Douze pull requests fusionnées pendant la nuit. La suite de tests est verte. Le déploiement est parti à 04h12 sans réveiller personne. Quand l’équipe se connecte, le travail est en production et sert du trafic.

Personne ne l’a lu. Non pas « personne n’a eu le temps » : personne n’était censé le faire. Aucun relecteur n’est assigné, parce que la chaîne n’en prévoit pas. Un agent a planifié le travail, un agent l’a écrit, un second agent l’a contrôlé, et ce sont les tests qui ont décidé de la mise en production.

C’est le niveau 5. Dan Shapiro l’a baptisé la dark factory, du nom de ces lignes de production qui tournent lumières éteintes parce que rien, sur place, n’a besoin de voir. Simon Willison, en écrivant sur ce modèle en janvier, a ajouté le détail qui le fait passer de l’expérience de pensée à la pratique : il connaît une petite équipe qui fonctionne ainsi aujourd’hui. Aucune revue de code. Un poids considérable mis sur les tests. Des humains occupés uniquement à la conception du système.

Reste une question, qui vaut bien un article. Si aucun humain ne lit le code, à partir de quoi ce code est-il écrit ?

La capacité est arrivée en premier

Il vaut la peine d’être précis sur ce qui a changé, parce que « les modèles se sont améliorés » est vrai et inutile. Trois choses précises se sont produites, et une seule relève vraiment de l’intelligence.

Le contexte est devenu assez grand pour contenir le problème. Il n’y a pas si longtemps, on donnait une fonction à un modèle en espérant. Une seule session contient aujourd’hui le document d’architecture, les modules touchés par un changement, la suite de tests, la sortie en échec et toute la conversation à son sujet, simultanément. Une grande partie de ce qui passait pour de la bêtise du modèle était un modèle raisonnant avec assurance sur du code qu’on ne lui avait jamais montré.

La mémoire persiste entre les sessions. Les agents ne recommencent plus chaque tâche amnésiques. La recherche dans l’historique d’un projet, ses décisions et ses travaux antérieurs fait que ce qui travaille mardi sait ce qui s’est passé lundi, et pourquoi.

Les longues chaînes d’outils ont cessé de s’effondrer. C’est celle qui a compté. Modifier, lancer les tests, lire l’échec, formuler une hypothèse, corriger, relancer — trente ou quarante étapes de profondeur sans perdre le fil. C’est toute la différence entre un générateur de code et quelque chose qu’on peut laisser seul avec une tâche.

Ensemble, ces trois évolutions ont transformé un tour de passe-passe en organisation de travail. Mais remarquez bien ce qu’elles ont fait, et ce qu’elles n’ont pas fait. Elles ont levé la contrainte de capacité. Elles n’ont pas dit à l’agent à quoi sert votre système.

Une fenêtre de contexte plus grande, c’est un appétit plus grand

Un million de tokens, ce n’est pas de la connaissance. C’est de la place pour de la connaissance. Le modèle la remplira avec ce que votre dépôt peut fournir, puis agira sur ce résultat avec une confiance totale.

Alors si vos décisions d’architecture vivent dans un fil Slack de 2024 ; si « on n’appelle jamais ce service directement » est quelque chose que quatre personnes savent et que personne n’a écrit ; si vos critères d’acceptation étaient une conversation en salle de réunion — la fenêtre de contexte ne vous sauve pas. Elle met la supposition à l’échelle, et elle la met à l’échelle pendant la nuit, en parallèle, sur chaque tâche.

C’est l’inversion au cœur de la dark factory, et elle est rarement présentée ainsi parce que les démonstrations sont plus amusantes à raconter. Pendant trente ans, la documentation a été une politesse faite aux humains futurs : la première chose sacrifiée quand l’échéance approche, parce que le code était l’artefact réel et les documents un commentaire à son sujet.

