Qui maîtrise le mieux Claude Code ? La réponse n'est peut-être pas un programmeur

Titre original : Agentic coding and persistent returns to expertise
Auteur original : Anthropoic
Traducteur : Peggy

Auteur original :律动BlockBeats

Source originale :

Reproduction : 火星财经

Note de l’éditeur : Ce rapport est basé sur environ 400 000 sessions avec Claude Code, et discute de la manière dont les outils de programmation IA changent la relation entre l’homme et le code.

La découverte la plus centrale de l’article est : dans la programmation par agent intelligent, l’humain décide principalement « quoi faire », tandis que Claude est responsable du « comment faire ». L’utilisateur assume la majorité des décisions de planification, tandis que Claude prend en charge la majorité de l’exécution. En d’autres termes, l’IA prend en charge la rédaction de code, la modification de fichiers, l’exécution de commandes, le débogage, etc., mais la définition des objectifs et l’évaluation des résultats restent dépendantes de l’humain.

Plus important encore, l’efficacité de l’utilisation de Claude Code ne dépend pas uniquement du fait que l’utilisateur soit programmeur. Le rapport montre que, pour les tâches de génération de code, la réussite des utilisateurs issus de professions non techniques telles que le droit, la finance, la gestion ou la recherche scientifique est désormais proche de celle des ingénieurs logiciels. Ce qui influence réellement le résultat, c’est la compréhension par l’utilisateur du problème à résoudre.

Cela signifie que la programmation IA réduit la barrière à la réalisation, mais pas celle à la jugement. À l’avenir, ceux qui comprennent le métier, le contexte, et peuvent clairement formuler leurs besoins et juger des résultats, pourraient mieux exploiter l’IA que ceux qui savent simplement coder. L’IA ne remplacera pas automatiquement la connaissance du domaine, mais amplifie plutôt la valeur de cette connaissance.

Voici le texte original :

Découvertes clés

Sur la base de recherches existantes, nous proposons un cadre pour étudier la programmation par agents intelligents interactifs. Ce cadre repose sur une analyse de la confidentialité d’environ 400 000 sessions Claude Code, réalisées entre octobre 2025 et avril 2026, afin d’évaluer la composition des tâches, la collaboration entre humains et IA, et le taux de réussite des tâches.

Dans une session typique, l’humain est responsable de la majorité des décisions de planification, c’est-à-dire de « quoi faire » ; Claude est responsable de la majorité des décisions d’exécution, c’est-à-dire de « comment faire ». Plus la connaissance de l’utilisateur dans un domaine est forte, plus la quantité de travail que Claude doit accomplir suite à chaque instruction est grande. Dans les tâches de codage, le taux de réussite moyen — c’est-à-dire la proportion de cas où l’utilisateur a obtenu ce qu’il voulait, avec des preuves vérifiables comme des tests ou des soumissions de code — est presque équivalent à celui des ingénieurs logiciels.

Plus la compétence dans le domaine est élevée, plus la session tend à réussir. Cependant, la différence entre utilisateurs intermédiaires et experts n’est pas très grande. Au cours des sept mois observés, la proportion de sessions utilisées pour le débogage a presque été divisée par deux, et la façon d’utiliser l’outil s’est orientée vers des usages plus bout en bout : déploiement et exécution de code, analyse de données, rédaction de documents non code.

Au cours de ces sept mois, la valeur des tâches typiques a augmenté dans presque tous les types de travail. En la comparant à des annonces d’emplois en freelance, nous estimons que la valeur moyenne par session a augmenté d’environ 25 %.

Introduction

La programmation par agents intelligents connaît une croissance rapide. Depuis la fin 2025, la proportion de projets sur GitHub impliquant des agents de codage a plus que doublé, et les utilisateurs de Claude Code l’utilisent en moyenne 20 heures par semaine. Peut-on, sans expérience formelle en programmation, réussir à commander un agent pour réaliser des tâches techniques complexes ? Comment cette adoption rapide et cette montée en capacité vont-elles influencer le travail intellectuel plus large ? Nous n’avons pas encore de réponse complète, mais quelques signaux précoces apparaissent dans les données d’utilisation de Claude Code.

