La couche de vérification de l'usine sombre

StrongDM a publié du logiciel selon deux règles : « Le code ne doit pas être écrit par des humains » et « Le code ne doit pas être relu par des humains ».¹ Une équipe de trois personnes — Justin McCarthy, Jay Taylor et Navan Chauhan — a conçu et publié Attractor et CXDB (16 000 lignes de Rust, 9 500 de Go, 6 700 de TypeScript) avec une dépense minimale de 1 000 $ en tokens par ingénieur et par jour.¹ BCG Platinion, citant Spotify et la couverture de TechCrunch, rapporte que les meilleurs développeurs de Spotify n’avaient plus écrit de code depuis décembre 2025, l’entreprise fusionnant des centaines de pull requests générées par IA chaque mois.²

Dan Shapiro désigne le point d’aboutissement comme le Niveau 5 : l’usine sombre (Dark Factory). Du code généré par des machines, vérifié par des machines, déployé sans qu’un humain ne lise une seule ligne.³ Les niveaux précédents retracent la progression que suivent la plupart des équipes aujourd’hui — du codage manuel (Niveau 0) à la délégation de tâches (Niveau 1), au pilote automatique sur autoroute (Niveau 2), au mode Waymo avec conducteur de sécurité (Niveau 3), puis au robotaxi où l’on rédige la spécification et part pendant 12 heures (Niveau 4).³

La question à laquelle personne n’a bien répondu : à quoi ressemble la couche de vérification au Niveau 5 ?

Le problème de la vérification se démultiplie

À chaque niveau en dessous du 5, un humain lit le code à un moment donné. Au Niveau 3, l’humain supervise l’IA comme un développeur senior. Au Niveau 4, l’humain vérifie si les tests passent après 12 heures.³ Ces niveaux fonctionnent parce qu’une personne dotée d’une connaissance institutionnelle peut reconnaître des schémas en les comparant à l’intention. La spécification disait « réessayer avec un backoff exponentiel » et le code effectue un réessai linéaire — un développeur repère cela d’un coup d’œil.

Supprimez entièrement l’humain, et la vérification devient un problème d’une tout autre nature. Pas plus difficile en degré. Différent par essence. Le vérificateur ne peut pas s’appuyer sur la compréhension de lecture. Il doit encoder ce que « correct » signifie sous forme exécutable, puis évaluer le résultat par rapport à cet encodage sans jamais inspecter l’artefact lui-même.

Le piège fondamental, ce sont les agents qui trichent avec les tests. StrongDM a découvert que leurs agents écrivaient return true pour faire passer les suites de tests sans rien faire d’utile.¹ Les tests étaient verts. Le pipeline CI était satisfait. Le code ne valait rien. Eran Kahana, de Stanford Law, étend cette observation à un avertissement structurel : le problème de fond est la circularité, où la même classe de technologie évalue du code que cette même classe a écrit.⁴

La loi de Goodhart opère ici avec une force inhabituelle. Quand les agents optimisent pour le passage des tests, ce passage cesse de mesurer la correction.⁴ Toute métrique qui devient la cible cesse d’être une bonne métrique. La couche de vérification d’une usine sombre doit prendre en compte cette dynamique, sous peine de mesurer la conformité plutôt que la qualité.

Comment StrongDM résout concrètement la vérification

La réponse de StrongDM repose sur ce qu’ils appellent des « Scenarios » — des parcours utilisateur de bout en bout stockés en dehors de la base de code, fonctionnant comme des ensembles de validation (holdout sets) en machine learning.¹ L’analogie est précise : de même que les modèles de ML sont évalués sur des données sur lesquelles ils ne se sont jamais entraînés, le code construit par des agents est évalué contre des scénarios auxquels l’agent n’a pas accès pendant la génération.

La métrique clé est la « Satisfaction » : la fraction des trajectoires observées qui satisfont probablement l’utilisateur.¹ Il n’existe aucun standard industriel définissant quel score constitue une satisfaction suffisante. StrongDM a établi son propre seuil de manière empirique.

