Les agents de code : quand l'IA agit dans le projet

Il n'y a pas si longtemps, l'IA dans le développement ressemblait surtout à de l'autocomplétion améliorée. On écrivait une fonction, l'assistant proposait la suite. On posait une question, il répondait. Pratique, parfois brillant, parfois dangereusement sûr de lui — comme beaucoup d'outils qui finissent en production.

Une nouvelle étape est pourtant en train de s'installer : les agents de code.

Un agent de code ne se contente pas de suggérer une ligne ou d'expliquer une erreur. Il lit une base de code, comprend une demande, modifie plusieurs fichiers, lance des tests, corrige ses propres erreurs, ouvre une pull request ou documente son travail. Il ne répond plus seulement : il agit.

Le changement est de taille, car il fait passer l'IA du rôle d'assistant conversationnel à celui de contributeur opérationnel.

De l'assistant au collègue

Un assistant de code classique épaule le développeur pendant que celui-ci garde la main. Il complète une ligne, propose une fonction, explique un message d'erreur ou génère un test unitaire.

Un agent de code, lui, fonctionne autrement. On lui confie un objectif plus large : « corrige ce bug », « ajoute cette fonctionnalité », « mets à jour cette dépendance », « améliore cette page », « trouve pourquoi ce test échoue ».

À partir de là, l'agent décompose le problème. Il lit les fichiers concernés, cherche des références, identifie les dépendances, propose un plan, modifie le code, exécute des commandes, observe les erreurs, recommence — puis produit un résultat.

C'est cette boucle qui change tout : observer, agir, vérifier, corriger.

Là où l'autocomplétion accélère une action locale, l'agent prend en charge une tâche entière. Il ne remplace pas le développement logiciel, mais il en modifie profondément la granularité. Le développeur ne pilote plus seulement ligne par ligne : il peut piloter par intention.

Qu'en est-il aujourd'hui ?

Tous les grands outils de développement IA se repositionnent autour de cette idée.

GitHub Copilot propose désormais un « coding agent » capable de partir d'une issue pour produire une pull request. OpenAI présente Codex comme un agent qui traite des tâches de développement de bout en bout, de la correction routinière aux refactorings complexes. Anthropic positionne Claude Code comme un agent capable de lire une base de code, modifier des fichiers et exécuter des commandes dans le terminal ou l'IDE.

Cette évolution n'est pas qu'un argument marketing. Elle traduit une transformation plus large : les modèles raisonnent mieux sur la durée, les IDE sont plus connectés, les protocoles comme MCP facilitent l'accès aux outils, et les entreprises cherchent à automatiser les tâches répétitives du cycle logiciel.

Autrement dit, l'IA ne reste plus dans une boîte de chat. Elle entre dans Git, dans le terminal, dans les tickets, dans la CI et dans les pull requests. C'est utile. C'est aussi exactement le genre de phrase qui devrait faire lever un sourcil à n'importe quelle équipe sécurité.

Les points forts des agents…

Les agents de code brillent surtout sur les tâches bien cadrées.

Ils aident à corriger des bugs simples, ajouter des tests, migrer une API répétitive, renommer des éléments, mettre à jour une documentation, appliquer une convention de code, expliquer une base existante ou préparer une première version de pull request.

Leur force tient à leur patience mécanique. Un humain se lasse vite de modifier vingt fichiers presque identiques ; un agent, lui, ne se plaint pas. Ce qui est injuste, vu qu'il le devrait.

Ils sont aussi précieux pour explorer un projet. Un développeur qui débarque sur une base de code peut demander : « où est gérée l'authentification ? », « quels fichiers interviennent dans ce flux ? », « quelles parties risquent d'être touchées si je modifie cette fonction ? ». Un bon agent fait alors office de guide dans un système complexe.

Enfin, les agents accélèrent le passage de l'idée au prototype. Pour une petite fonctionnalité, une interface interne ou une modification bien spécifiée, ils produisent rapidement une première version. Pas forcément parfaite, mais souvent suffisante pour démarrer une revue.

… Et leurs faiblesses

Les ennuis commencent dès que la tâche devient ambiguë.

Un agent peut écrire du code qui compile sans saisir l'intention produit. Il peut traiter le symptôme plutôt que la cause. Il peut ajouter une condition spéciale au lieu de corriger une architecture fragile. Il peut produire une solution localement correcte, mais globalement mauvaise.

C'est l'un des grands pièges : l'agent donne une impression de progression. Il modifie des fichiers, lance des tests, ouvre une PR. Visuellement, il travaille. Mais l'activité n'est pas la valeur.

Les benchmarks récents le confirment : les agents progressent vite, mais restent loin d'une autonomie complète dans des environnements industriels complexes. Sur des tâches mobiles réalistes issues d'une base iOS de production, même les meilleures configurations évaluées n'atteignent que 12 % de réussite. Sur des tâches 5G, les modèles diagnostiquent souvent correctement les bugs, mais les taux de résolution restent entre 10 % et 30 %. La limite est claire : comprendre un problème et le résoudre proprement sont deux choses différentes.

Les agents gèrent aussi mal les dépendances implicites. Un humain expérimenté sait qu'un changement dans un module peut casser un comportement métier, une convention interne ou un cas limite non documenté. L'agent, lui, dépend étroitement de ce qu'on lui fournit : tests, logs, documentation, contexte, exemples, règles de projet.

