Le Constat

Le développement assisté par IA change tout, sauf nos méthodologies.

Scrum, Kanban, SAFe ont été conçus pour gérer la rareté du temps de développement. Quand une équipe de 10 personnes mettait un an à livrer une plateforme, il fallait planifier, prioriser, coordonner.

Aujourd'hui, un développeur avec les bons outils IA livre en 2 jours ce qui prenait 12 mois.

Le temps de développement n'est plus le goulot d'étranglement.

Les nouveaux goulots sont :

  • La clarté de l'intention
  • La validation de l'alignement
  • La mémoire du système

Et les nouveaux risques sont :

  • La dérive silencieuse entre intention et implémentation
  • L'hallucination présentée comme livraison
  • Le faux alignement (TODO cachés, implémentations partielles)
  • La perte de contexte entre sessions

MADD est une méthodologie conçue pour ces nouveaux défis.

Les 6 Principes MADD

1. L'intention est un artefact de première classe

L'intention n'est pas une conversation oubliée. C'est un document versionné, structuré, qui répond à "pourquoi" et "quoi" avant tout "comment".

Ce que ça change : Avant de générer du code, l'intention doit être formalisée et validée.

2. Le contrat est exécutable

Une spécification qu'on ne peut pas vérifier automatiquement n'est pas un contrat, c'est un souhait.

Ce que ça change : Chaque requirement a des critères de validation automatisables (tests, assertions, schemas).

3. Aucun agent ne valide son propre travail

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.

Ce que ça change : Architecture obligatoire à 4 rôles minimum — Intention, Développement, Audit, Rétro-Spécification.

4. La rétro-spécification est la mémoire du système

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.

Ce que ça change : Un agent Scribe indépendant analyse le code et produit la documentation de ce qui existe vraiment.

5. Les fondations précèdent les features

Quand le coût marginal de développement baisse, investir dans l'architecture devient rationnel. On ne priorise plus par "valeur business immédiate" mais par "solidité des fondations".

Ce que ça change : Le séquençage favorise ce qui dé-risque la suite, pas ce qui impressionne le stakeholder.

6. Les skills sont des contrats de connaissance

L'IA a des données d'entraînement potentiellement obsolètes. Les skills injectent la connaissance à jour (documentation, conventions, patterns) et définissent les critères de qualité entre phases.

Ce que ça change : Chaque transition (Intention→Dev, Dev→Audit, etc.) est médiatisée par un skill explicite.

Ce que MADD n'est pas

Du "vibe coding" structuré MADD exige des contrats vérifiables, pas des prompts vagues
Une certification à vendre MADD est open source, sans business de formation
Un remplacement de développeurs MADD repositionne l'humain comme architecte d'intention
Une méthode rigide MADD définit des principes, pas des cérémonies obligatoires
Réservé aux experts IA MADD s'adapte : solo, équipe, PO, dev, tous peuvent pratiquer

Les 4 Agents MADD

L'architecture MADD repose sur une séparation stricte des responsabilités. Chaque agent a un rôle unique et ne valide jamais son propre travail.

Agent Spec — L'Architecte d'Intention

Formalise le "pourquoi" et le "quoi". Produit l'Intention Document et définit le contrat exécutable avec ses critères de validation.

Agent Dev — Le Développeur

Transforme l'intention en code. Respecte le contrat, implémente les fonctionnalités, documente ses choix techniques.

Agent Audit — Le Vérificateur

Audite sans complaisance. Analyse le code produit, vérifie l'alignement avec l'intention, identifie les dérives et les risques.

Agent Scribe — Le Témoin

Documente la réalité objective. Analyse ce qui existe vraiment dans le code (pas ce que le dev déclare), compare avec les specs, produit la rétro-spécification.

Principe fondamental : Le Scribe n'a pas participé au développement. Sa rétro-spécification est objective car il n'a aucun intérêt à embellir ou minimiser.

Note d'implémentation : En pratique, un 5ème rôle — l'Orchestrateur — peut coordonner le flux entre agents, gérer les boucles d'itération dev/audit, et déterminer le scope de validation. Ce rôle peut être humain ou automatisé.

Le MADD Boilerplate fournit une implémentation prête à l'emploi avec 5 agents, un contrat JSON distribué, et un système de recommandations d'audit.

Les Skills MADD

Les skills sont des contrats de connaissance qui médiatisent chaque transition entre agents.

Skill de Spécification

Guide l'Agent Spec dans la production d'Intention Documents structurés avec des requirements vérifiables.

Skill de Développement

Définit les conventions, patterns, et contraintes que l'Agent Dev doit respecter.

Skill d'Audit

Liste les critères de validation, les patterns à détecter, le format du rapport d'audit.

Skill de Rétro-Spécification

Guide le Scribe dans l'analyse objective du code et la production de la documentation de ce qui existe réellement.

Skill de Correction

Encadre la correction des findings d'audit avec traçabilité obligatoire.

Les skills sont versionnés et évoluent avec le projet. Ils peuvent être publics (documentation framework), projet (conventions internes), ou delta (patches de connaissance temporaires).

Commencer avec MADD

Solo (1 personne + IA)

  • Utilise 2-3 modèles/agents différents pour les rôles (ex: Gemini pour specs, Claude pour dev, GPT pour audit)
  • Formalise tes intentions avant de coder
  • Ne merge jamais sans audit indépendant
  • Génère une rétro-spec à chaque cycle

Équipe (2-5 personnes)

  • Assigne les rôles : Architecte d'Intention, Orchestrateur, Arbitre
  • Centralise les skills dans un repo partagé
  • Rétro-spec partagée comme source de vérité

Migration depuis Scrum

  • Les sprints deviennent des cycles d'intention (durée variable)
  • Les stories deviennent des Intention Docs + Contrats
  • La Definition of Done devient le skill d'Audit
  • Les rétrospectives deviennent des consolidations de rétro-spec

Contribuer

MADD est open source. La méthodologie évolue grâce aux contributions de la communauté.

  • GitHub : Proposez des améliorations aux principes, skills, documentation
  • Issues : Signalez les ambiguïtés, proposez des clarifications
  • Discussions : Partagez vos retours d'expérience, cas d'usage

Pas de certification. Pas de formation payante. Pas de dénaturation commerciale.

MADD reste ouvert, ou ne reste pas.

Rejoignez le mouvement

Contribuez à définir le futur du développement assisté par IA.