# Pack Dev Studio : six personas et 38 workflows

> Dev Studio couvre le cycle de vie logiciel avec six personas et 38 workflows nommés, du brief produit à la revue de code. Installation, catalogue par phase, huit exemples, CLI studio, limites.

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

Documentation BMAD+ › [Packs](https://bmad-plus.rochetta.fr/fr/docs/packs/) › Pack Dev Studio : six personas et 38 workflows

Dev Studio vous donne une équipe logicielle complète sous forme de procédures écrites. Six personas, chacune avec un rôle, exécutent 38 workflows nommés répartis en cinq phases : analyse, planification, architecture, implémentation et utilitaires. Vous nommez la persona ou le workflow, et votre outil de codage IA lit les instructions et les exécute avec ses propres outils. C’est le pack à choisir quand vous voulez une procédure précise et reproductible (valider un PRD, écrire une architecture, enquêter sur une défaillance) plutôt qu’une conversation libre.

<a id="when-to-use"></a>
## Quand l’utiliser

- Vous voulez une procédure nommée, avec une entrée définie et un résultat attendu documenté, exécutée de la même façon à chaque fois.
- Vous utilisez déjà Core et voulez des rôles plus fins : par exemple une UX designer dédiée (Rachel) ou une rédactrice technique (Huldah).
- Une correction ciblée n’exige pas tout le pipeline : l’orchestrateur choisit le plus petit workflow qui produit le résultat demandé.

<a id="installed"></a>
## Ce qui est installé

Dev Studio est un pack empaqueté dans `.agents/skills/pack-dev-studio/`, plus la compétence de dispatch `dev-studio` dans `.agents/skills/dev-studio/`. Le pack contient l’orchestrateur `dev-studio-orchestrator.md`, le `shared/catalog.json` lisible par machine (personas, workflows, alias, types d’entrée, ressources requises), le guide d’exécution `shared/execution.md`, un README et `categories/` avec un fichier Markdown par persona et par workflow. Chaque workflow répond à au moins trois noms : `<id>`, `bmad-<id>` et `bmad-plus-<id>`, si bien que `bmad-plus-validate-prd` et `validate-prd` mènent à la même procédure.

<a id="personas"></a>
### Les six personas

**Personas et workflows dont chacune a la charge**

| Persona | Rôle | Prend en charge |
| --- | --- | --- |
| Miriam (מרים) | Business Analyst | `product-brief`, `prfaq`, `market-research`, `domain-research`, `technical-research`, `party-mode`, `brainstorming`, `advanced-elicitation`, `bmad-help` |
| Huldah (חולדה) | Technical Writer | `document-project`, `distillator`, `editorial-review-prose`, `editorial-review-structure`, `shard-doc`, `index-docs` |
| Yosef (יוסף) | Product Manager | `create-prd`, `prd`, `edit-prd`, `validate-prd`, `adversarial-review` |
| Rachel (רחל) | UX Designer | `create-ux-design` |
| Bezalel (בצלאל) | System Architect | `create-architecture`, `create-epics-stories`, `implementation-readiness`, `generate-project-context`, `edge-case-hunter` |
| Oholiab (אהליאב) | Senior Engineer | `sprint-planning`, `create-story`, `dev-story`, `code-review`, `quick-dev`, `sprint-status`, `retrospective`, `correct-course`, `investigate`, `checkpoint-preview`, `qa-e2e-tests`, `customize` |

Une persona est un ensemble d’instructions, pas un processus en cours d’exécution. Choisissez le rôle dont la tâche a besoin ; Atlas, Forge, Sentinel et Nexus de Core peuvent coexister avec ces six personas.

<a id="catalogue"></a>
### Les 38 workflows par phase

La colonne Entrée dit ce dont un workflow a besoin. Un workflow de type demande attend votre demande ou un fichier. Un workflow de type artefact attend au moins un fichier existant, par exemple le PRD à valider. Un workflow de type projet attend une demande ou un fichier et travaille sur le projet. Le workflow bmad-help n’attend rien. Un contexte manquant est signalé comme besoin d’entrée, pas deviné.

<a id="phase-analysis"></a>
### Analyse (6)

**Workflows d’analyse**

| Workflow | Persona | Entrée | Résultat attendu |
| --- | --- | --- | --- |
| `product-brief` | Miriam | demande | Problème produit, public et premier périmètre utile |
| `prfaq` | Miriam | demande | Récit de lancement proposé et questions qui le mettent à l’épreuve |
| `document-project` | Huldah | projet | Documentation fondée sur des fichiers de projet réellement inspectés |
| `market-research` | Miriam | demande | Analyse sourcée du marché et des alternatives |
| `domain-research` | Miriam | demande | Concepts du domaine, contraintes et lacunes de preuves |
| `technical-research` | Miriam | demande | Options de faisabilité et prochaine vérification concrète |

<a id="phase-planning"></a>
### Planification (5)

**Workflows de planification**

| Workflow | Persona | Entrée | Résultat attendu |
| --- | --- | --- | --- |
| `create-prd` | Yosef | demande | Exigences testables et périmètre |
| `prd` | Yosef | demande | Choix entre création, édition et validation d’un PRD |
| `edit-prd` | Yosef | artefact | Changements d’exigences traçables |
| `validate-prd` | Yosef | artefact | Constats sur les exigences, fondés sur des preuves |
| `create-ux-design` | Rachel | demande | Parcours utilisateur, états d’interaction et contrôles d’acceptation |

<a id="phase-architecture"></a>
### Architecture (4)

**Workflows d’architecture**

| Workflow | Persona | Entrée | Résultat attendu |
| --- | --- | --- | --- |
| `create-architecture` | Bezalel | demande | Décisions techniques, frontières et compromis |
| `create-epics-stories` | Bezalel | artefact | Incréments livrables et stories implémentables |
| `implementation-readiness` | Bezalel | artefact | Écarts d’alignement et preuves de préparation |
| `generate-project-context` | Bezalel | projet | Contraintes actuelles du projet, avec leur provenance |

<a id="phase-implementation"></a>
### Implémentation (11)

**Workflows d’implémentation**

| Workflow | Persona | Entrée | Résultat attendu |
| --- | --- | --- | --- |
| `sprint-planning` | Oholiab | artefact | Travail délimité, dépendances et hypothèses de capacité |
| `create-story` | Oholiab | artefact | Une story avec contexte et critères d’acceptation |
| `dev-story` | Oholiab | artefact | Implémentation et vérification par rapport à une story |
| `code-review` | Oholiab | projet | Constats étayés ou rapport sans constat sur un périmètre précis |
| `quick-dev` | Oholiab | projet | Un changement borné avec des contrôles proportionnés |
| `sprint-status` | Oholiab | projet | Avancement et blocages appuyés sur des preuves actuelles |
| `retrospective` | Oholiab | artefact | Leçons et changements de processus actionnables |
| `correct-course` | Oholiab | projet | Une réponse argumentée à un changement important |
| `investigate` | Oholiab | projet | Hypothèses, preuves de reproduction et action suivante |
| `checkpoint-preview` | Oholiab | projet | Une explication relisible d’un changement |
| `qa-e2e-tests` | Oholiab | projet | Contrôles automatisés pertinents et preuves d’exécution réelle |

<a id="phase-utilities"></a>
### Utilitaires (12)

**Workflows utilitaires**

| Workflow | Persona | Entrée | Résultat attendu |
| --- | --- | --- | --- |
| `distillator` | Huldah | artefact | Un brief compact avec sources et omissions déclarées |
| `party-mode` | Miriam | demande | Points de vue comparés et trace de décision |
| `brainstorming` | Miriam | demande | Options distinctes et une petite expérience |
| `adversarial-review` | Yosef | artefact | Objections étayées, réfutations et questions ouvertes |
| `edge-case-hunter` | Bezalel | demande | Scénarios concrets de limites et de défaillances |
| `editorial-review-prose` | Huldah | artefact | Améliorations précises de la formulation |
| `editorial-review-structure` | Huldah | artefact | Un plan orienté lecteur et la correspondance des sections |
| `advanced-elicitation` | Miriam | demande | Incertitudes levées et exigences testables |
| `shard-doc` | Huldah | artefact | Sections liées avec contrôle de couverture de la source |
| `index-docs` | Huldah | projet | Un index des documents inspectés |
| `bmad-help` | Miriam | aucune | Les parcours pertinents et une prochaine étape justifiée |
| `customize` | Oholiab | projet | Changements de configuration vérifiés ou d’instructions explicites |

<a id="quick-start"></a>
## Démarrage rapide

1. **Installer le pack** Core est ajouté automatiquement ; le nommer aussi est sans effet. Seul Node.js 20 est nécessaire.

   ```sh
   npx bmad-plus install --packs core,dev-studio
   ```
2. **Demander à une persona d’exécuter un workflow** Nommez la persona et l’identifiant du workflow.

   ```sh
   Miriam, utilise product-brief pour définir un petit outil de tri des tickets pour notre équipe support.
   ```
3. **Facultatif : lister le catalogue depuis le terminal** La CLI liste chaque workflow avec sa persona et son type d’entrée, sans rien modifier.

   ```sh
   npx bmad-plus studio list --json
   ```

<a id="examples"></a>
## Exemples à copier

<a id="example-dev-studio-product-brief"></a>
### Miriam : définir un produit avec product-brief

À utiliser tout au début d’une idée. Type d’entrée : demande.

**Dans votre assistant IA**

```text
Miriam, utilise product-brief pour définir une application de listes de contrôle d’inspection pour nos techniciens de terrain. Ils travaillent souvent en sous-sol sans réseau : dis ce que cela implique pour le premier périmètre.
```

**Ce que vous devriez obtenir** Un rapport avec le problème produit, le public et le premier périmètre utile, écrit par défaut dans `_bmad-output/dev-studio/product-brief.md`.

<a id="example-dev-studio-document-project"></a>
### Huldah : documenter un projet existant

À utiliser quand un code n’a pas de documentation exploitable. Type d’entrée : projet.

**Dans votre assistant IA**

```text
Huldah, lance document-project sur ce dépôt. Documente seulement ce que tu peux fonder sur des fichiers réellement ouverts et liste ce que tu n’as pas pu vérifier.
```

**Ce que vous devriez obtenir** Une documentation fondée sur des fichiers de projet inspectés, avec les points non vérifiés signalés, enregistrée dans `_bmad-output/dev-studio/document-project.md` sauf autre dossier de sortie.

<a id="example-dev-studio-validate-prd"></a>
### Yosef : valider un PRD

À utiliser avant le début de l’architecture. Type d’entrée : artefact, le fichier est donc obligatoire.

**Dans votre assistant IA**

```text
Yosef, lance validate-prd sur docs/prd.md.
```

**Ce que vous devriez obtenir** Des constats sur les exigences fondés sur des preuves, chacun relié à ce que le fichier dit réellement, dans `_bmad-output/dev-studio/validate-prd.md`. Si le fichier manque, le workflow indique qu’il a besoin d’une entrée.

<a id="example-dev-studio-ux-design"></a>
### Rachel : concevoir les parcours d’un onboarding

À utiliser avant la couche visuelle. Si le pack Design est installé, Atelier gère les règles visuelles et d’accessibilité et les parcours de Rachel alimentent son intake.

**Dans votre assistant IA**

```text
Rachel, lance create-ux-design pour l’onboarding des nouveaux utilisateurs : de la création du compte à leur première facture enregistrée. Couvre les états vide, erreur et hors ligne.
```

**Ce que vous devriez obtenir** Des parcours utilisateur, des états d’interaction et des contrôles d’acceptation dans `_bmad-output/dev-studio/create-ux-design.md`.

<a id="example-dev-studio-architecture"></a>
### Bezalel : concevoir l’architecture

À utiliser une fois les exigences arrêtées. Le workflow procède par étapes et peut reprendre à partir d’un rapport antérieur.

**Dans votre assistant IA**

```text
Bezalel, conçois l’architecture de l’application de prise de rendez-vous décrite dans docs/prd.md. Consigne chaque décision avec ses alternatives et ses compromis.
```

**Ce que vous devriez obtenir** Des décisions techniques, des frontières et des compromis, consignés dans `_bmad-output/dev-studio/create-architecture.md` avec le modèle de décision d’architecture. Enchaînez avec `create-epics-stories` et `implementation-readiness` pour vérifier la cohérence du plan.

<a id="example-dev-studio-investigate"></a>
### Oholiab : reproduire une défaillance avant de la corriger

À utiliser pour les défaillances dont la cause est floue. Type d’entrée : projet, avec la description en demande ou en fichier.

**Dans votre assistant IA**

```text
Oholiab, utilise investigate pour reproduire l’import en échec décrit dans docs/issue.md.
```

**Ce que vous devriez obtenir** Des hypothèses, des preuves de reproduction et l’action suivante, dans `_bmad-output/dev-studio/investigate.md`. Ensuite seulement un correctif a du sens, par exemple avec `quick-dev`.

<a id="example-dev-studio-prepare-cli"></a>
### Préparer un lot de contexte en lecture seule depuis le terminal

À utiliser pour voir exactement ce qu’un workflow recevra. Cela prépare, cela n’exécute pas : c’est toujours votre assistant qui travaille.

**Dans votre assistant IA**

```text
npx bmad-plus studio prepare validate-prd --input docs/prd.md --json
```

**Ce que vous devriez obtenir** Un lot en lecture seule : la configuration résolue, les textes d’instructions livrés avec leurs empreintes SHA-256, le contenu et les empreintes des fichiers d’entrée, et le chemin de rapport proposé. Les fichiers d’entrée doivent exister dans le projet et `--input` peut être répété. Si une entrée requise n’est pas fournie (pas de `--input` pour un workflow de type artefact), la commande sort avec le code 2 et le statut needs-input, tandis qu’un chemin `--input` inexistant est une erreur (code de sortie 1) ; elle n’écrit jamais le livrable, ne lance pas de tests et ne certifie pas qu’un modèle a suivi le workflow.

<a id="example-dev-studio-help"></a>
### Demander quel workflow convient

À utiliser quand vous connaissez l’objectif mais pas le nom du workflow. bmad-help n’exige aucune entrée.

**Dans votre assistant IA**

```text
Miriam, lance bmad-help : j’ai un PRD à moitié rédigé et une échéance. Quels workflows Dev Studio dois-je lancer, dans quel ordre, et lesquels puis-je sauter ?
```

**Ce que vous devriez obtenir** Les parcours pertinents et une prochaine étape justifiée. Pour un PRD à moitié rédigé, cela veut généralement dire terminer d’abord les exigences (`prd` ou `edit-prd`), puis `validate-prd`, puis `create-architecture`. Les identifiants de workflow dans la réponse sont des suggestions, pas des déclencheurs automatiques.

<a id="outputs"></a>
## Ce qu’il écrit et où

Les rapports vont par défaut dans `_bmad-output/dev-studio/<workflow-id>.md`, ajusté au dossier de sortie configuré. Les changements de code restent dans le vrai projet. Un rapport consigne le périmètre, les entrées, les décisions, le travail accompli, les contrôles, les questions ouvertes et l’action suivante. À la reprise, le workflow relit le rapport précédent et revalide les entrées qui ont changé. Un rapport n’autorise jamais à écraser vos changements ni à répéter une publication.

**Réglages lus dans _bmad/config.yaml (chaque clé a une valeur par défaut ; project_name retombe sur le nom du dossier, ici demo-app)**

```yaml
user_name: user
communication_language: English
document_output_language: English
output_folder: _bmad-output
project_name: demo-app

```

Un fichier absent est valide. Un fichier mal formé, ou un champ connu invalide, est une erreur. `project_name` vaut par défaut le nom du dossier. Votre demande actuelle et les instructions de votre hôte priment sur les préférences de langue de la configuration.

<a id="data-and-prerequisites"></a>
## Flux de données et prérequis

Node.js 20 pour l’installateur et la commande facultative `studio`. Ni Python, ni clé, ni flux propre qui quitte votre machine : `studio list` et `studio prepare` ne lisent que des fichiers locaux. Ce que votre assistant envoie à son modèle dépend de votre outil hôte. Les workflows de recherche exigent des sources accessibles pour étayer les affirmations factuelles actuelles, et le disent quand ils n’en ont pas.

<a id="limits"></a>
## Limites et pièges

> **Attention · Un rôle, pas un planificateur** L’orchestrateur est un rôle d’instructions. Il n’envoie aucune notification, ne fait aucun commit et ne publie rien de lui-même. Les agents parallèles indépendants, la navigation et l’exécution de commandes dépendent de votre hôte ; quand un seul assistant joue plusieurs points de vue, il doit le dire, et les contrôles indisponibles restent visibles. Aucun workflow ne garantit un code sans défaut ni un résumé sans perte.

> **Remarque · Pas d’interpréteur BWML** L’ancienne notation de workflow de style XML (BWML) et la personnalisation TOML n’ont ni interpréteur ni résolveur dans ce pack. Une note de migration du pack décrit le comportement de remplacement pris en charge : des procédures Markdown simples, le catalogue et `_bmad/config.yaml`.

> **Astuce · Recoupement avec Core et Design** Dev Studio recoupe Atlas, Forge, Sentinel et Nexus ; les deux peuvent coexister, choisissez donc la persona dont vous voulez le workflow. Pour les écrans, soit Rachel soit Atelier a la charge d’un écran donné, et la passation dit lequel.

> **Remarque · Provenance** Dev Studio est un pack original écrit par Laurent Rochetta : six agents spécialisés du cycle de vie logiciel et 38 workflows, rédigés comme des instructions BMAD+ originales. Les noms de personas et la lignée des workflows reconnaissent BMAD-METHOD de BMad Code, LLC (licence MIT, base v6.6.0) ; aucun runtime amont n’est embarqué.

**Voir aussi**

- [Les dix packs côte à côte](https://bmad-plus.rochetta.fr/fr/docs/packs/packs-overview/)
- [Pack Core](https://bmad-plus.rochetta.fr/fr/docs/packs/core/)
- [Pack Design (Atelier)](https://bmad-plus.rochetta.fr/fr/docs/packs/design/)
- [Référence de la commande studio](https://bmad-plus.rochetta.fr/fr/docs/reference/cli-studio/)
- [Liste des 48 agents](https://bmad-plus.rochetta.fr/fr/docs/agents/agents-roster/)

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

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