Assistants IA : pourquoi des développeurs expérimentés ont travaillé 19 % plus lentement

L’intelligence artificielle est souvent présentée comme un accélérateur évident du travail des développeurs : elle complète du code, propose des correctifs et rédige des fonctions en quelques secondes. Pourtant, lorsqu’elle est testée sur des tâches réelles, dans des projets complexes et connus de leurs mainteneurs, elle peut produire l’effet inverse. C’est le constat déroutant d’une étude de l’institut Model Evaluation and Threat Research, METR, rendue publique le 10 juillet 2025.

Dans cette expérimentation, des développeurs chevronnés ont mis 19 % de temps supplémentaire à mener leurs tâches à bien lorsqu’ils disposaient d’un assistant de programmation fondé sur l’IA. Le résultat ne signifie pas que l’IA est inutile pour écrire du code. Il invite plutôt à regarder ce que recouvre concrètement le mot « productivité » : dans un grand projet logiciel, générer une réponse rapidement ne suffit pas. Il faut comprendre le besoin, examiner le code proposé, vérifier ses conséquences et l’intégrer sans créer de régression.

Une expérimentation menée auprès de développeurs open source expérimentés

METR a recruté 16 développeurs expérimentés, impliqués dans des projets open source et déjà familiers des outils d’intelligence artificielle. Ce profil est central pour interpréter les résultats. Il ne s’agit pas de débutants découvrant un langage informatique, mais de personnes qui connaissent en profondeur les logiciels sur lesquels elles travaillent, leurs conventions, leur historique et leurs zones les plus sensibles.

L’étude a porté sur 246 tâches utiles, représentatives du travail quotidien de maintenance et de développement. Elles comprenaient notamment des corrections de bugs et des ajouts de fonctionnalités. Ces tâches étaient conçues pour pouvoir, en théorie, être réalisées en deux heures. Elles ont été réparties entre des situations de travail avec assistance IA et des situations sans cette assistance.

L’outil testé était Cursor Pro, avec les modèles Claude 3.5 et Claude 3.7. Les participants pouvaient donc s’appuyer sur une interface pensée pour le développement, capable de lire des fichiers du dépôt, de répondre à des questions sur le code et de proposer des modifications.

Le chiffre de 19 % concerne donc le temps nécessaire pour accomplir les tâches étudiées. Il ne doit pas être lu comme un verdict absolu sur la qualité des modèles de langage, ni comme une mesure de toutes les formes de travail informatique. En revanche, il apporte une donnée rare sur un usage situé : celui de professionnels compétents, confrontés à des problèmes réels au sein de leurs propres projets.

Pourquoi l’IA peut-elle ralentir un développeur ?

Le paradoxe s’explique d’abord par le coût caché de l’assistance. Un outil peut générer une modification de code en quelques instants. Mais la vitesse de cette génération ne garantit ni que la proposition répond exactement à la demande, ni qu’elle s’accorde avec l’architecture du logiciel, ni qu’elle respecte les choix techniques accumulés au fil des années.

Dans un environnement de développement, une réponse qui paraît plausible peut nécessiter une lecture attentive. Le développeur doit comparer la proposition avec le comportement attendu, vérifier les dépendances, exécuter des tests et parfois réécrire une partie du résultat. Si la suggestion est écartée, il a aussi consacré du temps à l’examiner, puis doit revenir à sa propre démarche de résolution du problème.

Le taux d’approbation mesuré dans l’étude illustre cette réalité : 44 % seulement des suggestions de l’IA ont été approuvées par les participants. Cela ne veut pas dire que les 56 % restantes étaient nécessairement inutilisables dans tous les cas. Mais cela montre qu’une part importante de l’assistance demandait des corrections, une révision substantielle ou un rejet.

Le contexte d’un projet ne tient pas dans une simple requête

Les modèles d’IA peuvent analyser du code fourni dans leur contexte immédiat, mais leur compréhension d’un projet reste limitée par les informations auxquelles ils ont accès et par la manière dont elles leur sont présentées. Or, les dépôts sur lesquels travaillent des mainteneurs expérimentés peuvent compter plus d’un million de lignes de code et avoir été construits au fil d’une dizaine d’années.

Dans de tels projets, une fonction ne se comprend pas seulement à partir de quelques lignes voisines. Son comportement peut dépendre de conventions internes, de décisions historiques, de bibliothèques anciennes, de contraintes de compatibilité ou de cas particuliers connus de l’équipe. Le développeur expert possède souvent ce contexte de façon implicite. Il sait quels fichiers éviter, quelles solutions ont déjà échoué et quelles conséquences une modification apparemment mineure peut avoir.

L’IA, elle, doit être guidée. Donner ce contexte, formuler la demande, lire la réponse et lui demander des ajustements prend du temps. Lorsque le problème est parfaitement connu du développeur, sa propre connaissance peut être plus directe et plus fiable que cette succession d’échanges.

Un écart spectaculaire entre attentes et résultats mesurés

Avant de travailler avec l’outil, les participants de l’étude prévoyaient une amélioration sensible de leur vitesse : ils anticipaient en moyenne une accélération de 24 %. Les mesures ont révélé l’inverse, avec un ralentissement de 19 %. Cet écart est l’un des enseignements les plus frappants de l’expérimentation.

