Article · 8 MIN

Cyberattaque : le prestataire informatique est-il toujours responsable ?

Cyberattaque : le prestataire informatique est-il toujours responsable ?

Lorsqu’une cyberattaque paralyse un système d’information, le premier réflexe consiste souvent à chercher le responsable technique : hébergeur, infogérant, éditeur, prestataire de cybersécurité ou fournisseur cloud.

Le droit français impose une analyse plus nuancée.

Une cyberattaque ne rend pas automatiquement le prestataire responsable. À l’inverse, l’intervention d’un tiers malveillant ne suffit pas à l’exonérer. Il faut revenir au contrat, aux obligations de chacun, aux mesures de sécurité effectivement mises en œuvre et au lien entre les fautes constatées et le dommage subi.

L’arrêt rendu par la cour d’appel de Reims le 28 avril 2026, RG n° 24/01502, en fournit une illustration particulièrement concrète : le prestataire avait manqué à son devoir de conseil, mais son client avait lui aussi contribué au dommage. La responsabilité a finalement été partagée à hauteur de 50 %.

1. Une cyberattaque n’efface pas les obligations contractuelles

La première question consiste à déterminer si l’attaque peut exonérer le débiteur de son obligation.

L’article 1218 du Code civil définit la force majeure comme un événement échappant au contrôle du débiteur, qui ne pouvait raisonnablement être prévu lors de la conclusion du contrat et dont les effets ne pouvaient être évités par des mesures appropriées.

Une cyberattaque peut donc, en théorie, être invoquée au titre de la force majeure.

Elle ne l’est jamais automatiquement.

Le juge doit examiner concrètement la prévisibilité de l’événement, les mesures qui auraient pu permettre d’en éviter les effets et l’obligation dont l’exécution a été empêchée.

Dans un contexte où les attaques informatiques constituent désormais un risque récurrent pour les entreprises, la seule invocation d’un piratage extérieur ne suffit donc pas à faire disparaître toute responsabilité.

L’article 1231-1 du Code civil ramène ensuite le débat sur le terrain contractuel : le débiteur peut être condamné à réparer les conséquences de l’inexécution ou du retard dans l’exécution de son obligation, sauf à démontrer notamment un cas de force majeure.

La question devient alors très factuelle : qu’est-ce que le prestataire s’était réellement engagé à faire ?

Un hébergeur, un infogérant, un éditeur de logiciel et un prestataire chargé de détecter les incidents n’assument pas les mêmes missions. Leur responsabilité doit être appréciée à partir du contrat, mais aussi du devoir de conseil attaché à leur qualité de professionnel.

2. Cour d’appel de Reims, 28 avril 2026 : le prestataire devait alerter, le client devait exprimer ses besoins

L’affaire jugée à Reims est particulièrement intéressante parce qu’elle refuse la recherche d’un responsable unique.

Une société industrielle avait confié à un prestataire informatique la refonte de son système d’information afin notamment d’intégrer un logiciel de gestion et des services permettant le travail à distance.

Aucun véritable cahier des charges n’avait été établi avant l’intervention.

Après une cyberattaque par rançongiciel, le client recherchait la responsabilité de son prestataire.

La cour relève que l’installation était conforme au devis accepté. Cela ne suffit pourtant pas à exonérer le professionnel.

Le prestataire connaissait l’absence de cahier des charges et intervenait face à un client qui ne disposait pas de compétences informatiques particulières. Il lui appartenait donc de demander une expression précise des besoins, d’alerter son client sur les enjeux de cybersécurité, d’émettre des réserves, d’organiser les investigations nécessaires ou, s’il estimait ne pas disposer d’informations suffisantes, de refuser de s’engager.

En ne le faisant pas, il a manqué à son devoir de conseil.

La cour n’exonère cependant pas le client.

Celui-ci devait lui aussi mieux définir ses besoins. L’absence de cahier des charges et les informations insuffisantes transmises au prestataire avaient contribué au dommage. Le dispositif de sauvegarde n’était notamment pas clairement défini dans les documents contractuels.

Résultat : le prestataire est déclaré responsable de 50 % des dommages subis.

Il est condamné à indemniser notamment une partie de la perte d’exploitation, des coûts de remise en état du système et même du montant de la rançon payée.

Cette décision illustre une idée simple : externaliser l’informatique n’externalise pas l’intégralité du risque.

3. Le contrat compte, mais le comportement des parties compte tout autant

L’arrêt de Reims montre également pourquoi la qualité de la documentation contractuelle devient déterminante après une cyberattaque.

Le prestataire tentait notamment d’invoquer des conditions générales limitant sa responsabilité concernant la sauvegarde des données. La cour constate toutefois que ces conditions n’avaient pas été jointes au devis accepté et qu’aucune signature ne démontrait leur acceptation.

Elles ont donc été déclarées inopposables au client.

Pour une direction juridique, l’enseignement est très pratique.

Une clause de responsabilité n’a de valeur que si elle est effectivement entrée dans le champ contractuel.