Ce rapport s’appuie sur une analyse de la confidentialité d’environ 235 000 utilisateurs, et 400 000 interactions, entre octobre 2025 et avril 2026, pour fournir des preuves sur la façon dont Claude Code est réellement utilisé. Il poursuit nos recherches antérieures sur l’indicateur d’autonomie dans les sessions Claude Code, et sur la manière dont il modifie le fonctionnement interne d’Anthropic. Nous proposons un cadre pour décrire l’utilisation d’assistants IA interactifs : ce que les gens font, qui le fait, et si cela aboutit à un résultat réussi. Nous nous concentrons sur l’utilisation de Claude Code via l’interface en ligne de commande (CLI), Claude.ai ou l’application de bureau Claude Code. En suivant comment l’usage de la programmation par agents évolue avec l’amélioration des capacités du modèle, nous pouvons mieux comprendre l’impact de ces outils sur les professionnels de la programmation et le marché du travail du savoir.

Ce qui se passe avec Claude Code pourrait annoncer l’avenir du travail intellectuel : les agents s’intègrent progressivement dans des tâches non codantes. Nous constatons que Claude traite des tâches plus complexes et plus précieuses. En même temps, la division claire du travail dans la programmation par agents persiste : l’humain décide de ce qui doit être construit, l’agent décide de comment le construire.

Nous voyons aussi des preuves que la véritable amplification de l’efficacité des outils repose sur la connaissance du domaine, et non sur la maîtrise de la programmation. En particulier, les experts de domaine ont plus de succès, et récupèrent plus facilement d’erreurs ou de malentendus. Cependant, la différence entre utilisateurs intermédiaires et experts n’est pas très grande. Cela indique qu’avec une maîtrise suffisante dans un domaine, on peut utiliser ces outils aussi efficacement qu’un spécialiste.

Ces découvertes nous permettent d’observer une transformation potentielle du marché du travail. Dans nos données, la réussite dépend de la compréhension du problème par l’individu, et non de sa formation en programmation. Si ces modèles s’avèrent valides à l’échelle de l’économie, cela signifie que, bien que la programmation IA absorbe une partie du travail orienté réalisation, elle récompense aussi ceux qui comprennent réellement leur problème. La programmation d’agents ne remplace pas la connaissance du domaine. Au contraire, plus un travailleur comprend son domaine, plus il pourra produire un travail de haute qualité avec l’agent.

Division du travail

Ce que les gens font avec Claude Code

Pour comprendre comment les gens utilisent Claude Code, nous classons chaque session en l’une des neuf catégories d’activité, celle qui décrit le mieux l’objectif de la session. Quatre de ces catégories concernent directement la programmation ou la maintenance : construire quelque chose de nouveau, réparer quelque chose de cassé, tester du code, ou orchestrer d’autres agents ou pipelines automatisés. Une autre concerne l’opération de logiciels : déploiement, configuration, exécution de pipelines, surveillance. Deux autres sont plus orientées vers la compréhension du « quoi faire » : comprendre le fonctionnement d’un système existant, ou planifier des changements avant de commencer à agir. Enfin, deux catégories ne concernent pas le code ou ne l’utilisent qu’en support : analyser des données, ou communiquer via des présentations ou autres documents textuels.

Environ 56 % des sessions consistent en écriture de code (25 %), réparation de code (26 %), ou test et orchestration de code (5 %). La gestion de logiciels représente 17 %, la planification ou exploration 14 %, l’analyse ou la rédaction de textes 13 % (voir figure 1).

Nous faisons d’abord lire le transcript de la session par le modèle, puis le classons ; ensuite, à l’aide de notre outil d’analyse de confidentialité, nous croisons ces classifications avec les données télémétriques enregistrées automatiquement pour chaque session, notamment si du code a été ajouté ou supprimé. La forte cohérence entre ces deux sources est notable. Par exemple, dans les sessions classées comme création ou modification de code, plus de 90 % montrent aussi dans les données télémétriques des changements de code. Voir annexes pour plus de détails.

Qui prend les décisions