Il ne s’agit pas seulement d’un optimisme théorique avant l’essai. Même après avoir effectué les tâches, les développeurs estimaient encore que l’IA les avait fait travailler 20 % plus vite. Leur perception ne correspondait donc pas au temps réellement observé.

Ce décalage peut s’expliquer par la nature même de l’expérience avec un assistant conversationnel. Obtenir rapidement du code donne une impression immédiate de progrès. Cette impression peut être forte, surtout lorsqu’une proposition débloque une piste ou évite une recherche fastidieuse. En revanche, les minutes absorbées par la validation, le débogage et les modifications successives sont plus difficiles à percevoir sur le moment.

Pour les équipes de développement, cette distinction est importante. Mesurer la productivité ne consiste pas seulement à demander aux utilisateurs s’ils ont trouvé un outil utile. Il faut aussi observer le délai de réalisation des tâches, la qualité de l’intégration et la charge de relecture qu’elle impose.

Ce que l’étude permet de conclure, et ce qu’elle ne permet pas de dire

L’étude de METR apporte un contrepoint utile aux promesses très générales autour de l’IA dans le travail. Elle montre qu’un assistant ne rend pas automatiquement un spécialiste plus rapide, particulièrement lorsque ce spécialiste intervient dans un codebase qu’il maîtrise déjà très bien.

Mais ses résultats doivent être replacés dans leur cadre. L’échantillon compte 16 participants et concerne des développeurs open source expérimentés. Leurs tâches portaient sur des projets existants, complexes et familiers. On ne peut donc pas en déduire qu’un assistant IA ralentira nécessairement un étudiant, une personne découvrant un langage, un développeur qui cherche une information de documentation ou une équipe qui produit du code très répétitif.

L’utilité d’un assistant peut varier fortement selon plusieurs facteurs :

• la familiarité du développeur avec le projet et le problème à résoudre ;
• la taille et l’ancienneté du dépôt de code ;
• la qualité du contexte transmis à l’outil ;
• la complexité de la modification demandée ;
• le temps requis pour tester et relire la proposition.

Les participants n’avaient pas non plus atteint ce que METR décrit comme un possible effet d’apprentissage après plusieurs centaines d’heures d’usage. Il est donc possible que des utilisateurs très entraînés à un outil tel que Cursor modifient leur manière de formuler les requêtes, de sélectionner les tâches déléguées et de vérifier les réponses. L’étude ne démontre pas cet effet, elle rappelle simplement qu’il pourrait compter dans les usages à long terme.

Comment intégrer l’IA sans confondre aide et automatisation

La leçon pratique de l’étude n’est pas de bannir les assistants de programmation. Elle est de les employer avec une attente réaliste. Un modèle peut être utile pour explorer une base de code, expliquer une fonction, proposer un premier brouillon ou suggérer des pistes de correction. En revanche, il ne remplace pas la connaissance du système détenue par les personnes qui le maintiennent.

Pour les responsables techniques, l’enjeu est de choisir des critères adaptés avant de déployer un outil à grande échelle. Une démonstration convaincante, où l’IA produit une fonction isolée, ne dit pas forcément grand-chose de son impact dans un logiciel ancien et très interconnecté. Il est plus pertinent d’observer son effet sur des tâches représentatives : combien de temps est réellement gagné, quelle part des suggestions est conservée et combien de retouches sont nécessaires.

Cette approche suppose également de ne pas évaluer l’outil à partir du seul ressenti. La satisfaction peut être réelle, car l’assistant réduit la sensation de page blanche ou accélère certaines micro-tâches. Mais, comme le montre le décalage observé par METR, ce ressenti peut coexister avec une durée totale de travail plus élevée.

Les entreprises qui développent des assistants plus personnalisés, parmi lesquelles Microsoft et OpenAI, cherchent précisément à mieux adapter l’IA aux besoins des utilisateurs. Pour être réellement efficace dans le développement logiciel, l’assistance devra notamment mieux prendre en compte le contexte du projet et réduire le travail de vérification qu’elle impose.

Ce qu’il faut surveiller

Au 23 juillet 2025, l’étude METR ne ferme pas le débat sur la productivité des développeurs assistés par IA. Elle le rend plus précis. La question n’est plus seulement de savoir si un modèle peut écrire du code, capacité désormais bien établie, mais dans quelles conditions cette production réduit effectivement le temps nécessaire à la résolution d’un problème.

Les futurs travaux devront notamment déterminer si l’effet varie avec l’expérience des utilisateurs, la durée de prise en main, les types de tâches et le niveau de contexte auquel l’outil peut accéder. Il faudra aussi distinguer les gains locaux, par exemple l’écriture rapide d’un fragment de code, de la performance globale d’un projet, qui dépend de la maintenance, des tests et de la fiabilité sur la durée.

Pour les développeurs comme pour les organisations, le message est sobre : l’IA mérite d’être testée, mais ses promesses de vitesse doivent être mesurées sur le terrain. Dans les projets complexes, le jugement humain, la connaissance de l’historique et la capacité à vérifier chaque changement restent des ressources que l’assistant ne remplace pas automatiquement.