Pourquoi la plupart des développeurs tirent encore peu de bénéfices des agents de codage.

Deux études menées en 2026, l’une par JetBrains et l’autre par Anthropic, donnent des chiffres sur la manière dont les ingénieurs travaillent réellement avec des agents de codage. Ensemble, elles affirment que la différence entre tirer un avantage d’un agent et en recevoir du bruit réside dans la façon dont le travail est délégué, et non dans le choix du modèle.

L’idée principale est que le codage par IA n’est plus une expérience ; la distinction importante aujourd’hui concerne plutôt la différence entre demander à un modèle d’écrire du code et lui déléguer véritablement des tâches d’ingénierie.

AI coding is no longer an experiment.

90% of professional developers now use coding agents at least weekly.

But there is a big difference between asking AI to write code
and actually delegating engineering work to an agent.

Pourquoi une application de trading est un bon test

Imaginons une application de trading pour iOS conçue pour une société de valeurs mobilières. UIKit et SwiftUI coexistent, avec MVVM et Clean Architecture en surcouche. Dans ce type de base de code, un chiffre erroné à l’écran de confirmation d’ordre ne devient pas une demande de correction de bug ; il s’agit plutôt d’un appel du département de conformité.

Pour une équipe dans cette situation, confier du travail réel à un agent de codage ne relève pas de la vitesse. Ce qu’il faut surveiller, c’est le moment où l’agent commet discrètement une erreur sans que personne ne s’en aperçoive. Étudier ce moment enseigne davantage sur les méthodes de travail des agents que n’importe quel cours, et les données de 2026 expliquent pourquoi.

Ce que l’enquête de JetBrains a révélé

Entre mai et juillet 2026, JetBrains a interrogé plus de 15 000 développeurs en activité. Neuf sur dix ont déclaré utiliser des agents de codage basés sur l’IA au moins une fois par semaine, et 68 % le font quotidiennement.

Claude Code occupe la première place avec 39 % dans le monde et 47 % aux États-Unis, soit presque le double de GitHub Copilot qui affiche 21 %, chiffre en baisse par rapport aux 29 % de l’année précédente. Codex, quant à lui, est passé de 3 % à 16 %.

Un rapport complémentaire présente un chiffre encore plus intéressant : les développeurs estiment qu’environ 47 % de leur code est désormais entièrement écrit par des agents, plus de la moitié d’entre eux écrivant manuellement moins de 20 % de leur code, et un développeur sur cinq ne rédigeant aucun code sans l’aide de l’IA.

L’expérience n’a pas freiné l’adoption ; elle l’a plutôt favorisée. Environ un développeur senior sur quatre fait produire par des agents plus de 80 % de son code, proportion supérieure à celle des développeurs juniors qui préfèrent une aide ligne par ligne. Cela contredit l’idée selon laquelle l’IA rend les juniors redondants. Ceux qui possèdent le meilleur jugement délèguent le plus, et ce n’est certainement pas un hasard.

Ce que révèlent 400 000 sessions

L’étude menée par Anthropic portait sur environ 400 000 sessions interactives de Claude Code réalisées par près de 235 000 utilisateurs, enregistrées d’octobre 2025 à avril 2026. La répartition est plus simple que ce que la communication marketing pourrait laisser penser :

• Les tâches liées au codage représentaient 56 % des sessions, réparties comme suit : 25 % pour l’écriture, 26 % pour la correction et 5 % pour les tests ou l’orchestration.
• L’utilisation de logiciels occupait 17 % des sessions.
• La planification et l’exploration représentaient 14 % des sessions.
• L’analyse et la rédaction correspondaient à 13 % des sessions.

La conclusion la plus importante concerne celui qui décide de quoi faire. Les humains prennent environ 70 % des décisions relatives à la planification, tandis que Claude prend environ 80 % des décisions concernant l’exécution. Les humains se chargent du quoi, tandis que l’agent s’occupe du comment.

Personne n’a conçu cette division. C’est l’équilibre auquel des centaines de milliers d’ingénieurs sont parvenus indépendamment, car il fonctionne. De nombreuses plaintes concernant les agents de codage proviennent de personnes qui ont inversé la logique, en se concentrant d’abord sur le quoi avant de se disputer avec l’agent au sujet du comment.

Les compétences influencent le résultat

