Vous avez déjà vu ce code généré par l’IA : une fonction appelée getData(), une variable nommée temp, un autre champ user_id puis UserID dans le même fichier. Ça ne semble pas grave au premier abord. Mais dans une base de code de 20 000 lignes, ça devient un cauchemar. Et ce n’est pas seulement un problème de style. C’est un problème de cohérence.
Pourquoi les conventions de nommage comptent vraiment avec l’IA
Il y a cinq ans, les conventions de nommage étaient une question de goût. Les développeurs préféraientsnake_case ou camelCase, et c’était à peu près tout. Aujourd’hui, ce n’est plus une question de préférence. C’est une question de survie pour les équipes qui utilisent l’IA.
Les assistants comme GitHub Copilot, Claude Code ou Amazon CodeWhisperer ne comprennent pas le code comme un humain. Ils le voient comme une suite de motifs. Si vous nommez une variable user_name dans un fichier, puis userName dans un autre, l’IA ne sait pas que c’est la même chose. Elle voit deux identifiants différents. Et elle va générer du code qui s’aligne sur ce qu’elle voit - pas sur ce que vous voulez.
Une étude d’ONSpace AI en décembre 2024 montre que 37 % du code généré par l’IA nécessite une réécriture à cause d’incohérences de nommage. Pour le code écrit à la main, ce chiffre tombe à 12 %. Pourquoi ? Parce qu’un humain, même fatigué, sait que user_id et UserID ne devraient pas coexister. Une IA, elle, ne sait pas. Elle n’a pas de mémoire contextuelle à moins qu’on la lui donne.
Les règles de base selon les langages
Chaque langage a ses propres conventions. Et l’IA les respecte… si on le lui demande clairement.- Python : utilise
snake_casepour les variables et fonctions (get_user_email),PascalCasepour les classes (UserManager). PEP 8 est la bible. Ignorer cette règle, c’est demander à l’IA de générer du code qui sera rejeté par les outils comme Black ou Flake8. - JavaScript/TypeScript :
camelCasepour tout sauf les classes (getUserProfile,AuthController). Les constantes sont enUPPER_SNAKE_CASE(MAX_RETRY_COUNT). - Java :
camelCasepour les méthodes et variables,PascalCasepour les classes. Google a un guide strict. Copilot le suit souvent, mais pas toujours. - Go :
camelCasepour les identifiants publics (commençant par une majuscule),camelCasepour les privés (minuscule). Les noms doivent être courts mais précis.
Comment forcer l’IA à suivre vos règles
Vous ne pouvez pas compter sur l’IA pour deviner. Vous devez lui donner des instructions précises - et répéter ces instructions à chaque génération. Voici un exemple de prompt efficace pour générer du code Python :"Génère une fonction Python qui récupère un utilisateur par ID. Utilise snake_case pour toutes les variables et fonctions. Nomme les paramètres de manière descriptive. Ajoute un docstring pour chaque fonction. Utilise des annotations de type. Ne jamais utiliser de noms génériques comme 'data', 'result' ou 'temp'."Ce n’est pas juste un bon prompt. C’est un prompt exigent. Certaines équipes vont plus loin. Elles créent un fichier
CLAUDE.md dans leur projet (une pratique recommandée par Anthropic) avec des règles comme :
# CLAUDE.md - Toujours utiliser snake_case pour les variables et fonctions en Python - Utiliser le préfixe "user_" pour tous les champs de modèle de base de données : user_id, user_name, user_email - Jamais de "temp", "data", "result" - utiliser "user_input", "calculated_total", etc. - Les booléens doivent commencer par "is_" : is_active, is_verifiedEt quand un développeur utilise Claude Code, il inclut ce fichier dans la requête. Résultat ? 92 % de cohérence entre fichiers, selon une étude de DEV Community en février 2025.
Les pièges du code généré par l’IA
L’IA adore les noms génériques. C’est son biais naturel. Dans une analyse de 10 000 extraits de code générés par l’IA, ONSpace AI a trouvé que 63 % contenaient au moins un identifiant commedata, result, temp, ou obj.
Comparez ça au code humain : seulement 22 % de noms génériques. Pourquoi ? Parce qu’un humain sait que result ne dit rien. login_attempt_count, lui, dit exactement ce qu’il fait.
Un autre piège : la réfaction. Lorsque vous renommez une variable dans un fichier, l’IA ne met pas à jour automatiquement les autres références dans les autres fichiers. Dans 34 % des cas d’ajustement de code assisté par l’IA, selon GitLab, les noms deviennent incohérents après modification. C’est là que les outils automatisés entrent en jeu.
Automatiser la cohérence : les outils qui font le travail à votre place
Vous ne pouvez pas vérifier manuellement 500 fichiers. Vous avez besoin de systèmes qui le font pour vous.- Black pour Python : formate automatiquement le code selon PEP 8. Il réécrit les noms si vous les avez mal écrits.
- Prettier pour JavaScript : s’occupe de la casse et de la ponctuation.
- gofmt pour Go : force une seule façon d’écrire le code - y compris les noms.
- Pre-commit hooks : ces scripts s’exécutent avant chaque
git commit. Si le code ne respecte pas les règles, il est bloqué. Plus de compromis.
La règle d’or : ne comptez pas sur les revues de code
Beaucoup pensent : "Je vais vérifier ça en revue de code." C’est comme compter sur un correcteur orthographique pour corriger un mauvais style d’écriture. Quand le code arrive en revue, la confusion est déjà installée. Molisha Shah, de Augment Code, le dit clairement : "Relying on code reviews to enforce naming conventions is like relying on proofreading to fix bad writing. By the time it reaches review, the damage is done." Au lieu de ça, utilisez des systèmes comme Augment Code’s Rules, qui flaguent automatiquement des erreurs comme :# Flagged: violates team rule requiring snake_case # Found: def GetUserID(userId):C’est une alerte en temps réel. Pas un commentaire sur un pull request.
Les erreurs à éviter
- Ne pas documenter les règles : si personne ne les écrit, personne ne les suit - ni l’IA, ni les humains.
- Changer de convention au milieu du projet : ça crée des zones incohérentes. Fixez une règle, tenez-vous-y.
- Ignorer les différences de langage : un projet avec Python et JavaScript doit avoir des règles distinctes pour chaque. L’IA ne sait pas faire le lien.
- Ne pas inclure des exemples dans les prompts : dire "utilise snake_case" ne suffit pas. Dites : "Comme dans user_id, user_name, user_email - utilise ce format."
Comment commencer - étape par étape
1. Prenez 5 à 10 fichiers représentatifs dans votre projet. Identifiez les noms les plus fréquents. Quelle est la tendance ?snake_case ? camelCase ?
2. Écrivez une règle simple : "Tous les noms de variables en Python doivent être en snake_case. Les booléens commencent par is_."
3. Créez un fichier de style : STYLE.md ou CLAUDE.md. Mettez-y vos règles. Faites-le lire à toute l’équipe.
4. Configurez vos outils : installez Black, Prettier, ou gofmt. Configurez les hooks Git pour les exécuter avant chaque commit.
5. Adaptez vos prompts : ajoutez toujours vos règles de nommage à chaque requête à l’IA. Exemple : "Utilise le préfixe user_ pour tous les champs de base de données, comme dans le modèle User existant."
Cela prend 8 à 12 heures au début. Mais après, vous gagnez des heures chaque semaine.
Le futur : l’IA qui corrige elle-même
Les outils évoluent. GitHub a annoncé en mai 2025 une fonctionnalité appelée "Style Memory". Elle analyse votre code existant et suggère automatiquement les conventions à utiliser. Dans les tests, ça réduit les erreurs de nommage de 52 %. Anthropic a amélioré Claude Code pour qu’il suive des instructions comme "YOU MUST use snake_case for all Python variables" avec 94 % de précision. D’ici 2027, selon Forrester, 85 % des entreprises utiliseront une automatisation complète pour les conventions de nommage. Ce n’est plus une option. C’est une exigence.Conclusion : la cohérence, c’est la confiance
L’IA ne va pas devenir plus intelligente. Elle va juste devenir plus dépendante de vos instructions. Si vous ne lui donnez pas des règles claires, elle va générer du code chaotique. Et ce chaos, c’est vous qui le paierez en heures de revue, en bugs cachés, en onboarding lent. La cohérence dans les noms, c’est la clé pour que l’IA soit un collaborateur, pas un fardeau. Ce n’est pas une question de style. C’est une question de fiabilité.Vous n’avez pas besoin d’être parfait. Vous avez besoin d’être constant.
Pourquoi l’IA génère-t-elle souvent des noms comme "data" ou "temp" ?
L’IA est entraînée sur des millions de lignes de code publiques, dont beaucoup sont mal nommées ou écrits rapidement. Elle apprend à reproduire les motifs les plus fréquents - même les mauvais. Les noms comme "data", "result" ou "temp" sont très courants dans les exemples de code, donc l’IA les utilise par défaut. Ce n’est pas une erreur technique, c’est un biais d’apprentissage. La seule façon de le corriger est de lui donner des exemples précis dans vos prompts.
Est-ce que je dois utiliser la même convention pour tous les langages dans un même projet ?
Non. Chaque langage a ses propres conventions établies. Forcer du snake_case en JavaScript ou du camelCase en Python rend le code moins lisible pour les humains et peut même causer des erreurs avec les outils. Il vaut mieux avoir des règles distinctes pour chaque langage. Documentez-les dans votre fichier STYLE.md et utilisez des outils comme Prettier pour JavaScript et Black pour Python - ils sont conçus pour respecter ces différences.
Comment faire pour que les nouveaux développeurs suivent les conventions ?
Ne comptez pas sur les rappels ou les réunions. Automatisez. Configurez des hooks Git qui bloquent les commits avec des noms invalides. Utilisez des outils comme Flake8 ou ESLint pour afficher les erreurs en temps réel dans l’éditeur. Quand un nouveau développeur voit une erreur en rouge avant même de pousser son code, il apprend plus vite qu’avec un manuel de 20 pages.
Est-ce que les conventions de nommage affectent les performances du code ?
Non, les noms de variables n’ont aucun impact sur la vitesse d’exécution. Le compilateur ou l’interpréteur les remplace par des références internes. Mais elles affectent énormément la vitesse de développement. Des noms clairs réduisent le temps de lecture, de débogage et de collaboration. Selon Augment Code, les équipes avec des conventions cohérentes on-boardent les nouveaux développeurs 28 % plus vite.
Quel outil recommandez-vous pour commencer ?
Commencez par Black pour Python, Prettier pour JavaScript/TypeScript, et gofmt pour Go. Installez-les avec des hooks Git. Ensuite, créez un fichier simple STYLE.md avec vos règles de nommage de base. Enfin, ajoutez ces règles à vos prompts d’IA. C’est une combinaison simple, gratuite et extrêmement efficace. Vous n’avez pas besoin d’outils complexes pour commencer - juste de la constance.
4 Commentaires
James Swinson
Je viens de passer 3 semaines à nettoyer du code généré par Copilot dans un projet legacy. J’ai perdu 40 heures juste à renommer des variables comme 'temp', 'data', et 'result' partout. L’IA, elle, s’en fiche complètement. Elle voit 'user_id' dans un fichier et 'UserID' dans un autre, et elle pense : 'Ah, deux trucs différents, je vais en faire deux autres pour varier !' C’est fou. Maintenant, j’ai un fichier STYLE.md dans chaque repo. Même les nouveaux arrivants le lisent avant de toucher au code. Ça a changé la donne.
Et oui, les hooks Git avec Black et Prettier, c’est la vie. J’ai bloqué 17 commits en un mois parce que quelqu’un avait mis 'getUserName' au lieu de 'get_user_name'. Au début, ils me haïssaient. Maintenant, ils me remercient. Parce que quand tu ouvres un fichier, tu sais ce que tu vas trouver. Pas de surprise. Pas de 'putain, qui a fait ça ?'
Le pire, c’est quand tu modifies un nom dans un fichier et que l’IA le garde partout ailleurs en ancien format. J’ai eu un bug de production parce que 'user_id' était resté en camelCase dans un service tiers. L’IA n’a jamais compris que c’était la même chose. C’est pas de la malveillance, c’est de l’aveuglement. Et on est les seuls à pouvoir la corriger.
Je dis toujours aux juniors : 'Si tu vois un nom comme 'temp', tu le changes. Pas après. Maintenant.' Parce que la cohérence, c’est pas du style. C’est de la survie. Quand tu reviens sur un code après 6 mois, tu veux pas déchiffrer un codex mystique. Tu veux juste comprendre. Et l’IA, elle te donne un codex. Toi, tu dois le traduire.
Magaly Guardado-Marti
Je suis désolée, mais c’est juste pathétique qu’on doive encore parler de ça en 2025. On a des outils qui s’appellent BLACK, PRETTIER, GOFMT, et on a des gens qui se disent 'développeurs' et qui laissent l’IA écrire du code avec des noms de variable comme 'data' ?!?!? C’est comme laisser un enfant de 5 ans choisir le nom de ton chien. 'Fido' ? 'Barky' ? 'Thing'? Non. On a des règles. On a des standards. On a des langages. Et on a des humains qui savent ce qu’ils font. L’IA, elle, est une machine. Elle ne sait pas ce qu’est un bon nom. Elle sait juste ce qu’elle a vu le plus souvent dans les forums de 2012.
Et puis, arrêtez de dire 'mais l’IA, elle fait du bon travail'. Oui, elle fait du travail. Mais c’est du travail de nettoyage. Vous payez quelqu’un pour écrire un texte, et vous le renvoyez à un correcteur pour qu’il réécrive tout. C’est pas de la productivité. C’est de la débilité organisée.
Je viens de voir un PR avec 'getUSERdata()' dans un fichier Python. J’ai refusé. J’ai écrit : 'Si tu veux coder avec l’IA, tu dois la dresser. Pas la laisser te dresser.' Personne n’a osé répondre. Parce que j’ai raison. Et les outils existent. Et les règles sont écrites. Et vous, vous faites comme si c’était normal. Non. Ce n’est pas normal. C’est une faiblesse. Et vous la nourrissez.
Lucile Dubé
OH MON DIEU J’AI EU UN CODE AVEC 'temp' ET 'data' DANS LE MEME FICHIER J’AI CRIE J’AI PLEURE J’AI SUPPRIME TOUT J’AI RECOMMENCE A ZERO
JE VOUS JURE JE VOUS JURE JE VOUS JURE
Rene Pérez Vázquez
Quelle étrange dérive de l’ingénierie logicielle. Autrefois, on écrivait du code pour les machines. Aujourd’hui, on écrit du code pour des IA qui ne comprennent rien, et on les oblige à se conformer à des conventions humaines que même les humains négligent. C’est comme demander à un chien de lire Proust en lui donnant un dictionnaire. Il ne comprendra jamais. Et vous, vous vous épuisez à lui apprendre le sens du mot 'snake_case' comme si c’était une morale divine.
Le vrai problème, c’est que nous avons renoncé à la maîtrise. Nous avons délégué notre jugement à une boîte noire qui s’appelle 'Copilot' et qui, en réalité, n’est qu’un miroir déformant de la paresse collective. Ce n’est pas l’IA qui est mauvaise. C’est nous qui avons cessé d’être exigeants. Nous avons remplacé la discipline par la facilité. Et maintenant, nous nous étonnons que le code soit un désastre.
La cohérence n’est pas une convention. C’est une éthique. Et si vous ne la pratiquez pas, vous n’êtes pas un développeur. Vous êtes un opérateur de machine à générer du bruit.