Convention de nommage — machines & services

1. Pourquoi cette page existe

Un étudiant BUT ouvre son TP, lit « connectez-vous à IP_VM2 », ouvre VirtualBox et voit taaf-monitoring. Rien ne lui dit que c’est la même machine, ni ce qui tourne dessus. Il se trompe de VM, installe NextCloud sur le collecteur de métriques, et l’erreur se propage dans tout le TP.

Ce n’est pas un défaut d’attention. Et le problème n’est pas que le TP dise IP_VM2 — un placeholder neutre est au contraire ce qu’on veut (§2.5). Le problème, c’est que trois systèmes de nommage coexistaient sans passerelle entre eux, et que le placeholder n’était accompagné d’aucune glose :

Système	Exemples	Volume
Positionnel	IP_VM2, VM2, VM3, VM4	~87 occurrences
Sémantique	TAAF-MONITORING-001, TAAF-AUDIT-001, TAAF-FS-001	~83 occurrences
Vagrant, minuscules	taaf-monitoring, taaf-siem, tp2-svc-DDU, taaf-pfsense	5 fichiers

Le plus révélateur tient dans une seule ligne de la doc actuelle : IP_VM2 · IP_SOC · IP_AUDIT. Deux machines sur trois sont déjà nommées par leur rôle — la troisième, celle du monitoring, est restée positionnelle. Il ne manquait qu’une règle écrite.

Le test d’un bon nom

Un nom de machine doit répondre à une seule question : qu’est-ce qui tourne dessus ? VM2 n’y répond pas. TAAF-MONITORING-001 y répond en un coup d’œil.

---

2. La règle

2.1 — Forme canonique

TAAF - <RÔLE> - <IDENTIFIANT>
 │        │           │
 │        │           └── 3 chiffres (001, 002…) OU code de base (PAF07, DDU)
 │        └── rôle, pris dans le vocabulaire fermé (§2.3)
 └── préfixe projet, invariant

Règle de lecture : le premier segment est toujours TAAF, le dernier est l’identifiant, tout ce qui est au milieu est le rôle. C’est ce qui permet à un rôle composé de rester valide — TAAF-SATCOM-GW-PAF se lit TAAF / SATCOM-GW / PAF.

2.2 — Deux identifiants, deux usages

Forme	Quand	Exemples
<NNN> — 3 chiffres, zéros en tête	Machine de laboratoire, celle que l’étudiant monte	TAAF-MONITORING-001, TAAF-SOC-001
<BASE>[NN] — code de base	Machine du SI fictif du fil rouge, celle dont l’étudiant lit les logs	TAAF-DB-PAF, TAAF-W-PAF07, TAAF-SATCOM-GW-PAF

La règle des deux mondes — le cœur de la convention

Deux systèmes d’information coexistent, et l’identifiant est ce qui les distingue :

	Le lab de l’étudiant	Le SI du fil rouge (base de PAF)
Qui	les machines qu’il monte, administre, démarre	la base australe qu’il supervise à distance
Identifiant	TAAF-<RÔLE>-<NNN> — ex. TAAF-DB-001	TAAF-<RÔLE>-<BASE> — ex. TAAF-DB-PAF
Adressage	10.42.0.0/16 (+ 192.168.56 mgmt)	10.60.0.0/16

En une phrase : un nom en -001 = ma machine ; un nom en -PAF = la base que je supervise. Une IP en 10.42 = mon lab ; une IP en 10.60 = la base attaquée.

Ce n’est pas cosmétique : les deux mondes poussent leurs logs dans le même Loki. Deux machines sous le même label hostname, c’est une corrélation cassée — le rôle peut être identique (DB, AD, FS…), l’identifiant, jamais. La référence du SI fictif est data/_scenario/entities.yaml ; celle du lab, server/ingenieurs/ma-topologie.yaml.

Cas particulier — équipements de site. Le matériel réseau et OT installé sur une base suit une troisième forme, base avant rôle : TAAF-<BASE>-<RÔLE>-<NN> — TAAF-DDU-GEN-01 (groupe électrogène), TAAF-CDA-SW-01 (commutateur Concordia), TAAF-PAF-AEG-01. C’est volontaire et conforme aux usages d’inventaire : pour un équipement, le site est la clé de tri principale, pas la fonction. Ces noms sont liés côté zabbix-lab/ — leur passage à 3 chiffres est une dette assumée, à traiter avec les repos aval (§5, étape 4).

