La Dark Factory : Des Logiciels Où Aucun Humain N’Écrit ni Ne Relit le Code

Imaginez entrer dans une entreprise logicielle et qu’on vous dise deux choses : le code ne doit pas être écrit par des humains, et le code ne doit pas être relu par des humains. Pas « le code peut être assisté par IA » ou « les développeurs devraient tirer parti de l’automatisation ». Les règles sont absolues. Aucune main humaine ne touche le code. Aucun œil humain ne le parcourt. Ce n’est pas une expérience de pensée. C’est la réalité opérationnelle chez StrongDM, où une équipe de trois ingénieurs fait tourner ce qu’ils appellent une « software factory » — un système qui transforme des fichiers de spécification en markdown en logiciels de production sans aucune implémentation ni revue humaine nulle part dans le pipeline.

Le concept emprunte au secteur manufacturier. Une « dark factory » est une installation de production qui fonctionne les lumières éteintes parce qu’aucun humain n’est présent sur le plancher. Des robots construisent les produits. Des capteurs gèrent le contrôle qualité. Les humains conçoivent les produits et fixent les normes, mais le plancher d’usine lui-même est entièrement autonome. StrongDM a appliqué ce modèle au logiciel. Et les résultats ne sont pas théoriques — leur magasin de contextes IA, CXDB, fonctionne en production depuis des mois, construit entièrement par la factory.

Ce qui rend cela intéressant n’est pas seulement que ça fonctionne. C’est que cela révèle un framework de maturité pour le développement assisté par IA qui expose où se trouvent actuellement presque toutes les autres organisations logicielles — et le chemin qu’elles ont à parcourir.

Les Cinq Niveaux de Codage IA

Ben Shapiro, responsable engineering chez StrongDM, décrit cinq niveaux distincts de maturité dans le codage IA. Le framework est utile parce qu’il donne aux organisations un langage honnête pour évaluer où elles se trouvent réellement, plutôt que là où leurs supports marketing affirment être.

Niveau 1 : Autocomplétion. C’est GitHub Copilot dans sa forme originale. Tab, tab, tab. L’IA suggère la ligne suivante. Le développeur accepte ou refuse. Le workflow est fondamentalement inchangé — le développeur écrit toujours du code, juste un peu plus vite. La majeure partie de l’industrie a adopté ce niveau. C’est aussi là que la majeure partie de l’industrie s’est arrêtée.

Niveau 2 : Itération. Le développeur utilise l’IA comme partenaire conversationnel. Il décrit ce qu’il veut. L’IA génère un premier brouillon. Il l’affine à travers plusieurs échanges. Des outils comme Cursor, Windsurf et Claude Code opèrent à ce niveau. L’IA écrit des morceaux significatifs de fonctionnalité, mais l’humain reste l’architecte principal. Chaque ligne de code est encore relue par une personne. La majorité des développeurs utilisant activement des outils IA aujourd’hui opèrent ici.

Niveau 3 : Délégation. C’est là que la dynamique change. Le développeur confie à l’IA une fonctionnalité ou un module entier à construire, puis évalue la sortie dans son ensemble. Il ne lit pas chaque ligne. Il exécute le code, le teste, vérifie s’il atteint l’objectif. Le rôle de l’humain passe de rédacteur à évaluateur. Moins d’organisations opèrent ici qu’elles ne le prétendent.

Niveau 4 : Orchestration. Le développeur gère plusieurs agents IA travaillant en parallèle, chacun gérant différents composants du système. Le développeur écrit des spécifications, pas du code. Il conçoit des critères d’évaluation, pas des suites de tests. Le code lui-même est une boîte noire. S’il passe l’évaluation, son implémentation interne est sans importance. Ce niveau exige une confiance profonde — à la fois dans le système IA et dans la propre capacité du développeur à écrire des spécifications suffisamment précises pour produire une sortie fiable. Cette compétence de spécification est quelque chose que presque personne n’a encore bien développé.

Niveau 5 : La Dark Factory. Aucun humain n’écrit de code. Aucun humain ne relit de code. Des spécifications entrent. Un logiciel fonctionnel sort. La factory tourne de manière autonome. C’est le modèle opérationnel de StrongDM, et il représente l’extrémité d’un spectre que la plupart des organisations n’atteindront pas avant des années.

