Trois responsabilités sur un serveur dédié : hébergeur, exploitant, client
Sur un serveur dédié, trois personnes répondent de la même machine, et aucune ne répond de tout. L'hébergeur fournit le matériel et le réseau, l'exploitant administre le système, le client décide de ce qui tourne dessus. Les incidents coûteux naissent presque toujours d'une ligne oubliée entre ces trois-là, rarement d'une panne technique.
Trois contrats empilés sur une seule machine
Un serveur dédié n'est pas un service unique, c'est un empilement. En bas, l'hébergeur met à disposition une machine physique dans un bâtiment alimenté, refroidi et raccordé, avec des disques, de la mémoire et une adresse réseau. Au milieu, l'exploitant installe et maintient le système, les services, les sauvegardes et les comptes. En haut, le client détient le code applicatif, les contenus, les données métier et les décisions qui vont avec. Chaque étage a son contrat, ses horaires et ses limites propres.
Le schéma devient utile le jour où quelque chose casse. Disque plein un samedi : l'hébergeur constate que la machine répond, l'exploitant constate que le service ne répond plus, le client constate que le formulaire de contact ne mène nulle part. Sans répartition écrite, chacun peut légitimement croire que le problème est chez l'autre, et le temps passé à se le dire est du temps d'indisponibilité facturé à personne.
Le matériel : la garantie n'est pas la continuité
L'hébergeur engage deux choses distinctes qu'un contrat confond souvent. La garantie couvre le remplacement d'un composant défaillant selon les conditions du constructeur : elle répare, elle ne maintient pas le service. La continuité porte sur ce qui reste disponible pendant l'attente de la pièce. Une machine dont le disque est remplacé en trois jours ouvrés n'a pas la même valeur pour son utilisateur qu'une machine où la même pièce attend dans un tiroir du bâtiment.
D'où la question à faire écrire : quels composants sont redondants, où se trouvent les pièces de rechange, et comment la machine redémarre-t-elle si le remplacement traîne. La page de manuel de mdadm le rappelle sans détour : un ensemble RAID logiciel combine plusieurs disques et certains niveaux survivent à la défaillance d'un ou plusieurs d'entre eux, ce qui ne remplace ni une sauvegarde ni une machine de secours.
L'exploitant : le système, pas l'application
L'exploitation commence là où le matériel s'arrête : installation du système, mises à jour, serveur web, moteur de base de données, supervision, sauvegardes, comptes et filtrage réseau. Elle ne couvre pas le code de l'application, ses extensions, ses contenus ni ses choix fonctionnels. Un disque saturé par des journaux applicatifs est un incident d'exploitation ; une page en erreur parce que l'application écrit mal dans sa base est un incident de développement. La frontière se lit dans les journaux, pas dans les organigrammes.
Deux mécanismes montrent où elle se situe techniquement. Le rechargement progressif d'Apache, obtenu par le signal USR1 ou l'option graceful, fait relire la configuration au processus parent puis remplacer les processus enfants après leur requête en cours : la modification passe sans couper les connexions, alors qu'un arrêt par TERM interrompt les requêtes en cours. Côté base, PostgreSQL archive ses journaux de transactions pour permettre une restauration à un instant précis, et sa documentation précise que pg_dump, copie logique, ne peut pas servir de base à ce mécanisme.
Le client : code, contenus et qualification juridique
Le client garde trois choses non délégables : ce que fait l'application, ce qu'elle publie et la responsabilité des données personnelles qu'elle traite. La CNIL le rappelle à propos de la qualification : le rôle se détermine par les faits, qui décide du pourquoi et du comment du traitement, et non par l'étiquette choisie au contrat. Une personne qui intervient sur des données hébergées à des fins de maintenance ou d'infogérance est un sous-traitant ; celui qui décide des finalités reste responsable du traitement.
Conséquence pratique : l'exploitant doit être encadré par un contrat qui fixe la répartition des obligations de confidentialité, les contraintes minimales d'authentification, la gestion et la notification des incidents, et les conditions de restitution ou de destruction des données en fin de contrat. La chaîne compte aussi : les sous-traitants de l'exploitant, souvent l'hébergeur, entrent dans le périmètre, et le responsable du traitement doit pouvoir en donner l'identité.
Les zones grises qui fabriquent les conflits
Trois questions reviennent dans presque tous les désaccords. Qui détient le compte principal chez l'hébergeur, celui qui permet de réinstaller la machine, de commander une adresse supplémentaire ou de résilier ? Qui possède le nom de domaine et la zone qui va avec ? Et qui conserve les journaux, pendant combien de temps, sous quelle forme ? Aucune de ces réponses n'est technique : ce sont des décisions de propriété et de preuve, et elles se prennent avant l'incident.
Un compte ouvert au nom de l'exploitant met le client en dépendance au moment du départ. Des journaux conservés chez l'exploitant seul rendent un incident difficile à démontrer. Une zone DNS dont le client ignore l'emplacement transforme un simple changement de prestataire en migration risquée. Ces trois points tiennent en une page au contrat ; découverts après coup, ils coûtent des semaines et parfois les données qui allaient avec.
Écrire la répartition, puis l'éprouver avant la panne
La rédaction tient en un tableau à trois colonnes, une par responsabilité, et une liste de situations concrètes : disque plein, certificat expiré, restauration demandée en urgence, tentative d'intrusion, pic de trafic, départ d'un salarié qui détenait un accès. Pour chaque ligne, une seule colonne porte le diagnostic, une autre l'action, et le client doit savoir à qui il parle. Une ligne où deux colonnes se répondent est une ligne à réécrire, pas à discuter pendant l'incident.
Le tableau ne vaut que s'il est éprouvé à froid. Restaurer une sauvegarde sur une machine qui n'est pas la production, demander le rapport du dernier incident, vérifier qui reçoit les alertes à trois heures du matin : trois exercices qui montrent en une heure ce qu'un contrat promet en dix pages. La sortie se teste de la même façon, avec la liste des données, journaux, documentation et accès à rendre, le format attendu et le délai admis.