L'usine logicielle

Le codage agentique transforme l'unité de production logicielle : le développeur conçoit, supervise et améliore de plus en plus une usine de systèmes connectés pour construire, auditer, déployer et exploiter.

La plupart des révolutions technologiques sont plus faciles à comprendre après coup. Nous leur donnons un nom, traçons des chronologies bien nettes et faisons comme si la direction avait toujours été évidente. Mais, pour ceux qui les vivaient, elles devaient paraître bien plus désordonnées : nouveaux outils, méthodes de travail maladroites, promesses excessives, véritables percées, mauvais produits et lente transformation du sens même du travail.

En tant que développeur, j’ai surtout vécu dans un monde façonné par des révolutions déjà accomplies. Internet existait lorsque j’ai commencé à créer des logiciels. L’open source, le cloud, les smartphones, les boutiques d’applications, les API et les logiciels en ligne faisaient déjà partie du paysage. Ils ont bien sûr transformé mon travail, mais je ne sentais pas les fondations mêmes du métier bouger.

Le développement avec des agents IA me semble différent. J’ignore le nom que lui donneront les historiens et je ne prétends pas que chaque nouvel outil constitue une rupture de civilisation. Mais, vu de l’intérieur du métier, ce n’est pas simplement une amélioration de l’autocomplétion. C’est l’unité de base de la production qui change. La question n’est plus seulement de savoir à quelle vitesse un développeur peut écrire du code, mais comment il peut organiser des machines qui écrivent, testent, relisent, déploient et surveillent ce code.

La révolution industrielle n’a pas seulement consisté à remplacer la force musculaire par des machines. Elle a aussi été l’apprentissage de leur organisation par les humains.

Avant la production industrielle, une personne fabriquait directement l’objet, ou une grande partie de celui-ci. Le savoir-faire résidait dans la main, le regard, les habitudes et l’atelier. L’arrivée des machines motorisées n’a pas rendu le jugement humain inutile. Elle a déplacé son champ d’application.

La perceuse est un exemple simple. Quand je l’utilise, je reste responsable du trou : je choisis son emplacement, sa raison d’être, ses dimensions et je juge le résultat. En revanche, ce n’est plus moi qui fournis le mouvement de rotation. La machine s’en charge.

La transformation la plus profonde est venue ensuite, lorsque les machines ont été réunies en usines. L’invention décisive n’était pas seulement la machine, mais le système qui l’entourait : passages de relais, contrôle qualité, maintenance, planification, encadrement, logistique et sécurité. Les entreprises qui ont réussi ne possédaient pas simplement un meilleur outil. Elles avaient appris à organiser de nombreux outils en un système de production.

Je pense que le logiciel entre dans sa propre version de cette transition.

Jusqu’à très récemment, l’essentiel du logiciel était développé à la main. Même avec d’excellents outils, le développeur réalisait directement les opérations : ouvrir les fichiers, écrire le code, lancer les tests, lire les erreurs, puis corriger. Nous avions de meilleures perceuses, mais notre métier consistait toujours à les tenir toute la journée.

Les agents de développement changent la nature du travail. Ils n’ont rien de magique et ne sont pas des entreprises autonomes. Ils se trompent, se bloquent, suivent trop littéralement des consignes insuffisantes, manquent de contexte et produisent parfois des absurdités plausibles. Mais ils transforment bien la part mécanique du développement logiciel. Un humain peut désormais décrire un résultat délimité et laisser une machine explorer le code, le modifier, lancer les tests, rencontrer des erreurs, les corriger et proposer une solution.

C’est déjà un changement considérable. Le changement le plus important est pourtant l’usine qu’il devient possible de construire autour de l’agent.

Du codage à la production

La première tentation est de voir le développement avec des agents IA comme une manière de « coder plus vite ». C’est vrai, mais trop réducteur.

La question la plus intéressante est la suivante : à quoi ressemblerait une usine à applications ? Pas un générateur de code ni un simple squelette de projet. Une véritable usine qui transforme une intention produit en logiciel opérationnel : cadré, développé, relu, testé, déployé, observé et amélioré.

C’est très différent de ce que l’on appelle souvent le « vibe coding ».

Le vibe coding, c’est avoir une idée un vendredi soir, ouvrir un agent, contourner les difficultés et finir le week-end avec quelque chose d’assez fonctionnel pour le montrer. J’apprécie cette façon de travailler. Elle est concrète, utile et importante pour la créativité. Elle rend possibles de petits outils et permet de suivre sa curiosité sans devoir d’abord justifier une feuille de route.