Le framework est important parce qu’il fournit une carte réaliste du terrain. La plupart des organisations se situent entre le niveau 1 et le niveau 3. La plupart pensent être plus avancées qu’elles ne le sont réellement. Et les écarts entre les niveaux ne sont pas incrémentaux — ils sont architecturaux.

Scénarios vs. Tests : La Distinction la Plus Importante Dont Personne ne Parle

Le système d’assurance qualité de la dark factory n’utilise pas de tests traditionnels. Il utilise ce que StrongDM appelle des « scénarios ». La distinction paraît sémantique. Elle est fondamentale.

Un scénario décrit un comportement attendu d’un point de vue externe. Il se lit comme un critère d’acceptation rédigé comme une histoire : « Si un utilisateur crée une ressource et qu’un admin l’approuve, alors l’utilisateur doit pouvoir accéder à cette ressource. » Un scénario capture ce que le logiciel doit faire du point de vue de quelqu’un qui l’utilise.

Un test est du code qui exerce directement des fonctions internes. Asserter que la fonction X renvoie Y quand on lui donne l’entrée Z. Un test valide la mécanique interne de l’implémentation.

La différence devient critique quand l’IA écrit à la fois le code et les tests — ce qu’elle fera, si on le lui permet. Quand un système IA génère le code puis génère des tests pour ce code, une boucle de rétroaction dangereuse émerge. L’IA optimise le code pour passer ses propres tests. Les tests sont écrits pour valider les propres hypothèses d’implémentation de l’IA. Le résultat est un code qui passe 100 % de sa suite de tests tout en échouant à faire ce que quiconque avait réellement besoin qu’il fasse.

C’est l’équivalent IA du « teaching to the test ». Un développeur humain écrivant une suite de tests apporte une compréhension indépendante de ce que le logiciel doit accomplir. Ses tests reflètent la compréhension humaine du problème, pas seulement la logique interne du code. Quand l’IA gère les deux côtés — implémentation et vérification — cette vérification indépendante disparaît sauf si l’architecture le prévient délibérément.

L’architecture de scénarios de StrongDM résout ce problème en plaçant les critères de validation entièrement en dehors du système d’implémentation. Les scénarios sont rédigés par des humains en langage courant. Ils décrivent un comportement observable de l’extérieur. L’IA ne peut pas les optimiser de la manière dont elle peut optimiser ses propres tests programmatiques, parce que les scénarios testent des résultats, pas des internaux. C’est une décision architecturale subtile mais critique, et c’est l’une des principales raisons pour lesquelles la dark factory produit des logiciels fiables plutôt que des logiciels qui paraissent seulement fiables.

L’Univers de Jumeaux Numériques

Le deuxième pilier de la dark factory est ce que StrongDM appelle leur « univers de jumeaux numériques » — des clones comportementaux de chaque service externe avec lequel le logiciel interagit. Un Okta simulé. Un Jira simulé. Un Slack simulé, un Google Docs simulé, un Google Drive simulé, un Google Sheets simulé. Les agents IA se développent contre ces jumeaux numériques, exécutant des scénarios de test d’intégration complets sans jamais toucher les systèmes de production réels, les APIs réelles ou les données réelles.

Ce n’est pas un environnement de staging standard. C’est un monde simulé conçu spécifiquement pour le développement logiciel autonome. Les jumeaux numériques ne se contentent pas de simuler des réponses API — ils simulent des patterns de comportement réalistes, des conditions d’erreur, des limites de débit et des cas limites que les services de production présentent. Les agents IA travaillent dans cet univers simulé comme s’ils travaillaient contre de vrais systèmes, et les scénarios valident le comportement à travers ces intégrations simulées.

Construire cette infrastructure est coûteux et chronophage. Elle exige une compréhension approfondie du comportement de chaque service externe, non seulement son chemin heureux mais ses modes de défaillance et ses particularités. Pour StrongDM, l’investissement était justifié parce que l’univers de jumeaux numériques permet quelque chose qui serait autrement impossible : un développement autonome contre des intégrations complexes avec zéro risque pour les systèmes de production. Mais pour la plupart des organisations, reproduire cette approche nécessiterait un investissement engineering significatif en infrastructure de simulation qui n’existe pas encore.

