Quand on loue un VPS ou un serveur dédié, l’hébergeur livre une machine avec un système fraîchement installé et un accès root. C’est tout. Ce qui se passe ensuite, personne ne s’en occupe.
C’est le malentendu le plus fréquent que je rencontre : beaucoup pensent qu’en payant un serveur plus cher, ils achètent aussi la tranquillité. Ce n’est pas le cas. J’en parlais déjà dans mon article sur le choix entre mutualisé, VPS ou serveur dédié : le vrai critère n’est pas la machine, c’est le niveau de gestion autour.
Voici concrètement ce que recouvre l’infogérance, et ce qui arrive quand personne ne la fait.
Ce que l’hébergeur fait, et ce qu’il ne fait pas
La frontière est nette, mais rarement expliquée à la souscription.
L’hébergeur prend en charge :
- le matériel et son remplacement en cas de panne ;
- le réseau et la connectivité ;
- l’alimentation électrique et le datacenter ;
- parfois une sauvegarde de l’image disque, en option et à vérifier.
L’hébergeur ne prend pas en charge :
- les mises à jour de votre système et de vos paquets ;
- la configuration de Nginx, Apache, MySQL ou PHP ;
- le pare-feu et le durcissement des accès ;
- vos sauvegardes applicatives et leur restauration ;
- la surveillance de vos services ;
- le diagnostic quand votre site tombe alors que la machine, elle, répond.
Ce dernier point mérite d’être souligné. Si votre site est inaccessible mais que le serveur pingue, le support de l’hébergeur considère que son engagement est rempli. Techniquement, il a raison.
Ce qui se passe sur un serveur laissé sans suivi
Ce n’est jamais une panne brutale. C’est une dérive lente, et c’est précisément ce qui la rend dangereuse : rien n’alerte tant que ça tient.
Les premières semaines, tout va bien. Le serveur est neuf, à jour, peu chargé. C’est la période qui donne l’impression que l’infogérance ne sert à rien.
Au bout de quelques mois, les paquets accumulent du retard. Des failles publiées ne sont pas corrigées. Les logs grossissent sans rotation correcte. Un certificat Let’s Encrypt arrive à expiration parce que le renouvellement automatique s’est cassé sans que personne ne le voie — c’est un grand classique, et le site passe en alerte de sécurité dans tous les navigateurs du jour au lendemain.
Au bout d’un an, on est sur un système dont la version n’est plus supportée, avec des tentatives d’intrusion automatisées en continu sur SSH, un disque qui se remplit, et des sauvegardes dont personne n’a jamais vérifié qu’elles étaient restaurables.
Le point commun de ces situations : aucune ne nécessitait de compétence rare pour être évitée. Elles nécessitaient juste que quelqu’un regarde.
Ce que couvre l’infogérance, poste par poste
Les mises à jour système
Appliquer les correctifs de sécurité sans casser la production. Cela suppose de distinguer ce qui peut passer en automatique (les patches de sécurité isolés) de ce qui demande une intervention contrôlée : une montée de version de PHP, une migration de distribution, un changement majeur de base de données.
L’automatisation totale des mises à jour est une fausse bonne idée. Un apt upgrade non surveillé sur un serveur de production peut redémarrer un service au mauvais moment ou introduire une incompatibilité avec votre applicatif.
La sécurisation
Le minimum sérieux : un pare-feu correctement fermé, SSH par clé avec l’authentification par mot de passe désactivée, Fail2Ban actif sur les services exposés, les services inutiles arrêtés, les droits fichiers cohérents.
Ce n’est pas de la haute technicité. C’est une checklist qu’il faut poser une fois proprement, puis maintenir dans le temps — parce qu’une installation ultérieure peut rouvrir ce qu’on avait fermé.
À noter que la sécurité serveur ne remplace pas la sécurité applicative : un WordPress avec des extensions obsolètes reste vulnérable même sur un serveur impeccable. Les deux sujets se traitent en parallèle, j’en parle dans mon guide sécurité WordPress.
Les sauvegardes
Une sauvegarde n’existe vraiment que si trois conditions sont réunies : elle est automatique, elle est externalisée sur une autre machine, et elle a été testée en restauration.
Le troisième point est celui qu’on saute presque toujours. Une sauvegarde qui tourne depuis huit mois sans qu’on ait jamais tenté de la restaurer est une hypothèse, pas une garantie. J’ai vu des dumps SQL de quelques kilo-octets s’empiler pendant des mois parce que la commande échouait silencieusement.
Et une sauvegarde stockée sur le serveur lui-même ne protège de rien : si la machine est compromise ou perdue, la sauvegarde part avec.
Le monitoring
Surveiller le disque, la mémoire, la charge, et surtout la disponibilité réelle des services. L’intérêt n’est pas de collecter des jolis graphiques, mais d’être prévenu avant le client.
Un disque plein est l’incident le plus banal et l’un des plus paralysants : la base de données s’arrête d’écrire, le site tombe, et sans supervision on le découvre par un appel. Avec une alerte à 80 % de remplissage, c’est une intervention de dix minutes un mardi après-midi.
La documentation et la réversibilité
Savoir où sont les choses : quelle stack, quels vhosts, quels cron, quels accès, quelles dépendances. C’est ce qui permet à un incident d’être traité vite, et c’est aussi ce qui vous garantit de pouvoir reprendre la main ou changer de prestataire sans être bloqué.
Un serveur que personne ne peut reprendre est un risque en soi, même quand il tourne bien.
À partir de quand ça devient nécessaire
L’infogérance n’est pas justifiée partout. Quelques repères concrets.
Ce n’est probablement pas nécessaire si :
- vous êtes en mutualisé, où l’hébergeur assure déjà la couche système ;
- vous administrez vous-même et vous le faites réellement, avec le temps que ça demande ;
- le site n’a aucun enjeu direct et une interruption de plusieurs jours serait sans conséquence.
Ça devient nécessaire quand :
- le site génère du chiffre d’affaires, ou des demandes commerciales ;
- vous êtes sur un VPS ou un dédié sans personne pour l’administrer au quotidien ;
- la personne qui s’en occupait est partie, ou n’a plus le temps ;
- vous ne savez pas répondre à « quand a eu lieu la dernière restauration testée ? » ;
- vous hébergez des données clients, avec ce que ça implique côté RGPD.
Ce dernier point est souvent sous-estimé. Héberger des données personnelles engage votre responsabilité sur les mesures de sécurité mises en place, indépendamment de qui gère la machine.
Le vrai calcul
La question n’est pas « combien coûte l’infogérance », mais « combien coûte l’incident que je n’ai pas anticipé ».
Une boutique en ligne arrêtée trois jours, c’est trois jours de commandes perdues, plus le référencement qui encaisse, plus le temps de remise en route en urgence — qui est toujours plus cher qu’une intervention planifiée. Une base de données perdue sans sauvegarde restaurable, c’est parfois l’activité elle-même.
Face à ça, l’infogérance est une dépense modeste et surtout prévisible. Elle ne rend pas le serveur invulnérable, aucun prestataire sérieux ne vous promettra ça. Elle fait deux choses : elle réduit fortement la probabilité de l’incident, et elle raccourcit nettement le temps de retour à la normale quand il arrive quand même.
En résumé
Un serveur n’est pas un produit qu’on achète une fois. C’est un environnement qui vit, qui se dégrade sans entretien, et qui finit toujours par rappeler qu’il existe — en général au mauvais moment.
L’infogérance, ce n’est pas de la surveillance théorique. C’est quelqu’un qui applique les correctifs, vérifie que les sauvegardes sont restaurables, reçoit les alertes à votre place, et sait quoi faire quand ça casse.
Si vous avez un VPS ou un dédié dont personne ne s’occupe vraiment, vous pouvez regarder mon offre d’infogérance serveur. Pour un site WordPress spécifiquement, l’entrée se fait plutôt par l’infogérance WordPress, qui couvre l’applicatif en plus du système.