Deux billets publiés le même jour, le 20 juillet 2026, racontent la même mutation par deux bouts opposés. D’un côté, des bricoleurs qui laissent un agent démonter le firmware de leur aspirateur connecté pour l’automatiser en un après-midi. De l’autre, des équipes qui n’écrivent plus une ligne : elles construisent l’usine qui écrit le code à leur place. Le geste de programmer vient de changer de nature.
L’unité de travail n’est plus la ligne de code
Addy Osmani, ingénieur chez Google, décrit dans « Software Factories, Light and Dark » une pile à trois étages. À la base, la boucle : un agent qui répète un cycle unique, rassembler le contexte, agir, vérifier le résultat, recommencer jusqu’à une condition d’arrêt. Autour, le harnais (harness) : le bac à sable où tourne l’agent, les outils qu’il peut atteindre, la mémoire qui survit d’une exécution à l’autre, et les portes qui définissent ce que « terminé » signifie. Au sommet, l’usine : des dizaines de boucles harnachées en parallèle, alimentées par une file de tâches et drainées vers la production à travers une porte de revue.
L’idée n’a rien de neuf. Osmani la fait remonter à un papier de Bob Bemer de 1968, « The economics of program production », qui rêvait déjà d’un logiciel produit comme on emboutit des pièces automobiles. Le rêve a échoué pendant un demi-siècle, faute de pouvoir industrialiser les idées elles-mêmes. Ce qui a basculé en deux ans, c’est que les agents savent enfin tenir une boucle sans supervision permanente. Le développeur ne rédige plus le diff : il conçoit et pilote la chaîne qui le produit. Dex Horthy, cofondateur de HumanLayer, le formule crûment dans une conférence donnée à l’AI Engineer World’s Fair : l’ingénierie du harnais ne suffit pas, c’est l’usine entière qu’il faut penser.
Quand démonter son aspirateur ne coûte plus rien
Simon Willison observe le même glissement par le bas. Il collectionne les récits de gens qui se servent d’agents de programmation pour rétro-concevoir (reverse-engineering) et automatiser leurs appareils domestiques. Rien de techniquement inédit : disséquer l’API non documentée d’un objet connecté était déjà possible hier. Ce qui manquait, c’était le retour sur investissement.
Le calcul vient de s’inverser. Ce code coûtait cher en heures et en frustration, surtout pour des API instables vouées à casser à la prochaine mise à jour du fabricant. Willison pointe le déclic : quand produire du code devient quasi gratuit, le poids psychologique de devoir le maintenir, ou de le jeter pour tout recommencer, s’effondre. On tente, on échoue, on relance sans y penser. La même logique de boucle bon marché qui alimente l’usine d’Osmani se rejoue dans un garage, un dimanche après-midi.
Usine claire ou usine sombre : qui reste dans la boucle
Osmani trace une frontière nette. L’usine claire (light factory) garde des humains dans la boucle : on échange du jugement et de la concentration contre de la vitesse, en assumant un peu de casse. L’usine sombre (dark factory) évacue l’humain : les agents cadrent, construisent et livrent le code sans que personne n’en lise vraiment le détail.
Le risque n’est pas la vitesse, c’est l’aveuglement. Si les gens cessent de lire le code, ils cessent de le comprendre. Une base logicielle que plus personne ne saisit devient impossible à réparer le jour où elle dérape, et nul ne saura même expliquer pourquoi. La compétence critique se déplace donc : elle ne consiste plus à écrire les lignes, mais à savoir quels garde-fous construire et quelle dose d’autonomie confier à chaque boucle.
Concepteurs d’usine d’un côté, artisans du code de l’autre
À terme, le poste de développeur devrait éclater en deux fonctions nettes. D’un côté, des concepteurs d’usine qui passent leurs journées à écrire des tests, des portes de revue et des règles d’autonomie : leur livrable n’est plus le code, mais le système qui le contrôle. De l’autre, des artisans qui refusent la boucle là où l’erreur coûte trop cher, sécurité, paiement, santé, et continuent de relire chaque ligne à la main.
La bascule ne tiendra qu’à une condition : la fiabilité des garde-fous automatisés. Tant que les portes de revue resteront plus lentes ou moins sûres que les boucles qu’elles filtrent, l’usine sombre ne sera qu’une dette différée déguisée en gain de productivité. Le basculement ne se lira pas dans un modèle plus puissant. Il se lira le jour où une équipe assumera de livrer en production du code qu’aucun humain n’a relu, sans que ce choix ne choque plus personne. Ce jour-là, le savoir-faire du développeur tiendra dans une décision : ce qu’il garde sous ses yeux, ce qu’il abandonne à l’usine.