La Boucle Auto-référentielle

La dark factory n’est pas propre à StrongDM. Les exemples les plus frappants de développement logiciel autonome se produisent chez les entreprises IA elles-mêmes.

Anthropic a divulgué qu’environ 90 % du codebase de Claude Code a été écrit par Claude Code lui-même. L’agent a écrit l’agent. Le produit Codex d’OpenAI livre des fonctionnalités qui ont été entièrement construites par des agents Codex — le système se construit lui-même. Ce ne sont pas des affirmations marketing. Ce sont des réalités opérationnelles confirmées par plusieurs ingénieurs des deux entreprises.

Cela crée une boucle d’intelligence composée. À mesure que les modèles s’améliorent, le code qu’ils écrivent s’améliore. Un meilleur code produit de meilleurs outils. De meilleurs outils produisent un code encore meilleur. Chaque génération du système crée une version supérieure de lui-même. Et parce que ces entreprises vendent les produits mêmes qu’elles construisent avec ces produits, chaque amélioration améliore simultanément leur capacité de développement interne et leur offre commerciale.

C’est l’une des principales raisons pour lesquelles les entreprises IA sont tellement en avance sur tout le monde dans l’adoption de workflows de développement autonome. Elles utilisent leur produit pour construire leur produit. La boucle de rétroaction est directe, mesurable et s’accélère. Pour tout le monde, la courbe d’adoption est plus lente parce que la boucle de rétroaction est indirecte — les outils IA qu’ils utilisent sont construits par quelqu’un d’autre, et les améliorations qu’ils génèrent bénéficient à leurs propres produits plutôt qu’aux outils eux-mêmes.

Le Problème du Brownfield

Pour la plupart des entreprises, la dark factory n’est pas un point de départ. Elle ne peut pas l’être. Parce que la plupart des logiciels ne vivent pas dans un greenfield. Ils vivent dans un brownfield de code legacy, de dette technique, d’hypothèses non documentées et de connaissances institutionnelles qui n’existent que dans les têtes des gens.

StrongDM avait un avantage inhabituel : leur produit IA-natif, CXDB, a été construit spécialement pour le workflow de la dark factory dès le début. Pas de codebase legacy à gérer, pas de décennie de dette technique accumulée, pas d’hypothèses implicites codées dans du code qui précède l’ère IA.

La plupart des entreprises font face à une réalité différente. Des millions de lignes de code existant sans spécifications, sans scénarios et sans infrastructure de jumeaux numériques. Rétro-ingénierer le comportement existant — comprendre ce que le système fait réellement par opposition à ce qu’une documentation obsolète prétend qu’il fait — est la première et la plus difficile étape. Construire des suites de scénarios qui capturent le comportement réel, concevoir des environnements de simulation pour les intégrations externes, et passer progressivement d’un développement écrit par des humains à un développement piloté par spécification est un projet de plusieurs années.

C’est pourquoi la majeure partie de l’industrie restera entre le niveau 2 et le niveau 3 dans un avenir prévisible. Non pas parce que les modèles IA manquent de capacité. Non pas parce que les outils sont indisponibles. Mais parce que la transformation organisationnelle et architecturale requise pour passer de « l’humain écrit le code » à « la machine écrit le code » est massive. Elle exige de nouvelles approches d’assurance qualité (basées sur les scénarios plutôt que sur les tests), une nouvelle infrastructure de développement (jumeaux numériques et environnements de simulation), de nouvelles structures d’équipe (plus petites, axées sur la spécification plutôt que sur l’implémentation) et de nouvelles compétences (rédaction de spécifications, conception d’évaluation, pensée systémique).

Pourquoi Rédiger des Spécifications Est Plus Difficile qu’Écrire du Code

L’insight peut-être le plus contre-intuitif du modèle de la dark factory est que rédiger des spécifications est plus difficile qu’écrire du code. Cela va à l’encontre de l’instinct de la plupart des développeurs, qui voient le code comme la partie difficile et les exigences comme la partie facile.

Quand un développeur écrit du code, il reçoit un feedback immédiat. Il l’exécute. Ça marche ou non. Il voit l’erreur. Il la corrige. La boucle de rétroaction est serrée. L’ambiguïté dans sa pensée est exposée instantanément parce que le compilateur ou le runtime ne la tolère pas.