Quelle autonomie a Claude Code ? Son potentiel est déjà élevé, et continue de croître. Par exemple, dans des benchmarks comme METR, les modèles avancés peuvent désormais réaliser de façon autonome des tâches logicielles qui prenaient auparavant plusieurs heures à un humain, en surmontant eux-mêmes certains obstacles. Mais qu’en est-il dans la pratique ? Ici, nous étudions la part de guidage que l’humain et Claude prennent dans une session réelle.

Nous abordons cette question sous deux angles. D’abord, dans quelle mesure l’humain délègue-t-il la décision à Claude ? Ensuite, combien d’actions l’humain confie-t-il à Claude ? Pour comprendre la division des décisions dans une session, nous avons construit un classificateur d’attribution de décisions, basé sur le contenu de la session, qui respecte la confidentialité. Ce classificateur liste toutes les décisions significatives, et les classe en décisions de planification (quoi faire, comment faire, quand considérer une tâche comme terminée) ou en décisions d’exécution (quels fichiers modifier, quel code écrire, dans quelle langue, quelles commandes exécuter). Ensuite, il attribue chaque décision à Claude ou à l’humain, et génère deux chiffres par session : la proportion de décisions de planification prises par l’humain, et celle de décisions d’exécution.

En moyenne, l’humain prend environ 70 % des décisions de planification, mais seulement 20 % des décisions d’exécution (voir figure 2). Dans la pratique, la programmation par agent montre une division claire du travail : l’humain décide « quoi construire », l’agent décide « comment le construire ».

Pour comprendre le degré de délégation des actions dans une session, nous ne regardons pas le contenu, mais la structure. Une session Claude Code consiste en une série d’échanges entre Claude et l’utilisateur : l’utilisateur envoie une invite, Claude agit ; puis l’utilisateur envoie une nouvelle invite, etc. En session typique, il y a environ quatre tours. Dans nos données d’octobre à avril, chaque invite de l’utilisateur déclenche en moyenne une dizaine d’actions de Claude, pouvant parfois dépasser 100 actions. À chaque tour, Claude lit des fichiers, modifie du code, exécute des commandes, et produit en moyenne 2 400 mots.

La quantité de travail que Claude accomplit entre deux vérifications par l’utilisateur dépend beaucoup de qui décide. Quand l’utilisateur garde le contrôle de l’exécution — c’est-à-dire qu’il prend plus de 80 % des décisions d’exécution —, Claude effectue moins d’actions par tour, environ 8. Quand Claude contrôle la planification — plus de 80 % des décisions de planification —, il effectue le plus d’actions, environ 16.

Niveau de compétence

Selon chaque session, Claude évalue le niveau apparent de compétence de l’utilisateur sur la tâche, sur une échelle de cinq niveaux, du débutant à l’expert. Le classificateur de compétence se base sur trois signaux : la précision des instructions données par l’utilisateur, ce que l’utilisateur demande à Claude de vérifier, et si l’utilisateur corrige plus souvent Claude ou vice versa. Il est important de noter que ce niveau de compétence est totalement distinct du poste ou des capacités générales, et qu’il est spécifique à la tâche. Par exemple, un ingénieur expérimenté qui pose une question sur Rust peut être considéré comme débutant pour cette tâche. Un comptable qui n’a jamais utilisé Python, mais qui peut expliquer précisément à Claude quelles règles de réconciliation doivent être appliquées dans un script Python, et repérer des erreurs lors de la clôture mensuelle, sera considéré comme expert pour cette tâche.

Le tableau ci-dessous montre comment nous définissons chaque niveau dans le classificateur, avec un exemple de requête tirée du dataset public SWE-chat. Les dialogues classés comme « débutant » donnent des instructions vagues, sans connaissance spécifique du domaine ; ceux classés comme « expert » transmettent une compréhension approfondie du code et de l’environnement technique.

Nous quantifions la relation entre le niveau de compétence et la quantité de sortie et d’activité générée par Claude par prompt. Dans une session typique de débutant, chaque prompt déclenche environ 5 actions de Claude, et une sortie d’environ 600 mots ; dans une session d’expert, la chaîne d’actions est plus longue, environ 12 actions, avec une sortie d’environ 3 200 mots, soit cinq fois plus (voir figure 3). La différence entre débutant et expert apparaît dans tous les types de travail et toutes les plages de valeur de tâche.

