Serveur dédié infogéré : le matériel, l'exploitation, la sortie

Trois responsabilités, trois contrats

La machine est fournie par un hébergeur, qui en garantit le matériel, le réseau et l'alimentation. L'exploitation est assurée par une équipe, qui peut être celle de l'hébergeur, un prestataire distinct, ou le client lui-même. Le contenu, enfin, relève de celui qui publie.

Ces trois niveaux peuvent être réunis chez un même acteur, mais les obligations restent distinctes : une panne de disque relève du matériel, une saturation de base relève de l'exploitation, une faille dans une extension relève du code. En cas d'incident, la première question utile est donc « quel niveau est en cause ? ».

Le contrat d'infogérance doit dire explicitement où passe la frontière. Un prestataire qui n'a pas accès à l'interface de l'hébergeur ne peut ni remplacer un disque ni agir sur le réseau ; s'il n'est pas dit qui détient ce compte, personne ne peut le faire au moment où cela compte.

Le matériel : garanties, pièces et délais réels

Un serveur dédié est une machine physique, avec des composants qui vieillissent. Les contrats d'hébergement distinguent la garantie de remplacement — le composant est changé — de la continuité de service, qui dépend de la redondance en place : RAID, alimentations doubles, réseau multiple.

Sur un serveur sans redondance, un disque en panne signifie un arrêt, quelle que soit la rapidité d'intervention. La question à poser n'est pas « en combien de temps intervenez-vous ? » mais « qu'est-ce qui continue de fonctionner si l'élément tombe ? ».

Les délais de remplacement dépendent aussi de la logistique : stock de pièces sur place ou expédition. Dans un contexte insulaire, l'écart entre les deux peut se compter en jours. Cette donnée figure rarement dans les offres, et c'est pourtant elle qui décide de la durée réelle d'une panne.

Exploitation : ce que fait l'équipe chaque jour

L'exploitation quotidienne couvre moins de gestes spectaculaires que d'actions de maintenance : surveiller les ressources, appliquer les correctifs, vérifier les sauvegardes, renouveler les certificats, contrôler les journaux, ajuster les configurations quand la charge change.

Le travail invisible est le plus important : un certificat renouvelé à temps, un disque dont la croissance est anticipée, une sauvegarde restaurée pour vérifier qu'elle fonctionne. Rien de tout cela ne se voit dans un rapport d'incident, et l'absence de ces gestes ne se remarque que le jour où ils manquent.

La frontière avec l'application doit être écrite : l'exploitant installe et maintient la pile (système, serveur web, interpréteur, base), il ne corrige pas le code du site, sauf clause explicite. Sans cette précision, chaque erreur applicative devient un débat sur le périmètre.

Réseau, adresses et attaques volumétriques

Un serveur dédié arrive avec une ou plusieurs adresses, un reverse DNS et, selon l'offre, un filtrage des attaques par déni de service. Ce filtrage protège d'une saturation de bande passante ; il ne protège pas d'une attaque applicative, qui ressemble à du trafic normal.

Le reverse DNS, souvent négligé, conditionne la délivrabilité du courriel : un serveur qui envoie des messages sans reverse cohérent est filtré par la plupart des destinataires. C'est un réglage de quelques minutes qui évite des semaines de messages en indésirable.

Le changement d'adresse IP est un autre point de fragilité : il faut modifier la zone DNS, attendre la propagation, et penser aux services qui filtrent par adresse — pare-feu applicatif, API tierces, listes blanches. Une bascule réussie se prépare avec un TTL abaissé la veille.

Sauvegardes hors machine et plan de reprise

Sur un serveur unique, la sauvegarde sur le même disque ne protège de rien. Elle doit sortir : autre machine, autre baie, autre site, avec un chiffrement et une durée de conservation définies.

Le plan de reprise répond à trois questions : combien de données peut-on perdre (la fréquence des sauvegardes), combien de temps peut-on rester arrêté (le délai de restauration), et sur quelle machine remonte-t-on si le serveur principal est détruit. Sans réponse à la troisième, les deux premières ne servent à rien.

Le test est la seule preuve : restaurer une base, relancer le site sur une machine de secours, vérifier que les certificats et les DNS suivent. Un plan non testé est une intention, et il se découvre inopérant le jour où il faudrait l'appliquer.

Fin de contrat : récupérer ce qui compte

La sortie d'un serveur dédié infogéré comporte trois objets : les données, les accès et le savoir. Les données se récupèrent dans un format exploitable ; les accès comprennent les comptes d'administration, les interfaces d'hébergement et les zones DNS ; le savoir, ce sont les procédures et la documentation accumulées.

Le piège fréquent est la zone DNS : enregistrements de messagerie, vérifications de propriété, jetons d'API. Une zone qui disparaît avec le contrat coupe le courriel et les services tiers, souvent sans lien apparent avec le serveur.

La clause utile fixe un préavis, un état de la machine à la date de fin, la remise d'une copie complète et la suppression des données résiduelles après un délai. Elle prévoit aussi la continuité pendant la transition : deux environnements en parallèle le temps de la bascule.

Les niveaux