# Utiliser BMAD+ en équipe

> Ce qu’il faut commiter et ce qui reste local, les réglages à convenir, un adaptateur par collègue sur un socle commun, une politique de mise à jour sûre, portes de CI et accueil.

Canonical: https://bmad-plus.rochetta.fr/fr/docs/guides/for-teams/
Language: fr
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

Documentation BMAD+ › [Guides](https://bmad-plus.rochetta.fr/fr/docs/guides/) › Utiliser BMAD+ en équipe

BMAD+ vit dans le projet : une équipe le partage donc comme n’importe quelle autre partie du dépôt, en décidant ce qui est versionné, ce qui est configuré de la même façon pour tous et qui le modifie. Cette page liste ces décisions et les faits qui rendent chacune sûre : hashes de propriété, modifications préservées, politique de mise à jour par projet, adaptateurs générés à partir d’un seul socle. Elle s’adresse aux responsables techniques et à quiconque doit accueillir des collègues qui utilisent des outils IA différents. Quand un choix relève du goût plutôt que d’un fait, le texte le dit.

<a id="what-to-version"></a>
## Ce qu’il faut versionner et ce qui reste local

**Les fichiers que crée BMAD+, et à qui ils appartiennent**

| Fichiers | Nature | À considérer |
| --- | --- | --- |
| `AGENTS.md`, fichiers d’adaptateur, `.agents/skills/`, `.agents/data/` | Générés et copiés par l’installateur ; hachés dans le manifeste. | Les commiter donne à chaque collègue les mêmes instructions sans lancer l’installateur. Ne pas les commiter, c’est que chacun installe la même version. Les deux marchent ; choisissez. |
| `_bmad/config.yaml` | Vos réglages : langue, mode d’exécution, points de contrôle, uat, swarm. Écrit une fois et fusionné, jamais écrasé. | Le fichier naturel à partager, puisqu’il porte les conventions de l’équipe. |
| `_bmad/update-policy.json` | Écrit par `update-policy` quand vous changez la politique. | Partagez-le si l’équipe veut une seule politique ; il nomme la plage de versions autorisée. |
| `_bmad/review-rules.yaml` et ses documents | Règles de revue du projet. | Partagez-le : un fichier de constats répond à un seul jeu de règles, l’équipe doit donc relire avec le même. |
| `_bmad/.bmad-plus-install.json` | Le manifeste : version, packs, outils, un SHA-256 par fichier installé. | Il doit rester cohérent avec les fichiers qu’il décrit : versionnez-le avec eux, ou aucun des deux. |
| `.agents/memory/` | Décisions, leçons, motifs, contexte, passations. | Versionnez-la si la mémoire est celle de l’équipe. L’installation et la mise à jour n’écrasent jamais ces fichiers. |
| `.agents/memory/.brain-link` | Le chemin absolu du cerveau relié sur une machine. | Propre à la machine : ne le partagez pas. |
| `_bmad-output/` | Livrables : briefs, PRD, preuves de revue, résultats de recette. | En général versionné en partie : briefs, PRD, tri et résultats sont des preuves à garder. |
| `.bmad/`, `.bmad-plus/` | Cache et reçus de mise à jour, journal de mémoire, état des essaims et des exécutions Nexus. | État local. Le verrou de mise à jour et les reçus concernent une seule copie de travail. |

<a id="shared-conventions"></a>
## Conventions à convenir ensemble

**Réglages et leur effet sur l’équipe**

| Réglage | Où | Pourquoi en convenir |
| --- | --- | --- |
| Packs | `install --packs` | Les packs définissent quels agents existent. `--packs` et `--tools` s’ajoutent à une installation précédente : on peut donc ajouter un pack plus tard sans rien perdre. |
| `communication_language`, `document_output_language` | `_bmad/config.yaml` | La langue que parlent les agents et la langue des livrables. |
| `execution_mode` | `_bmad/config.yaml` | `manual`, `autopilot` ou `hybrid` : jusqu’où l’équipe laisse Nexus avancer seul. |
| `checkpoints` | `_bmad/config.yaml` | Qui approuve quoi : `discovery`, `architecture`, `story`, `delivery`, chacun `require_approval`, `notify_only` ou `auto`. |
| `uat.mode` et `uat.environment` | `_bmad/config.yaml` | `advisory`, `gate` ou `off`, et l’environnement de test visé par une recette. |
| `swarm.budget` et `swarm.wave` | `_bmad/config.yaml` | Combien de sous-agents une exécution peut utiliser avant que quelqu’un doive dire oui (26 et 10 par défaut). |
| Règles de revue | `_bmad/review-rules.yaml` | Le même jeu de règles pour chaque relecteur, humain ou agent. |
| Politique de mise à jour | `_bmad/update-policy.json` | Voir la section suivante. |

<a id="adapters"></a>
## Un socle, un adaptateur par collègue

Tous les adaptateurs sont générés à partir du même registre que `AGENTS.md` : un collègue sous Cursor et un autre sous Claude Code obtiennent donc la même liste et les mêmes règles, seul le format de fichier diffère. `--tools` accepte plusieurs ids à la fois (`--tools claude-code,cursor`), `all` ou `none`. L’installateur détecte les outils d’après leurs dossiers (`.claude/`, `.gemini/`, `.cursor/`, `.codex/`, `.opencode/`, `.aider.conf.yml`) quand vous ne passez pas `--tools` ; `--yes` sans outil détecté n’écrit aucun adaptateur. Un adaptateur BMAD+ que vous avez modifié est préservé. Un fichier d’instructions que vous avez écrit vous-même est préservé par une installation interactive et par `update` ; `install --yes` le copie d’abord en `<file>.bak`, puis le remplace. Les anciens fichiers de l’installateur sont sauvegardés en `<file>.bak`.

**Adaptateurs**

| Id de l’outil | Fichier écrit | Détecté par |
| --- | --- | --- |
| `claude-code` | `CLAUDE.md` | un dossier `.claude/` |
| `gemini-cli` | `GEMINI.md` | un dossier `.gemini/` |
| `antigravity` | `GEMINI.md` (partagé avec gemini-cli) | un dossier `.gemini/antigravity/` |
| `cursor` | `.cursor/rules/bmad-plus.mdc` (toujours appliqué) | un dossier `.cursor/` |
| `codex-cli` | `.codex/AGENTS.md` | un dossier `.codex/` |
| `opencode` | `.opencode/AGENTS.md` | un dossier `.opencode/` |
| `aider` | `CONVENTIONS.md` ; ajoutez `read: CONVENTIONS.md` à `.aider.conf.yml` ou lancez `/read CONVENTIONS.md` dans Aider | un fichier `.aider.conf.yml` |

Un collègue qui ajoute un outil plus tard relance l’installateur avec cet outil : l’exécution garde ce qui est déjà installé et ajoute l’adaptateur manquant. `--tools none` installe agents, compétences et mémoire sans toucher à la configuration d’aucun outil, ce qui convient à un projet dont le `CLAUDE.md` ou l’`AGENTS.md` est tenu à la main.

<a id="update-policy"></a>
## Une politique de mise à jour sûre

Le défaut est la notification : les instructions générées demandent à l’assistant de lancer `update-check` une fois par session et de le signaler. Rien n’est appliqué. Pour une équipe, le schéma pratique est une personne (ou un job de CI) qui décide du moment, applique `update`, relit le rapport et commite ; les autres reçoivent le résultat à leur prochain pull. Si l’équipe veut que les mises à jour passent sans humain, `auto` exige une plage semver explicite et plusieurs garde-fous : le résultat du registre doit être frais, les fichiers gérés inchangés, l’inventaire de hashes de l’installation complet, la version cible exactement celle de la commande, et l’exigence Node satisfaite. Une recherche hors ligne, périmée ou en échec n’autorise jamais une mise à jour automatique.

**Lire et fixer la politique**

```text
$ npx bmad-plus update-policy
Update policy: notify; channel=latest; range=none; prereleases=false
$ npx bmad-plus update-policy --json
{"policy":{"mode":"notify","channel":"latest","allowedRange":null,"allowPrerelease":false,"registry":"https://registry.npmjs.org/"},"changed":false}
$ npx bmad-plus update-policy --mode auto --range "^0.23.0"
Update policy saved: auto; channel=latest; range=^0.23.0; prereleases=false
$ npx bmad-plus update-policy --mode notify
Update policy saved: notify; channel=latest; range=^0.23.0; prereleases=false
$ npx bmad-plus update-check --offline --json
{"schemaVersion":1,"installedVersion":"0.23.0","runningVersion":"0.23.0","latestVersion":null,"targetVersion":null,"channel":"latest","status":"unknown","checkedAt":null,"source":"none","stale":false,"updateAvailable":null,"releaseEligible":false,"versionEligible":false,"canAutoApply":false,"engineCompatible":null,"engines":{},"reason":"offline"}
```

Sortie capturée lors d’une exécution réelle. Source: Rejoué sur un serveur de test le 2026-10-18 avec la source 0.23.0 (tools/cli/bmad-plus-cli.js) dans un projet Git jetable

- `off` arrête toute recherche. `notify` (défaut) informe. `auto` exige `--range` ; ajoutez `--allow-prerelease` ou `--stable-only` pour gérer les préversions. Le registre est fixé à `https://registry.npmjs.org/`.
- Une mise à jour préserve les fichiers modifiés depuis leur hash enregistré et les signale ; un conflit bloque la voie automatique. Les fichiers qu’une nouvelle version ne livre plus sont retirés après une sauvegarde restaurable. Chaque mise à jour appliquée écrit `.bmad/updates/<receipt-id>/` avec `receipt.json` et `backups/` ; `update --restore <receipt-id> --yes` y revient et refuse d’écraser des modifications locales ultérieures.
- Une installation antérieure à 0.13 (sans hashes de fichiers) ne peut pas être mise à jour automatiquement ; une migration explicite, `npx --yes bmad-plus@0.23.1 update --yes`, sauvegarde ce qu’elle remplace.
- `install` ne change jamais la version installée : un retour en arrière est refusé et une montée de version passe par `update`. Si deux collègues ont installé des versions différentes, celui qui a la plus ancienne lance `update`.
- Un verrou `.bmad/update.lock` protège le projet pendant une mise à jour (considéré périmé après 60 minutes ou quand son propriétaire est mort) ; `doctor` signale un verrou qui n’est pas le sien.

<a id="ci-and-gates"></a>
## CI et portes

BMAD+ n’installe aucun hook Git ni hook de cycle de vie dans votre projet, parce qu’une consigne peut être contournée. Ce qu’une équipe veut imposer, elle l’impose avec sa propre CI, grâce à des codes de sortie conçus pour cela.

**Contrôles qu’une équipe peut brancher en CI**

| Contrôle | Commande | Échoue quand |
| --- | --- | --- |
| Intégrité de l’installation | `bmad-plus doctor --json` | Sortie 1 sur toute erreur (un fichier requis manquant, par exemple). Les fichiers modifiés sont des avertissements. |
| Veille des mises à jour | `bmad-plus update-check --json` | Sortie 1 pour un runtime, une installation ou une politique invalide ; un registre inaccessible donne `unknown`, pas un échec. |
| Porte de revue sur les pull requests | Les recettes de `docs/recipes/ci-review/` | La revue est incomplète (sortie 2) ou a des constats ouverts (sortie 1). |
| Une version a une recette humaine acceptée | `uat-release-gate.mjs` de la compétence uat | Pas de résultat terminé, une autre révision, un échec non classé, une écriture non confirmée (sorties 1 à 3 ; 4 signifie que la porte n’a pas pu s’exécuter). |
| Une version a au moins une recette | `uat-spec-present.mjs` | Aucune recette ne nomme la version de `package.json`. |
| Un fichier d’intake d’équipe est valide | `bmad-plus intake check FILE` | Sortie 1 avec tous les problèmes listés. |
| Preuves Shield | `bmad-plus assurance verify` et `ai-register check` | `assurance verify` sort avec 1 quand une affirmation n’est pas étayée ; `ai-register check` ne fait qu’avertir. |

<a id="onboarding"></a>
## Accueillir un collègue

1. **Récupérer le dépôt et vérifier l’installation** Si les fichiers générés sont commités, `doctor` fonctionne déjà. Sinon, lancez l’installateur avec la liste de packs de l’équipe, puis `doctor`.

   ```sh
   npx bmad-plus@0.23.1 install --packs core,memory --tools claude-code
   npx bmad-plus@0.23.1 doctor
   ```
2. **Ajouter votre propre outil** Installez avec l’id de votre outil ; les fichiers existants sont conservés et votre adaptateur est ajouté.

   ```sh
   npx bmad-plus@0.23.1 install --packs core,memory --tools cursor
   ```
3. **Lire le socle, puis interroger l’assistant** Ouvrez `AGENTS.md` pour la liste des agents et les règles de l’équipe, puis tapez `bmad-help` dans la conversation. Lisez les réglages de `_bmad/config.yaml` pour savoir quels points de contrôle s’arrêteront pour vous demander.
4. **Relier la mémoire à votre machine** Avec le pack Memory, l’installation détecte un cerveau sur votre machine (`BMAD_PLUS_BRAIN`, un dossier `_brain/` dans un dossier parent, `~/.bmad-plus/brain/`, puis un `~/.claude/memory/` non vide) et l’enregistre dans `.agents/memory/.brain-link`. Ce fichier est à vous seul ; les fichiers de mémoire du projet qui l’entourent sont ceux de l’équipe.

<a id="governance"></a>
## Notes de gouvernance pour les équipes

- Approbations : si l’équipe veut qu’une personne approuve l’architecture et la livraison, gardez `require_approval` sur ces points de contrôle. Un autopilot avec `auto` partout est un choix délibéré, pas un défaut.
- Budget : un essaim plus grand que `swarm.budget` est refusé tant qu’un humain n’a pas dit oui ; la génération de médias payants est demandée à chaque fois. Personne ne devrait passer `--approved` à la place d’un autre.
- OSINT : rechercher une personne nommée exige un but et une base légale consignés, à chaque exécution. En équipe, cela suppose quelqu’un qui porte cette décision. Voir la page de confiance.
- Shield : les rapports sont générés par IA et portent la mention « not legal advice » ; une décision de conformité reste à une personne qualifiée.
- Secrets : les clés d’API relèvent de l’environnement de chaque personne ou de la CI, jamais du dépôt. Le plancher de masquage de la revue et celui des notes de recette masquent les formes courantes d’identifiants ; ils ne remplacent pas le fait de ne pas commiter de secrets.
- Propriété : chaque fichier écrit par BMAD+ est haché. Un fichier modifié par un collègue est conservé par la mise à jour et la désinstallation et signalé par `doctor` comme modifié (un avertissement) : la personnalisation locale est visible, pas écrasée en silence.

<a id="example-team-conventions-review"></a>
### Auditer les conventions BMAD+ de l’équipe

À utiliser quand un nouveau responsable technique arrive, ou avant d’accueillir un collègue. L’assistant ne fait que lire ; rien n’est modifié.

**Dans votre assistant IA**

```text
Lis _bmad/config.yaml, _bmad/update-policy.json s’il existe, _bmad/review-rules.yaml s’il existe et le manifeste _bmad/.bmad-plus-install.json. Résume dans un tableau : version installée, packs, outils, mode d’exécution, comportement de chaque point de contrôle, mode uat, budget d’essaim, mode et plage de la politique de mise à jour. Liste ensuite ce qu’un nouveau collègue devrait faire pour obtenir la même configuration, et signale tout réglage qui semble incohérent avec les autres. Ne change rien.
```

**Ce que vous devriez obtenir** Un tableau des valeurs réelles lues dans les fichiers, une liste d’accueil (installer avec les mêmes packs, ajouter votre outil, lire le socle) et une courte liste d’incohérences, par exemple `execution_mode: autopilot` avec tous les points de contrôle sur `auto`. Aucun fichier n’est modifié.

**Voir aussi**

- [Votre première heure avec BMAD+](https://bmad-plus.rochetta.fr/fr/docs/guides/first-hour/)
- [Installer, mettre à jour, désinstaller](https://bmad-plus.rochetta.fr/fr/docs/guides/install-lifecycle/)
- [Référence : config.yaml](https://bmad-plus.rochetta.fr/fr/docs/reference/config-yaml/)
- [Référence : adaptateurs](https://bmad-plus.rochetta.fr/fr/docs/reference/adapters/)
- [Confiance et propriété](https://bmad-plus.rochetta.fr/fr/docs/security/trust-and-ownership/)
- [Traitement des données](https://bmad-plus.rochetta.fr/fr/docs/security/data-handling/)

[Documentation BMAD+](https://bmad-plus.rochetta.fr/fr/docs/) · [Guides](https://bmad-plus.rochetta.fr/fr/docs/guides/)

[Code sur GitHub](https://github.com/lrochetta/BMAD-PLUS)