Il faut également pouvoir déterminer précisément :

  • qui assure les sauvegardes ;
  • qui applique les correctifs ;
  • qui sécurise les accès distants ;
  • qui décide de l’authentification multifacteur ;
  • qui surveille les incidents ;
  • qui gère les mises à jour ;
  • qui déclenche le plan de réponse à incident ;
  • et qui doit alerter l’autre partie lorsqu’un risque est identifié.

Plus le contrat reste silencieux sur ces sujets, plus le juge devra reconstruire après coup la répartition des rôles.

4. Le RGPD confirme l’idée d’une responsabilité qui ne disparaît pas avec l’externalisation

Lorsque la cyberattaque concerne des données personnelles, une deuxième couche juridique apparaît.

L’article 32 du RGPD impose au responsable du traitement et au sous-traitant de mettre en œuvre des mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque.

Le texte vise notamment la confidentialité, l’intégrité, la disponibilité et la résilience des systèmes, la capacité de restaurer les données après un incident et l’évaluation régulière de l’efficacité des mesures de sécurité.

Pour l’entreprise cliente, cela signifie qu’externaliser son infrastructure ne suffit pas à transférer son obligation de sécurité.

Le responsable du traitement doit sélectionner des prestataires adaptés, organiser contractuellement leurs responsabilités et vérifier que le niveau de sécurité reste cohérent avec les risques du traitement.

Le prestataire, lorsqu’il agit lui-même en qualité de sous-traitant au sens du RGPD, supporte également ses propres obligations.

La logique rejoint donc celle de la responsabilité contractuelle : la cybersécurité repose rarement sur un acteur unique.

5. Après l’attaque, la preuve devient centrale

Lorsqu’un incident survient, le contentieux ne se résume pas aux logs techniques.

Le juge cherchera à reconstruire toute la chaîne de décision.

Qui connaissait la vulnérabilité ?

Qui devait appliquer le correctif ?

Une alerte avait-elle été envoyée ?

Le client l’avait-il suivie ?

Des réserves avaient-elles été formulées ?

Le cahier des charges définissait-il les sauvegardes ?

Le prestataire avait-il signalé qu’une mesure supplémentaire était nécessaire ?

Les comptes rendus, tickets, e-mails, audits, rapports d’incident et alertes écrites deviennent alors essentiels.

Pour le prestataire comme pour le client, ce qui n’a pas été documenté sera beaucoup plus difficile à démontrer après l’incident.

6. Cyberassurance : attention au délai de 72 heures

Un dernier réflexe doit être anticipé.

L’article L.12-10-1 du Code des assurances prévoit que, pour les personnes morales et les professionnels concernés, le versement d’une indemnisation au titre d’une garantie couvrant certaines atteintes à un système de traitement automatisé de données est subordonné au dépôt d’une plainte dans les 72 heures suivant la connaissance de l’atteinte.

Ce délai ne doit pas être confondu avec le délai de notification prévu par le RGPD en cas de violation de données personnelles.

Les deux mécanismes répondent à des logiques différentes.

Une procédure interne de réponse à incident doit donc intégrer simultanément les obligations réglementaires, contractuelles et assurantielles.

Ce qu’il faut retenir

La cyberattaque ne désigne jamais automatiquement son responsable.

Le prestataire pourra être mis en cause s’il a mal exécuté sa mission, négligé une vulnérabilité relevant de son périmètre ou manqué à son devoir de conseil.

Le client pourra également voir sa responsabilité retenue s’il n’a pas défini ses besoins, n’a pas appliqué les recommandations reçues ou n’a pas assuré les mesures de sécurité qui lui incombaient.

L’arrêt de la cour d’appel de Reims du 28 avril 2026 résume parfaitement cette logique : la responsabilité cyber se reconstruit à partir de la répartition réelle des obligations, pas à partir de l’étiquette apposée sur les acteurs.

Le meilleur moment pour déterminer qui devait sécuriser quoi n’est donc pas après l’attaque.

C’est au moment de rédiger le contrat.

Le prestataire informatique est-il automatiquement responsable après une cyberattaque ?

Non. Sa responsabilité dépend notamment de ses obligations contractuelles, de ses éventuels manquements, du devoir de conseil applicable et du lien de causalité avec le dommage.

Une cyberattaque peut-elle constituer un cas de force majeure ?

Potentiellement, mais les conditions de l’article 1218 du Code civil doivent être démontrées concrètement. L’intervention d’un pirate informatique ne suffit pas, à elle seule, à caractériser la force majeure.

Le client peut-il être partiellement responsable ?

Oui. L’arrêt de la cour d’appel de Reims du 28 avril 2026 en fournit un exemple : l’absence de cahier des charges et l’insuffisance des informations transmises par le client ont contribué au dommage, conduisant à un partage de responsabilité à 50 %.

Externaliser son informatique permet-il de transférer l’obligation de sécurité RGPD ?

Non. L’article 32 du RGPD impose des mesures de sécurité appropriées au responsable du traitement comme au sous-traitant, selon leurs rôles respectifs.

Quel délai respecter en matière de cyberassurance ?

L’article L.12-10-1 du Code des assurances impose, dans son champ d’application, un dépôt de plainte dans les 72 heures suivant la connaissance de l’atteinte pour bénéficier de l’indemnisation prévue par la garantie.