Le Workflow MADD
Chaque cycle MADD suit un pipeline en trois phases. Les artefacts circulent entre les agents — chaque agent lit la sortie de la phase précédente et écrit pour la suivante.
Phase 1 — Formalisation Conductor + Architect
Le Conductor reçoit le besoin et orchestre le cycle. L'Architect formalise l'intention, annote les tâches par domaine, et produit le Contrat Exécutable avec ses critères de validation.
Phase 2 — Exécution Maker + CI + Breaker (par fraction)
Le travail est décomposé en fractions. Pour chaque fraction, un Maker spécialisé par domaine implémente, le CI valide le build, et un Breaker spécialisé audite. Si le Breaker rejette, le Maker itère.
Phase 3 — Mémoire Witness
Le Witness analyse le code produit de manière indépendante — sans lire ce que le Maker déclare avoir fait. La rétro-spécification résultante documente la réalité et devient le point de départ du prochain cycle.
La sortie de chaque phase est l'entrée de la suivante. Aucun agent ne valide son propre travail. Le cycle est ancré dans la réalité, pas dans les promesses.
L'Intention Document
L'artefact d'entrée. Chaque cycle MADD commence par une intention formalisée — pas un message de chat, pas une demande vague.
L'Intention Document capture le pourquoi et le quoi — jamais le comment. Il est produit par l'Agent Architect et sert de fondation au Contrat Exécutable.
Structure
Bonnes pratiques
- Un Intention Document = une unité de travail cohérente
- Chaque requirement doit correspondre à au moins un critère de validation
- Le "hors scope" est aussi important que le scope — il empêche la dérive des agents
- Versionnez l'Intention Document avec le code — c'est un artefact de première classe, pas un prompt jetable
Le Contrat Exécutable
L'artefact de validation. Ce qui transforme un souhait en engagement vérifiable.
Un contrat est "exécutable" quand il peut être vérifié automatiquement. Pas de "ça a l'air bon" — soit ça passe, soit ça échoue.
Le contrat est au centre de l'architecture MADD. L'Architect l'écrit en même temps que l'Intention Document. Le Maker implémente pour le satisfaire. Le CI l'exécute. Le Breaker vérifie la conformité au-delà des vérifications automatisées. Le Witness compare la réalité contre lui.
Types de contrats
Le principe
Si on ne peut pas écrire un test pour vérifier un requirement, ce requirement est mal défini.
Les Fractions
L'unité d'exécution. Le travail est décomposé en petites fractions livrables indépendamment, chacune complétant son propre cycle Maker → CI → Breaker.
Au lieu d'un cycle monolithique "tout implémenter, tout auditer", le Conductor décompose les tâches en fractions — des groupes de 2 à 6 tâches liées. Chaque fraction passe par son propre cycle avant que la suivante ne commence.
Règles de décomposition
- Taille — 2-6 tâches par fraction. Assez petit pour un contexte ciblé, assez grand pour une livraison cohérente.
- Cohérence — Les tâches d'une fraction doivent être liées. Un changement de schéma de base de données et ses endpoints API vont ensemble.
- Ordre — Les fondations d'abord. Les fractions infrastructure et base de données avant les fractions API. L'API avant le frontend.
- Indépendance — Chaque fraction produit du code fonctionnel et testé. Le système doit être opérationnel après chaque fraction.
Pourquoi les fractions ?
- Contrôle du contexte — Les agents traitent 2-6 tâches par session au lieu de 20+, réduisant hallucinations et dérives
- Audit ciblé — Le Breaker revoit 3-4 changements liés, pas tout le codebase en une fois
- Récupération après crash — Si une session échoue, reprise depuis la dernière fraction complétée, pas depuis zéro
- Livraison incrémentale — Du code fonctionnel après chaque fraction, pas une livraison big-bang à la fin
La Rétro-Spécification
L'artefact de mémoire. Ce qui documente objectivement ce qui existe réellement dans le code.
La rétro-spec n'est pas ce que le Maker dit avoir fait. C'est ce que le Witness — un agent indépendant qui n'a pas participé au développement — constate en analysant le code réel.
Pourquoi c'est différent
Contenu
- État actuel — Ce qui existe dans le code en ce moment
- Écarts — Différences entre intention et implémentation
- Dette technique — TODO, FIXME, workarounds, raccourcis identifiés
- Dépendances — Librairies, versions, contraintes
- Points d'attention — Risques, limitations connues, zones nécessitant du travail futur
L'ancre du cycle
La rétro-spec devient le point de départ du prochain cycle. Quand un nouvel Intention Document est rédigé, l'Architect consulte la rétro-spec pour comprendre l'état réel du système — pas la documentation marketing, pas la description optimiste du développeur, mais ce qui existe vraiment. C'est ainsi que MADD atteint le zéro dérive : chaque cycle est ancré dans la réalité du précédent.
Les Opérations
L'artefact d'exécution. Comment le système fonctionne au-delà du développement.
MADD ne s'arrête pas à la livraison du code. La spécification opérationnelle capture tout ce qui est nécessaire pour déployer, exécuter et surveiller le système en production.
Ce que couvrent les opérations
Pourquoi les opérations comptent dans MADD
Quand l'IA accélère le développement, l'écart entre "marche en local" et "tourne de façon fiable en production" devient le nouveau risque. Spécifier les opérations en amont — dans le contrat, pas en afterthought — assure que l'Architect pense aux contraintes de déploiement et que le Maker construit avec la production en tête.