Le développement assisté par IA a résolu un premier problème : générer du code rapidement. Mais un deuxième problème, plus fondamental, persiste : qui définit ce qu'il faut construire, et comment s'assurer que l'IA respecte cette vision ? La méthode BMAD et l'outil AWS sample-e2e-product-development-with-kiro apportent chacun une réponse à cette question, avec des approches complémentaires qui s'inscrivent pleinement dans la logique de l'AI-DLC.
BMAD : une équipe virtuelle pour piloter le cycle produit
Le problème de la dérive contextuelle
Quand vous utilisez un agent IA dans un IDE — que ce soit Cursor, Claude Code ou Kiro — chaque nouvelle session repart à zéro. L'agent ne sait plus pourquoi telle décision architecturale a été prise, quels compromis ont été acceptés, ou quels cas limites ont été identifiés. C'est ce que la communauté appelle la dérive contextuelle : un code fonctionnel qui s'éloigne progressivement de la vision produit initiale.
La méthode BMAD (Breakthrough Method of Agile AI-Driven Development) attaque ce problème frontalement. Au lieu de traiter l'IA comme un assistant généraliste, BMAD orchestre des agents spécialisés — chacun avec un rôle précis, une place définie dans le workflow, et des livrables documentés.
Les agents BMAD : des personas avec une mission
BMAD définit plus de 12 agents spécialisés, dont six rôles principaux :
| Agent | Persona | Responsabilité |
|---|---|---|
| Analyst | Mary | Brainstorming, recherche marché, brief projet |
| Product Manager | John | PRD, épics, stories, validation produit |
| Architect | Winston | Architecture système, tech stack, APIs, schémas DB |
| Developer | Amelia | Implémentation, code review, sprint planning |
| UX Designer | Sally | Specs UX, patterns d'interaction |
| Tech Writer | Paige | Documentation technique |
Chaque agent est un fichier Markdown/YAML qui encode sa persona, ses commandes et ses dépendances. L'activation suit un template structuré : chargement du contexte persistant, adoption de la persona, puis exécution de la tâche.
Quatre phases, des artefacts durables
BMAD structure le développement en quatre phases successives :
- Analyse — Brainstorming, recherche, brief produit
- Planification — PRD, spécifications UX, architecture
- Conception — Architecture détaillée, design système
- Implémentation — Développement story par story, code review, rétrospective
Le point clé : chaque phase produit des artefacts versionnés dans Git (PRD, documents d'architecture, fichiers story) qui deviennent la source de vérité du projet. Quand l'agent Developer ouvre une nouvelle session, il ne repart pas à zéro — il lit le fichier story qui contient tout le contexte nécessaire à l'implémentation.
Agent Lattice : le Design Thinking piloté par l'IA dans Kiro
Un sample AWS qui va plus loin qu'un exemple
Le repository sample-e2e-product-development-with-kiro publié par AWS Labs n'est pas un simple tutoriel. C'est un framework complet — baptisé Agent Lattice — qui orchestre un processus de Design Thinking de bout en bout, directement dans l'IDE Kiro.
Agent Lattice se compose de deux éléments :
-
Le runtime (
.al/) : un orchestrateur qui gère les rôles, workflows, gates et scripts, avec des modules pluggables pour le Design Thinking et la génération de specs Kiro - Les extensions IDE : un plugin de visualisation qui affiche la progression des phases dans une sidebar dédiée
Le workflow Design Thinking complet
L'outil guide l'utilisateur à travers les cinq phases classiques du Design Thinking, orchestrées par des skills Kiro :
-
Empathize (
/al-dt-workflow-empathize) — Interviews utilisateurs, empathy maps, personas - Define — Carte d'affinité, insights, questions "How Might We"
- Ideate — Brainstorming structuré, évaluation des concepts
- Prototype — User flows, wireframes, spécifications d'interaction
- Test — Plans de test, métriques, validation des hypothèses
À la fin du processus, un module Kiro Bridge transforme automatiquement les artefacts de Design Thinking en specs Kiro natives (requirements → design → tasks), prêtes pour l'implémentation.
L'impersonation de rôles
Un mécanisme original d'Agent Lattice : la commande /al-impersonate permet à l'IA d'adopter un rôle spécifique (designer, ingénieur, product manager, UX researcher, market researcher) pendant une phase donnée. Chaque rôle dispose de son propre fichier de steering qui cadre les réponses de l'IA selon l'expertise attendue.
L'intérêt pour la vision produit et l'AI-DLC
Combler le fossé entre intention et implémentation
L'AI-DLC, tel que formalisé par AWS, repositionne l'humain sur la direction stratégique tandis que l'IA exécute. Mais ce modèle suppose que la direction stratégique est clairement articulée et accessible à l'agent d'implémentation. C'est précisément le maillon faible de la plupart des outils actuels.
BMAD et Agent Lattice adressent ce fossé de deux manières complémentaires :
- BMAD structure la chaîne de documents (brief → PRD → architecture → stories) qui encode les décisions produit de manière durable et versionnable
- Agent Lattice structure la phase d'exploration (empathie → problème → idéation → prototype → test) qui précède la rédaction des specs
Ensemble, ils couvrent l'intégralité du spectre : de la compréhension utilisateur jusqu'au code déployé.
Le développeur comme Tech Lead, pas comme exécutant
Dans un AI-DLC structuré par ces outils, le rôle du développeur change fondamentalement. Il ne passe plus son temps à écrire du code répétitif. Il :
- Valide les personas générées par la phase Empathize
- Arbitre les décisions architecturales proposées par l'agent Architect
- Review les stories avant de lancer l'implémentation automatique
- Approuve les gates entre chaque phase du workflow
C'est un rôle de curateur et de validateur — exactement la redistribution de l'effort cognitif que promet l'AI-DLC.
Artefacts versionnés : la mémoire du projet
Le bénéfice le plus tangible de ces deux approches : le projet a une mémoire. Les PRD, les documents d'architecture, les empathy maps, les fichiers story — tout vit dans Git. Un nouveau développeur qui rejoint le projet peut comprendre non seulement ce que le logiciel fait, mais pourquoi il a été conçu ainsi. Un agent IA qui ouvre une nouvelle session peut charger le contexte complet sans que l'humain ait à tout ré-expliquer.
C'est l'antidote à la dérive contextuelle : quand les décisions sont documentées dans des artefacts structurés, l'IA peut les respecter session après session.
Les limites à connaître
Ces approches ne sont pas sans compromis :
- Overhead documentaire : le processus complet BMAD génère des dizaines d'artefacts avant la première ligne de code. Pour un fix rapide, c'est disproportionné (d'où l'existence d'un Quick Flow)
- Consommation de tokens : les allers-retours entre agents consomment significativement plus de tokens qu'un prompt direct
- Coordination manuelle : BMAD laisse au développeur la responsabilité de passer les artefacts entre agents, là où Agent Lattice automatise davantage via les skills Kiro
Ce qu'il faut retenir
La méthode BMAD et l'outil Agent Lattice d'AWS représentent une évolution majeure dans l'écosystème AI-DLC : la structuration de la phase amont. Là où la plupart des outils IA se concentrent sur la génération de code, ces frameworks s'attaquent au vrai problème — s'assurer que le code généré respecte une vision produit cohérente et documentée.
Pour une équipe qui adopte Kiro, la combinaison est naturelle : Agent Lattice pour la phase de Discovery (Design Thinking → specs), puis le workflow natif Kiro (specs → implémentation) pour la phase de Delivery. Le tout versionné dans Git, auditable, et reproductible.
Le futur du développement assisté par IA n'est pas « l'IA fait tout ». C'est « l'IA exécute un processus structuré, guidé par des artefacts que l'humain valide ». BMAD et Agent Lattice montrent à quoi ce futur ressemble concrètement.
Références :
Top comments (0)