En 2026, une équipe d'entreprise a créé un agent qui lisait les tickets de gestion des incidents, générait des analyses post-mortem à partir de ceux-ci et créait automatiquement des éléments de réparation. Un deuxième agent de la même équipe surveillait les nouveaux éléments de travail et ouvrait des projets de PR pour chacun afin d'aider les développeurs à démarrer. Un développeur a examiné l'un de ces PR, l'a trouvé raisonnable, l'a approuvé et l'a fusionné avec la branche principale.

**Le problème était que le changement était entièrement fabriqué.**

L’agent avait inventé une solution apparemment plausible à un problème qui n’existait pas de la manière décrite. Le changement a fait régresser un scénario de production réel. Un vrai client l'a remarqué. Il y a eu une panne.

C'est pour cela que la Constitution EDD existe.

La constitution est un fichier unique qui régit chaque modification non triviale de la base de code. Il définit à quoi ressemble un changement terminé, quelles preuves il doit contenir, ce qu'un audit limité doit couvrir et comment les règles elles-mêmes peuvent évoluer. Chaque agent et chaque humain qui touche le dépôt le charge à chaque session. La barre ne fait que monter.

Cet article parcourt la constitution étape par étape : l'incident qui l'a motivée, la question de conception à laquelle elle répond, comment elle est structurée, comment elle a été écrite (et ce que nous nous sommes trompés au début), comment fonctionnent les amendements et comment le kit complet se déploie dans un nouveau dépôt.

Étape 1 - Qu'est-ce que c'est

L’incident est l’illustration la plus claire possible du mode de défaillance qu’EDD est censé empêcher. L’agent n’a pas halluciné par hasard. Il a produit un PR cohérent, lisible et formaté professionnellement. Le développeur qui l'a examiné a fait ce que font les développeurs : il a lu l'intention, a trouvé l'intention plausible et a approuvé. L'écart n'était pas l'attention. La lacune était l’absence de preuve. Rien dans le processus d'examen n'obligeait l'agent à démontrer que le problème qu'il prétendait résoudre existait réellement, que le correctif concernait un comportement réel ou que le changement n'avait rien régressé.

EDD répond à cette lacune avec une seule exigence stricte : si l’agent ne peut pas le prouver, la tâche n’est pas accomplie. La preuve n'est pas un résumé. La preuve n'est pas une affirmation de confiance. La preuve est un artefact qui peut être vérifié de manière indépendante : un test échoué, une sortie de scanner, une capture d'écran avant/après, une différence de plan. Le PR porte l'artefact ou le PR est incomplet.

La constitution se trouve dans `docs/methodology/CONSTITUTION.md`. Chaque agent IA configuré sur le projet le charge à chaque session via son propre fichier de chargement. Le corps est neutre en termes d'agent : pas de noms d'outils, pas de syntaxe spécifique à la plate-forme. Il définit neuf principes fondamentaux, des contraintes strictes avec des ID de slug stables, la boucle de mise en œuvre en 10 étapes, les dimensions de l'audit, les critères d'acceptation des preuves par type de changement, les exclusions triviales pour les travaux à faible risque et la clause d'amendement.

