Fondations immuables

Valeurs et piliers — la constitution d'AIAD

La philosophie d'AIAD tient en une phrase : AIAD ne juge pas sur l'effort, la vélocité ou la conformité aux processus — il juge sur la valeur réalisée pour les stakeholders. Tout le reste en découle : quatre piliers, sept valeurs immuables, trois principes fondateurs.

Juger sur la valeur réalisée

Sans définition explicite de « réussir », les équipes optimisent les mauvaises métriques. Une fonctionnalité techniquement parfaite que personne n'utilise est un échec. Un cycle complété à 100 % sans impact mesurable est un échec. Une livraison partielle qui résout le problème réel est un succès. AIAD énonce cela sans ambiguïté pour que l'équipe ne confonde jamais activité et valeur.

Les quatre piliers

1. L'empirisme radical. Tout est une hypothèse jusqu'à preuve du contraire. Les données et usages réels priment sur les intuitions ; pivoter rapidement vaut mieux que persévérer dans l'erreur ; maximiser la vitesse d'apprentissage compte plus que la vitesse de production. Anti-pattern : « On sait ce que veulent nos utilisateurs, on travaille avec eux depuis cinq ans. » Les certitudes d'hier sont les échecs de demain.

2. L'orchestration systémique. La valeur d'une équipe ne réside plus dans sa capacité à coder, mais dans sa capacité à orchestrer des agents IA. Les humains définissent le pourquoi et le quoi ; les agents prennent en charge le comment. Former un expert améliore une personne de 20 % ; configurer correctement l'AGENT-GUIDE améliore toute l'équipe de 50 %. Anti-pattern : « Notre meilleur dev n'a pas besoin des agents. » Son temps serait mieux investi à configurer l'écosystème pour les dix autres.

3. La fluidité par émergence. Les cadences artificielles — cycles de durée fixe — créent une friction avec la vélocité naturelle du développement assisté par IA. AIAD y substitue un flux continu ajusté à la complexité réelle : un bug se corrige en deux heures, une fonctionnalité prend trois jours, une exploration une semaine. Anti-pattern : « On garde nos cycles mais on fait de l'AIAD dedans » — le pire des deux mondes : rigidité plus confusion.

4. L'Excellence Intentionnelle. Livrer du code n'est pas l'objectif ; réaliser une intention digne de la valeur investie l'est. L'agent peut contribuer à l'excellence technique — il ne peut pas porter l'intention. La question centrale : « les critères d'outcome eux-mêmes reflètent-ils une intention digne de la valeur investie ? » L'Atelier d'Intention mensuel — espace humain pur, sans IA — est le mécanisme qui vérifie cet alignement. Anti-pattern : « On livre d'abord, on améliorera après. » « Après » n'arrive jamais.

Les piliers forment un système

On ne prend pas « deux piliers sur quatre ». Sans empirisme, on construit les mauvaises choses ; sans orchestration, on construit lentement et mal ; sans fluidité, on crée friction et gaspillage ; sans Excellence Intentionnelle, on livre du code — pas une intention réalisée.

Les sept valeurs immuables

1. Primauté de l'Intention Humaine. L'intention de ce qu'on construit reste le domaine exclusif de l'humain. L'agent exécute ; il ne décide pas de ce qui mérite d'être construit.

2. Honnêteté sur les Contradictions. Quand les contraintes s'opposent, AIAD dit la vérité sur les trade-offs plutôt que de promettre l'impossible.

3. Sobriété Intentionnelle. On construit ce qui est nécessaire, pas ce qui est impressionnant. Chaque fonctionnalité doit se justifier par une intention claire.

4. Ouverture Radicale. AIAD est open source : le savoir méthodologique se partage, il ne se verrouille pas. Pratiques, outils et retours d'expérience sont publiés sur aiad.ovh — la transparence est une condition de l'amélioration collective.

5. Empirisme sans Concession. On valide les hypothèses par l'observation, pas par le consensus. Une équipe AIAD ne décide pas sur la foi d'une intuition quand une mesure est possible.

