1. Accueil
  2. Juridique & conformité
  3. Système obsolète chez un client : le MSP peut-il être tenu responsable ?

Système obsolète chez un client : le MSP peut-il être tenu responsable ?

Guillaume Fenet
Attentif aux enjeux numériques et cyber, je décrypte les tendances technologiques et réglementaires qui transforment l’IT. Mon objectif : apporter des repères et rendre ces sujets plus clairs pour les décideurs.
8 juin 2026 • 9 min de lecture
Responsabilité des MSP

Un client conserve encore un poste, un serveur ou une machine métier sous Windows XP. Le système n’est plus maintenu par Microsoft depuis le 8 avril 2014 et ne reçoit plus de mises à jour de sécurité, mais l’environnement reste utilisé pour des raisons budgétaires, techniques ou métier.

En cas de cyber incident, qui porte la responsabilité : le client propriétaire de son système d’information ou le MSP chargé de l’infogérance ?

Le Guide du MSP a interrogé Cécile Vernudachi, Avocat Associé au sein du cabinet Anders avocats pour comprendre où se situe la ligne de responsabilité lorsqu’un client conserve un système obsolète malgré les risques connus.

Il n’existe pas de responsabilité automatique par défaut

Dans les faits, une responsabilité partagée peut émerger. Le client conserve une responsabilité générale sur la sécurité de son système d’information. Mais le MSP, en tant que professionnel de l’IT, peut voir sa responsabilité engagée s’il n’a pas alerté, conseillé ou documenté les risques connus.

« Le droit français ne pose pas de responsabilité unilatérale par défaut. Il faut d’abord regarder ce qui est écrit dans le contrat, puis analyser le contexte et la qualité des parties. A priori, il peut y avoir une responsabilité partagée entre le client et son prestataire, selon les missions confiées et les obligations effectivement prévues. », Cécile Vernudachi

Le contrat devient donc le point de départ de l’analyse. Il faut vérifier ce qui a été confié au prestataire : supervision, maintenance, patch management, gestion des mises à jour, sécurité, sauvegarde, durcissement, conseil, alertes, reporting. Une mission d’infogérance ne signifie pas automatiquement que le MSP est responsable de toutes les composantes du système d’information (SI). 

À l’inverse, l’absence d’une clause précise ne suffit pas toujours à l’exonérer, surtout s’il avait connaissance d’un risque critique.

Le MSP est le “sachant” face à un client souvent peu outillé

Dans une relation d’infogérance, le MSP n’est pas un simple exécutant technique. Il est aussi le professionnel qui sait identifier les fragilités d’un environnement informatique et en expliquer les conséquences à son client.

Cette position est particulièrement importante lorsque le client est une PME ou une organisation sans équipe IT structurée. Dans ce cas, le client externalise précisément parce qu’il ne dispose pas des compétences internes pour évaluer seul les risques liés à son système d’information.

C’est là que l’obligation de conseil du MSP prend toute son importance. Lorsqu’un prestataire identifie un système obsolète, il doit alerter le client, expliquer le risque et formuler des recommandations compréhensibles.

« Plus la prestation est complexe et technique, plus l’étendue de l’obligation de conseil qui pèse sur le prestataire est importante. C’est encore plus vrai lorsque le client n’est pas outillé pour comprendre ces sujets. Si une PME externalise la maintenance et l’administration de son SI, le prestataire devient le sachant et porte une obligation d’alerte et de conseil. »,  Cécile Vernudachi.

L’alerte orale ne suffit pas : il faut formaliser

La formalisation écrite est un élément central de protection. Elle peut prendre plusieurs formes : rapport d’audit, e-mail de recommandation, compte rendu de réunion, ticket documenté, note de risque, proposition commerciale de migration ou annexe contractuelle.

« Un MSP a tout intérêt à formaliser au maximum. Lorsqu’un nouveau client arrive, l’audit initial permet déjà de formuler des recommandations et des alertes. Si vous relevez des systèmes obsolètes, non maintenus ou présentant des vulnérabilités critiques, il faut l’écrire, recommander de ne pas continuer à les utiliser et conseiller une migration ou des mesures adaptées. » Cécile Vernudachi.

Bon à savoir : Pour un MSP, cette logique doit être intégrée dans les processus d’avant-vente et d’exploitation. Un système obsolète identifié lors de l’audit initial doit apparaître dans les livrables. Un risque découvert en cours de contrat doit faire l’objet d’un écrit. Une recommandation refusée doit être suivie d’une trace.

Le refus du client doit être documenté, pas seulement constaté

De nombreux MSP rencontrent la même situation : le risque est connu, la migration est recommandée, mais le client refuse. Les raisons sont souvent le coût, l’indisponibilité d’une application métier, la dépendance à une machine industrielle, des contraintes de production ou un manque de ressources internes.

Pour autant, ce refus ne suffit pas, à lui seul, à protéger le prestataire. Il doit être documenté.

Le MSP doit pouvoir démontrer que le client avait connaissance du risque et qu’il a choisi de ne pas suivre la recommandation. Cette preuve peut prendre la forme d’un compte rendu de réunion validé, d’un e-mail de confirmation, d’un arbitrage écrit ou d’un document dans lequel le client reconnaît accepter le risque.

« Il faut démontrer que le client avait connaissance du fait qu’il y avait des risques » Cécile Vernudachi.

