Comment fonctionnent les agents IA de programmation, et ce qu'il faut savoir à leur sujet

Le développeur de 2025 écrit de moins en moins de code de zéro. Il formule la tâche, lance un agent IA et le regarde générer des dizaines de fichiers, refactoriser l'architecture et même exécuter des tests. Des outils comme Cursor, GitHub Copilot Workspace, Devin et Claude Code sont passés en un an du statut d'expériences exotiques à celui de quotidien pour des centaines de milliers de développeurs. Mais peu d'utilisateurs comprennent vraiment ce qui se passe sous le capot. Ars Technica a publié une analyse détaillée de la mécanique interne des agents IA de programmation, et ses conclusions méritent l'attention de quiconque confie à une machine ne serait-ce qu'une partie de son travail.

Le socle de tout agent de programmation est un grand modèle de langage, qu'il s'agisse de GPT-4o, de Claude 3.5 Sonnet ou de Gemini. Mais le modèle seul n'est que le moteur.

L'agent, lui, est tout un appareillage d'ingénierie construit autour. Le premier problème, et sans doute le plus critique, que doivent résoudre les concepteurs d'agents est la limite de la fenêtre de contexte. Même pour les modèles les plus avancés, elle est finie : 128 ou 200 mille tokens paraissent impressionnants, mais un vrai projet logiciel peut compter des millions de lignes de code.

Les agents s'en sortent grâce à plusieurs astuces : ils indexent la base de code, construisent des cartes sémantiques du dépôt, n'extraient que les fragments pertinents et compressent le contexte en écartant ce que le modèle a déjà « traité ». En somme, l'agent joue le rôle d'un bibliothécaire avisé qui apporte au modèle exactement les livres nécessaires pour répondre à une question précise, au lieu de déverser toute la bibliothèque sur la table.

Le deuxième mécanisme clé est la chaîne de raisonnement, ou chain-of-thought. Au lieu de produire une réponse d'un seul jet, l'agent découpe une tâche complexe en étapes successives. Il analyse d'abord la structure du projet, formule ensuite un plan de modifications, met en œuvre chaque étape, vérifie le résultat et, au besoin, corrige le tir.

Ce n'est pas un simple procédé de style : des travaux montrent que le raisonnement pas à pas réduit radicalement les erreurs sur les tâches complexes. Certains agents vont plus loin et adoptent une architecture dite multi-agents : un modèle joue l'« architecte » et décompose la tâche, un autre écrit le code, un troisième se charge de la relecture, un quatrième des tests. Ils communiquent par des prompts structurés, en imitant le fonctionnement d'une vraie équipe de développeurs.

C'est ainsi que sont conçus Devin, de Cognition, et plusieurs autres systèmes avancés.

Mais derrière les démonstrations impressionnantes se cachent de sérieuses limites à garder en tête. La principale : les hallucinations. Un agent peut utiliser avec aplomb une API qui n'existe pas, appeler des fonctions avec de mauvais arguments ou produire un code d'apparence impeccable mais truffé d'erreurs logiques subtiles. Le problème s'aggrave du fait que les agents agissent de façon autonome : là où un autocompléteur classique, comme les premières versions de Copilot, proposait une ligne que le développeur évaluait aussitôt, un agent moderne peut générer des centaines de lignes réparties sur une dizaine de fichiers. Vérifier un tel volume à la main n'a rien d'anodin, et la tentation de cliquer sur « tout accepter » est forte.

La sécurité est un casse-tête à part. Des études ont déjà documenté des cas où des agents IA ont introduit des failles dans le code, des injections SQL à la gestion non sécurisée des saisies utilisateur. Le modèle optimise le code pour qu'il « fonctionne », pas pour qu'il soit « sûr », et sans exigence de sécurité explicite, il peut choisir la voie la plus simple mais vulnérable. Pour les équipes qui manipulent des données sensibles ou des systèmes financiers, ce n'est pas un risque abstrait, mais une menace concrète.

Il existe aussi un effet plus subtil, que l'industrie commence à peine à percevoir. Quand un développeur s'en remet à un agent pour écrire une part importante du code, il perd peu à peu la compréhension fine de sa propre base de code. Le code écrit par une machine est souvent étranger au style de l'équipe, recourt à des schémas inhabituels et se débogue plus difficilement. Un paradoxe apparaît : l'outil censé accélérer le développement peut ralentir la maintenance du produit à long terme.

Rien de tout cela ne signifie qu'il faille renoncer aux agents IA. Ils accélèrent bel et bien les tâches routinières, aident à prendre en main des frameworks inconnus et abaissent le seuil d'entrée en programmation. Mais mieux vaut les traiter comme un stagiaire très doué mais inexpérimenté : il peut accomplir beaucoup, mais chacun de ses résultats exige la relecture d'un collègue senior.

Comprendre comment l'agent prend ses décisions — comment il compresse le contexte, comment il découpe une tâche, où se trouvent ses angles morts — passe du statut de curiosité académique à celui de compétence pratique. Dans un monde où les agents IA écrivent de plus en plus de code, maîtriser leur mécanique devient une compétence aussi élémentaire pour un développeur que connaître Git ou savoir lire des logs.