# Les services d'exploitation de l'hébergeur

> **Pour qui :** le **mainteneur** — quels services l'hébergeur se doit à lui-même, et de quoi chacun doit survivre.

> **Décision du 2026-08-04.** Tout ce qu'un hébergeur fait tourner n'appartient pas à un
> tenant. Ce document dit où va quoi, et pourquoi certains services ne peuvent pas vivre
> dans l'overlay qu'ils observent. **Rien n'est construit** : la décision est consignée,
> le chantier reste devant.

## 1. Le test qui tranche

Pour chaque service, une seule question : **de quoi doit-il survivre ?**

Un service qui observe ou répare la fabric ne peut pas dépendre de la fabric. Mettez
Prometheus dans une zone EVPN pour surveiller les hyperviseurs, et le jour où le VXLAN
tombe vous perdez la supervision **et** la raison de la panne en même temps. Pire pour les
sauvegardes : on veut restaurer la configuration d'un commutateur précisément quand le
réseau est cassé.

C'est le motif *in-band / out-of-band*, et il ne se contourne pas.

## 2. Trois catégories, pas deux

**Le tenant de l'hébergeur** — son courriel, sa forge, son nuage, son site. L'hébergeur
*comme entreprise*. Aucune différence avec un client : même plan, même machinerie, mêmes
preuves, même EVPN. Chezlepro est ici hébergeur **et** tenant, ce qui a longtemps masqué
la distinction (D-13).

**Les opérations de l'hébergeur** — ce qui fait tenir la fabric. Doit rester **hors
overlay**.

**Le plan de contrôle** — Set-OPS lui-même, les dépôts, la voûte. Déjà dehors, sur le
poste de l'opérateur et sa forge. Rien à changer.

## 3. Ce qui n'a pas de maison aujourd'hui

Constaté le 2026-08-04, **révisé le 2026-09-05**. La moitié du constat a été levée
entre-temps ; l'autre tient toujours, et il faut distinguer les deux.

**Ce qui a une maison désormais** : les **VM du site** ont leur inventaire Ansible
(`scripts/site_inventaire.py` — 7 machines, 23 groupes, dérivé d'`underlay.yml` sans
fichier intermédiaire), leur socle, leur durcissement, leurs sauvegardes et leur
supervision (`site-mon-01`, depuis le 2026-09-02).

**Ce qui n'en a toujours pas** : les **équipements** eux-mêmes — hyperviseurs,
commutateurs, frontière. C'est là que le constat d'origine reste entier.

| Besoin | État |
|---|---|
| Supervision des hyperviseurs, commutateurs, frontière | personne — `site-mon-01` ne voit que les VM du site |
| Journaux de ces équipements | personne |
| Sauvegarde de leurs configs (`running-config`, `config.xml`, `/etc/pve`) | personne — **vérifié le 2026-09-05, aucun rôle ne les touche** |
| Résolution des noms d'underlay (`asgard`, `bifrost-3`, `bifrost-1`) | personne — **vérifié : `site-dns-01` ne les résout pas** |
| Certificats pour leurs interfaces web | personne |

Ce n'est pas un oubli de conception : ces besoins tombaient entre les chaises. Ils ne sont
d'aucun tenant, et `underlay.yml` ne décrit que du matériel, sans service.

## 4. Où ça va

**Dans le dépôt de l'hébergeur** — celui qui porte déjà `underlay.yml` et
`proxmox-hebergeur.yml`. Ses services d'exploitation lui appartiennent au même titre que
sa fabric ; les loger ailleurs recréerait la confusion qu'on vient de défaire.

Ce dépôt **a désormais son inventaire Ansible** — `scripts/site_inventaire.py`, dynamique
plutôt que généré, parce qu'un site ne dérive de rien : sa déclaration *est* déjà sa forme
finale. Ce qui reste à faire, c'est d'y loger les **équipements**, qui n'y sont pas.