Ces indicateurs complètent nos recherches antérieures sur l’autonomie de Claude Code. Ces études suivaient la durée de fonctionnement de l’agent, et la fréquence à laquelle l’utilisateur approuvait automatiquement ses actions. En revanche, nos indicateurs d’attribution de décisions captent qui prend des décisions substantielles dans toute la session, tandis que le nombre d’actions ou la quantité de sortie par prompt mesurent dans quelle mesure chaque instruction humaine peut déclencher une activité autonome de Claude.

Qui utilise Claude Code, et pour quoi faire

Utilisateurs

Pour comprendre qui fait ces travaux, nous inférons la profession de chaque utilisateur à partir des transcripts, puis la mappons à l’un des 23 grands groupes de la classification SOC de l’US Bureau of Labor Statistics. Le classificateur ne se base que sur certains signaux : le contexte chargé au début de la session, le nom et la structure des fichiers, les références citées par l’utilisateur (documents juridiques, données cliniques, rapports financiers, supports de cours, etc.), et le vocabulaire employé. Il est explicitement interdit de considérer « écrire du code » comme preuve d’une profession de programmeur. La seule condition pour classer une session dans une catégorie liée à la programmation est la présence de signaux clairs indiquant une activité logicielle ou de traitement de données. Par exemple, si un avocat construit un script pour vérifier automatiquement l’absence de clauses dans un contrat, même si la session consiste principalement à écrire du logiciel, elle sera classée dans la catégorie « Profession juridique ». Si aucun signal ne permet d’identifier la profession de l’utilisateur, la session ne sera pas classée.

Nous pouvons inférer la profession dans environ 70 % des sessions. Parmi ces sessions classables, la catégorie « Profession dans l’informatique et les mathématiques » est la plus représentée, ce qui n’est pas surprenant puisqu’elle couvre la majorité des travaux liés au logiciel. Viennent ensuite les secteurs des affaires et de la finance, de l’art et des médias, de la gestion, ainsi que des sciences de la vie, de la physique et des sciences sociales. Parmi nos échantillons, les groupes professionnels non liés au logiciel qui croissent le plus rapidement sont la gestion, la vente et le droit.

Travail

De octobre 2025 à avril 2026, la composition des tâches réalisées avec Claude Code a fortement évolué. La baisse la plus notable concerne les sessions de réparation de code cassé, qui passent de 33 % à 19 % (voir figure 4). À l’inverse, les activités autour du code ont augmenté : gestion de logiciels de 14 % à 21 %, rédaction et analyse de données environ doublées, passant d’environ 10 % à 20 %.

La valeur économique des tâches a aussi augmenté. En estimant le coût de travaux similaires sur le marché freelance, calibré avec des données réelles d’offres d’emploi, nous estimons que la valeur moyenne par session a augmenté de 27 % entre octobre et avril. Cette augmentation concerne plusieurs types de travail : la construction, la gestion et la réparation de code ont respectivement augmenté d’environ 43 %, 34 % et 32 %. Ces estimations de prix étant approximatives, elles servent surtout à repérer des tendances temporelles, et non à donner une valeur en dollars directement exploitable. Pour plus de détails sur la construction de cet estimateur, voir annexes.

Ce que l’efficacité dépend de ce que l’utilisateur apporte

L’estimation de la valeur d’une tâche est une façon d’appréhender comment Claude Code aide à réaliser un travail. Un autre aspect est de voir combien de sessions aboutissent à un succès, et quels traits de session y contribuent. Dans tous nos indicateurs de succès, un schéma clair apparaît : plus le niveau de compétence apparent de l’utilisateur dans la session est élevé, plus la probabilité de succès est grande. La majorité de cette amélioration se concentre dans la partie inférieure de l’échelle, c’est-à-dire que la différence entre débutant et intermédiaire est plus grande que celle entre intermédiaire et expert.

