Votre prototype IA fonctionne. Le faire tenir en production est un autre métier.

Un dirigeant nous décrit souvent la même scène. Un prototype monté en quelques jours avec un agent de codage, une démonstration qui impressionne, l’impression tenace que le plus dur est fait. Puis trois mois passent, et l’application ne part toujours pas en production.

Le réflexe est d’y voir un échec, celui de l’outil, de l’équipe ou du projet. C’est rarement le cas. Ce décalage entre ça marche en démonstration et ça tient en production est l’arête visible d’une distinction que l’IA n’a pas créée, mais qu’elle a rendue beaucoup plus nette : écrire du code et concevoir un système ne sont pas le même travail. Le premier est devenu rapide et bon marché. Le second reste un métier.

Cet article regarde où passe cette ligne, et pourquoi : ce que l’autonomie de l’IA ne couvre pas, la dette technique qui s’accumule sans qu’on la voie passer, les points où un projet IA-augmenté casse réellement une fois en production, et la répartition du travail qui, elle, tient.

Ce que l’agent fait vraiment bien

Commençons par ce qui marche, parce que c’est considérable. Sur une tâche locale et bien cadrée, un agent de codage est excellent : produire une fonction à partir d’une spécification claire, échafauder une interface de gestion d’enregistrements, écrire un script, transposer un extrait d’un langage à un autre, livrer une première implémentation plausible d’un motif connu. Sur ces tâches, il va plus vite qu’un humain et fait souvent aussi bien. Ce n’est pas une concession arrachée du bout des lèvres : c’est une part énorme du quotidien d’un développeur, et c’est précisément pour cela que ces outils se sont diffusés aussi vite.

Ce que ces tâches ont en commun, c’est d’être ponctuelles. Elles sont locales, bornées, immédiates, et le contexte qui compte tient devant l’agent : la spécification est dans la consigne, le fichier est dans la fenêtre, le succès se vérifie sur-le-champ en exécutant le résultat. Un système, c’est l’inverse. Sa justesse est répartie sur de nombreux fichiers, de nombreuses décisions et une longue durée ; une grande partie de ce qui le rend correct n’est écrite nulle part ; et « est-ce que ça marche » ne se vérifie pas en lançant une fois le chemin nominal. L’agent est fait pour optimiser la tâche qu’on lui confie. Or un système est exactement ce qui n’est pas confié dans une tâche : il est la somme des contraintes, des invariants et des décisions qu’aucune tâche isolée n’exprime.

C’est là que passe la ligne. Non pas « l’agent est bon ou mauvais », mais « l’agent opère sur le ponctuel, et un système de production est systémique ». Tout le reste découle de cet écart.

Ce que l’autonomie ne couvre pas

Le premier effet de cet écart touche le raisonnement à l’échelle du système. L’agent optimise localement ; il ne tient pas dans son champ l’ensemble des invariants et des couplages de l’application. Des décisions individuellement justes finissent par composer une incohérence globale : une logique dupliquée à deux endroits, une abstraction qui fuit, des contrats qui ne s’accordent pas d’un module à l’autre. Chaque morceau passerait une revue ; c’est l’assemblage qui ne tient pas ensemble.

Viennent ensuite les préoccupations transverses, tout ce qui n’est pas logé dans un seul fichier. La stratégie de gestion des erreurs, les frontières transactionnelles, la politique d’autorisation, l’observabilité, la cohérence des données : ce sont des décisions qui traversent toute la base de code et qui doivent être tenues de façon cohérente, en un seul geste de conception. Un agent qui sert une tâche après l’autre les produit par fragments : une gestion d’erreur un peu différente ici, un contrôle d’autorisation oublié là, parce qu’aucune tâche prise isolément n’est « la politique de sécurité » ou « le modèle de cohérence ».

