Repérer et corriger les code smells : les dix les plus fréquents dans le code généré par IA

Un code smell est un endroit du code source qui fonctionne et signale pourtant un problème plus profond. Le terme vient de Kent Beck et Martin Fowler. Dans le code généré par IA, certains smells apparaissent plus souvent que la moyenne, parce que le modèle voit l’extrait qu’il doit modifier, mais pas le code existant dans lequel il écrit.

Qu’est-ce qu’un code smell ?

Un code smell est un motif de soupçon, pas un défaut. Le code s’exécute, les tests sont verts, et pourtant la structure laisse penser que la prochaine modification à cet endroit sera pénible.

La distinction est importante : un smell n’est pas une violation de règle que l’on peut faire corriger automatiquement. Certains smells sont à leur place — des doublons volontaires entre deux modules appelés à évoluer indépendamment, par exemple. Un outil peut signaler le soupçon ; c’est celui qui connaît le contexte qui décide s’il est fondé.

Quels code smells apparaissent le plus souvent dans le code généré par IA ?

Dix motifs, classés selon le coût qu’ils atteignent plus tard.

• Logique dupliquée. Le même comportement à plusieurs endroits. De loin le smell le plus fréquent et le plus coûteux, et le seul dont la progression se mesure sur des années — voir la dette technique due au code IA.
• Implémentation parallèle. Une nouvelle fonction utilitaire à côté de celle qui existe déjà et fait la même chose, parce que le modèle ne connaissait pas l’existante.
• Fonction trop longue. Le code généré tend à écrire le déroulement complet dans une seule fonction, parce que c’est ainsi que le prompt le décrivait.
• Erreur avalée. Bloc catch vide ou valeur par défaut qui fait passer un échec pour un succès. Catégorie OWASP à part entière depuis 2025 (A10).
• Valeurs magiques. Nombres et chaînes de caractères directement dans le code, dont la signification ne ressort que du contexte.
• Généralisation spéculative. Un commutateur de configuration, une interface, une couche d’abstraction pour un cas qui n’existe pas. Les modèles aiment construire « pour plus tard ».
• Commentaire au lieu de clarté. Un commentaire qui décrit ce que fait la ligne suivante. Il ne remplace pas un nom compréhensible et devient faux à la prochaine refonte.
• Grappes de données. Les mêmes cinq paramètres circulent à travers six fonctions, au lieu d’être regroupés dans un objet.
• Restes inutilisés. Imports, variables, fonctions issus d’un état intermédiaire abandonné.
• Test sans assertion. Un test qui exécute du code et ne vérifie rien. Produit de la couverture et aucune sécurité — voir Mesurer la qualité du code.

Comment repérer les code smells dans mon projet ?

Un outil trouve six des dix motifs ci-dessus ; pour les quatre autres, il vous faut un humain. La séparation en vaut la peine, car elle économise du temps de relecture.

• Repérables par machine : doublons, fonctions trop longues, erreurs avalées, valeurs magiques, restes inutilisés, tests sans assertion. C’est ce que prend en charge l’analyse statique du code.
• Repérables uniquement par un humain : implémentation parallèle (suppose de connaître le code existant), généralisation spéculative (suppose de connaître les exigences), commentaire au lieu de clarté, grappes de données.

Ce sont précisément les quatre smells humains qui augmentent avec le code IA — et ceux qui sont les plus difficiles à voir dans le diff, car l’autre pendant se trouve dans un autre fichier.

Comment corriger un code smell sans rien casser ?

En quatre étapes, et la première est celle qui est le plus souvent sautée.

• D’abord sécuriser. Avant de remanier un endroit, il doit exister un test qui fige le comportement actuel. Sans ce test, tout remaniement est un pari.
• Une seule chose par étape. Fusionner le doublon et scinder la fonction et changer les noms donne un diff que personne ne peut relire.
• Laisser le comportement inchangé. Un refactoring qui corrige une erreur au passage n’est plus un refactoring. La correction d’erreur est un commit à part.
• Vérifier après chaque étape. Exécution des tests au vert, puis l’étape suivante.

À quoi cela ressemble concrètement avec du code généré, l’article Refactoring du code généré par IA le décrit.

Vaut-il la peine de corriger chaque smell ?

Non — et c’est la phrase la plus importante sur le sujet. Un smell dans du code qu’on ne touchera plus jamais ne coûte rien. L’effort pour le corriger coûte toujours.

Une hiérarchisation judicieuse combine deux grandeurs, toutes deux lisibles dans le dépôt : combien de fois ce fichier a-t-il été modifié ces derniers mois, et quelle est sa complexité ? Ce qui se retrouve en haut à droite — souvent modifié et complexe — mérite l’attention. Le reste peut sentir mauvais.

Questions fréquentes sur les code smells

Un code smell est-il la même chose qu’un bug ?

Non. Un bug est un comportement erroné. Un smell est un comportement correct dans une structure qui complique les modifications futures. Un smell peut rester sans conséquence pendant des années.

Une IA reconnaît-elle les code smells de façon fiable ?

Pour les motifs repérables par machine, oui, souvent mieux qu’un moteur de règles, car elle lit le contexte. Pour les implémentations parallèles, elle n’est pas fiable, car il lui manque précisément la vue d’ensemble qui rend le smell visible — à moins que l’outil ne parcoure activement le code existant avant d’écrire.

Combien de lignes une fonction peut-elle avoir ?

Il n’existe pas de limite normalisée, et tout chiffre avancé est une convention. Plus solide est la question de savoir si la fonction peut être décrite en une phrase sans « et ». Si la description a besoin d’un « et », la fonction fait deux choses.

Dois-je corriger les smells avant de construire une fonctionnalité ?

Seulement là où la fonctionnalité sera intégrée. Ranger aux abords de sa propre modification est peu coûteux et sera vérifié, parce que cela fait de toute façon partie de la relecture. Un rangement généralisé comme projet à part trouve rarement un commanditaire.

Les quatre smells qu’aucun outil ne trouve naissent tous au même endroit : là où personne n’a regardé ce qui existe déjà. Code Guardian pose précisément cette question avant la première ligne — quelle fonction, quel helper, quelle requête existe déjà ?

Sources

• Martin Fowler, Refactoring (origine et catalogue des code smells, avec Kent Beck).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research (part de copier-coller).
• OWASP Top 10:2025, catégorie A10 « Mishandling of Exceptional Conditions ».

Mise à jour : 27 juillet 2026. Mise en perspective technique générale.