6. Responsabilité Partagée. Le succès et l'échec appartiennent à l'équipe, pas à un individu. Les responsabilités sont claires — la culpabilisation ne l'est jamais. Illustration terrain (mai 2026) : un agent doté d'autonomie financière (protocole Cloudflare/Stripe, plafond de 100 $ par mois) a acheté le domaine superseal.cc au lieu de superseal.club — une erreur sans responsable clairement désigné en amont. La Responsabilité Partagée impose qu'une délégation d'autonomie à un agent, a fortiori financière ou opérationnelle, soit assortie d'une responsabilité humaine explicitement assumée et de points de contrôle documentés (plafond, journal d'audit, procédure de rollback). Ces points de contrôle sont détaillés dans le profil « Agents à effet irréversible » de l'agent AIAD-AI-ACT et vérifiés à l'Execution Gate.

7. Human Authorship. La paternité de l'intention ne se délègue pas. Tout Intent Statement est rédigé en première personne par un humain identifiable ; si un agent l'a rédigé, la session est invalidée. Légitimation externe (2026) : cette valeur correspond précisément à la « programmation agentique sérieuse » de Martin Fowler — par opposition au vibe coding — et prévient la cognitive debt (Fowler/Joshi, 2026). La pratique terrain va dans le même sens : sur 29 585 cycles de pull requests analysés (arXiv, mai 2026), l'autorité de fusion reste « presque exclusivement humaine », et les agents de pointe présentent un biais d'action mesuré de 35 à 65 % qui justifie un point de contrôle humain avant exécution. Depuis la doctrine v1.9, la valeur se décline en un continuum d'autorité : chaque passage d'un niveau d'autorité au suivant est un acte humain distinct — et répondre aux questions de l'agent n'est pas consentir.

Un système, pas un menu

Ces sept valeurs forment un système — en retirer une fait s'effondrer l'ensemble. Elles ne sont pas des aspirations : elles sont constitutives du framework.

Les trois principes fondateurs de l'orchestration

Les 3 principes fondateurs
PrincipeÉnoncé
La spécification comme invariant vivantLa SPEC reste la source de vérité avant, pendant et après l'implémentation. Elle est « done » quand elle reflète exactement l'état du code en production. AIAD est spec-anchored : ni spec-first jetable, ni spec-as-source.
Le drift comme échec de Definition of DoneLe spec drift n'est pas un problème d'IA — c'est un échec de processus humain. Toute itération qui modifie un comportement met à jour la SPEC dans la même session. C'est le Drift Lock.
Le Context Budget comme disciplineLe PE est responsable du budget de contexte de chaque session. Un AGENT-GUIDE de cent pages est moins efficace, pas plus : injecter tout dans chaque session est l'anti-pattern principal.

Budget, délégation et datation (v1.9). Deux évolutions de 2026 changent le calcul sans changer la discipline. D'abord, les fenêtres de contexte d'un million de tokens se généralisent : elles repoussent le seuil de dégradation, elles ne le suppriment pas. Ensuite, certains harnesses font hériter aux sous-agents la conversation parente : une délégation coûte alors le contexte parent en plus du travail propre, et il vaut mieux déléguer tôt. Règle transverse : toute hypothèse de capacité ou de prix citée dans un artefact AIAD est datée et revalidée périodiquement.

Positionnement dans l'écosystème SDD

AIAD est un méta-framework : les outils — Kiro (Amazon), GitHub Spec Kit, OpenSpec, Codeplain, SPDD et son REASONS Canvas, OpenAI Symphony, les Routines de Claude Code — gèrent le « comment faire avec les agents » ; AIAD gère le « comment travailler en équipe humain-IA » : qui porte quelle responsabilité, comment valider que l'intention reste intacte, comment mesurer la valeur réelle, comment maintenir la gouvernance réglementaire. Il peut intégrer ces outils comme implémentations de sa couche spec.

