From 2d2b6b83a3857c3b37e41623732d7c8fd952003b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Emmanuel=20Ats=C3=A9?= <4688434+eatse21@users.noreply.github.com> Date: Mon, 25 May 2026 10:08:04 +0200 Subject: [PATCH] docs(fr): apply French typography and table formatting pass MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Continuation of 27002100. Systematic pass across all French documentation assisted by an automated French typography linter: - Replace regular space with NBSP (U+00A0) before colons per French typographic convention - Align table separator rows to match column widths - Fix thousands separator in install-bmad.md (5000 → 5 000) - Correct glossary example code block rendering in _STYLE_GUIDE.md --- docs/fr/_STYLE_GUIDE.md | 8 +-- docs/fr/explanation/adversarial-review.md | 4 +- docs/fr/explanation/brainstorming.md | 2 +- docs/fr/explanation/named-agents.md | 12 ++-- docs/fr/explanation/party-mode.md | 26 ++++---- .../explanation/preventing-agent-conflicts.md | 12 ++-- docs/fr/explanation/project-context.md | 2 +- docs/fr/explanation/quick-dev.md | 4 +- docs/fr/how-to/customize-bmad.md | 42 ++++++------- docs/fr/how-to/established-projects.md | 18 +++--- docs/fr/how-to/expand-bmad-for-your-org.md | 60 +++++++++---------- docs/fr/how-to/get-answers-about-bmad.md | 18 +++--- docs/fr/how-to/install-bmad.md | 40 ++++++------- docs/fr/how-to/install-custom-modules.md | 12 ++-- docs/fr/how-to/project-context.md | 12 ++-- docs/fr/how-to/upgrade-to-v6.md | 30 +++++----- docs/fr/index.md | 2 +- docs/fr/reference/agents.md | 18 +++--- docs/fr/reference/commands.md | 52 ++++++++-------- docs/fr/reference/modules.md | 32 +++++----- docs/fr/reference/testing.md | 18 +++--- docs/fr/reference/workflow-map.md | 26 ++++---- docs/fr/tutorials/getting-started.md | 30 +++++----- website/public/workflow-map-diagram-fr.html | 6 +- 24 files changed, 243 insertions(+), 243 deletions(-) diff --git a/docs/fr/_STYLE_GUIDE.md b/docs/fr/_STYLE_GUIDE.md index ec94823b2..b9fc993ae 100644 --- a/docs/fr/_STYLE_GUIDE.md +++ b/docs/fr/_STYLE_GUIDE.md @@ -50,7 +50,7 @@ Avertissements critiques uniquement — perte de données, problèmes de sécuri ## Formats de tableau standards -**Phases :** +**Phases :** ```md | Phase | Nom | Ce qui se passe | @@ -59,7 +59,7 @@ Avertissements critiques uniquement — perte de données, problèmes de sécuri | 2 | Planification | Exigences — PRD ou spécification technique *(requis)* | ``` -**Skills :** +**Skills :** ```md | Skill | Agent | Objectif | @@ -243,7 +243,7 @@ votre-projet/ 1. Titre + Accroche 2. Éléments (## pour chaque élément) - Brève description (une phrase) - - **Skills :** ou **Infos clés :** sous forme de liste simple + - **Skills :** ou **Infos clés :** sous forme de liste simple 3. Universel/Partagé (## section) (optionnel) ``` @@ -304,9 +304,9 @@ Starlight génère la navigation « Sur cette page » à droite à partir de ### Format de tableau +```md ## Nom de catégorie -```md | Terme | Définition | |--------------|------------------------------------------------------------------------------------------------------------| | **Agent** | Personnalité IA spécialisée avec une expertise spécifique qui guide les utilisateurs dans les workflows. | diff --git a/docs/fr/explanation/adversarial-review.md b/docs/fr/explanation/adversarial-review.md index fda3e7490..e5a3f0bf0 100644 --- a/docs/fr/explanation/adversarial-review.md +++ b/docs/fr/explanation/adversarial-review.md @@ -13,7 +13,7 @@ Une technique de revue où le réviseur *doit* trouver des problèmes. Pas de « Il ne s’agit pas d’être négatif. Il s’agit de forcer une analyse authentique au lieu d’un coup d’œil superficiel qui valide automatiquement ce qui a été soumis. -**La règle fondamentale :** Il doit trouver des problèmes. Zéro constatation déclenche un arrêt - réanalyse ou explique pourquoi. +**La règle fondamentale :** Il doit trouver des problèmes. Zéro constatation déclenche un arrêt - réanalyse ou explique pourquoi. ## Pourquoi Cela Fonctionne @@ -30,7 +30,7 @@ La revue contradictoire apparaît dans tous les workflows BMad - revue de code, ## Filtrage Humain Requis -Parce que l’IA est *instruite* de trouver des problèmes, elle trouvera des problèmes - même lorsqu’ils n’existent pas. Attendez-vous à des faux positifs : des détails présentés comme des problèmes, des malentendus sur l’intention, ou des préoccupations purement hallucinées[^3]. +Parce que l’IA est *instruite* de trouver des problèmes, elle trouvera des problèmes - même lorsqu’ils n’existent pas. Attendez-vous à des faux positifs : des détails présentés comme des problèmes, des malentendus sur l’intention, ou des préoccupations purement hallucinées[^3]. **C’est vous qui décidez ce qui est réel.** Examinez chaque constatation, ignorez le bruit, corrigez ce qui compte. diff --git a/docs/fr/explanation/brainstorming.md b/docs/fr/explanation/brainstorming.md index fcc4f59ae..0ef16147a 100644 --- a/docs/fr/explanation/brainstorming.md +++ b/docs/fr/explanation/brainstorming.md @@ -11,7 +11,7 @@ Libérez votre créativité grâce à une exploration guidée. Lancez `bmad-brainstorming` et vous obtenez un facilitateur créatif qui fait émerger vos idées - pas qui les génère pour vous. L’IA agit comme coach et guide, utilisant des techniques éprouvées pour créer les conditions où votre meilleure réflexion émerge. -**Idéal pour :** +**Idéal pour :** - Surmonter les blocages créatifs - Générer des idées de produits ou de fonctionnalités diff --git a/docs/fr/explanation/named-agents.md b/docs/fr/explanation/named-agents.md index 1b38222be..098da76bd 100644 --- a/docs/fr/explanation/named-agents.md +++ b/docs/fr/explanation/named-agents.md @@ -31,12 +31,12 @@ BMad embarque six agents nommés, chacun ancré à une phase de la méthode BMad | Agent | Phase | Module | |------------------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------| -| 📊 **Mary**, Analyste d’affaires | Analyse | étude de marché, brainstorming, product briefs, PRFAQs | -| 📚 **Paige**, Rédactrice technique | Analyse | documentation de projet, diagrammes, validation de docs | -| 📋 **John**, Chef de produit | Planification | création de PRD, décomposition epic/story, vérification de la préparation à l’implémentation | -| 🎨 **Sally**, Designer UX | Planification | spécifications de design UX | -| 🏗️ **Winston**, Architecte système | Solutioning | architecture technique, vérifications d’alignement | -| 💻 **Amelia**, Ingénieure senior | Implémentation | exécution de stories, quick-dev, revue de code, planification de sprint, [enquête de code](./forensic-investigation.md) | +| 📊 **Mary**, Analyste d’affaires | Analyse | étude de marché, brainstorming, product briefs, PRFAQs | +| 📚 **Paige**, Rédactrice technique | Analyse | documentation de projet, diagrammes, validation de docs | +| 📋 **John**, Chef de produit | Planification | création de PRD, décomposition epic/story, vérification de la préparation à l’implémentation | +| 🎨 **Sally**, Designer UX | Planification | spécifications de design UX | +| 🏗️ **Winston**, Architecte système | Solutioning | architecture technique, vérifications d’alignement | +| 💻 **Amelia**, Ingénieure senior | Implémentation | exécution de stories, quick-dev, revue de code, planification de sprint, [enquête de code](./forensic-investigation.md) | Chacun possède une identité codée en dur (nom, titre, domaine) et une couche personnalisable (rôle, principes, style de communication, icône, menu). Vous pouvez réécrire les principes de Mary ou ajouter des éléments de menu ; vous ne pouvez pas la renommer — c’est délibéré. La reconnaissance de marque persiste après personnalisation pour que « hey Mary » active toujours l’analyste, indépendamment de la façon dont une équipe a façonné son comportement. diff --git a/docs/fr/explanation/party-mode.md b/docs/fr/explanation/party-mode.md index 6e1083762..3b793a628 100644 --- a/docs/fr/explanation/party-mode.md +++ b/docs/fr/explanation/party-mode.md @@ -24,35 +24,35 @@ La conversation continue aussi longtemps que vous le souhaitez. Posez des questi ### Remettre en question une mauvaise architecture -**Vous :** « Ok l’équipe, notre dernier sprint a été un désastre. Le service d’authentification est tombé trois fois. Qui a cafouillé ? » +**Vous :** « Ok l’équipe, notre dernier sprint a été un désastre. Le service d’authentification est tombé trois fois. Qui a cafouillé ? » -**Architecte :** « Le design était solide - authentification distribuée avec des fallbacks appropriés. Si l’implémentation a dévié des specs... » +**Architecte :** « Le design était solide - authentification distribuée avec des fallbacks appropriés. Si l’implémentation a dévié des specs... » -**Développeur :** « J’ai suivi le document d’architecture à la lettre. Les specs ne prenaient pas en compte les race conditions lors de l’invalidation de sessions concurrentes. » +**Développeur :** « J’ai suivi le document d’architecture à la lettre. Les specs ne prenaient pas en compte les race conditions lors de l’invalidation de sessions concurrentes. » -**PM :** « Vous avez tous les deux raté le vrai problème - nous n’avons pas validé les exigences de gestion des sessions dans le PRD. C’est de ma faute de ne pas l’avoir repéré. » +**PM :** « Vous avez tous les deux raté le vrai problème - nous n’avons pas validé les exigences de gestion des sessions dans le PRD. C’est de ma faute de ne pas l’avoir repéré. » -**TEA :** « Et j’aurais dû le repérer dans les tests d’intégration. Les scénarios de test ne couvraient pas l’invalidation concurrente. » +**TEA :** « Et j’aurais dû le repérer dans les tests d’intégration. Les scénarios de test ne couvraient pas l’invalidation concurrente. » ### Brainstorming créatif -**Vous :** « Comment rendre l’onboarding magique au lieu d’ennuyeux ? » +**Vous :** « Comment rendre l’onboarding magique au lieu d’ennuyeux ? » -**Designer UX :** « Commençons par la divulgation progressive - révélons les fonctionnalités au fur et à mesure que les utilisateurs en ont besoin, pas d’un coup dans un tutoriel. » +**Designer UX :** « Commençons par la divulgation progressive - révélons les fonctionnalités au fur et à mesure que les utilisateurs en ont besoin, pas d’un coup dans un tutoriel. » -**Storyteller :** « Et si l’onboarding était une histoire ? Chaque étape révèle le parcours d’un personnage - l’utilisateur EST le héros. » +**Storyteller :** « Et si l’onboarding était une histoire ? Chaque étape révèle le parcours d’un personnage - l’utilisateur EST le héros. » -**Game Designer :** « En partant de là - et si la première « quête » consistait à résoudre un vrai problème utilisateur ? Ils apprennent en faisant quelque chose d’utile. » +**Game Designer :** « En partant de là - et si la première « quête » consistait à résoudre un vrai problème utilisateur ? Ils apprennent en faisant quelque chose d’utile. » ### Décision technique -**Vous :** « Monolithe ou microservices pour le MVP[^1] ? » +**Vous :** « Monolithe ou microservices pour le MVP[^1] ? » -**Architecte :** « Commencez en monolithe. Les microservices ajoutent une complexité dont vous n’avez pas besoin à 1 000 utilisateurs. » +**Architecte :** « Commencez en monolithe. Les microservices ajoutent une complexité dont vous n’avez pas besoin à 1 000 utilisateurs. » -**PM :** « D’accord. Le time-to-market[^2] compte plus que la scalabilité théorique. » +**PM :** « D’accord. Le time-to-market[^2] compte plus que la scalabilité théorique. » -**Développeur :** « Monolithe avec des frontières de modules claires. On pourra extraire des services plus tard si nécessaire. » +**Développeur :** « Monolithe avec des frontières de modules claires. On pourra extraire des services plus tard si nécessaire. » :::tip[Meilleures décisions] De meilleures décisions grâce à des perspectives diverses. Bienvenue dans le party mode. diff --git a/docs/fr/explanation/preventing-agent-conflicts.md b/docs/fr/explanation/preventing-agent-conflicts.md index 429ba50da..505f5c008 100644 --- a/docs/fr/explanation/preventing-agent-conflicts.md +++ b/docs/fr/explanation/preventing-agent-conflicts.md @@ -14,10 +14,10 @@ Lorsque plusieurs agents IA implémentent différentes parties d’un système, Sans architecture : - L’agent A utilise REST avec `/users/{id}` - L’agent B utilise des mutations GraphQL -- Résultat : Patterns d’API incohérents, consommateurs confus +- Résultat : Patterns d’API incohérents, consommateurs confus Avec architecture : -- L’ADR[^1] spécifie : « Utiliser GraphQL pour toute communication client-serveur » +- L’ADR[^1] spécifie : « Utiliser GraphQL pour toute communication client-serveur » - Tous les agents suivent le même pattern ### Conflits de conception de base de données @@ -25,7 +25,7 @@ Avec architecture : Sans architecture : - L’agent A utilise des noms de colonnes en snake_case - L’agent B utilise des noms de colonnes en camelCase -- Résultat : Schéma incohérent, requêtes illisibles +- Résultat : Schéma incohérent, requêtes illisibles Avec architecture : - Un document de standards spécifie les conventions de nommage @@ -36,7 +36,7 @@ Avec architecture : Sans architecture : - L’agent A utilise Redux pour l’état global - L’agent B utilise React Context -- Résultat : Multiples approches de gestion d’état, complexité +- Résultat : Multiples approches de gestion d’état, complexité Avec architecture : - L’ADR spécifie l’approche de gestion d’état @@ -56,8 +56,8 @@ Chaque choix technologique significatif est documenté avec : ### 2. Guidance spécifique aux FR/NFR[^2] L’architecture associe chaque exigence fonctionnelle à une approche technique : -- FR-001 : Gestion des utilisateurs → Mutations GraphQL -- FR-002 : Application mobile → Requêtes optimisées +- FR-001 : Gestion des utilisateurs → Mutations GraphQL +- FR-002 : Application mobile → Requêtes optimisées ### 3. Standards et conventions diff --git a/docs/fr/explanation/project-context.md b/docs/fr/explanation/project-context.md index a528218b5..f919468cf 100644 --- a/docs/fr/explanation/project-context.md +++ b/docs/fr/explanation/project-context.md @@ -20,7 +20,7 @@ Le fichier `project-context.md` résout ce problème en documentant ce que les a Chaque workflow d’implémentation charge automatiquement `project-context.md` s’il existe. Le workflow architecte le charge également pour respecter vos préférences techniques lors de la conception de l’architecture. -**Chargé par ces workflows :** +**Chargé par ces workflows :** - `bmad-create-architecture` — respecte les préférences techniques pendant la phase de solutioning - `bmad-create-story` — informe la création de stories avec les patterns du projet - `bmad-dev-story` — guide les décisions d’implémentation diff --git a/docs/fr/explanation/quick-dev.md b/docs/fr/explanation/quick-dev.md index ea1afade6..f461475ad 100644 --- a/docs/fr/explanation/quick-dev.md +++ b/docs/fr/explanation/quick-dev.md @@ -15,7 +15,7 @@ Il permet au modèle de s’exécuter plus longtemps entre les points de contrô Les interactions humaines dans la boucle sont nécessaires et coûteuses. -Les LLM actuels échouent encore de manière prévisible : ils interprètent mal l’intention, comblent les lacunes avec des suppositions assurées, dérivent vers du travail non lié, et génèrent des résultats à réviser bruyants. En même temps, l’intervention humaine constante limite la fluidité du développement. L’attention humaine est le goulot d’étranglement. +Les LLM actuels échouent encore de manière prévisible : ils interprètent mal l’intention, comblent les lacunes avec des suppositions assurées, dérivent vers du travail non lié, et génèrent des résultats à réviser bruyants. En même temps, l’intervention humaine constante limite la fluidité du développement. L’attention humaine est le goulot d’étranglement. `bmad-quick-dev` rééquilibre ce compromis. Il fait confiance au modèle pour s’exécuter sans surveillance sur de plus longues périodes, mais seulement après que le workflow ait créé une frontière suffisamment solide pour rendre cela sûr. @@ -25,7 +25,7 @@ Les LLM actuels échouent encore de manière prévisible : ils interprètent mal Le workflow commence par compresser l’interaction de la personne et du modèle à partir de la requête en un objectif cohérent. L’entrée peut commencer sous forme d’une expression grossière de l’intention, mais avant que le workflow ne s’exécute de manière autonome, elle doit devenir suffisamment petite, claire et sans contradiction pour être exécutable. -L’intention peut prendre plusieurs formes : quelques phrases, un lien vers un outil de suivi de bugs, une sortie du mode planification, du texte copié depuis une session de chat, ou même un numéro de story depuis un fichier `epics.md` de BMAD. Dans ce dernier cas, le workflow ne comprendra pas la sémantique de suivi des stories de BMAD, mais il peut quand même prendre la story elle-même et l’exécuter. +L’intention peut prendre plusieurs formes : quelques phrases, un lien vers un outil de suivi de bugs, une sortie du mode planification, du texte copié depuis une session de chat, ou même un numéro de story depuis un fichier `epics.md` de BMAD. Dans ce dernier cas, le workflow ne comprendra pas la sémantique de suivi des stories de BMAD, mais il peut quand même prendre la story elle-même et l’exécuter. Ce workflow n’élimine pas le contrôle humain. Il le déplace vers un nombre réduit d’étapes à forte valeur : diff --git a/docs/fr/how-to/customize-bmad.md b/docs/fr/how-to/customize-bmad.md index 45e8c8252..6cb2cc54d 100644 --- a/docs/fr/how-to/customize-bmad.md +++ b/docs/fr/how-to/customize-bmad.md @@ -44,12 +44,12 @@ Le dossier `_bmad/custom/` est initialement vide. Les fichiers n’apparaissent Le résolveur applique quatre règles structurelles. Les noms de champ n’ont pas de traitement particulier — le comportement est déterminé uniquement par la forme de la valeur : -| Forme | Règle | -|---|---| -| Scalaire (chaîne, entier, booléen, flottant) | L’override prévaut | -| Table | Fusion profonde (application récursive des mêmes règles) | +| Forme | Règle | +|-------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------| +| Scalaire (chaîne, entier, booléen, flottant) | L’override prévaut | +| Table | Fusion profonde (application récursive des mêmes règles) | | Tableau de tables où chaque élément partage le **même** champ identifiant (chaque élément a `code`, ou chaque élément a `id`) | Fusionner par cette clé — les clés correspondantes **remplacent sur place**, les nouvelles clés **s’ajoutent** | -| Tout autre tableau (scalaires ; tables sans identifiant ; tableaux qui mélangent `code` et `id` entre les éléments) | **Ajouter** — éléments de base en premier, puis éléments d’équipe, puis éléments utilisateur | +| Tout autre tableau (scalaires ; tables sans identifiant ; tableaux qui mélangent `code` et `id` entre les éléments) | **Ajouter** — éléments de base en premier, puis éléments d’équipe, puis éléments utilisateur | **Pas de mécanisme de suppression.** Les overrides ne peuvent pas effacer les éléments de base. Si vous devez supprimer un élément de menu par défaut, surchargez-le via son `code` avec une description ou un prompt sans effet. Si vous devez restructurer un tableau plus en profondeur, forkez le skill. @@ -86,10 +86,10 @@ _bmad/custom/ :::caution[Ne copiez PAS le `customize.toml` complet] Les fichiers d’override sont **allégés**. Incluez uniquement les champs que vous modifiez — rien d’autre. Chaque champ omis est hérité automatiquement de la couche inférieure (l’équipe hérite des valeurs par défaut, l’utilisateur de l’équipe ou des valeurs par défaut). -Copier le `customize.toml` complet dans un override est contre-productif : la prochaine mise à jour livrera de nouvelles valeurs par défaut, mais votre fichier d’override figera les anciennes valeurs. Votre configuration s’éloignera silencieusement des valeurs par défaut à chaque mise à jour. +Copier le `customize.toml` complet dans un override est contre-productif : la prochaine mise à jour livrera de nouvelles valeurs par défaut, mais votre fichier d’override figera les anciennes valeurs. Votre configuration s’éloignera silencieusement des valeurs par défaut à chaque mise à jour. ::: -**Exemple — changer l’icône et ajouter un principe :** +**Exemple — changer l’icône et ajouter un principe :** ```toml # _bmad/custom/bmad-agent-pm.toml @@ -158,7 +158,7 @@ activation_steps_append = [ **Pourquoi deux hooks ?** Le préfixe s’exécute avant la salutation pour que l’agent puisse charger le contexte dont il a besoin pour personnaliser la salutation elle-même. Le suffixe s’exécute après la salutation pour que l’utilisateur ne reste pas devant un terminal vide pendant les scans lourds. -**Personnalisation du menu (fusion par `code`).** Le menu est un tableau de tables. Chaque élément possède un champ `code` (convention BMad). Le résolveur fusionne donc par code : les codes correspondants remplacent sur place, les nouveaux codes s’ajoutent. +**Personnalisation du menu (fusion par `code`).** Le menu est un tableau de tables. Chaque élément possède un champ `code` (convention BMad). Le résolveur fusionne donc par code : les codes correspondants remplacent sur place, les nouveaux codes s’ajoutent. La syntaxe TOML pour les tableaux de tables utilise `[[agent.menu]]` pour chaque élément : @@ -182,13 +182,13 @@ Signaler tout écart et citer la section réglementaire pertinente. Chaque élément de menu possède exactement un `skill` (invoque un skill enregistré) ou `prompt` (exécute le texte directement). Les éléments non listés dans votre override conservent leurs valeurs par défaut. -**Référencer des fichiers.** Quand le texte d’un champ doit pointer vers un fichier (dans `persistent_facts`, `activation_steps_prepend`/`activation_steps_append`, ou le `prompt` d’un élément de menu), utilisez un chemin complet partant de `{project-root}`. Même si le fichier se trouve à côté de votre override dans `_bmad/custom/`, écrivez le chemin complet : `{project-root}/_bmad/custom/info.md`. L’agent résout `{project-root}` à l’exécution. +**Référencer des fichiers.** Quand le texte d’un champ doit pointer vers un fichier (dans `persistent_facts`, `activation_steps_prepend`/`activation_steps_append`, ou le `prompt` d’un élément de menu), utilisez un chemin complet partant de `{project-root}`. Même si le fichier se trouve à côté de votre override dans `_bmad/custom/`, écrivez le chemin complet : `{project-root}/_bmad/custom/info.md`. L’agent résout `{project-root}` à l’exécution. ### 4. Personnel vs Équipe -**Fichier d’équipe** (`bmad-agent-pm.toml`) : Versionné dans git. Partagé au sein de l’organisation. À utiliser pour les règles de conformité, le persona de l’entreprise, les capacités personnalisées. +**Fichier d’équipe** (`bmad-agent-pm.toml`) : Versionné dans git. Partagé au sein de l’organisation. À utiliser pour les règles de conformité, le persona de l’entreprise, les capacités personnalisées. -**Fichier personnel** (`bmad-agent-pm.user.toml`) : Automatiquement ignoré par git. À utiliser pour les ajustements de ton, les préférences de workflow personnelles et les faits privés que l’agent doit garder en tête. +**Fichier personnel** (`bmad-agent-pm.user.toml`) : Automatiquement ignoré par git. À utiliser pour les ajustements de ton, les préférences de workflow personnelles et les faits privés que l’agent doit garder en tête. ```toml # _bmad/custom/bmad-agent-pm.user.toml @@ -209,7 +209,7 @@ python3 {project-root}/_bmad/scripts/resolve_customization.py \ --key agent ``` -**Prérequis** : Python 3.11+ (les versions antérieures n’incluent pas `tomllib`). Pas de `pip install`, pas de `uv`, pas de virtualenv. Vérifiez avec `python3 --version`. Certaines plateformes (macOS sans Homebrew, Ubuntu 22.04) ont `python3` par défaut en 3.10 ou antérieur, vous devrez peut-être installer 3.11+ séparément. +**Prérequis** : Python 3.11+ (les versions antérieures n’incluent pas `tomllib`). Pas de `pip install`, pas de `uv`, pas de virtualenv. Vérifiez avec `python3 --version`. Certaines plateformes (macOS sans Homebrew, Ubuntu 22.04) ont `python3` par défaut en 3.10 ou antérieur, vous devrez peut-être installer 3.11+ séparément. `--skill` pointe vers le répertoire installé du skill (où se trouve `customize.toml`). Le nom du skill est déduit du basename du répertoire, et le script cherche automatiquement `_bmad/custom/{skill-name}.toml` et `{skill-name}.user.toml`. @@ -260,7 +260,7 @@ persistent_facts = [ on_complete = "Résumer le brief en trois points et proposer de l'envoyer par email via le skill gws-gmail-send." ``` -Les mêmes conventions de champs s’appliquent indifféremment aux agents et aux workflows : `activation_steps_prepend`/`activation_steps_append`, `persistent_facts` (avec refs `file:`) et les tables `[[…]]` de style menu avec `code`/`id` pour la fusion par clé. Le résolveur applique les mêmes quatre règles structurelles quelle que soit la clé de premier niveau. Les références dans SKILL.md suivent l’espace de noms : `{workflow.activation_steps_prepend}`, `{workflow.persistent_facts}`, `{workflow.on_complete}`. Tout champ supplémentaire qu’un workflow expose (chemins de sortie, bascules, paramètres de revue, drapeaux d’étape) suit les mêmes règles de fusion basées sur la forme. Lisez le `customize.toml` du workflow pour voir ce qui est personnalisable. +Les mêmes conventions de champs s’appliquent indifféremment aux agents et aux workflows : `activation_steps_prepend`/`activation_steps_append`, `persistent_facts` (avec refs `file:`) et les tables `[[…]]` de style menu avec `code`/`id` pour la fusion par clé. Le résolveur applique les mêmes quatre règles structurelles quelle que soit la clé de premier niveau. Les références dans SKILL.md suivent l’espace de noms : `{workflow.activation_steps_prepend}`, `{workflow.persistent_facts}`, `{workflow.on_complete}`. Tout champ supplémentaire qu’un workflow expose (chemins de sortie, bascules, paramètres de revue, drapeaux d’étape) suit les mêmes règles de fusion basées sur la forme. Lisez le `customize.toml` du workflow pour voir ce qui est personnalisable. ### Ordre d’activation @@ -277,7 +277,7 @@ Après l’étape 6, le corps du workflow commence. Utilisez `activation_steps_p ### Périmètre de cette première passe -La personnalisation est déployée de manière incrémentale. Les champs documentés ci-dessus — `activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete` — sont la **surface de base** que chaque workflow personnalisable expose, et ils resteront stables d’une version à l’autre. Ils vous donnent un contrôle à grands traits dès aujourd’hui : injecter des étapes pré/post, épingler du contexte fondamental, déclencher des actions de suivi. +La personnalisation est déployée de manière incrémentale. Les champs documentés ci-dessus — `activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete` — sont la **surface de base** que chaque workflow personnalisable expose, et ils resteront stables d’une version à l’autre. Ils vous donnent un contrôle à grands traits dès aujourd’hui : injecter des étapes pré/post, épingler du contexte fondamental, déclencher des actions de suivi. Au fil du temps, les workflows individuels exposeront des **points de personnalisation plus ciblés** adaptés à ce que le workflow fait réellement — par exemple des bascules par étape, des drapeaux d’étape, des chemins de templates de sortie ou des jalons de revue. Quand ils arriveront, ils viendront s’ajouter aux champs de base plutôt que de les remplacer, pour que les personnalisations que vous rédigez aujourd’hui continuent de fonctionner. @@ -359,12 +359,12 @@ L’override prévaut sur ce que chaque développeur a répondu lors de son inst | Besoin | Utiliser | |----------------------------------------------------------|-------------------------------------------------------------------------------| -| Ajouter des appels d’outils MCP à chaque workflow de dev | Par skill : `_bmad/custom/bmad-agent-dev.toml` `persistent_facts` | -| Ajouter un élément de menu à un agent | Par skill : `_bmad/custom/bmad-agent-{role}.toml` `[[agent.menu]]` | -| Remplacer le template de sortie d’un workflow | Par skill : `_bmad/custom/{workflow}.toml` override scalaire | -| Renommer le descripteur public d’un agent | **Centrale** : `_bmad/custom/config.toml` `[agents.]` | -| Ajouter un agent personnalisé ou fictif au registre | **Centrale** : `_bmad/custom/config.*.toml` nouvelle entrée `[agents.]` | -| Figer les paramètres d’installation pour l’équipe | **Centrale** : `_bmad/custom/config.toml` `[modules.]` ou `[core]` | +| Ajouter des appels d’outils MCP à chaque workflow de dev | Par skill : `_bmad/custom/bmad-agent-dev.toml` `persistent_facts` | +| Ajouter un élément de menu à un agent | Par skill : `_bmad/custom/bmad-agent-{role}.toml` `[[agent.menu]]` | +| Remplacer le template de sortie d’un workflow | Par skill : `_bmad/custom/{workflow}.toml` override scalaire | +| Renommer le descripteur public d’un agent | **Centrale** : `_bmad/custom/config.toml` `[agents.]` | +| Ajouter un agent personnalisé ou fictif au registre | **Centrale** : `_bmad/custom/config.*.toml` nouvelle entrée `[agents.]` | +| Figer les paramètres d’installation pour l’équipe | **Centrale** : `_bmad/custom/config.toml` `[modules.]` ou `[core]` | Utilisez les deux espaces dans le même projet selon vos besoins. @@ -377,7 +377,7 @@ Pour des recettes orientées entreprise (façonner un agent à travers tous les **La personnalisation n’apparaît pas ?** - Vérifiez que votre fichier se trouve dans `_bmad/custom/` avec le nom de skill correct -- Vérifiez la syntaxe TOML : les chaînes doivent être entre guillemets, les en-têtes de table utilisent `[section]`, les tableaux de tables utilisent `[[section]]`, et toute clé scalaire ou de tableau pour une table doit apparaître *avant* toute `[[sous-table]]` de cette table dans le fichier +- Vérifiez la syntaxe TOML : les chaînes doivent être entre guillemets, les en-têtes de table utilisent `[section]`, les tableaux de tables utilisent `[[section]]`, et toute clé scalaire ou de tableau pour une table doit apparaître *avant* toute `[[sous-table]]` de cette table dans le fichier - Pour les agents, la personnalisation se trouve sous `[agent]` — les champs écrits sous cet en-tête appartiennent à `agent` jusqu’à ce qu’un autre en-tête de table commence - Rappelez-vous que `agent.name` et `agent.title` sont en lecture seule ; les overrides n’ont aucun effet diff --git a/docs/fr/how-to/established-projects.md b/docs/fr/how-to/established-projects.md index 1423d2423..da101d1b5 100644 --- a/docs/fr/how-to/established-projects.md +++ b/docs/fr/how-to/established-projects.md @@ -15,7 +15,7 @@ Ce guide couvre le flux de travail essentiel pour l’intégration à des projet - Accès à un IDE IA (Claude Code ou Cursor) ::: -## Étape 1 : Nettoyer les artefacts de planification terminés +## Étape 1 : Nettoyer les artefacts de planification terminés Si vous avez terminé tous les epics et stories du PRD[^1] via le processus BMad, nettoyez ces fichiers. Archivez-les, supprimez-les, ou appuyez-vous sur l’historique des versions si nécessaire. Ne conservez pas ces fichiers dans : @@ -23,7 +23,7 @@ Si vous avez terminé tous les epics et stories du PRD[^1] via le processus BMad - `_bmad-output/planning-artifacts/` - `_bmad-output/implementation-artifacts/` -## Étape 2 : Créer le contexte du projet +## Étape 2 : Créer le contexte du projet :::tip[Recommandé pour les projets existants] Générez `project-context.md` pour capturer les patterns et conventions de votre base de code existante. Cela garantit que les agents IA suivent vos pratiques établies lors de l’implémentation des modifications. @@ -46,7 +46,7 @@ Vous pouvez examiner et affiner le fichier généré, ou le créer manuellement [En savoir plus sur le contexte du projet](../explanation/project-context.md) -## Étape 3 : Maintenir une documentation de projet de qualité +## Étape 3 : Maintenir une documentation de projet de qualité Votre dossier `docs/` doit contenir une documentation succincte et bien organisée qui représente fidèlement votre projet : @@ -57,9 +57,9 @@ Votre dossier `docs/` doit contenir une documentation succincte et bien organis Pour les projets complexes, envisagez d’utiliser le workflow `bmad-document-project`. Il offre des variantes d’exécution qui analyseront l’ensemble de votre projet et documenteront son état actuel réel. -## Étape 4 : Obtenir de l’aide +## Étape 4 : Obtenir de l’aide -### BMad-Help : Votre point de départ +### BMad-Help : Votre point de départ **Exécutez `bmad-help` chaque fois que vous n’êtes pas sûr de la prochaine étape.** Ce guide intelligent : @@ -79,10 +79,10 @@ BMad-Help s’exécute également **automatiquement à la fin de chaque workflow Vous avez deux options principales selon l’ampleur des modifications : -| Portée | Approche recommandée | -| ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | -| **Petites mises à jour ou ajouts** | Exécutez `bmad-quick-dev` pour clarifier l’intention, planifier, implémenter et réviser dans un seul workflow. La méthode BMad complète en quatre phases est probablement excessive. | -| **Modifications ou ajouts majeurs** | Commencez avec la méthode BMad, en appliquant autant ou aussi peu de rigueur que nécessaire. | +| Portée | Approche recommandée | +|-------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **Petites mises à jour ou ajouts** | Exécutez `bmad-quick-dev` pour clarifier l’intention, planifier, implémenter et réviser dans un seul workflow. La méthode BMad complète en quatre phases est probablement excessive. | +| **Modifications ou ajouts majeurs** | Commencez avec la méthode BMad, en appliquant autant ou aussi peu de rigueur que nécessaire. | ### Pendant la création du PRD diff --git a/docs/fr/how-to/expand-bmad-for-your-org.md b/docs/fr/how-to/expand-bmad-for-your-org.md index d83daff19..f5edf6848 100644 --- a/docs/fr/how-to/expand-bmad-for-your-org.md +++ b/docs/fr/how-to/expand-bmad-for-your-org.md @@ -28,13 +28,13 @@ Avant de choisir une recette, comprenez où votre override se situe : | **Workflow** (ex. product-brief, create-prd) | Section `[workflow]` de `_bmad/custom/{workflow-name}.toml` | S’applique uniquement à l’exécution de ce workflow | | **Configuration centrale** | `[agents.*]`, `[core]`, `[modules.*]` dans `_bmad/custom/config.toml` | Registre des agents (qui est disponible pour party-mode, retrospective, elicitation), paramètres d’installation figés pour toute l’organisation | -En règle générale : si la règle doit s’appliquer partout où un ingénieur travaille sur le développement, personnalisez l'**agent dev**. Si elle s’applique uniquement quand quelqu’un rédige un product brief, personnalisez le **workflow product-brief**. Si elle change *qui participe* (renommer un agent, ajouter une voix personnalisée, imposer un chemin d’artefact partagé), modifiez la **configuration centrale**. +En règle générale : si la règle doit s’appliquer partout où un ingénieur travaille sur le développement, personnalisez l'**agent dev**. Si elle s’applique uniquement quand quelqu’un rédige un product brief, personnalisez le **workflow product-brief**. Si elle change *qui participe* (renommer un agent, ajouter une voix personnalisée, imposer un chemin d’artefact partagé), modifiez la **configuration centrale**. -## Recette 1 : Façonner un agent à travers tous les workflows qu’il dispatche +## Recette 1 : Façonner un agent à travers tous les workflows qu’il dispatche -**Cas d’usage :** Standardiser l’utilisation des outils et les intégrations avec les systèmes externes pour que chaque workflow dispatché par un agent hérite du comportement. C’est le pattern le plus impactant. +**Cas d’usage :** Standardiser l’utilisation des outils et les intégrations avec les systèmes externes pour que chaque workflow dispatché par un agent hérite du comportement. C’est le pattern le plus impactant. -**Exemple : Amelia (agent dev) utilise toujours Context7 pour la documentation des bibliothèques, et se rabat sur Linear quand une story n’est pas trouvée dans la liste des epics.** +**Exemple : Amelia (agent dev) utilise toujours Context7 pour la documentation des bibliothèques, et se rabat sur Linear quand une story n’est pas trouvée dans la liste des epics.** ```toml # _bmad/custom/bmad-agent-dev.toml @@ -49,17 +49,17 @@ persistent_facts = [ ] ``` -**Pourquoi ça marche :** Deux phrases suffisent à reconfigurer tous les workflows de dev de l’organisation, sans duplication par workflow ni modification du code source. Chaque nouvel ingénieur qui clone le dépôt hérite automatiquement des conventions. +**Pourquoi ça marche :** Deux phrases suffisent à reconfigurer tous les workflows de dev de l’organisation, sans duplication par workflow ni modification du code source. Chaque nouvel ingénieur qui clone le dépôt hérite automatiquement des conventions. -**Fichier d’équipe vs fichier personnel :** -- `bmad-agent-dev.toml` : versionné dans git ; s’applique à toute l’équipe -- `bmad-agent-dev.user.toml` : ignoré par git ; préférences personnelles ajoutées par-dessus +**Fichier d’équipe vs fichier personnel :** +- `bmad-agent-dev.toml` : versionné dans git ; s’applique à toute l’équipe +- `bmad-agent-dev.user.toml` : ignoré par git ; préférences personnelles ajoutées par-dessus -## Recette 2 : Imposer les conventions de l’organisation dans un workflow spécifique +## Recette 2 : Imposer les conventions de l’organisation dans un workflow spécifique -**Cas d’usage :** Façonner le *contenu* de la sortie d’un workflow pour qu’il réponde aux exigences de conformité, d’audit ou des consommateurs en aval. +**Cas d’usage :** Façonner le *contenu* de la sortie d’un workflow pour qu’il réponde aux exigences de conformité, d’audit ou des consommateurs en aval. -**Exemple : chaque product brief doit inclure des champs de conformité, et l’agent connaît les conventions de publication de l’organisation.** +**Exemple : chaque product brief doit inclure des champs de conformité, et l’agent connaît les conventions de publication de l’organisation.** ```toml # _bmad/custom/bmad-product-brief.toml @@ -73,13 +73,13 @@ persistent_facts = [ ] ``` -**Ce qui se passe :** Les faits sont chargés durant l’étape 3 de l’activation du workflow. Quand l’agent rédige le brief, il connaît les champs requis et le document de conventions enterprise. La valeur par défaut livrée (`file:{project-root}/**/project-context.md`) se charge toujours, car il s’agit d’un ajout. +**Ce qui se passe :** Les faits sont chargés durant l’étape 3 de l’activation du workflow. Quand l’agent rédige le brief, il connaît les champs requis et le document de conventions enterprise. La valeur par défaut livrée (`file:{project-root}/**/project-context.md`) se charge toujours, car il s’agit d’un ajout. -## Recette 3 : Publier les livrables finis vers des systèmes externes +## Recette 3 : Publier les livrables finis vers des systèmes externes -**Cas d’usage :** Une fois le livrable produit, le publier automatiquement vers les systèmes de référence de l’entreprise (Confluence, Notion, SharePoint) et créer des tickets de suivi (Jira, Linear, Asana). +**Cas d’usage :** Une fois le livrable produit, le publier automatiquement vers les systèmes de référence de l’entreprise (Confluence, Notion, SharePoint) et créer des tickets de suivi (Jira, Linear, Asana). -**Exemple : les briefs sont automatiquement publiés vers Confluence et proposent la création facultative d’un epic Jira.** +**Exemple : les briefs sont automatiquement publiés vers Confluence et proposent la création facultative d’un epic Jira.** ```toml # _bmad/custom/bmad-product-brief.toml @@ -112,18 +112,18 @@ et demander à l'utilisateur de publier manuellement. """ ``` -**Pourquoi `on_complete` et pas `activation_steps_append` :** `on_complete` s’exécute exactement une fois, au stade terminal, après que le workflow a écrit sa sortie principale. C’est le bon moment pour publier des artefacts. `activation_steps_append` s’exécute à chaque activation, avant que le workflow ne fasse son travail. +**Pourquoi `on_complete` et pas `activation_steps_append` :** `on_complete` s’exécute exactement une fois, au stade terminal, après que le workflow a écrit sa sortie principale. C’est le bon moment pour publier des artefacts. `activation_steps_append` s’exécute à chaque activation, avant que le workflow ne fasse son travail. -**Arbitrages :** +**Arbitrages :** - **La publication Confluence est non-destructive** et s’exécute toujours à la fin - **La création d’epic Jira est visible par toute l’équipe** et déclenche un processus de planification de sprint, conditionnez-la donc à la confirmation de l’utilisateur -- **Dégradation gracieuse :** si les outils MCP échouent, passer la main à l’utilisateur plutôt que de silencieusement abandonner le livrable +- **Dégradation gracieuse :** si les outils MCP échouent, passer la main à l’utilisateur plutôt que de silencieusement abandonner le livrable -## Recette 4 : Remplacer le template de sortie par le vôtre +## Recette 4 : Remplacer le template de sortie par le vôtre -**Cas d’usage :** La structure de sortie par défaut ne correspond pas au format attendu par votre organisation, ou différentes organisations dans le même dépôt ont besoin de templates différents. +**Cas d’usage :** La structure de sortie par défaut ne correspond pas au format attendu par votre organisation, ou différentes organisations dans le même dépôt ont besoin de templates différents. -**Exemple : pointer le workflow product-brief vers un template appartenant à l’entreprise.** +**Exemple : pointer le workflow product-brief vers un template appartenant à l’entreprise.** ```toml # _bmad/custom/bmad-product-brief.toml @@ -132,16 +132,16 @@ et demander à l'utilisateur de publier manuellement. brief_template = "{project-root}/docs/enterprise/brief-template.md" ``` -**Comment ça marche :** Le `customize.toml` du workflow est fourni avec `brief_template = "resources/brief-template.md"` (chemin relatif, résolu depuis la racine du skill). Votre override pointe vers un fichier sous `{project-root}`, donc l’agent lit votre template à l’étape 4 au lieu de celui livré par défaut. +**Comment ça marche :** Le `customize.toml` du workflow est fourni avec `brief_template = "resources/brief-template.md"` (chemin relatif, résolu depuis la racine du skill). Votre override pointe vers un fichier sous `{project-root}`, donc l’agent lit votre template à l’étape 4 au lieu de celui livré par défaut. -**Conseils pour la rédaction de templates :** +**Conseils pour la rédaction de templates :** - Gardez les templates dans `{project-root}/docs/` ou `{project-root}/_bmad/custom/templates/` pour qu’ils soient versionnés avec le fichier d’override - Utilisez les mêmes conventions structurelles que le template livré (titres de sections, frontmatter) ; l’agent s’adapte à ce qu’il trouve - Pour les dépôts multi-organisations, utilisez `.user.toml` pour permettre à chaque équipe de pointer vers ses propres templates sans toucher au fichier d’équipe versionné dans git -## Recette 5 : Personnaliser le registre des agents +## Recette 5 : Personnaliser le registre des agents -**Cas d’usage :** Changer *qui sera présent dans la pièce* pour les skills basés sur le registre comme `bmad-party-mode`, `bmad-retrospective` et `bmad-advanced-elicitation`, sans modifier le code source ni forker. Voici trois variantes courantes. +**Cas d’usage :** Changer *qui sera présent dans la pièce* pour les skills basés sur le registre comme `bmad-party-mode`, `bmad-retrospective` et `bmad-advanced-elicitation`, sans modifier le code source ni forker. Voici trois variantes courantes. ### 5a. Renommer un agent BMad pour toute l’organisation @@ -197,18 +197,18 @@ document_output_language = "English" Les paramètres personnels comme `user_name`, `communication_language` ou `user_skill_level` restent dans leur propre fichier `_bmad/config.user.toml` de chaque développeur. Le fichier d’équipe ne doit pas les modifier. -**Pourquoi la configuration centrale vs le customize.toml par agent :** Les fichiers par agent façonnent la façon dont *un seul* agent se comporte quand il s’active. La configuration centrale façonne ce que les consommateurs du registre *voient* : quels agents existent, comment ils s’appellent, à quelle équipe ils appartiennent, et les paramètres d’installation partagés sur lesquels tout le dépôt s’accorde. Deux surfaces, des rôles différents. +**Pourquoi la configuration centrale vs le customize.toml par agent :** Les fichiers par agent façonnent la façon dont *un seul* agent se comporte quand il s’active. La configuration centrale façonne ce que les consommateurs du registre *voient* : quels agents existent, comment ils s’appellent, à quelle équipe ils appartiennent, et les paramètres d’installation partagés sur lesquels tout le dépôt s’accorde. Deux surfaces, des rôles différents. ## Renforcer les règles globales dans le fichier de session de votre IDE Les personnalisations BMad se chargent quand un skill est activé. Beaucoup d’outils IDE chargent aussi un fichier d’instructions global au **début de chaque session**, avant tout skill (`CLAUDE.md`, `AGENTS.md`, `.cursor/rules/`, `.github/copilot-instructions.md`, etc.). Pour les règles qui doivent s’appliquer même en dehors des skills BMad, reproduisez-y les plus critiques. -**Quand les utiliser ensemble :** +**Quand les utiliser ensemble :** - Une règle est suffisamment importante pour qu’une conversation simple (sans skill actif) doive la respecter - Vous voulez une double sécurisation parce que les défauts des données d’entraînement pourraient autrement détourner le modèle - La règle est assez concise pour être répétée sans alourdir le fichier de session -**Exemple : une ligne dans le `CLAUDE.md` du dépôt renforçant la règle de l’agent dev de la Recette 1.** +**Exemple : une ligne dans le `CLAUDE.md` du dépôt renforçant la règle de l’agent dev de la Recette 1.** ```markdown