Serveur dédié infogéré : ce que couvre réellement le contrat
Un contrat d'infogérance ne se lit pas comme une fiche produit : il se lit comme une répartition de responsabilités. Ce qui est inclus, ce qui reste une option et ce qui n'est pas couvert du tout ne figurent presque jamais au même endroit. Voici une méthode pour reconstituer le périmètre réel d'une prestation sur serveur dédié, en s'appuyant sur les textes publics qui encadrent la sous-traitance et sur la manière dont les correctifs de sécurité sont publiés.
Trois cercles à distinguer avant de comparer deux offres
Un contrat d'infogérance mélange trois objets de nature différente. La prestation incluse est décrite avec un mode opératoire et laisse une trace : un correctif appliqué, une sauvegarde vérifiée, une alerte acquittée. L'option est la même prestation, mais activée par un avenant et souvent facturée à part. L'exclusion, elle, est rarement présentée comme telle : elle apparaît en creux, dans une phrase qui réserve l'administration des applications métier au client ou à son éditeur.
Cette confusion a une cause simple : le mot infogérance n'a pas de définition normative. Il désigne un ensemble de tâches d'exploitation, dont le contenu varie d'un prestataire à l'autre, et parfois d'un contrat à l'autre chez le même prestataire. Le règlement européen sur la protection des données ne définit pas davantage la prestation : il impose seulement que le contrat encadrant un sous-traitant précise l'objet et la durée du traitement, sa nature et sa finalité, le type de données et les catégories de personnes concernées.
La méthode de lecture tient donc en une étape : surligner chaque verbe d'action du contrat, puis vérifier qu'il est suivi d'un objet précis et d'une preuve. Installer, mettre à jour, sauvegarder, restaurer, surveiller, répondre : un verbe sans objet ni trace n'est pas une prestation, c'est une intention. Deux offres qui emploient les mêmes mots peuvent ainsi couvrir des périmètres très différents, sans qu'aucune des deux ne soit de mauvaise foi.
Ce que l'article 28 du RGPD impose d'écrire noir sur blanc
Dès qu'un prestataire traite des données personnelles pour le compte de son client, il est sous-traitant au sens du règlement, et le client reste responsable du traitement. La CNIL rappelle que cette qualification entraîne des obligations qui doivent figurer dans le contrat : transparence et traçabilité, sécurité des données traitées, assistance et alerte, notamment une procédure de notification des violations. Ce socle s'applique à l'infogérance comme à n'importe quelle prestation informatique.
L'article 28 énumère ensuite le contenu attendu. Le sous-traitant ne traite que sur instruction documentée, fait signer une obligation de confidentialité aux personnes autorisées, applique les mesures de sécurité de l'article 32, encadre le recours à d'autres sous-traitants, aide le responsable à répondre aux demandes des personnes, aide à respecter les obligations de sécurité et de notification, restitue ou supprime les données au terme de la prestation, et fournit les informations nécessaires aux audits.
Deux clauses sont fréquemment absentes des contrats d'exploitation, alors qu'elles conditionnent l'usage réel du serveur. La première est l'autorisation écrite, préalable et spécifique ou générale, exigée avant de recruter un autre sous-traitant : elle détermine si le prestataire peut confier la sauvegarde ou le filtrage à un tiers sans vous prévenir. La seconde est l'obligation d'informer immédiatement le client lorsqu'une instruction lui paraît contraire au règlement.
La ligne de partage technique : matériel, système, application, données
Un serveur dédié se comprend en quatre couches. Le matériel et le réseau du datacenter relèvent du fournisseur d'infrastructure. Le système d'exploitation, le serveur web, le pare-feu local et les services d'infrastructure relèvent de l'infogérance, si le contrat le prévoit. L'application métier relève de son éditeur ou de l'intégrateur. Les données et leur finalité relèvent du client, qui reste responsable du traitement. Chaque incident se résout dans une couche, et une seule.
Cette répartition découle du règlement plus que du bon sens commercial. L'article 24 place la charge de la preuve de conformité sur le responsable du traitement, qui doit être en mesure de démontrer que le traitement respecte le règlement. Déléguer l'exploitation ne transfère donc ni la décision, ni la responsabilité de principe : le sous-traitant assiste, alerte et documente, mais il ne choisit pas ce que le serveur fait ni quelles données il contient.
La traduction contractuelle de cette ligne est la clause d'instruction. Le prestataire agit sur instruction documentée du client, ce qui suppose un canal identifié pour formuler une demande, une trace de la demande et une trace de l'exécution. Ouvrir un port, installer une application, modifier une règle de filtrage : chacune de ces opérations change le niveau de risque du serveur et devrait laisser une trace datée, des deux côtés.
Les prestations qui changent de camp selon la rédaction
La sauvegarde est le meilleur exemple de prestation ambiguë. Trois questions suffisent à lever l'ambiguïté : qui déclenche la copie, où sont conservées les copies, et qui exécute la restauration. Une sauvegarde dite incluse peut se limiter à une copie de fichiers sans procédure de restauration éprouvée. Or l'article 32 demande des moyens permettant de rétablir la disponibilité des données et l'accès à celles-ci dans des délais appropriés en cas d'incident : le contrat doit dire qui rétablit, et comment ce rétablissement est vérifié.
Les mises à jour posent une difficulté du même ordre, parce que le mot recouvre deux opérations distinctes. Le correctif de sécurité corrige une faille connue et n'ajoute aucune fonction. La montée de version modifie le comportement des services et demande une fenêtre, une sauvegarde préalable et un test. Les distributions publient leurs avis de sécurité de façon datée et continue, et le CERT-FR relaie les vulnérabilités qui touchent les logiciels répandus : un contrat qui promet des mises à jour régulières sans distinguer les deux catégories laisse la porte ouverte à l'interprétation la plus faible.
D'autres prestations basculent d'un camp à l'autre selon une phrase. Le renouvellement des certificats peut être automatisé, mais la surveillance de leur expiration reste à attribuer. Le filtrage réseau peut être inclus au niveau du serveur et exclu au niveau du datacenter. L'application métier reste généralement hors périmètre : l'infogéreur maintient l'hébergement, l'éditeur maintient le code, et personne ne maintient les deux sans que ce soit écrit. Les exclusions typiques, elles, portent sur le développement, les licences, les contenus et le référencement.
Demander des preuves plutôt que des engagements de principe
L'article 32 demande une procédure visant à tester, analyser et évaluer régulièrement l'efficacité des mesures techniques et organisationnelles. Appliqué à l'exploitation d'un serveur, cela se traduit par des artefacts consultables : un exercice de restauration documenté, un journal horodaté des interventions, un relevé des correctifs appliqués. Ce sont ces pièces qui distinguent une prestation tenue d'une prestation annoncée, et elles existent indépendamment de tout engagement de disponibilité.
Les preuves utiles ont une caractéristique commune : elles sont datées et rattachées à une référence publique quand c'est possible. Un correctif appliqué renvoie à un avis de sécurité identifié, publié par la distribution ou par le CERT-FR. Un incident renvoie à un compte rendu qui décrit la détection, l'action et le retour à l'état nominal. À l'inverse, une surveillance présentée comme permanente, sans canal d'alerte nommé ni journal d'acquittement, n'est pas vérifiable : personne ne peut dire si l'alerte a été vue.
La notification des violations illustre l'intérêt de ces précisions. Le responsable du traitement notifie l'autorité de contrôle dans les meilleurs délais et, si possible, dans les soixante-douze heures après avoir pris connaissance de la violation. Le sous-traitant, lui, doit informer le responsable dans les meilleurs délais, sans que le règlement fixe de délai chiffré à son niveau. C'est donc au contrat de fixer ce délai et le canal d'alerte, faute de quoi le client apprendra l'incident par un autre chemin.
La sortie fait partie du périmètre
Un contrat d'infogérance se juge aussi sur ce qu'il prévoit le jour où il s'arrête. L'article 28 impose au sous-traitant de supprimer les données personnelles ou de les renvoyer au responsable au terme de la prestation, et de détruire les copies existantes, sauf obligation légale de conservation. Cette clause a des conséquences très concrètes sur un serveur dédié : les sauvegardes sont-elles restituées, dans quel format, et pendant combien de temps restent-elles consultables après la fin du contrat.
La réversibilité ne s'improvise pas au moment du départ : elle se prépare pendant l'exploitation, par un inventaire daté des accès, des dépendances et des configurations. Comptes et clés autorisés, noms de domaine, certificats, règles de filtrage, tâches planifiées, sources des sauvegardes : chaque élément oublié se paie le jour de la migration. Un prestataire qui documente son installation rend la sortie possible sans négociation.
La question à poser n'est donc pas de savoir ce que le prestataire fait, mais ce qui est écrit, tracé et vérifiable. Un périmètre explicite, avec ses inclusions, ses options et ses exclusions, protège les deux parties : le client sait ce qu'il doit encore assumer, et le prestataire sait ce qu'il ne peut pas se voir reprocher. C'est moins spectaculaire qu'une promesse de disponibilité, mais c'est ce qui tient dans la durée.