L’IA accélère-t-elle vraiment le codage ?

Depuis quelques années, les modèles de pointe de l’IA font une promesse audacieuse : l’utilisation d’assistants de codage permet d’accélérer le codage, de réduire le nombre de bogues et de diminuer la charge de travail fastidieuse des développeurs. Des outils tels que GitHub Copilot et Cursor, alimentés par de grands modèles de langage (LLM) tels que Claude ou GPT, sont conçus pour automatiser les tâches pénibles de la programmation afin que les programmeurs humains puissent se consacrer aux problèmes plus difficiles et plus créatifs de leur base de code.

Du moins, c’est ce qui était avancé jusqu’à présent. Mais METR (abréviation de Model Evaluation and Threat Research, prononcé « meter » à l’anglaise), une organisation à but non lucratif de Berkeley qui évalue les capacités des modèles de pointe, a voulu vérifier s’il existait des preuves tangibles pour étayer cette affirmation. Leurs conclusions racontent une tout autre histoire : les assistants de codage pourraient en fait ralentir les développeurs.

Les chercheurs de METR ont observé le travail de 16 développeurs expérimentés qui contribuaient depuis plusieurs années à de grands référentiels open source. Chaque développeur a fourni une liste des tâches réelles qu’il accomplissait habituellement, de la correction de bogues à l’ajout de nouvelles fonctionnalités. Les chercheurs ont ensuite réparti les tâches de manière aléatoire en deux groupes : l’un où les développeurs pouvaient utiliser des outils d’IA, et l’autre où ils ne le pouvaient pas.

Lorsque l’IA était autorisée, les développeurs pouvaient choisir les outils qu’ils voulaient ; la plupart ont choisi Cursor Pro associé à Claude 3.5 ou 3.7 Sonnet. Ils ont enregistré leurs écrans pendant qu’ils accomplissaient chaque tâche, puis ont indiqué ce qu’ils estimaient être leur temps total de mise en œuvre. Les résultats de l’étude ont été surprenants. « Lorsque les développeurs sont autorisés à utiliser des outils d’IA, ils mettent 19 % plus de temps à résoudre les problèmes, ce qui représente un ralentissement significatif qui va à l’encontre des convictions des développeurs et des prévisions des experts », ont écrit les auteurs de l’article.

Nous avons demandé à PJ Hagerty, responsable de la promotion de l’IA chez IBM, et à Chris Hay, ingénieur émérite, d’examiner l’étude du METR et de nous faire part de leurs impressions.

M. Hagerty a averti que l’engouement pour les assistants d’IA pourrait dépasser leur utilité dans le monde réel. « La promesse d’une IA rendant les gens plus productifs provient des leaders technologiques et des entreprises d’IA générative qui cherchent à capitaliser sur l’engouement pour l’IA, a-t-il déclaré à IBM Think. En réalité, l’IA apprend au fur et à mesure et utilise probablement les mêmes ressources qu’un développeur junior, à savoir Stack Overflow, Github et Google, mais sans aucun contexte. »

« Je pense que c’est un résultat pertinent, a ajouté M. Hay. Mais je ne pense pas que nous devrions nous dire : "L’IA est inutile. Je suis plus rapide en le faisant moi-même." Je pense toutefois qu’il est vrai que pour certaines tâches, il est peut-être plus rapide de les faire soi-même plutôt que d’essayer de convaincre l’IA. »

L’autre moitié des résultats de l’étude est tout aussi intéressante : les développeurs s’attendaient à ce que l’IA accélère leur travail de 24 % avant de commencer. Pourtant, même après avoir constaté un ralentissement de 19 %, ils continuaient à penser que l’IA leur avait fait gagner 20 % de temps.

Qu’est-ce qui explique cet écart de perception ? Nous avons interrogé Nate Rush, de METR, l’un des auteurs de l’étude. « C’est une excellente question, à laquelle notre travail ne répond pas entièrement, a déclaré M. Rush à IBM Think. Idéalement, les travaux futurs exploreront plus en détail comment les attentes des développeurs concernant l’utilité de l’IA influencent leur utilisation des outils [et] pourquoi cet écart de perception existe. »

Au-delà de la perception, l’étude soulève un certain nombre de questions importantes : le gain de temps est-il le seul moyen de mesurer la productivité des développeurs ? Comment des indicateurs tels que la qualité du code et l’impact sur l’équipe s’intègrent-ils dans le tableau d’ensemble ?

« Notre étude ne porte que sur le gain de temps, qui n’est qu’une mesure d’un aspect de la productivité, a déclaré M. Rush. Il n’existe pas d’indicateur unique, mais plutôt un ensemble d’indicateurs qui fournissent des informations sur l’impact des outils d’IA. » Il ajoute que, bien que cette étude se soit concentrée sur le temps, son équipe a trouvé le cadre SPACE de la productivité des développeurs (acronyme de Satisfaction, Performance, Activité, Communication et Efficacité) utile pour réfléchir aux orientations futures.

Autre question : les versions du modèle, en l’occurrence Claude 3.5 et 3.7 Sonnet, ont-elles pu influencer le temps de performance ? « Voici la réalité, a déclaré M. Hay. Je pense que les versions ont leur importance. Claude 4 Sonnet est nettement meilleur. Claude 4 Opus est nettement meilleur. Nous ne parlons pas d’une légère amélioration, mais d’une amélioration considérable. »

Selon Quentin Anthony, l’un des 16 participants à l’étude, l’élément humain est un autre facteur important à prendre en compte. « Nous aimons dire que les LLM sont des outils, mais nous les traitons plutôt comme une solution miracle, a-t-il écrit sur X. Les LLM sont un gros bouton de raccourci dopaminergique qui peut résoudre votre problème d’un seul coup. Continuez-vous à appuyer sur le bouton qui a 1 % de chances de tout régler ? C’est beaucoup plus agréable que l’alternative pénible, du moins pour moi. » (Anthony a ajouté que les distractions liées aux réseaux sociaux sont un autre moyen facile de causer des retards.)

Alors, à mesure que les assistants de codage d’IA évoluent et s’améliorent, où auront-ils l’impact le plus durable à long terme sur le développement logiciel ? « Une fois qu’ils seront stables, fiables et utiles, je pense que les assistants de codage trouveront leur place dans la couche QA (test, assurance qualité, accessibilité), déclare M. Hagerty. Les tâches contraignantes et basées sur des règles sont les meilleures applications de ces outils. »

En effet, selon lui, écrire du code est fondamentalement différent de le vérifier. « Le codage en soi est une activité créative. Il s’agit de construire quelque chose à partir de rien dans un écosystème unique. Les assistants d’IA ne saisissent pas cette nuance. Mais ils peuvent probablement effectuer des tests à l’aide d’un système de règles plus générales et universelles. »