Mais le vibe coding n’est pas le pilotage d’une usine.

Une usine est plus lente, du moins à certaines étapes. Elle ajoute volontairement des contrôles. Une fonctionnalité ne passe pas directement de l’idée au code, puis à la production. Elle traverse le cadrage produit, l’architecture, le développement, une revue contradictoire, des tests dans le navigateur, des vérifications de sécurité, le déploiement et la surveillance. Le parcours varie selon le changement : une correction de texte ne doit pas mobiliser le même dispositif qu’une migration de facturation, et un prototype ne doit pas se faire passer pour un logiciel de production. Le principe reste toutefois le même : l’usine n’est pas optimisée pour le plaisir de créer vite une première version, mais pour produire beaucoup de choses de manière fiable.

Cette distinction compte. Les agents de développement facilitent considérablement les prototypes de week-end. Les usines logicielles à base d’agents rendent possible une exploitation durable.

Chez Pyratz, nous avançons dans cette direction, même si nous ne l’avions pas nommée ainsi au départ. Les briques sont apparues séparément, parce que les problèmes se présentaient séparément. Comment transformer une idée de fonctionnalité vague en travail bien délimité ? Comment relire du code écrit par un agent sans lui faire aveuglément confiance ? Comment déployer et exploiter davantage d’applications sans réinventer l’infrastructure à chaque fois ? Et comment, à titre individuel, garder le contrôle sans devenir le point de blocage de chaque opération mécanique ?

Ces questions conduisent à des outils différents. Mais une même conviction les relie : la production logicielle doit devenir un système que l’on pilote.

Il existe une boucle de construction, dans laquelle l’idée devient une fonctionnalité, puis un plan d’architecture et des tâches de développement. Une boucle d’audit soumet le résultat à une revue contradictoire, à des essais dans le navigateur et à des contrôles de sécurité et de non-régression. Une boucle de déploiement prépare l’infrastructure, configure et publie l’application, puis observe son fonctionnement. Enfin vient le responsable de l’usine : la couche qui coordonne les autres machines, sait laquelle doit intervenir ensuite et soumet les décisions à l’humain.

Dans notre ensemble d’outils, Business Builder devient la boucle de construction. Code Voucher devient la boucle d’audit. Pyratz Apps devient le dispositif de déploiement. MrChief est le candidat au rôle de responsable de l’usine.

Ce dernier point est important. Je ne veux pas que MrChief soit « l’agent qui écrit tout le code ». Ce serait la mauvaise abstraction. Je le vois plutôt comme un super-assistant ou un directeur technique semi-autonome chargé des opérations mécaniques de l’entreprise. Il devrait se connecter aux autres briques par des interfaces MCP, des API, des outils en ligne de commande ou toute autre couche de communication adaptée. Il devrait savoir quand une fonctionnalité nécessite un éclaircissement produit, quand un audit bloque un déploiement, quand un environnement de préproduction fonctionne mal et quand je dois prendre une décision.

Dans ce modèle, je ne suis ni l’ouvrier ni même le responsable de l’usine. Mon rôle se rapproche de celui d’un dirigeant : fixer la direction, accepter les risques, établir les priorités et juger la qualité du produit. MrChief gère l’atelier.

C’est là que l’analogie industrielle devient utile. Une usine n’est pas une machine unique. C’est un système de machines avec des passages de relais, des contrôles, des réserves de capacité, des opérateurs, des procédures de sécurité et des boucles de retour d’expérience.

Le logiciel a besoin de la même chose.

Le pont entre les machines

Les projets ci-dessus sont utiles indépendamment. Mais une véritable usine exige de les connecter.

Si la construction, les tests qualité, le déploiement, la surveillance et l’interface de pilotage ont chacun leur propre état, leurs propres concepts et leur propre mémoire, l’humain reste la couche d’intégration. C’est mieux que d’écrire tout le code à la main, mais ce n’est toujours pas une usine : c’est un ensemble d’outils motorisés posés sur un établi.

L’usine apparaît lorsque ces outils partagent une structure suffisante pour se transmettre du travail de manière fiable.

Cela signifie qu’une fonctionnalité doit conserver une identité stable tout au long de son cycle de vie. Le cadrage produit, la proposition d’architecture, les tâches de développement, les commits, les constats de revue, les captures de tests, la cible de déploiement, les alertes de surveillance et les tickets de suivi doivent tous être reliés au même objet. Le système doit savoir que telle régression dans Sentry provient de tel déploiement, issu de telle fonctionnalité, elle-même issue de telle décision produit.

