Vision & Philosophie
Définition
Section intitulée « Définition »La philosophie d’AIAD tient en une phrase : AIAD ne juge pas sur l’effort, la vélocité ou la conformité aux processus. AIAD juge sur la valeur réalisée pour les stakeholders. Tout le reste en découle.
Pourquoi cette clarté est nécessaire
Section intitulée « Pourquoi cette clarté est nécessaire »Sans définition explicite de ce que signifie “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 éviter que l’équipe ne confonde activité et valeur.
Exemple concret : une équipe livre un système de notifications push en trois semaines. Code propre, tests complets, documentation exhaustive. Résultat : 2 % des utilisateurs activent les notifications. Avant de construire, l’équipe aurait dû valider l’hypothèse “les utilisateurs veulent des notifications push” par un test simple — un bouton factice, une enquête, un prototype. Coût : deux jours. Économie : trois semaines.
Les quatre piliers
Section intitulée « Les quatre piliers »Pilier 1 : Empirisme radical
Section intitulée « Pilier 1 : Empirisme radical »Dans un contexte de développement assisté par IA, la vélocité d’exécution rend les plans obsolètes avant leur complétion. 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 maximiser la vitesse de production.
L’anti-pattern classique : “On sait ce que veulent nos utilisateurs, on travaille avec eux depuis cinq ans.” Les besoins évoluent. Les certitudes d’hier sont les échecs de demain.
Pilier 2 : Orchestration systémique
Section intitulée « Pilier 2 : Orchestration systémique »La valeur d’une équipe ne réside plus dans sa capacité à coder, mais dans sa capacité à orchestrer des agents IA efficacement. Les humains définissent le pourquoi et le quoi — l’intention et la validation. Les agents prennent en charge le comment — la génération de code, de tests, de documentation.
Former un développeur expert améliore la performance d’une personne de 20 %. Configurer correctement l’AGENT-GUIDE améliore la performance de toute l’équipe de 50 %. L’investissement optimal est évident.
L’anti-pattern : “Notre meilleur dev n’a pas besoin des agents, il code plus vite manuellement.” Peut-être. Mais son temps serait mieux investi à configurer l’écosystème pour les dix autres.
Pilier 3 : Fluidité par émergence
Section intitulée « Pilier 3 : 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 substitue aux cycles prescrits un flux continu ajusté à la complexité réelle. Une tâche simple (correction de bug) s’accomplit en deux heures. Une tâche complexe (nouvelle fonctionnalité) prend trois jours. Une exploration (nouveau domaine) prend une semaine. Chaque tâche trouve sa cadence naturelle.
L’anti-pattern : “On garde nos cycles mais on fait de l’AIAD dedans.” Vous aurez le pire des deux mondes : rigidité plus confusion.
Pilier 4 : Excellence Intentionnelle
Section intitulée « Pilier 4 : Excellence Intentionnelle »Livrer du code n’est pas l’objectif. Réaliser une intention digne de la valeur investie l’est. Le mot “intentionnelle” ancre ce pilier sur ce que seul l’humain peut apporter dans un système d’orchestration IA : l’agent peut contribuer à l’excellence technique, il ne peut pas porter l’intention.
La question centrale n’est plus seulement “les fonctionnalités atteignent-elles leurs critères d’outcome ?” mais “les critères d’outcome eux-mêmes reflètent-ils une intention digne de la valeur investie ?” L’Atelier d’Intention mensuel est le mécanisme qui vérifie cet alignement.
L’anti-pattern : “On livre d’abord, on améliorera après si besoin.” “Après” n’arrive jamais.
Ancrage constitutionnel de l’Excellence Intentionnelle : Valeur 1 (Primauté de l’Intention Humaine), Valeur 3 (Sobriété Intentionnelle), Article I (Raison d’être).
Les trois principes fondateurs de l’orchestration
Section intitulée « Les trois principes fondateurs de l’orchestration »La spécification comme invariant vivant
Section intitulée « La spécification comme invariant vivant »Une spécification n’est pas un document de passage. C’est un invariant vivant qui reste la source de vérité entre l’intention humaine et le code généré, avant, pendant et après l’implémentation. Le code évolue — la spécification évolue avec lui. Une spécification est “done” quand elle reflète exactement l’état du code en production. Tant que ce n’est pas le cas, l’itération n’est pas terminée.
Conséquence directe : le spec drift — l’écart entre spécification et réalité du code — est l’anti-pattern numéro un d’AIAD, non un problème mineur de documentation.
Le drift comme échec de Definition of Done
Section intitulée « Le drift comme échec de Definition of Done »Le spec drift n’est pas un problème d’IA — c’est un échec de processus humain. Quand le code évolue sans que la spécification soit mise à jour, l’artefact devient de la documentation morte. La prochaine session avec l’agent repart d’une intention incorrecte.
- Après une itération : spécification légèrement désalignée, corrections mineures.
- Après cinq itérations : spécification obsolète, l’agent génère du code conflictuel.
- Après vingt itérations : spécification inutilisable, retour au codage sans cadre de facto.
La règle est non-négociable : toute itération qui modifie le comportement d’une fonctionnalité doit mettre à jour la spécification correspondante dans la même session.
Le Context Budget comme discipline d’orchestration
Section intitulée « Le Context Budget comme discipline d’orchestration »Les études terrain (Addy Osmani, janvier 2026 ; Anthropic, mars 2026) montrent que les agents IA dégradent leur adhérence aux instructions quand le contexte injecté dépasse un certain seuil. Un AGENT-GUIDE de cent pages n’est pas plus efficace — il est moins efficace. Ce phénomène, le context rot, désigne la dégradation de la qualité LLM bien avant la limite théorique de la fenêtre de contexte.
Le Product Engineer est responsable de ne pas saturer le Context Engineering Budget de l’agent. La hiérarchie des artefacts AIAD (PRD → ARCHITECTURE → AGENT-GUIDE → SPEC) est précisément l’outil pour gérer ce budget :
- Le contexte permanent (standards, conventions, patterns) va dans l’AGENT-GUIDE
- Le contexte de tâche (fonctionnalité en cours) va dans la SPEC activée uniquement pour la session
- Le contexte stratégique (vision, outcomes) va dans un PRD synthétique en référence
Injecter tout dans chaque session est l’anti-pattern principal : l’agent reçoit tout, comprend peu.
Note : Anthropic a formalisé en mars 2026 le Context Engineering comme discipline à part entière, distincte du prompt engineering — “l’art et la science de curating ce qui entre dans la fenêtre de contexte limitée à partir d’un univers en constante évolution d’informations possibles”. Le Context Budget AIAD est une implémentation opérationnelle de cette discipline.
Les sept valeurs fondatrices
Section intitulée « Les sept valeurs fondatrices »AIAD repose sur sept valeurs fondatrices, immuables et non-négociables. Elles ne sont pas des aspirations — elles sont constitutives du framework.
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. Les 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 prend pas de décision 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.
7. Human Authorship. La paternité de l’intention ne se délègue pas à l’agent. Tout Intent Statement doit être rédigé en première personne par un humain. L’agent peut enrichir, questionner, affiner. Il ne peut pas initier. Si un agent a rédigé l’Intent Statement, la session est invalidée. L’Execution Gate ne peut pas être passé sans un Intent Statement dont l’auteur est humain et identifiable.
Ancrage constitutionnel : Valeur 1 de l’Article II de la Constitution AIAD v1.0.
Ces sept valeurs forment un système. En retirer une fait s’effondrer l’ensemble.
Anti-patterns de vision
Section intitulée « Anti-patterns de vision »“On mesure déjà la vélocité, c’est pareil.” La vélocité mesure l’output — les unités livrées. L’outcome est la valeur créée. Une équipe peut livrer des fonctionnalités inutiles à grande vitesse. AIAD mesure l’adoption, l’usage, la satisfaction — pas les points.
“L’empirisme, c’est ne pas planifier.” Confusion entre “pas de plan” et “plan adaptatif”. AIAD donne une direction (North Star), des objectifs (Outcomes), et des hypothèses à valider. Ce qu’il n’a pas, c’est un plan détaillé à six mois figé.
“Les piliers sont indépendants, on en prend deux sur quatre.” Les piliers forment un système. Sans l’empirisme, on construit les mauvaises choses. Sans l’orchestration, on construit lentement et mal. Sans la fluidité, on crée de la friction et du gaspillage. Sans l’Excellence Intentionnelle, on livre du code, pas une intention réalisée.
Positionnement dans l’écosystème des outils SDD (v1.6)
Section intitulée « Positionnement dans l’écosystème des outils SDD (v1.6) »AIAD intègre les meilleures pratiques SDD (Kiro, GitHub Spec-Kit, SPDD) en leur ajoutant la dimension organisationnelle et humaine. Cette phrase résume le positionnement du framework dans un écosystème en rapide évolution.
Les outils gèrent le “comment faire avec les agents” — Kiro (Amazon), GitHub Spec-Kit, SPDD et son REASONS Canvas, OpenAI Symphony : ces outils s’attachent à la production de spécifications ou à l’orchestration d’agents dans un flux individuel ou équipe. Ils sont utiles, souvent complémentaires, et évoluent rapidement.
AIAD gère le “comment travailler en équipe humain-IA” — il opère à un niveau supérieur : qui porte quelle responsabilité, comment valider que l’intention reste intacte, comment mesurer la valeur réelle livrée, et comment maintenir la gouvernance réglementaire. AIAD est un meta-framework : il peut intégrer ces outils comme implémentations de sa couche spec.
Relation avec SPDD : Le REASONS Canvas de SPDD constitue une approche optionnelle et enrichissante pour la phase de rédaction de SPEC (/sdd-spec). SPDD = couche méthode de production de spec. AIAD = couche gouvernance du cycle complet.
Relation avec OpenAI Symphony : Symphony et les Intent Statements AIAD convergent sur le concept d’artefact d’intention persistant pour ancrer les agents. La différence clé : Symphony est issue-tracker-first, sans critères qualité formels. AIAD enrichit ce concept avec le SQS, le Drift Lock et la gouvernance réglementaire. Les Intent Statements AIAD peuvent pointer vers des issues Jira/GitHub tout en existant comme artefacts indépendants avec leur propre cycle de vie.
Validations industrielles 2026 : Anthropic formalise en mars 2026 le Context Engineering comme discipline à part entière — AIAD l’implémente opérationnellement depuis v1.3. Thoughtworks Radar 2026 identifie des concepts convergents (Context Engineering, Harness Engineering, Spec-Driven Development). R2Code (arXiv, avril 2026) valide empiriquement le spec-first : −41,7 % de tokens et +7,4 % de fidélité sur le code généré. Ces convergences ne sont pas des suivis — elles sont des validations indépendantes d’une approche antérieure.