Bon à savoir : Dans les cas les plus sensibles, le contrat peut également prévoir une clause permettant au prestataire de mettre fin à la mission si le client refuse durablement de suivre des recommandations de sécurité essentielles. Cette option doit rester encadrée, mais elle peut devenir nécessaire lorsque la poursuite de l’exploitation expose le MSP à un risque trop important.

Quand la migration est impossible, le prestataire doit pouvoir proposer des mesures compensatoires

Tous les systèmes obsolètes ne peuvent pas être remplacés immédiatement. Dans certains environnements industriels, médicaux ou métiers, une machine ancienne peut dépendre d’un logiciel qui ne fonctionne que sous Windows XP. Une mise à jour brutale peut interrompre la production ou rendre inutilisable un équipement critique.

Dans ce cas, le MSP doit proposer une trajectoire alternative.

Segmentation réseau, isolement de la machine, durcissement des accès, limitation des flux, supervision renforcée, sauvegardes spécifiques, ces mesures ne suppriment pas totalement le risque, mais elles montrent que le prestataire a cherché à le réduire.

« Vous avez l’obligation de proposer la migration, mais si ce n’est pas possible, alors de proposer des mesures compensatoires », Cécile Vernudachi.

Bon à savoir : Dans une alerte consacrée à une vulnérabilité RDP, le CERT-FR rappelait que Windows XP et Windows Server 2003 n’étaient plus supportés par l’éditeur. Il recommandait de ne connecter aucune machine concernée à Internet ou à un réseau local, et de ne pas l’administrer par ce vecteur.

Les clauses limitatives de responsabilité sont utiles, mais pas absolues

Les contrats d’infogérance peuvent prévoir des clauses limitatives de responsabilité, notamment pour plafonner les indemnités dues en cas de dommage. Ils peuvent aussi exclure certains périmètres, par exemple les systèmes non maintenus par l’éditeur ou les environnements conservés contre recommandation du prestataire.

« Les clauses limitatives de responsabilité fonctionnent plutôt bien en relation B2B, à condition d’être correctement rédigées, visibles et équilibrées. Mais attention, sur des services de cybersécurité, si le prestataire se présente comme un professionnel du sujet et n’a pas alerté son client, le magistrat peut considérer qu’il a manqué à son obligation essentielle, voire commis une faute lourde. » Cécile Vernudachi.

Bon à savoir : une clause doit rester cohérente avec la mission vendue. L’article 1170 du Code civil prévoit qu’une clause qui prive de sa substance l’obligation principale du débiteur est réputée non écrite. Autrement dit, une clause ne doit pas vider de sa portée l’engagement principal pris par le prestataire.

Données personnelles : le risque peut s’aggraver avec le RGPD

La situation devient plus sensible lorsque le poste Windows XP donne accès à des données personnelles.

Le Règlement général sur la protection des données (RGPD) impose au responsable du traitement et au sous-traitant de mettre en place des mesures techniques et organisationnelles adaptées au risque.

L’article 32 cite notamment la confidentialité, l’intégrité, la disponibilité, la résilience des systèmes et la capacité à rétablir l’accès aux données en cas d’incident.

Bon à savoir : Dans certains secteurs, comme la santé, cette vigilance est encore plus forte. Les données de santé sont des données sensibles, et les prestataires qui hébergent, opèrent ou administrent des environnements concernés peuvent être soumis à des exigences spécifiques, notamment autour de la certification HDS (hébergeur de données de santé) selon les cas d’usage.

Ce que les MSP doivent conserver comme preuves

Pour se protéger, le MSP doit être capable de reconstituer l’historique de son conseil. Les documents utiles ne se limitent pas au contrat initial. Ils doivent couvrir tout le cycle de vie de la relation client.

Les éléments à conserver en priorité sont les suivants :

  • le contrat d’infogérance et ses annexes techniques ;
  • le périmètre exact des prestations : maintenance, mises à jour, sécurité, sauvegarde, supervision ;
  • l’audit initial et les rapports d’état du parc ;
  • les inventaires faisant apparaître les systèmes obsolètes ;
  • les alertes adressées au client ;
  • les recommandations écrites ;
  • les propositions de migration ou de remplacement ;
  • les mesures compensatoires proposées ;
  • les comptes rendus de réunion ;
  • les refus ou arbitrages du client ;
  • les validations écrites du risque résiduel ;
  • les tickets et actions réalisées ;
  • les rapports de suivi ou de revue périodique.

Cette documentation n’a pas seulement une valeur juridique. Elle améliore aussi la qualité de la relation client. Elle permet de sortir des échanges informels, de rendre visibles les risques, d’objectiver les arbitrages et de montrer la valeur du MSP au-delà de l’intervention technique.

Un sujet de maturité contractuelle autant que cyber

Pour les prestataires informatiques, la cybersécurité ne se joue plus seulement dans la stack technique. Elle se joue aussi dans les contrats, les preuves, les comptes rendus et la capacité à démontrer que le conseil a bien été donné.

Pour rester informé des enjeux juridiques, contractuels et opérationnels, suivez Le Guide du MSP : des ressources pour aider les prestataires informatiques à structurer leurs offres, sécuriser leur responsabilité et accompagner leurs clients dans des environnements de plus en plus exposés.

Sur le même sujet

Solutions citées
Ne manquez aucune opportunité du marché MSP.
Rejoignez la communauté des prestataires IT : veille stratégique, alertes nouveautés…



    Les données sont collectées par le Guide du MSP pour la gestion de votre inscription. Voir notre Politique de Confidentialité