Quand l'IA code plus vite que vous ne spécifiez, votre méthodologie doit évoluer. MADD fournit le cadre pour contrôler la dérive et forcer la convergence entre l'intention et l'implémentation.
Chaque agent a un rôle unique. Aucun ne valide son propre travail. Les paires Maker/Breaker spécialisées par domaine garantissent l'expertise.
Le Chef d'Orchestre. Coordonne les agents, détecte les domaines, gère les cycles d'itération par fraction.
L'Architecte d'Intention. Formalise le "pourquoi" et le "quoi", annote les tâches par domaine.
Le Maker. Implémentation spécialisée par domaine, guidée par les skills.
La Porte Qualité. Validation automatisée build, lint, type-check et tests entre Maker et Breaker.
Le Breaker. Vérification spécialisée par domaine. Audite sans complaisance.
Le Witness. Documente la réalité objective.
Le Conductor détecte les domaines techniques depuis les annotations de tâches et invoque des paires d'agents spécialisées. Chaque domaine a des skills Maker et Breaker dédiés.
| Aspect | Le Maker produit | Le Breaker audite |
|---|---|---|
| Base de données | Normalisation, RLS, journalisation d'audit, patterns temporels, indexation | Normalisation manquante, RLS, index, contraintes, risques de cascade |
| API | Patterns REST, validation, rate limiting, pagination, format d'erreur | Validation manquante, auth, CORS, requêtes N+1, pagination |
| Frontend | Architecture composants, gestion d'état, accessibilité | Performance, taille du bundle, accessibilité, vecteurs XSS |
| Sécurité | OIDC/JWKS, RBAC, chiffrement, mTLS, headers de sécurité | OWASP Top 10, escalade de privilèges, exposition de secrets |
| Infrastructure | Docker multi-stage, Compose, Terraform, gestion des secrets | Exécution en root, healthchecks manquants, secrets en dur, SPOF |
L'IA produit du code qui semble correct mais qui s'écarte subtilement de votre intention. Sans le savoir, vous accumulez de la dette technique invisible.
L'agent dit "c'est fait" mais a laissé des TODO, des implémentations partielles, des edge cases ignorés. Le code passe les tests mais ne résout pas le problème.
Chaque session repart de zéro. Les décisions architecturales se perdent. Les conventions s'érodent. Le projet devient un patchwork incohérent.
L'agent qui génère le code est le même qui le documente. C'est le renard qui garde le poulailler. L'auto-évaluation masque les problèmes.
L'intention n'est pas une conversation oubliée. C'est un document versionné, structuré, qui répond à "pourquoi" et "quoi" avant tout "comment".
→ Avant de générer du code, l'intention doit être formalisée et validée.
Une spécification qu'on ne peut pas vérifier automatiquement n'est pas un contrat, c'est un souhait. Chaque requirement a des critères de validation automatisables.
→ Tests, assertions, schemas : le contrat se vérifie lui-même.
Un agent qui génère du code ne peut pas être la source de vérité sur la qualité de ce code. La validation doit toujours venir d'un agent qui n'a pas participé à la production.
→ Architecture obligatoire à 6 rôles.
Ce qui a été réellement implémenté doit être documenté objectivement, indépendamment de ce que l'agent de développement déclare avoir fait.
→ Un agent Witness indépendant analyse le code et produit la vérité.
Quand le coût marginal de développement baisse, investir dans l'architecture devient rationnel. On priorise ce qui dé-risque la suite.
→ Le séquençage favorise la solidité, pas l'impression immédiate.
L'IA a des données d'entraînement obsolètes. Les skills injectent la connaissance à jour et définissent les critères de qualité entre phases.
→ Chaque transition est médiatisée par un skill explicite.
| Aspect | Scrum / Kanban / SAFe | MADD |
|---|---|---|
| Goulot d'étranglement | Temps de développement | Clarté d'intention |
| Unité de travail | Story / Ticket | Intention + Contrat |
| Estimation | Points / Jours | Obsolète (trop rapide) |
| Validation | Code review humaine | Audit par agent indépendant |
| Documentation | Souvent négligée | Rétro-spec automatique |
| Rythme | Sprints fixes (2-3 sem) | Cycles adaptatifs |
| Coordination | Cérémonies d'équipe | Contrats inter-agents |
| Mémoire projet | Dans les têtes | Rétro-spec versionnée |
MADD partage la philosophie "spécification d'abord" avec d'autres méthodologies, mais diffère dans son approche de la validation et de la mémoire.
| Aspect | BMAD | SpecKit | MADD |
|---|---|---|---|
| Philosophie | Prompts structurés | Spécifications vivantes | Contrats exécutables |
| Validation | Revue manuelle | Conformité aux specs | Audit par agent indépendant |
| Mémoire | Historique des prompts | Versionnage des specs | Rétro-spécification |
| Détection de dérive | Manuelle | Basée sur les diffs | Automatisée par le Witness |
| Séparation des agents | Optionnelle | Non imposée | Obligatoire (6 rôles) |
| Auto-validation | Autorisée | Autorisée | Interdite |
| Documentation | Écrite par le dev | Dérivée des specs | Analyse indépendante |
| Objectivité | Perspective dev | Perspective spec | Réalité du code |
Utilise 2-3 modèles différents : Gemini pour les specs, Claude pour le dev, GPT pour l'audit. Ne laisse jamais un agent valider son propre travail.
Avant chaque session de dev, écris un Intention Document : pourquoi, quoi, critères de succès. C'est ton contrat.
Passe le code produit à ton agent d'audit avec un skill de due diligence. Ne merge jamais sans audit indépendant.
Un 4ème agent (ou toi) analyse ce qui a été réellement implémenté et met à jour la documentation. C'est ta mémoire projet.
Architecte d'Intention (PM/PO), Conducteur d'Agents (dev senior), Arbitre d'Alignement (QA ou pair). Chaque rôle est responsable d'une phase.
Un repo partagé avec tous les skills : Spec Skill, Dev Skill, Audit Skill, Retro-Spec Skill. Versionnés comme du code.
La rétro-spécification est partagée et mise à jour à chaque cycle. C'est le point de départ de toute nouvelle itération.
Plus de durée fixe. Un cycle commence quand une intention est formalisée et se termine quand la rétro-spec est validée.
Chaque story devient un Intention Document avec des critères de validation exécutables. Plus de "c'est bon pour moi".
La DoD devient un skill formel que l'agent d'audit exécute. Vérifiable, reproductible, non-négociable.
Plus de "comment améliorer le process". On consolide les rétro-specs et on améliore les skills.
MADD est open source. Rejoignez la communauté et contribuez à définir le futur du développement assisté par IA.