Chaque contrainte matérielle a un slug comme `[HC-EVIDENCE-BEFORE]` et déclare trois choses : la barre (ce qui doit être vrai), la vérification (comment l'adhésion est vérifiée) et la source du modèle (quel fichier d'instructions élabore les conseils d'implémentation).

La boucle en 10 étapes est le cœur opérationnel : définir la réalisation, rédiger un test qui prouve l'écart, le regarder échouer, capturer les preuves préalables, mettre en œuvre, surveiller la réussite du test, capturer les preuves après, vérifier les documents, auditer les dimensions déclarées, puis examen humain. Les étapes 1 à 4 ont lieu avant toute modification d'implémentation. Cet ordre est constitutionnel car cet incident montre exactement ce qui se passe quand ce n’est pas le cas.

Comme garantie supplémentaire, EDD emprunte un principe fondamental à TDD : il faut prouver que le scénario échoue avant que les travaux ne commencent. Une preuve qui réussit à la fin d'un changement n'est pas une preuve suffisante en soi : si le test a également réussi avant le changement, l'agent peut avoir réparé quelque chose qui n'a jamais été brisé. Il s’agit d’un mode d’échec spécifique dans les flux de travail assistés par l’IA : un agent génère un correctif qui semble plausible, la vérification s’avère satisfaisante et le changement est expédié comme s’il résolvait un problème réel. Exiger un état de défaillance documenté avant le début de la mise en œuvre comble cette lacune. L’étape préalable aux preuves n’est pas seulement une base de comparaison : c’est la preuve que le problème à résoudre était réel.

Parmi toutes les contraintes strictes qui ont été imposées dans la constitution, deux ont détecté plus de défauts que toutes les autres réunies, et elles constituent sans doute la mise à niveau la plus importante apportée par EDD à tout flux de travail assisté par l'IA : « [HC-EVIDENCE] » et « [HC-EVIDENCE-INTEGRITY] ». Les deux sont déclarés dans `.github/copilot-instructions.md` - le fichier chargé avec impatience qui se trouve dans le contexte de l'agent à chaque session.

`[HC-EVIDENCE]` exige que chaque PR contienne des artefacts avant et après réels - pas des descriptions de ce que les artefacts montreraient, pas des résumés de ce que l'agent pense s'être produit, mais le résultat brut. « [HC-EVIDENCE-INTEGRITY] » va plus loin : il exige que les preuves contenues dans le PR puissent être retracées jusqu'au travail qui a été réellement effectué. Il valide que le PR contient ce qu'il prétend contenir.

Ensemble, ces deux contraintes ont détecté des centaines de bogues générés par l’IA avant qu’ils ne soient examinés. Le mode d’échec contre lequel ils se prémunissent n’est pas une hallucination au sens évident du terme. Il s'agit d'un comportement plus subtil : l'agent marque une tâche comme terminée, rédige une description de relations publiques confiante et inclut ce qui se lit comme une preuve - mais la preuve a été composée et non capturée. L'agent a décrit à quoi devrait ressembler le résultat plutôt que d'exécuter la commande et d'inclure le résultat réel.

`[HC-EVIDENCE-INTEGRITY]` est particulièrement efficace pour détecter ce que l'on pourrait appeler le modèle « Je ne pouvais pas faire ça ». Un agent confronté à une tâche difficile ou inconnue prétendra parfois que la tâche est impossible ou hors de portée plutôt que de la tenter. La revendication est souvent formulée comme une limitation : un outil qui n'existe pas, une contrainte qui empêche la démarche, un environnement qui ne supporte pas l'opération. « [HC-EVIDENCE-INTEGRITY] fait ressortir ceci : si l'agent prétend qu'une tâche n'a pas pu être effectuée, le PR doit montrer la preuve que la tâche a été véritablement tentée et que l'obstacle est réel. "Je n'ai pas pu exécuter la suite de tests" nécessite une sortie de terminal montrant l'échec, et non une déclaration indiquant que l'échec s'est produit. Sans cette exigence, l'évitement par l'agent d'un travail difficile est invisible au moment de la révision et la tâche est livrée incomplète comme si elle avait été effectuée.

Étape 2 - Comment nous en sommes arrivés là

La Constitution n’est pas une accumulation de leçons apprises. C’est la réponse à une question de conception posée au début : comment forcer un agent d’IA à prouver son travail à chaque fois, d’une manière qui ne soit pas contournable et ne dépende pas du fait qu’un humain se souvienne de la question ?

Répondre à cette question a forcé une décomposition. La preuve nécessite de savoir à quoi ressemble la réalisation avant le début de la mise en œuvre - ce qui a produit l'étape de documentation. La preuve nécessite un test qui échoue avant le changement et réussit après - ce qui a produit la discipline de test d'échec/réussite. La preuve nécessite un état préalable qui a été capturé avant que la mise en œuvre ne touche quoi que ce soit - qui a produit l'exigence de preuve préalable. La preuve nécessite un audit indépendant qui détecte ce que les preuves par changement ne peuvent pas détecter - et qui a produit les dimensions de l'audit. Et la preuve doit survivre au processus de révision sans être adoucie - ce qui a produit la dure contrainte selon laquelle l'examinateur humain est la porte finale et la seule qui ne peut pas être automatisée.

Le résultat est la boucle en 10 étapes. Chaque étape existe parce que sa suppression crée un trou par lequel peut passer un travail non prouvé. La boucle n'est pas une liste de contrôle. C'est une chaîne causale.

À partir de là, la question est devenue : quelles catégories d’échecs un agent peut-il produire et que la boucle ne détecte pas par défaut ? Cela a produit des contraintes strictes. Les peluches de sécurité restant silencieuses pendant que les règles étaient dégradées ont produit `[HC-SECURITY-LINT]`. Un échec de codage de caractères dans un artefact déployé a produit `[HC-ASCII-PUNCT]`. Chaque HC clôture une classe de défaillance spécifique avec une vérification automatisée spécifique. Les règles qui ne pouvaient pas nommer une vérification ont été refusées : si une vérification ne peut pas être automatisée, la règle est ambitieuse et non constitutionnelle.

La dernière question de conception était la suivante : qui gouverne la constitution elle-même ? La réponse est le cliquet. La Constitution ne peut que devenir plus stricte. Les amendements doivent apporter la preuve que le comportement des agents s’améliore ou se maintient. Le sol ne descend jamais. Cela signifie que l’on peut faire confiance à la Constitution au fil du temps, ce qu’un guide de style de vie ne peut pas faire : chaque version est strictement plus forte que la précédente.

Étape 3 - Comment il est structuré

La constitution suit une architecture à trois niveaux.

**Couche 1 : Le corps canonique.** Un fichier, `docs/methodology/CONSTITUTION.md`. C'est la source de la vérité. Il est neutre quant à l’agent : il ne fait aucune hypothèse sur l’outil d’IA utilisé. Il définit les principes, les contraintes strictes, la boucle, les dimensions de l'audit, les critères d'acceptation des preuves, les exclusions de trivialité et la clause d'auto-amélioration. Lorsque le corps dépasse environ 250 lignes, les règles qui s'appliquent à un modèle de chemin spécifique sont prises en compte dans des fichiers de portée chemin, avec un pointeur d'une ligne laissé dans le corps.

**Couche 2 : chargeurs d'agent.** Chaque agent configuré reçoit exactement un fichier de chargeur à l'emplacement que l'agent charge avec impatience. Pour GitHub Copilot, il s'agit de « .github/copilot-instructions.md ». Pour Claude, c'est `CLAUDE.md`. Le chargeur importe ou intègre le corps de constitution en fonction de ce que la plate-forme prend actuellement en charge. Le chargeur est rendu mécaniquement à partir du corps canonique ; il n’est pas édité à la main. Si un projet utilise trois outils d'IA, il existe trois fichiers de chargement, tous restituant le même contenu constitutionnel.

**Couche 3 : règles limitées au chemin.** Certaines règles s'appliquent uniquement à des types de fichiers spécifiques. Les règles d'accessibilité et de localisation s'appliquent aux fichiers JSX et CSS, et non aux modèles d'infrastructure. Ces règles résident dans des fichiers d'instructions avec un global de front :

L'agent charge ces fichiers uniquement lorsqu'il touche un chemin correspondant. Cela maintient le budget de contexte de chargement rapide serré (règles de base toujours présentes, règles spécialisées chargées à la demande) et empêche les conseils d'accessibilité de faire surface sur une modification de modèle Bicep.

Les fichiers de support complètent la structure : les corps de commande `/constitute` dans `.github/prompts/`, les dossiers par fonctionnalité dans `docs/methodology/features/`, les scénarios d'évaluation dans `docs/methodology/eval/scenarios/` et `verify-sequence.yaml` à la racine du dépôt qui définit l'ordre des portes CI.

Étape 4 - Comment nous l'avons écrit

**Le contexte est tout. Ce qui n'est pas dans son contexte est mort pour l'agent.**

Il s’agit de l’idée la plus importante concernant la rédaction d’une constitution pour un développement régi par l’IA. Une règle qui existe dans un fichier que l'agent ne charge jamais n'existe pas. Une contrainte matérielle enfouie dans un document qui ne se charge que lorsqu'un chemin de fichier spécifique est touché n'est une contrainte matérielle pour aucun autre chemin. La constitution doit toujours être dans son contexte, et tout ce qui doit toujours s'appliquer doit y vivre.

Cela conduit à trois décisions de rédaction :

**L'optimisation des jetons n'est pas négociable.** Le corps canonique cible moins de 300 lignes et 8 000 jetons. Chaque amendement doit maintenir ou améliorer l’efficacité symbolique – les règles verbeuses qui accomplissent ce que peuvent faire des règles laconiques sont rejetées pour ces seules raisons. Ce n’est pas une préférence de style. C'est une contrainte de charge. Si la constitution dépasse le budget, les agents dans des fenêtres contextuelles plus petites commencent à la tronquer, et les règles tronquées ne sont pas des règles.

**Chargement conditionnel via frontmatter.** Les règles qui s'appliquent uniquement à des types de fichiers spécifiques sont extraites du corps canonique et dans des fichiers d'instructions de portée chemin avec une déclaration globale frontmatter. Les conseils d’accessibilité et de localisation se chargent uniquement lorsque l’agent touche JSX ou CSS. Le guidage de l'infrastructure se charge uniquement lorsque l'agent touche Bicep. Le corps canonique conserve un pointeur sur une seule ligne. L'agent charge le fichier limité au chemin uniquement lorsque cela est pertinent. Il ne s'agit pas seulement d'efficacité : cela empêche les conseils d'accessibilité de apparaître comme une distraction lors d'une modification de l'infrastructure, ce qui entraîne l'agent à les ignorer.

Ce projet n'utilise pas de fichiers de règles séparés par front-matter, car la constitution est suffisamment petite pour être chargée entièrement en contexte : un seul développeur, une portée ciblée, un ensemble de règles allégé. Pour les grandes équipes, le calcul change. Un projet à l'échelle de l'entreprise qui exécute actuellement EDD comporte 75 contraintes strictes en matière de sécurité, de conformité, d'accessibilité et d'exigences spécifiques à la plate-forme. Intégrer les 75 fichiers dans un seul fichier à chargement rapide pousserait la constitution bien au-delà du budget contextuel de la plupart des agents. La division Frontmatter maintient le corps canonique sous 250 lignes - un pointeur récapitulatif par domaine - et charge paresseusement les détails complets de la règle uniquement lorsque l'agent touche les chemins correspondants. La constitution reste rapide et légère. Les règles restent complètes. Le coût du jeton reste limité.

**Les amendements comme unités de changement.** Un amendement constitutionnel n'est pas un changement de mot dans un fichier de démarque. Il s'agit d'un ensemble de trois artefacts : le delta exact de la règle, le mécanisme de vérification qui détectera les violations futures et un scénario d'évaluation comportementale qui prouve que le comportement de l'agent s'améliore. Tous les trois sont expédiés ensemble dans le même PR. L’amendement est atomique. Les amendements partiels qui promettent d'ajouter la vérification plus tard sont rejetés - plus tard n'arrive pas, et une règle invérifiable est la décoration.

**Écrivez les évaluations et les rubriques avant de penser que vous en avez besoin.** L'évaluation est le cliquet. Sans cela, les amendements sont acceptés de bonne foi et la Constitution dérive. La rubrique évalue le comportement des agents sur des scénarios réalistes. Chaque nouvelle règle produit au moins un scénario. La rubrique produit un score numérique. L'amendement n'est adopté que si le score de l'arbre de travail atteint ou dépasse la ligne de base.

**Documentez ce que vous pouvez et ne pouvez pas couvrir. Ne vous mentez pas à propos de la couverture.**

Dès le début, la contrainte stricte d'accessibilité a déclaré que les nouvelles surfaces d'interface utilisateur interactives nécessitaient une couverture e2e a11y à l'aide d'axe-core. Cela semblait complet. En pratique, c'était naïf. axe-core gère un sous-ensemble significatif de WCAG - il détecte les étiquettes manquantes, la structure des points de repère, l'ordre de mise au point et le contraste dans les cas où le DOM est entièrement rendu et les couleurs sont résolues. Il ne détecte pas la logique d'annonce du lecteur d'écran, les modèles de charge cognitive, les contrats de clavier de widgets complexes ou les problèmes de contraste impliquant des dégradés et des nœuds d'image SVG où la couleur calculée ne peut pas être résolue.

Avoir `[HC-A11Y-GATE]` avec axe-core dans la vérification ne signifie pas que tous les bugs sont nuls. Cela signifie que l'ensemble de règles axe-core spécifique s'exécute sur le DOM rendu. La différence est extrêmement importante dans les réclamations de couverture PR.

Le correctif était la décomposition. Au lieu de « axe-core clean », la vérification a été réécrite pour énumérer les critères de réussite WCAG couverts de manière déterministe par l'ensemble de règles axe-core (1.1.1 pour le contenu non textuel, 1.3.1 pour les informations et les relations, 1.4.3 pour le contraste lorsqu'il est résoluble, 4.1.2 pour le nom/rôle/valeur) et qui n'ont aucune couverture automatisée (1.3.3 caractéristiques sensorielles, 2.4.6 sémantique des titres et des étiquettes, tous 3.x Critères compréhensibles). La section des lacunes connues de la dimension d'audit indique désormais explicitement : axe-core gère ces critères ; une analyse manuelle est requise pour ceux-ci. Les évaluateurs des relations publiques voient la couverture réelle, et non un résumé de fausse confiance.

