> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Scénarios : grandir avec ACME Corp

> Comment la configuration des blueprint évolue d’un seul dépôt à une application multi-dépôts avec des dépendances partagées, puis à une entreprise multi-organisation.

Les blueprints comportent trois niveaux — dépôt, organisation et entreprise — et la question la plus fréquente est : *dans quel niveau faut-il placer cela ?*

Cette page répond à cette question en suivant une entreprise fictive, **ACME Corp**, au fil de trois étapes de croissance. Chaque étape introduit exactement un nouveau problème, et chaque problème est résolu par le niveau immédiatement supérieur. Passez directement à l’étape qui ressemble le plus à votre entreprise.

| Étape                                                                                                | À quoi ressemble ACME                                                                         | Ce qu’elle configure                                           |
| ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| [1. Un dépôt](#stage-1-one-repository)                                                               | Une seule application Rails, une Team                                                         | Un blueprint de dépôt                                          |
| [2. Plusieurs dépôts, dépendances partagées](#stage-2-several-repositories-with-shared-dependencies) | Cinq dépôts, une CLI de développement partagée, des services qui dépendent les uns des autres | Un blueprint d’organisation plus un blueprint par dépôt        |
| [3. Plusieurs organisations](#stage-3-multiple-organizations-the-enterprise-blueprint)               | Plusieurs Teams, chacune avec sa propre organisation, plus une équipe sécurité                | Un blueprint d’entreprise plus des blueprints par organisation |

<Info>
  En règle générale : **les blueprints de dépôt installent les dépendances du projet, les blueprints d’organisation installent tout ce qui est partagé par plusieurs dépôts, et les blueprints d’entreprise installent tout ce dont chaque organisation a besoin.** Les niveaux sont additifs et s’exécutent de haut en bas : entreprise → organisation → cloner les dépôts → dépôt.
</Info>

***

<div id="stage-1-one-repository">
  ## Étape 1 : un dépôt
</div>

ACME a un produit : `acme-web`, une application Rails avec Postgres et Redis. Deux ingénieurs, un seul dépôt. Il n’y a encore rien à mutualiser, donc **tout va dans le blueprint du dépôt**.

Ils ajoutent le dépôt dans **Settings > Environment > Blueprints > Add**, ouvrent son éditeur et écrivent :

```yaml acme-web (repository blueprint) theme={null}
initialize:
  - name: Install Ruby 3.3
    uses: github.com/ruby/setup-ruby@v1
    with:
      ruby-version: "3.3"

  - name: Install Postgres and Redis
    run: |
      sudo apt-get update -qq
      sudo apt-get install -y postgresql redis-server libpq-dev
      sudo systemctl enable --now postgresql redis-server
      sudo -u postgres createuser -s "$USER"

maintenance:
  - name: Install gems and prepare the database
    run: |
      bundle install
      bin/rails db:prepare

knowledge:
  - name: lint
    contents: bundle exec rubocop
  - name: test
    contents: bundle exec rspec
  - name: startup
    contents: bin/rails server -p 3000
```

C’est toute la configuration. Ils l’enregistrent, un build se lance, et chaque session démarre avec Ruby installé, Postgres lancé, les gems installées et la base de données migrée.

**Pourquoi pas encore de blueprint d’organisation ?** Un blueprint d’organisation qui ne sert qu’à un seul dépôt n’est qu’un niveau d’indirection. Attendez qu’un deuxième dépôt en ait besoin.

<Tip>
  ACME n’a pas écrit cela à la main. Ils ont demandé à Devin *"configure ton environnement pour ce dépôt"*, ont examiné la carte de suggestion, puis ont cliqué sur **Approve**. Consultez [Prise en main](/fr/onboard-devin/environment/blueprints#getting-started).
</Tip>

***

<div id="stage-2-several-repositories-with-shared-dependencies">
  ## Étape 2 : plusieurs dépôts avec des dépendances partagées
</div>

Deux ans plus tard, ACME a cinq dépôts :

| Dépôt           | Description                                                                                                                                                                                                                       |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `acme-devtools` | Une CLI (`acme`) qui lance des conteneurs, connecte les services entre eux et expose des noms d'hôte locaux (`acme.local`, `portal.acme.local`). Elle gère aussi la recherche dans la documentation interne (`acme docs:search`). |
| `acme-web`      | L'application principale. La plupart des fonctionnalités y sont développées.                                                                                                                                                      |
| `acme-portal`   | Portail client. Il appelle `acme-web`.                                                                                                                                                                                            |
| `acme-sso`      | Service d'authentification. Les deux applications en dépendent.                                                                                                                                                                   |
| `acme-events`   | Consommateur d'événements.                                                                                                                                                                                                        |

C'est là que les choses deviennent intéressantes, car les dépôts ne sont **pas indépendants** : on ne peut rien faire d'utile dans `acme-portal` tant que `acme-devtools` n'est pas installé et que `acme-sso` n'est pas en cours d'exécution. Deux questions se posent.

<div id="one-blueprint-per-application-or-just-one-for-the-development-cli">
  ### "Un blueprint par application, ou un seul pour la CLI de développement ?"
</div>

**Les deux — ils n’ont pas le même rôle.** Devin construit *un snapshot* contenant *tous* les dépôts configurés : ce n’est donc pas un choix à faire entre l’un ou l’autre.

* Ajoutez **les cinq dépôts** à l’environnement pour qu’ils soient tous clonés dans le snapshot.
* Placez **la configuration partagée entre plusieurs dépôts, une seule fois,** dans le **blueprint d’organisation** : environnements d’exécution, Docker, noms d’hôte locaux et identifiants du registre interne.
* Donnez à chaque dépôt son propre **blueprint de dépôt** pour ses dépendances propres et ses entrées `knowledge` spécifiques (commandes de lint, de test et de démarrage).

Voici pourquoi il ne faut pas tout regrouper dans le blueprint `acme-devtools` : les blueprints de dépôt s’exécutent une fois que tous les dépôts ont été clonés, mais leurs étapes s’exécutent **dans le répertoire du dépôt concerné**, et leurs entrées `knowledge` ne sont chargées que lorsque Devin travaille dans ce dépôt. Si `acme-devtools` installait tout, une session travaillant dans `acme-portal` ne verrait aucune des commandes de lint et de test du portail, et une seule étape `acme-devtools` en échec laisserait les quatre autres dépôts en apparence sains, mais inutilisables.

<div id="the-organization-blueprint">
  ### Le blueprint d’organisation
</div>

```yaml Organization-wide setup theme={null}
initialize:
  - name: Install Ruby 3.3
    uses: github.com/ruby/setup-ruby@v1
    with:
      ruby-version: "3.3"

  - name: Install Node.js 20
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: Install Docker and Compose
    run: |
      curl -fsSL https://get.docker.com | sh
      sudo usermod -aG docker "$USER"

  - name: Local hostnames for the development CLI
    run: |
      for host in acme.local portal.acme.local sso.acme.local; do
        grep -q " $host$" /etc/hosts \
          || echo "127.0.0.1 $host" | sudo tee -a /etc/hosts > /dev/null
      done

maintenance:
  - name: Authenticate to the internal registry
    run: |
      bundle config set --global https://gems.acme.internal "$ACME_REGISTRY_TOKEN"
      npm config set //npm.acme.internal/:_authToken "$ACME_REGISTRY_TOKEN"

post-build:
  - name: Verify the stack comes up
    run: |
      acme up --detach
      acme status
      acme down
```

Trois points à noter :

1. **`initialize` versus `maintenance`.** Docker, les environnements d’exécution et les noms d’hôte relèvent d’une configuration système ponctuelle ; ils doivent donc aller dans `initialize`. Les identifiants du registre doivent être actualisés à chaque build périodique ; ils doivent donc aller dans `maintenance`.

   Le CLI `acme` lui-même est volontairement absent ici. Il se trouve dans `acme-devtools`, et les étapes au niveau de l’organisation s’exécutent **avant le clonage de tout dépôt** ; il est donc installé depuis le blueprint propre à ce dépôt (présenté ci-dessous). Cette installation s’exécute pendant le build et est conservée dans le snapshot, que tous les autres dépôts peuvent ensuite utiliser.
2. **`post-build` est le véritable avantage des configurations multi-dépôts.** Il s’exécute une fois que *tous* les dépôts ont été clonés et configurés ; c’est donc le seul endroit où vous pouvez vérifier que toute la stack démarre correctement ensemble. Un code de sortie non nul fait échouer le build, ce qui vous permet de repérer une stack défaillante au moment du build plutôt qu’en pleine session. Voir [`post-build`](/fr/onboard-devin/environment/blueprint-reference#post-build).
3. **Les secrets relèvent de l’organisation**, et non de chaque dépôt. Un seul `ACME_REGISTRY_TOKEN` dans l’onglet **Secrets** du blueprint d’organisation suffit pour les commandes `bundle install` et `npm install` de tous les dépôts.

<Warning>
  **Point d’attention sur l’ordre d’exécution :** `initialize` et `maintenance` au niveau de l’organisation s’exécutent tous deux **avant** le clonage des dépôts (voir l’[ordre du build](/fr/onboard-devin/environment/blueprints#how-builds-work)). Tout ce qui nécessite du code source déjà extrait — comme un CLI présent *dans* l’un de vos dépôts — doit aller dans le blueprint de ce dépôt ou dans `post-build`, pas dans `maintenance` au niveau de l’organisation. Ne le laissez au niveau de l’organisation que si vous pouvez l’installer depuis un artefact publié, comme une archive tar, un package ou une image de conteneur.
</Warning>

<div id="the-repository-blueprints">
  ### Les blueprints de dépôt
</div>

Chaque blueprint de dépôt reste succinct, puisque tout ce qui est partagé existe déjà :

```yaml acme-devtools (repository blueprint) theme={null}
initialize: |
  ./bin/install            # ajoute `acme` au PATH pour l'ensemble du snapshot

maintenance: |
  acme docs:index          # actualise l'index de documentation interne à chaque build

knowledge:
  - name: cli
    contents: |
      `acme` manages every local service. Common commands:
        acme up <service>     start a service and its dependencies
        acme status           list running services
        acme docs:search <q>  search internal ACME engineering documentation
      Prefer `acme docs:search` over guessing at conventions.
```

```yaml acme-portal (repository blueprint) theme={null}
maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: startup
    contents: |
      The portal needs SSO running first:
        acme up sso
        acme up portal
      Then visit https://portal.acme.local
```

`acme-web`, `acme-sso` et `acme-events` ont la même structure : une étape `maintenance` pour leurs propres dépendances, et des entrées `knowledge` pour leurs propres commandes de lint, de test et de démarrage.

<Tip>
  **Placez `acme-devtools` en premier** dans la liste des dépôts. Les blueprints de dépôt s’exécutent dans l’ordre affiché dans Settings ; le dépôt qui fournit la CLI partagée doit donc être configuré avant les dépôts qui l’utilisent.
</Tip>

<Info>
  **Knowledge est propre à chaque dépôt.** Avec cinq dépôts configurés, une session qui travaille dans `acme-portal` voit les entrées Knowledge du portail, ainsi que celles de l’organisation et de l’entreprise, mais pas celles de `acme-web`. C’est pourquoi chaque dépôt mérite son propre blueprint, même lorsque sa section `maintenance` ne fait qu’une ligne.
</Info>

<Tip>
  Comme la CLI `acme` sait déjà tout exécuter, la partie la plus utile de ces blueprints est la section **`knowledge`** : elle indique à Devin quelle commande CLI utiliser. Faites-la pointer vers votre moteur de recherche interne dans la documentation, si vous en avez un.
</Tip>

<div id="if-your-services-live-in-a-monorepo-instead">
  ### Si vos services se trouvent plutôt dans un monorepo
</div>

L’idée est la même, mais à un niveau inférieur : utilisez des [espaces de travail](/fr/onboard-devin/environment/workspaces) pour donner à chaque package sa propre configuration et son propre Knowledge dans un seul dépôt, au lieu d’un blueprint par dépôt.

***

<div id="stage-3-multiple-organizations-the-enterprise-blueprint">
  ## Étape 3 : plusieurs organisations — le blueprint d’entreprise
</div>

ACME compte désormais 400 ingénieurs. Platform, Payments et Data ont chacun leur propre **organisation** Devin, avec des dépôts distincts, des membres distincts et des snapshots distincts. Une équipe de sécurité a des exigences qui s’appliquent à toutes :

* Tout le trafic passe par un proxy d’entreprise, avec une autorité de certification interne.
* Tous les packages proviennent d’Artifactory, jamais de dépôts publics.
* Chaque environnement doit disposer des outils de détection des dépendances et des secrets de l’entreprise.
* Python est en version 3.12 et Node.js en version 20 dans toute l’entreprise, sans exception.

Rien de tout cela n’a sa place dans un blueprint d’organisation, car il faudrait le **copier dans chaque organisation**, et il finirait par diverger dès qu’une équipe oublierait de le mettre à jour. C’est à cela que sert le **blueprint d’entreprise** : un environnement de base qui s’exécute en premier, dans le build de chaque organisation, à l’échelle de toute l’entreprise.

```yaml Devin's base environment (enterprise blueprint) theme={null}
initialize:
  - name: Corporate certificate authority and proxy
    run: |
      sudo cp "$FILE_ACME_CA_CERT" /usr/local/share/ca-certificates/acme-ca.crt
      sudo update-ca-certificates
      cat <<'EOF' >> ~/.bashrc
      export HTTPS_PROXY=http://proxy.acme.internal:8080
      export NO_PROXY=localhost,127.0.0.1,.acme.internal
      export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/acme-ca.crt
      export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
      EOF

  - name: Standard Python runtime
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: Security tooling
    run: |
      pip install bandit safety
      curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

maintenance:
  - name: Point every package manager at Artifactory
    run: |
      pip config set global.index-url \
        "https://devin:$ARTIFACTORY_TOKEN@artifactory.acme.internal/api/pypi/pypi/simple/"
      npm config set registry https://artifactory.acme.internal/api/npm/npm/
      npm config set //artifactory.acme.internal/api/npm/npm/:_authToken "$ARTIFACTORY_TOKEN"

knowledge:
  - name: security-policy
    contents: |
      All dependencies must resolve through artifactory.acme.internal.
      Never add a public registry to a lockfile or a CI configuration.
```

`ARTIFACTORY_TOKEN` est un **secret d’entreprise**, défini une seule fois dans **Settings > environnement de base de Devin > Secrets** et disponible dans chaque build et chaque session de chaque organisation. Le certificat est un fichier joint, mis à disposition du build sous la forme de `$FILE_ACME_CA_CERT`.

<div id="what-each-tier-owns-now">
  ### Ce que gère désormais chaque niveau
</div>

| Niveau           | Responsable                                        | Exemple ACME                                                                                                          |
| ---------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Entreprise**   | Administrateurs de la sécurité et de la plateforme | Autorité de certification, proxy, Artifactory, Python 3.12, outils d’analyse, un token partagé                        |
| **Organisation** | Administrateurs de chaque équipe                   | Payments : Docker, l’interface en ligne de commande `acme` et les noms d’hôte de l’équipe. Data : Spark et le JDK 17. |
| **Dépôt**        | Responsable du dépôt                               | `bundle install`, `npm install`, ainsi que les consignes de linting, de test et de démarrage                          |

Le blueprint d’organisation Payments de l’étape 2 continue de fonctionner **sans changement**. Il n’a simplement plus besoin d’installer Python ni de configurer les registres, car le niveau Entreprise l’a déjà fait. Le blueprint d’organisation Data installe Spark et un JDK, que Payments n’utilise jamais. Les blueprints de dépôt restent inchangés.

<div id="operating-it">
  ### L’utiliser
</div>

* **La mise à niveau de Python de 3.12 vers 3.13** se résume à modifier une seule ligne, puis à lancer un [rebuild à l’échelle de l’entreprise](/fr/enterprise/environment-management/overview#enterprise-wide-rebuilds), qui se propage à toutes les organisations.
* **Lorsqu’une Team a besoin d’un identifiant différent** — par exemple, si l’organisation Data dispose de son propre realm Artifactory — cette Team définit un secret d’organisation portant le même nom, et il **prévaut sur** le secret d’entreprise.
* **Pour déployer cela progressivement** dans les organisations, consultez [Migrer votre entreprise](/fr/enterprise/environment-management/rollout).

***

<div id="deciding-where-something-goes">
  ## Déterminer où placer chaque élément
</div>

Parcourez la liste dans l’ordre. Le premier « oui » vous donne la réponse :

<Steps>
  <Step title="Est-ce que toutes les organisations de l’entreprise en ont besoin ?">
    → **Blueprint d’entreprise.** Certificats, proxys, registres internes, environnements d’exécution imposés, outils de sécurité et secrets à l’échelle de l’entreprise.
  </Step>

  <Step title="Est-ce que deux dépôts ou plus dans cette organisation en ont besoin ?">
    → **Blueprint d’organisation.** Docker, CLI de développement partagés, noms d’hôte locaux, orchestration de services entre dépôts et identifiants de registre. Validez la pile obtenue dans `post-build`.
  </Step>

  <Step title="Est-ce que seul ce dépôt en a besoin ?">
    → **Blueprint de dépôt.** Installation des dépendances, migrations et entrées `knowledge` pour ses commandes de lint, de test et de démarrage.
  </Step>

  <Step title="S’agit-il d’une information plutôt que d’une commande à exécuter ?">
    → **`knowledge`**, au niveau concerné. Il n’est jamais exécuté ; il est chargé dans le contexte de Devin.
  </Step>
</Steps>

Erreurs courantes que cela permet d’éviter :

* **Tout mettre dans le blueprint d’un seul dépôt.** Les autres dépôts n’obtiennent aucune entrée `knowledge`, et une seule étape défaillante peut donner l’impression que toute la configuration est en mauvais état.
* **Dupliquer les outils partagés dans chaque dépôt.** Quand deux dépôts installent des versions différentes du même outil global, c’est la dernière exécution qui l’emporte. Placez plutôt l’outil dans le blueprint d’organisation.
* **Ignorer la vérification entre dépôts.** Quand vos dépôts ne fonctionnent qu’ensemble, `post-build` est le seul endroit où vous pouvez le vérifier — avant le début d’une session, plutôt qu’en cours de session.

<div id="related-pages">
  ## Pages associées
</div>

* [Configuration déclarative](/fr/onboard-devin/environment/blueprints) — ordre de build, snapshots et dépannage
* [référence Blueprint](/fr/onboard-devin/environment/blueprint-reference) — tous les champs, y compris `post-build` et `clone`
* [bibliothèque de modèles](/fr/onboard-devin/environment/templates) — blueprints à copier-coller par langage et par registre
* [Workspaces and monorepos](/fr/onboard-devin/environment/workspaces) — l’équivalent monorepo de l’étape 2
* [Vue d’ensemble de l’environnement Enterprise](/fr/enterprise/environment-management/overview) — l’étape 3 en détail