Le contrat, premier levier de cybersécurité

Les architectures numériques contemporaines reposent sur une chaîne de prestataires de plus en plus longue (cloud, infogérance, SOC, éditeurs SaaS, intégrateurs, maintenance applicative, support, etc.). En pratique, la surface d’attaque d’une organisation est donc largement « externalisée » : une faiblesse chez un sous-traitant peut devenir une compromission chez le donneur d’ordre, avec des effets systémiques (propagation, indisponibilité, exfiltration, etc.).

Un scénario courant illustre l’enjeu : un prestataire est victime d’une attaque, des accès d’administration sont compromis et des données sont exfiltrées, l’incident étant détecté tardivement. Le donneur d’ordre constate alors l’absence d’exigences de sécurité opposables, de procédure de notification contractuellement définie et de garanties d’accès aux éléments de preuve. La crise technique se transforme en crise de gouvernance, faute de mécanismes contractuels permettant de piloter rapidement la réponse à incident.

C’est précisément pour éviter ce « trou noir » de responsabilité que les textes structurants du numérique imposent une approche orientée sur le contrat : la directive NIS2, via l’article 21 (mesures de gestion des risques incluant, notamment, la gestion des incidents, la continuité et la sécurité de la chaîne d’approvisionnement) ; le règlement DORA, via l’article 30 (exigences relatives aux dispositions contractuelles avec les prestataires TIC) ou encore le RGPD, via l’article 28 (contrat encadrant la relation responsable de traitement/sous-traitant et la sous-traitance ultérieure). Le contrat n’est donc pas un simple « papier » : il devient une composante de la posture de cybersécurité de chaque organisation.

I. Le droit impose de prendre en compte la cybersécurité dans les contrats

1) NIS2 : l’approche par les risques implique la maîtrise des fournisseurs

La logique de NIS2 est simple : les entités essentielles et importantes doivent mettre en œuvre des mesures « appropriées et proportionnées » de gestion des risques. Or, cette gestion ne peut pas se limiter au périmètre interne : l’article 21 vise explicitement des capacités (gestion d’incident, continuité, hygiène cyber) et inclut la sécurité de la chaîne d’approvisionnement. Autrement dit, la conformité NIS2 ne se joue pas seulement dans la politique interne de chaque entité ; elle se joue aussi dans la capacité à exiger, vérifier et faire appliquer des exigences de sécurité chez les prestataires, y compris en cascade.

Sur le plan opérationnel, la contractualisation permet (i) de transformer une exigence de sécurité en obligation opposable, (ii) d’obtenir des preuves en cas de besoin et (iii) d’organiser des mécanismes de contrôle. Sans contrat, l’organisation est exposée à un risque classique : être juridiquement responsable de la maîtrise de son risque, tout en étant techniquement dépendante d’un tiers non contraint.

2) DORA : la résilience des services TIC passe par des clauses contractuelles structurantes

DORA consacre le contrat comme un instrument de maîtrise du risque lié aux prestataires TIC : il ne s’agit pas seulement de « gérer un fournisseur », mais de documenter et d’encadrer une dépendance opérationnelle, parfois critique. L’article 30 de DORA impose un socle de dispositions contractuelles couvrant notamment la description des services, les niveaux de service, les exigences de sécurité, la gestion des changements, l’accès aux informations, l’audit et la résilience.

En pratique, DORA tire vers le haut la maturité contractuelle : le prestataire ne peut plus se contenter d’engagements généraux (« best efforts ») ; il doit accepter un cadre de preuve, de contrôle et de remédiation. Cela pose des difficultés de négociation (refus d’audit large, limitations de responsabilité, clauses standard non négociables), ce qui renforce l’intérêt d’une stratégie d’industrialisation : annexes sécurité, matrices d’écarts, clauses alternatives et segmentation des prestataires selon la criticité.

3) RGPD : le Data Protection Agreement (DPA) comme minimum vital

Le RGPD, via l’article 28, impose un contrat (ou acte juridique équivalent) encadrant la relation responsable de traitement/sous-traitant : instructions documentées, confidentialité, mesures de sécurité, assistance, suppression/restitution des données, audits, encadrement des sous-traitants ultérieurs. Là encore, la logique supply chain est centrale : l’organisation ne peut pas externaliser le traitement sans externaliser (et maîtriser) le risque correspondant.

Le point clé, côté cybersécurité, est que l’article 28 fixe un socle, mais laisse de la place à la négociation opérationnelle. L’intérêt du contrat est d’aller au-delà de la conformité formelle et d’obtenir des engagements réellement utiles en cas d’incident : délais de notification précis, format et contenu de notification, obligations de coopération technique, conditions d’audit, exigences de sous-traitance ultérieure et clauses de réversibilité. La crise cyber est précisément le moment où l’on mesure la qualité du DPA : si l’accès aux informations ou la coopération ne sont pas contractualisés, la gestion de crise devient incertaine.

II. Droit commun des contrats : négocier la prise en compte des risques cyber

Le droit commun fournit le cadre : liberté contractuelle, force obligatoire et exécution de bonne foi. La question n’est pas de « faire du juridique » à côté de la cybersécurité ; la question est d’allouer correctement les risques et d’éviter que des clauses standard neutralisent, en pratique, la posture cyber du donneur d’ordre. Concrètement, il convient de prioriser un noyau de clauses « structurantes » cyber, en complément des clauses « classiques » (responsabilité, force majeure, imprévision, etc,.…).

1) L’annexe cybersécurité : rendre la sécurité opposable et auditée