Chaque étape doit aussi reposer sur un contrat. Business Builder ne devrait pas transmettre à Code Voucher un vague « merci de relire ceci », mais un dossier de fonctionnalité avec son périmètre, ses critères d’acceptation, sa classification des risques, les parcours attendus, la stratégie de test et les commits concernés. Code Voucher ne devrait pas transmettre au déploiement un bloc de prose, mais une validation structurée, les constats bloquants, les pièces justificatives et les risques résiduels. Le dispositif de déploiement ne devrait pas simplement annoncer « terminé », mais préciser la version publiée, sa destination, son environnement et la manière de la vérifier. La surveillance ne devrait pas produire du bruit, mais des signaux structurés pouvant devenir du travail à traiter.

La liaison ne se résume pas à une intégration d’API. C’est un langage de travail partagé.

Les objets centraux me semblent être les suivants :

• une idée ;
• une fonctionnalité ;
• un dépôt de code ;
• un environnement ;
• une exécution ;
• un livrable ;
• un constat ;
• un déploiement ;
• un incident ;
• une décision.

Une fois ces objets partagés dans tout le système, l’opérateur peut poser des questions de plus haut niveau :

• Qu’est-ce qui empêche cette fonctionnalité d’arriver en production ?
• Quels constats restent à résoudre ?
• Qu’est-ce qui a changé depuis le dernier déploiement réussi ?
• Quels parcours utilisateurs les tests qualité ont-ils réellement couverts ?
• Quels incidents doivent donner lieu à des évolutions produit ?
• Quel agent doit intervenir ensuite ?

C’est cette liaison qui transforme des applications séparées en une usine.

Cela rejoint aussi l’argument en faveur des logiciels extensibles. Ils deviennent plus importants à l’ère des agents, car ils leur offrent de véritables moyens d’action : API, points d’extension, états structurés, commandes, événements et concepts documentés dans le système lui-même. Une usine apparaît lorsque cette idée s’applique non seulement au sein d’une application, mais aussi entre les applications qui construisent et exploitent le logiciel.

Il existe toutefois une différence. Dans un programme extensible, l’utilisateur étend le logiciel à travers les interfaces qu’il expose déjà. Emacs en est l’exemple évident : commandes, points d’extension, variables, modes et documentation. Avec l’usine logicielle, nous descendons d’un niveau supplémentaire. Je ne me contente plus nécessairement d’étendre l’application : en tant que créateur, je peux modifier l’application elle-même.

Ce n’est pas un pouvoir que l’on devrait accorder à n’importe quel utilisateur. Un utilisateur ordinaire ne devrait pas pouvoir réécrire Business Builder parce qu’il souhaite un bouton. Mais en tant que concepteur et exploitant de l’usine, je devrais pouvoir modifier l’usine elle-même en passant par elle.

Supposons par exemple que je veuille ajouter à Business Builder une fonctionnalité permettant de discuter avec un agent après le développement, pour vérifier que rien n’a été oublié. Cette demande ne devrait pas rester une consigne isolée dans une fenêtre de discussion. Elle devrait devenir un échange de cadrage, un périmètre, un contexte de dépôt, un plan d’architecture, des tâches, une revue, des tests et enfin un déploiement. Si elle modifie la manière dont les résultats de revue sont stockés, le système devrait savoir quels tests et parcours vérifier. Si le déploiement échoue, cet échec devrait devenir une tâche structurée plutôt qu’un journal de terminal oublié.

Ajoutons maintenant MrChief au-dessus de cet ensemble. Je ne souhaiterai peut-être même pas commencer dans Business Builder. Depuis mon téléphone, je pourrais dire à MrChief : « Améliore Business Builder pour que je puisse faire le point avec un agent après le développement. » MrChief devrait identifier la machine responsable, lancer le bon processus, revenir vers moi lorsque mon jugement est nécessaire et préserver la chaîne de preuves. L’objectif n’est pas qu’un assistant fasse tout. C’est qu’il devienne l’interface de pilotage d’un réseau d’outils spécialisés dont on peut examiner le fonctionnement.

