Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics

Cette étude révèle un décalage entre les priorités de la recherche académique, les besoins de l'industrie et le comportement réel des modèles de langage, soulignant la nécessité d'intégrer des mécanismes d'assurance qualité pour garantir que le code généré respecte non seulement les tests fonctionnels mais aussi les caractéristiques non fonctionnelles critiques comme la maintenabilité et la sécurité.

L'essentiel

Voici une explication simple et imagée de cette recherche, comme si nous en discutions autour d'un café.

🧱 Le Grand Défi : Construire une maison avec un architecte robot

Imaginez que vous avez un architecte robot très doué (c'est le modèle de langage ou LLM, comme ceux qui écrivent du code pour nous). Ce robot est incroyable : il peut dessiner des plans de maison, construire des murs et installer des fenêtres en quelques secondes. Si vous lui demandez "Fais-moi une porte", il en crée une qui s'ouvre et se ferme parfaitement. C'est ce qu'on appelle la fonctionnalité : la porte fonctionne.

Mais ce papier pose une question cruciale : Est-ce que cette porte est bien faite ?

Est-elle solide ? Est-elle facile à repeindre dans 10 ans ? Est-ce qu'elle ne va pas se casser sous la pluie ? C'est ce qu'on appelle la qualité non fonctionnelle (sécurité, maintenabilité, performance).

Les chercheurs de l'Université de Linköping en Suède ont voulu savoir si ces robots architectes construisent des maisons solides ou juste des "maisons en carton" qui fonctionnent pour l'instant mais qui vont s'effondrer plus tard.

---

🔍 Les Trois Étapes de l'Enquête

Pour répondre à cette question, les chercheurs ont utilisé trois méthodes, comme un détective qui utilise des indices, des témoignages et une reconstitution sur le terrain.

1. L'Enquête dans les livres (La Revue de Littérature)

Les chercheurs ont lu 109 articles scientifiques récents.

• Ce qu'ils ont vu : Les chercheurs universitaires sont très obsédés par deux choses : la sécurité (est-ce qu'il y a une serrure ?) et la performance (est-ce que la porte s'ouvre vite ?).
• Le problème : Ils ont remarqué que beaucoup d'autres aspects importants (comme la facilité à réparer la porte plus tard) sont ignorés. C'est comme si on ne vérifiait que si la maison a une clé, sans regarder si les murs sont bien alignés.

2. Le Café avec les Pros (Les Ateliers Industriels)

Ensuite, ils ont parlé avec 15 ingénieurs et experts du monde réel (des gens qui construisent de vraies maisons tous les jours).

• Ce qu'ils ont dit : "Hé, la sécurité c'est bien, mais ce qui nous fait peur, c'est la maintenabilité !"
• L'analogie : Pour ces pros, si le robot construit une maison avec des matériaux bizarres et des plans illisibles, c'est un cauchemar pour les futurs réparateurs. Ils ont peur que ces maisons robotiques créent une dette technique : c'est comme emprunter de l'argent pour construire vite, mais devoir payer des intérêts énormes (réparer des heures et des heures) plus tard.
• Le décalage : Les chercheurs en labo parlent de "sécurité", les pros en entreprise parlent de "facilité à entretenir". Il y a un malentendu !

3. L'Expérience sur le Terrain (L'Étude Empirique)

C'est la partie la plus concrète. Les chercheurs ont donné à trois robots différents (Claude, DeepSeek, GPT-4o) de vrais problèmes à résoudre dans de grands projets informatiques (comme des bugs dans des sites web populaires).

