BMad Method

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 1 sur 15. La plupart des assistants de code IA échouent au bout du troisième jour parce qu'ils oublient pourquoi ils ont écrit le code le premier jour. Tu te retrouves avec un tas de scripts isolés qui ne s'emboîtent pas. Pour résoudre ça, tu n'as pas besoin d'un meilleur prompt, tu as besoin de Context Engineering et des quatre phases. Une erreur courante, c'est de traiter la méthode BMad comme un simple générateur de code. Ce n'est pas le cas. C'est un pipeline agile de Context Engineering. Si tu demandes juste à un agent IA de coder une feature, il va deviner les limites. BMad empêche ça en construisant et en verrouillant progressivement le contexte à travers quatre phases distinctes. L'agent ne perd jamais le fil, parce que chaque phase fournit des règles strictes et documentées à la suivante. Prends l'exemple de la création d'une application SaaS. Si tu sautes directement au code, l'IA pourrait choisir une base de données qui ne respecte pas tes contraintes de résidence des données. Le Context Engineering empêche ça. Le pipeline commence par la phase d'analyse. Ici, l'IA joue le rôle de Business Analyst. Elle traite tes idées brutes et produit un Product Requirements Document. Cette phase verrouille les contraintes principales. Elle capture les personas utilisateurs, les règles de conformité et les workflows principaux. Le document qui en résulte devient la fondation pour tout le reste. Ensuite, c'est la phase de planification. L'agent passe dans le rôle de Product Owner. Il prend le Product Requirements Document et le découpe en Epics et en User Stories. Les exigences abstraites se transforment en éléments distincts et actionnables. Le contexte se resserre. L'IA ne pense plus au produit dans son ensemble, mais juste à des unités livrables spécifiques, associées à une timeline claire. C'est là que ça devient intéressant. La troisième phase, c'est le Solutioning. L'IA prend le rôle d'Architecte. Elle regarde les User Stories de la phase de planification et les contraintes de la phase d'analyse pour créer le design technique. Elle décide des modèles de données, des endpoints d'API et de la structure des dossiers. Pour ton application SaaS, les contraintes métier définies dans la phase un disent exactement à l'Architecte de la phase trois quelles sont les limites. Ça garantit que l'architecture choisie correspond vraiment aux règles métier d'origine. Enfin, on arrive à la phase d'implémentation. Maintenant, l'IA prend le rôle de Développeur. L'agent Développeur n'a pas besoin de deviner l'architecture ou de se poser des questions sur la logique métier. Il reçoit le blueprint technique exact de l'Architecte. Il écrit le code pour accomplir une User Story spécifique, en suivant les modèles de données et les chemins de fichiers précis définis à l'étape précédente. Cette chaîne de contexte, c'est tout l'intérêt. L'information redescend à travers une documentation persistante. L'output d'une phase devient la limite stricte en input de la suivante. L'agent Développeur réussit parce que l'agent Architecte a préparé le terrain, et l'Architecte a réussi parce que le Business Analyst a cartographié le territoire. Tu fais du Context Engineering à chaque niveau pour que l'IA se concentre entièrement sur l'exécution. Le trait caractéristique d'un workflow IA résilient, ce n'est pas la vitesse à laquelle il génère du texte, mais la rigueur avec laquelle il impose des limites à travers les différentes étapes de réflexion. Si tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour aujourd'hui. Merci d'avoir écouté, et continue de coder !

Salut, c'est Alex de DEV STORIES DOT EU. BMad Method, épisode 2 sur 15. Tu penses peut-être qu'adopter un nouveau framework de développement d'IA demande de mémoriser une énorme séquence de commandes spécifiques et des phases de workflow rigides. Détrompe-toi. Tu n'as pas besoin de mémoriser la moindre séquence de commandes dans ce framework, parce que le système inspecte physiquement ton dossier local et te dit exactement quoi taper ensuite. C'est le processus d'Intelligent Guide et d'installation. Pour commencer, une seule étape suffit. Dans ton terminal, tu lances la commande de l'exécuteur de package npx bmad-method install. Cette commande initialise le workspace et prépare la structure de ton repository. Elle fait ça en créant deux répertoires spécifiques dans ton dossier root. Le premier répertoire est underscore bmad. Ce dossier est le cerveau de ton framework local. Il contient les skills de base, les définitions de prompts et les templates contextuels que l'IA utilise pour faire son travail. Le deuxième répertoire est underscore bmad tiret output. Il sert de dossier de destination dédié. Chaque fois que le framework génère de nouveaux assets, que ce soit des documents de spécifications produit, des spécifications de features ou du code à proprement parler, ils sont déposés dans ce dossier d'output, isolés en toute sécurité de ton code source existant. Voici le point essentiel. Une fois que ces dossiers existent, les développeurs font souvent une erreur classique. Ils s'imaginent qu'ils doivent ouvrir la documentation officielle, étudier les différentes phases du framework et mémoriser les commandes exactes du terminal pour passer d'une phase à l'autre. Ils ont peur de sauter une étape par accident ou de lancer une commande dans le désordre. Tu n'as absolument pas besoin de faire ça. Le framework est auto-documenté au runtime grâce à un skill intégré qui s'appelle bmad-help. Bmad-help est un guide actif qui élimine la charge cognitive liée à la navigation dans la méthodologie. Ce n'est pas un manuel statique. Quand tu l'invoques, le skill regarde activement l'état actuel de ton workspace. Il vérifie ce qu'il y a actuellement dans tes dossiers pour déterminer exactement où tu en es dans le cycle de développement. Prenons un scénario concret. Tu viens de terminer la commande d'installation. Ton workspace est vide, à l'exception des nouveaux dossiers de configuration. Tu as une idée de produit logiciel, mais aucune idée de la commande à taper ensuite. Tu as juste à lancer la CLI et à taper bmad-help suivi de ta question en langage naturel. Par exemple, tu tapes bmad-help j'ai une idée de SaaS, par où je commence ? Le skill traite ta question, se rend compte qu'il n'y a pas encore de documents de planification dans ton dossier d'output, et te dit exactement quoi faire. Il te répond avec la commande spécifique que tu dois lancer pour initier la première phase. Il ne te donne pas une liste générique de toutes les commandes disponibles. Il te donne l'unique instruction précise pour ton contexte immédiat. Au fur et à mesure que tu progresses dans la méthodologie, en créant tes documents et ton code, bmad-help s'adapte. Si tu finis de générer ton architecture et que tu demandes quoi faire ensuite, il voit les fichiers d'architecture et te prescrit la commande pour la phase appropriée suivante. Le framework inspecte physiquement ta progression et guide dynamiquement ta prochaine action. Tu n'as jamais à deviner si tu es prêt à écrire du code ou si tu dois d'abord affiner tes requirements, parce que l'installation locale lit constamment ton environnement pour te garder sur la bonne voie. Je voudrais prendre un instant pour te remercier de ton écoute, ça nous aide beaucoup. Passe une excellente journée !