Inversez maintenant chacun de ces termes. La spécification est ce que l’agent compile. Le document d’architecture est ce qui contraint la conception. Les règles du projet sont le linter des arbitrages qu’aucun linter ne peut attraper. Les tests sont le seul oracle qui reste debout une fois la revue disparue.

La documentation a cessé d’être un commentaire pour devenir l’entrée.

Situez-vous honnêtement

Le modèle de Shapiro emprunte les niveaux d’autonomie de la conduite automatisée, ce qui le rend utile pour exactement une chose : une réponse honnête à la question de savoir où vous en êtes réellement.

Niveau	Nom	À quoi cela ressemble
N0	Autocomplétion pimentée	Le Copilot d’origine, ou du copier-coller depuis une fenêtre de chat.
N1	Le stagiaire	Du code répétitif et sans enjeu, tout est relu.
N2	Le développeur junior	Programmation en binôme avec le modèle, chaque ligne encore lue.
N3	Le développeur	L’essentiel du code est généré ; vous êtes devenu relecteur à plein temps.
N4	L’équipe d’ingénierie	Vous collaborez sur les spécifications et les plans. Les agents exécutent.
N5	La dark factory	Aucun humain n’écrit le code. Aucun humain ne le relit non plus.

La plupart des équipes avec qui j’échange sont au N3 et se décrivent au N4. Cet écart mérite d’être nommé, car les exigences changent brutalement d’un côté à l’autre. Au N3, l’humain est encore l’oracle — la dernière ligne de défense est une personne qui lit. À partir du N4, ce sont les artefacts qui font office d’oracle. Tout ce qui suit est une question de qualité de vos écrits.

La revue de code, c’était quatre métiers dans une même réunion

Retirer la revue donne l’impression de retirer un point de contrôle. C’est faux. C’est retirer quatre contrôles distincts qui partageaient la même interface. Chacun doit être relogé quelque part, et si vous ne choisissez pas où, la réponse est nulle part.

Le métier	Comment la revue s’en chargeait	Où il doit vivre désormais
Exactitude	Un second regard sur la logique, attrapant ce que l’auteur ne voyait pas.	Des critères d’acceptation écrits dans la spécification avant le début du travail, et un oracle de test assez solide pour les porter — rejeu de scénarios, invariants, analyse statique, fitness functions dans la chaîne.
Cohérence de conception	« Ce n’est pas comme ça qu’on fait ici », livré dans un fil de commentaires.	Des règles de projet que l’agent lit avant d’écrire. `AGENTS.md` et ses cousins, encodant des contraintes actives plutôt qu’une archive de décisions passées.
Transmission du savoir	Le relecteur apprenait le système en le lisant, semaine après semaine.	Des documents d’architecture vivants, entretenus délibérément — parce que plus personne n’absorbe le système par osmose.
Responsabilité	Un humain nommé cliquait sur « approuver » et assumait le résultat.	Des spécifications avec des scénarios d’acceptation explicites, plus la télémétrie de production et les error budgets comme surface où l’écart d’intention est détecté.

Chacune de ces destinations est un document ou un test. Ce n’est pas une coïncidence, c’est tout le motif. L’Encyclopedia of Agentic Coding Patterns énumère les prérequis pour opérer au niveau 5, et la liste se lit comme un audit documentaire : spécifications lisibles par la machine avec scénarios d’acceptation, oracle de test fiable, fitness functions faisant respecter les contraintes, télémétrie de production complète comme mécanisme de retour principal.

Une spécification incapable de dire à quoi ressemble « terminé » n’est pas une spécification

S’il y a une chose à ajouter à chaque document que lit un agent, c’est celle-ci : une description de ce à quoi ressemble la réussite, écrite assez précisément pour pouvoir être vérifiée sans vous dans la pièce.