• Le test : Ils ont demandé aux robots de réparer des bugs, puis ils ont vérifié non seulement si le bug était réparé, mais aussi si la réparation était propre, rapide et sûre.
• Le résultat choc :
  • Les robots réussissent souvent à réparer le bug (la porte s'ouvre).
  • MAIS, la réparation est souvent "sale". Elle crée des problèmes cachés (des murs de travers, des câbles mal rangés).
  • Le piège du "Prompt" : Les chercheurs ont essayé de dire aux robots : "Sois plus rapide !" ou "Sois plus sûr !". Résultat ? Souvent, quand on force le robot à être plus rapide, il devient moins sûr, ou inversement. C'est comme essayer de courir plus vite en portant un sac de sable : on gagne en vitesse, mais on perd en stabilité.

---

💡 Les Grandes Leçons (En termes simples)

1. Le robot ne comprend pas la "qualité" : Pour l'instant, le robot est programmé pour dire "Oui, j'ai fini, ça marche !". Il ne se soucie pas si le code est joli, facile à lire ou durable. Il veut juste passer le test.
2. Le danger de la dette technique : Si on laisse ces robots coder sans surveillance, on risque de construire des systèmes qui fonctionnent aujourd'hui, mais qui seront un enfer à réparer demain. C'est comme construire une maison en papier mâché : ça tient debout, mais un coup de vent (une mise à jour) et tout s'effondre.
3. On ne peut pas tout optimiser en même temps : Essayer d'optimiser un seul aspect (comme la vitesse) en donnant un simple ordre au robot ("Sois rapide !") ne fonctionne pas bien. Cela crée souvent des effets secondaires négatifs sur les autres aspects (sécurité, lisibilité).

🚀 Conclusion et Avenir

L'article conclut que nous ne pouvons pas juste dire "Lâche le robot et laisse-le faire". Nous devons intégrer des contrôles de qualité dans le processus.

Imaginez que le robot ne soit pas seul. Il doit avoir un inspecteur du bâtiment (un outil d'analyse) qui vérifie en temps réel : "Attends, cette porte est rapide, mais elle est en bois pourri. Recommence !"

L'objectif final : Ne pas se contenter de code qui "passe les tests", mais de code qui "passe avec une qualité" durable, sûr et facile à entretenir pour les humains qui viendront après.

En résumé : Les robots sont de superbes apprentis, mais ils ont encore besoin d'un maître artisan pour s'assurer que la maison tient debout dans 10 ans.

Résumé technique

1. Problématique

L'intégration massive des modèles de langage (LLM) dans les flux de travail d'ingénierie logicielle a révolutionné la génération de code. Cependant, les évaluations actuelles se concentrent presque exclusivement sur la correctitude fonctionnelle (le code fait-il ce qu'il est censé faire ?), négligeant les caractéristiques de qualité non fonctionnelles (NFQCs) telles que la sécurité, la maintenabilité et l'efficacité des performances.

Le problème central identifié par les auteurs est un décalage critique entre :

• La recherche académique, qui privilégie souvent la sécurité et l'efficacité.
• Les priorités industrielles, où les praticiens s'inquiètent davantage de la maintenabilité et de la lisibilité, craignant que le code généré n'accélère l'accumulation de dette technique.
• Le comportement réel des modèles, qui produisent souvent du code fonctionnellement correct mais structurellement fragile, peu sécurisé ou inefficace.

L'absence de mécanismes d'assurance qualité intégrés dans les pipelines de génération pose un risque majeur pour la fiabilité des systèmes logiciels futurs.

2. Méthodologie

L'étude adopte une approche multi-méthodes guidée par le modèle de qualité ISO/IEC 25010, combinant trois éléments complémentaires :

1. Revue de littérature systématique :

   • Analyse de 109 articles publiés entre 2022 et 2025.
   • Cartographie des caractéristiques de qualité étudiées et identification des lacunes méthodologiques (manque de cadres unifiés, terminologie incohérente).

2. Ateliers industriels :

   • Deux ateliers interactifs avec 15 praticiens issus de sept organisations (principalement membres du Software Center suédois).
   • Objectif : Comprendre les attentes réelles, les points de douleur et les priorités des ingénieurs logiciels concernant le code généré.

3. Évaluation empirique (Expérience contrôlée) :

   • Jeu de données : Utilisation de SWE-bench Lite (300 problèmes réels issus de dépôts GitHub, principalement Django et SymPy).
   • Modèles testés : Trois LLMs distincts : Claude 4 Sonnet, DeepSeek-Reasoner et GPT-4o.
   • Pipeline expérimental en trois étapes :
     1. Évaluation de base : Génération de correctifs (patches) et mesure de la correctitude fonctionnelle, du temps d'exécution, de l'utilisation mémoire, ainsi que des problèmes de sécurité et de maintenabilité via CodeQL.
     2. Conception de prompts : Identification des instances résolues par les trois modèles et création de prompts optimisés spécifiques aux NFQCs (incluant des retours basés sur les rapports CodeQL).
     3. Régénération et analyse des compromis : Régénération des correctifs avec les nouveaux prompts pour évaluer les améliorations ciblées et les compromis (trade-offs) entre les différentes qualités (ex: améliorer la sécurité au détriment des performances).

3. Contributions Clés

• Identification d'un décalage recherche-industrie : Mise en évidence du fait que la recherche se concentre sur la sécurité et les performances, tandis que l'industrie priorise la maintenabilité et la lisibilité pour la durabilité à long terme.
• Analyse des compromis (Trade-offs) : Démonstration empirique que l'optimisation d'une NFQC via des prompts ne garantit pas une amélioration isolée et peut dégrader d'autres qualités ou même la fonctionnalité elle-même.
• Évaluation de l'instabilité des prompts : Preuve que l'optimisation des NFQCs par simple ajustement de prompt est instable dans des scénarios d'ingénierie logicielle réels.
• Appel à l'action : Plaidoyer pour l'intégration de mécanismes d'assurance qualité (analyse statique, validation) directement dans les pipelines de génération, passant d'une logique de "passage des tests" à une logique de "passage avec qualité".

4. Résultats Principaux

A. Revue de littérature et Ateliers

• La littérature se concentre massivement sur la sécurité (33,6%), l'efficacité des performances (23,3%) et la maintenabilité (17,2%). D'autres aspects comme la fiabilité ou la modularité sont sous-étudiés.
• Les praticiens soulignent que le code généré manque souvent de contexte global, rendant la maintenabilité difficile, surtout dans les grandes bases de code existantes. Ils craignent que l'automatisation ne masquerait la dette technique.
• Il existe un manque de cadres d'évaluation quantitatifs unifiés et une difficulté à mesurer les compromis entre plusieurs NFQCs simultanément.

B. Évaluation Empirique (SWE-bench Lite)

• Correctitude fonctionnelle : Les LLMs obtiennent des taux de résolution bien inférieurs aux correctifs humains (Gold patches). GPT-4o a le taux de patchs applicables le plus élevé (75%) mais le taux de résolution le plus faible (16%), suggérant des problèmes de logique fonctionnelle malgré une syntaxe correcte.
• Maintenabilité et Sécurité :
  • Les patches générés déclenchent beaucoup plus de règles CodeQL que les patches humains.
  • Un problème majeur identifié est l'introduction de cycles d'importation (cyclic-imports) dans les projets Python, absents des patches humains qui respectent mieux la structure du projet.
  • Le code généré contient plus de "Code Smells" et de dette technique structurelle.
• Performance (Temps et Mémoire) :
  • Les patches générés sont généralement plus lents et consomment plus de mémoire que les solutions de référence.
• Impact des Prompts d'Optimisation (RQ 5.2 & 5.3) :
  • L'ajout de prompts spécifiques aux NFQCs (ex: "améliore la sécurité") entraîne souvent une baisse de la correctitude fonctionnelle.
  • Compromis inévitables : L'optimisation d'un aspect (ex: temps d'exécution) dégrade souvent un autre (ex: consommation mémoire). Parfois, l'optimisation d'une qualité spécifique dégrade même cette même qualité (optimisation négative).
  • Les modèles montrent des spécialisations : Claude 4 Sonnet performe mieux sur la maintenabilité et la sécurité, tandis que DeepSeek est meilleur pour l'optimisation mémoire.

5. Signification et Implications

Cette étude démontre que la génération de code par LLM n'est pas encore prête pour une intégration autonome et fiable dans des environnements de production critiques sans supervision humaine rigoureuse.

• Limitation des modèles actuels : Les LLMs sont entraînés pour prédire le token suivant et non pour optimiser des objectifs d'ingénierie logicielle complexes. Ils manquent de "conscience" des NFQCs.
• Risque de dette technique : L'utilisation de patches générés sans validation approfondie risque d'introduire des vulnérabilités et une dette technique structurelle (mauvaise modularité, imports cycliques).
• Nécessité de nouveaux pipelines : L'avenir de l'IA en génie logiciel ne réside pas seulement dans de meilleurs modèles, mais dans des pipelines d'assurance qualité intégrant l'analyse statique (CodeQL), la validation dynamique et des boucles de rétroaction itératives pour guider les modèles vers des solutions non seulement fonctionnelles, mais aussi robustes, sécurisées et maintenables.

En conclusion, l'article appelle à un changement de paradigme : passer d'une évaluation centrée sur la fonctionnalité à une approche holistique intégrant les contraintes non fonctionnelles dès la phase de génération.