Salut, c'est Alex de DEV STORIES DOT EU. BMad Method, épisode 3 sur 15. Si tu demandes dix idées à un large language model, tu obtiens généralement dix idées parfaitement dans la moyenne, et fondamentalement ennuyeuses. Le système est conçu pour prédire le mot suivant le plus probable, ce qui veut dire qu'il gravite vers le banal. Pour obtenir des résultats vraiment innovants, tu dois forcer l'IA à agir comme un coach qui extrait les concepts de toi. C'est exactement ce que fait le workflow Forging Ideas with AI Brainstorming. La plupart des gens associent le brainstorming avec l'IA au zero-shot prompting. Tu tapes une demande d'idées dans une chat box, et tu reçois une liste générique en retour. Cette approche échoue parce qu'elle traite l'IA comme un oracle. Le coach de brainstorming de la BMad Method fonctionne sur le principe inverse. C'est un framework de facilitation guidé et multi-turn, où l'IA ne génère pas du tout les idées de base. À la place, elle apporte une friction cognitive structurée pour te forcer à penser de manière latérale. Le workflow repose fortement sur deux mécanismes spécifiques : les protocoles anti-biais et le domain shifting. Quand tu entres une idée initiale, le protocole anti-biais empêche l'IA d'être simplement d'accord avec toi. Si tu proposes une solution standard à un problème, l'IA est programmée pour la challenger. Elle pourrait te demander ce qui se passe si ta solution échoue complètement, ou comment un concurrent pourrait exploiter les failles évidentes de ta logique. Le domain shifting va encore plus loin en te forçant à voir ton problème à travers le prisme d'une industrie complètement différente. Prends un scénario concret où tu veux explorer des moyens d'améliorer l'onboarding des développeurs. Une IA standard te donnerait une liste sur la rédaction d'une meilleure documentation et l'assignation de mentors. Le coach de brainstorming BMad, en revanche, pourrait lancer un exercice sur la technique SCAMPER. SCAMPER est un framework qui te pousse à Substituer, Combiner, Adapter, Modifier, Proposer un autre usage, Éliminer ou Renverser les éléments d'un processus. Voici l'idée clé. L'IA ne va pas parcourir tout l'acronyme d'un coup et te balancer un mur de texte. Elle gère le rythme étape par étape. Elle te demande comment tu pourrais éliminer complètement la phase de lecture de la documentation de l'onboarding. Tu donnes une réponse basée sur ton expertise métier. Ensuite, l'IA te prompte pour combiner l'onboarding avec une tâche d'ingénierie sans aucun rapport, comme la réponse aux incidents en live. Tu réponds à nouveau. L'IA maintient le framework stable pendant que tu fournis la véritable idée. Tu commences le workflow en définissant ton problem space brut. L'IA répond avec une contrainte spécifique ou une question ciblée. Tu réponds. L'IA traite ta réponse, applique sa vérification anti-biais, puis te challenge ou fait un domain shift. Cette boucle multi-turn continue jusqu'à ce que tu aies épuisé les réponses évidentes et que tu commences à produire des concepts vraiment nouveaux. L'IA agit comme un facilitateur infatigable qui refuse de te laisser te contenter de la première chose qui te vient à l'esprit. La valeur d'une IA dans les premières phases du product design n'est pas sa capacité à inventer des choses de zéro, mais sa patience infinie pour appliquer une friction cognitive structurée à ta propre expertise. C'est tout pour cet épisode. Merci d'avoir écouté, et keep building !