Ici, les chiffres contredisent ceux qui pensent que « n’importe qui peut coder aujourd’hui ». Les sessions ont été évaluées en fonction des compétences apparentes de l’utilisateur dans le domaine, à travers trois critères : la précision des instructions, ce que l’utilisateur demandait à Claude de vérifier, et la manière dont les corrections étaient apportées. Les résultats ont ensuite été comparés côte à côte.

Commencez par les deux premières lignes. Les experts ne tapent pas plus. Une seule instruction d’un expert produit plus du double du travail accompli sans supervision : douze actions contre cinq pour un novice, même si le modèle, l’outil et le prix sont identiques. Le message de l’expert contient suffisamment de contexte pour que l’agent n’ait jamais besoin de s’arrêter et de deviner.

La dernière ligne est tout aussi importante. Lorsqu’une session prend une mauvaise direction, environ 19 % des novices abandonnent sans avoir produit de code, contre 5 à 7 % des experts. La compétence décisive n’est pas la formulation de l’instruction, mais plutôt la capacité à ramener une session déviée sur la bonne voie.

Une phrase du rapport résume bien cela : avec les novices, Claude a tendance à corriger l’utilisateur, tandis qu’avec les experts, c’est l’utilisateur qui corrige Claude. C’est là la frontière entre utiliser un agent et être géré par lui.

Le cycle en trois étapes qui échoue

Une routine courante se présente comme suit :

Bad:
Prompt → AI writes code → Accept

Deux de ces trois étapes relèvent de l’agent. Il n’y a ni exigence, ni contexte, ni plan, ni vérification. Ce n’est pas déléguer un travail d’ingénierie ; c’est plutôt effectuer une complétion automatique à plus grande échelle en espérant que le résultat soit correct.

Un cycle en sept étapes fiable

La routine qui a résisté au contact avec une application de trading en production comporte sept étapes :

Better:
Requirement
↓
Context
↓
Plan
↓
Agent implementation
↓
Build
↓
Tests
↓
Human review

L’ingénieur est responsable des trois premières étapes et des deux dernières, tandis que l’agent s’occupe de ce qui se trouve entre elles. Cette répartition correspond aux résultats de la recherche, avec un partage 70/30 pour la planification et 80/20 pour l’exécution, représenté sous forme de pipeline. Chaque étape a son propre coût.

Exigence

Une phrase telle que « Ajouter une feuille de confirmation au flux de commande » compte comme une tâche. Un agent peut créer quelque chose qui est techniquement correct mais fonctionnellement erroné. Une exigence valable implique bien plus que cela :

Order confirmation sheet, SwiftUI, presented from OrderEntryViewController.

Must show: instrument code, side (BUY/SELL), quantity in lots,
limit price, estimated total including fee, and account buying power
AFTER the order.

Buying power must be recomputed, never passed in from the entry screen.
If recompute fails, disable confirm and show the retry state.
Never show a stale number next to a confirm button.

La dernière ligne de cette spécification concerne les connaissances sectorielles, que aucun modèle ne possède. C’est ce qui distingue un écran fonctionnel d’un écran donnant lieu à une décision réglementaire. Cela correspond au signal de « précision de la direction » de la recherche, et c’est le point le plus facile à corriger.

Contexte

Lorsque UIKit et SwiftUI coexistent dans le cadre de l’Architecture Propre, un agent crée son propre schéma s’il n’y en a pas de prédefini, et chaque schéma inventé devient par la suite un commentaire dans les revues. Ainsi, l’agent est d’abord orienté vers des exemples concrets : le protocole du cas d’utilisation actuel, une implémentation de repository, le ViewModel qui remplit la fonction la plus proche, ainsi que le fichier CLAUDE.md du module contenant ses règles de hiérarchisation. Trois fichiers et un document de conventions surpassent à chaque fois trois paragraphes d’explication. Presque tout le monde saute cette étape, bien qu’elle rapporte les meilleurs résultats.

Plan

Demandez un plan avant tout code, indiquant quels fichiers changent, quel niveau gère chaque modification, ce que le ViewModel expose et ce qui reçoit un test. Lisez-le comme s’il s’agissait d’une description de PR. Refuser un plan prend environ quatre-vingt-dix secondes. Refuser une implémentation prend vingt minutes et laisse un diff qui doit être mentalement ignoré.

