Un serveur dédié infogéré : juger la méthode, pas la fiche technique
Un serveur dédié se loue en quelques minutes ; ce qui se paie ensuite, c'est la tenue dans la durée. Entre un serveur nu et une prestation d'infogérance, la différence ne tient ni au processeur ni au nombre de cœurs, mais à trois choses vérifiables : les mises à jour sont-elles appliquées, les sauvegardes sont-elles restaurées, et qui répond quand quelque chose tombe.
Ce qu'on confie vraiment quand on confie un serveur
Un serveur dédié est une machine physique dont vous êtes seul locataire : le processeur, la mémoire et les disques ne sont pas partagés avec d'autres clients. Ce que vous en faites — système d'exploitation, services exposés, comptes, données — reste sous votre responsabilité, sauf clause contraire écrit au contrat. C'est précisément cet espace que l'infogérance vient occuper.
Déléguer l'exploitation ne veut pas dire déléguer la décision. Un prestataire sérieux applique des correctifs de sécurité, surveille les services, sauvegarde et restaure, mais il ne choisit pas à votre place ce que le serveur doit faire ni quelles données il contient. La répartition doit donc être écrite : ce qui est pris en charge, ce qui reste à votre charge, et comment un changement est validé.
Le repère utile est le contrat de sous-traitance du règlement européen sur la protection des données : dès qu'un prestataire traite des données personnelles pour votre compte, il doit agir sur instruction documentée, présenter des garanties et notifier les violations. Un prestataire qui ne sait pas dire s'il est sous-traitant sur votre installation n'a pas encore réglé la question du périmètre.
Les mises à jour : correctives d'abord, fonctionnelles ensuite
Une mise à jour de sécurité corrige une faille connue ; elle n'ajoute aucune fonction et ne justifie donc aucun report. Les éditeurs de distributions publient ces correctifs en continu, et le CERT-FR relaie les vulnérabilités qui touchent les logiciels les plus répandus. L'infogérance commence par là : appliquer ces correctifs dans un délai annoncé, pas au moment où l'on y pense.
Les montées de version — changer de branche majeure d'un système ou d'un serveur web — obéissent à une autre logique : elles modifient le comportement des services et demandent une fenêtre, une sauvegarde préalable et un test. Les mélanger aux correctifs est l'erreur la plus courante, parce qu'elle transforme une opération de routine en prise de risque non planifiée.
Ce qu'il faut demander n'est pas « faites-vous les mises à jour » mais « sous quel délai, avec quelle trace, et que se passe-t-il si une mise à jour casse un service ». Un prestataire qui répond par une date et un journal d'intervention est vérifiable ; celui qui répond par une promesse ne l'est pas.
Une sauvegarde ne vaut que par sa restauration
Une sauvegarde non testée est une hypothèse, pas une protection. La question n'est pas de savoir si les fichiers partent chaque nuit vers un autre disque, mais si l'on sait, en combien de temps et avec quelle perte, remettre le service en état. Cette réponse s'obtient en restaurant réellement, sur une machine de test, à intervalle régulier.
La règle dite du 3-2-1 reste un bon garde-fou : trois copies, sur deux supports différents, dont une hors du site principal. Sur un serveur dédié, cela se traduit par une copie locale rapide, une copie vers un autre serveur ou un stockage objet, et une copie hors du réseau du prestataire — celle qui sert le jour où le compte du fournisseur est lui-même indisponible.
La fréquence et la profondeur de conservation se déduisent de l'usage, pas d'un réglage par défaut : un site de contenu et une application de facturation n'ont ni la même fréquence de changement ni la même tolérance à la perte. Un plan de sauvegarde qui ne mentionne pas de durée de restauration mesurée n'a pas été relu depuis longtemps.
Surveiller peu, mais surveiller longtemps
Un serveur correctement surveillé n'affiche pas des centaines de courbes : il en affiche quelques-unes, choisies pour ce qu'elles annoncent. Espace disque qui se remplit, mémoire qui dérive, certificat qui approche de l'expiration, service qui ne répond plus depuis l'extérieur, sauvegarde qui n'a pas tourné : chacune de ces mesures déclenche une action précise.
Le reste — charge processeur, latence moyenne, nombre de connexions — ne devient utile qu'au moment d'un diagnostic. Les remonter en permanence produit du bruit, et le bruit finit par être ignoré, ce qui revient à ne pas surveiller du tout. La discipline consiste à distinguer les alertes qui réveillent quelqu'un de celles qu'on consulte le lendemain.
La supervision doit aussi être extérieure au serveur surveillé : une machine qui constate elle-même sa propre panne ne l'annonce pas. Un contrôle qui interroge le site depuis un autre réseau, avec une alerte par un canal indépendant, est la seule mesure qui vaut pour la disponibilité perçue par les visiteurs.
Les accès : un compte, une clé, un journal
L'accès administrateur est la porte d'entrée la plus fréquentée d'un serveur, et donc la première à fermer. Cela passe par des comptes nominatifs plutôt qu'un compte partagé, une authentification par clé plutôt que par mot de passe, et la désactivation pure et simple de la connexion du superutilisateur à distance lorsque l'usage le permet.
Chaque connexion doit laisser une trace exploitable : qui s'est connecté, quand, depuis quelle adresse, et ce qui a été fait. Les journaux d'authentification et ceux du pare-feu local racontent l'essentiel d'un incident. Encore faut-il qu'ils soient conservés assez longtemps et à l'abri d'un effacement par l'attaquant lui-même.
Cette hygiène se relâche vite : un accès ouvert « pour un test », un compte ancien jamais supprimé, une clé conservée par un prestataire qui n'intervient plus. Une revue datée des comptes et des clés autorisées, deux ou trois fois par an, est plus efficace qu'un audit complet une fois tous les cinq ans.
Le contrat : périmètre, délais, exclusions
Un engagement de disponibilité n'a de sens qu'accompagné de trois précisions : ce qui est mesuré (le service rendu ou la machine allumée), sur quelle période, et ce qui se passe en cas de manquement. Une disponibilité annoncée sans méthode de calcul ni contrepartie est un argument commercial, pas un engagement.
Les exclusions comptent autant que les promesses : maintenance planifiée, incident chez le fournisseur réseau, panne matérielle dont le délai dépend d'un datacenter tiers, intervention demandée par le client. Les lire avant de signer évite les discussions du jour où le service tombe — c'est-à-dire le jour où l'on a le moins de temps pour négocier.
Enfin, la sortie doit être prévue : comment récupérer les données, les sauvegardes et la configuration si le prestataire change, et dans quel délai. Un serveur dont on ne peut pas repartir n'est pas infogéré, il est confisqué.
En images
Questions fréquentes
Quelle différence entre un serveur dédié et un serveur virtuel infogéré ?
Le serveur dédié est une machine physique réservée à un seul client ; le serveur virtuel partage un hôte avec d'autres. L'infogérance peut porter sur les deux, mais les contraintes diffèrent : sur un dédié, le matériel et son remplacement dépendent du fournisseur, et une panne matérielle se traduit par une migration ou un échange, pas par un redémarrage.
Faut-il un engagement de disponibilité pour un serveur dédié ?
Il est utile s'il précise ce qui est mesuré, la période de calcul et la contrepartie en cas de manquement. Un taux affiché sans méthode de calcul ne permet aucun contrôle : il ne protège ni le client ni le prestataire.
Qui est responsable des données hébergées sur le serveur ?
Le client reste responsable du traitement ; le prestataire qui agit sur ses instructions est sous-traitant au sens du règlement européen sur la protection des données. Cette qualification entraîne des obligations écrites : instructions documentées, garanties, notification des violations.
Les sauvegardes sont-elles incluses dans l'infogérance ?
Cela dépend du périmètre retenu, et c'est précisément ce qu'il faut faire écrire. Une sauvegarde incluse sans restauration testée ne garantit rien : demandez la fréquence, la durée de conservation et le délai de restauration mesuré lors du dernier exercice.
Peut-on garder la main sur son serveur tout en étant infogéré ?
Oui, si les accès restent nominatifs et tracés des deux côtés. Beaucoup de clients conservent un accès administrateur pour leurs propres interventions ; l'essentiel est que chaque connexion soit identifiée et que la revue des comptes soit faite à intervalle régulier.