Salut, ici Alex de DEV STORIES DOT EU. BMad Method, épisode 4 sur 15. Amazon est connu pour écrire la press release avant de builder le produit. Et si une IA challengeait cette press release sans relâche avant même de te laisser toucher à la codebase ? Choisir le bon format de document dès le départ détermine si tu buildes un outil dont les gens ont vraiment besoin, ou si tu perds des mois sur un truc dont personne ne veut. La BMad Method gère cette divergence via deux outputs de phase d'analyse distincts : le PRFAQ Gauntlet et le Product Brief. Les utilisateurs ont souvent du mal à choisir le bon format. La règle est simple. Si tu as déjà de fortes convictions sur ce que tu buildes et que tu as juste besoin d'aligner l'équipe, utilise le Product Brief. Si tu dois déterminer si le produit mérite même d'exister, utilise le PRFAQ. Le Product Brief est un processus de discovery collaboratif et en douceur. Vois ça comme une conversation guidée. Toi et l'IA travaillez ensemble pour définir le problem space, les utilisateurs cibles, les features principales et les metrics de succès. L'IA agit comme un copilote bienveillant. Elle prend tes concepts de base, les structure logiquement, et pose poliment des questions pour remplir les détails manquants. C'est le chemin de moindre résistance. Tu l'utilises quand la direction est claire et que tu as simplement besoin d'un document professionnel et organisé pour obtenir une validation ou passer au design technique. Le PRFAQ, qui signifie Press Release and Frequently Asked Questions, est un mécanisme complètement différent. C'est un stress test rigoureux, orienté customer-first. Il te force à faire du working backwards à partir d'un jour de lancement imaginaire. Tu commences par écrire une press release concise qui annonce le produit fini à ton public cible. À ce stade, l'IA abandonne son persona de copilote utile et devient un stakeholder sceptique. Elle lit ta press release et génère un gauntlet de questions brutales et inquisitrices. Imagine un scénario où tu veux builder un nouvel outil de deploy interne. Tu écris une press release qui se vante que les deploys prendront désormais un seul clic au lieu de dix. Dans un Product Brief, l'IA pourrait simplement te demander de lister les plateformes supportées. Dans le PRFAQ Gauntlet, l'IA te demandera comment tu comptes gérer les rollbacks automatisés quand ce simple clic déploiera un bug critique. Elle exigera de savoir pourquoi l'équipe infra devrait adopter cet outil plutôt que leurs scripts existants et battle-tested. Tu dois répondre à ces questions de manière satisfaisante. Si tes réponses sont vagues, l'IA te challenge. Tu es forcé de défendre la proposition de valeur, l'usabilité et la faisabilité technique avant même de dépenser du vrai temps d'engineering. Voici l'idée clé. Le Product Brief se concentre sur ce qu'est le produit, tandis que le PRFAQ se concentre sur pourquoi le client devrait s'en soucier et si ton plan d'exécution est réaliste. Le Brief construit un consensus. Le PRFAQ détruit les hypothèses fragiles. Tu déploies le PRFAQ quand une idée est coûteuse, controversée ou très ambiguë. Au final, survivre au PRFAQ Gauntlet prouve que ton concept peut résister à l'épreuve du monde réel, agissant comme une défense absolue contre le fait de builder des features que personne n'a vraiment demandées. C'est tout pour cet épisode. Merci de ton écoute, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 5 sur 15. Le moyen le plus rapide de construire le mauvais système, c'est de laisser une IA halluciner tes requirements à partir d'un prompt trop vague. Tu dois restreindre l'IA à des limites exactes avant même que du code ne soit écrit. Verrouiller le PRD est le processus qui construit ces limites. On confond souvent la planification de projet avec la conception technique. Les gens pensent que planifier implique de choisir une base de données ou de cartographier des microservices. C'est faux. La planification concerne entièrement la business logic. Elle ne dicte aucune exécution technique. La phase de planification se concentre exclusivement sur le Quoi et le Pourquoi. Le Comment appartient à une phase totalement différente. Dans la méthode BMad, ça se passe dans la Phase Deux. L'acteur responsable est l'agent product manager, John. John prend les outputs de la phase une, plus précisément ton PRFAQ approuvé et tes documents de brainstorming, et il les consomme. Tu déclenches ce processus en utilisant une commande appelée bmad tiret create tiret prd. John prend la vision du PRFAQ et la traduit dans un fichier texte rigide nommé PRD point md. Ce document sert de source de vérité absolue pour le reste du projet. Pour faire ça, John décompose les requirements en deux catégories strictes. Ce sont les Functional Requirements, ou FRs, et les Non-Functional Requirements, ou NFRs. Les Functional Requirements définissent exactement ce que le système doit faire. Les Non-Functional Requirements définissent les contraintes opérationnelles du système, comme les seuils de performance, les règles de conformité ou la disponibilité. Prends un scénario concret. Tu construis un module de facturation SaaS. Tu fournis ton PRFAQ approuvé à l'agent PM. John produit des Functional Requirements stipulant que le module doit permettre aux utilisateurs d'upgrader leur abonnement, et qu'il doit automatiquement downgrader les utilisateurs si un paiement échoue trois fois. Ensuite, John produit des Non-Functional Requirements stipulant que toutes les mises à jour du statut de paiement doivent se refléter dans le dashboard utilisateur en moins de deux secondes. Voici le point clé. Remarque ce qui manque dans ces requirements. John ne mentionne pas Stripe, il ne mentionne pas PostgreSQL, et il ne conçoit pas de payload d'API. Si ton PRD mentionne une technologie de base de données spécifique, le processus a échoué. Le PRD verrouille uniquement les attentes business. Une fois le PRD verrouillé, la Phase Deux passe au workflow de design UX. Cette étape prend la business logic brute et modélise l'interaction humaine. Si un Functional Requirement dit qu'un utilisateur doit upgrader un abonnement, le workflow de design UX dicte la séquence exacte d'écrans, de boutons et de messages d'erreur que l'utilisateur va rencontrer. Tout comme le PRD, ce workflow UX ne fait aucun choix de framework frontend. Il se fiche de savoir si tu utilises finalement React ou Vue. Il s'intéresse uniquement au parcours utilisateur étape par étape. En forçant l'agent PM à générer un PRD et un flow UX stricts et agnostiques en termes de technologie, tu crées un point d'ancrage. Les Large Language Models dérivent naturellement avec le temps. Plus tard dans le projet, tes agents d'ingénierie seront forcés de vérifier leurs solutions techniques par rapport à ces FRs et NFRs exacts. Si une feature n'est pas dans le PRD, les agents ne la construiront pas. Le PRD n'est pas un simple document de suggestions, c'est une limite rigide pour tes agents IA qui isole complètement tes besoins business fondamentaux de l'implémentation technique finale. Je voudrais prendre un moment pour te remercier de ton écoute, ça nous aide beaucoup. Passe une excellente journée !

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 6 sur 15. Si tu confies à deux agents IA le développement de deux features différentes sans document d'architecture partagé, ils vont inévitablement déclarer la guerre au code de l'autre. Ils feront des choix techniques contradictoires qui vont casser ton application. Le mécanisme pour arrêter ça, c'est la Phase 3 Solutioning, en se concentrant spécifiquement sur la prévention des conflits entre agents grâce à l'architecture. Les humains qui bossent sur un projet logiciel se parlent. Ils partagent leurs hypothèses autour d'un café ou par messages sur un chat. Les agents IA qui tournent en parallèle n'ont pas de conscience partagée. Ils opèrent dans des context windows complètement isolées. Donne à l'Agent A la tâche d'implémenter un dashboard utilisateur, et il pourrait décider qu'une API REST et Redux sont les meilleurs choix. Donne à l'Agent B la tâche de builder une page de settings utilisateur, et il pourrait décider de son côté de partir sur GraphQL et Zustand. Quand ces deux features essaient de merge sur la main branch, tu te retrouves face à un problème d'intégration massif. Les deux agents ont fait exactement ce que tu as demandé, mais leurs optimisations isolées ont créé un chaos systémique. Les développeurs veulent souvent zapper la documentation d'architecture formelle parce que ça ressemble à de la lourdeur corporate. Si tu bidouilles un petit script isolé, c'est acceptable. La méthode BMad inclut un Quick Flow spécifiquement pour les petites tâches, qui bypasse délibérément cette phase. Mais pour les projets complexes, zapper la phase d'architecture garantit un drift des agents. Tu ne peux pas compter sur le comportement par défaut des large language models pour s'aligner par accident sur la même stack technique à travers différentes sessions. Pour forcer l'alignement technique, la méthode utilise un workflow spécifique appelé bmad create architecture. Tu exécutes ce workflow avant même qu'une seule ligne de code applicatif ne soit écrite. Il analyse les requirements de ton projet et génère des Architecture Decision Records. Les Architecture Decision Records sont des fichiers texte légers et structurés. Ils capturent les choix techniques définitifs pour le projet. Un record dicte la librairie de state management. Un autre spécifie le pattern exact pour le data fetching. Un troisième définit le testing framework. Ils établissent les règles dures et inflexibles du système. Voici l'idée clé. En software engineering traditionnel, un architecture decision record est principalement un log historique pour aider les nouveaux développeurs humains à comprendre les choix passés. Dans un système d'IA multi-agents, c'est un mécanisme de contrôle actif. Les large language models n'ont aucune mémoire de ce qu'un autre modèle a décidé, à moins que tu n'injectes explicitement cette information dans leur prompt context. Quand tu run le workflow d'architecture, les documents qui en résultent sont sauvegardés directement dans le repository de ton projet. Plus tard, quand tu déploies l'Agent A pour builder le dashboard et l'Agent B pour builder les settings, le système fournit exactement ces mêmes decision records aux deux agents avant qu'ils ne commencent à écrire du code. Les fichiers d'architecture agissent comme la ground truth absolue. L'Agent A lit le record qui dicte Redux et REST, et build en conséquence. L'Agent B lit exactement le même record, et build aussi avec Redux et REST. Les frontières architecturales forcent les modèles indépendants à agir comme une équipe cohésive. En retirant le fardeau du choix pendant la phase d'implémentation de la feature, tu réduis drastiquement les hallucinations et tu préviens les dépendances conflictuelles. Les documents d'architecture dans un workflow IA ne sont pas juste des notes passives pour les humains ; ce sont des contraintes programmables qui forcent des agents non déterministes à builder un système déterministe. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à builder !