La plupart des expressions de besoin décrivent le comportement attendu et s’arrêtent là. Un humain qui les lit comble l’écart avec son jugement. Il sait ce que « raisonnable » veut dire dans ce système, il connaît les cas limites que le rédacteur n’a pas pris la peine de mentionner, il sait quelle défaillance est tolérable et laquelle réveille quelqu’un à trois heures du matin. Rien de tout cela n’est écrit nulle part, et jusqu’à récemment rien de tout cela n’avait besoin de l’être.

Un agent ne dispose d’aucune réserve de ce genre. Il comble le même écart par une invention plausible, avec assurance, puis livre. L’ambiguïté vous coûtait un sprint lent et un message de clarification. Elle est désormais tranchée à votre place, pendant la nuit, par quelque chose qui n’aura jamais l’idée de demander.

L’unité de travail cesse donc d’être une description du changement. Elle devient une description du changement plus la façon dont quiconque saurait qu’il a fonctionné : des scénarios d’acceptation en forme étant donné/quand/alors, les invariants qui doivent encore tenir après coup, les entrées qu’il doit encaisser, les budgets de latence et d’erreur au-delà desquels le résultat compte comme un échec, et un énoncé explicite de ce qui est hors périmètre. Ce dernier point mérite sa place — un agent sans bornes améliorera volontiers six choses que vous ne lui avez jamais demandé de toucher.

Rédigez un document ainsi et le document et le test cessent d’être deux artefacts. Le scénario d’acceptation est le test, à une transcription près. Vous n’entretenez pas une documentation puis, séparément, une suite de tests. Vous écrivez la condition de réussite une fois, là où l’intention vit déjà, et vous laissez la chaîne en faire ce qui garde la porte du déploiement.

C’est aussi ce qui empêche un agent de corriger sa propre copie. Un agent qui écrit l’implémentation puis les tests qui l’approuvent n’a rien vérifié — il a confirmé sa propre lecture d’une exigence ambiguë, à toute vitesse, en vert. Des critères rédigés en amont, par une personne, avant le début du travail, sont la seule chose qui rende le contrôle indépendant.

Un test est la seule partie d’un document qui échoue quand elle cesse d’être vraie.

D’où l’argument pratique : pousser dans cette forme autant du sens d’un document qu’elle peut en accepter. La prose dérive en silence. Une note d’architecture peut être fausse pendant huit mois sans que rien ne se produise, sinon que tout ce qui en découle est discrètement faux aussi. La section d’une spécification qui nomme sa condition de succès en est incapable : elle passe au rouge à la prochaine exécution. Dans une chaîne où personne ne lit la sortie, c’est le seul type de documentation muni d’une alarme.

Et la discipline joue dans les deux sens. Si vous ne savez pas écrire les critères de réussite d’un travail, vous ne comprenez pas encore l’exigence assez bien pour la confier à quoi que ce soit — agent ou nouvelle recrue. À cette différence près que la nouvelle recrue, elle, serait revenue vous poser la question.

Ce qui arrive quand on saute cette étape

Les travaux empiriques de 2026 ne sont pas tendres avec la version optimiste de cette histoire.

302 600 commits vérifiés écrits par IA analysés sur 6 299 dépôts
484 366 problèmes distincts attribués à cinq assistants de code largement utilisés
22,7 % de ces problèmes toujours présents dans la dernière version de ces dépôts

Ces chiffres viennent de Debt Behind the AI Boom (mars 2026), qui a lancé une analyse statique de part et d’autre de chaque commit écrit par IA afin d’isoler ce que l’assistant avait lui-même introduit. La dette de maintenabilité représente 89,3 % du total, et plus de 15 % des commits de chaque assistant étudié introduisent au moins un problème.

