Les Boucles Itératives

Définition

Les boucles itératives AIAD sont les cycles naturels de création de valeur. Elles ne sont pas des cycles prescrits à durée fixe — ce sont des boucles dont la durée est dictée par la complexité réelle du travail. Une correction de bug : deux heures. Une nouvelle fonctionnalité : trois jours. Une exploration de domaine : une semaine. Chaque tâche trouve sa cadence naturelle.

Quatre caractéristiques définissent une boucle : flux continu (dès qu’une fonctionnalité est intégrée, la prochaine démarre), durée variable (la complexité dicte la durée, pas le calendrier), priorité dynamique (le feedback peut réorienter la prochaine fonctionnalité), et focus absolu (une seule fonctionnalité à la fois par PE).

Pourquoi les boucles remplacent les cycles prescrits

Les cycles de durée fixe créent une friction artificielle avec la vélocité naturelle du développement assisté par IA. Ils imposent une cadence indépendante de la complexité, ce qui produit soit du surengagement (trop pour une boucle), soit du rembourrage (trop peu). Les boucles AIAD éliminent cette friction en calquant le rythme sur la réalité.

L’important n’est pas de suivre un calendrier — c’est de livrer de la valeur en continu.

---

La phase d’initialisation

Définition. La phase d’initialisation pose les fondations avant de construire. Elle n’a lieu qu’une fois par produit, ou à chaque pivot majeur.

Pourquoi cette phase existe. Sans initialisation structurée, les équipes démarrent dans le flou. Les agents IA génèrent du code sans contexte, l’architecture émerge par accident, et la dette technique s’accumule dès le premier jour.

Comment. La phase d’initialisation produit sept livrables :

1. La vision produit et le Product Goal (PM)
2. Le PRD initial (PM)
3. Le document ARCHITECTURE (Tech Lead)
4. L’AGENT-GUIDE (AE + PE)
5. Les Definitions of Done DoOD et DoOuD (équipe)
6. Le repository avec CI/CD (PE)
7. La première SPEC prête (PM + PE)

L’équipe doit pouvoir démarrer l’implémentation entre le cinquième et le septième jour, avec tous les artefacts essentiels en place.

Anti-pattern. L’initialisation qui s’éternise pendant des semaines — aucun artefact n’est parfait au départ. Ou le démarrage précipité sans artefacts — les premières semaines coûtent des mois de dette.

---

Boucle 1 : Planifier

Définition. La boucle Planifier transforme une intention métier en spécification que les agents IA peuvent implémenter.

Pourquoi cette boucle existe. Sans planification explicite, le PE interprète l’intention du PM. Cette interprétation diverge. Le code livré ne correspond pas au besoin.

Comment. La boucle se déroule en cinq étapes : le PM présente la prochaine priorité, le PE questionne et clarifie, l’équipe prend la décision de décomposition, rédige la SPEC collaborativement, puis la valide.

Ce qui déclenche la boucle : la fonctionnalité précédente est intégrée, ou une nouvelle priorité critique émerge.

Ce que produit la boucle : une SPEC détaillée prête pour implémentation, les Outcome Criteria définis (si fonctionnalité majeure), et une compréhension partagée entre PM et PE.

Les indicateurs de succès : l’agent IA peut implémenter sans clarification, les tests attendus sont explicites à 100 %, et tous les cas limites sont documentés.

Anti-pattern. La planification marathon de quatre heures, ou la SPEC de trois lignes type “Ajouter le login”. Les deux sont des anti-investissements.

---

Boucle 2 : Implémenter

Définition. La boucle Implémenter orchestre les agents IA pour transformer la SPEC en code fonctionnel.

Pourquoi cette boucle existe. C’est là que la valeur se matérialise. Un PE qui orchestre bien produit plus qu’une équipe traditionnelle de cinq développeurs.

Comment. La boucle se déroule en sept étapes :

1. Le PE prépare le contexte (SPEC + ARCHITECTURE + AGENT-GUIDE) en respectant le Context Budget
2. Il demande le plan à l’agent avant de coder
3. Il valide en continu (compilation, linting, types)
4. Il génère les tests
5. Il itère si nécessaire — maximum trois fois
6. Il finalise (tous les tests passent, commit local)
7. Il réalise la micro-phase Sync des artefacts

Micro-phase Sync des artefacts

Cette micro-phase dure quinze minutes. Elle est sous la responsabilité du PE. Elle n’est pas négociable. Elle pose quatre questions :

• La SPEC reflète-t-elle le comportement implémenté ? (si non, mettre à jour la SPEC)
• Le Critère de Drift de la SPEC est-il toujours valide ? (si les fichiers impactés ont changé, réviser)
• Une erreur agent notable a-t-elle été corrigée manuellement ? (si oui, documenter dans Lessons Learned)
• Une nouvelle convention a-t-elle émergé ? (si oui, ajouter dans les patterns de l’AGENT-GUIDE)

