Le code qui passe les tests n'est pas forcément un code sain
Les agents de code ont changé le rythme du développement logiciel. En quelques minutes, ils écrivent une fonction, un service, parfois un module entier, qui compile et passe les tests. Pour une équipe sous pression, dans la banque, l'énergie, la santé ou le commerce, la tentation est forte de considérer que le travail est fait.
C'est là que se loge le risque. Un test vérifie un comportement : pour telle entrée, telle sortie. Il ne dit rien de la conception : une méthode trop longue pour être comprise, une classe qui centralise tout, une logique dupliquée à trois endroits. Le programme fonctionne, mais il devient plus difficile à comprendre, à modifier et à faire évoluer.
Ces défauts portent un nom depuis les travaux de Martin Fowler : les « code smells », des symptômes dans le code qui signalent un problème de conception plus profond. Ils deviennent d'autant plus actuels que les modèles génèrent du code fonctionnel très vite, et que ce code tend à accumuler de mauvaises pratiques de conception qui se paient, à moyen terme, en dette technique.
Cet article s'appuie sur les travaux de recherche de Djamel Mesbah, menés chez Adservio dans le cadre d'une thèse CIFRE avec l'Université Paris-Saclay et l'ISEP, consacrée à la détection automatique de ces défauts par l'intelligence artificielle. Ils ont donné lieu à plusieurs publications scientifiques, citées en fin d'article.
Pourquoi les défauts de conception coûtent cher
Les code smells ne sont pas une question de style. De nombreuses études empiriques les associent à une maintenabilité réduite et à un effort d'évolution plus important.
Plus de modifications, plus de défauts
Les systèmes qui concentrent des défauts comme le God Class, le Feature Envy ou le Long Method présentent davantage de modifications et de défauts, des temps de modification plus longs et des changements plus complexes pendant la maintenance. Les composants concernés accumulent de la dette technique : il devient plus difficile de comprendre l'intention de conception, de localiser une modification et de la propager sans risque.
Une charge cognitive qui s'additionne
Un défaut isolé reste gérable pour un développeur. C'est leur accumulation qui pose problème : la coexistence de plusieurs défauts augmente nettement la charge de travail et réduit la précision de compréhension. À l'échelle d'une base de code alimentée en continu par des agents, ce phénomène d'accumulation est précisément celui qu'il faut surveiller.
Quatre défauts à connaître
Long Method
Une méthode trop longue pour être comprise facilement.
Blob, ou God Class
Une classe qui centralise trop de responsabilités.
Data Class
Une classe qui ne contient que des données et des accesseurs, sans comportement réel.
Feature Envy
Une méthode qui s'intéresse davantage aux données d'une autre classe qu'aux siennes.
Meilleur score F1 obtenu par l'ensemble des 17 modèles comparés, sur une échelle de 0 à 1. Source : Mesbah et al., Information and Software Technology, tableau 5.
Peut-on confier la détection à l'IA ?
Si l'IA produit ces défauts, peut-elle aussi les repérer ? Les résultats de recherche apportent une réponse nuancée, et c'est ce qui les rend utiles pour les équipes.
Aucune famille de modèles ne domine
Dix-sept modèles, issus de trois grandes familles, ont été comparés sur un même jeu d'extraits Java annotés par des développeurs professionnels (le jeu de données MLCQ), avec un protocole identique : apprentissage classique sur des métriques, modèles de séquence qui lisent le code comme un texte, et réseaux de neurones sur des graphes issus de l'arbre syntaxique. Les modèles à base de graphes l'emportent sur les défauts de niveau classe (Blob, Data Class), les modèles de séquence sur les méthodes trop longues. Aucune famille ne gagne partout.
Aucune famille de modèles ne domine, et le Feature Envy résiste à toutes
Meilleur score F1 obtenu par chaque famille sur chaque défaut (0 = aucune détection fiable, 1 = détection parfaite). Jeu de données MLCQ, 4 366 extraits Java, moyenne sur 10 exécutions. Source : Mesbah et al., Information and Software Technology, tableau 5.
Les grands modèles de langage : utiles, mais pas suffisants
Interrogés directement par prompt, des modèles comme GPT-4 et LLaMA obtiennent des performances limitées sur cette tâche. Fournir quelques exemples dans le prompt améliore nettement leurs réponses, et GPT-4 reste le plus fiable. Mais tous deux peinent sur le Feature Envy et le Blob. Une étude est en cours sur des modèles de langage plus récents, capables de raisonner par étapes (chaîne de réflexion, ou chain of thought) et dotés d'un harnais d'outils, pour mesurer leur progression.
Un défaut résiste à tout
Le Feature Envy reste un défi ouvert pour toutes les approches testées. La raison est instructive : c'est un défaut relationnel. Pour le voir, il faut savoir quelles classes s'appellent entre elles et avec quels types, une information que les représentations actuelles d'un bout de code isolé ne portent pas.
La leçon : ce n'est pas le modèle, c'est la représentation
Le principal enseignement tient en une phrase : ce qui rend un défaut détectable, ce n'est pas la sophistication du modèle, mais la façon dont on représente le code qu'on lui donne à lire.
Un même code, trois façons de le donner à lire, un même angle mort
Schéma d'après les publications de Djamel Mesbah (AINA 2025, Information and Software Technology). Le code et les valeurs des mini-visualisations sont des illustrations.
Augmenter la puissance de calcul ne change rien à ce constat. Distribuer l'entraînement réduit le coût et le temps de calcul, mais ne fait pas sauter le plafond de détection : la limite tient à la représentation du code.
Pour une DSI comme pour une équipe de développement, l'enseignement dépasse la recherche : un modèle plus gros ne remplace pas une réflexion sur ce qu'on lui donne à voir. C'est vrai pour la détection des défauts, et c'est vrai pour les agents de code eux-mêmes.
Mesurer la propreté du code généré
Les bancs d'essai de référence, comme SWE-bench, mesurent si le code généré fonctionne et résout le problème posé. Une autre question reste largement ouverte : ce code est-il propre ? Quels défauts de conception les modèles introduisent-ils dans ce qu'ils produisent ?
C'est l'axe qu'explorent les travaux en cours chez Adservio. La question devient centrale à mesure que les agents de code se généralisent : produire du code qui passe les tests ne garantit pas un code maintenable.
En résumé
Les agents de code accélèrent la production du logiciel, mais la vitesse ne dit rien de la qualité de conception. Mesurer les défauts dès leur création et encadrer les agents, c'est ce qui transforme un gain de productivité en actif durable.
Sources
Mesbah D., El Madhoun N., Al Agha K., Zouaoui A., « A Survey on Code Smells Detection using Machine Learning Techniques », Information and Software Technology, Elsevier, accepté, 2026. https://www.sciencedirect.com/science/article/pii/S0950584926002314
Mesbah D., El Madhoun N., Al Agha K., Chalouati H., « Leveraging Prompt-Based Large Language Models for Code Smell Detection: A Comparative Study on the MLCQ Dataset », EIDWT, Springer, 2025. https://link.springer.com/chapter/10.1007/978-3-031-86149-9_42
Mesbah D., El Madhoun N., Al Agha K., Chalouati H., « Exploring NLP Techniques for Code Smell Detection: A Comparative Study », AINA, Springer, 2025. https://link.springer.com/chapter/10.1007/978-3-031-87769-8_9
Mesbah D., El Madhoun N., Al Agha K., Chalouati H., « Beyond the Code: Unraveling the Applicability of Graph Neural Networks in Smell Detection », NBiS, Springer, 2024. https://link.springer.com/chapter/10.1007/978-3-031-72325-4_15
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
Comment nous intégrons les agents IA dans nos projets
Chez Adservio, ces enseignements guident la manière dont nous intégrons des agents IA dans le cycle de vie logiciel de nos clients, quel que soit leur secteur. Quatre principes structurent nos projets.
Contrôler la conception au moment où la dette se crée
Illustration des recommandations de cet article.
Mesurer la conception, pas seulement le comportement
Les tests restent indispensables, mais ils ne suffisent plus. La détection des défauts de conception entre dans la chaîne d'intégration au même titre que les tests, pour que la dette technique soit visible au moment où elle se crée, et non six mois plus tard.
Combiner les approches plutôt que parier sur un modèle
Puisqu'aucune famille de modèles ne domine, un outillage robuste combine plusieurs approches selon le type de défaut recherché, plutôt que de confier toute la détection à un seul modèle, aussi puissant soit-il.
Garder l'humain sur les défauts relationnels
Les défauts qui demandent de comprendre les relations entre classes, comme le Feature Envy, échappent encore aux outils. La revue de conception par un développeur expérimenté reste le filet de sécurité sur ces points.
Encadrer les agents sur des schémas éprouvés
Un agent de code donne ses meilleurs résultats sur des tâches récurrentes, dont les schémas ont été validés et capitalisés. Nous commençons par ces cas, nous mesurons les gains, puis nous élargissons progressivement. Le gain vient de l'encadrement des agents, pas de leur liberté.