Dernière mise à jour : 2025-10-30

La racine du mal

Choisir une convention de nommage des machines est, le plus souvent, une étape dont se saisissent les administrateurs système et/ou réseau, assez tôt dans la vie d'une société.
Seulement, lorsque l'entreprise grandit, les bouts de ficelle, mis en place au début, ne suffisent plus (si vous nommez vos serveurs comme les chevaliers du Zodiaque, vous allez avoir du mal passé 30 machines).
C'est généralement à ce moment qu'on va opter pour une politique de nommage mieux dimensionnée mais encore informelle.
Puis l'entreprise grandit encore, elle a plusieurs bâtiments, les administrateurs n'étaient pas tous là au démarrage de l'entreprise (ils ne connaissent pas l'historique). Plusieurs conventions de nommage cohabitent (parfois différentes entre les services). Savoir à qui appartient une machine et à quoi elle sert devient un casse tête.

Face à cela, l'entreprise va mettre en place un outil de CMDB. Malheureusement, dans les faits il y en a souvent plusieurs qui cohabitent et personne ne s'accorde sur celui qui doit primer. Ils sont incomplets, peu mis à jour, lourds, tout le monde les détestent et doit se débrouiller avec de la magie noire pour trouver l'info.

"Mal nommer les choses c'est ajouter au malheur du monde" disait Camus

Chez Astar, nous aimons bien les solutions simples, légères et qui épargnent les usines à gaz. Une bonne politique de nommage peut repousser le moment où vous aurez besoin d'outillage (CMDB) et même après, cela vous épargnera bien du travail d'archéologie du SI. Voici quelques bénéfices simples:

• Un mainteneur qui voit qu'une machine ne répond plus peut directement qualifier la gravité (savoir si c'est une machine de production ou de dev, si c'est de l'usage interne ou du B2C, etc.) et savoir où elle se trouve si il veut agir physiquement dessus
• Un opérateur du SOC peut rapidement savoir où se trouve une machine qui génèrent des alertes et à quoi elle sert. Ceci peut permettre de confirmer/infirmer d'un coup d'oeil si un événement de sécurité est suspect (un équipement réseau qui se met à faire du HTTPS c'est pas la même soupe qu'un poste de travail)
• Si une vulnérabilité publique affecte un certain type de système, une première estimation des machines concernées dans l'entreprise, peut rapidement être menée
• En cas de contrôle RGPD, un Data officer peut rapidement fournir une liste macroscopique des machines qui hébergent des données personnelles
• On peut s'assurer que le déploiement d'une machine est bien passé par toutes les étapes voulues (chacune fournissant un élément du nommage)
• Vous pouvez scripter des comportements en vous basant sur le nom d'une machine (si le nom m'indique que c'est une machine Linux, je me connecte en SSH, si c'est du Windows en WinRM, ...)
• etc.

Mais avant de rentrer dans le vif du sujet, il faut préciser quelque chose d'important :

Si nous vous proposons cet article, c'est parce qu'il y a un intérêt énorme à faire une bonne politque de nommage du premier coup et le plus tôt possible. Cela améliore considérablement la connaissance et la maintenabilité d'un SI (ce qui est l'étape primordiale à la sécurité: on ne sécurise que ce que l'on connait). Cela lutte contre le shadow IT, les angles morts, les surfaces d'attaque inutilement exposées (les serveurs toujours branchés mais que plus personne n'utilise), etc.

Si vous partez sur une convention temporaire que vous prévoyez d'améliorer avec le temps, vous aurez une cohabitation de plusieurs conventions et donc ce sera nul.
Une politique de nommage doit être homogène. Dès qu'on commence à avoir plusieurs conventions qui cohabitent, il vaut mieux perdre un peu de temps à tout remettre à plat que laisser perdurer. C'est beaucoup plus facile à faire que contrôler que toutes les machines sont bien renseignées dans la CMDB. Mais le plus tôt on introduit une politique de nommage, le plus tard on rencontrera ce genre de problème.

Autre considération prépondérante : il va falloir jauger l'aspect intangible des infos que l'on mettra dans le nom. SI vous mettez plein d'infos sujettes à changement (comme le responsable de la machine par exemple) et qu'il faut mettre à jour les noms régulièrement, c'est contre-productif. Mais si vous avez une politique saine de "un serveur = un usage" et que tout changement majeur se fait en mode "je wipe l'ancienne machine et je fais poper une nouvelle", il y a pas mal d'informations qui seront pérenne pendant la durée de vie de la machine (l'OS, l'usage, ...).

Allons-y

Que nommer ?

Qu'est-ce qui pourrait nous intéresser de connaître "d'un coup d'oeil" en lisant le nom d'une machine ? En vrac on peut citer :

• Sa localisation physique (pays, ville, bâtiment, ...)
• Sa localisation logique (Edge, DMZ, Lan, hébergeur, AWS, ...)
• Son type (serveur, workstation, équipement réseau, IoT, ...)
• Son OS (Linux, Windows, BSD, FortiOS, Android, ...)
• Sa criticité opérationnelle (production, pré-production, dev, ...)
• Sa criticité métier (B2C, B2B, interne, ...)
• Le service fourni (Mail, Router, ERP, ...)
• Le responsable (la personne a contacter si on a une question dessus (genre "est-ce que cette machine est toujours utilisée ?"))
• Les données qu'elle héberge (ce bien aimé RGPD veut savoir s'il y a des données personnelles dessus)