S’ajoute le contexte implicite. Une large part de ce qui rend un système métier correct n’est pas écrite : les invariants du domaine, les contraintes réglementaires, les raisons d’un choix antérieur, les contrats avec les systèmes auxquels l’application parle. L’agent ne dispose que de ce qui est dans son contexte. Il ne peut pas inférer ce qui n’a jamais été énoncé, et dans une organisation réelle, une quantité considérable de choses ne l’est jamais.

Reste enfin la cohérence sur la durée. Un prototype est un instantané ; un système vit et change. Les raccourcis sans conséquence pour une démonstration (pas de stratégie de migration de schéma, configuration inscrite en dur, aucune gestion de version) deviennent des passifs au moment précis où la chose doit évoluer sous usage réel. L’agent optimise la tâche présente, pas la capacité du système à se transformer sur des mois.

Le point décisif est que rien de tout cela n’est un retard de maturité que la prochaine version comblera. C’est une inadéquation entre la forme du travail qu’un agent fait bien, locale, bornée et immédiate, et la forme d’un système de production, distribuée, implicite et durable. Un agent plus capable fait mieux le ponctuel ; il ne transforme pas le systémique en ponctuel. La limite porte sur l’autonomie : sur le fait de produire un système sans qu’un humain tienne la vue d’ensemble. Placez un architecte compétent dans la boucle, et la génération actuelle d’agents devient un accélérateur remarquable. Retirez-le, et l’écart réapparaît, quelle que soit la version.

La dette qu’on ne voit pas passer

La dette technique est une notion ancienne : on emprunte sur la maintenabilité future pour livrer maintenant. En temps normal, c’est un arbitrage conscient ; on sait qu’on coupe un angle, et on le note.

La dette d’un développement IA-augmenté a un caractère particulier : elle est produite vite et de façon plausible. Le code se lit bien, s’exécute, passe la démonstration. L’angle est donc coupé sans que personne ait décidé de le couper. Quand un humain écrit chaque ligne, une partie de la friction se ressent à l’écriture : le développeur perçoit le couplage, le test absent, le raccourci, et l’enregistre au moins comme une dette. L’agent supprime cette friction. C’est tout son intérêt, et c’est aussi ce qui supprime le signal. La dette est contractée en silence. La rapidité qui a tant de valeur est précisément ce qui en masque le coût.

Ce qui s’accumule est concret : un couplage implicite entre des parties qui devraient être indépendantes, des chemins d’erreur et des cas limites jamais écrits parce que la démonstration n’a exercé que le cas nominal, des motifs qui diffèrent d’un coin à l’autre de la base de code, un modèle de données taillé pour la forme de la démonstration et non pour ce que la production portera, des hypothèses et une configuration figées dans le code. Rien de visible tant que le prototype tourne.

Et c’est là l’asymétrie qui compte. Réparer un système dont la dette a fait des intérêts coûte bien plus cher que de l’avoir construit d’emblée avec la vue systémique, et cela coûte le plus cher au pire moment. Démêler un couplage que personne n’a documenté, reconstituer des invariants que personne n’a écrits, greffer des tests sur un code qui n’a jamais été pensé pour être testable, et faire tout cela sur un système désormais en service, qu’on ne peut pas casser pendant qu’on le répare. La vitesse qui semblait gratuite au stade du prototype était un emprunt ; l’échéance tombe en production, sous charge, avec de vraies données et de vrais utilisateurs, au plus mauvais moment possible pour découvrir la facture.

Là où ça casse : production, sécurité, montée en charge

Le passage en production est le premier mur. Le prototype tourne sur le poste du développeur, sur le chemin nominal. La production réclame tout ce qui n’est pas la fonctionnalité : une gestion des erreurs et une dégradation maîtrisée, des journaux et une observabilité pour qu’un problème soit diagnosticable, une configuration et des secrets gérés hors du code, un déploiement reproductible, la capacité de revenir en arrière. L’agent a construit la fonctionnalité ; cette couche de durcissement est largement absente, parce que rien de tout cela n’était la tâche.