**Rattachement réseau : un pont VLAN ordinaire, jamais un VNet du SDN.** C'est la
contrainte qui découle du §1, et la seule qui distingue ces VM de celles d'un tenant.

## 5. Ce que ça ne change pas

Les **commutateurs** et la **frontière** restent hors flotte : le premier n'a pas d'agent,
la seconde se pilote par API. Ils reçoivent des devis, pas des rôles (D-23).

Les **hyperviseurs** sont un cas différent, et la doctrine « hors flotte » les englobait à
tort : ce sont des machines Debian, joignables en SSH. Rien n'empêche de les gérer par
Ansible depuis l'inventaire de l'hébergeur — c'est même la seule façon d'y poser un
`node_exporter` et un expéditeur de journaux.

## 6. Question ouverte, non tranchée

**L'index du tenant propre de l'hébergeur.** L'idée d'un `0` réservé — local par
construction, donc jamais à coordonner entre hébergeurs, et jamais porté par un tenant qui
déménage — est séduisante et reste **en attente**.

Deux obstacles mesurés le 2026-08-04, à lever avant :

- l'index 0 produit les VNI `1001`–`1006`, et le parc hérité utilise déjà `1001`
  (TechnoLibre historique, 8 VM) et `1003` (KBR). C'est une condition de **séquence** :
  la place se libère quand l'ancien monde s'éteint ;
- **P21** vérifie l'unicité des index entre dépôts frères. Si tout hébergeur a un tenant
  `0`, poser deux dépôts d'hébergeurs côte à côte déclencherait une fausse collision — il
  faudrait exempter `0`, donc inscrire dans la garde que cette valeur est locale.

À noter au passage : la convention héritée était déjà `1000 + numéro de tenant`. La formule
de Set-OPS (`1000 + index×10 + zone`) en est un raffinement, pas une invention.

## 7. La vocation du dépôt réseau : une interface normalisée

Ce dépôt n'est pas seulement un rangement. Il porte le **contrat entre l'Alliance Boréale
et ses hébergeurs** : si chacun présente la même interface, un tenant se déplace de l'un à
l'autre sans rien changer chez lui.

Il sert aussi de **couche d'abstraction du matériel**. Le tenant est encapsulé dans sa zone
SDN EVPN, et le VRF devient la frontière de ce qu'il a le droit de connaître.

| Ce que l'hébergeur fournit | Ce que le tenant en voit |
|---|---|
| une zone EVPN par tenant | son VRF, dérivé de son `index` |
| six VNets et leurs sous-réseaux | ses passerelles `.1`, dérivées |
| un pool | son regroupement |
| un chemin de sortie vers la frontière | « l'extérieur » |
| des classes de nœud et de stockage | un besoin, pas un nom d'équipement |

**Le tenant ne nomme aucun de ces objets.** C'est la mesure de sa portabilité.

### Où en est-on, mesuré

Aucun tenant ne nomme un commutateur, un VLAN, une adresse d'underlay ni une zone EVPN :
tout dérive de son `index`. Au 2026-08-04, les **seules** mentions d'équipement de
l'hébergeur, dans les deux dépôts de tenants :

```
proxmox_clone_noeud:    asgard
proxmox_clone_stockage: TrueNAS
proxmox_clone_pont:     vmbr1 / vmbr3      ← corrigé, voir ci-dessous
```

Trois valeurs, dans un seul fichier. L'architecture tenait déjà la promesse avant qu'on
l'ait formulée.

### La troisième n'était pas seulement non portable : elle était fausse

`proxmox_clone_pont` faisait brancher la VM sur `vmbr1` **avec une étiquette VLAN** —
l'ancien monde. En SDN, une VM appartient à son **VNet**. C'est ce qu'il a fallu corriger à
la main sur `infra-pki-01`, et les treize suivantes auraient suivi.

Le VNet est **dérivable** : `index` + zone de sécurité → `t17serv`, comme le VMID et
l'adresse le sont déjà. `deriver_nomenclature()` expose désormais la zone, `instancier`
émet `proxmox_pont` et une **étiquette vide** (le VNet porte déjà le tag), et la chaîne va
jusqu'à `make creer-vm`.