Codes de base : PAF (Port-aux-Français) · AF (Alfred Faure) · AMS (Amsterdam) · DDU (Dumont-d’Urville) · REU (La Réunion).

Les zéros en tête ne sont pas cosmétiques

TAAF-SOC-01 et TAAF-SOC-001 sont deux chaînes différentes. Un grep, une clé de série Prometheus ou une jointure de log ne les rapprochera jamais. Toujours trois chiffres.

2.3 — Vocabulaire fermé des rôles

Un rôle ne s’invente pas. Il se prend dans cette liste ; l’étendre est une décision, pas un réflexe.

Rôle	Ce qui tourne dessus
MONITORING	Grafana, Prometheus, Loki, Alloy — la supervision
SOC	Grafana de détection, soc-console — la sécurité opérationnelle
AUDIT	Lynis, Grype, Nmap — l’outillage d’audit
AD	Active Directory, DNS de domaine
FS	Partage de fichiers, NextCloud
DB	PostgreSQL base_af
WEB	Frontal web, reverse proxy
GW	Passerelle, pare-feu, routeur
SATCOM-GW	Passerelle de liaison satellite
TELEMETRY	Ingestion de télémétrie satellite
SVC	Services applicatifs regroupés (TP conception)
W	Poste de travail utilisateur

2.4 — La même chaîne, trois casses

C’est ici que se joue toute la lisibilité : une machine porte un seul nom, décliné mécaniquement.

Contexte	Forme	Exemple
Inventaire, scénario, pages de référence	MAJUSCULES	TAAF-MONITORING-001
hostname, vb.name VirtualBox, DNS, conteneurs	minuscules, chaîne identique	taaf-monitoring-001
Énoncés de TP	jamais de nom concret → voir §2.5	IP_VM2

Partout où un nom concret apparaît, la seule chose qui change est la casse : qui lit TAAF-MONITORING-001 dans l’inventaire doit voir taaf-monitoring-001 dans VirtualBox. Aucune traduction mentale.

2.5 — Les TP ne citent jamais un nom concret

Règle absolue. Un énoncé de TP utilise un placeholder positionnel — IP_VM1, IP_VM2, IP_VM3 — et jamais un hostname.

La raison n’est pas cosmétique : un TP qui cite TAAF-MONITORING-001 est couplé à la convention. Le jour où elle change — ou le jour où le TP est rejoué dans un autre contexte, chez un client, sur une autre infra — il faut réécrire des dizaines de fichiers. Avec un placeholder, on édite une table.

┌─────────────────────────────┐
│  Énoncés de TP              │   ← ne connaissent que IP_VM1, IP_VM2, IP_VM3
│  (des dizaines de fichiers) │      portables, réutilisables, stables
└──────────────┬──────────────┘
               │  un seul point de couplage
┌──────────────▼──────────────┐
│  Table de correspondance    │   ← le SEUL endroit qui connaît les vrais noms
│  ressources/infrastructure/ │
└──────────────┬──────────────┘
┌──────────────▼──────────────┐
│  Infrastructure réelle      │   ← TAAF-MONITORING-001, taaf-monitoring-001…
└─────────────────────────────┘

Contrepartie à payer, obligatoirement : un placeholder positionnel ne dit pas ce qui tourne sur la machine. Chaque énoncé doit donc s’ouvrir sur une légende, avant toute autre chose :

:::note[Légende — les trois machines du TP]
| Placeholder | Machine | Ce qui tourne dessus |
|---|---|---|
| **`IP_VM1`** | Supervision | Grafana, Prometheus, Loki, Alloy **+ le SI observé** |
| **`IP_VM2`** | SOC | Grafana de détection, règles Sigma, alerting |
| **`IP_VM3`** | Audit | Outillage offensif et de conformité |

Relevez vos adresses avec `hostname -I` sur chaque VM. Les noms réels sont dans
[Infrastructure](/formation/ressources/infrastructure/) — les énoncés n'en dépendent pas.
:::

