L'importance des conventions de nommage

Adopter une convention de nommage claire et cohérente est essentiel dans tout environnement informatique. Que ce soit pour nommer des fichiers, des variables, des bases de données, des ressources cloud ou des endpoints d’API, un mauvais choix peut rapidement entraîner de la confusion, des erreurs et une maintenance difficile.

Pourquoi des normes de nommage ?

Mettre en place une règle de nommage est essentiel pour assurer la lisibilité, la cohérence et la maintenabilité d’un projet, quel que soit son domaine (fichiers, programmation, cloud, réseaux, etc.). Sans une convention bien définie, les noms deviennent rapidement incohérents, difficiles à comprendre et sources d’erreurs.

Voici les principales raisons pour lesquelles une règle de nommage standardisée est indispensable.

Améliorer la lisibilité et la compréhension

Un nom clair et structuré permet de comprendre immédiatement l’utilité d’un fichier, d’une variable ou d’une ressource sans avoir à deviner son contenu ou son rôle.

Bonnes pratiques :

• Donner des noms significatifs et explicites.
• Éviter les abréviations ambiguës ou cryptiques.
• S’assurer que tout le monde comprend le format utilisé.

Garantir la cohérence et la standardisation

Une convention de nommage assure une uniformité sur l’ensemble du projet et facilite la collaboration entre équipes. Sans standard, chaque personne applique ses propres règles, ce qui peut générer du chaos et des erreurs.

Bonnes pratiques :

• Appliquer la même convention partout (fichiers, variables, bases de données, cloud…).
• Respecter les standards du domaine (CamelCase en Java, snake_case en Python, kebab-case pour les URLs).
• Documenter la convention pour qu’elle soit clairement définie et suivie.

Faciliter la recherche et l’organisation

Quand les noms suivent une convention claire, retrouver un fichier, une variable ou une ressource devient immédiat. Cela évite les pertes de temps et améliore l’efficacité du travail.

Bonnes pratiques :

• Adopter un format structuré et hiérarchisé.
• Utiliser des préfixes pour classer les ressources (ex : log-, backup-, user-).
• Adopter un format de dates et de versions standardisé.

Réduire les erreurs et les conflits

Des noms mal définis peuvent causer des erreurs critiques dans un projet, notamment lors de l’utilisation de scripts, d’outils d’automatisation ou de bases de données. Une convention stricte permet de minimiser ces risques.

Bonnes pratiques :

