L'infogérance d'un serveur, prestation par prestation
Un contrat d'infogérance ne dit pas « nous gérons votre serveur » : il énumère des tâches, des horaires et des délais. Ce site décrit ce que chaque brique recouvre réellement — supervision, mises à jour, sauvegardes, sécurité, astreinte — et ce qui reste au client quoi qu'il arrive : le code, les contenus et les décisions.
Trois mots du contrat qui décident de tout
Un contrat d'infogérance repose sur trois notions : le périmètre (quelles machines, quels logiciels, quels environnements), les horaires (heures ouvrées, astreinte, week-ends) et les délais (prise en compte, intervention, rétablissement). Sans ces trois précisions, la phrase « serveur administré » ne veut rien dire.
Le périmètre se définit par exclusion autant que par inclusion. Un serveur « infogéré » peut exclure le code applicatif, les bases de données, les certificats ou les sauvegardes applicatives. Ce qui n'est pas nommé n'est pas couvert, et c'est précisément là que se logent les désaccords au moment de l'incident.
Le troisième mot est le délai. Un engagement de prise en compte en quinze minutes n'est pas un engagement de rétablissement en quinze minutes : le premier porte sur la lecture de l'alerte, le second sur le retour du service. Les contrats sérieux distinguent les deux, et parfois un troisième — le délai de contournement.
Supervision : surveiller quoi, et qui regarde
La supervision technique vérifie qu'une machine répond, qu'un service écoute, qu'un disque ne se remplit pas. Elle ne dit rien de la qualité vécue par l'utilisateur : un site peut répondre en 200 avec une page d'erreur, une base peut accepter les connexions et refuser les écritures.
La question à poser n'est pas « supervisez-vous ? » mais « que surveillez-vous, à quelle fréquence, et qui lit les alertes ? ». Une sonde toutes les cinq minutes avec alerte par courriel non lue la nuit ne protège de rien, et une supervision sans seuil documenté produit des alertes que personne ne traite.
Le point le plus souvent oublié : la supervision de la supervision. Si la plateforme d'alerte tombe, ou si le canal d'alerte est le même que le service en panne, l'incident passe inaperçu. Un canal indépendant, testé périodiquement, fait partie de la prestation.
Mises à jour et redémarrages : la fenêtre et le retour arrière
Mettre à jour un système, un serveur web ou un interpréteur, c'est modifier un environnement qui fonctionne. La prestation doit dire quand ces mises à jour ont lieu, qui décide du moment, et ce qui se passe si la mise à jour casse le service.
Deux pratiques s'opposent : appliquer les correctifs de sécurité automatiquement, au risque de casser une compatibilité sans prévenir, ou attendre une fenêtre planifiée, au risque de laisser une faille ouverte plusieurs jours. Le contrat doit trancher, par type de correctif — critique, fonctionnel, montée de version majeure.
Le retour arrière est la clause qui manque le plus souvent. Une mise à jour sans instantané préalable ni procédure de restauration n'est pas une opération d'exploitation : c'est un pari. Demander comment on revient en arrière, et en combien de temps, en dit plus long que la liste des tâches incluses.
Sauvegardes : la seule promesse qui se vérifie
Une sauvegarde n'a de valeur que si elle se restaure. La prestation doit préciser la fréquence, la rétention, le lieu de stockage, le chiffrement et — surtout — la fréquence des tests de restauration, avec le compte rendu de ces tests.
Le piège classique est la sauvegarde dans le même environnement que la production : même machine, même baie, même compte. Elle protège d'une erreur humaine ou d'une suppression, pas d'une panne matérielle, d'une attaque par rançongiciel ou d'une coupure du site.
La cohérence compte autant que la fréquence : sauvegarder les fichiers d'une base en cours d'écriture produit une copie inutilisable. Les mécanismes prévus pour cela — arrêt contrôlé, vidage cohérent, journalisation des transactions — doivent figurer au contrat, avec la responsabilité de chacun.
Sécurité : ce qui est réellement dans le périmètre
« Sécurisé » n'est pas une prestation, c'est un objectif. Ce qui se contractualise, ce sont des actes : application des correctifs, filtrage réseau, authentification, journalisation, revue des accès, surveillance des tentatives d'intrusion.
La frontière avec le code applicatif est la plus délicate : une faille dans une extension, un composant obsolète ou un formulaire mal filtré ne relève pas de l'exploitation, mais l'exploitant est le premier à voir les symptômes. Le contrat doit dire qui corrige quoi, et qui prévient qui.
Les journaux sont le point de preuve : qui les conserve, combien de temps, et sous quelle forme. Un incident sans journaux se raconte, il ne se démontre pas — et la conservation minimale relève aussi d'obligations légales selon l'activité.
Engagements, indicateurs et sortie
Un engagement de résultat se mesure : disponibilité, délai de rétablissement, nombre d'incidents, délai de réponse aux demandes. Un engagement de moyens ne se mesure pas, et c'est souvent le signe qu'il ne faut pas le signer tel quel.
Le rapport mensuel est l'outil qui rend la prestation vérifiable : incidents, causes, durées, actions, et mesures correctives. Un prestataire qui n'en produit pas laisse le client dans l'incapacité de savoir si le contrat est tenu.
Enfin la sortie : comment récupérer les données, les journaux, la documentation et les accès, dans quel format et dans quel délai. Une infogérance sans clause de réversibilité n'est pas une délégation, c'est une dépendance — et elle se paie au moment du départ, jamais avant.
Questions fréquentes
Que reste-t-il au client dans une infogérance complète ?
Le code applicatif, les contenus, les décisions d'évolution et la responsabilité de ce que le site publie. L'exploitant maintient la machine et les services, il ne décide pas du produit.
Un délai de prise en compte est-il un délai de rétablissement ?
Non. Le premier porte sur la lecture et la qualification de l'alerte, le second sur le retour du service. Les contrats sérieux distinguent les deux, et parfois un délai intermédiaire de contournement.
À quelle fréquence faut-il tester les sauvegardes ?
Assez souvent pour que le test soit une habitude et non un événement : au minimum une restauration complète par an, et des restaurations partielles plus fréquentes, avec un compte rendu écrit.
L'infogérance couvre-t-elle une faille dans l'application ?
En général non : elle couvre l'exploitation, pas le développement. Le contrat doit préciser qui détecte, qui corrige et qui prévient, sinon l'incident se traite par messages plutôt que par procédure.
Que doit contenir la clause de sortie ?
La restitution des données et des journaux, la remise de la documentation et des procédures, la transmission des accès, un format exploitable, un délai et un état de la machine à la date de fin.