Sans cette légende, on retombe exactement sur le problème du §1. Le placeholder seul ne suffit pas — c’est le couple placeholder + légende qui fonctionne. La légende est en tête d’énoncé, pas enfouie dans les prérequis : l’étudiant doit la croiser avant la première commande.

Numérotation : VM1, VM2, VM3 — on commence à 1, dans l’ordre de déclaration du Vagrantfile (monitoring, siem, audit). Une numérotation qui démarre à 2 provoque immédiatement la question « où est la VM1 ? ».

Le point de couplage doit rester unique

Si un hostname concret apparaît dans un second endroit, le découplage est perdu sans que personne s’en aperçoive. Une seule table, dans ressources/infrastructure/. Tout le reste pointe vers elle.

Interdit — pour les noms de machines, pas pour les placeholders

Ces interdits portent sur le nom que porte réellement la machine (hostname, vb.name, inventaire). Dans un énoncé de TP, c’est l’inverse qui s’applique : le placeholder positionnel est la règle (§2.5).

• Nommer une machine par sa position : machine1, vm-2. Un numéro d’ordre ne survit ni à un ajout, ni à une réorganisation.
• Nommer par la technologie : taaf-pfsense, taaf-grafana. Le jour où on remplace l’outil, le nom ment. On nomme la fonction, pas le produit.
• Nommer par le TP : tp1-router, tp2-svc. La machine survit au TP qui l’a créée.
• Citer un hostname dans un énoncé de TP : c’est le couplage que §2.5 interdit.

Ce qui n’est pas une machine

Les réseaux ont leur propre espace de noms et ne suivent pas cette convention : réseau Docker taaf-monitoring, réseaux internes VirtualBox taaf-front, taaf-back, taaf-mgmt, taaf-services, taaf-soc. Ils restent tels quels — un réseau n’est pas un hôte, et les confondre reviendrait à renommer des choses qui n’ont rien à voir.

---

3. Table « une VM = un rôle »

C’est le tableau à publier dans l’Acte 0 et à garder sous les yeux. Il règle le décrochage à lui seul, avant même le renommage.

Machine	Ce qui tourne dessus	Ce que l’étudiant y fait
TAAF-MONITORING-001	Grafana, Prometheus, Loki, Alloy	Construit ses dashboards et ses alertes (Acte 1)
TAAF-SOC-001	Grafana de détection, règles Sigma→LogQL, soc-console	Écrit ses détections et mène ses enquêtes (Acte 2)
TAAF-AUDIT-001	Lynis, Grype, Nmap, outillage offensif	Audite et attaque son propre SI (Acte 3)
TAAF-FS-001	NextCloud	Héberge les services applicatifs — c’est ici qu’on installe, pas sur le monitoring
TAAF-AD-001	Active Directory, DNS	Gère les identités
TAAF-DB-001	PostgreSQL base_af	Sert les données métier

La confusion à tuer

TAAF-MONITORING-001 observe. TAAF-FS-001 héberge. On n’installe jamais un service métier sur la machine de supervision : elle doit rester debout quand le reste tombe — c’est tout son intérêt.

---

4. Table de correspondance — ancien → nouveau

À écrire avant de toucher au premier fichier : c’est elle qui permet de reprendre une migration interrompue.

Actuel	Nouveau	Où	Motif
IP_MONITORING, IP_SOC, IP_AUDIT	IP_VM1, IP_VM2, IP_VM3	doc, 163 occurrences	fait — un seul schéma, numéroté depuis 1
(rien)	légende en tête d’énoncé	14 TP	fait — §2.5