Quand un développeur rédige une spécification pour un système autonome, chaque ambiguïté devient un bug potentiel. Chaque omission devient une fonctionnalité manquante. Chaque hypothèse non exprimée devient une implémentation incorrecte. La spécification doit être suffisamment précise pour qu’un système IA — qui n’a pas de jugement humain sur « ce que le développeur voulait probablement dire » — puisse l’implémenter de manière fiable. Il n’y a pas de place pour le contexte implicite, les conventions non écrites ou le « vous voyez ce que je veux dire ».

Les fichiers de spécification de StrongDM sont des documents markdown détaillés et structurés qui décrivent exactement ce que le logiciel doit faire, comment il doit se comporter dans les cas limites et quelles contraintes il doit respecter. Rédiger ces documents exige une profondeur de pensée systémique que la plupart des organisations logicielles n’ont pas cultivée, parce qu’elles n’en ont jamais eu besoin. Quand des humains écrivent du code, ils portent le contexte dans leur tête. Quand l’IA écrit du code à partir d’une spécification, ce contexte doit être entièrement externalisé.

C’est le vrai goulot d’étranglement de la dark factory. Pas la capacité IA. Pas l’infrastructure. La qualité des spécifications. Et c’est une compétence que l’industrie n’a pas encore développée à l’échelle.

Les Implications Organisationnelles

L’équipe dark factory de StrongDM est composée de trois personnes. Trois. Pas de manager engineering — il n’y a rien à gérer. Pas de scrum master — il n’y a pas de sprints à coordonner. Pas de tech lead faisant des revues de code — aucun humain ne relit le code. Pas d’équipe QA — l’architecture de scénarios gère l’assurance qualité de manière autonome.

La totalité de la couche de coordination qui constitue le système d’exploitation d’une organisation logicielle moderne — standups, sprint planning, rétrospectives, dépendances inter-équipes, conflits de merge, revues de conception — n’existe pas. Non pas parce qu’elle a été éliminée comme mesure d’économie, mais parce qu’elle ne sert plus un objectif.

C’est un aperçu d’un changement structurel qui s’étend au-delà d’une seule entreprise. L’organisation engineering de 500 personnes de 2023 peut devenir l’organisation engineering de 50 personnes de 2027 — non pas parce que le logiciel est plus simple, mais parce que la charge de coordination et le travail d’implémentation ont tous deux été automatisés. Les personnes qui restent seront plus précieuses, mieux rémunérées et travailleront à un niveau d’abstraction plus élevé. Mais elles seront moins nombreuses.

La valeur du manager engineering passe de « coordonner l’équipe construisant la fonctionnalité » à « définir la spécification suffisamment clairement pour que les agents construisent la fonctionnalité ». La valeur du release manager passe de « coordonner le déploiement entre les équipes » à « concevoir les critères d’évaluation déterminant si la sortie d’agent est publiée ». Le rôle du scrum master devient difficile à justifier quand il n’y a pas de sprints. Les couches de coordination qui existent pour gérer des centaines d’ingénieurs construisant un produit peuvent être supprimées quand les agents font l’ingénierie.

Questions Fréquemment Posées

Sources et lectures complémentaires

• StrongDM Software Factory and Five Levels of AI Coding — Ben Shapiro Framework — Blog engineering StrongDM détaillant l’architecture dark factory et la méthodologie de développement piloté par spécification
• Anthropic Claude Code Best Practices — 90% AI-Written Codebase — L’équipe engineering d’Anthropic confirmant que le codebase de Claude Code est écrit à environ 90 % par Claude Code lui-même
• METR Study: AI Tools and Developer Productivity — Étude randomisée rigoureuse sur des développeurs open source expérimentés montrant un ralentissement de 19 % avec les outils IA sur des codebases familiers
• OpenAI Codex Documentation — Plateforme de développement logiciel autonome d’OpenAI, incluant des fonctionnalités construites entièrement par des agents Codex
• Brooks, F. P. (1975). The Mythical Man-Month — Texte classique d’ingénierie logicielle sur la surcharge de coordination
• Stack Overflow 2025 Developer Survey — AI Tools Adoption — Sondage industriel montrant une adoption de 84 % des outils IA mais une confiance en déclin