Ce que produit la boucle : code fonctionnel respectant la DoOD, tests automatisés passants, commit prêt, SPEC mise à jour si le comportement a évolué, et Lessons Learned mis à jour si une erreur agent notable a été corrigée.

Les indicateurs de succès : code correct du premier coup supérieur à 70 %, ratio code généré/manuel supérieur à 80/20, couverture de tests supérieure à 80 % backend et 70 % frontend.

Anti-pattern. Le PE qui corrige 80 % du code généré — c’est le signal que la SPEC ou l’AGENT-GUIDE est déficient. Ou le PE qui génère sans contexte et espère que ça marche — le résultat est prévisible.

---

Boucle 3 : Valider

Définition. La boucle Valider s’assure que le code répond aux attentes métier ET aux standards de qualité.

Pourquoi cette boucle existe. Le code qui compile n’est pas forcément le code qui fonctionne. Le code qui fonctionne n’est pas forcément le code qui apporte de la valeur.

Comment. La validation se déroule en cinq étapes avec des responsables distincts :

1. Validation technique (PE) : CI, couverture, linting, DoOD
2. Validation fonctionnelle (QA) : tests, acceptance criteria
3. Validation utilisabilité (QA + PM) : UX, accessibilité, performance
4. Validation métier (PM) : intention respectée, outcomes
5. Décision (équipe) : VALIDÉ, CORRECTIONS ou REJET

Ce que produit la boucle : un rapport de validation, une liste de corrections mineures si applicable, et le feu vert pour intégration.

Les indicateurs de succès : validation au premier essai supérieure à 70 %, zéro bug critique détecté, et moins de trois bugs mineurs par fonctionnalité.

Anti-pattern. La validation bâclée “ça a l’air de marcher”, ou le ping-pong interminable entre QA et PE. Le premier crée de la dette cachée. Le second crée de la friction inutile.

---

Boucle 4 : Intégrer

Définition. La boucle Intégrer met le code en production et prépare la prochaine itération.

Pourquoi cette boucle existe. Le code non déployé n’a aucune valeur. Plus le délai entre merge et production est long, plus le feedback est tardif.

Comment. La boucle se déroule en huit étapes :

1. Revue de code (self ou peer selon criticité)
2. Pull main, résolution de conflits et tests
3. Push, PR et CI/CD
4. Déploiement staging puis production
5. Vérification post-déploiement
6. Mise à jour CHANGELOG et AGENT-GUIDE
7. Anti-drift check
8. Nettoyage du contexte et fermeture du ticket

Anti-drift check (v1.5)

L’Anti-drift check dure dix minutes et est sous la responsabilité du PE. Avant de fermer le ticket, le PE répond à trois questions pour chaque SPEC utilisée dans la session :

1. Le comportement livré correspond-il exactement à ce que décrit la SPEC ?
2. Les fichiers impactés listés dans la SPEC sont-ils toujours exhaustifs ?
3. (v1.5) Le CRITERE DE DRIFT de l’Intent Statement parent signale-t-il un écart entre l’intention initiale et ce qui a été livré ?

Si la réponse à l’une des trois est non, mettre à jour la SPEC et éventuellement l’Intent Statement avant de fermer. La SPEC doit être committée dans le même PR que le code, dans le même Drift Lock.

Ce que produit la boucle : code en production, documentation mise à jour, contexte prêt pour la prochaine fonctionnalité, SPECs vérifiées et synchronisées avec la réalité du code livré (Drift Lock respecté), et Intent Statement archivé dans .aiad/intents/.

Les stratégies de déploiement disponibles : Continuous Deployment (fonctionnalités non-critiques), Staged Rollout (fonctionnalités majeures), Feature Flags (expérimentales, A/B tests), et Manual Release (critiques, compliance). La recommandation AIAD : Continuous Deployment avec Feature Flags.

Les indicateurs de succès : temps merge à production inférieur à une heure (idéal quinze minutes), taux de rollback inférieur à 5 %, et zéro downtime lors des déploiements.

Anti-pattern. Le code qui attend des jours avant d’être mergé, ou le déploiement manuel stressant du vendredi soir. Les deux sont des anti-patterns de gouvernance, pas de compétence.

---

Anti-patterns des boucles

“On planifie tout en début de semaine.” Retour au mode batch : les priorités changent mais le plan est figé. Planifier juste avant d’implémenter — le contexte est frais, les décisions sont pertinentes.

“L’implémentation prend toujours plus longtemps que prévu.” SPECs insuffisantes ou contexte agent mal préparé. Investir trente minutes de plus en planification économise des heures en implémentation.

“On valide à la fin, juste avant la release.” Les bugs s’accumulent, la validation devient un goulot d’étranglement. Valider chaque fonctionnalité immédiatement : le feedback rapide permet de corriger vite.