Beyond Resolved Rate: A Non-Functional Quality Study
Cette étude révèle que bien que les nouveaux modèles d'IA résolvent davantage de tâches de codage au niveau du dépôt que les versions antérieures, ils ne démontrent pas d'améliorations constantes des mesures de qualité non fonctionnelles telles que l'analyse statique, la complexité du code ou l'utilisation des ressources sur les tâches que les deux générations résolvent avec succès.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez un monde où les ordinateurs ont appris à écrire du code, agissant comme des développeurs juniors infatigables capables de corriger des bogues, de construire des fonctionnalités et même de refactoriser des projets logiciels entiers. C'est le domaine des grands modèles de langage (LLM) dans l'ingénierie logicielle. Pendant longtemps, la seule façon de juger ces codeurs numériques était de poser une question simple : « Ont-ils corrigé le bogue ? » Si le code passait les tests, il recevait une étoile dorée. C'est ce qu'on appelle la « correction fonctionnelle ». Mais ce n'est pas parce que le moteur d'une voiture démarre que les freins fonctionnent, que la peinture est durable ou que l'efficacité énergétique est bonne. Dans le monde réel, un logiciel doit être sécurisé, facile à mettre à jour plus tard et assez rapide pour ne pas faire planter votre ordinateur. Ce sont les « qualités non fonctionnelles ». La grande question que se posent les chercheurs est la suivante : à mesure que ces modèles d'IA deviennent plus intelligents et plus récents, deviennent-ils simplement meilleurs pour résoudre le problème immédiat, ou écrivent-ils également un code plus propre, plus sûr et plus efficace ?
Ce document, intitulé « Beyond Resolved Rate », plonge dans ce mystère exact. Les auteurs, une équipe de l'Université de Linköping en Suède, ont décidé de ne plus se contenter de compter combien de bogues l'IA a corrigés, mais de commencer à inspecter comment elle les a corrigés. Ils ont traité les modèles d'IA comme des concurrents dans un concours de cuisine. Les juges (les chercheurs) leur ont donné une tâche spécifique : corriger une recette défectueuse (un bogue dans un projet logiciel). Les anciens modèles étaient les vétérans et les nouveaux modèles étaient les étoiles montantes. Le but n'était pas seulement de voir qui pouvait servir un plat qui avait bon goût (passer les tests), mais de voir si les nouveaux chefs utilisaient de meilleurs ingrédients, créaient moins de déchets et rendaient la cuisine plus sûre pour le prochain cuisinier.
Les chercheurs ont mis en place une expérience rigoureuse utilisant un benchmark populaire appelé SWE-bench Lite, qui contient des tâches de réparation de logiciels réels. Ils ont opposé deux générations de modèles face à face, issues de deux familles différentes : la famille commerciale « Claude » et la famille open-source « DeepSeek ». Ils ont pris les correctifs (les patchs) générés par les anciens et les nouveaux modèles et les ont passés au crible d'une batterie d'inspections de haute technologie. Ils ont utilisé des outils comme CodeQL et CodeCodeScene pour scanner les risques de sécurité, les structures de code désordonnées et les problèmes de maintenabilité. Ils ont également chronométré le temps de fonctionnement du code et mesuré la quantité de mémoire qu'il dévorait, traitant l'ordinateur comme une bête affamée qui doit être nourrie efficacement.
Les résultats ont apporté un certain rebondissement scénaristique. Les modèles plus récents, plus « intelligents », ont certainement corrigé plus de bogues. Ils ont résolu plus d'instances que leurs frères et sœurs plus anciens, obtenant ainsi un « taux de résolution » plus élevé. Cependant, lorsque les chercheurs ont examiné la qualité du code pour les tâches que les deux modèles ont réussi à résoudre, l'histoire a changé. Les nouveaux modèles n'ont montré aucune amélioration constante des qualités non fonctionnelles. En fait, les données suggèrent que les nouveaux modèles sont tout aussi susceptibles d'introduire des « odeurs de code » (code smells), des risques de sécurité ou des problèmes de performance que les anciens.
Plus précisément, l'étude a révélé que pour les tâches résolues par les deux modèles, les nouveaux modèles ne produisaient pas de code significativement plus propre. Les outils d'analyse statique ont montré que le nombre de nouveaux problèmes introduits était sensiblement le même pour les deux générations. En termes de performance, les nouveaux modèles étaient légèrement plus « gourmands » en ressources. Sur les tâches communes, le nouveau modèle Claude utilisait environ 0,048 seconde de temps CPU et environ 4,5 MiB de mémoire de pointe de plus que l'ancien. Le nouveau modèle DeepSeek utilisait environ 0,5 MiB de mémoire de plus. Bien que ces chiffres soient faibles, ils indiquent que devenir meilleur pour corriger le bogue ne signifiait pas automatiquement devenir meilleur pour écrire un code efficace.
Les auteurs ont également examiné la « saveur » du code. Ils ont vérifié si les nouveaux modèles évitaient certaines mauvaises habitudes, comme des noms de variables confus ou des imports désordonnés. Les résultats ont été mitigés et incohérents ; parfois, le nouveau modèle était meilleur sur une règle spécifique, parfois l'ancien l'était, mais il n'y avait pas de tendance claire indiquant que la nouvelle génération était universellement supérieure en qualité de code.
En fin de compte, le document suggère que si les modèles d'IA deviennent meilleurs sur le « quoi » (corriger le bogue), ils ne deviennent pas nécessairement meilleurs sur le « comment » (écrire un code de haute qualité et maintenable) par le simple fait d'être plus récents. Les auteurs avertissent qu'un taux de réussite plus élevé dans la correction de bogues ne garantit pas une meilleure ingénierie logicielle globale. Ils soutiennent que nous devons regarder au-delà du simple score de réussite ou d'échec et commencer à mesurer les coûts cachés du code généré par l'IA, tels que les risques de sécurité et les problèmes de maintenance, pour comprendre véritablement comment ces assistants numériques se comportent dans le monde réel.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.