Flux continu

Boucles itératives et rituels — le rythme sans cadence artificielle

Les boucles AIAD ne sont pas des cycles prescrits à durée fixe : leur 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.

Les cycles de durée fixe créent une friction artificielle avec la vélocité du développement assisté par IA : ils produisent soit du surengagement, soit du rembourrage. Quatre caractéristiques définissent une boucle AIAD : flux continu (dès qu'une fonctionnalité est intégrée, la suivante 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). L'important n'est pas de suivre un calendrier — c'est de livrer de la valeur en continu.

La phase d'initialisation

Avant la première boucle, une phase d'initialisation pose les fondations — une fois par produit, ou à chaque pivot majeur. Sans elle, les agents génèrent du code sans contexte et la dette s'accumule dès le premier jour. Elle produit sept livrables : la vision produit et le Product Goal (PM), le PRD initial (PM), le document ARCHITECTURE (Tech Lead), l'AGENT-GUIDE (AE + PE), les Definitions of Done (équipe), le repository avec CI/CD (PE) et 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. Anti-pattern symétrique : l'initialisation qui s'éternise des semaines — aucun artefact n'est parfait au départ — ou le démarrage précipité sans artefacts, dont les premières semaines coûtent des mois de dette.

Boucle 1 — Planifier

La boucle Planifier transforme une intention métier en spécification que les agents peuvent implémenter. Sans planification explicite, le PE interprète l'intention du PM, l'interprétation diverge, et le code livré ne correspond pas au besoin. Cinq étapes : le PM présente la prochaine priorité, le PE questionne et clarifie, l'équipe décide de la décomposition, rédige la SPEC collaborativement, puis la valide. Elle produit une SPEC prête pour l'implémentation, des Outcome Criteria définis et une compréhension partagée PM/PE. Indicateurs : l'agent peut implémenter sans clarification, les tests attendus sont explicites à 100 %, tous les cas limites sont documentés. Anti-patterns : la planification marathon de quatre heures comme la SPEC de trois lignes type « Ajouter le login » — deux anti-investissements.

Boucle 2 — Implémenter

C'est là que la valeur se matérialise : un PE qui orchestre bien produit plus qu'une équipe traditionnelle de cinq développeurs. La boucle se déroule en sept étapes : préparer le contexte (SPEC + ARCHITECTURE + AGENT-GUIDE, dans le respect du Context Engineering Budget), demander le plan à l'agent avant de coder, valider en continu (compilation, linting, types), générer les tests, itérer si nécessaire — trois fois maximum —, finaliser (tests verts, commit local), puis réaliser la micro-phase Sync des artefacts.

Indicateurs : code correct du premier coup > 70 %, ratio code généré/manuel > 80/20, couverture > 80 % backend et 70 % frontend. Anti-pattern : le PE qui corrige 80 % du code généré — signal d'une SPEC ou d'un AGENT-GUIDE déficient, pas d'un mauvais agent.

Boucle 3 — Valider

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. La validation se déroule en cinq étapes aux responsables distincts :

Elle produit un rapport de validation, une liste de corrections mineures si applicable, et le feu vert pour l'intégration. Indicateurs : validation au premier essai > 70 %, zéro bug critique, moins de trois bugs mineurs par fonctionnalité. Anti-patterns : la validation bâclée « ça a l'air de marcher » (dette cachée) et le ping-pong interminable QA/PE (friction inutile).

La vérification se conçoit, elle ne s'achète pas

AIAD fait le pari que la qualité de la vérification dépend d'abord du design du processus — ce qu'on vérifie, quand et par qui — plutôt que de la puissance du modèle qui relit. C'est une position, pas un résultat démontré : les indices convergent, aucun ne suffit seul. Elle se traduit en quatre règles :

1. La conversation critique a lieu d'abord à l'Execution Gate. C'est là qu'on discute ce qu'on veut ; la revue de code vérifie ensuite la conformité à une intention déjà discutée. Elle reste le lieu où l'on détecte ce qui a été mal compris, pas celui où l'on découvre ce qu'on voulait.
2. Deux classes de défauts. Les défauts structurellement détectables (compilation, types, règles d'architecture outillées, secrets) se délèguent à l'outillage et aux agents. Les défauts sémantiques — fidélité à l'intention, justesse métier, frontières de conception — restent sous revue humaine, en s'appuyant sur le Test de l'Étranger.
3. Séparer celui qui produit de celui qui critique. Quand la revue est confiée à un agent, AIAD recommande — sans l'imposer — un relecteur d'une autre famille de modèles que l'agent producteur : une étude de 2026, menée sur des problèmes de mathématiques, mesure 35 % de faux rejets en auto-revue contre 2 % en revue croisée. Le coût (plusieurs fournisseurs, contrats, analyse RGPD) doit être pesé.
4. Concevoir avant de tester pas à pas. En boucle agent, une conception complète en amont — architecture, types, cas limites, contrats, c'est-à-dire une SPEC — semble plus efficace qu'un TDD incrémental, qui a coûté 3 à 8,5 fois plus de tokens sans gain net dans une expérience exploratoire de 2026. Indice à confirmer, pas règle.

Exemplars de revue. Le savoir de revue d'une organisation — ce qu'un relecteur senior repère et pourquoi — peut être extrait en exemples annotés, versionnés dans des fichiers dédiés (par exemple .aiad/review-exemplars/) et chargés uniquement dans les sessions de revue — pas dans l'AGENT-GUIDE, injecté à chaque session et réservé aux consignes permanentes. Un exemplar se constitue à partir de revues réelles, se révise comme un artefact et se retire quand il ne reflète plus les standards de l'équipe.

Verification Tax. Une synthèse de littérature de 2026 nomme ainsi l'écart entre le gain de productivité à l'écriture du code et le gain, bien plus faible, à la livraison d'un logiciel fiable. C'est ce que l'investissement amont en SPEC et en Gate cherche à réduire.

Boucle 4 — Intégrer

Le code non déployé n'a aucune valeur. La boucle se déroule en huit étapes : revue de code (self ou peer selon criticité), pull main et résolution de conflits, push, PR et CI/CD, déploiement staging puis production, vérification post-déploiement, mise à jour du CHANGELOG et de l'AGENT-GUIDE, Anti-Drift Check, et nettoyage du contexte avec fermeture du ticket.

Quatre stratégies de déploiement sont disponibles : Continuous Deployment (fonctionnalités non critiques), Staged Rollout (fonctionnalités majeures), Feature Flags (expérimentations, A/B tests) et Manual Release (critiques, conformité). Recommandation AIAD : Continuous Deployment avec Feature Flags. Indicateurs : merge → production en moins d'une heure (idéal quinze minutes), rollback < 5 %, zéro downtime.

Déploiement automatisé : la confiance est une chaîne de preuve

Un déploiement sans intervention humaine n'est admissible que si le code est trusted au sens d'une chaîne de preuve vérifiable — Intent Statement, SPEC validée à la Gate, vérifications tracées, Drift Lock — et non d'une confiance déclarative dans l'outil ou le modèle. C'est le critère posé par Roblox pour accepter du code agentique en production (2026) ; AIAD en fait le critère d'entrée du Continuous Deployment pour du code produit par agent. Pour une organisation aux moyens d'ingénierie plus modestes, la conséquence pratique est de réserver le déploiement automatisé aux fonctionnalités dont la chaîne de preuve est complète. Dans le continuum d'autorité, l'autorisation de déploiement reste un acte humain distinct de l'autorisation d'écriture.

Les synchronisations intentionnelles

Les synchronisations ne sont pas des cérémonies : ce sont des moments de décision collective déclenchés par un besoin réel, timeboxés, actionnables et documentés. Chacune est outillée par une commande /aiad qui prépare les données — jamais ne remplace la conversation.

• Standup quotidien (optionnel, 15 min max — /aiad standup) : structuré autour de trois questions SDD — quelle SPEC aujourd'hui ? quel Context Engineering Budget ? y a-t-il un drift à signaler ? Blocages résolus dans la journée à plus de 80 %.
• Demo & Feedback (hebdomadaire, ou après chaque fonctionnalité majeure, 30-60 min — /aiad demo) : la démonstration est structurée par les Intent Statements — d'abord le pourquoi d'origine, puis ce qui a été livré — avant le feedback qualitatif des utilisateurs et l'adaptation du backlog. Cible : plus de trois insights actionnables par session.
• Tech Review (mensuelle, ou après un changement architectural majeur, 1-2 h — /aiad tech-review) : vérifie la cohérence entre ARCHITECTURE.md et le code réel — dérives de patterns, dépendances non documentées, ADR à rédiger, dette technique, revue de l'écosystème d'agents.
• Rétrospective (hebdo ou bi-hebdo, 45-60 min — /aiad retro) : rétrospective classique, puis rétrospective IA — collecte des Lessons Learned (erreurs récurrentes de l'agent) et des Human Learnings (écarts intention/livraison) versés à l'AGENT-GUIDE, avec les métriques d'itération (SQS moyen, drifts détectés, first-time success rate). Les défaillances de supervision — un agent qui agit sans approbation, des relectures automatiques empilées sans plus aucun humain pour trancher — forment une catégorie à part des Human Learnings, avec une question dédiée : « à quel moment un humain aurait-il dû être consulté, et pourquoi ne l'a-t-il pas été ? » Une à trois actions maximum, avec owners.

L'Atelier d'Intention — espace humain pur

L'Atelier d'Intention est la synchronisation fondamentale d'AIAD : mensuel, 60 minutes, toute l'équipe. Les autres synchronisations demandent « qu'a-t-on livré ? », « est-ce que ça marche ? » ; lui seul pose la question que l'agent ne peut pas poser à notre place : « Sommes-nous toujours en train de construire ce que nous voulions vraiment construire ? » Quatre temps : lecture des Intent Statements à voix haute (10 min), confrontation avec le réel (20 min), hypothèses d'écart (20 min), décision d'alignement ou de révision (10 min).

Cible : taux d'alignement intention/livraison > 80 %, deux à cinq hypothèses d'écart documentées, participation à 100 %. Anti-pattern : l'atelier qui dérive en revue technique ou en post-mortem de bugs — les questions restent au niveau de l'intention.

Synchronisation Alignement Stratégique

Mensuelle ou bi-mensuelle — ou quand un Product Goal est atteint, ou après un pivot —, 1 h 30 à 2 h (/aiad sync-strat), avec PM, PE, Tech Lead, QA, stakeholders et Supporters : review des outcomes, review du Product Goal, priorisation du backlog — y compris ce qu'on décide de ne pas faire —, feedback des Supporters sur les obstacles organisationnels, décisions documentées. Elle s'appuie sur les métriques DORA et Flow pour ajuster les priorités.

Anti-patterns des boucles et des synchronisations

• « 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, quand le contexte est frais.
• « L'implémentation prend toujours plus longtemps que prévu. » SPECs insuffisantes ou contexte agent mal préparé : trente minutes de planification en plus économisent des heures d'implémentation.
• « On valide à la fin, juste avant la release. » Les bugs s'accumulent, la validation devient un goulot. Valider chaque fonctionnalité immédiatement.
• « On fait toutes les syncs chaque semaine. » Surcharge de réunions : adapter la fréquence au besoin réel, espacer quand l'équipe est mature.
• « Personne ne prépare les syncs. » Sessions d'improvisation inefficaces : chaque synchronisation a un owner qui prépare l'agenda et les inputs.