Set-OPS-Public/docs/responsabilites-locataire-hebergeur.md

Pour qui : le locataire et l'hébergeur — les deux lisent le même texte, et c'est le but. Un partage de responsabilités dont chaque partie aurait sa version est un désaccord qui attend son incident.

Responsabilités du locataire et de l'hébergeur

1. Le principe : une responsabilité est la conséquence d'un pouvoir

Ce document ne distribue pas des devoirs par bonne volonté. Il les dérive :

Qui peut, doit. Qui ne peut pas, ne peut pas être tenu — et personne ne peut se décharger sur celui qui ne peut pas.

Trois règles en découlent, et elles décident de tout le reste :

1. À chaque pouvoir sa responsabilité. Un pouvoir sans devoir correspondant est une prise sur autrui ; un devoir sans pouvoir correspondant est un piège.
2. Une responsabilité sans mécanisme est un vœu. Chaque ligne du tableau nomme l'endroit du système qui la rend vraie — un rôle, une garde, une commande. Ce qui n'a pas de mécanisme est écrit au §5, parmi les points non tranchés, plutôt que promis.
3. Le silence ne crée pas de responsabilité. Si une ligne n'a pas de vis-à-vis, ce n'est pas une zone partagée : c'est un trou, et il se voit.

2. La ligne de partage : trois portées, et aucun pouvoir total

C'est la structure même du moteur, pas une convention de contrat (roles/serveur_ops_tenant/README.md) :

calculer       plan → inventaire            aucune voûte      n'importe quel runner
configurer     des rôles sur ses machines   voûte du TENANT   le runner du locataire
matérialiser   créer / détruire des VM      voûte du SITE     le runner de l'hébergeur

Aucun runner n'est omnipotent. Celui de l'hébergeur matérialise le terrain et n'entre jamais chez un locataire ; celui du locataire configure son écosystème et ne touche jamais la fabric. Tout ce qui suit découle de cette coupure.

3. Le tableau