Salut, ici Alex de DEV STORIES DOT EU. Méthode BMad, épisode 7 sur 15. Les agents d'IA suivent par défaut les bonnes pratiques génériques, ce qui veut dire qu'ils écrivent du code qui ressemble à une réponse Stack Overflow moyenne, pas à ta codebase. Si tu veux qu'ils codent exactement comme ton équipe d'ingénieurs seniors, tu dois imposer tes propres règles. C'est exactement ce que fait la Project Context Constitution. À la base, c'est un fichier nommé project-context.md. Tu le places à la racine de ton repository. Vois ça comme le document de référence ultime pour n'importe quelle IA qui interagit avec ton projet. Quand un agent lit ton repository, il charge ce fichier en premier pour comprendre les limites non négociables de ton architecture. Tu peux créer ce fichier manuellement, ou tu peux générer un point de départ en lançant la commande bmad-generate-project-context dans ton terminal. Dans tous les cas, le document doit contenir deux sections spécifiques. Ce sont la Tech Stack, et les Critical Rules. La section Tech Stack est simple, mais elle demande de la précision. Tu ne te contentes pas de lister React ou Node. Tu spécifies les versions exactes, le paradigme de routing, et les librairies de styling. Si tu utilises Next.js avec l'App Router et Tailwind, dis-le exactement comme ça. L'IA utilise ça pour filtrer ses vastes données d'entraînement et se concentrer sur la syntaxe spécifique que ton projet requiert. Maintenant, la deuxième partie, c'est la section des Critical Rules. Fais bien attention à cette partie. Une erreur très courante chez les devs, c'est de remplir cette section avec des conseils génériques comme écrire du clean code ou utiliser les principes DRY. Ne fais pas ça. L'IA connaît déjà le clean code générique. Tu dois écrire les patterns spécifiques à ton projet, ceux qui ne sont pas évidents et que l'agent ne pourrait jamais deviner tout seul. C'est là que tu imposes des lois architecturales strictes. Par exemple, tu écris une règle qui impose le strict mode de TypeScript pour chaque nouveau fichier. Tu indiques à l'agent que tous les tests d'intégration doivent utiliser Mock Service Worker. Plus important encore, tu peux interdire des comportements. Si ton projet a un singleton de client API custom, tu écris explicitement une règle qui dit de ne jamais utiliser le fetch natif ou Axios directement, mais de toujours importer le client API custom depuis le dossier des network utilities. Quand l'IA génère une nouvelle feature, elle croise son output avec ces règles. Parce que le project context se trouve tout en haut de la hiérarchie du prompt, ces instructions prennent le pas sur les tendances de base de l'IA. Si un agent essaie d'écrire un fetch API direct, la Project Context Constitution le force à réécrire cette logique en utilisant ton wrapper custom avant même de sortir le code. Le but de ce fichier n'est pas d'apprendre à l'IA comment programmer, mais de lui apprendre comment programmer ici, dans ce repository spécifique. Si tu aimes ces épisodes et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. Je voudrais prendre un instant pour te remercier de ton écoute — ça nous aide beaucoup. Passe une excellente journée !

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 8 sur 15. Avant que tu laisses une IA écrire des centaines de lignes de code, il y a une étape cruciale que tu dois lancer pour éviter un sprint catastrophique. Cette étape, c'est le découpage du travail et le Gate Check. À ce stade du workflow, tu as un Product Requirements Document finalisé et un design d'Architecture complet. Maintenant, il te faut des tickets. C'est là qu'intervient l'agent Project Manager. Son job, c'est d'exécuter le process de création des Epics et des User Stories. L'agent PM lit le document de spécifications, mais il n'opère pas dans le vide. Il croise ces besoins métier avec les contraintes définies dans ta documentation d'Architecture. L'agent PM traduit les features de haut niveau en Epics. Ensuite, il découpe ces Epics en User Stories spécifiques et actionnables. Il rédige les critères d'acceptation et le contexte technique pour chaque tâche. En se référant aux documents d'Architecture, le PM s'assure que les modèles de données et les interactions de composants requis par la story existent vraiment dans le plan technique. Ça garantit que chaque ticket sert un vrai besoin métier tout en respectant strictement les limites du system design. L'output de cette étape, c'est un backlog bien rempli. Voici le point clé. Une fois que ce backlog existe, la tentation est énorme de commencer immédiatement à générer du code. On saute souvent l'étape suivante par pure impatience. On veut voir un logiciel qui tourne, alors on pousse les nouveaux tickets directement en développement. Ne fais pas ça. Sauter le readiness check, c'est comme ça que tu finis par cramer des tokens API qui coûtent cher pour du code qui ne peut pas être intégré. C'est pour ça que l'agent Architect revient pour effectuer la phase de check implementation readiness. C'est ton ultime filet de sécurité. Il agit comme un Gate Check strict avant que la programmation ne commence. L'Architect lit chaque Epic et User Story générée par le PM et les valide directement par rapport à l'Architecture. L'Architect cherche les prérequis techniques manquants, les contradictions architecturales ou les hypothèses implicites. Il vérifie que chaque structure de données mentionnée dans une story a un database schema correspondant. Il vérifie que les endpoints de service nécessaires sont bien définis. Prends un scénario spécifique. Tu lances le Gate Check, et l'Architect flag une Epic pour une nouvelle feature de notification utilisateur. Le ticket suppose l'utilisation d'une API de messagerie tierce spécifique. Cependant, l'Architect fait remarquer que cette intégration n'a jamais été discutée ou approuvée dans les Architecture Decision Records. Le Gate Check stoppe le process immédiatement. Tu viens de sauver des heures de temps de développement perdu à essayer de builder une feature sur une dépendance non approuvée ou non documentée. Cette collaboration entre les besoins métier et la réalité technique est le cœur de cette phase. L'agent PM définit le travail en fonction de ce que l'utilisateur demande. L'agent Architect vérifie le travail en fonction de ce que le système peut réellement supporter. Tu ne vas de l'avant que quand l'Architect valide, prouvant que le backlog est complètement implémentable. Un product requirement parfait est totalement inutile si l'architecture système sous-jacente ne peut pas le supporter, et ce Gate Check est la seule preuve objective que tes tickets sont vraiment prêts à être développés. C'est tout pour celui-ci. Merci de ton écoute, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. BMad Method, épisode 9 sur 15. Tu ne peux pas juste dire à une IA de builder une application. Si tu demandes à un modèle de langage d'implémenter une feature complète ou une Epic d'un coup, tu vas te retrouver avec une logique bancale, des fichiers manquants et un code complètement emmêlé. Pour obtenir un output production-grade d'une IA, tu dois imposer exactement la même discipline que celle que tu attends d'une équipe d'ingénieurs ultra performante. Aujourd'hui, on regarde le Build Cycle et le Sprint Tracking, qui est la boucle mécanique et disciplinée pour exécuter la phase quatre de l'implémentation. La plus grosse erreur que font les devs avec les outils d'IA, c'est d'en demander trop d'un coup. Le Build Cycle repose entièrement sur une exécution stricte, une story à la fois. Tu trackes le state, tu prends une seule story, tu l'exécutes, tu la valides, et tu mets à jour ton state. Ce process nécessite des personas distincts qui gèrent des parties spécifiques du pipeline, pour s'assurer qu'aucun contexte n'est perdu et que le scope n'explose pas. Le cycle commence par le sprint planning. Tu lances le prompt bmad sprint planning, qui génère un fichier appelé sprint status yaml. Ce fichier est ta source de vérité absolue. Il liste explicitement chaque story de ton sprint actuel et marque son statut comme pending, in progress, ou done. Ce document garde l'IA bien ancrée. Il empêche le modèle de faire des hallucinations sur l'avancement ou d'oublier des dépendances, parce que l'IA doit constamment lire ce fichier pour comprendre le state actuel du projet. Une fois que ton sprint est planifié, tu lances la boucle d'exécution. D'abord, tu fais intervenir le persona Scrum Master, Bob, en utilisant le prompt bmad create story. Tu dis à Bob de regarder le fichier sprint status yaml et de prendre le premier item en pending. Bob n'écrit aucun code applicatif. À la place, il génère un fichier markdown ultra focus, dédié exclusivement à cette seule user story. Ce document détaille les critères d'acceptation spécifiques, les contraintes techniques et les scénarios de test requis pour terminer la tâche. Ensuite, tu passes ce fichier de story isolé au persona Developer, Amelia. Tu utilises le prompt bmad dev story pour lancer cette étape. Amelia lit le fichier de la story, analyse la codebase actuelle, et implémente la logique. Comme son contexte est artificiellement réduit aux seules instructions de Bob et aux fichiers pertinents de l'application, elle ne va pas réécrire par accident des modules qui n'ont rien à voir, ni dériver en dehors du scope de la tâche immédiate. Une fois qu'Amelia a écrit le code, la story n'est pas encore done. Tu invoques le prompt bmad code review. Ça agit comme une quality gate automatisée. Le process de review vérifie le code d'Amelia par rapport aux critères d'acceptation stricts définis dans le fichier de story de Bob. Il fait remonter les edge cases manquants, les failles de logique ou les incohérences de formatage. Tu corriges tous les problèmes trouvés pendant cette review. C'est seulement quand le code passe que tu mets à jour le fichier sprint status yaml, en passant manuellement la story de in progress à completed. Ensuite, tu refais la boucle vers Bob pour récupérer le prochain item en pending. Voici l'idée clé. La puissance de cette boucle ne réside pas dans la génération de code en elle-même, mais dans la stricte separation of concerns qui force l'IA à planifier, exécuter et faire la review comme des étapes distinctes et isolées. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 10 sur 15. Parfois, le process agile complet est un peu overkill pour un fix localisé. Tu as un ticket de bug Jira un peu brouillon, et tu veux juste qu'il soit corrigé et reviewé sans vérifier manuellement chaque étape. Voici comment passer de ce ticket brut à une pull request reviewée en un seul run autonome en utilisant le Quick Dev Track pour les changements à blast radius zéro. On voit souvent le Quick Dev comme un simple prompt de code générique où tu balances un ticket à un large language model en croisant les doigts. Ce n'est pas le cas. Le Quick Dev isole explicitement la clarification de l'intention par rapport à l'exécution. Ça donne au système une limite stricte sur laquelle s'appuyer, au lieu de laisser la définition du problème déborder directement sur l'étape de génération de code. Le track agile standard repose à fond sur des checkpoints stricts. Tu fais une pause, tu vérifies le plan, tu vérifies les tests, et tu vérifies l'implémentation. Le Quick Dev supprime ces checkpoints. Il fait plus confiance au modèle et garde ton attention humaine pour les moments à fort impact. Tu n'utilises ce track que pour des changements à blast radius zéro. Mécaniquement, ça veut dire que les modifications doivent être isolées sur un seul composant ou une seule fonction. Le changement ne peut pas altérer les interfaces publiques, modifier les schémas de base de données, ou réécrire des fonctions utilitaires partagées utilisées par d'autres domaines. Si un changement touche au state management principal, il doit passer sur le track standard. Prends le scénario où tu passes un lien vers un ticket de bug Jira fragmenté dans le tool bmad-quick-dev. La première chose que le système exécute, c'est la compression d'intention. Il lit les commentaires éparpillés, les étapes de reproduction, et les plaintes des utilisateurs. Il force le modèle à résoudre les contradictions avant de toucher au moindre code. Si le ticket a des instructions contradictoires, l'étape de compression les synthétise en un seul but définitif. Cet output est en plain text, et définit exactement ce que le fix implique et, surtout, quelles sont les limites du fix. Voici l'idée clé. Parce que l'intention est maintenant compressée et isolée, la phase d'exécution autonome a une spécification stricte à suivre. Le système écrit le fix, génère ou met à jour les tests localisés, et lance une self-review par rapport à cette intention compressée initiale. Il boucle sur ces étapes en continu. Tu t'éloignes pendant qu'il bosse, et tu reviens sur une pull request terminée. Quick Dev est rapide, mais quand un run autonome échoue, tu dois diagnostiquer les couches d'échec avec précision. Tu regardes où le process a planté. Si le code final résout un problème complètement différent, l'échec s'est produit au niveau de la couche de compression d'intention. Le ticket Jira était probablement trop ambigu, ce qui a poussé le modèle à halluciner l'objectif. Tu corriges ça en réécrivant l'input initial. Si l'intention est bonne mais que les nouveaux tests échouent ou que le build plante, l'échec se situe dans la couche d'exécution. Tu corriges les échecs d'exécution en poussant le modèle à retry le bloc de logique spécifique. Si la couche d'exécution échoue deux fois de suite, le problème n'est plus le prompt. Le blast radius du changement était simplement plus grand que ce que tu pensais au départ, et tu dois repasser sur le track standard avec ses checkpoints. L'autonomie ne fonctionne que quand la limite de la tâche est plus petite que la context window du modèle qui la résout. C'est tout pour cet épisode. Merci de m'avoir écouté, et continue à coder !

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 11 sur 15. La plupart des frameworks d'IA partent du principe que tu démarres d'un dossier complètement vide. Ils veulent générer le scaffolding, dicter l'architecture et contrôler tout le process dès le premier jour. Mais quand tu lâches un agent IA dans un énorme monolithe Rails de cinq ans avec des conventions de nommage non documentées, cette approche de la page blanche casse tout. L'onboarding de codebases existantes, c'est comme ça que tu fais marcher BMad avec ce que tu as déjà. Une erreur fréquente des devs, c'est de penser que BMad est strictement réservé au développement greenfield. C'est faux. BMad ne force pas une réécriture et n'impose pas de structure externe. Il est conçu pour s'adapter, en respectant et en découvrant ton architecture existante pour s'intégrer proprement. Cependant, ingérer un repository existant nécessite un workflow spécifique pour éviter que l'IA n'adopte ta dette technique. La toute première étape, c'est de nettoyer les artefacts. Les modèles d'IA sont essentiellement des moteurs de pattern-matching avancés. Si tu les pointes vers un repository rempli de blocs de code commentés, d'appels d'API deprecated et de nommage de fichiers incohérent, l'agent va supposer que ce sont les standards acceptés. Avant d'introduire l'agent, tu dois supprimer le dead code, appliquer tes règles de linting et t'assurer que ta test suite passe vraiment. Tu définis le standard de base. Plus l'état d'entrée est propre, mieux l'agent s'alignera sur tes vraies intentions. Une fois le repository propre, tu le map avec une commande appelée bmad-generate-project-context. C'est là que l'adaptation se fait. Plutôt que de taper manuellement des pages de documentation sur la structure de ton application, tu lances cet outil pour scanner tes patterns legacy. Repense à ce monolithe Rails de cinq ans. Le générateur de contexte lit l'arborescence des fichiers, parse les abstractions et déduit tes règles non documentées. Il détermine si ton équipe préfère les fat models ou les service objects. Il analyse ton dossier de tests pour voir comment tu mock les appels à la base de données. Il prend toutes ces déductions et les écrit dans un document de contexte centralisé. Ce fichier devient le prompt de base pour l'IA. Quand tu demandes à l'agent de développer une nouvelle feature, il lit d'abord ce contexte. Il comprend l'architecture existante et génère du code qui donne l'impression d'avoir été écrit par un ingénieur senior de ton équipe. Une fois le contexte généré, tu choisis comment appliquer les mises à jour en utilisant soit Quick Dev, soit la Full Method. Ton choix dépend entièrement de la complexité de la tâche. Si tu corriges un bug localisé ou que tu ajoutes un simple query parameter à un endpoint existant, utilise Quick Dev. L'agent lit ton fichier de contexte, applique le patch ciblé, le vérifie avec tes tests locaux et s'arrête. C'est une opération rapide, avec un faible overhead. Maintenant, la deuxième partie gère les mises à jour complexes. Si tu as besoin de construire un tout nouveau module de facturation dans ce monolithe, tu passes à la Full Method. L'agent va utiliser le fichier de contexte pour rédiger d'abord un design document complet. Il décrit comment le nouveau module va interagir avec tes composants existants. Il écrit des failing tests qui correspondent à ton style de test legacy, implémente la business logic, et itère jusqu'à ce que les tests passent. Le framework adapte sa rigueur en fonction de ce que la tâche demande. Voici le point clé. Le succès d'un agent IA dans un repository legacy dépend entièrement de la qualité des patterns qu'il détecte, ce qui veut dire qu'un nettoyage initial rigoureux et un fichier de contexte précis sont les seules choses qui séparent l'ajout fluide d'une feature et le chaos architectural. Je voudrais prendre un moment pour te remercier de ton écoute, ça nous aide beaucoup. Passe une super journée !