Avant d’analyser les caractéristiques des sessions réussies, il faut définir précisément ce qu’on entend par succès. Nous ne pouvons pas observer directement les résultats dans le monde réel, ni demander aux utilisateurs s’ils ont réussi à faire ce qu’ils voulaient avec Claude. Nous utilisons donc deux méthodes complémentaires, basées sur l’analyse des transcripts. La première est une « détection de succès » par un classificateur qui, après lecture complète de la session, juge si l’objectif initial a été atteint, avec des options : succès, succès partiel, échec, ou objectif non clair. Deux autres classificateurs évaluent la force de la preuve de succès, en cherchant des éléments vérifiables, notamment des activités git (commit, pull request), la réussite de tests, ou la reconnaissance explicite de l’utilisateur. Ils attribuent une note de 1 (aucun signal) à 5 (plusieurs signaux forts). Un classificateur parallèle évalue aussi la présence de preuves d’échec, comme erreurs, échecs de tests, tentatives répétées, ou opposition de l’utilisateur. La réussite vérifiée nécessite que la session soit jugée comme réussie, et qu’au moins un signal fort de succès soit présent. Notre analyse se concentre sur le degré de succès ou d’échec dans la session, en excluant celles où la détection de succès indique « objectif non clair », ce qui représente environ 7,7 % de l’échantillon.

Les retours sur le niveau de compétence

Quels types de sessions ont le plus de chances de réussir ? Les résultats montrent que le score de compétence apparent, mentionné ci-dessus, a une forte influence sur la réussite.

Certains pourraient craindre que le niveau de compétence ne soit qu’un proxy, et que ce soit en réalité la nature des tâches ou d’autres facteurs qui expliquent la réussite. Dans cette section, en comparant des sessions du même type de travail, avec la même valeur estimée, au même mois, sur le même sujet, et provenant du même groupe professionnel, nous répondons en partie à cette crainte, en examinant comment la compétence influence le résultat.

Dans tous nos indicateurs, plus le niveau de compétence apparent est élevé, plus la session a de chances d’être réussie. Les sessions classées comme « débutant » ont un taux de succès vérifié de 15 %, et 77 % au moins partiellement réussies. Celles classées comme « intermédiaire » ou supérieur ont un taux de succès vérifié entre 28 % et 33 %, et un taux de succès partiel entre 91 % et 92 % (voir figure 5).

Dans chaque indicateur, la majorité des gains provient de la progression du débutant à l’intermédiaire ; la progression de l’intermédiaire à l’expert est plus faible. Voir détails de l’analyse de régression derrière la figure 5 en annexes.

Même dans les sessions où la détection d’échec est présente, on observe une tendance similaire. Lorsqu’un signal d’échec vérifiable est enregistré, on considère que la session « rencontre un problème ». Cela peut inclure des erreurs, des échecs de tests, des tentatives multiples pour la même tâche, ou une expression de frustration par l’utilisateur. Dans ces sessions « problématiques », après contrôle de tous ces facteurs, la proportion de succès vérifié passe de 4 % pour les débutants à 15 % pour les experts (voir figure 5). Si l’on utilise une définition plus large de succès, on trouve que la part de succès partiel est de 60 % chez les débutants, et de 80-81 % chez les intermédiaires et experts.

Nous avons aussi suivi une relation inverse : celle entre le niveau de compétence et certains indicateurs d’échec. Il faut noter que, dans cette analyse, une session déclarée comme échouée est une session où aucun succès partiel n’a été atteint. Si une session problématique est déclarée comme échouée, et qu’aucune ligne de code n’a été écrite, on parle d’abandon. Chez les débutants, 19 % de ces sessions sont abandonnées, contre 5 à 7 % pour les autres groupes. En d’autres termes, les utilisateurs avec moins d’expérience abandonnent plus souvent lorsqu’ils rencontrent des difficultés pour atteindre leur objectif. La maîtrise d’un domaine semble aussi valorisée par la capacité à ramener l’agent dans la bonne direction.

Le métier pourrait être moins important que le niveau de compétence