Deux autres chiffres circulent beaucoup, et tous deux méritent leurs réserves. Le rapport State of AI vs Human Code Generation de CodeRabbit situe les pull requests assistées par IA à 1,7× les signalements des pull requests humaines — 10,83 contre 6,45, sur 470 PR open source — ce qu’il faut lire en sachant que CodeRabbit vend de la revue de code. Et une analyse en différence de différences portant sur 806 dépôts ayant adopté un assistant de code a mesuré ensuite une hausse d’environ 41 % de la complexité du code et de 30 % des avertissements d’analyse statique. Ce sont deux mesures distinctes, et non un unique « la dette technique a augmenté de 30 à 41 % » ; les fondre en une seule fourchette relève précisément de l’imprécision que cet article dénonce. Le résumé du domaine par Info-Tech est plus brutal : un développement assisté par IA non encadré accélère les défauts sur tout le cycle de vie.

Il existe aussi un coût qui n’apparaît dans aucun de ces chiffres. Une publication l’appelle la dette de connaissance : des changements mis en œuvre par des agents et jamais réellement compris par les personnes qui en sont responsables. Votre base de code grossit pendant que la prise de votre équipe sur elle se réduit, et l’écart reste invisible jusqu’à la nuit où il faut le combler.

Le Pattern Book résume la version opérationnelle en une phrase : n’essayez pas de tourner au niveau 5 sur une base de code qui ne peut pas être bien testée. Retirez la revue humaine d’un dépôt non documenté à la suite de tests faible et vous n’avez pas construit une chaîne autonome. Vous avez automatisé la production de défauts, et vous lui avez confié une clé de déploiement.

Une documentation périmée est désormais un incident

Un document erroné égarait autrefois une nouvelle recrue dans sa troisième semaine. Quelqu’un finissait par corriger autour d’un café. Le rayon d’action était d’une personne et la réparation passait par l’humain.

Un document erroné égare désormais chaque agent sur chaque tâche qui touche à ce domaine, silencieusement et en parallèle, jusqu’à ce que quelque chose remonte en production et que l’on remonte la piste. L’obsolescence documentaire est passée du désagrément au défaut à retardement.

Le signe est visible dans ce que construisent réellement les praticiens. Le dispositif de Cole Medin — celui qui sous-tend son expérience publique de dark factory — fait tourner une boucle Plan / Implement / Validate sur du markdown propre à chaque dépôt : documents d’architecture, règles de projet, compétences réutilisables, historique des workflows. Il fait aussi tourner une passe de réflexion quotidienne dont le seul travail est de repérer les entrées périmées. Il a construit un outillage de maintenance pour la documentation, parce que la documentation est porteuse. Archon, la couche d’orchestration en dessous, fige le processus lui-même en YAML afin que les étapes que vous ne voulez pas voir improvisées ne soient pas laissées à la discrétion de l’agent.

Si vos documents sont une entrée, ils ont besoin de ce qu’on accorde à une entrée : un propriétaire, une cadence de revue, des contrôles d’obsolescence en intégration continue, et une définition de « terminé » qui les inclut. « Mettre à jour la doc » en ligne pleine d’espoir dans le modèle de pull request, ce n’est pas cela.

Avant d’éteindre la lumière

Rien de tout ceci n’est un argument contre l’autonomie. C’est un argument sur l’ordre des choses. Voici ce qui doit être vrai d’abord, et le signal honnête que ça ne l’est pas encore.