Le principe plus large : pour chaque vérification, documenter ce qu’elle détecte et ce qu’elle ne détecte pas. "Les peluches de sécurité passent" ne signifie pas que la base de code est sécurisée. "axe-core clean" ne signifie pas conforme aux WCAG 2.2 AA. Nommez l’écart. Enregistrez-le dans la dimension d'audit. Nécessite une numérisation manuelle de la surface de l'espace. Ne laissez pas le contrôle automatisé se substituer au jugement humain qu’il ne peut pas remplacer.

Étape 5 - Comment nous rédigeons les amendements

Les amendements ne commencent presque jamais par des propositions d’amendement. Ils commencent comme des bugs.

Un bug fait surface. Le correctif est appliqué. Avant l'expédition, « /reflect » pose une question : s'agit-il d'un cas isolé, ou manque-t-il quelque chose dans la constitution qui aurait attrapé cette classe d'échec ? Si la réponse est ponctuelle, le correctif est livré et c'est la fin. Si la réponse est qu'il manque quelque chose, c'est alors que `/constitute` est invoqué.

**Le chemin /reflect -> écart -> modification.** `/reflect` examine le correctif et le classe : écart de constitution (aucune règle ne couvrait cette classe d'échec) ou écart de vérification (une règle existait mais aucun contrôle automatisé ne l'appliquait). Les deux routes mènent à « /constitute ». Un vide constitutionnel produit un nouveau HC. Une lacune dans la vérification produit une vérification plus stricte sur un HC existant - généralement une nouvelle sous-section de dimension d'audit, une nouvelle règle d'analyse ou un nouveau scénario d'évaluation.