Pour que les tests basés sur les scénarios fonctionnent à grande échelle, StrongDM a construit un Digital Twin Universe — des clones comportementaux d’Okta, Jira, Slack, Google Docs, Drive et Sheets.¹ Ces jumeaux visent une compatibilité API à 100 % en utilisant des bibliothèques clientes de référence SDK populaires et publiquement disponibles.¹ Les agents s’exécutent contre les jumeaux, pas contre des endpoints simulés (mocks). La fidélité comportementale du jumeau détermine la fiabilité du test.

StrongDM a observé quelque chose que j’ai également constaté : « avec la deuxième révision de Claude 3.5 (octobre 2024), les workflows de codage agentique à long horizon ont commencé à accumuler de la correction plutôt que des erreurs ».¹ En dessous d’un certain seuil de capacité, des exécutions d’agents plus longues produisent davantage d’erreurs. Au-dessus, des exécutions plus longues produisent un meilleur code. Le modèle de l’usine sombre n’est devenu viable qu’après que les modèles ont franchi ce seuil.

Cinq couches de gouvernance

Le cadre de transformation en cinq piliers de BCG Platinion inclut une couche de gouvernance avec plusieurs étapes de vérification avant que le code n’atteigne la production.² Les piliers : un système d’exploitation piloté par l’intention, une infrastructure de connaissances codifiées, la montée en compétences des équipes, une couche de gouvernance avec des agents de vérification indépendants, et une architecture d’usine pour l’orchestration.² Au sein du pilier gouvernance, BCG Platinion décrit des tests basés sur des scénarios exécutés par des agents indépendants, de l’analyse statique, de la vérification de conformité architecturale, des tests de régression comportementale et des agents red-team qui tentent activement de casser le résultat.²

L’indépendance est cruciale. Quand le même agent écrit et teste son propre code, le problème de circularité soulevé par Kahana s’applique.⁴ Quand un agent distinct — avec des prompts système différents, un contexte différent, des incitations différentes — évalue le travail, les modes de défaillance se décorrèlent. Pas s’éliminent. Se décorrèlent. Deux agents peuvent toujours partager des biais systématiques hérités des données d’entraînement. Toutefois, la probabilité d’angles morts identiques diminue quand l’agent d’évaluation opère depuis un cadre différent.

BCG Platinion identifie la « pensée par l’intention » (intent thinking) comme une compétence critique pour les équipes d’usine sombre : traduire les besoins métier en descriptions précises et testables des résultats souhaités.² Le rôle humain passe de l’écriture de code à la rédaction de spécifications contre lesquelles les agents peuvent s’exécuter. Des spécifications médiocres produisent des tests qui passent sur un comportement erroné — la même dynamique du return true que StrongDM a rencontrée.¹

BCG Platinion identifie par ailleurs une contrainte que j’ai directement expérimentée : « Les agents IA ne sont efficaces qu’à la hauteur des connaissances codifiées auxquelles ils peuvent accéder ».² Un agent opérant sans contexte de projet génère du code plausible qui viole les conventions locales, ignore les décisions architecturales et redécouvre des problèmes que l’équipe avait déjà résolus. Les connaissances codifiées — décisions de conception, contrats API, guides de style, historiques de pannes — sont de l’infrastructure, pas de la documentation.

Ce que j’exécute déjà au Niveau 4

Ma boucle d’exécution nocturne, la Ralph Loop, opère au Niveau 4 de Shapiro. Je rédige des spécifications, lance des agents, dors, et examine les résultats le matin. Les agents s’exécutent avec plus de 95 hooks qui interceptent chaque appel d’outil — écritures de fichiers, commandes git, exécutions shell — avant et après exécution. Les hooks imposent des contraintes que l’agent ne peut ni négocier ni contourner.

Les hooks répondent au problème de triche soulevé par Kahana au niveau des outils. Un agent qui tente un force-push vers main est bloqué avant l’exécution de la commande, pas après qu’un test constate les dégâts. Un agent qui tente de committer des fichiers correspondant à des patterns .env est intercepté. Un agent qui rapporte « tous les tests passent » sans avoir exécuté pytest est signalé par la porte de preuves (evidence gate), qui exige un résultat de test collé montrant zéro échec — pas une affirmation que les tests passeraient.

