Code généré par l'IA : pourquoi « ça marche » ne veut pas dire « c'est maintenable »

SECTION 1

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.

@cite:la-programmation-intuitive-peut-elle-produire-des-logiciels

SECTION 2

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

@diagram:code-ia-defauts

SECTION 3

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.

@diagram:code-ia-scores

### 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.

SECTION 4

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.

@diagram:code-ia-representations

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.

SECTION 5

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.

SECTION 6

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.

@diagram:code-ia-chaine

### 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é.

@cite:claude-code-nous-a-economise-97-du-travail-puis-c-est-devenu

SECTION 7

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.

SECTION 8

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

FAQ

Questions fréquentes