**Les trois artefacts requis.** `/constitute` refuse de procéder sans les trois dans le même PR :

• **Règle delta.** Le changement de texte exact, classé : nouvelle règle, formulation modifiée, déplacement (remplacer et supprimer l'ancienne), remplacement (élever la barre avec l'ancienne comme plancher) ou déplacement. Les doublons sont rejetés à vue.
• **Mécanisme de vérification.** La porte spécifique qui détectera une violation future : un nom de test, un ID de règle de charpie, une sous-section de dimension d'audit, une vérification du code de sortie du scanner ou un scénario d'évaluation comportementale. Il doit exister au moment de la validation. Les règles sans violations détectables sont décoratives.
• **Scénario d'évaluation.** Stocké dans `docs/methodology/eval/scenarios/<id>.md`. Décrit une situation réaliste dans laquelle l'ancienne règle produit un mauvais comportement d'agent et la nouvelle règle produit la bonne réponse pouvant être notée.

**Le cliquet.** Une fois les trois artefacts approuvés, la modification est appliquée à une succursale. L'évaluation s'exécute sur les règles de la branche principale et les règles de l'arbre de travail. La rubrique note les deux. Pass nécessite un arbre de travail >= main sur chaque scénario. La régression bloque l'amendement jusqu'à ce que le libellé soit corrigé. Le cliquet n’est pas facultatif pour les modifications évidentes : elles peuvent toujours produire des régressions subtiles, et l’évaluation est le seul mécanisme qui les détecte avant qu’elles n’atteignent.

