La promesse d’une livraison logicielle automatisée
En 2026, le rêve de la livraison automatisée de logiciels est celui d’un agent capable de lire un dépôt de code, comprendre sa structure, planifier un changement en plusieurs étapes, écrire le code, les tests et la documentation, exécuter le code et corriger ses propres erreurs, puis produire un diff prêt pour une demande d’extraction (pull request). Cependant, cet idéal se heurte à une réalité plus nuancée. Les trois premières tâches — lecture, cartographie et planification — sont dites « addititives » : elles ajoutent des informations sans modifier le comportement du système. Les trois dernières — écriture de code, tests et exécution — sont « transformatives » : elles altèrent la structure causale du code existant.
Un fossé entre l’additif et le transformatif
Cette distinction entre travail additif et travail transformatif est au cœur de la limitation fondamentale des modèles de langage (LLM) actuels. La génération de code est une tâche locale et additive : le modèle étend un motif sans avoir besoin de comprendre le système dans son ensemble. En revanche, le travail agentique est global et transformatif : il nécessite de modifier le système lui-même, ce qui exige une compréhension des dépendances, des invariants, des interactions et des conséquences en aval. Il s’agit d’un raisonnement causal, et non d’une simple extension de motifs. Les LLM prédisent des tokens, pas des conséquences.
Ce que les laboratoires ont réellement livré
Les travaux des laboratoires — OpenAI, Google, Cognition Labs, GitHub (Microsoft), Sourcegraph, JetBrains, Replit, Amazon, Meta et Anthropic —, publiés en 2023 et 2024, montrent que les agents s’améliorent, mais qu’ils ne sont ni fiables, ni autonomes, ni sûrs pour la production. Selon un expert du secteur, « les LLM peuvent aider à la livraison de logiciels, mais ils ne peuvent pas en être propriétaires ». Les démonstrations impressionnantes ne portent que sur des codes simples de quelques dizaines de lignes, et non sur des dépôts réels de plusieurs milliers de lignes, modifiés pendant des années par des dizaines de développeurs.
Pourquoi les LLM échouent-ils ?
Les LLM génèrent des continuations statistiquement plausibles de texte, ce qui fonctionne bien pour des tâches autonomes comme écrire une fonction ou rédiger une documentation, car ce sont des problèmes d’extension de motifs. Mais la reconnaissance de motifs n’est pas la compréhension de systèmes, et la plausibilité n’est pas la correction. Les systèmes logiciels sont causaux : les composants dépendent les uns des autres, les invariants contraignent le comportement, et les changements se propagent dans tout le système. Dès qu’une tâche cesse d’être autonome et devient dépendante du système — nécessitant la cohérence des dépendances, un état persistant ou la conscience de la façon dont les changements se répercutent dans une base de code réelle —, la reconnaissance de motifs ne suffit plus.
L’état persistant crée des dépendances temporelles
Une tâche autonome n’a ni passé ni futur. Une tâche dépendante du système en a un. Dès qu’un changement dépend d’écritures précédentes, de données accumulées, de valeurs en cache, d’objets à longue durée de vie ou d’un état système externe, tout modèle agentique doit raisonner sur la façon dont le système en est arrivé là et sur la façon dont il se comportera après le changement. Les LLM ne peuvent pas maintenir cette chaîne causale interne.
Produire un diff prêt pour une pull request
Une pull request (PR) est un morceau de code qui va modifier un système. Pour que ce changement soit sûr, il doit respecter l’architecture actuelle du système, son intention et toutes les conséquences en aval. Les ingénieurs logiciels travaillent dur pour garantir cette sécurité par des tests, leur jugement et leur expérience, avant qu’un collègue ne révise le changement. Appliquer un changement n’est plus une reconnaissance de motifs mais une compréhension du comportement causal : comment le système changera-t-il si cette PR est appliquée ? La correction de la PR dépend de la compréhension de l’ensemble du système, pas seulement de la génération de texte. Le LLM doit modifier le système, ce qui nécessite une compréhension des dépendances, des invariants, des interactions et des conséquences, tout cela demande un raisonnement causal, et non une simple reconnaissance de motifs.
Que faire concrètement ?
Pour l’instant, il est conseillé de traiter l’IA agentique comme une direction stratégique, et les outils actuels comme des assistants, pas comme des ingénieurs. Il est recommandé d’investir dans la clarté, l’architecture et la discipline des tests, d’attendre des progrès mais pas des miracles, et de ne pas planifier les pipelines de livraison autour de capacités non prouvées. Le jugement humain doit rester au centre du système.
Pourquoi cela importe : le code est bon marché, le jugement ne l’est pas
La livraison de logiciels augmentée par LLM ne supprime pas l’ingénierie ; elle la déplace vers un niveau supérieur. Les humains doivent se concentrer sur l’intention, les contraintes, l’architecture, la correction, la sécurité et les compromis. L’état final souhaité n’est pas « l’IA écrit du code », mais « l’IA maintient des systèmes ». Si nous y parvenons, les humains devront toujours maintenir l’intention. La conséquence d’un système agentique n’est pas de supprimer l’ingénierie, mais de l’élever, afin que les équipes passent moins de temps sur la construction mécanique et plus sur le jugement, l’alignement et la mise en forme de l’environnement dans lequel les agents opèrent.