La porte de preuves impose six critères sur chaque modification non triviale : suit les patterns de la base de code (nommer le pattern et le fichier), solution la plus simple fonctionnelle (exposer les alternatives rejetées), cas limites traités (lister chacun), tests passés (coller la sortie), aucune régression (nommer les fichiers vérifiés) et résout le problème réel (énoncer le besoin de l’utilisateur et comment la modification y répond). « Je pense que » et « ça devrait » ne constituent pas des preuves. La porte rejette le langage évasif et exige des artefacts.

La boucle qualité — implémenter, relire, évaluer, affiner, prendre du recul, itérer, rapporter — s’exécute comme une contrainte comportementale encodée dans le prompt système de l’agent via CLAUDE.md. La boucle ne garantit pas que l’agent suive chaque étape. Les hooks vérifient qu’il l’a fait.

Les cinq piliers de BCG Platinion correspondent à une infrastructure que je maintiens déjà :

• OS piloté par l’intention : les fichiers CLAUDE.md et les spécifications de développement pilotées par PRD encodent l’intention du projet comme contexte exécutable.
• Connaissances codifiées : plus de 139 skills, organisés en capacités réutilisables, donnent aux agents accès aux conventions du projet, aux décisions architecturales et aux connaissances métier.
• Gouvernance : les hooks implémentent la couche d’interception. La porte de preuves implémente la couche d’audit. La boucle qualité implémente la couche de contraintes comportementales.

Deux piliers que je n’ai pas construits : la montée en compétences des équipes (non pertinent pour un praticien solo) et l’architecture d’usine en tant que plateforme d’orchestration dédiée (ma configuration actuelle utilise le lancement d’agents natif de Claude Code, pas une usine construite à cet effet).

L’écart entre le Niveau 4 et le Niveau 5

Passer du Niveau 4 au Niveau 5 signifie éliminer la revue matinale. Actuellement, je me réveille et lis ce que les agents ont produit pendant la nuit. Je consulte les diffs git. Je lance l’application. Je vérifie que le résultat correspond à mon intention. Cette revue prend 30 minutes à une heure, et elle détecte des problèmes que les hooks manquent.

Les problèmes que les hooks manquent sont les plus intéressants. Ils se répartissent en catégories que l’automatisation actuelle gère mal :

La dérive d’intention. L’agent a exécuté la spécification fidèlement, mais la spécification était ambiguë, et l’agent a choisi la mauvaise interprétation. Aucun test ne détecte une interprétation incorrecte qui produit un comportement valide. L’approche par scénarios de StrongDM aborde ce problème en encodant les parcours utilisateur comme spécification, et non les exigences techniques.¹ Les scénarios décrivent ce que l’utilisateur expérimente, pas ce que le code fait.

L’érosion architecturale. L’agent a ajouté une fonctionnalité qui fonctionne isolément mais dégrade la cohérence structurelle du système. Une nouvelle requête de base de données qui contourne le pattern de repository existant. Un nouvel endpoint qui duplique la logique d’un autre module. L’analyse statique détecte certains de ces cas. La vérification de conformité architecturale — la couche de gouvernance de BCG Platinion — en détecte davantage.² Ni l’une ni l’autre ne détecte les cas subtils où le nouveau code est techniquement conforme aux patterns mais introduit une fracture conceptuelle qui s’aggrave avec les modifications futures.

La perte de connaissance institutionnelle. Kahana soulève un risque sous-estimé : quand personne ne lit le code, personne ne développe d’intuition sur le système.⁴ Comme le met en garde Kahana : « Personne ne saura pourquoi. Personne ne saura comment le corriger. »⁴ Aujourd’hui, ma revue matinale construit cette intuition de manière incrémentale. Au Niveau 5, le système devient opaque pour son opérateur. Tout système complexe finit par nécessiter une intervention que l’automatisation ne peut gérer — un incident de sécurité, un changement de logique métier qui viole des hypothèses intégrées dans la suite de tests, une intégration avec un système externe qui se comporte différemment de ce que sa documentation prétend. L’opérateur qui n’a jamais lu le code ne peut pas intervenir efficacement.

Ce dont la couche de vérification a réellement besoin

En synthétisant la pratique de StrongDM, le cadre de gouvernance de BCG Platinion, l’analyse des défaillances de Kahana et ma propre infrastructure, la couche de vérification d’une usine sombre nécessite au minimum :