**Le balayage rétroactif.** Un amendement fixe immédiatement la règle pour le nouveau code : la portée différentielle de `/audit` signifie que le nouveau travail répond à la nouvelle barre à partir du moment où l'amendement arrive. Le code préexistant qui viole la nouvelle règle est traité par un PR de balayage distinct mis en file d'attente via `/rollout`. Le site de correctifs n'a pas besoin de réparer chaque instance préexistante en ligne. Cela rendrait les amendements d’un coût prohibitif. Au lieu de cela : le nouveau code rencontre immédiatement la nouvelle barre, l'ancien code est dans la file d'attente de déploiement et le PR de balayage apporte sa propre preuve que les instances préexistantes sont résolues.

Les quatre déclencheurs valides pour `/constitute` sont : un bug, un incident, une autopsie et une nouvelle norme contractuelle. Les propositions sous la forme « nous devrions probablement... » sans aucun des quatre déclencheurs sont refusées et acheminées vers « /reflect » à la place.

Étape 6 - Comment nous le déployons

Le kit de méthodologie portable (`EDD - Portable Methodology Kit.md`) est un document autonome que vous remettez à n'importe quel agent IA avec l'instruction d'exécuter `/begin`. L'agent inspecte le dépôt, exécute une passe de découverte, confirme les valeurs détectées avec vous dans un seul tableau, demande uniquement à quoi la découverte ne peut pas répondre et émet l'échafaudage minimum viable pour votre projet. Une session pour mettre en place l'infrastructure complète d'EDD.