Le pouvoir	Qui le détient	La responsabilité qui en découle	Ce que l'autre ne peut donc pas faire à sa place
Créer et détruire les machines (raser, site-raser, clonage du gabarit)	l'hébergeur	Que les machines existent, démarrent et tiennent ; qu'aucune destruction n'ait lieu sans confirmation explicite ni sans sauvegarde hors du site au préalable	Le locataire ne peut pas garantir l'existence de ses machines, ni se les rendre lui-même
Le réseau, la frontière et le stockage (SDN, VLAN, OPNsense, Ceph)	l'hébergeur	Que le chemin existe et que la bordure refuse ce qui n'est pas déclaré ; prévenir avant toute coupure planifiée	Le locataire ne peut pas ouvrir un flux vers l'extérieur sans que l'hébergeur l'applique
Déclarer ses flux (roles/*/meta/flux.yml, pare-feu d'hôte)	le locataire	Déclarer ce que ses services ont besoin d'échanger ; ce qui n'est pas déclaré est refusé, et c'est voulu	L'hébergeur ne peut pas deviner un flux applicatif ; il n'ouvrira rien « au cas où »
Configurer les services (son runner, sa voûte)	le locataire	L'état de ses services : ce qui est déployé, à jour, et conforme à son plan	L'hébergeur ne peut pas configurer un service du locataire : il n'a pas sa voûte
L'annuaire et l'entrée unique (LDAP, Keycloak)	le locataire	Qui entre, qui sort, et quand — créer, désactiver, révoquer sans attendre personne	L'hébergeur ne peut retirer l'accès de personne : mutualiser l'annuaire serait lui confier ses gens
Les habilitations (appartenance aux groupes, D-66/D-67)	le locataire	Tenir ses groupes à jour. Le moteur amorce un accès puis se retire : il ne réconcilie jamais les appartenances	Ni l'hébergeur ni l'outillage ne corrigeront un groupe : un redéploiement n'efface pas le compte créé la veille
Son autorité de certification (step-ca, D-87)	le locataire	Renouveler ses certificats, et recharger les services qui les servent — un certificat renouvelé sur disque reste servi périmé en mémoire	L'hébergeur ne peut pas émettre de certificat au nom du locataire, et c'est délibéré : il pourrait sinon se faire passer pour n'importe lequel de ses services
Ses journaux (Loki, D-87)	le locataire	Les lire, les conserver, et les fournir s'il demande de l'aide	L'hébergeur ne voit pas les journaux du locataire : il ne peut donc pas diagnostiquer un incident applicatif à sa place
La disponibilité de la fabric (une VM est-elle debout ?)	l'hébergeur	Constater qu'une machine est tombée et le dire — c'est sa fabric	Le locataire n'a pas de vue sur l'hyperviseur qui porte ses VM
Les métriques d'hébergement (charge, disque)	l'hébergeur, avec réserve	S'en servir pour dimensionner et prévenir, pas pour lire l'activité d'une organisation — elles disent quand et combien	— (elles ne disent pas quoi : le contenu reste hors de portée)
Le dépôt de sauvegarde (serveur_backup, chiffré côté client)	l'hébergeur	Que le dépôt accepte encore une écriture : espace, droits, système de fichiers en lecture seule. Sa sonde constate l'endroit, jamais le contenu	L'hébergeur ne peut pas juger un instantané : il héberge des octets qu'il ne peut pas ouvrir
La clé de ses sauvegardes (restic)	le locataire	Juger que ses instantanés sont récents, complets et restaurables, et éprouver une restauration. La vérification suit la clé	Personne ne peut vérifier une sauvegarde à la place de qui détient la clé — et sa perte les rend définitivement illisibles
Sa voûte et ses secrets (jamais mutualisée)	le locataire	Garder sa clé hors de l'infrastructure qu'elle ouvre, en double, et faire tourner ses secrets	L'hébergeur ne peut pas recouvrer une clé de voûte perdue : il n'en a aucune copie, par construction
Le courriel (relais à la bordure)	partagé	L'enveloppe transite chez l'hébergeur, qui en répond ; le contenu appartient au locataire, qui en répond	L'hébergeur ne lit pas le contenu ; le locataire ne tient pas la réputation de la bordure
La forge du génome (D-81)	l'hébergeur	Tenir l'autorité du génome disponible : c'est de là qu'un écosystème se reproduit	Le locataire ne dépend pas d'elle pour vivre — seulement pour se reconstruire ; il peut en garder son propre miroir
L'accès de secours par sudo (D-40)	l'hébergeur, tant qu'il exploite	Le dire plutôt que de le taire : exploiter une machine, c'est pouvoir tout y lire. C'est la raison d'être du second temps de la remise, et de sa date	Le locataire ne peut pas le supprimer sans reprendre lui-même l'exploitation — d'où une échéance écrite, pas une confiance indéfinie
La remise des clés (make remise-*, garde P80)	l'hébergeur remet, le locataire reçoit	Remettre en deux temps : l'identité le jour de la livraison, la machine à l'échéance — sa clé entre, la nôtre sort, la voûte est re-clétée	Un accès qu'on oublie de rendre ne devient pas légitime en vieillissant : la garde signale tout retard
Nommer le responsable désigné (D-18, remise.yml)	le locataire	Nommer la personne qui engage l'organisation, et la maintenir à jour	L'hébergeur ne peut pas la désigner : ce serait choisir qui a le droit de le quitter
Décider de partir (migration, émancipation)	le locataire	Mandater, et emporter ce qui est à lui : son plan, ses données, sa voûte, ses domaines	L'hébergeur ne peut ni retenir ni décider à sa place ; la machine instruit, l'humain décide
Libérer un partant (migration-tenant.md §6)	l'hébergeur	Révoquer, pas transmettre : ses accès tombent, puis rétention convenue, puis purge	Le locataire ne peut pas vérifier lui-même la purge ; elle est un engagement daté, pas une mesure

4. Ce que personne ne peut déléguer

Trois choses ne se confient à aucune des deux parties, parce que les confier les annule :

• La phrase de passe d'un paquet de remise ne voyage jamais avec le support qu'elle ouvre. Séparés, ils ne valent rien l'un sans l'autre ; ensemble, ils valent l'écosystème.
• La seconde copie d'une clé, dans un autre lieu physique. Un support unique dans un tiroir unique n'est pas une sauvegarde, c'est le même risque déplacé de quelques mètres.
• La comparaison d'une empreinte avant d'installer une autorité de certification. Installer une AC, c'est lui donner le droit de signer n'importe quel nom : la comparaison est ce qui distingue sa racine d'une racine interceptée.

5. Ce qui n'est pas tranché — et qui reste donc à convenir

Nommer un point ouvert vaut mieux qu'une ligne rassurante sans mécanisme derrière.

• Le recouvrement de la clé du responsable désigné. Elle se perd, se compromet, ou la personne quitte l'organisation. Sans procédure, un locataire devient inmigrable : captif non par contrat mais par accident. Piste retenue : un contact de secours nommé en même temps que le responsable, tant que personne n'est en situation d'urgence.
• Comment on change de responsable désigné — acte au moins aussi sensible que la migration, puisqu'il décide qui pourra la mandater ensuite.
• La durée de rétention avant purge chez un hébergeur sortant : elle se convient, elle ne se dérive pas.
• La preuve que l'hébergeur ne peut plus entrer. Le plan déclare la révocation et le déploiement l'applique ; le vérifier depuis l'extérieur demande d'essayer d'entrer, donc une machine vivante (make emancipation-prouver).

6. Comment chaque ligne se vérifie

Aucune de ces responsabilités n'est laissée à la parole :

make prouver              le dépôt est-il cohérent avec lui-même (91 preuves, zéro réseau)
make remise-verifier      le second temps de la remise est-il fait, ou en retard ? (P80)
make certificats-plan     ce que le disque porte contre ce que la mémoire sert
make expositions-plan     chaque service publié répond-il, et depuis où
make identite-plan        royaume, fédération, politique de mot de passe, comptes
make emancipation-prouver un lien d'hébergement est-il réellement coupé

make deployer répare, les devis constatent : les confondre fait perdre l'information au moment où elle sert.

---

Le partage décrit ici n'est pas une politique commerciale : c'est la forme du système. Chaque fois qu'il a été possible de donner un pouvoir au locataire, il lui a été donné — et chaque fois que l'hébergeur a conservé un pouvoir, c'est parce que quelqu'un doit porter la fabric, et cela s'écrit ici plutôt que de se découvrir le jour d'un incident.