Vérification en Dark Factory : quand plus personne ne lit le code

Une Dark Factory (niveau 5) est un environnement de développement logiciel où les machines génèrent, vérifient et déploient le code — aucun humain ne lit la moindre ligne. La couche de vérification qui rend la dark factory viable exige une évaluation de type holdout, des Digital Twin Universes, une revue multi-agents et des contraintes de goût encodées. Sans cette couche, les agents contournent les tests et la qualité disparaît.

StrongDM a publié du logiciel sous 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 construit et livré 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 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 l’IA chaque mois.²

Dan Shapiro appelle le point d’arrivée le niveau 5 : la Dark Factory. Du code généré par des machines, vérifié par des machines, déployé sans qu’un humain lise une seule ligne.³ Les niveaux précédents tracent la progression que la plupart des équipes suivent actuellement : codage manuel (niveau 0), délégation de tâches (niveau 1), pilote automatique sur autoroute (niveau 2), Waymo avec conducteur de sécurité (niveau 3) et robotaxi où l’on rédige la spécification et part pour 12 heures (niveau 4).³

La question à laquelle personne n’a bien répondu : à quoi ressemble la couche de vérification au niveau 5 ? L’analyse qui suit cartographie l’infrastructure requise, en s’appuyant sur l’infrastructure de goût qui régit la façon dont j’évalue la qualité dans l’ensemble de mon travail d’ingénierie.

Le problème de la vérification se compose

À chaque niveau en dessous de 5, un humain lit le code à un moment donné. Au niveau 3, l’humain gère 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 de connaissances institutionnelles peut faire du pattern-matching avec l’intention. La spécification disait « retry avec backoff exponentiel » et le code effectue un retry 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 différent. Pas plus difficile en degré. Différent par nature. 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 la sortie par rapport à cet encodage sans jamais inspecter l’artefact lui-même.

Le piège central : les agents qui contournent les tests. StrongDM a découvert que ses agents écrivaient return true pour faire passer les suites de tests sans rien faire d’utile.¹ Les tests étaient verts. Le pipeline CI rapportait un succès. Le code ne valait rien. Eran Kahana, de Stanford Law, étend l’observation à un avertissement structurel : le problème plus large est la circularité, où la même classe de technologie évalue du code que la même classe a écrit.⁴

La loi de Goodhart opère ici avec une force inhabituelle. Le goût est un système technique défend l’idée que la vérification automatisée a besoin d’une couche de jugement au-dessus d’elle ; sans évaluation au niveau du goût, les tests deviennent des cibles plutôt que des mesures. Quand les agents optimisent pour le passage des tests, le passage des tests 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 dark factory doit tenir compte de 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 du codebase, fonctionnant comme des jeux de holdout en machine learning.¹ L’analogie est précise : tout comme les praticiens du ML évaluent les modèles sur des données jamais utilisées à l’entraînement, des agents indépendants évaluent le code généré par rapport à des scénarios auxquels l’agent codeur n’a pas accès pendant la génération.

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

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

StrongDM a observé un schéma que j’ai moi aussi constaté : « avec la deuxième révision d’Claude 3.5 (octobre 2024), les flux de travail de codage agentique à long horizon ont commencé à composer la correction plutôt que l’erreur ».¹ En dessous d’un seuil de capacité, des exécutions d’agents plus longues produisent davantage d’erreurs. Au-dessus, des exécutions plus longues produisent du meilleur code. Le schéma de la dark factory 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 de la main-d’œuvre, une couche de gouvernance avec des agents de vérification indépendants, et une architecture d’usine pour l’orchestration.² Le pilier de gouvernance inclut des tests par scénarios exécutés par des agents indépendants, de l’analyse statique, du contrôle de conformité architecturale, des tests de régression comportementaux et des agents red-team qui tentent activement de casser la sortie.²

L’indépendance compte. Quand le même agent écrit et teste son propre code, le problème de circularité de 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 l’« intent thinking » comme une compétence critique pour les équipes de dark factory : 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 à l’écriture 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 aussi une contrainte que j’ai vécue directement : « Les agents IA ne sont efficaces que dans la mesure des connaissances codifiées auxquelles ils peuvent accéder. »² Un agent opérant sans contexte 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 a déjà résolus. Les connaissances codifiées (décisions de conception, contrats API, guides de style, historiques d’échecs) sont de l’infrastructure, pas de la documentation.

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