| TAAF-SOC-01 | TAAF-SOC-001 | doc, 13 occurrences | fait — 3 chiffres | | taaf-monitoring | taaf-monitoring-001 | server/_infra/Vagrantfile, server/but/golden-box/Vagrantfile | identifiant manquant | | taaf-audit | taaf-audit-001 | idem | identifiant manquant | | taaf-siem (define "siem") | taaf-soc-001 (define "soc") | idem | la doc dit SOC, Vagrant dit SIEM — le rôle tranche | | taaf-pfsense | taaf-gw-001 | tp-archi/tp1-segmentation/ | nommé par la techno | | taaf-tp1-router | taaf-gw-001 | idem | nommé par le TP | | tp2-svc-<BASE> | taaf-svc-<base> | tp-archi/services/ (ex-tp2-acces-distant/) | préfixe TP | | tp2-gw-<BASE> | taaf-gw-<base> | idem | préfixe TP | | tp2-nomade | taaf-w-001 | idem | rôle poste de travail | | TAAF-AD-001, TAAF-FS-001, TAAF-DB-001 en contexte lab | inchangés | doc (SSO, PingCastle, Wazuh, setup) | machines du lab — conformes -<NNN> | | TAAF-AD-001, TAAF-FS-001, TAAF-DB-001, TAAF-TELEMETRY-001 en contexte fil rouge (échantillons de logs, règles Sigma, kill chain) | TAAF-AD-PAF, TAAF-FS-PAF, TAAF-DB-PAF, TAAF-TELEMETRY-PAF | entities.yaml et doc | fait — règle des deux mondes (§2.2) : le SI fictif porte un code de base, pas un numéro | | KDS-WIN-AD-001 | TAAF-AD-001 (lab) | doc setup | fait — l’ancien préfixe projet est abandonné | | TAAF-W-PAF07, TAAF-SATCOM-GW-PAF | inchangés | entities.yaml et doc | déjà conformes -<BASE> | | TAAF-SAE-001, TAAF-CDA-001 | à trancher | 1 occurrence chacun | orphelins — conserver ou supprimer |

---

5. Ordre de migration

Le renommage touche ~112 fichiers sur 6 zones, dont des scripts exécutables et les fixtures du scénario. Un sed global casserait la corrélation du fil rouge.

flowchart LR
  REF["🔒 entities.yaml<br/><small>référence — on n'y touche pas</small>"]:::ref
  D["1 · documentation/<br/><small>26 fichiers · risque nul</small>"]:::a
  S["2 · server/<br/><small>40 fichiers dont 5 .sh</small>"]:::b
  A["3 · repos aval<br/><small>monitoring · zabbix · soc-console</small>"]:::c
  REF -.->|la convention s'y plie| D --> S --> A
  classDef ref fill:#fee2e2,stroke:#b91c1c,color:#7f1d1d
  classDef a fill:#dcfce7,stroke:#15803d,color:#14532d
  classDef b fill:#fef3c7,stroke:#b45309,color:#78350f
  classDef c fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a

1. data/_scenario/entities.yaml est la référence. On ne le renomme pas : la convention s’aligne dessus. Ses hostnames sont déjà conformes.
2. La documentation d’abord — éradiquer le positionnel. Risque nul, et c’est là qu’est tout le gain pédagogique. Cette étape seule règle le décrochage.
3. server/ ensuite — les Vagrantfile, puis les 5 scripts .sh et l’unité systemd. Validation : un vagrant up complet qui va au bout.
4. Les repos aval en dernier — monitoring/, zabbix-lab/, soc-console/. Attention : un nom d’hôte est une clé de série temporelle. Un dashboard qui perd ses séries est un dashboard vide, sans erreur affichée.

Vérification après chaque étape

# Plus aucun nommage positionnel dans la doc
grep -rn "IP_VM[0-9]\|\bVM[0-9]\b" documentation/src/content/docs/ | wc -l   # attendu : 0

# Padding à 3 chiffres partout
grep -rnE "TAAF-[A-Z-]+-[0-9]{1,2}\b" documentation/src/ server/ | wc -l      # attendu : 0

# Le nom VirtualBox correspond au nom cité dans le TP
grep -rn "vb.name" server/**/Vagrantfile

Le piège silencieux

Renommer un hôte dans monitoring/ ne produit aucune erreur : Prometheus crée simplement une nouvelle série et l’ancienne s’arrête. Le dashboard affiche un trou, pas un message. Vérifiez les séries, pas les logs.

---

6. Étendre la convention

Un nouveau rôle s’ajoute au vocabulaire §2.3 par décision explicite, pas au fil d’un TP. Trois questions avant d’en créer un :

1. Est-ce vraiment une fonction nouvelle, ou une variante d’un rôle existant ?
2. Le nom survivrait-il à un changement de technologie ?
3. Un étudiant qui le lit sait-il ce qui tourne dessus ?

Si l’une des réponses est non, ce n’est pas un rôle — c’est un <IDENTIFIANT> de plus sur un rôle existant.