Des spécifications lisibles par la machine, pas des titres de tickets. Pas prêt si les exigences arrivent dans la chaîne sous forme d’une phrase et d’une conversation que personne n’a écrite.
Chaque spécification porte sa propre description de la réussite. Pas prêt si un travail peut être marqué terminé sans que quiconque se soit mis d’accord à l’avance sur le sens de « terminé ».
Une réussite énoncée en scénarios et en seuils, pas en adjectifs. Pas prêt si vos critères disent « rapide », « robuste » ou « intuitif » sans aucun chiffre attaché.
Des critères rédigés en amont, par une personne, avant l’implémentation. Pas prêt si le même agent écrit le code puis les tests qui l’approuvent.
Un oracle de test sur lequel vous miseriez la production. Pas prêt si une suite verte a livré une version cassée ce trimestre.
Des règles de projet comme contraintes actives, pas comme histoire. Pas prêt si votre seule architecture écrite est une archive d’ADR que personne n’a rouverte depuis sa fusion.
Fitness functions, analyse statique et scan de sécurité dans la chaîne. Pas prêt si les contrôles qui n’exigent aucune opinion sont encore effectués par des gens qui en ont.
Télémétrie et error budgets comme surface de revue. Pas prêt si la production est devenue votre relecteur sans être instrumentée comme telle.
Feature flags et déploiements canari. Pas prêt si chaque changement atteint tous les utilisateurs d’un coup. L’exposition progressive est ce qui rachète la sécurité qu’apportait la revue.
Un chemin documenté de retour au manuel. Pas prêt si aucun runbook ne couvre la nuit où la chaîne se trompe et où quelqu’un doit déboguer du code qu’aucun humain n’a lu. Les équipes qui sautent celui-ci découvrent l’atrophie des compétences au pire moment.
Une propriété nommée et des contrôles de fraîcheur sur chacun des documents ci-dessus. Pas prêt si vous ne pouvez pas dire qui répond de la véracité du document d’architecture aujourd’hui.

Vous n’avez pas besoin de tout cela pour tirer profit du développement agentique. Vous avez besoin de tout cela avant de retirer l’humain.

Le goulot d’étranglement n’a jamais été l’outillage

Voici la conclusion inconfortable pour qui construit en ce moment un budget sur le sujet. Les équipes qui avanceront le plus vite vers le développement autonome ne sont pas celles qui achètent les agents les plus performants. Ce sont celles qui écrivaient déjà les choses.

Leurs spécifications sont explicites et disent ce que réussir veut dire. Leur architecture est décrite quelque part à jour. Leurs tests échouent quand le code est faux. Leurs contraintes vivent dans le dépôt plutôt que dans la tête d’un ingénieur principal. Pour ces équipes, il s’agit surtout de brancher sur un nouveau runtime des artefacts qu’elles entretiennent déjà, et les progrès de capacité des deux dernières années sont un gain net.

Tous les autres sont sur le point de découvrir que leur contrainte réelle n’a jamais été la capacité des modèles, ni l’outillage. C’était que la connaissance nécessaire à la fabrication de leur logiciel n’a jamais existé ailleurs que dans des personnes — et que cela n’était tenable qu’aussi longtemps que ces personnes étaient celles qui construisaient.

Les agents n’ont pas créé ce problème. Ils ont rendu impossible de continuer à l’ignorer.

Pour aller plus loin

Le cadre

The Five Levels: from Spicy Autocomplete to the Dark Factory — Simon Willison sur le modèle de Dan Shapiro, avec des notes de première main sur une équipe réellement au N5.
Dark Factory — Encyclopedia of Agentic Coding Patterns — prérequis, socle nécessaire et modes de défaillance.

Le système en fonctionnement

How to Build the Most Powerful System for AI Coding — le décryptage complet de la boucle Plan / Implement / Validate par Cole Medin.
Archon — constructeur de harnais open source ; workflows YAML, worktrees git isolés, nœuds déterministes.

La documentation comme entrée

AGENTS.md — le format ouvert, désormais porté par l’Agentic AI Foundation sous l’égide de la Linux Foundation.
AGENTS.md vs Architecture Decision Records — documentation passive contre gouvernance active.
How to write a good spec for AI agents — Addy Osmani.
Context Engineering: A Practical Guide et Context is AI coding’s real bottleneck in 2026.

Les données

Debt Behind the AI Boom — l’étude empirique sur 302 600 commits.
State of AI vs Human Code Generation — la comparaison de CodeRabbit sur 470 PR ; source du chiffre de 1,7×.
Faster Code, Deeper Debt? — revue de littérature sur la dette technique en développement assisté par LLM.
3100 Opinions on Code Review in an AI World — le discours des praticiens sur ce que devient la revue.
Knowledge Debt: The Hidden Cost of AI Coding.