Les utilisateurs issus de professions liées au logiciel ont un taux de succès vérifié d’environ 30 %, contre 26 % pour les autres. Dans les sessions où du code est généré, c’est-à-dire au moins une ligne ajoutée ou modifiée, ces chiffres sont respectivement de 34 % et 29 % (voir figure 6). En utilisant une définition plus large de succès, la différence entre professions liées au logiciel et autres se réduit encore. Dans ces sessions, la proportion de succès partiel est de 89 % pour les professionnels du logiciel, et 88 % pour les autres. La différence de cinq points de pourcentage est stable sur sept mois, sans s’accroître ni diminuer, même si les taux de réussite augmentent pour tous. Dans nos dix plus grands groupes professionnels, la différence de réussite entre ces groupes et les ingénieurs logiciels ne dépasse pas sept points de pourcentage. La gestion affiche le taux de succès vérifié le plus élevé, légèrement supérieur à celui des professionnels du logiciel. La réussite plus élevée des gestionnaires pourrait refléter une transférabilité des compétences managériales à la conduite d’un agent. Mais cela pourrait aussi venir de notre méthode de mesure : la validation dépend en partie de la confirmation explicite de l’utilisateur, et les gestionnaires sont peut-être plus habitués à exprimer leur satisfaction quand ils obtiennent le résultat voulu.

Perspectives

Ce rapport esquisse une image en train de se former : la programmation par agents amplifie certains savoirs et compétences, tout en en remplaçant d’autres. Dans les sessions de génération de code, la réussite des principales professions est proche de celle des professionnels du logiciel. Il semble que la capacité à coder dans l’agent devienne moins déterminante pour réussir une tâche de programmation.

Par ailleurs, la réussite des sessions est plus souvent associée à la connaissance du domaine. Les sessions d’experts ont un taux de succès vérifié deux fois supérieur à celui des débutants. Lorsqu’un problème survient, la proportion de débutants qui abandonnent est plusieurs fois plus élevée. La façon dont la collaboration fonctionne est aussi révélatrice : les experts peuvent guider Claude pour faire plus de travail avec chaque instruction. La capacité à amener Claude vers la réussite dépend donc davantage de la maîtrise du domaine que de la capacité à écrire du code. Toute personne maîtrisant un domaine peut désormais réaliser des tâches techniques auparavant hors de portée. Ceux qui manquent de cette compréhension spécialisée, même avec le même outil, en tireront beaucoup moins. Et la majorité des bénéfices provient de la compétence, pas de la maîtrise approfondie. Avoir une compréhension opérationnelle d’un domaine suffit pour en tirer la majorité des gains ; la spécialisation approfondie n’apporte qu’un avantage marginal supplémentaire.

Ces découvertes restent préliminaires. Comme dans la plupart de nos études, nous ne pouvons mesurer directement les résultats dans le monde réel, comme si le code généré était utilisé ou abandonné, ou s’il a produit une valeur économique. De plus, ce rapport exclut l’usage non interactif, qui constitue une part importante de l’activité. Développer un cadre pour mesurer ce type d’usage sera une étape clé pour les travaux futurs. Enfin, toutes nos classifications reposent sur la lecture des transcripts par le modèle. Dans l’annexe, nous montrons que le classificateur reste cohérent avec des données télémétriques indépendantes, et qu’il est généralement en accord avec des jugements de référence. Mais, à grande échelle, la validation du classificateur reste difficile ; les sessions Claude Code étant souvent longues et complexes, il est difficile de faire une annotation humaine de référence.

À mesure que les modèles, les utilisateurs, et la division du travail évoluent, l’image présentée ici continuera de se modifier. Nous espérons que ces indicateurs pourront suivre ces changements majeurs. Par exemple, si à l’avenir la valeur du niveau de compétence diminue, cela indiquerait que le modèle fournit désormais des jugements clés, et que ses bénéfices s’étendent au-delà des experts pour toucher un public plus large. Si la proportion d’utilisateurs hors du secteur logiciel qui réussissent à faire coder leur tâche continue d’augmenter, cela pourrait signifier que la production logicielle devient une activité courante dans tous les domaines, et plus seulement une spécialité. Ces transformations changeront qui pourra bénéficier de la programmation par agents, et dans quelle mesure.