La façon dont vous le déploierez dépend entièrement du fait que vous repartiez à zéro ou que vous l'intégriez dans une base de code existante. Les deux voies sont suffisamment différentes pour être traitées séparément.

**Greenfield.** Sur un nouveau projet, inscrivez toutes les règles auxquelles vous pouvez penser dans la constitution dès le premier jour. Vous n'avez aucun code préexistant à auditer, aucune pratique d'équipe à protéger, aucun PR existant à conserver. Le coût de la rigueur dès le premier jour est presque nul. Ajoutez toutes les contraintes strictes, toutes les dimensions d'audit, toutes les règles de portée du chemin. Exécutez ensuite la boucle. Ce que vous découvrirez rapidement, c'est là où la constitution crée des frictions : des délais de construction qui s'envolent parce que chaque changement déclenche un audit complet, des suites de tests qui sont lentes parce que la barre de couverture est trop élevée pour la complexité actuelle, des budgets symboliques qui sont serrés parce que le corps canonique est trop verbeux. La rigueur du premier jour fait apparaître ces problèmes dans le développement, pas dans la production. Ensuite, vous optimisez : resserrez les barrières de construction, ajustez les règles de couverture, réduisez le corps constitutionnel à son minimum. Vous stabilisez tout d’un coup, sans aucun client affecté, aucune équipe perturbée. Le coût à court terme est un premier sprint légèrement plus lent. Le gain à long terme est une constitution qui a été testée dès le premier engagement.