Privé du bon contexte, il peut livrer une réponse très propre à un mauvais problème. L'informatique adore ce genre d'élégance inutile.

Que devient le développeur dans tout ça ?

La question n'est donc pas de savoir si les agents vont « remplacer les développeurs ». Elle est plus intéressante : que devient le travail de développement quand une partie de l'exécution peut être déléguée ?

Le développeur consacre davantage de temps à définir le problème, fournir le bon contexte, découper les tâches, poser les contraintes, relire les résultats, vérifier les impacts et décider quoi intégrer.

Il est moins l'auteur du code que le superviseur de systèmes capables d'en produire.

Cela exige de nouvelles compétences : savoir formuler une bonne demande, savoir repérer une mauvaise solution pourtant plausible, savoir concevoir des tests qui capturent vraiment l'intention, savoir limiter les permissions d'un agent, et savoir relire une PR générée par IA avec plus de suspicion qu'une PR humaine — ce qui n'est pas peu dire.

Le développement devient plus orchestral. Plusieurs agents peuvent travailler en parallèle sur des tâches distinctes. Mais quelqu'un doit encore décider quelle musique jouer, vérifier que les instruments ne se contredisent pas et empêcher le trombone de pousser en production.

L'importance des tests

Avec les agents de code, les tests ne sont plus un simple filet de sécurité. Ils deviennent une interface de pilotage.

Un agent itère bien plus efficacement quand les tests lui disent clairement ce qui échoue. Une demande vague comme « améliore ce module » est difficile à vérifier ; une demande assortie de critères d'acceptation, de tests attendus et d'exemples concrets lui offre une boucle de feedback autrement plus solide.

C'est pourquoi les entreprises qui tireront le plus de valeur des agents ne seront pas forcément celles qui achètent le meilleur outil, mais celles qui ont déjà une bonne hygiène logicielle : tests fiables, CI rapide, documentation minimale, conventions claires, architecture compréhensible, ownership identifié.

Les agents n'effacent pas les mauvaises pratiques. Ils les amplifient.

Une base de code claire devient plus facile à faire évoluer. Une base confuse devient plus facile à détériorer très vite.

Les risques à encadrer

• Sécurité : un agent qui peut lire des secrets, exécuter des commandes ou modifier des fichiers doit être bridé. Ses permissions doivent être explicites, traçables et ajustées à la tâche.
• Dette technique : un agent peut résoudre une issue avec un patch superficiel. Faute de relecture sérieuse, l'équipe accumule du code qui fonctionne aujourd'hui mais deviendra difficile à maintenir demain.
• Perte de compréhension : si les développeurs acceptent des changements sans les comprendre, l'équipe perd peu à peu la propriété intellectuelle de son propre système. Le code existe, mais plus personne ne sait vraiment pourquoi il est ainsi fait.
• Coût : les agents consomment bien plus de tokens qu'un simple assistant de chat. Ils lisent du contexte, produisent du code, relancent des tests, corrigent, recommencent. Leur coût doit être suivi, surtout lorsqu'ils travaillent longtemps ou en parallèle.

Que faut-il mettre en place ?

Pour adopter les agents de code intelligemment, il faut éviter deux excès.

Le premier : les bannir entièrement par peur du risque. Autant ignorer une évolution majeure du développement logiciel.

Le second : leur donner accès à tout en espérant que « ça ira ». Cette stratégie a déjà nourri une bonne partie de l'histoire de la cybersécurité moderne.

Une approche saine commence par des tâches limitées : documentation, tests, petites corrections, migrations répétitives, refactorings isolés, analyse de code. Les équipes élargissent ensuite progressivement le périmètre, selon la qualité observée.

Il faut aussi poser des règles simples : pas de modification critique sans revue humaine, pas d'accès inutile aux secrets, pas d'écriture en production, traçabilité des actions, tests obligatoires, description claire des changements et validation par un responsable du code.

Enfin, il faut mesurer. Combien de temps gagné ? Combien de PR acceptées ? Combien de bugs introduits ? Quel coût par tâche réussie ? Quelle part du travail demande une correction humaine ? Sans mesure, l'agent n'est qu'un objet de foi doté d'une interface moderne.

Et à l'avenir ?

Les agents de code ne sonnent pas la fin du développeur. Ils annoncent plutôt la fin d'une partie du travail répétitif, local et mécanique.

La valeur se déplace vers la compréhension du système, la formulation du besoin, la qualité des tests, l'architecture, la revue, la sécurité et la décision produit.

Bonne nouvelle pour les équipes qui savent déjà construire proprement. Mauvaise nouvelle pour celles qui espéraient que l'IA compenserait par magie l'absence de méthode.

Les agents de code deviendront probablement une couche normale de l'environnement de développement, au même titre que Git, la CI ou les linters. D'abord ils impressionnent. Ensuite ils s'intègrent. Enfin, on ne comprend plus comment on faisait sans eux — soit, en général, le moment précis où ils deviennent vraiment dangereux.

La question n'est donc pas : « faut-il utiliser des agents de code ? » La vraie question est : « quelles tâches sommes-nous prêts à leur déléguer, avec quels contrôles, et en gardant quelle responsabilité humaine ? »