L’objectif qui m’intéresse n’est pas « un agent écrit du code ». C’est qu’une personne puisse exploiter une application depuis n’importe où. Depuis un téléphone, elle devrait pouvoir exprimer un besoin, le préciser, laisser le système le développer, examiner la revue, approuver le déploiement, puis recevoir les informations de surveillance. Pas pour toutes les catégories de logiciels ni sans discernement, mais pour une grande partie des applications courantes.

Cela peut sembler modeste, jusqu’à ce que l’on considère ce que cela rend possible.

Aujourd’hui, développer une application pour un club de poker local n’est probablement pas rentable. Une petite association peut avoir besoin de gérer les inscriptions, les événements, les cotisations, les tables, les annonces et quelques tâches administratives. Mais recruter une équipe, installer l’infrastructure, développer, sécuriser, maintenir et exploiter l’application coûte trop cher. Le besoin reste donc mal couvert, ou finit dans un tableur et une discussion de groupe.

Dans un monde d’usines logicielles, cela change. L’application peut toujours nécessiter un jugement humain sur le produit, une vérification juridique et des paiements, ainsi qu’une personne attentive aux utilisateurs. Mais le coût mécanique de production et d’exploitation baisse suffisamment pour rendre davantage de logiciels de niche viables.

Voilà pourquoi je ne pense pas que cette évolution supprime le travail logiciel. Les usines n’ont pas éliminé la production : elles l’ont développée. Elles ont permis de fabriquer davantage, à moindre coût et avec plus de régularité. Elles ont aussi créé des métiers dans la conception, la maintenance, la logistique, les procédés, la sécurité, la qualité et l’encadrement.

Je m’attends à la même chose dans le logiciel. Nous en produirons beaucoup plus, pas moins. Le métier passera de l’exécution manuelle de chaque geste à la conception, à la supervision et à l’amélioration du système de production.

Les dangers de l'usine

Mais quiconque veut exploiter une usine doit prendre ses dangers au sérieux.

Le revers de la médaille, c’est qu’une usine logicielle à base d’agents peut échouer à la vitesse des machines. Un développeur qui commet une erreur à la main reste limité par sa vitesse d’exécution. Une usine mal conçue peut produire de mauvaises modifications, des revues trompeuses, des déploiements vulnérables et des corrections désordonnées bien plus vite qu’une équipe humaine ne peut les comprendre.

L’injection d’instructions malveillantes est un risque évident. Quand les agents lisent des tickets, de la documentation, des sites, des journaux, des courriels ou du contenu utilisateur, ils doivent traiter ces entrées comme potentiellement hostiles. Une instruction cachée dans une page ne doit pas leur permettre d’exfiltrer des secrets, d’affaiblir les tests, d’approuver leur propre travail ou de modifier la politique de déploiement. L’usine a besoin de frontières strictes entre contenu non fiable et instructions autorisées : permissions sur les outils, traçabilité des sources, environnements isolés et contrôles de publication. La capacité à produire un texte convaincant ne justifie pas l’octroi de droits d’écriture.

Le risque augmente lorsque les applications sont interconnectées. Si Business Builder peut lancer le développement, Code Voucher publier des résultats de revue, Pyratz Apps déployer et MrChief orchestrer l’ensemble, une injection réussie à un endroit peut tenter de provoquer une défaillance opérationnelle partout. Les échanges doivent donc transmettre les niveaux d’autorité, pas seulement les données. Un constat de test qualité n’est pas une autorisation de déploiement. Un journal de déploiement n’est pas une exigence produit. Un commentaire utilisateur n’est pas une instruction de confiance. Chaque livrable doit avoir une provenance, des permissions et une liste d’actions suivantes autorisées.

La maintenabilité est un autre risque. Une usine qui n’optimise que le débit produira de la dette logicielle à une échelle industrielle. Les agents ajoutent très facilement un fichier, une abstraction, une couche de compatibilité ou une fonction presque identique à une autre. Sans mémoire de l’architecture ni revue, le code peut devenir une accumulation de décisions individuellement plausibles. La boucle de construction doit donc veiller à la réutilisation, aux responsabilités des modules, aux migrations, aux tests et à la justification des nouvelles abstractions.

C’est encore une différence entre la discipline de l’usine et le vibe coding. Dans un prototype de week-end, un peu de duplication ou une abstraction maladroite peuvent être acceptables : le but est d’apprendre. En production, ces habitudes s’accumulent. Si chaque fonctionnalité ajoute son propre modèle presque correct, l’usine perd en capacité à chaque passage. Le résultat peut toujours sembler rapide, mais le système devient plus difficile à modifier, à relire et à considérer comme fiable.