**Brownfield.** Une base de code existante a une équipe existante, des pratiques existantes et des PR existants qui n'ont pas suivi EDD. Le déploiement ici est progressif et doit être additif et non perturbateur. L'objectif du premier mois n'est pas de moderniser toutes les décisions passées - il est de commencer à générer les garanties qui rendent EDD digne de confiance : une dimension d'audit qui détecte quelque chose de réel, une contrainte stricte qui automatise une vérification que l'équipe effectuait déjà manuellement, un cycle de modification de bout en bout. Utiliser les signaux de qualité existants de l’équipe comme matière première. Si l'équipe a déjà une règle de charpie pour la sécurité, ajoutez « [HC-SECURITY-LINT] » et pointez-la vers la porte existante - rien ne change pour les développeurs, mais maintenant le dossier constitutionnel reflète ce que la porte applique réellement.

La règle cardinale en matière de friches industrielles est la suivante : gagner des alliés avant de gagner des arguments. Ne proposez pas une constitution complète qui touche tous les domaines de la base de code au cours de la première semaine. Commencez par la dimension qui intéresse déjà l'équipe le plus : généralement la sécurité ou la fiabilité. Montrer que le processus d’amendement comble une véritable lacune qu’ils ont déjà constatée. Laissez le cliquet s'assembler à partir de là. Une équipe qui a vu EDD détecter un véritable bug qui s'est glissé dans son processus existant fera de la place pour la règle suivante. Une équipe qui rencontre EDD comme un document qui lui indique qu'elle a tout fait de travers, le contournera.

**Ce que cela débloque.** La raison pour laquelle il faut procéder au déploiement, qu'il s'agisse d'une nouvelle ou d'une friche industrielle, n'est pas le document constitutionnel. C’est ce que permet la Constitution une fois que le mécanisme de vérification est en marche.

La qualité du code de production et la vitesse de livraison se combinent d’une manière véritablement contre-intuitive si vous ne l’avez pas vu. Les ingénieurs arrêtent le changement de contexte pour déboguer les régressions que la boucle aurait détectées. Les cycles d'examen sont raccourcis parce que les PR contiennent des preuves plutôt que des explications. L'audit s'exécute automatiquement et signale les problèmes qui auraient été détectés par l'examinateur le plus expérimenté, permettant ainsi à cet évaluateur de se concentrer sur les décisions architecturales qui nécessitent réellement son jugement.

La preuve la plus claire de cela : un nouvel ingénieur rejoignant l'équipe, avec un accès complet à la constitution, aux spécifications des fonctionnalités et à la boucle, peut apporter une contribution aux fonctionnalités de qualité production enregistrée dans le main dans les 48 heures suivant son premier jour. Pas un changement de jouet. Pas une mise à jour de la documentation. Une vraie fonctionnalité, avec des preuves, qui a passé l'audit complet. Ce n’est pas un hasard et ce n’est pas un ingénieur particulièrement inhabituel. Les garde-fous permettent à tout développeur qualifié de fonctionner selon les normes de qualité de l'équipe dès le premier jour, car les normes de qualité sont écrites, vérifiables et appliquées automatiquement plutôt que conservées comme une connaissance institutionnelle dans la tête de celui qui existe depuis le plus longtemps.