C'est le meilleur argument pour cette vocation : **ce qui n'est pas dérivé finit par
diverger du réel.**

### Ce qui reste à abstraire

`noeud` et `stockage` désignent de vraies offres de l'hébergeur. Un tenant ne peut pas les
emporter — mais il ne devrait pas non plus les nommer. L'interface normalisée les rendrait
**abstraits** : le tenant déclare un besoin, l'hébergeur publie la correspondance.
`proxmox_noeuds` et `proxmox_stockages` sont déjà chez lui ; il manque la classe, pas le
catalogue.

## 8. Un dépôt à part pour l'hébergeur — FAIT

> **Cette section disait « Rien n'est fait » jusqu'au 2026-09-06.** Le dépôt existe :
> **`SITE-Chezlepro`**, frère de `OPS-Chezlepro`, et le symlink `underlay.yml` du moteur y
> pointe (`../SITE-Chezlepro/underlay.yml`).

Le raisonnement qui l'a motivé, et qui vaut pour tout hébergeur : `underlay.yml` et
`proxmox-hebergeur.yml` décrivent une **infrastructure** — des câbles, des VLAN, un
cluster ; le plan d'un tenant décrit une **organisation** — ses serveurs, ses applications,
ses comptes. Un tenant peut déménager ; une fabric ne déménage pas. Les garder dans le même
dépôt obligeait, à chaque commit, à trancher lequel des deux on touchait.

Ce que le dépôt de l'hébergeur porte aujourd'hui :

| Fichier | Ce qu'il décrit |
|---|---|
| `underlay.yml` | la fabric physique — réseaux, VLAN, MTU, commutateurs, hyperviseurs |
| `proxmox-hebergeur.yml` | l'API du cluster, ses nœuds, ses stockages, ses ponts |
| `opnsense.yml` | la frontière nord/sud (paramètres non sensibles) |
| `underlay.vault.yml` | ses secrets à lui — **voûte séparée**, clé séparée (2026-08-28) |
| `plan/` | ses **propres VM** : sept machines de service (pilotage, autorité, génome, cache, sauvegarde, supervision, DNS) |

C'est cette dernière ligne qui a le plus changé : l'hébergeur n'est plus seulement un
porteur de fabric, **c'est un exploitant** — avec son inventaire (`scripts/site_inventaire.py`),
son socle, son durcissement, ses sauvegardes et sa supervision.

## 9. Le plan d'administration, et ce qu'il n'est pas

> **Les adresses de cette section ont toutes changé** avec la bascule D-77/D-78, terminée le
> 2026-08-22. Elle désignait `10.0.0.0/24` et les « VLAN 11 (transport VXLAN) et 40 (sortie
> tenant) » ; `10.0.0.0/24` n'existe plus, et le transport est passé au VLAN 50.

Le plan d'**administration** — `10.17.0.0/24`, dans la bande basse du supernet du tenant
Chezlepro (D-77) — est réservé aux **équipements** et à l'exploitant. Il n'a **aucun VLAN** :
c'est un segment physique, et **aucun pont d'hyperviseur ne le touche**, donc aucune VM ne
peut y naître. Le validateur refuse d'ailleurs qu'on y déclare une machine.

Distinct de lui, le **contrôle de la grappe** (`192.168.11.0/24`, `vmbr0`) porte l'interface
web de Proxmox et le dialogue entre nœuds.

Aucun trafic tenant ne traverse ni l'un ni l'autre — ni encapsulé, ni décapsulé. C'est
précisément la raison d'être du **VLAN 50** (transport VXLAN) et du **VLAN 40** (transit vers
la frontière) : les avoir sortis de ces domaines de diffusion. *(Le transport a porté le
numéro 11 jusqu'à la bascule ; `192.168.11.0/24` étant pris par le contrôle de la grappe, il
est passé au 50.)*