Une bonne pratique consiste à intégrer une annexe dédiée (« annexe cybersécurité ») au contrat principal. Cette annexe poursuit trois objectifs : (i) traduire les exigences techniques en obligations contractuelles, (ii) organiser la documentation et le contrôle, (iii) rendre la gestion d’incident opérable.

Sans annexe, les clauses de sécurité restent souvent générales. L’annexe permet de préciser certaines exigences minimales (journalisation, sauvegardes et tests de restauration, gestion des vulnérabilités, chiffrement etc.) mais aussi les exigences précises liées à la sous-traitance ultérieure.

2) Clause d’audit : le contrôle comme condition de maîtrise de la supply chain

L’audit est un point de friction fréquent, mais c’est un levier majeur de cybersécurité contractuelle. Une clause d’audit efficace doit préciser : le périmètre (organisation, mesures, sites, sous-traitants), les modalités (préavis raisonnable, confidentialité, audit sur pièces et/ou sur place), la cadence (audit périodique, audit déclenché par événement) et les suites (plan de remédiation, délais, pénalités ou résiliation en cas de manquement grave).

Deux points méritent une attention particulière : (i) l’audit « en situation de crise » (ou post-incident) afin de reconstruire la chronologie et qualifier l’exposition ; (ii) la répartition des coûts, souvent négociée, avec une règle incitative : le prestataire supporte tout ou partie des coûts si un manquement est constaté.

3) Gestion des incidents : contractualiser la vitesse, la preuve et la coopération

La clause de gestion d’incident doit traiter le « temps réel » : qui informe qui, quand, comment, avec quel niveau de détail, et quelles obligations de coopération. Elle doit, au minimum, encadrer :

Définition d’un incident de sécurité et articulation avec la violation de données en lien avec les exigences légales et réglementaires ;
Notification immédiate au donneur d’ordre (souvent sous 24h, voire « sans délai » avec un premier « rapport flash »), puis rapports itératifs ;
Contenu : périmètre, services affectés, données potentiellement concernées, mesures de confinement, hypothèses de cause, indicateurs de compromission et éléments utiles à la remédiation ;
Coopération : participation à la cellule de crise, mobilisation d’experts, conservation de la preuve (logs, images, tickets), assistance aux notifications (autorités, personnes concernées le cas échéant) ;
Remédiation : délais, priorisation, validation et conditions de reprise.

Ces éléments sont déterminants pour éviter un incident « muet » (détection tardive, informations incomplètes) qui prive le donneur d’ordre de la capacité de décision.

4) Encadrement de l’usage de l’IA : un nouveau front contractuel

L’usage d’outils d’IA (générative, agents, analyse automatique, traduction, assistance au code, etc.) par un prestataire peut introduire des risques spécifiques : exposition de données, réutilisation/entraînement, dépendance à un tiers, absence de traçabilité, incertitude sur les droits et sur le périmètre des traitements.

Il est donc pertinent d’encadrer contractuellement : (i) l’autorisation ou l’interdiction de recourir à des outils d’IA sur les données ou contenus du client ; (ii) les conditions de traitement (confidentialité, localisation, absence de réutilisation, non-entraînement si requis) ; (iii) la transparence (liste des solutions tierces, information préalable en cas de changement) ; (iv) la sécurité et la sous-traitance ultérieure ; (v) les garanties relatives aux résultats (qualité, absence d’atteinte à des droits de tiers) lorsque l’IA contribue à produire des livrables.

5) Clauses classiques à sécuriser : responsabilité, force majeure, imprévision

Enfin, les clauses « classiques » conditionnent l’effectivité du dispositif. Une limitation de responsabilité trop basse peut rendre la clause d’incident théorique ; une force majeure trop extensive peut neutraliser les obligations de sécurité ; une imprévision mal encadrée peut générer des renégociations opportunistes dès que la conformité (ou la menace) renchérit les coûts. L’objectif n’est pas de supprimer ces clauses, mais de les aligner avec la criticité du service, le risque cyber et les obligations réglementaires applicables.

Conclusion

La cybersécurité de la chaîne de sous-traitance ne peut plus reposer sur des attentes implicites ou sur des engagements généraux. NIS2, DORA ou encore le RGPD convergent vers une même exigence : la maîtrise du risque passe par la capacité à exiger, contrôler et faire appliquer des mesures de sécurité chez les prestataires, y compris en cascade. Dans ce cadre, le contrat est un outil de gouvernance à part entière.

Pour les professionnels de la cybersécurité, la démarche est pragmatique : segmenter les prestataires selon la criticité, standardiser un noyau de clauses (annexe cybersécurité, audit, gestion des incidents, encadrement de l’IA, sous-traitance ultérieure), puis traiter les clauses d’allocation du risque (responsabilité, force majeure, imprévision) de manière cohérente avec l’exposition réelle. Autrement dit, la sécurité n’est pas seulement une affaire d’outils et de contrôles : c’est aussi une affaire d’obligations opposables, de preuve et de gouvernance contractuelle.

L’auteur.

François Gorriez est avocat expert en droit de la cybersécurité. Il est le co-fondateur de l’entreprise LAWXER, une solution spécialisée dans l’analyse automatisée de contrats. Pour plus d’informations et des contenus opérationnels sur l’analyse de la conformité des contrats en matière de cybersécurité cliquez sur ce lien.

François Gorriez est notamment co-auteur de l’ouvrage publié en ce début d’année 2026 « IA, cybersécurité et data : garantir la conformité numérique ».