Environ un tiers des plans est modifié, presque toujours en raison d’une question liée à la hiérarchisation des composants, comme le fait pour l’agent de placer un calcul dans le ViewModel alors qu’il devrait se trouver dans un cas d’utilisation. Corriger cela en prose est simple, tandis que le faire en Swift ne l’est pas.

Implémentation

Avec le plan convenu, mettez-vous de côté. C’est ici que se trouvent 80 % des décisions relatives à l’exécution : la nommage, le flux de contrôle, la manière de structurer un diff, quel petit outil d’aide extraire. Interrompre pour critiquer le nom d’une variable est ce qui transforme une session prévue pour douze actions en une ne comptant que cinq. Cela oblige également des ingénieurs seniors à consacrer leur temps pour obtenir un résultat de la part d’ingénieurs juniors.

Vérification

L’instruction la plus efficace stipule que le travail n’est terminé qu’une fois que le code compile et que les tests passent, l’agent exécutant ces tâches de manière autonome. La recherche décrit cela comme ce que l’utilisateur demande à Claude de vérifier, et c’est le signal que les gens sous-estiment le plus longtemps. Un agent capable d’exécuter xcodebuild ainsi que les tests associés ferme son propre cycle. Celui qui ne possède pas cette capacité renvoie un brouillon en le qualifiant de fonctionnalité.

Pour la feuille de confirmation, réussir les tests signifie que les comportements spécifiques ont été listés au préalable. Le pouvoir d’achat doit être recalculé lors de la présentation de la feuille, le bouton de confirmation doit rester désactivé pendant ce recalcul, et les calculs des frais doivent correspondre aux paramètres déjà présents dans le dépôt.

Revue

Chaque ligne est lue. Ce n’est pas parce que le code est généralement mauvais, car ce n’est pas le cas en règle générale. La revue est le moment où l’expertise humaine doit encore intervenir dans le système. La lecture vise ce que la compilation ne peut pas détecter : si le changement respecte les limites des couches, si la règle de arrondi est bien celle utilisée en finance, et si la machine à états gère correctement la perte de connexion au milieu d’une confirmation.

Cette étape représente également le véritable plafond de productivité. Un agent peut générer plus de travail que quiconque ne peut en examiner de manière responsable, et la tendance à le parcourir rapidement constitue le véritable danger de tout ce flux de travail. Le risque n’est pas tant l’hallucination que la fatigue.

Où se dirige le travail

La tendance sur sept mois au sein des 400 000 sessions mérite une attention particulière :

• La part des sessions consacrées au débogage a diminué, passant d’un tiers (33 %) à 19 %.
• L’exécution de logiciels en cours d’exploitation a grimpé à 21 % après avoir commencé à 14 %.
• L’écriture ainsi que l’analyse de données ont presque doublé, passant d’environ un dixième à environ un cinquième des sessions.

La recherche de bogues prend moins de temps, tandis que la gestion et l’analyse des systèmes en cours d’exécution demandent plus de temps. Au cours de la même période, la valeur estimée des tâches a augmenté d’environ 25 %, et celle des tâches de développement a grimpé d’environ 43 %. Le travail ne disparaît pas ; il se déplace vers un niveau supérieur, loin de la simple rédaction d’implémentations pour se concentrer sur leur spécification, leur orchestration et leur vérification, ce qui correspond à la manière dont un ingénieur senior avec une équipe a toujours travaillé.

Le goulot d’étranglement, c’est la boucle

Neuf développeurs sur dix utilisent ces outils chaque semaine, pourtant seulement de 15 à 33 % des sessions se terminent par un succès vérifié. Ainsi, le modèle n’a jamais été la contrainte ; la plupart des gens suivent simplement une boucle en trois étapes avec un outil conçu pour sept étapes.

Améliorer la formulation de l’instruction ne résoudra pas le problème. La solution consiste à établir des critères dès le départ, c’est-à-dire à définir ce qui est « correct » et à vérifier à la fin que ces critères ont été respectés. L’agent s’occupe du reste et le fait bien, en fonction de la clarté avec laquelle les limites ont été définies.

En 2026, ceux qui tirent le meilleur parti des agents de codage ne sont pas ceux qui rédigent les instructions les plus ingénieuses. Ce sont plutôt eux qui décident de ce que signifie « terminé ».