Infogérance de serveur : les incidents, l'astreinte et ce qui se passe la nuit
Un serveur dédié ne tombe pas par surprise : il sature, il fuit, il expire, il ralentit. La question n'est pas de savoir si cela arrivera, mais qui le voit, à quelle heure, et ce qu'il fait. Ce site décrit les incidents réels, ce qu'une supervision détecte ou manque, et ce qu'un contrat d'astreinte engage concrètement.
Les cinq incidents qui arrivent vraiment
Le disque plein vient en tête, et il ne prévient pas : journaux applicatifs, sauvegardes locales oubliées, fichiers temporaires, images non compressées. Un serveur dont la partition système atteint cent pour cent cesse d'écrire, la base refuse les insertions et le site tombe — parfois sans erreur explicite, parce que le superviseur lui-même ne peut plus écrire son journal.
La fuite mémoire vient ensuite : un processus PHP ou une file de messages qui grossit lentement, jusqu'au déclenchement du tueur de processus du noyau. Le symptôme est un service qui redémarre seul une fois par semaine, ce que personne ne remarque avant que la fréquence ne devienne quotidienne.
Le certificat expiré est le plus évitable : automatisé correctement, il ne devrait jamais arriver. Il arrive quand le renouvellement dépend d'un challenge HTTP qu'une redirection bloque, ou quand une limite de requêtes chez l'autorité de certification a été atteinte sans que l'alerte ait été lue. Les deux autres cas classiques : la base qui ralentit sur une requête non indexée, et la saturation de bande passante lors d'un pic.
Ce que la supervision voit, et ce qu'elle manque
Une supervision par sonde répond à une seule question : le service répond-il, et en combien de temps ? Elle détecte la panne franche, pas la dégradation. Un serveur qui répond en huit secondes au lieu de deux cents millisecondes est « disponible » pour la sonde et inutilisable pour le visiteur.
Les métriques système complètent : charge, mémoire, espace disque, entrées-sorties, connexions à la base, files d'attente. Le seuil importe plus que la métrique : alerter à quatre-vingt-dix pour cent d'occupation disque laisse le temps d'agir, alerter à quatre-vingt-dix-huit pour cent ne laisse plus que quelques heures.
Ce qui échappe à toute supervision standard : la lenteur d'une seule fonction métier, l'erreur qui ne touche qu'un formulaire, le courriel qui n'arrive plus. Ces pannes silencieuses se détectent par des tests fonctionnels — un parcours de commande complet, un envoi de formulaire réel, une fois par heure.
Astreinte : ce qui est couvert la nuit
Un contrat d'infogérance sans astreinte s'arrête à l'heure de fermeture : l'incident de trois heures du matin est traité le lendemain matin. C'est un choix défendable pour un site vitrine, pas pour une boutique qui encaisse ou un service utilisé en journée par des professionnels.
L'astreinte se définit par trois éléments : la plage couverte (soirs, week-ends, jours fériés), le délai de prise en charge — distinct du délai de résolution — et le canal de déclenchement. Un numéro de téléphone qui sonne dans le vide n'est pas une astreinte ; une boîte de courriel relevée le matin non plus.
La question à poser avant de signer : combien d'incidents ont été traités la nuit le trimestre dernier, et en combien de temps ? Un prestataire qui ne sait pas répondre n'a probablement pas de mesure, donc pas d'astreinte réelle.
Mises à jour critiques et retour arrière
Les correctifs de sécurité se distinguent des montées de version fonctionnelles. Les premiers s'appliquent vite, sous quarante-huit heures en général, parce que la faille est publique dès la publication du correctif. Les secondes se planifient, se testent et se documentent.
La règle qui évite les catastrophes est simple : aucune mise à jour sans sauvegarde vérifiée et sans procédure de retour arrière écrite. Une montée de version qui casse une extension se répare en dix minutes si l'on peut revenir à l'état antérieur, en une nuit sinon.
La fenêtre d'intervention compte autant que la mise à jour elle-même : appliquer un correctif à midi un jour de forte activité, sans prévenir, est un choix d'exploitation qui se paie. Une fenêtre annoncée, même courte, vaut mieux qu'une disponibilité théorique continue.
Un incident se raconte : chronologie et prévention
Un incident traité sans trace écrite se reproduira. Le compte rendu utile tient en une page : ce qui a été constaté et à quelle heure, ce qui a été fait, ce qui a fonctionné ou non, la cause racine, et la mesure prise pour que cela ne recommence pas.
La distinction entre cause déclenchante et cause racine évite les corrections cosmétiques : redémarrer le service traite le symptôme, augmenter la limite de mémoire traite le symptôme, corriger la fuite traite la cause. Le rapport doit dire laquelle des trois a été choisie.
Ces comptes rendus, accumulés, forment la seule base sérieuse pour décider d'un investissement : ajouter de la mémoire, changer de disque, revoir une architecture. Sans historique, chaque incident se traite comme une surprise.
Ce que l'infogérance ne fait pas
L'infogérance couvre le système et les services : système d'exploitation, serveur web, base de données, certificats, sauvegardes, supervision, pare-feu. Elle ne corrige pas le code de l'application, ne rédige pas le contenu et ne décide pas des évolutions métier.
La frontière se situe à l'erreur applicative : un correctif de sécurité dans le noyau est du ressort de l'infogérance ; une faille dans une extension développée sur mesure relève de l'équipe qui l'a écrite. Un contrat qui promet les deux sans le dire est un contrat flou, et le flou se paie au premier incident.
Enfin, l'infogérance ne remplace pas la décision : elle alerte, propose, documente et exécute sur accord. Un prestataire qui redémarre un serveur de production sans prévenir, ou qui attend un accord écrit pendant qu'un service est en panne, rate les deux côté du même problème — et c'est précisément ce que le contrat doit trancher.
En images
Questions fréquentes
Quelle différence entre infogérance et hébergement ?
L'hébergement fournit la machine et le réseau ; l'infogérance exploite le système et les services — mises à jour, sauvegardes, supervision, incidents. Un serveur dédié non infogéré reste sous votre responsabilité.
L'astreinte de nuit est-elle incluse ?
Rarement. Elle se définit par la plage couverte, le délai de prise en charge et le canal de déclenchement. À vérifier noir sur blanc, avec le nombre d'incidents traités la nuit sur le trimestre écoulé.
Qui corrige une faille dans mon application ?
Le code applicatif relève de l'équipe qui l'a écrit. L'infogérance couvre le système, le serveur web, la base, les certificats et les sauvegardes — pas le code métier.
À quelle fréquence les correctifs de sécurité sont-ils appliqués ?
Sous quarante-huit heures pour les correctifs critiques, dans une fenêtre annoncée. Aucune mise à jour sans sauvegarde vérifiée ni procédure de retour arrière écrite.
Comment savoir si mon serveur est réellement surveillé ?
Demandez les alertes configurées, leurs seuils, et le dernier rapport d'incident. Une supervision sans seuil documenté et sans historique d'incidents n'est pas une supervision, c'est une sonde.