La sécurité mérite qu’on s’y arrête. Le code généré embarque fréquemment des motifs plausibles et vulnérables : une construction de requête ouverte à l’injection, une validation des entrées partielle ou absente, une autorisation appliquée point d’accès par point d’accès au lieu d’une politique unique, des secrets laissés dans le code, des dépendances tirées sans que personne examine ce qu’elles transportent. Deux causes convergent : un agent reproduit les motifs d’une distribution d’entraînement qui contient quantité de code peu sûr, et la sécurité est une propriété transverse, exactement le type que la section précédente montrait sous-servi par l’autonomie. Surtout, les failles n’apparaissent pas dans la démonstration ; elles apparaissent quand quelqu’un sonde le système en fonctionnement. Les catalogues de référence des vulnérabilités applicatives courantes se lisent, point par point, comme la liste de ce qu’un prototype rapide omet.

La montée en charge est le mur suivant. Le prototype fonctionne pour un utilisateur et une poignée d’enregistrements. La production apporte la concurrence, des volumes de données réels, des requêtes irréprochables sur dix lignes et qui s’effondrent sur dix millions, des index manquants, une mémoire non bornée, aucune stratégie de cache ni de régulation de charge. Ce sont des décisions d’architecture prises tôt, ou laissées de côté, face à un profil de charge que l’agent n’a jamais vu.

Restent les intégrations. Une application métier réelle vit dans un écosystème : elle parle au paiement, à l’identité, à des données historiques. L’agent gère proprement un appel à une interface qui se comporte bien. La réalité moins docile (un tiers instable, des défaillances partielles, l’idempotence, des contrats qui dérivent) est systémique, et c’est là que les intégrations cèdent sans bruit.

Chacun de ces points est invisible dans la démonstration et surgit en production. C’est le mécanisme exact par lequel un projet marche puis coince : la démonstration exerce le ponctuel, la production exerce le systémique.

La division du travail qui tient

La question n’a jamais été « l’IA ou les ingénieurs ». L’agent est réellement bon sur le ponctuel, et le ponctuel représente une part importante du travail. Le retirer serait absurde ; le garder est juste.

Ce que la couche systémique ajoute est un autre travail, pas une dose supplémentaire du même. Tenir l’architecture : la vue d’ensemble, les invariants, le chemin par lequel le système évoluera. Poser les politiques transverses (sécurité, gestion des erreurs, cohérence des données) une fois et de façon cohérente. Assurer le durcissement de production et la cohérence sur la durée. C’est le travail qui ne tient pas dans une fenêtre de contexte, parce qu’il vit à l’échelle du système entier et du temps long. Ce n’est pas la défense d’un effectif ; c’est une catégorie de travail que l’agent autonome, structurellement, ne fait pas.

Le rôle de l’humain se déplace en conséquence : d’écrire chaque ligne, désormais largement assisté, à tenir la vue d’ensemble et les décisions transverses, et à se servir de l’agent pour exécuter vite à l’intérieur de ce cadre. Même outil, résultats opposés, selon que quelqu’un tient le cadre ou non.

Les projets qui s’enlisent sont presque toujours ceux où la vélocité interne existe (l’équipe, l’agent, la vitesse), mais où le contrepoids systémique manque : pas de revue d’architecture, pas d’audit de la dette qu’on est en train de contracter, pas de durcissement de la sécurité et de la charge, pas de discipline de production. C’est à cette frontière, lorsque la vélocité est présente mais la couche systémique absente, qu’un regard d’ingénierie extérieur trouve sa place.

Le décalage du prototype à la production n’est donc pas l’échec qu’il paraît être. C’est l’arête visible d’une distinction qui a toujours existé, entre écrire du code et concevoir un système. L’agent a rendu le premier bon marché. Ce faisant, il a rendu le second plus visible, et sans doute plus précieux. La valeur n’a pas disparu quand le code est devenu facile à produire. Elle s’est déplacée : de produire le code à tenir le système debout.