Relations avec les outils de l'écosystème
OutilRelation avec AIAD
SPDDLe REASONS Canvas est une approche optionnelle pour /sdd spec. SPDD = méthode de production de spec ; AIAD = gouvernance du cycle complet.
OpenAI SymphonyConvergence sur l'artefact d'intention persistant — mais Symphony est issue-tracker-first, sans critères qualité. AIAD ajoute le SQS, le Drift Lock et la gouvernance.
Routines (Claude Code)Déclencheurs d'exécution compatibles : une Routine exécute une SPEC déjà validée (Gate ≥ 4/5), elle n'en tient pas lieu — pas d'Intent, pas de SQS, pas de Human Authorship chez elle.
Amazon KiroIDE, CLI et web avec spec intégrée, steering documents et hooks ; orchestrateur Kiro Crew open source (Apache 2.0). Kiro a ajouté une revue de spec aux checkpoints de phase et, dans Kiro Crew, des portes d'approbation et un journal d'audit signé : la différence ne porte plus sur la présence de contrôles humains mais sur leur objet — l'exécution chez Kiro, l'intention chez AIAD. Kiro peut servir de couche d'exécution d'une SPEC AIAD validée, ses steering documents alimentant l'AGENT-GUIDE.
GitHub Spec KitOpen source (licence MIT) et multi-agents. Il outille la production de spécifications ; AIAD y ajoute l'Intent Statement, le SQS, la gouvernance réglementaire et le modèle de responsabilités.
OpenSpecSpec unifiée, delta specs, validation des scénarios et consentement explicite avant écriture — une convergence avec l'Execution Gate, sans couche organisationnelle ni gouvernance réglementaire.
CodeplainPartage la thèse du SDD Mode — la spec est l'actif durable, le code un produit régénérable — et va plus loin en ne maintenant jamais le code. Sous AIAD, une spec .plain peut être la SPEC ; l'Intent Statement et l'Execution Gate la précèdent.
GitHub Copilot agent-nativePassé en mode agent-native en juin 2026 (agents en parallèle, worktrees isolés, canvas de supervision). Compatible : l'Intent Statement cadre chaque session, l'Execution Gate valide la SPEC avant chaque agent parallèle, le Drift Lock synchronise chaque worktree avec sa SPEC dans la PR correspondante.

L'ère des agent labs. En 2026, les grands laboratoires se repositionnent en « agent labs » et livrent leurs propres harnesses (OpenAI Codex, Claude Code d'Anthropic, Gemini de Google). Cette adoption massive crée un vide de gouvernance de l'intention humaine que les harnesses ne comblent pas : ils optimisent le « comment générer », pas le « qui a voulu quoi, et qui valide ». AIAD est aussi model-agnostic par conception : quand un modèle est déprécié, Intent Statements, SPECs, AGENT-GUIDE et Execution Gate restent valides — seul l'exécutant change. La gouvernance est dans les artefacts, pas dans le vendor.

Validations industrielles 2026

Les convergences récentes ne sont pas des suivis — ce sont des validations indépendantes d'une approche antérieure. Anthropic formalise en mars 2026 le Context Engineering comme discipline à part entière — AIAD l'implémente depuis la v1.3. Thoughtworks Radar 2026 identifie Context Engineering, Harness Engineering et Spec-Driven Development comme concepts convergents. R2Code (arXiv, avril 2026) valide empiriquement le spec-first : −41,7 % de tokens et +7,4 % de fidélité. AWS Strands (2026) observe −96 % de tokens sur des workflows intent-based. Gartner MQ 2026 projette 30-50 % de gain de productivité agentique d'ici 2028 — créant le vide de gouvernance qu'AIAD adresse structurellement. Tang et al. (arXiv, juin 2026) fournissent la preuve empirique fondatrice : sur 20 574 sessions réelles d'agents de code, 91,49 % nécessitent une correction humaine explicite, et les sept formes de désalignement identifiées (mauvaise interprétation de l'intention, scope creep, solutions hors spec, exigences hallucinées…) correspondent aux problèmes que le cycle Intent Statement → SQS → Execution Gate adresse structurellement. Fin juillet 2026, Cognizant intègre à son produit Flowsource un module explicitement nommé « Spec-Driven Development » : le SDD devient une offre d'intégrateur pour les grands comptes — une preuve de marché, pas d'efficacité.

Appui externe (v1.9). En juillet 2026, Anthropic a publié une refonte de sa doctrine de context engineering : suppression d'environ 80 % du system prompt de Claude Code sans perte mesurée selon l'éditeur — un chiffre de l'éditeur, non audité — et bascule recommandée des consignes simples vers des références riches et vérifiables (suites de tests détaillées, code existant à porter). C'est une validation externe de la thèse du SQS : une bonne SPEC n'est pas une liste de contraintes plus longue, c'est un artefact riche et vérifiable.