Glossaire
Chaque terme de la documentation BMAD+ en mots simples, par thème : hôte, socle, pack, compétence, intake, essaim, graine, porte, reçu, recette et mots d’état des outils.
Sur cette page
- Architecture
- Fichiers et cycle de vie
- Intake et essaims
- Orchestration
- Revue et recette
- Mémoire et packs spécialisés
- Mots d’état affichés par les outils
Les tableaux sont groupés par thème plutôt que par ordre alphabétique, pour que les mots voisins restent ensemble. Les noms d’agents, de commandes, d’options, de fichiers et les mots d’état affichés par les outils (comme needs-approval) restent en anglais dans toutes les langues, car c’est ce que vous verrez à l’écran. La colonne de droite renvoie à la page qui explique le terme en contexte.
Architecture#
Termes d’architecture| Terme | Sens | Pour en savoir plus |
|---|
| hôte (host) | L’outil de codage IA qui lit les instructions et fait le travail avec son propre modèle et ses propres permissions : Claude Code, Cursor, Codex CLI et d’autres. | Comment fonctionne BMAD+ |
|---|
host-managed | Le contrat d’exécution de BMAD+ : l’hôte fournit le modèle, les permissions et les éventuels sous-agents ; BMAD+ n’appelle aucun modèle et ne fait rien tourner en arrière-plan. | Comment fonctionne BMAD+ |
|---|
| socle (spine) | AGENTS.md, le fichier d’instructions unique et généré que tous les outils lisent : liste des agents, compétences, règles de mémoire et faits du registre. | Comment fonctionne BMAD+ |
|---|
| adaptateur | Un fichier court généré, au format qu’un outil attend (CLAUDE.md, GEMINI.md, une règle Cursor, ...), qui renvoie au socle. | Adaptateurs |
|---|
| pack | Un groupe d’agents, de compétences et de workflows installés ensemble. Il y en a dix ; Core est obligatoire. | Tous les packs |
|---|
| agent | Une persona nommée à qui vous vous adressez dans la conversation (« Forge, ... »). 48 au total dans les packs, dont 15 points d’entrée de l’installateur. | La liste des agents |
|---|
| rôle | Un mode à l’intérieur d’un agent, comme Analyste ou Product Manager pour Atlas. Le changement est demandé ou automatique, et toujours annoncé. | Comment les rôles s’activent |
|---|
| persona | L’identité nommée d’un agent, avec son nom, son rôle et sa description, telle que déclarée dans le registre. | Registre et skills |
|---|
| compétence (skill) | Un dossier avec un SKILL.md que l’hôte charge au besoin : une procédure comme autopilot, intake ou swarm. Chaque agent est aussi une compétence. | Registre et skills |
|---|
| workflow | Une procédure Markdown pas à pas dans un pack, exécutée par votre assistant. Dev Studio en a 38 et Shield 11. | Dev Studio |
|---|
| registre (registry) | registry.yaml, la source unique de vérité du dépôt source, dont sont générés les packs, les listes, les nombres et les adaptateurs. | Registre et skills |
|---|
| CLI | L’outil en ligne de commande bmad-plus : tenue de registres déterministe sur des fichiers locaux. Il n’appelle aucun modèle et demande Node.js 20 ou plus récent. | Référence de la ligne de commande |
|---|
| instruction de conversation | Une phrase destinée à votre assistant, comme bmad-help, autopilot ou parallel. Pas une commande de terminal. | Comment fonctionne BMAD+ |
|---|
Fichiers et cycle de vie#
Termes de fichiers et de cycle de vie| Terme | Sens | Pour en savoir plus |
|---|
| manifeste | _bmad/.bmad-plus-install.json : version, packs, outils et SHA-256 de chaque fichier installé. | Confiance et propriété |
|---|
| inventaire de propriété | Le fileInventory du manifeste. Un fichier appartient à BMAD+ tant qu’il correspond à son hash ; une fois modifié, il est à vous. Son statut est complete, incomplete, legacy ou invalid. | Confiance et propriété |
|---|
| reçu (receipt) | Le registre d’une mise à jour appliquée dans .bmad/updates/<id>/receipt.json, avec les sauvegardes, utilisé par update --restore. | Installer, mettre à jour, désinstaller |
|---|
| politique de mise à jour | _bmad/update-policy.json : off, notify (par défaut) ou auto avec une plage de versions explicite, plus les réglages de canal et de préversions. | Utiliser BMAD+ en équipe |
|---|
| point de contrôle (checkpoint) | Un arrêt dans une exécution autopilot, réglé par étape (discovery, architecture, story, delivery) sur require_approval, notify_only ou auto. | Nexus |
|---|
| mode d’exécution | manual (vous appelez chaque agent), autopilot (Nexus gère le pipeline) ou hybrid (autopilot avec des points de contrôle fréquents). | Référence : config.yaml |
|---|
| livrable | Un fichier produit par un agent, en général sous _bmad-output/ : un brief, un PRD, une architecture, des stories, une revue, un rapport. | Votre première heure |
|---|
| mode consignes seules | La façon dont le pack SEO fonctionne sans environnement Python utilisable : l’agent suit ses consignes, marque les catégories non vérifiées et ne calcule aucune note globale. | Le pack SEO |
|---|
Intake et essaims#
Termes d’intake et d’essaim| Terme | Sens | Pour en savoir plus |
|---|
| intake (questionnaire d’entrée) | La liste des questions auxquelles un pack doit avoir une réponse avant d’agir, définie dans un intake.yaml et pilotée par bmad-plus intake. | Intake |
|---|
| indispensable (must-have) | Une question sans laquelle le pack ne peut pas démarrer : elle doit être répondue ou marquée inconnue avec son risque. Elle ne peut porter aucune valeur par défaut. | Intake |
|---|
answered, defaulted, unknown | Les trois statuts d’une réponse d’intake : vous l’avez dit ; vous avez laissé la valeur proposée ; vous ne savez pas (le risque est copié). | Intake |
|---|
| brief | Deux sens. Un brief d’intake est le Markdown que la CLI rédige à partir des réponses, le contrat des étapes suivantes du pack. Un brief d’essaim est le fichier qu’un sous-agent lit comme toute son instruction. | Intake |
|---|
| essaim (swarm) | De nombreux sous-agents qui font chacun une fois le même genre de travail, pilotés par bmad-plus swarm : un panel, un jury ou un fanout. | Essaims |
|---|
| sous-agent | Une session de travail lancée par l’hôte, une par brief. BMAD+ ne la démarre jamais ; c’est le modérateur qui le fait, via l’hôte. | Essaims |
|---|
panel, jury, fanout | Les trois sortes d’essaim : unités distribuées à partir d’un profil ; unités listées avec un angle chacune ; unités fournies avec des périmètres d’écriture disjoints. | Essaims |
|---|
| unité, fiche (card) | Une unité est un membre d’un essaim. Sa fiche est sa donnée (segment, âge, objection, angle, périmètre), distribuée ou listée à l’init et figée pour l’exécution. | Essaims |
|---|
| profil, définition, gabarit, contexte | Les quatre entrées d’un essaim : la distribution du panel ; le JSON qui déclare le type, la forme de réponse et le décompte ; le gabarit de brief ; et le texte que lisent les unités (un argumentaire, par exemple), inclus tel quel. | Essaims |
|---|
| graine (seed) | Un nombre de 0 à 2147483647 qui rend la distribution reproductible : même profil, même --n, même graine, mêmes fiches. | Essaims |
|---|
| budget, vague | swarm.budget (26) est le nombre de sous-agents qu’une exécution peut utiliser avant qu’un humain doive dire oui ; swarm.wave (10) le nombre lancé ensemble. | Essaims |
|---|
| approbation | Le oui humain qui autorise une exécution au-delà du budget. Enregistré par --approved ; l’assistant ne doit pas le passer de lui-même. | Essaims |
|---|
| mention de transparence (disclosure) | La phrase qui ouvre chaque décompte, comme « Simulated units are not people ». Rapportée une fois, avant tout chiffre. | Essaims |
|---|
| décompte (tally) | tally.json et tally.md, calculés sur les seules réponses valides, avec les unités ignorées nommées et le dénominateur affiché. | Essaims |
|---|
| réponse valide | Un fichier de réponse bien formé : bon id, tous les champs obligatoires, aucun champ non déclaré, types et bornes respectés. Valide veut dire bien formé, pas vrai. | Essaims |
|---|
Orchestration#
Termes Nexus| Terme | Sens | Pour en savoir plus |
|---|
| autopilot | Le mode de Nexus qui déroule Discovery, Build et Ship avec points de contrôle. Lancé en disant autopilot dans la conversation. | Nexus |
|---|
| exécution Nexus (run) | Un graphe de tâches durable et ses tentatives, stocké sous .bmad-plus/nexus/runs/, créé à partir d’un plan. | Nexus |
|---|
| plan | Le fichier JSON que vous écrivez pour nexus create : des tâches avec objectif, périmètre, artefacts, ressources, contrôles et limites. | Nexus |
|---|
| tâche, tentative | Une tâche est un nœud du plan. Une tentative est un essai de cette tâche, lié à une identité (session d’hôte ou processus supervisé). | Nexus |
|---|
| périmètre d’écriture (scope) | Les fichiers ou dossiers qu’une tâche peut écrire. Les périmètres sont exclusifs et disjoints entre tâches. | Nexus |
|---|
| ressource | Une entrée protégée d’une tâche (instructions, vérificateur) que Nexus hache et qui doit se trouver hors de tout périmètre d’écriture. | Nexus |
|---|
| exécution, vérification, acceptation | Les trois issues distinctes d’une tâche : quelqu’un a fait le travail ; des contrôles indépendants ont réussi ; l’espace de travail courant a été accepté. Chacune peut être en attente, réussie, échouée ou ambiguë sans impliquer la suivante. | Nexus |
|---|
| réconcilier (reconcile) | Clore une tentative incertaine par une observation d’opérateur (propriétaire arrêté, nouvel essai sûr ou non). Requis avant un nouvel essai. | Nexus |
|---|
| backend de processus, superviseur | La façon facultative d’exécuter une tâche comme commande locale ou appel Codex CLI. Le superviseur est le processus au premier plan qui l’a lancée et le seul qui peut envoyer un signal à son processus enfant. | Nexus |
|---|
Revue et recette#
Termes de revue et de recette| Terme | Sens | Pour en savoir plus |
|---|
| périmètre de revue (scope) | La liste scellée et hachée des fichiers qu’une revue doit couvrir, avec une raison nommée pour chaque fichier écarté. Écrite par review scope. | Revue et recette |
|---|
| constat (finding), ancrage (anchor) | Un constat est un problème rapporté avec le code qu’il cite. L’ancrage localise cette citation dans le fichier (located, ambiguous ou unlocated) ; un numéro de ligne donné par un modèle n’est jamais cru. | Revue et recette |
|---|
| couverture (coverage) | coverage.json : pour chaque fichier sélectionné, completed, failed ou waived avec une raison. Le verdict en découle. | Revue et recette |
|---|
| porte (gate) | Une commande dont le code de sortie est un verdict : review gate (0 clean, 1 findings, 2 incomplete), uat gate (0 passed, 1 failed, 2 awaiting, 3 stale), assurance verify. | Revue et recette |
|---|
| effort | --effort low|medium|high : le nombre de passes de revue (1, 2 ou 3) et si chaque constat est contesté par une étape de réfutation (pas à low). Que le relecteur planifie d’abord sa lecture dépend de la taille du changement, pas de l’effort. | Revue et recette |
|---|
| règle de revue | Une consigne Markdown liée à des motifs de chemin ; huit sont livrées avec BMAD+, Shield en ajoute six de conformité et un projet ajoute les siennes dans _bmad/review-rules.yaml. | Revue et recette |
|---|
| recette (recipe) | Une page autonome qu’une personne joue pas à pas pour confirmer une livraison à l’écran. La commande est bmad-plus uat (alias recette). | Revue et recette |
|---|
| témoin (witness) | Ce sur quoi repose une recette (un enregistrement, un fichier, un état), déclaré avec la requête en lecture seule qui prouve son état. | Revue et recette |
|---|
| résultat (run), tri (triage) | Un résultat (run) est l’ensemble des réponses d’un testeur en JSON. Le tri classe chaque échec en product, recipe, data ou undecided, avec une décision. | Revue et recette |
|---|
human-observed | L’étiquette de la preuve de recette : une personne l’a vu. La porte établit que le résultat est complet, à jour et trié, pas que le testeur a regardé au bon endroit. | Revue et recette |
|---|
Mémoire et packs spécialisés#
Termes de mémoire et de packs| Terme | Sens | Pour en savoir plus |
|---|
| cerveau (brain) | Un dossier de mémoire partagée hors d’un projet : le cerveau global ~/.bmad-plus/brain/, un _brain/ de portefeuille, ou le dossier de mémoire de Claude. Un projet s’y relie ; il n’est jamais copié. | Mémoire |
|---|
| passation (handoff) | Une note datée dans .agents/memory/sessions/ qui résume ce qui a été fait, décidé et laissé, pour qu’une session à froid puisse reprendre. | Mémoire |
|---|
| garde-fous G1 à G4 | Quatre règles de conduite dans les instructions de chaque agent : réfléchir avant de coder, simplicité d’abord, changements chirurgicaux, exécution guidée par l’objectif. | Mémoire |
|---|
| Atelier, design read, réglages (dials) | Atelier est l’agent de design. Le design read est son intake. Les réglages (variance, motion, density, de 1 à 10) règlent le design ; un réglage laissé ouvert est déduit de la surface et noté comme déduit. | Le pack Design |
|---|
| porte de base légale (Phase moins 1) | La règle OSINT selon laquelle une opération sur une personne nommée exige d’abord un but, une base légale, une conservation et une voie d’effacement consignés. Sans eux, l’agent refuse. | Confiance et propriété |
|---|
| niveau de confiance (A à D) | La note de Shadow pour un fait : A trois sources ou plus, B deux, C une, D non vérifié. | Le pack OSINT |
|---|
| dossier d’assurance, registre (ledger) | L’outillage de preuves de Shield : des affirmations, chacune appuyée par un contrôle exécuté ; un registre chaîné par hash runs.jsonl consigne les exécutions. Une affirmation est supported ou unsupported ; passed, failed, stale et missing sont les statuts d’un contrôle. | Le pack Shield |
|---|
| contrôles (controls) | Des références de conformité écrites FRAMEWORK:ID, comme ISO27001:A.8.5 ou GDPR:Art.32. Un contrôle inconnu ou mal saisi est refusé. | Le pack Shield |
|---|
Mots d’état affichés par les outils#
Mots d’état et leur sens| Mot | Affiché par | Sens |
|---|
ready / not ready | intake plan | Chaque indispensable est répondu ou inconnu avec son risque / un indispensable reste ouvert (sortie 2). |
|---|
needs-approval | swarm init | L’exécution dépasse le budget et n’a pas été approuvée (sortie 2) ; aucun brief n’a été écrit. |
|---|
missing / invalid | swarm check | Pas de fichier de réponse pour une unité / un fichier de réponse qui échoue à la validation, avec les raisons. |
|---|
incomplete / findings / clean | review gate | Preuves manquantes ou revue arrêtée (2) / constats ouverts dans un périmètre couvert (1) / aucun dans un périmètre couvert (0). |
|---|
passed / failed / awaiting / stale | uat gate | Résultat terminé, à jour et trié (0) / échoué (1) / pas de résultat terminé (2) / le résultat répondait à une autre révision (3). |
|---|
not started / running / completed | nexus summary | L’état d’exécution d’une tâche ; verification et acceptance sont affichés séparément comme pending, passed, failed ou accepted. |
|---|
unknown / off / notify / auto | update-check, update-policy | Dernière version non établie (hors ligne, périmée) / recherches arrêtées / informer seulement / appliquer dans une plage explicite. |
|---|
ok / warning / error | doctor | Sain / un fichier modifié ou non possédé, signalé / un fichier requis manquant ou illisible (sortie 1). |
|---|