Aller au contenu principal
Infogérance serveur

Le périmètre d'une infogérance : ce qui est inclus, ce qui ne l'est pas, et comment le lire au contrat

Deux contrats peuvent porter le même nom et ne pas couvrir le même travail. Le périmètre d'une infogérance ne se lit pas dans l'intitulé mais dans la liste des tâches, dans les exclusions écrites et dans les traces que la prestation laisse. Voici comment séparer ce qui est réellement inclus de ce qui reste, en pratique, à la charge du client.

Contrat imprimé ouvert sur une table de réunion, stylo posé en travers des pages, tasses et lunettes à côté
Le périmètre se lit dans la liste des tâches et dans les exclusions, pas dans le titre du contrat.

Le mot ne définit pas la prestation, le contrat le fait

L'infogérance n'a pas de définition légale qui fixerait son contenu. Le mot désigne un transfert : l'exploitation courante d'un système d'information passe à quelqu'un d'autre, contre une redevance. Ce que ce transfert englobe varie dans des proportions considérables. Deux documents de même intitulé peuvent couvrir l'un le seul système d'exploitation, l'autre le système, la supervision, les sauvegardes et l'astreinte.

La question utile n'est donc pas de savoir si une prestation est « une infogérance », mais quelles tâches sont nommées, par qui, à quelle fréquence, et comment on constate qu'elles ont été faites. L'ANSSI range ce risque parmi ceux de l'externalisation : sa troisième règle d'hygiène informatique prévient que les dangers viennent aussi de spécifications contractuelles déficientes ou incomplètes. Un périmètre mal écrit est un facteur d'incident reconnu.

Deux serveurs en rack dans une petite salle technique, diodes actives et câbles rangés
Le matériel, le système et l'application sont trois couches : le curseur du contrat se pose sur chacune.

Les briques qu'on retrouve presque partout

Un périmètre d'exploitation se découpe en trois couches, et le curseur peut être posé sur chacune. La couche matérielle et réseau : machine ou hyperviseur, stockage, adressage, filtrage, certificats. La couche système : système d'exploitation, services, comptes, mises à jour, journaux, sauvegardes. La couche applicative : le code du site, ses extensions et ses dépendances.

La plupart des contrats couvrent la deuxième couche et une partie de la première. Ils nomment les mises à jour de sécurité, la gestion des comptes et des droits, la vérification des sauvegardes, la supervision des services et le traitement des incidents. Ce sont les briques de l'entretien courant, celles qui maintiennent un état stable sans intervention du client.

Une brique n'existe dans le périmètre que si elle laisse une trace. Une surveillance annoncée sans destinataire d'alerte nommé, une sauvegarde sans journal de fin d'exécution, une mise à jour sans relevé de version constatée : la prestation reste déclarative. Le contrat doit dire quel document permet de la constater et à quelle fréquence il est remis.

Ce qui reste dehors, et qu'on croit souvent inclus

Le code applicatif sort presque toujours du champ. Corriger une faille dans une extension, adapter un formulaire, réparer un enchaînement de traitements relèvent du développement, avec un autre interlocuteur et souvent un autre contrat. Un exploitant sérieux signale la faille, la documente et propose un contournement ; il ne réécrit pas le code sans commande distincte.

D'autres éléments restent dehors sans que personne ne le remarque : le contenu et les données métier, leur saisie et leur mise à jour ; les postes de travail des équipes ; le réseau fourni par un opérateur ; les projets, c'est-à-dire une migration ou une refonte. Ce sont des travaux, pas de l'exploitation. Les services externes suivent la même logique : l'ANSSI indique que les outils hébergés dans le nuage ne relèvent pas de l'infogérance.

Carnet ouvert avec des notes manuscrites près d'un ordinateur portable et d'un téléphone
Une prestation ne devient vérifiable que lorsqu'elle laisse une trace datée et nominative.

Trois formules qui déplacent la charge sans le dire

La première porte sur la construction de la liste. Un contrat à liste fermée énumère ce qui est inclus, et tout le reste est exclu par défaut. Un contrat à liste ouverte énumère les exclusions, et le reste est réputé inclus. La seconde forme protège mieux le client, à condition que les exclusions soient courtes : une clause rédigée en termes généraux suffit à vider la première.

La deuxième famille déplace le coût : « sur demande », « sur devis », « prestation optionnelle ». La tâche reste dans le périmètre technique mais sort du périmètre financier, donc facturée à l'acte au moment où le client négocie le moins, c'est-à-dire pendant l'incident. La troisième déplace l'engagement : « dans la mesure du possible », « autant que faire se peut ». Ces mots décrivent une intention, pas un délai.

Il existe une quatrième manière, plus discrète : conditionner la tâche à une action du client. Une mise à jour « après validation du client », une sauvegarde « des données fournies par le client », une supervision « des seuls services déclarés » transfèrent la tenue à jour à celui qui a le moins de visibilité. Cela doit alors être assumé et organisé, avec une date et un responsable de chaque côté.

Moyens, résultat, et ce que les plafonds laissent subsister

Un engagement de moyens décrit ce qui sera fait ; un engagement de résultat décrit ce qui sera obtenu. Les contrats d'exploitation mélangent souvent les deux : le rétablissement est présenté comme un engagement de délai alors que la disponibilité n'est garantie par aucun chiffre. La question à poser est simple : en cas d'écart, que peut-on opposer, et sur quelle mesure ? Les plafonds de responsabilité délimitent ensuite ce qui reste à la charge du client.

Le versant données personnelles ajoute une couche. L'article 28 du règlement général sur la protection des données impose un contrat écrit qui définit l'objet et la durée du traitement, sa nature et sa finalité, les types de données et les catégories de personnes concernées. Il énumère les obligations du sous-traitant : agir sur instruction documentée, faire respecter la confidentialité, encadrer le recours à un autre sous-traitant, aider le responsable du traitement et permettre l'audit.

Ce qui rend le périmètre vérifiable : cinq questions

Cinq questions suffisent à transformer un contrat en périmètre lisible. Qui reçoit l'alerte, sur quel canal, à partir de quelle heure ? Qui est joignable la nuit et le week-end, par quel moyen ? Quel document mensuel montre ce qui a été fait, avec quels indicateurs ? Quelle restauration a été testée, quand, avec quel compte rendu ? Que se passe-t-il le jour du départ, et sous quel délai obtient-on les données ?

Cette dernière question figure dans les exigences que l'ANSSI recommande d'imposer : réversibilité du contrat, réalisation d'audits, sauvegarde et restitution des données dans un format ouvert normalisé, maintien à niveau de la sécurité dans le temps. L'agence ajoute que ces engagements se formalisent dans un plan d'assurance sécurité. Un périmètre sans rapport ni compte rendu n'est pas vérifiable.

Reste un exercice utile avant de signer : reformuler chaque ligne en une phrase testable, avec un verbe, un objet et une trace. « Les sauvegardes sont surveillées chaque jour et le journal d'exécution est remis en fin de mois » se vérifie ; « les sauvegardes sont gérées » ne se vérifie pas. Les phrases qui résistent à cet exercice indiquent l'endroit exact où le périmètre reste une intention.