Odeurs du code généré par IA.

Un assistant IA enveloppe du code dans des fonctions, classes ou interfaces supplémentaires qui ajoutent une couche d'indirection sans masquer la moindre complexité ni permettre la réutilisation — des abstractions qui ne font que rediriger vers un unique site d'appel.

Lorsqu'ils écrivent du nouveau code, les assistants IA ont tendance à coller ou à réécrire une copie légèrement modifiée d'une logique qui existe déjà au lieu d'appeler ou d'extraire une fonction partagée, si bien que le code dupliqué grossit à chaque nouvelle fonctionnalité.

Les assistants IA restructurent rarement le code existant : ils greffent de nouvelles branches, des paramètres drapeaux et des couches d'enveloppe sur ce qui existe déjà, si bien que fonctions et conditionnelles ne cessent de grossir pendant que le refactoring — le retravail qui garde une base de code saine — disparaît sans bruit.

Le modèle écrit à la main du code sur mesure pour quelque chose qu'une bibliothèque standard, une dépendance existante ou un helper déjà présent dans le dépôt fait déjà — ajoutant une logique dupliquée et moins testée au lieu d'appeler ce qui existe déjà.

Code généré par IA qui appelle des fonctions, méthodes, paramètres, clés de configuration ou paquets qui semblent plausibles mais n'existent pas dans la version réelle de la bibliothèque dont vous dépendez.

Les assistants IA tendent à générer du code qui ne gère que le cas réussi et bien formé — en sautant la validation des entrées, la gestion des erreurs, les vérifications de null/vide et les cas limites — si bien que le code marche dans la démo et casse en production.

Les assistants IA produisent du code fonctionnel qui omet silencieusement les contrôles de sécurité qu'un humain ajouterait par habitude — validation des entrées, autorisation, encodage des sorties, gestion des secrets — parce que « ça compile et ça renvoie 200 » ressemble à du travail terminé.

Des commentaires qui sont des artefacts de la conversation de génération — prompts reformulés, narration pas à pas, apartés de discussion et élisions de marqueur comme `// ... rest of the code here` — committés dans le code source au lieu d'une vraie documentation.

Les assistants IA alourdissent une logique simple de commentaires qui répètent chaque ligne, de narration pas à pas, d'échelles défensives de vérifications de null et d'expressions à rallonge là où un idiome du langage ou un helper existant suffirait — le nombre de lignes gonfle sans ajouter de comportement.

Un assistant IA nomme un nouveau code avec des marqueurs génériques ou une convention inédite qui ignore les identifiants existants et le vocabulaire métier du dépôt, érodant la lisibilité et engendrant des concepts dupliqués et mal décrits.

Code généré par IA qui ignore discrètement les conventions établies d'un dépôt — réinventant des helpers, choisissant la mauvaise bibliothèque et adoptant un nommage et une gestion d'erreurs non conformes au style maison — de sorte que la base de code dérive vers un style générique, moyen-de-l'internet.

Les assistants IA produisent avec assurance des API, des bibliothèques et des idiomes qui étaient d'actualité il y a plusieurs années mais qui sont aujourd'hui dépréciés, supprimés ou remplacés, parce que leur connaissance paramétrique est figée à une date limite d'entraînement et que l'ancien pattern reste statistiquement le plus courant dans leur corpus.

Les assistants IA se prémunissent contre des défaillances qui ne peuvent pas se produire, enveloppant du code déjà sûr dans des vérifications de null redondantes, des clauses de garde mortes et des blocs try/except attrape-tout qui ajoutent de la complexité sans ajouter de sécurité.

Les assistants IA intègrent des valeurs propres à l’environnement — URL, ports, chemins, délais d’expiration, clés et nombres magiques — directement dans la logique au lieu de les lire depuis la configuration ou l’environnement, parce qu’un littéral est le jeton suivant le plus probable et que le modèle n’a pas conscience de votre couche de configuration existante.