Voilà la forme que cela prend : une équipe où l'IA effectue le travail de vérification, les garde-corps détectent les classes de défaillance qui autrement échapperaient à la révision du code, et les ingénieurs consacrent leur temps à réfléchir aux problèmes qui nécessitent réellement un jugement technique.

Cela a été vérifié à différentes échelles : projets individuels d’abord, puis équipes de taille moyenne, puis organisations à l’échelle de l’entreprise. La mécanique tient dans les trois. Le coût de déploiement est différent (un développeur solo peut ignorer les registres d'exigences et les examens contradictoires entre fournisseurs ; une équipe d'entreprise en a besoin). La cadence de modification est différente (un projet solo peut prendre des semaines entre les invocations « /constitute » ; une équipe d'entreprise avec plusieurs agents contributeurs les exécute chaque semaine). Mais la boucle centrale, le cliquet et l’exigence de preuves se comportent de la même manière quelle que soit la taille de l’équipe. Le niveau de qualité ne fait qu'augmenter, et les machines de vérification le maintiennent là sans dépendre de celui qui se trouve être l'évaluateur le plus expérimenté dans la salle cette semaine-là.

Crochets IA

La constitution régit le comportement des agents à travers un contexte chargé. Les hooks l'appliquent au moment de l'action, avant que le travail ne soit déjà terminé et qu'un PR soit déjà ouvert. Sans hooks, une violation est détectée lors de l'examen : l'agent a déjà écrit le code, le PR existe et le corriger signifie refaire le travail. Avec les hooks, l’interception se produit avant toute frappe.

**Claude Code et GitHub Copilot exécutent tous deux un hook lors de la soumission de l'invite.** Lorsqu'une nouvelle tâche arrive, le hook se déclenche avant que l'agent ne fasse quoi que ce soit. Son travail : vérifier si la tâche n'est pas triviale, puis recâbler la liste des tâches dans la boucle `/wow` - la séquence EDD en 10 étapes que l'agent doit suivre avant d'expédier quoi que ce soit.

Un agent qui atteint l'étape 5 sans terminer les étapes 1 à 4 a violé la boucle. Le hook établit la séquence au début de la session - pas après coup.

**Claude Code** déclenche en outre un hook pré-appel d'outil avant toute écriture de fichier, commande de terminal ou opération git. Une validation ne peut pas être tentée si les étapes de la boucle n'ont pas été satisfaites.

**GitHub Copilot** déclenche en outre un hook de création de relations publiques. Avant que la description du PR ne soit finalisée, le hook exécute `/audit` en mode d'auto-révision - détectant les violations de dimension, les preuves manquantes et les plans de test vides avant qu'un réviseur humain ne voie le brouillon. Ce qui parvient au critique est déjà présélectionné.

**Le Codex et d'autres agents** n'ont pas de surface de crochet native au moment d'écrire ces lignes. La solution de secours est un robot observateur CI qui commente les PR immédiatement après leur création et signale les violations. Il s'agit d'un filet de sécurité, pas d'une porte de première surface - le travail est déjà fait au moment où il se déclenche, donc cela n'empêche pas la reprise que les crochets éliminent.

Sur un projet avec des hooks actifs, les violations sont corrigées en ligne pendant la session. L’agent comble l’écart, produit les preuves et les inclut dès le début. Examinez les baisses de temps. La retouche disparaît. La constitution passe d'un document que l'agent lit à une contrainte à l'intérieur de laquelle l'agent opère en temps réel.

Annexe - La Constitution complète

Ce qui suit est le véritable « CONSTITUTION.md » de ce projet - un projet de développement à développeur unique, entièrement autonome et assisté par l'IA. Il régit chaque modification non triviale apportée à cette base de code. Ceci n'est pas un modèle ou une illustration. Il s'agit du document en direct chargé par chaque agent à chaque session.