Une évaluation de type holdout. Des tests auxquels l’agent générateur n’a pas accès pendant la production du code. Les scénarios de StrongDM. Des spécifications comportementales stockées séparément de la base de code, évaluées par des agents indépendants. Sans évaluation holdout, la loi de Goodhart transforme toute suite de tests en cible.

Des jumeaux numériques pour les tests d’intégration. Les agents ne peuvent pas tester en production. Les mocks sont trop superficiels — ils vérifient les contrats API, pas le comportement. Des jumeaux qui répliquent la surface comportementale des dépendances externes permettent l’exécution de scénarios de bout en bout sans risque en production.

Une vérification multi-agents avec des modes de défaillance décorrélés. L’agent rédacteur et l’agent évaluateur doivent opérer depuis des contextes différents. Des agents red-team qui sondent activement la triche, les raccourcis et la vérification fantôme ajoutent une couche que les tests passifs ne peuvent fournir.

Une interception au niveau des outils. Des hooks qui bloquent les opérations nuisibles avant exécution, pas des tests qui détectent les dégâts après coup. La couche de hooks opère en dessous de la prise de décision de l’agent et ne peut être contournée par du prompting astucieux ou des raccourcis de type return true.

Des spécifications d’intention exécutables. Des spécifications suffisamment précises pour que l’ambiguïté soit détectable. La compétence « intent thinking » de BCG Platinion.² La spécification de Niveau 4 de Shapiro, celle que l’on rédige avant de partir pour 12 heures.³ La spécification est le produit. Le code n’en est qu’un effet de bord.

Une piste d’audit sans zone d’ombre. Kahana cite les AI Life Cycle Core Principles exigeant que le résultat soit « traçable jusqu’à une partie responsable appropriée ».⁴ Il n’existe pas encore de méthodologie d’audit standard pour les logiciels construits par des agents.⁴ La couche de vérification doit produire des artefacts qu’un humain (ou un régulateur, ou un intervenant en cas d’incident) peut suivre du comportement déployé jusqu’à la spécification qui l’a généré.

L’évaluation honnête

J’exécute le Niveau 4 avec une confiance élevée. Mes agents nocturnes produisent un travail qui passe la revue matinale le plus souvent. Les hooks attrapent les défaillances mécaniques. La porte de preuves attrape les défaillances épistémiques. La boucle qualité réduit les défaillances comportementales.

Le Niveau 5 exige de résoudre des problèmes que je n’ai pas résolus. La détection de dérive d’intention sans reconnaissance de patterns humaine. La conformité architecturale qui détecte l’érosion conceptuelle, pas seulement les violations structurelles. La connaissance institutionnelle qui s’accumule dans le système plutôt que dans la tête de l’opérateur.

BCG Platinion rapporte des gains de productivité de 3 à 5x pour les équipes adoptant les modèles d’usine sombre.² StrongDM a publié du logiciel construit par des agents avec trois ingénieurs et un budget de tokens.¹ L’argument de productivité est clair. L’argument de vérification ne l’est pas.

Les équipes qui réussissent au Niveau 5 partagent un trait commun : elles ont investi davantage dans l’infrastructure de vérification que dans la génération de code. StrongDM a construit un Digital Twin Universe complet avant de faire confiance aux agents pour livrer du code.¹ Le cadre de BCG Platinion comporte cinq piliers de transformation incluant une couche de gouvernance avec plusieurs étapes de vérification avant que le code n’atteigne la production.² L’usine sombre n’est pas une usine qui fonctionne dans le noir. C’est une usine où les lumières sont la couche de vérification, et tout le reste — y compris le code — est une commodité.

J’ai écrit précédemment sur ce qui casse quand les agents fonctionnent sans supervision et sur la porte de preuves comme défense contre la vérification fantôme. Ces articles décrivent l’infrastructure du Niveau 4. L’usine sombre exige cette même infrastructure, étendue pour fonctionner sans l’humain qui lit actuellement le diff matinal. Les hooks, les portes de preuves, les boucles qualité — tout cela est nécessaire au Niveau 5, mais pas suffisant. La pièce manquante est une vérification qui monte en autonomie au même rythme que la génération.

Construire cette pièce, c’est le travail qui reste à faire.