• Éviter les caractères spéciaux qui peuvent causer des erreurs dans certains systèmes ($, %, &, #).
• Ne pas utiliser de noms génériques (test, final, doc1).
• Suivre un format prévisible pour éviter les doublons (vm-prd-aws-ew1-web-001).

Permettre une meilleure automatisation

Les outils coomme Gitlab CI/CD, Terraform, Ansible, et de gestion des logs** reposent sur des règles de nommage précises pour fonctionner efficacement. Une nomenclature structurée permet donc une intégration fluide avec ces outils.

Bonnes pratiques :

• Définir des noms prévisibles et bien formatés pour les pipelines CI/CD.
• Utiliser un modèle de convention unique pour l’infrastructure-as-code.
• Adopter une nomenclature compatible avec les scripts et requêtes.

Faciliter la collaboration en équipe

Une convention de nommage bien définie facilite le travail en équipe, car chacun comprend immédiatement ce que désignent les noms de fichiers, variables ou ressources cloud. Cela évite les malentendus et les pertes de temps.

Bonnes pratiques :

• Définir et documenter la convention pour tous les membres de l’équipe.
• Imposer une uniformité stricte dans le projet.
• Former les nouveaux membres pour éviter les écarts.

Les différents types de nommage en programmation

Le nommage en programmation joue un rôle essentiel dans la lisibilité, la maintenance et la compréhension du code. Un mauvais choix de nom peut rendre un programme illisible, difficile à déboguer et compliqué à faire évoluer. Pour garantir une cohérence et une bonne organisation, plusieurs conventions de nommage sont utilisées selon les langages et les contextes.

Voici les principaux types de nommage que vous pouvez adopter en programmation.

Nommage des variables et constantes

Les variables et constantes doivent avoir un nom significatif et explicite pour éviter toute ambiguïté sur leur contenu ou leur utilité.

**Bonnes pratiques :

• Décrire précisément la donnée contenue (total_utilisateurs au lieu de tu).
• Suivre une convention adaptée au langage (camelCase, snake_case, PascalCase).
• Différencier les constantes des variables (généralement en majuscules).

Mauvaises pratiques :

Mauvais exemple	Bon exemple
a = 10	nombre_utilisateurs = 10
temp	temperature_celsius
x1, x2, x3	coord_x, coord_y, coord_z

Formats courants :

Format	Exemples	Langages concernés
camelCase	maVariable, totalUtilisateurs	Java, JavaScript, C#
snake_case	ma_variable, nombre_utilisateurs	Python, Ruby, PHP
PascalCase	MaVariable, TotalUtilisateurs	C#, TypeScript, Java (classes)
UPPER_CASE	MAX_LENGTH, DB_HOST	Constantes en C, Python, Java

Nommage des fonctions et méthodes

Une fonction représente une action, son nom doit donc exprimer clairement ce qu’elle fait.

Bonnes pratiques :

• Commencer par un verbe d’action (calculerPrix(), obtenirUtilisateur()).
• Utiliser un nom descriptif (éviter doStuff() ou process()).
• Respecter la convention du langage (camelCase en JavaScript, snake_case en Python).

Mauvaises pratiques :

Mauvais exemple	Bon exemple
doIt()	envoyerEmail()
getData()	obtenirDonnéesUtilisateur()
processRequest()	traiterRequeteHTTP()

Nommage des classes et objets

Les classes représentent généralement des entités, leur nom doit être clair, compréhensible et en PascalCase.

Bonnes pratiques :

• Utiliser un nom de classe qui représente un objet réel (Utilisateur, Facture).
• Commencer par une majuscule et suivre PascalCase (UserManager).
• Différencier les interfaces et implémentations (IService pour une interface, ServiceImpl pour l’implémentation).

Mauvaises pratiques :

Mauvais exemple	Bon exemple
dataProcessor	TraitementDonnées
class1, obj	Client, Commande
iuser, iservice	IUser, IService

Nommage des bases de données

Une bonne convention de nommage en base de données facilite la compréhension des structures et l’écriture des requêtes SQL.

Bonnes pratiques :

• Tables au singulier (utilisateur, commande).
• Colonnes en snake_case (date_creation, client_id).
• Utiliser des préfixes logiques (fk_, idx_).

Mauvaises pratiques :

Mauvais exemple	Bon exemple
UTILISATEURS	utilisateur
UserData	utilisateur
UserID	utilisateur_id

Exemples d’une structure bien nommée :

CREATE TABLE utilisateur (
    utilisateur_id SERIAL PRIMARY KEY,
    nom VARCHAR(100),
    email VARCHAR(255) UNIQUE,
    date_creation TIMESTAMP DEFAULT now()
);

Nommage des branches Git et des pipelines CI/CD

Le nommage des branches Git et des pipelines CI/CD permet de garder une bonne organisation dans le développement collaboratif.

Bonnes pratiques :

• Utiliser un préfixe selon le type de branche (feature/, fix/, release/).
• Inclure un identifiant clair (feature/authentication, fix/login-bug).
• Nommer les jobs CI/CD de manière descriptive (deploy-backend, run-tests).

Mauvaises pratiques :

Mauvais exemple	Bon exemple
new-branch	feature/paiement-en-ligne
bugfix	fix/correction-authentification
branch1	release/v2.1.0

Nommage des ressources multi-cloud

Dans un environnement multi-cloud (AWS, Azure, GCP, Outscale, OVH, etc.), l’usage d’une convention de nommage standardisée est essentiel pour assurer la cohérence, la gestion efficace et l’automatisation des ressources.

Une mauvaise nomenclature peut rapidement entraîner des confusions, des erreurs de configuration et des difficultés dans la recherche et la maintenance des ressources.

Gérer des ressources sur plusieurs fournisseurs cloud implique d’avoir une nomenclature cohérente pour :

• Faciliter la gestion et l’organisation des ressources.
• Assurer une recherche rapide et éviter les doublons.
• Réduire les erreurs humaines dans la configuration et l’automatisation.
• Simplifier les scripts et outils d’infrastructure-as-code (Terraform, Ansible, OpenTofu).

Exemple de convention de nommage multi-cloud

Pour uniformiser le nommage des ressources, j’utilise le format suivant :

<type>-<environnement>-<cloud>-<région>-<az>-<rôle>-<numéro>

Élément	Longueur	Description
type	2 lettres	Catégorie de la ressource (vm, lb, sg, db, etc.)
environnement	3 lettres	Environnement (prd, dev, ppd pour préproduction)
cloud	3 lettres	Fournisseur cloud (aws, azr, gcp, osc)
région	3 lettres	Code court de la région (ew1 pour eu-west-1, us1 pour us-east-1, etc.)
az	1 lettre	Zone de disponibilité (a, b, c…)
rôle	Variable	Fonction principale (web, db, app, fs, etc.)
numéro	3 chiffres	Identifiant unique (001 à 999)

Vous pouvez adapter ce format à vos besoins, en ajoutant ou en retirant des éléments selon votre contexte. Vous pouvez également ne pas utiliser de tirets pour séparer les éléments, mais veillez à garder une cohérence dans toute l’organisation.

Exemple :

vm-prd-aws-ew1-a-web-001

VM en production, hébergée sur AWS, en région eu-west-1, zone a, jouant le rôle de serveur web.

Abréviations pour les types de ressources

Chaque ressource doit avoir un type de ressource clairement défini. Voici une liste des quelques abréviations possibles :

Type de ressource	Abréviation
Machine virtuelle	vm
Load balancer	lb
Groupe de sécurité	sg
Base de données	db
Stockage objet (S3, blob)	os
Volume de stockage	vl
Sous-réseau	sb
Table de routage	rt
Adresse IP élastique	ei
Interface réseau	ni
Cluster Kubernetes	kc
Auto-scaling group	as
Firewall	fw

Abréviations pour les fournisseurs cloud et les régions

Cloud	Abréviation	Exemples de régions
AWS	aws	ew1 (eu-west-1), us1 (us-east-1)
Azure	azr	fc1 (francecentral), ew1 (westeurope)
GCP	gcp	uc1 (us-central1), ew4 (europe-west4)
Outscale	osc	ew2 (eu-west-2), cg1 (cloudgouv-eu-west-1)
OVH	ovh	gr1 (gravelines), sb1 (strasbourg)
Scaleway	scw	fp1 (Paris), na1 (Amsterdam)

Vous pouvez utiliser plus de lettres pour les régions si nécessaire, mais gardez une cohérence dans toute l’organisation.

Abréviations pour les rôles des ressources

Rôle	Description
app	Serveur d’application
api	Passerelle API
web	Serveur web
dbs	Serveur de base de données
sql	Base de données SQL
nos	Base de données NoSQL
fsv	Serveur de fichiers
bck	Serveur de sauvegarde
vpn	Serveur VPN
dns	Serveur DNS
dhc	Serveur DHCP
log	Serveur de logs
mon	Monitoring
cic	CI/CD runner
git	Serveur git
kub	Nœud Kubernetes
doc	Hôte Docker
iam	Identity & Access Management
mta	Serveur de messagerie

Exemples de noms de ressources

Nom de la ressource	Description
vm-prd-aws-ew1-a-web-001	Serveur web en production sur AWS eu-west-1, AZ a.
lb-ppd-osc-cg1-b-lbs-002	Load balancer en préproduction sur Outscale cloudgouv-eu-west-1, AZ b.
sg-dev-gcp-uc1-c-dns-003	Groupe de sécurité DNS en développement sur GCP us-central1, AZ c.
db-prd-azr-fc1-a-sql-004	Base de données SQL en production sur Azure francecentral, AZ a.
vm-dev-osc-ew2-b-api-005	Passerelle API en développement sur Outscale eu-west-2, AZ b.
kc-prd-aws-ew1-c-kub-006	Cluster Kubernetes en production sur AWS eu-west-1, AZ c.
os-ppd-gcp-ew4-a-bck-007	Stockage objet de sauvegarde en préproduction sur GCP europe-west4, AZ a.

Avantages de cette convention de nommage

• Uniformisation multi-cloud : AWS, Azure, GCP et Outscale suivent une même logique.
• Lisibilité immédiate : chaque nom permet d’identifier le type, l’environnement et la localisation de la ressource.
• Facilité d’automatisation : compatible avec des outils comme Terraform, Ansible et OpenTofu.
• Réduction des erreurs : limite les conflits et garantit une gestion efficace des ressources.

Avec cette convention, je m’assure d’un environnement cloud structuré, lisible et facile à administrer sur toutes les plateformes.

Conclusion

Croyez mon expérience : j’ai travaillé dans des structures où les serveurs portaient des noms de villes. Et combien de fois me suis-je fait peur en réalisant que j’étais en production juste après avoir tapé une commande ! 🤯

J’ai aussi passé des heures à essayer de comprendre la logique de nommage d’un projet pour déboguer un programme, cherchant en vain une cohérence qui n’existait pas. Perte de temps, stress, erreurs évitables… Tout cela parce qu’aucune règle claire n’avait été définie.

Avec une convention de nommage rigoureuse, ces problèmes disparaissent :

• Je sais immédiatement où je travaille et sur quelle ressource.
• La maintenance devient plus simple, car chaque nom suit une logique claire.
• Les erreurs humaines sont réduites, surtout en environnement critique.
• L’automatisation est facilitée, que ce soit avec Terraform, Ansible ou des scripts bash.

Ce guide m’a permis de poser les bases d’un naming standardisé pour tous les aspects d’un projet : fichiers, programmation, cloud, API, CI/CD. En appliquant ces règles, je m’assure que mon infrastructure est organisée, lisible et évolutive.

Je préfère passer mon temps à coder et à automatiser, plutôt qu’à deviner ce que signifie un nom de ressource. Et vous ?