Infogérance de serveurs OVH : ce qui reste à faire une fois la machine livrée
Un serveur OVH arrive avec un système, une adresse IP et un accès root — rien de plus. Les mises à jour, les sauvegardes, la supervision, les certificats et la réponse aux incidents restent à organiser. Ce site décrit les briques du fournisseur, les limites de ses sauvegardes et la répartition des rôles entre OVH, l'infogérant et le client.
Ce que l'hébergeur fournit, et ce qu'il ne fournit pas
Un serveur dédié livré chez un hébergeur d'infrastructure arrive avec une installation d'exploitation, une adresse IP, un accès administrateur et un réseau. Le matériel, l'alimentation, la bande passante et la protection anti-DDoS sont de son ressort ; le système, les services, les données et leur sauvegarde sont du ressort du client.
Cette frontière surprend souvent : un serveur qui ne démarre plus à cause d'une mise à jour ratée n'est pas un incident matériel, et l'hébergeur facturera l'intervention. À l'inverse, une panne de disque est de son ressort, avec remplacement matériel.
L'infogérance se situe exactement dans cet intervalle : elle prend en charge la couche système et services, et sert d'interlocuteur technique vis-à-vis de l'hébergeur quand l'incident touche le matériel ou le réseau.
Les briques à connaître : bare metal, cloud, réseau
Le serveur dédié (bare metal) offre la machine entière, sans virtualisation imposée : performances prévisibles, contrôle total du noyau, mais aucune redondance automatique. L'instance cloud, à l'inverse, est jetable et recréable, avec un coût horaire et une facturation à l'usage.
Le réseau privé (vRack) relie plusieurs serveurs ou instances dans un réseau isolé, sans passer par l'internet public : c'est la brique qui permet de séparer la base de données du serveur web. Les adresses IP supplémentaires, dites failover, permettent de déplacer une adresse d'une machine à l'autre sans changer le DNS.
Ces briques changent l'architecture possible : une bascule d'adresse IP est plus rapide qu'une bascule DNS, et un réseau privé évite d'exposer la base sur internet. Les ignorer conduit à des architectures coûteuses à exploiter.
Espace client, API et propriété des accès
Le compte de l'hébergeur doit appartenir au client, pas au prestataire. Un prestataire qui détient le compte principal détient la possibilité de suspendre, de déplacer ou de résilier les machines : c'est le point de dépendance le plus fort d'une relation d'infogérance.
L'idéal est un compte client avec authentification à deux facteurs, et des accès délégués pour le prestataire, révocables. L'API de l'hébergeur, quand elle est utilisée, repose sur des jetons : ils doivent être nominatifs, limités aux actions nécessaires et journalisés.
L'inventaire de ces accès fait partie de la réversibilité : à la fin du contrat, le client doit pouvoir récupérer la main sans recréer un compte ni perdre l'historique de facturation.
Sauvegardes : ce que les snapshots ne remplacent pas
Les snapshots proposés par un hébergeur capturent l'état d'un disque à un instant donné, souvent stockés dans la même infrastructure. Ils sauvent d'une erreur de manipulation, pas d'une suppression de compte, d'une compromission ou d'une panne de la zone.
Une sauvegarde exploitable est distincte : fréquence définie, rétention écrite, stockage externalisé chez un autre fournisseur ou dans une autre région, et restauration testée. Sans test, on ne dispose que d'une hypothèse de sauvegarde.
Le cas des bases de données demande un traitement à part : une copie des fichiers d'un moteur en cours d'exécution n'est pas cohérente. Il faut un export logique ou un instantané applicatif, avec la procédure de restauration associée.
Réseau, pare-feu et protection anti-DDoS
La protection anti-DDoS de l'hébergeur filtre le trafic en amont : elle absorbe les attaques volumétriques, pas les attaques applicatives. Une requête lente et légitime en apparence peut saturer une base sans déclencher aucune protection réseau.
Le pare-feu réseau de l'hébergeur filtre les ports avant d'atteindre la machine ; le pare-feu du système filtre ensuite. Les deux doivent être configurés, et leurs règles documentées : un port ouvert « pour tester » et oublié est une porte d'entrée durable.
Le reverse DNS, souvent négligé, conditionne la délivrabilité des courriels sortants : un serveur d'envoi sans enregistrement inverse cohérent finit en liste noire. Ce réglage se fait côté hébergeur, mais se vérifie côté exploitation.
Qui intervient : hébergeur, infogérant, client
Trois acteurs, trois périmètres. L'hébergeur intervient sur le matériel, le réseau, l'alimentation et la virtualisation. L'infogérant intervient sur le système, les services, les mises à jour, les sauvegardes, la supervision et les incidents applicatifs d'infrastructure. Le client décide, fournit les contenus, valide les changements et reste propriétaire des données.
La zone grise est l'application : une erreur dans le code n'est ni matérielle ni système. Le contrat d'infogérance doit dire si l'infogérant intervient en diagnostic seulement ou en correction, et à quel coût.
Un incident bien traité se reconnaît à sa chronologie : qui a été appelé, à quelle heure, ce qui a été fait, et quelle mesure évite la répétition. Sans ce compte rendu, la même panne revient sans que personne ne sache pourquoi.
Questions fréquentes
L'hébergeur gère-t-il les mises à jour du serveur ?
Non. Il fournit la machine, le réseau et l'anti-DDoS ; le système, les services, les données et leur sauvegarde restent à la charge du client ou de son infogérant.
Les snapshots suffisent-ils comme sauvegarde ?
Non. Ils protègent d'une erreur de manipulation, pas d'une suppression de compte, d'une compromission ou d'une panne de zone. Une sauvegarde exploitable est externalisée et sa restauration est testée.
À qui doit appartenir le compte chez l'hébergeur ?
Au client, avec authentification à deux facteurs et des accès délégués pour le prestataire, révocables. Un compte détenu par le prestataire est la dépendance la plus forte du contrat.
L'anti-DDoS protège-t-il de tout ?
Il absorbe les attaques volumétriques, pas les attaques applicatives : une requête lente qui sature une base ne déclenche aucune protection réseau. Le pare-feu et la limitation de débit restent nécessaires.
Qui corrige une erreur dans mon application ?
Le code applicatif relève du client ou de son développeur. Le contrat d'infogérance doit préciser si l'infogérant intervient en diagnostic seulement ou aussi en correction.