Coder avec l’IA : déléguer sans perdre la maîtrise

Les agents de programmation accélèrent certaines tâches, mais leur supervision repose sur des compétences qu’il faut continuer à exercer. Ce que les études et les ingénieurs permettent réellement d’affirmer.

Un agent de programmation peut écrire du code, lancer des commandes et enchaîner plusieurs étapes sans attendre une instruction à chaque fois. Le travail du développeur se déplace alors : moins de saisie, davantage de cadrage et de vérification. Reste une question moins visible que le gain de temps : si l’on pratique moins certaines tâches, comment garder les compétences nécessaires pour repérer une erreur ou reprendre la main ?

Ce risque est discuté par des ingénieurs qui utilisent ces outils au quotidien, mais il ne faut pas le confondre avec une perte durable de compétence démontrée chez tous les développeurs. Les éléments disponibles décrivent surtout des usages, des perceptions et des expériences limitées à des tâches précises. Ils permettent néanmoins de comprendre où la délégation peut devenir fragile, et comment rendre le contrôle plus concret.

Déléguer du code ne signifie pas déléguer la responsabilité

Dans un texte consacré à l’usage des agents de programmation, Addy Osmani, ingénieur chez Anthropic et membre de l’équipe Claude Code, distingue trois degrés de délégation. Au premier, l’agent produit une proposition que la personne examine. Au deuxième, cette proposition devient le point de départ du travail. Au troisième, elle est adoptée sans véritable contrôle. Les chercheurs de Wharton désignent cette attitude par l’expression « capitulation cognitive ».

La différence tient moins à l’outil qu’au rôle que l’utilisateur conserve. Un développeur peut laisser un agent rédiger une fonction tout en restant responsable de comprendre ce qu’elle fait, de vérifier qu’elle répond au besoin et de décider si elle peut être intégrée. À l’inverse, une réponse techniquement plausible peut être acceptée parce qu’elle est bien présentée ou parce que le premier test passe.

Un test qui réussit ne démontre pourtant que ce qu’il vérifie. Si le test reprend une hypothèse erronée de la fonction qu’il est censé contrôler, les deux peuvent échouer ensemble à détecter le problème. La vérification utile consiste donc aussi à examiner la portée du test : quels cas couvre-t-il, lesquels laisse-t-il de côté, et quelles suppositions faut-il croire pour que le résultat soit fiable ?

Les gains d’usage ne mesurent pas l’apprentissage

Une étude publiée par Anthropic en 2025 donne un aperçu des changements observés au sein de l’entreprise. Elle s’appuie sur une enquête auprès de 132 ingénieurs et chercheurs, 53 entretiens et l’analyse de 200 000 transcriptions internes de Claude Code, recueillies en février et en août 2025. Dans l’enquête, les salariés estimaient utiliser Claude dans 59 % de leur travail et lui attribuaient un gain de productivité moyen de 50 %. Ces chiffres sont déclaratifs : ils décrivent leur perception, pas une mesure indépendante du temps réellement économisé.

L’analyse des transcriptions montre, elle, une évolution de la répartition des usages. Entre février et août, la proportion des transcriptions classées comme portant sur l’implémentation de nouvelles fonctionnalités est passée de 14,3 % à 36,9 %, et celle classée comme portant sur le design ou la planification du code de 1 % à 9,9 %. L’outil enchaînait aussi davantage d’actions avant une nouvelle intervention humaine. Ces résultats indiquent que les équipes confiaient à Claude Code des tâches plus complexes ou plus autonomes. Ils ne mesurent pas, à eux seuls, une hausse du volume total de travail ni le niveau de compétence de chaque personne.

Les entretiens révèlent le revers possible de cette évolution. Certains participants disent gagner en aisance dans des domaines qu’ils maîtrisaient peu, parce que l’IA facilite la création d’une première version ou l’exploration d’un nouveau code. D’autres s’inquiètent de moins apprendre en résolvant eux-mêmes les problèmes : lire la documentation, examiner le fonctionnement d’un outil ou suivre une erreur peut transmettre des connaissances qui ne sont pas indispensables à la correction immédiate, mais qui aident ensuite à comprendre l’ensemble du système.

Anthropic précise que ses participants sont des employés d’une entreprise qui développe ces outils et y ont accès dans un contexte particulier. Les réponses peuvent aussi être influencées par la sélection des personnes interrogées et par le caractère déclaratif de certaines mesures. Ce travail éclaire des arbitrages observés dans cette organisation ; il ne permet pas de conclure que les développeurs, en général, perdent durablement leurs compétences lorsqu’ils utilisent l’IA.

Superviser suppose de savoir ce qu’on contrôle

C’est le paradoxe pratique de la supervision : pour évaluer le code d’un agent, il faut disposer d’assez de connaissances pour repérer ce qui est dangereux, incomplet ou mal adapté. Or les participants interrogés par Anthropic expriment précisément des inquiétudes sur le maintien de compétences qui servent à écrire le code comme à le critiquer. Quelques-uns disent donc réserver des moments à la programmation sans IA, afin de continuer à exercer ce savoir-faire.

Ce choix ne répond pas à toutes les questions. Il reste notamment à déterminer quelles compétences sont indispensables dans un travail où les outils changent les tâches confiées aux ingénieurs. Certains salariés interrogés envisagent un déplacement vers la conception, la revue ou la coordination d’agents. D’autres regrettent la pratique directe du code ou s’interrogent sur la formation des débutants. L’étude rapporte ces points de vue ; elle ne tranche pas l’avenir du métier.

Les résultats d’une autre étude, discutée par ses auteurs dans Wharton Magazine, attirent l’attention sur l’acceptation d’une réponse générée. Des participants pouvaient consulter ChatGPT pour résoudre des questions de logique et de raisonnement. Steven Shaw explique que, dans les expériences, les personnes ayant consulté l’outil adoptaient fréquemment sa réponse, y compris lorsque celle-ci était incorrecte. Ces exercices éclairent un comportement dans une situation expérimentale ; ils ne mesurent ni la qualité du travail d’un développeur en entreprise ni une érosion durable de ses capacités.

Un contrôle adapté à l’enjeu

Addy Osmani ne recommande pas de vérifier chaque tâche avec la même intensité. Une délégation peu risquée et facile à corriger ne demande pas nécessairement le même examen qu’un changement susceptible d’affecter la sécurité, les données ou la mise en production. Avant une tâche importante, il propose de formuler sa propre hypothèse, puis de chercher ce qui pourrait rendre la réponse de l’agent fausse. Il conseille aussi de lui demander d’expliciter ses choix et les valeurs par défaut qu’il a utilisées.

Pour un changement logiciel, ces étapes peuvent se traduire en questions concrètes : quel comportement doit changer ? Quelles parties du système seront touchées ? Quels cas le test couvre-t-il réellement ? L’agent a-t-il introduit une dépendance ou une supposition que l’équipe n’a pas examinée ? Une revue utile ne consiste pas seulement à relire le résultat ; elle confronte ce résultat à des critères définis avant de l’accepter.

La question n’est donc pas de choisir entre écrire chaque ligne soi-même et tout laisser faire à un agent. Il s’agit de décider quelles opérations peuvent être déléguées, de garder assez de compréhension pour superviser les décisions importantes et de vérifier que les habitudes de travail continuent de produire les compétences nécessaires. La rapidité d’exécution est visible dès qu’un code est généré. La capacité à le reprendre, elle, se mesure quand il faut l’expliquer, le corriger ou le faire évoluer.