Quand Robert C. Martin — surnommé "Uncle Bob" — a publié qu'il ne lit pas le code généré par l'IA, des milliers de développeurs ont réagi en moins de vingt-quatre heures. Son raisonnement est aussi simple que radical : "Je ne relis pas le code pour la même raison que je ne relis pas le binaire produit par le compilateur. J'ai appris à faire confiance, dans certaines limites, au résultat d'une IA correctement contrainte."
Ce n'est pas de la paresse. C'est une posture d'ingénierie construite sur des principes, forgée au fil de mois de travail avec des agents de codage IA — et elle s'accompagne d'une méthodologie rigoureuse appelée Disciplined Agentic Engineering (DAE).
L'analogie du compilateur
À la fin des années 1970, Uncle Bob devait écrire un filtre de correction pour un compilateur bogué — vérifiant la sortie assembleur ligne par ligne. Au fil des décennies, l'industrie a bâti suffisamment de confiance envers les compilateurs pour cesser de lire le binaire. Cette confiance a été gagnée grâce aux tests, à la vérification formelle et à l'accumulation de preuves.
Les générateurs de code IA occupent aujourd'hui la même position que les compilateurs en 1979. Il ne faut pas leur faire confiance aveuglément — mais il ne faut pas non plus inspecter manuellement chaque fonction qu'ils produisent. La voie à suivre est identique : construire un gauntlet de tests qui remplace la revue manuelle.
Uncle Bob le formule clairement : "Quand j'ai commencé à utiliser l'IA, je vérifiiais le code avec soin. Mais au fil des semaines et des mois, j'ai appris à lui faire confiance dans certaines limites. J'ai identifié les circonstances où cette confiance est justifiée, et celles où des contraintes supplémentaires sont nécessaires. Même chanson. Jour différent."
Les deux flux de tests
Le fondement de DAE est deux flux de tests indépendants, rédigés avant tout code de production :
Flux 1 — Tests d'acceptance (Gherkin) Rédigés en collaboration entre l'ingénieur humain et l'IA, en utilisant la syntaxe Given/When/Then de Gherkin. Ces tests constituent le contrat comportemental du système, exprimé en langage métier. L'IA n'a pas le droit de modifier les tests d'acceptance sans autorisation explicite.
Flux 2 — Tests unitaires Rédigés entièrement par l'IA. Ils valident le comportement interne et les détails d'implémentation.
Pourquoi deux flux ? Devoir satisfaire deux perspectives indépendantes empêche le modèle d'écrire du code qui passe uniquement les tests qu'il se souvient avoir rédigés. Les deux flux incitent l'IA à réfléchir plus profondément à la structure du code.
Le pipeline en 8 points de contrôle
La communauté a formalisé l'approche d'Uncle Bob en un pipeline à 8 étapes :
Point 0 — Charte et amorçage du projet. Définir les règles non négociables : style de code, patterns interdits, exigences de sécurité. La charte est un contrat en lecture seule que l'IA ne peut pas modifier.
Point 1.5 — Périmètre et niveau d'autonomie. Chaque fonctionnalité reçoit un niveau d'autonomie explicite, de serré (l'ingénieur valide chaque décision) à lâche (l'IA progresse de façon autonome). Les chemins sensibles en matière de sécurité sont par défaut en mode serré.
Point 2 — Découverte des critères d'acceptance. L'ingénieur et l'IA explorent ensemble les cas limites, les modes de défaillance et les règles métier. Résultat : une liste structurée de critères testables.
Point 3 — Spécification Gherkin. Les critères deviennent des scénarios Given/When/Then. Une règle critique s'applique ici : la prévention des fuites d'implémentation. Les spécifications doivent utiliser uniquement le langage métier. Écrire "POST to /api/users" est rejeté au profit de "l'utilisateur s'inscrit avec son email". Cela empêche les détails d'implémentation de polluer la couche de spécification.
Point 4 — Planification architecturale. L'IA propose une conception validée par rapport à la charte. Les ingénieurs examinent l'architecture, pas le code.
Point 5 — Implémentation. L'IA écrit simultanément le code de production et les tests unitaires contre les scénarios Gherkin. Les deux flux doivent réussir avant de continuer.
Point 6 — Revue tri-dimensionnelle. Vérifications automatisées des opportunités de réutilisation, des métriques de qualité et de l'efficacité. Aucun regard humain sur le code tant qu'une dimension ne signale pas d'anomalie.
Point 7 — Conformité architecturale et analyse des risques de changement. L'implémentation a-t-elle dévié du design convenu ? Introduit-elle un couplage inattendu ?
Point 8 — Mutation testing différentiel. L'innovation clé : seules les fonctions dont le code, les tests couvrants ou les opérateurs de mutation ont changé depuis la dernière exécution sont ré-mutées. Cela rend le mutation testing assez rapide pour tourner à chaque commit.
Pourquoi le mutation testing change tout
La couverture de code indique quelles lignes ont été exécutées. Le mutation testing indique si vos tests peuvent réellement détecter des bugs.
Un mutant est une petite modification du code de production — inverser un opérateur de comparaison, supprimer une vérification null, changer une valeur de retour. Si votre suite de tests ne détecte pas le mutant, les tests ne valident pas ce comportement.
Quand vous ne lisez pas le code généré par l'IA, le mutation testing devient votre principal indicateur de qualité. Le pipeline DAE utilise la mutation différentielle — en mettant en cache les résultats et en ne re-testant que ce qui a changé — ce qui maintient la boucle de feedback en dessous de trente secondes pour la plupart des bases de code.
Quand lire quand même le code IA
La règle "ne lisez pas" a des limites explicites :
- En début de nouveau contexte, avant que la confiance soit établie
- Les chemins critiques en matière de sécurité (auditez-les toujours manuellement)
- Quand un test échoue d'une façon impossible à diagnostiquer depuis la sortie du test seule
- Quand vous travaillez sur des systèmes aux conséquences réelles (contrôle matériel, transactions financières)
La règle est : confiance gagnée par les contraintes, révoquée quand les contraintes échouent.
Étapes pratiques pour adopter DAE
Commencez par Gherkin. Avant de demander quoi que ce soit à l'IA, rédigez trois à cinq scénarios Gherkin pour la fonctionnalité. Utilisez un répertoire features/ et un runner Cucumber simple.
Interdisez les détails d'implémentation dans les specs. Relisez chaque critère : s'il mentionne un nom de table, un chemin d'endpoint ou un nom de classe, supprimez-le. La spec doit se lire comme une exigence produit, pas comme un design technique.
Ajoutez le mutation testing. Pour JavaScript/TypeScript, utilisez Stryker ; pour Python, utilisez mutmut. Commencez par un seul module et étendez progressivement. Suivez le score de mutation comme métrique de build.
Définissez votre charte. Un fichier texte listant ce que l'IA peut et ne peut pas faire — dépendances qu'elle ne peut pas ajouter, patterns qu'elle doit respecter, fichiers qu'elle ne peut pas modifier. Référencez-la au début de chaque session.
Définissez les niveaux d'autonomie explicitement. Avant chaque fonctionnalité, décidez : serré (vous validez l'architecture), moyen (vous validez les tests), ou lâche (l'IA progresse de bout en bout). Annoncez-le à l'IA en début de session.
Le dépôt disciplined-agentic-engineering sur GitHub formalise ces points de contrôle dans un workflow compatible Claude Code avec des scripts de hook et des validateurs de checkpoint.
La vision globale
L'ère du "vibe coding" a introduit des millions de développeurs à la programmation assistée par IA. DAE en est la correction : non pas un retour au tout manuel, mais un cadre structuré où les ingénieurs possèdent la couche de spécification pendant que l'IA possède la couche d'implémentation.
L'analogie d'Uncle Bob avec le compilateur est historiquement précise. L'industrie a mis trente ans à apprendre à faire confiance aux compilateurs. Elle mettra bien moins de temps à apprendre à faire confiance à l'IA, parce que nous savons déjà à quoi ressemble un gauntlet de tests efficace.
La question n'est pas de savoir si vous devez lire le code généré par l'IA. La question est de savoir si vos tests sont assez bons pour que vous n'ayez pas besoin de le faire.