Cependant, vous devez aussi limiter la quantité d'information car tout cela sera accessible à un attaquant ayant pu pénétrer dans le réseau (s'il peut trouver d'un coup d'oeil tous les windows XP vulnérables, ou localiser directement le serveur de backup, ce n'est pas à votre avantage).
Tout est affaire de jugement selon la criticité de votre système d'information.

Comment nommer ?

Il y a 3 propriétés que l'on aimerait pour notre convention de nommage :

• que les noms ne soient pas trop longs (des fois il faudra les taper au clavier, il ne faut pas que ce soit une plaie)
• que les noms ne soient pas ambigus pour un humain ("TL" c'est Toulouse ou Toulon ? "S" c'est Serveur ou Smartphone ?, ...)
• que les noms ne soient pas ambigus pour un programme (c'est-à-dire qu'ils puissent être "parsés" pour effectuer des actions ou prendre des décisions)

Et en général, il y a trois alternatives pour les parties du nom :

• soit on utilise une lettre pour chaque info (en général l'initiale)
• soit on utilise un trigramme
• soit on utilise le mot en entier

Aucune n'est satisfaisante

Avec le trigramme (et a fortiori les mots entiers), les noms peuvent être très longs.

Avec les initiales, les risques de collision (quand deux choses différentes ont la même représentation) sont très forts. Par exemple représenter le lieu, ou le service fourni, avec une seule lettre est impossible passé une certaine échelle (car il y a plus que 26 lieux et plus que 26 services).
Le piège peut être de commencer avec une seule lettre car vous n'avez que 2 bureaux (p pour Paris et l pour Lyon). Mais 10 ans plus tard, votre succès fait que vous êtes aussi présents à Perpignan et à Lille (mais p et l sont déjà pris). Donc vous allez utiliser 2 lettres pour décrire ces nouvelles villes (li pour Lille et pe pour Perpignan). Sauf que tous vos traitements qui marchaient automatiquement d'après le nom de l'hôte vont bugguer sur cette lettre en trop.
Le risque de collisions existe aussi avec les trigrammes, mais on peut généralement s'en sortir avec un peu d'imagination.

Les initiales ont aussi le risque d'être plus dures à mémoriser pour les humains, surtout pour les cas peu fréquents. Par exemple, si vous utilisez les initiales pour le type de machine, vous avez réservé le "s" pour serveur. Du coup pour "smartphone" que mettre ? Vous décidez de mettre le "c" (pour cellphone). Mais comme le cas se rencontrera rarement, on ne se souviendra peut être plus de ce que le "c" signifie le cas échéant.

Avec les mots entiers, il sera plus difficile pour un programme d'interpréter les différents champs du nom. Par exemple un humain peut facilement identifier les 3 champs de "toulouseserveurwindows" mais un programme aura énormément de mal.
Donc chaque fois qu'il y a un champ dont le nombre de caractères peut varier, il faut utiliser des séparateurs (par exemple un tiret, deux points, un underscore, ...). De cette manière, un programme pourra toujours utiliser les séparateurs pour isoler les différents champs du nom. Mais ça ajoute de la longueur.

Le meilleur compromis semble être de combiner les approches.
Utilisez des initiales pour les champs où il y a peu de valeurs différentes possibles et où elles ne changent pas régulièrement (par exemple les systèmes d'exploitation).
Utilisez des noms complets pour les champs où il y a trop de possibilités pour que tout le monde retienne les associations par trigramme («Pourquoi Luxembourg on l'a mis en "BNL" ? C'est pour Benelux»).
Utilisez des trigrammes le reste du temps.
N'utilisez les séparateurs qu'entre les mots complets et le reste (ou bien entre les champs qui changent de mode de représentation, pour plus de clarté).

Dans quel ordre nommer ?

L'ordre n'est pas vraiment déterminant. La plupart du temps, la convention de nommage est rapidement adoptée, quelle qu'elle soit.

Voici tout de même trois propositions :

• Aller du plus tangible au plus abstrait : de la localisation physique à la donnée stockée par exemple.
• Aller du plus utile pour déterminer si c'est un actif important, vers le moins utile.
• Aller du champ le plus obligatoire au champ le plus optionnel (ceci permet de facilement omettre certains champs optionnels pour gagner de la place).

Une petite chose à garder en tête,c'est de voir comment seront triées ces hôtes quand vous le afficherez par ordre lexicographique.
Par exemple, mettre le nom de la ville en premier, car c'est souvent pertinent de distinguer d'abod par cette information, avant les autres.

Où nommer ?

Le mieux c'est le serveur DNS interne évidemment. Cela permet d'avoir une gestion centralisée: si on me demande toutes les machines Windows du parc, je peux faire un transfert de zone et trier celles qui correspondent. De la même manière, si une adresse IP n'a pas de résolution DNS associée, on saura que c'est suspect (soit un intrus, soit une machine qui n'a pas suivi le process normal de recette).

C'est en revanche complexe d'utiliser un nommage de toutes les machines avec une partie du réseau en DHCP. L'adressage fixe sera le plus adéquat.
Concernant le fait de nommer des équipements qui ne sont pas connectés au réseau (un PC en standalone par exemple), un enregistrement TXT (simple texte) peut être utilisé au lieu d'un A (association nom <-> IP).

Le nom doit être répliqué en tant que hostname de la machine pour assurer la cohérence. Cependant le hostname est parfois limité en taille (notamment sur les équipements réseau) et risquera donc de devoir être tronqué au dela de 10-12 caractères.

La formule

On ne va pas faussement vous faire attendre, voici le schéma de nommage plébiscité par Astar :

[ENTREPRISE-]CRITICITE-LIEU-TYPE-OS-USAGE

Si vous êtes un prestataire informatique, et que vous gérez le SI de plusieurs entreprises différentes, c'est utile de mettre le nom de cette entreprise au début.
Si c'est seulement pour votre usage interne, c'est inutile.

Voici tout de suite une série d'exemples qui recouvrent différents usages possibles :

• prd:tls:e:fo:fw : Un élément de production (prd) à Toulouse (tls) de type équipement réseau (e) tournant avec l'OS FortiOS (fo) servant de pare-feu (fw)
• 3-ovh-sw-axelor : Un élément ayant une criticité de 3/4, hébergé dans l'infrastructure d'OVH (ovh), de type serveur (s) windows (w) servant d'ERP (axelor)
• m23sl_bi : Un élément de criticité mineure (m), situé dans le VLan 23 (23) de type serveur (s) Linux (l) utilisé pour la business intelligence (bi)

Plus en détail

Criticité

On le met en premier car on veut savoir tout de suite si la machine à laquelle on s'intéresse est importante pour l'entreprise. Si on me dit "y a la machine crit-siege-sw-dc qui vient de tomber" je vais un peu plus me presser que si c'est low-ovh-sl-bi.

On peut utiliser une dénomination dont le lecteur pourra déduire la criticité :

‍

Ou bien utiliser une échelle de criticité textuelle :

‍

Ou encore numérique (1-2-3-4). Mais la version numérique pose toujours le problème que tout le monde n'a pas les mêmes réflexes quant à la criticité maximale (est-ce que c'est 1 ou est-ce que c'est 4 ?), donc nous recommandons la textuelle.

Une alternative peut être de remplacer la criticité par une description des données qui sont stockées et manipulées par cette machine. Dans 95% des cas, la criticité dépend de ces données. Cela peut aussi servir pour des arbitrages ou contraintes RGPD.

On peut simplement l'utiliser en mode booléen : est-ce que oui ou non des données personnelles sont présentes ? Bien entendu, il faut considérer les données personnelles non internes (sinon n'importe quelle machine stocke des noms d'utilisateurs donc des infos personnelles).

On peut aussi rendre ce champ plus riche en utilisant des initiales pour les principaux types de données :

‍

Les données "opérationnelles" sont à considérer comme celles nécessaires à l'accomplissement des tâches auprès des clients. Les données "stratégiques" sont les secrets industriels, les savoir-faires de l'entreprise. Les autres sont assez transparentes.

Si l'on adopte cette approche, ce champ devra toujours être entouré de séparateurs car le nombre de lettres peut varier. Un serveur de paiement hébergera des données personnelles et bancaire (pb). Un serveur de partage de fichier hébergera des données opérationnelles, stratégiques et personnelles (pos).

Comme ce champ va avoir des intersections importantes avec celui de la criticité, on vous déconseille d'utiliser les deux. Il faut toujours essayer de réduire la redondance si l'on veut que les usagers adoptent la convention de nommage. Si les administrateurs système ont l'impression de remplir des données compliquées à récolter et redondantes entre elles, ça ne marchera pas très bien.
Éventuellement, on peut combiner un champ criticité et un booléen ("-p-" si ça contient des données personnelles ou "--" sinon, ou bien "p" vs "n" (null) si on veut gagner de la place sur les séparateurs). Le Data Officer sera aux anges et vous n'aurez pas l'air aussi à l'Ouest que vous l'êtes en cas de contrôle de la CNIL.

Lieu

Connaitre le lieu est intéressant quand l'entreprise est grande et qu'elle dispose de plusieurs locaux, hébergements, datacenters, etc.

"Lieu" peut être entendu au sens géographique (France, Toulouse, Tour Occitanie, ...) ou bien au sens logique (DMZ, VLAN 200, réseau bureautique, ...).

L'aspect géographique est pratique si l'on voit qu'un serveur AD a planté et qu'il faut le rebooter. En effet, savoir rapidement qu'il est à Meudon (3-meu-srv-win-dc) et pas à San Francisco permet de passer son coup de fil plus vite.
Cette information est difficile à normaliser. Si vous commencez par seulement donner des noms de bâtiments mais que, plus tard, vous en avez des milliers dans le monde, on ne pourra plus décrypter l'information "d'un coup d'oeil". Inversement, si vous donnez seulement le nom de la ville ou du pays mais qu'il y a des dizaines de sous-lieux, vous perdez en utilité.
Dans la plupart des entreprises, il y a un responsable informatique par "site". C'est-à-dire un bâtiment ou un regroupement de bâtiments proches. Utiliser le nom du site est un choix pertinent car il y aura peu de collisions de noms, et vous aurez l'information utile : qui je dois appeler s'il y a un problème.
Au delà d'une certaine taille d'entreprise (les multinationales), il peut être plus judicieux d'utiliser un trigramme PAYS-VILLE-SITE (par exemple fla pour France-Labège-ACTYS). En effet, vous n'aurez probablement pas les adresses de tous les responsables par site dans votre bureau, mais plutôt des responsables par pays/région.

Si vous optez plutôt pour la notion de localisation dans le réseau (DMZ, VLAN 200, OVH, WAN, VoIP, zone rouge, ...), il y a quelques pièges.
De prime abord, ça peut sembler être l'information la plus utile : si j'ai une alerte de sécurité sur un serveur, je préfère savoir rapidement s'il est en DMZ (fort risque d'intrusion) ou dans le LAN, plutôt que de savoir s'il est à Vierzon ou à San Franciso.
MAIS
Déjà, ça veut dire qu'il faudra changer le hostname de la machine si vous la changez de position dans le réseau (si vous utilisez la notation par VLan par exemple). Ça peut être pénible.
Ensuite, l'expérience montre que l'information utile de la position dans le réseau peut souvent être en fait déduite des champs criticité et usage. Si c'est votre pare-feu qui a un problème, il aura probablement le tag "crit" et l'usage "fw". Donc avoir indiqué "DMZ" ne vous renseigne pas tellement plus.
Par contre, il y a un intérêt si vous cherchez à aller physiquement investiguer sur une machine dans un immense réseau. Là, savoir qu'elle est dans le VLAN 20, peut vous simplifier la tâche, via le schéma de brassage réseau, plutôt que de frapper à tous les bureaux.

En fait, il faut faire preuve de discernement. Utilisez de manière privilégiée la description géographique. Mais n'hésitez pas à parler au niveau réseau lorsque c'est pertinent.
Par exemple, si mon serveur Web est hébergé sur un VPS Scaleway, dans le Data Center de Paris ... je ne vais pas marquer "paris" (ça ne me sert à rien je ne vais jamais intervenir physiquement sur place). Je marquerai plutôt "sclw" (qui réfère au fait que c'est localisé dans l'infrastructure réseau de Scaleway).

Type

En suivant on indique le type de machine car ça donne tout de suite un début de contexte quant au fait qu'il se passe ceci ou cela.
Une caméra IP qui consomme beaucoup de bande passante ça m'étonne tout de suite moins que si c'est une badgeuse.

On peut partir sur une dénomination légère :

‍

Ou bien donner plus de détails, notamment pour les types d'équipements et d'objets connectés mais ça demandera d'utiliser plusieurs lettres : r:router - sw:switch - f:firewall - ... cm:camera - th:thermostat - r:raspberry - ...
Ce n'est pas forcément utile d'aller à ce niveau de précision car le champ usage donnera aussi des précisions.

OS

Connaitre l'OS peut rapidement permettre de savoir si une machine est concernée par un problème. Par exemple si une vulnérabilité affecte SSH, en se basant sur les noms on peut estimer le nombre de machines concernées (les Linux, les équipements réseau sont probablement concernés mais pas les windows, les android, etc.).

Une dénomination à une seule lettre suffit à couvrir les grandes familles ce qui est, le plus souvent, suffisant :

‍

La plupart des équipements réseau sont des surcouches du système BSD et peuvent donc y être associés. La catégorie "firmware" est un fourre-tout dans lequel on peut mettre les imprimantes, les téléphones sur IP, les caméras IP, etc.
Cependant, on peut être tenté d'aller plus loin dans la précision pour distinguer les différents OS des équipements frontaux afin de réagir plus vite en cas de vulnérabilité publique : FortiOS, Cisco IOS, Junos OS, Gaia, ... mais là aussi cela nécessitera probablement plus d'une seule lettre.

Du coup, si vous utilisez seulement une lettre de description, tant qu'à faire, supprimez le séparateur entre Type et OS, les deux sont assez liés : sw (serveur windows), ci (smarthone iOS), etc.
Si vous utilisez une description plus riche, gardez le séparateur : hpv-proxmox (hyperviseur proxmox).

MAIS
Si vous utilisez une version bien détaillée de l'OS, généralement vous pouvez en fait complètement faire sauter le Type. En effet, l'OS l'indiquera indirectement : iOS (je sais que c'est un smartphone), JuniperOS (je sais que c'est un pare-feu), ...
Il faudra par contre bien distinguer Windows Server et Windows Desktop (éventuellement pareil pour Linux et Mac).

Usage

Ce champ est, en quelque sorte, l'espace commentaire du nom, le joker. On peut y mettre la fonction générale de l'équipement (erp), être plus précis en donnant le nom de l'outil (axelor) ou au contraire plus général en donnant le service qui en est responsable(compta).

Indiquer un responsable (au sens RACI du terme) n'est pas une chose simple à renseigner. D'un côté, c'est une information très utile si elle est précise : ça dit directement à qui il faut s'adresser si on a une question sur cette machine, ce qui est inestimable.
Mais d'un autre côté, plus c'est précis, plus c'est susceptible d'être obsolète rapidement : si vous avez mis le nom du responsable (mettons "dofer") et qu'il est viré par la suite, ça va être pénible de changer tous les noms DNS des machines qu'il gérait. D'ailleurs, en plus d'être pénible, ce serait même risqué puisque des noms DNS sont vraisemblablement utilisés dans des fichiers de configuration.
On veut donc indiquer une information aussi immuable que possible : le nom d'un service/métier (admsys: administration des systèmes) ou d'un poste (rmarket : responsable maketing).

Il faut faire attention à ne pas être trop verbeux non plus car ça demeure une information facilement accessible par les adversaires.

‍

TLDR

Tous ces détails étant donnés, voici comment nous nommons nos propres machines chez Astar :

• une criticité allant de 1 (faible) à 4 (critique)
• un tiret
• un lieu écrit avec autant de lettres qu'on le veut
• un tiret
• le type et l'os décrit avec une seule lettre chacun
• un tiret
• l'usage écrit avec autant de lettres qu'on le veut

Donc l'actif qui héberge notre PKI interne se nomme 4-lcn-sl-pki et le site sur lequel vous lisez actuellement cet article se nomme 2-wbfl-sl-ws.

Le pouvoir de tout nommer

Bien entendu, vous pouvez/devez réappliquer la puissance d'une bonne convention de nommage à toutes les couches d'abstraction: nom d'utilisateur, de groupe, de partages, de bâtiment, de règles de pare-feu, etc.
Par exemple, vous verrez souvent des "ext" dans les noms d'utilisateurs des sous-traitants dans les grandes entreprises ou encore des préfixes "adm" pour les comptes à privilège. Mais on peut aller bien plus loin.