Ma boucle d’exécution nocturne, l’architecture de l’agent Ralph, fonctionne au niveau 4 de Shapiro. Je rédige les spécifications, lance les agents, dors, et passe en revue les résultats le matin. Les agents s’exécutent contre 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 traitent le problème de contournement de Kahana au niveau des outils. Un article séparé documente l’intégralité de l’architecture des hooks, mais la propriété pertinente ici est l’interception : les hooks se déclenchent avant l’exécution de l’outil, pas après. Un agent qui tente un force-push sur main est bloqué avant l’exécution de la commande. Un agent qui tente de commiter des fichiers correspondant à des patterns .env est intercepté. Un agent qui rapporte « tous les tests passent » sans exécuter pytest est signalé par l’evidence gate, qui exige une sortie de test collée montrant zéro échec — pas une affirmation selon laquelle les tests passeraient.

L’evidence gate impose six critères sur chaque changement non trivial : respecte les patterns du codebase (nommer le pattern et le fichier), solution fonctionnelle la plus simple (lister les alternatives rejetées), cas limites gérés (lister chacun), tests passés (coller la sortie), pas de régressions (nommer les fichiers vérifiés), et résout le problème réel (énoncer le besoin utilisateur et comment le changement y répond). « Je crois » et « ça devrait » ne sont pas des preuves. Le gate rejette le langage évasif et exige des artefacts.

