Nommage aveugle au contexte.

Un relecteur repère un nommage aveugle au contexte quand les noms d'un diff rédigé par IA sont localement plausibles mais déconnectés du dépôt environnant. Indices révélateurs :

• Marqueurs génériques dans du code métier : data, result, temp, item, obj, payload, response, value, handleStuff, processData là où le module parle déjà un langage spécifique (grossPremium, Customer, getCustomerById).
• Dérive des conventions : un symbole en snake_case déposé dans un fichier camelCase, un préfixe booléen is/has manquant, ou un nouveau verbe CRUD (fetch*) dans une base de code qui a standardisé sur get*. Chaque diff suit le style qu'il a rencontré en dernier, introduisant une quatrième convention. Puis une cinquième.
• Prolifération de synonymes / concepts dupliqués : l'IA invente fetchUser alors que getCustomerById existe déjà, ou mélange customer/client/user pour une même entité — réimplémentant au lieu de réutiliser.
• Des noms qui décrivent le mécanisme, pas l'intention — ou qui mentent sur le comportement : processData() qui calcule en fait la taxe de vente. Les agents (et le prochain agent) lisent processData() et procèdent comme si ce nom racontait toute l'histoire, donc le sens erroné se propage à chaque site d'appel.

// Le dépôt exporte déjà getCustomerById(id: CustomerId): Promise<Customer>
// L'IA ajoute un quasi-doublon avec des noms aveugles au contexte :
async function fetchData(id: string) {          // verbe générique, type lâche
  const result = await db.query("select * from customers where id = $1", [id]);
  const temp = result.rows[0];                  // 'temp' cache qu'il s'agit d'un Customer
  return temp;                                  // rien ici ne dit « Customer »
}

Pourquoi les modèles le produisent

• Biais de fréquence du token suivant. Dans l'ensemble du corpus d'entraînement, data/result/temp/foo comptent parmi les identifiants les plus fréquents, en particulier dans le code de tutoriel et de boilerplate que les LLM ingèrent massivement. Générer le nom statistiquement moyen est exactement ce pour quoi un prédicteur de token suivant est optimisé, ce qui gomme l'intention métier.
• Aucun (ou un) contexte de dépôt (tronqué). Le modèle voit rarement le glossaire du module voisin ou le getCustomerById existant. Le résumé du rapport GitClear 2025 publié par DevClass note que les assistants sont moins enclins à proposer de réutiliser une fonction similaire ailleurs, en partie à cause de la taille limitée du contexte (DevClass sur GitClear 2025).
• Optimisation locale / faible instinct de refactorisation. Chaque tour optimise le prompt immédiat, pas la base de code dans son ensemble. OX Security a relevé un évitement des refactorisations — une IA qui « excelle à générer du nouveau code mais ne revient jamais améliorer l'architecture » — dans 80–90 % du code IA étudié (rapport OX).
• Obsolescence liée à la date limite d'entraînement. Des conventions et des noms d'API issus de corpus plus anciens refont surface même après qu'un projet a évolué.

Pourquoi c'est nuisible

• Lisibilité/maintenabilité : les noms sont la documentation principale d'une base de code ; les noms génériques obligent chaque lecteur à re-déduire l'intention à partir du corps.
• Duplication et défauts : renommer un concept engendre une implémentation parallèle. L'analyse 2025 de GitClear, portant sur 211 millions de lignes modifiées (2020–2024), montre que les lignes associées au refactoring (lignes « déplacées ») sont passées de 25 % des lignes modifiées en 2021 à moins de 10 % en 2024, tandis que les lignes copiées-collées passaient de 8,3 % à 12,3 % sur la même période ; 2024 est la première année où les lignes copiées-collées dépassent les lignes déplacées, et les blocs d'au moins cinq lignes dupliquées ont été multipliés par huit environ au cours de 2024 (GitClear 2025).
• Boucle de rétroaction des agents (le préjudice spécifique à l'IA) : les noms sont l'interface que le prochain agent lit au pied de la lettre. Comme le dit l'Encyclopedia of Agentic Coding Patterns, « un agent IA traite les noms qu'il trouve dans une base de code comme son principal signal pour comprendre ce que font les choses », et « un nommage incohérent dans le code existant produit un nommage incohérent dans le code généré » (AI Pattern Book).
• Charge de revue & exactitude : les relecteurs doivent mentalement faire correspondre temp/data aux concepts métier, ce qui masque des bugs ; des noms trompeurs entraînent un mauvais usage aux sites d'appel.
• Angles morts de sécurité/audit : un secret ou un jeton garé dans une variable nommée data/tmp échappe aux greps et à l'attention de revue basés sur les noms.

Remarque : les outils statiques attrapent bien les violations de nommage locales et explicites (casse, longueur, mots interdits), mais la correspondance d'un nom avec le sens métier dépend de l'intention et échappe largement à la détection automatisée.

Tactiques de revue & de prompting

• Injectez les conventions et le glossaire dans le contexte. Tenez un court guide de nommage (casse, préfixes booléens, verbes CRUD, termes métier) dans CLAUDE.md/les docs de style et exigez que le modèle le suive. Appliquez les termes du glossaire métier de manière cohérente afin que les synonymes se réduisent à un seul mot.
• Forcez la réutilisation avant la création. Prompt : « Cherche dans le dépôt une fonction/un type existant pour ceci avant d'en ajouter un ; réutilise-le. » Cela contre directement l'échec de concept dupliqué signalé par GitClear et OX.
• Nommez les choses dans le prompt. « Nomme le handler createRefund » vaut mieux que « ajoute le traitement des remboursements ». Spécifiez des noms métier (monthlyRevenue, pas float1).
• Exigez l'exécution du linter + du scan de duplication sur le diff (naming-convention + id-denylist + jscpd) et faites en sorte que le modèle corrige les violations plutôt que vous à la main.

Le refactoring — appliquez Renommer la méthode (et la même opération pour les variables) pour corriger les noms trompeurs, et supprimez le Code dupliqué en appelant le symbole existant au lieu du nouveau.

Avant :

async function fetchData(id: string) {
  const result = await db.query("select * from customers where id = $1", [id]);
  const temp = result.rows[0];
  return temp;
}

Après (supprimez le quasi-doublon et appelez la fonction de dépôt existante avec le type métier) :

// Ne re-requête pas — réutilise getCustomerById et garde le vocabulaire métier.
const customer = await getCustomerById(id as CustomerId);

Si un nom trompeur a déjà été livré, renommez-le pour qu'il corresponde au comportement (processData → calculateSalesTax) avant de construire dessus, afin que les agents et les humains en aval héritent du bon signal.