Salut, c'est Alex de DEV STORIES DOT EU. BMad Method, épisode 12 sur 15. Tu ouvres ton terminal, tu tapes une commande pour formater ton code, et tu obtiens une erreur complètement générique. Tu essaies d'utiliser une commande interne d'agent, mais l'agent ne tourne même pas encore. Il y a deux façons distinctes de commander tes agents IA, et les confondre, c'est le point de friction le plus courant dans le système. Aujourd'hui, on parle de la commande des agents : les Skills contre les Triggers. La première catégorie, ce sont les Skills. Vois les Skills comme tes points d'entrée globaux. C'est ce que tu tapes dans le terminal de ton IDE ou en ligne de commande pour lancer une action from scratch. Quand tu tapes bmad-help ou que tu lances un script spécifique de lancement d'agent depuis ton IDE, tu utilises un Skill. Ça boot l'environnement. Ça charge le contexte nécessaire. Ça met l'agent en ligne. Les Skills se situent en dehors de la conversation avec l'agent. Ce sont les mécanismes qui démarrent le moteur. Ce qui nous amène au piège classique. Une fois que le moteur tourne et que tu discutes avec un agent, les règles changent. Tu arrêtes d'utiliser les Skills et tu commences à utiliser les Triggers. Un Trigger, c'est un code court tapé directement dans une session de chat active pour commander un agent qui est déjà à l'écoute. Si tu tapes un Trigger de menu d'agent dans ton terminal standard, le système n'a aucune idée de ce que tu veux dire. Si tu essaies de lancer un Skill d'IDE depuis le chat d'un agent, ça plante. La frontière est absolue. Les Skills démarrent la session. Les Triggers contrôlent la session active. Une fois que tu es dans le chat, les Triggers existent en deux versions : les Workflow Triggers et les Conversational Triggers. Les Workflow Triggers lancent des séquences rigides et prédéfinies. Tu tapes le Trigger, l'agent exécute un processus spécifique en plusieurs étapes, étape par étape, il te livre l'output, et la séquence se termine. Les Conversational Triggers sont beaucoup plus fluides. Ils permettent un task-switching dynamique sans casser le persona de l'agent. Tu restes dans le chat, mais tu pivotes le focus actif. Prends un scénario concret. Tu as besoin d'une nouvelle documentation. Tu commences par utiliser un Skill d'IDE pour lancer Paige, l'agent Technical Writer. Le Skill démarre Paige, et elle te demande ce dont tu as besoin. Elle est maintenant active. Maintenant, au lieu d'écrire un énorme prompt pour expliquer que tu as besoin d'un type de document spécifique formaté d'une façon bien précise, tu tapes simplement le Conversational Trigger W D dans le prompt du chat actif. Ça veut dire Write Docs. Paige bascule immédiatement dans son mode de rédaction de documentation prédéfini. Elle te demande tes notes brutes, elle les traite, et elle génère le texte. Tu lis le texte et tu te rends compte que tu as besoin d'un diagramme d'architecture pour l'accompagner. Tu ne fermes pas le chat. Tu ne lances pas un nouveau Skill depuis le terminal. Tu tapes juste un autre Conversational Trigger, M G, qui veut dire Mermaid Graph. Paige pivote instantanément. Elle reste dans son personnage de Technical Writer, elle garde le contexte du document qu'elle vient d'écrire, et elle génère le code du diagramme Mermaid qui correspond. Tu routes dynamiquement ses capacités à la volée sans jamais perdre le contexte. Voici l'idée clé. La vraie puissance de ce système double, ce n'est pas juste d'avoir des choses plus courtes à taper, mais de maintenir un contexte persistant et intelligent tout en switchant instantanément le mode de fonctionnement interne d'un agent. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à build !

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 13 sur 15. Tes code reviews IA sont probablement beaucoup trop gentilles. Quand tu demandes simplement à un modèle de chercher des bugs, il te donne des suggestions polies et fait des vérifications de syntaxe génériques. Pour trouver des failles catastrophiques, tu as besoin de moteurs de diagnostic spécialisés et opinionated. Cet épisode parle exactement de ça : la review adversariale et la chasse aux edge cases. On traite souvent la code review IA comme une seule passe générique. On balance un diff à un modèle et on espère qu'il va tout capter. Ça marche rarement bien. Un prompt générique manque d'un modèle mental spécifique, ce qui donne des retours superficiels. La méthodologie BMad résout ça en utilisant des personas spécialisés et très ciblés. On va regarder deux outils de review distincts qui fonctionnent avec des méthodologies complètement différentes. D'abord, prenons le reviewer adversarial. Cet outil est guidé par son attitude et il est hyper sceptique. Il ne fait confiance ni à ton code, ni à ton infrastructure, ni à tes utilisateurs. Il part du principe que ton implémentation est fondamentalement cassée et cherche activement des moyens de l'exploiter. Il ignore complètement les choix de style, le nommage des variables ou les petites optimisations de performance. À la place, il traque exclusivement les failles de business logic, les escalades de privilèges et les hypothèses de confiance brisées. Le reviewer adversarial regarde les périmètres de ton API et se demande comment un acteur malveillant pourrait contourner le flow prévu. Il lit ton code avec un profond cynisme, en traitant chaque input comme un vecteur d'attaque potentiel et chaque data boundary comme une faiblesse. Ensuite, on a le chasseur d'edge cases. Cet outil fonctionne avec la personnalité exactement opposée. Il est mathématiquement froid, dénué de contexte et entièrement mécanique. Il s'en fiche des utilisateurs malveillants ou des intentions business. À la place, il fait du path-tracing strict. Il construit un control flow graph mental de ton code et suit chaque branche jusqu'à sa conclusion logique. Le chasseur d'edge cases se concentre purement sur les mutations d'état, les boundary conditions et les types de données. Il cherche les chemins d'exécution obscurs qui causent des silent failures, des fuites de mémoire ou des unhandled exceptions. Pour voir la différence, applique les deux outils à un seul bout de code, comme un diff d'authentification complexe. Tu passes d'abord ce code au reviewer adversarial. Comme il fonctionne au cynisme, il ignore la syntaxe mécanique et repère une contrainte de business logic manquante. Il remarque que même si le token d'authentification est bien validé, le système fait implicitement confiance au rôle utilisateur embarqué dans ce token sans vérifier la base de données en live. Le reviewer adversarial flag ça comme une vulnérabilité de confiance critique. Maintenant, tu passes exactement le même diff d'authentification au chasseur d'edge cases. Cet outil ignore complètement la logique de confiance du token. À la place, via une dérivation de chemin mécanique, il traque le cycle de vie de chaque variable. Il trouve une fonction de validation profondément imbriquée qui manque d'un type check explicite. Il pointe du doigt une type coercion implicite non gérée. Si le payload en input contient un objet null au lieu d'une string à cet index précis, l'application va throw une unhandled exception et crasher. Voici l'idée clé. Tu n'utilises pas ces outils pour choper des fautes de frappe. Tu les utilises pour forcer deux frameworks analytiques distincts sur ta codebase. L'un attaque tes hypothèses sur la confiance du système et le comportement humain. L'autre attaque tes hypothèses sur les chemins d'exécution et les états des données. En séparant l'attaquant cynique du path-tracer mécanique, tu arrêtes de te reposer sur de la recherche de bugs générique et tu commences à exposer des vulnérabilités structurelles profondes avant même qu'elles n'atteignent la production. Merci de m'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 14 sur 15. Si tu donnes un document de cinquante pages directement à un large language model, il va presque immédiatement souffrir de context blindness. Il va zapper des détails au milieu du texte, halluciner des faits, et dégrader sa propre capacité de raisonnement. Pour corriger ça, tu as besoin d'une astuce de compression sans perte. Aujourd'hui, on parle de la gestion du contexte : la distillation et le sharding. Beaucoup de développeurs pensent que la distillation, c'est juste faire un résumé. C'est faux. Le résumé supprime volontairement des données pour donner un aperçu rapide à un humain. La distillation est un processus de compression sans perte et vérifiable. Voici l'idée clé. L'outil distillator prend du texte humain verbeux, supprime les transitions, les adjectifs et les mots de remplissage, et le convertit en un format à puces ultra dense. Ce format est conçu strictement pour être lu par une machine. Tu conserves absolument tous les faits, mais tu réduis drastiquement le nombre de tokens. Prends cet énorme livre blanc technique de cinquante pages. Si tu le passes dans l'outil distillator, tu peux obtenir un ratio de compression d'environ 3,2 pour 1. La taille globale du payload chute de plus des deux tiers, et pourtant le modèle garde accès à chaque spécification technique et décision d'architecture. L'IA lit les données brutes plus vite et traite la logique avec plus de précision, sans se noyer dans des paragraphes formatés pour les humains. Ça règle le problème de la densité du texte, mais le volume global peut encore être trop gros pour tenir proprement dans le contexte d'un seul prompt. C'est là que l'outil shard document entre en jeu. Le sharding découpe mécaniquement ton livre blanc distillé en petits fichiers texte indépendants, en se basant sur des limites logiques comme des chapitres ou des sections distinctes. Tu lances la commande shard, tu la pointes vers ton gros document, et elle te sort une séquence numérotée de fichiers légers. Au lieu de forcer l'IA à garder tout le livre blanc dans sa mémoire de travail, tu as maintenant des morceaux modulaires. Une fois que tu as vingt fichiers de shards qui traînent dans un répertoire, le système a besoin d'un moyen de les parcourir. Tu gères ça avec l'outil index documents. Tu pointes la commande index vers le dossier qui contient tes nouveaux shards. L'outil scanne le répertoire et génère un unique fichier master index. Ce fichier master sert de table de routage, en listant chaque shard avec une brève description de ce qu'il contient. En pratique, tu donnes d'abord cet index léger au language model. Le modèle lit la table, détermine quel chapitre spécifique contient les informations requises pour répondre à un prompt, puis demande uniquement ce shard spécifique. Le raisonnement reste affûté parce que la context window reste entièrement concentrée sur les données pertinentes. La chose la plus utile à retenir ici, c'est qu'une énorme context window n'est pas une excuse pour balancer des fichiers bruts dans un prompt. Structurer tes inputs via une distillation mécanique et des shards indexés force le modèle à lire systématiquement au lieu de scanner à l'aveugle. Si tu trouves ces épisodes utiles et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour aujourd'hui. Merci pour ton écoute, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Méthode BMad, épisode 15 sur 15. Ne demande jamais à un modèle de langage de juste améliorer quelque chose. Les prompts vagues produisent des révisions paresseuses et génériques. Si tu veux des améliorations structurelles, tu dois forcer le modèle dans un framework de raisonnement rigide, ou encore mieux, créer trois personas d'IA différents et les regarder débattre des failles. C'est exactement le domaine de l'Advanced Elicitation et du Party Mode. Un piège classique quand tu affines des outputs, comme un Product Requirements Document qui vient d'être généré, c'est de prompter le modèle pour qu'il revoie et améliore son propre travail. Les modèles de langage sont conçus pour être utiles et conciliants. Quand tu demandes une amélioration générale, le modèle va généralement modifier quelques adjectifs, restructurer une phrase et te la renvoyer. Il ne va pas réécrire la logique de base. L'Advanced Elicitation résout ça en appliquant des modèles mentaux formels et reconnus à l'output de l'IA. Tu arrêtes de demander un feedback général. À la place, tu donnes l'instruction au modèle d'exécuter un framework cognitif spécifique. Prends l'analyse pre-mortem. Tu fournis ton document de spécifications fraîchement généré au modèle. Tu lui dis de partir du principe que le projet a été buildé, lancé, et que c'est un échec absolu et catastrophique. Le modèle doit ensuite travailler à rebours pour diagnostiquer exactement ce qui a causé l'échec, en se basant uniquement sur le document actuel. Parce que tu as contraint le prompt à un état d'échec spécifique, le modèle contourne ses garde-fous de politesse et traque agressivement les failles logiques. Un autre framework puissant, c'est l'Inversion. Plutôt que de demander comment sécuriser une migration de base de données, tu demandes au modèle de lister les étapes exactes requises pour garantir une perte de données maximale pendant la migration. Les frameworks de raisonnement nommés donnent des résultats nettement supérieurs parce qu'ils forcent le modèle à sortir de ses chemins de génération de texte par défaut, hautement probables, pour l'amener vers des voies analytiques très spécifiques. Une fois que tu as identifié ces échecs garantis, tu dois concevoir le fix. Tu pourrais demander à un seul persona de résoudre le problème, mais les problèmes d'architecture complexes nécessitent de la tension. C'est ce qui nous amène au Party Mode. L'outil Party Mode orchestre une discussion de groupe multi-agents. Tu n'interagis plus avec un seul assistant. Tu configures une salle virtuelle remplie de personas spécifiques et spécialisés, tu leur donnes le problème, et tu prends du recul pour les laisser débattre. Voici comment la logique s'articule. Tu lances l'outil Party Mode et tu définis tes participants. Tu pourrais instancier un Solutions Architect senior, un Security Engineer paranoïaque, et un développeur frontend pragmatique. Tu leur passes les vulnérabilités découvertes pendant ton analyse pre-mortem. L'outil gère ensuite la boucle de conversation de manière autonome. L'Architect propose un fix robuste et complexe. L'outil passe cet output au Security Engineer, qui attaque la proposition pour trouver des vecteurs d'exploit potentiels. L'outil passe ensuite le contexte au développeur, qui se plaint de la complexité d'implémentation et suggère une approche plus simple. Ils itèrent sur ces arguments, se challengeant mutuellement sans ton intervention, jusqu'à ce qu'ils atteignent un consensus ou une limite de tours définie. Tu peux observer le débat et extraire la solution finalisée et battle-tested à partir de la transcription. Cette approche te fait passer du rôle de rédacteur de prompts à celui de directeur de moteurs de raisonnement. Tu utilises l'Advanced Elicitation pour casser systématiquement tes propres idées, et le Party Mode pour concevoir la reconstruction via une friction synthétique. Le changement le plus précieux quand tu travailles avec des modèles de langage, c'est de réaliser qu'un désaccord orchestré produit toujours une meilleure architecture technique qu'une conformité immédiate et polie. Comme c'est le dernier épisode de la série, on t'encourage vivement à lire la documentation officielle de BMad, à essayer d'orchestrer ces débats hands-on, ou à visiter devstories dot eu pour suggérer des sujets pour notre prochaine série. Je voudrais prendre un moment pour te remercier d'avoir écouté — ça nous aide beaucoup. Passe une super journée !