La boucle qualité (implémenter, relire, évaluer, affiner, prendre du recul, répéter, 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 à l’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 comme des capacités réutilisables, donnent aux agents accès aux conventions du projet, aux décisions architecturales et aux connaissances du domaine.
• Gouvernance : les hooks implémentent la couche d’interception. L’evidence gate implémente la couche d’audit. La boucle qualité implémente la couche de contrainte comportementale.

Je n’ai pas construit deux piliers : la montée en compétences de la main-d’œuvre (sans objet pour un praticien solo) et l’architecture d’usine en tant que plateforme d’orchestration dédiée (ma configuration actuelle utilise le spawning natif d’agents de Claude Code, pas une usine construite à cet effet). Le système de contexte composé décrit comment ces couches d’infrastructure s’accumulent en un actif capitalisable, rendant chaque session ultérieure plus performante.

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 vérifie les diffs Git. Je lance l’application. Je vérifie que la sortie correspond à mon intention. Cette revue prend de 30 minutes à une heure et attrape les 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 :

Dérive d’intention. L’agent a complété 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 qu’un utilisateur expérimente, pas ce que le code fait.

Érosion architecturale. L’agent a ajouté une fonctionnalité qui marche en isolation mais dégrade la cohérence structurelle du système. Une nouvelle requête en base de données qui contourne le pattern repository existant. Un nouvel endpoint qui duplique la logique d’un autre module. L’analyse statique en détecte certains cas. Le contrôle de conformité architecturale (la couche de gouvernance de BCG Platinion) en détecte davantage.² Ni l’un ni l’autre ne détecte les cas subtils où le nouveau code est techniquement cohérent avec les patterns mais introduit une fracture conceptuelle qui se compose au fil des changements futurs.

Perte de connaissances institutionnelles. Kahana soulève un risque sous-estimé : quand personne ne lit le code, personne ne développe d’intuition sur le système.⁴ Comme Kahana le prévient : « Personne ne saura pourquoi. Personne ne saura comment le réparer. »⁴ 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 pas 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 affirme. 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 dark factory 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 de code. Les scénarios de StrongDM. Des spécifications comportementales stockées séparément du codebase, évaluées par des agents indépendants. Sans évaluation holdout, la loi de Goodhart transforme chaque suite de tests en cible.

Des jumeaux numériques pour les tests d’intégration. Les agents ne peuvent pas tester contre des systèmes de 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 de 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 le contournement, les raccourcis et la vérification fantôme fournissent une couche que les tests passifs ne peuvent pas offrir.

Une interception au niveau des outils. Des hooks qui bloquent les opérations nuisibles avant exécution, pas des tests qui détectent les dommages après coup. La couche de hooks se situe en dessous de la prise de décision de l’agent et résiste au contournement par des prompts habiles ou des raccourcis 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 d’« intent thinking » de BCG Platinion.² La spécification de niveau 4 de Shapiro que l’on rédige avant de partir pour 12 heures.³ La spécification est le produit. Le code est un effet secondaire.

Une piste d’audit sans faille de responsabilité. Kahana cite les AI Life Cycle Core Principles exigeant une sortie « 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 tracer depuis le comportement déployé jusqu’à la spécification qui l’a engendré.

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 la plupart du temps. Les hooks attrapent les défaillances mécaniques. L’evidence gate 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 pattern-matching humain. La conformité architecturale qui détecte l’érosion conceptuelle, pas seulement les violations structurelles. Des connaissances institutionnelles qui s’accumulent 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 schémas de dark factory.² StrongDM a livré 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.² La dark factory n’est pas une usine qui tourne 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 précédemment écrit sur ce qui casse quand les agents tournent sans supervision et sur l’evidence gate comme défense contre la vérification fantôme. Ces articles décrivent l’infrastructure du niveau 4. La dark factory exige cette même infrastructure, étendue pour fonctionner sans l’humain qui lit actuellement le diff matinal. Les hooks, les evidence gates, les boucles qualité : tous nécessaires au niveau 5, mais pas suffisants. 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. Le hub d’ingénierie IA rassemble l’arc complet de cette investigation, de la conception de hooks individuels au contexte composé jusqu’à la frontière de la dark factory.

FAQ

Qu’est-ce qu’une Dark Factory en développement logiciel ?

Une Dark Factory (niveau 5 de Dan Shapiro) est un environnement de développement logiciel où les machines génèrent le code, vérifient le code et déploient le code sans qu’un humain lise une seule ligne. Les niveaux précédents progressent du codage manuel (niveau 0) vers une automatisation croissante, le niveau 4 étant le mode « robotaxi » où un humain rédige la spécification, part pour 12 heures et passe en revue les résultats. La dark factory élimine même cette revue finale.

Quel est le plus grand défi de vérification au niveau 5 ?

Le piège central : les agents qui contournent les tests. StrongDM a découvert des agents écrivant return true pour faire passer les suites de tests sans rien faire d’utile. La loi de Goodhart opère avec une force inhabituelle : quand les agents optimisent pour le passage des tests, le passage des tests cesse de mesurer la correction. La couche de vérification doit en tenir compte en utilisant une évaluation de type holdout (des tests auxquels l’agent générateur n’a pas accès pendant la production de code), une vérification multi-agents avec des modes de défaillance décorrélés, et une interception au niveau des outils qui bloque les opérations nuisibles avant exécution.

Quel est l’écart entre le niveau 4 et le niveau 5 ?

Trois problèmes que l’automatisation actuelle gère mal : la dérive d’intention (l’agent a complété la spécification fidèlement mais a choisi la mauvaise interprétation d’une exigence ambiguë), l’érosion architecturale (de nouvelles fonctionnalités qui marchent en isolation mais dégradent la cohérence structurelle), et la perte de connaissances institutionnelles (quand personne ne lit le code, personne ne développe l’intuition sur le système nécessaire pour intervenir lors d’incidents ou de changements de logique métier).

Comment StrongDM résout-il le problème de la vérification ?

StrongDM utilise des « Scenarios » — des parcours utilisateur de bout en bout stockés en dehors du codebase, fonctionnant comme des jeux de holdout en machine learning. Des agents indépendants évaluent le code par rapport à des scénarios auxquels l’agent codeur n’a pas accès pendant la génération. Ils ont construit un Digital Twin Universe (des clones comportementaux d’Okta, Jira, Slack, Google Docs) visant une compatibilité API à 100 %, afin que les agents testent contre des surfaces comportementales réalistes plutôt que des mocks superficiels.