Il existe aussi un risque de confiance excessive. Une suite de tests réussie ne prouve pas que le produit fonctionne. Un rapport de tests dans le navigateur ne prouve pas que tous les parcours ont été couverts. Une analyse de sécurité ne prouve pas que le système est sûr. Un message de déploiement réussi ne prouve pas que les utilisateurs sont satisfaits. Chaque étape produit des éléments de preuve, pas une vérité absolue. L’opérateur doit faire la différence.

L’ancien avertissement de Knuth paraît étrangement pertinent : « Méfiez-vous des bugs dans le code ci-dessus ; j’ai seulement prouvé qu’il était correct, je ne l’ai pas essayé. » Le problème diffère un peu, mais sa structure reste la même. Une preuve formelle, une exécution de tests, un rapport qualité, une analyse ou un résumé d’agent peuvent tous être précieux. Aucun ne se confond avec la réalité du produit.

L’usine doit aussi pouvoir être auditée. Si un agent modifie un parcours de facturation, qui l’a demandé ? Quel périmètre a été approuvé ? Quels fichiers ont changé ? Quels constats de revue ont été écartés ? Quels tests ont été exécutés ? Dans quel environnement la version a-t-elle été déployée ? Quel signal a ensuite révélé la régression ? Sans cette chaîne, on ne peut pas faire confiance à l’usine.

Enfin, il y a le risque humain : la tentation de cesser de réfléchir. L’usine doit supprimer les tâches fastidieuses, pas la responsabilité. Plus le système devient puissant, plus il importe que l’humain reste responsable du jugement produit, de l’acceptation du risque et des choix qualitatifs.

Le bon modèle n’est pas « des agents à tous les étages », mais un système industriel doté de garde-fous :

• des agents limités aux permissions nécessaires ;
• des environnements d’exécution isolés ;
• des étapes d’approbation explicites ;
• des livrables structurés ;
• des revues contradictoires ;
• des preuves brutes privées et des publications expurgées des données sensibles ;
• des historiques de déploiement ;
• des retours de surveillance ;
• des modifications réversibles ;
• une responsabilité humaine clairement établie.

Les usines sont puissantes parce qu’elles sont rigoureuses. Une usine logicielle sans discipline n’est qu’un désordre automatisé.

L'entreprise qui apprend à piloter l'usine

Les premières entreprises qui maîtriseront cette organisation disposeront d’un avantage réel.

Pas parce qu’elles posséderont un agent de développement magique : tout le monde aura accès à ces agents. L’avantage viendra du système de production qui les entoure : contrats, orchestration, boucles de revue, dispositifs de déploiement, surveillance et habitudes collectives permettant à une petite équipe de faire évoluer de nombreux logiciels sans perdre le contrôle.

C’est pourquoi ce sujet me paraît important. Ce n’est pas une astuce de productivité. C’est un changement de l’unité de production logicielle.

Plusieurs questions méritent d’être explorées ensuite. À quoi doit concrètement ressembler l’interface d’une telle usine ? Est-ce une évolution des outils connus, comme Linear pour formaliser l’intention, Sentry pour les signaux de production, GitLab pour le contrôle des changements et les tableaux de déploiement pour l’exploitation ? Ou faut-il une interface entièrement différente, plus proche de MrChief : un responsable placé au-dessus des outils, qui comprend leur état et permet à l’humain de piloter le système par la conversation, la revue et des décisions explicites ?

Se pose aussi la question de l’autonomie. Quelles étapes doivent s’exécuter automatiquement ? Lesquelles doivent attendre une approbation ? Quels risques le système peut-il prendre seul, et lesquels doivent toujours revenir à l’opérateur ? La réponse ne sera probablement pas un niveau d’autonomie unique. Elle dépendra de l’application, de l’environnement, de la maturité de l’usine et du coût d’une erreur. Cet espace de conception mérite un traitement à part entière : l’expérience d’utilisation des usines logicielles à base d’agents pourrait compter autant que les agents eux-mêmes.

Le développeur était autrefois celui qui tournait la manivelle. Il devient de plus en plus celui qui conçoit la machine, lui confie du travail utile, vérifie ses résultats, l’entretient et décide de ce qu’elle doit produire ensuite.

Les meilleurs concepteurs ne seront pas ceux qui demandent simplement du code aux agents, mais ceux qui apprennent à piloter toute l’usine.