Par Tanguy Duthion
·
13 juin 2026
Je peux résumer le sujet en une phrase : un même SaaS peut créer 3 problèmes d’un coup - données perso, arrêt de service, et écart réglementaire.
Si je devais aller droit au but, je retiendrais ceci :
Le point simple à garder en tête : DORA encadre surtout la résilience et les prestataires TIC, le RGPD encadre les données perso, et NIS2 encadre la sécurité des réseaux et systèmes.
En clair, je ne pilote pas 3 programmes séparés. Je mets en place un seul registre SaaS, un seul triage incident, et un seul suivi fournisseur, puis j’ajoute les demandes propres à chaque texte.
Comparaison rapide :
| Cadre | Ce qu’il couvre d’abord | Qui est visé | Délai incident |
|---|---|---|---|
| DORA | Résilience numérique | Entités financières | 4 h / 24 h max |
| RGPD | Données personnelles | Toute organisation qui en traite | 72 h |
| NIS2 | Sécurité des SI | Entités et fournisseurs visés par le texte | 24 h |
Mon idée centrale : pour un SaaS en production, je regarde toujours 3 questions :
C’est ce triptyque qui permet de savoir quoi journaliser, quoi tester, quoi mettre dans le contrat, et qui prévenir en cas d’incident.
Le point de départ n'est pas le même.
DORA vise les entités financières mentionnées à l'article 2(1) [1]. Dès qu'elles s'appuient sur un SaaS pour une activité réglementée, le fournisseur entre dans le périmètre ICT et devient un prestataire tiers de services TIC soumis à des clauses plus strictes. Dit simplement : le contrat SaaS n'est plus un simple document d'achat. Il devient un point de contrôle à la fois juridique et opérationnel. Et, dans certains cas, certains fournisseurs peuvent même être désignés comme prestataires critiques de services TIC (CTPP) et passer sous supervision européenne directe [3].
Le RGPD, lui, suit une autre logique. Il s'applique dès qu'il y a traitement de données à caractère personnel, peu importe le secteur. Un CRM, un outil RH, une plateforme de ticketing ou une suite collaborative utilisés en France peuvent donc déclencher les obligations RGPD : base légale, droits des personnes, contrat de sous-traitance et, si besoin, notification des violations de données à la CNIL. Le périmètre du RGPD se joue donc donnée par donnée, et pas seulement au niveau du secteur.
NIS2 cible les entités essentielles et importantes dans les secteurs listés, selon leur taille et leur criticité [4][7]. Les fournisseurs de services cloud, de centres de données ou de DNS peuvent être visés directement, y compris lorsqu'ils fournissent des services sur le territoire français sans y être établis. Dans la finance, DORA prime sur NIS2 pour les exigences déjà couvertes, notamment la gestion des incidents ICT, les tiers et la gouvernance [5][6].
En pratique, un même SaaS utilisé par une banque peut relever à la fois du RGPD, de DORA et de NIS2. Et le fournisseur lui-même peut aussi relever de NIS2. Cela veut dire, très concrètement :
C'est là que beaucoup d'organisations se heurtent au même mur : elles ont les outils, mais pas toujours la vue d'ensemble. Sans inventaire complet des SaaS, y compris le Shadow IT, il devient difficile de cartographier le périmètre, de centraliser les contrats et de suivre le risque.
Une fois ce périmètre posé, le sujet suivant est la gestion des incidents et de la continuité.
Trois cadres, trois façons de nommer un risque SaaS qui, sur le terrain, peut être le même.
Un incident ICT au sens de DORA correspond à un événement non planifié qui compromet la sécurité d’un système ou d’un service, et qui touche sa disponibilité, son authenticité, son intégrité ou sa confidentialité [13]. Côté NIS2, un incident est dit significatif s’il peut provoquer une perturbation opérationnelle grave, une perte financière importante ou un dommage notable [8][11]. Pour le RGPD, on parle de violation lorsqu’un incident de sécurité entraîne la destruction, la perte, l’altération, la divulgation ou l’accès non autorisé à des données à caractère personnel [19][20]. Et là, le point décisif est simple : le risque pour les droits et libertés des personnes [19].
Dans un contexte SaaS, la qualification ne dépend pas seulement de l’incident lui-même. Elle dépend aussi des données touchées et de l’effet concret sur l’activité. Une attaque par rançongiciel sur un SaaS utilisé par une banque peut donc entrer dans les trois cases à la fois : incident ICT majeur DORA, incident significatif NIS2, et violation RGPD si des données clients sont chiffrées ou exfiltrées [17][18][19]. À l’inverse, une erreur de configuration qui expose des fiches contact dans un CRM SaaS relève d’abord du RGPD. DORA et NIS2 n’entrent en jeu que si l’impact opérationnel dépasse leurs seuils.
Les délais de notification montrent bien cette logique à plusieurs étages. DORA impose une notification initiale dans les 4 heures après la classification de l’incident comme majeur, et au plus tard 24 heures après sa détection. Il faut ensuite transmettre un rapport intermédiaire sous 72 heures, puis un rapport final sous un mois [12][14][15]. NIS2 suit un schéma assez proche : alerte précoce sous 24 heures, notification complète sous 72 heures, puis rapport final sous un mois [8][11][16]. Le RGPD, lui, impose une notification à la CNIL dans les 72 heures après la prise de connaissance de la violation, sauf si celle-ci est peu susceptible d’engendrer un risque pour les personnes [19].
| Cadre | Type d’incident | Délai initial | Destinataire (France) |
|---|---|---|---|
| DORA | Incident ICT majeur | 4 h après classification / 24 h max | ACPR / AMF |
| NIS2 | Incident significatif | 24 h (alerte précoce) | ANSSI |
| RGPD | Violation de données à caractère personnel | 72 h | CNIL |
Mais les délais ne sont qu’une partie du sujet. La vraie ligne de fracture, c’est la continuité d’activité.
Sur ce point, DORA va le plus loin. Le texte impose des plans documentés de continuité et de reprise, des RTO/RPO définis pour les SaaS critiques, ainsi que des tests réguliers, y compris des simulations de panne chez un fournisseur [10][12][13]. Autrement dit, il ne suffit pas d’avoir un plan sur une étagère. Il faut pouvoir montrer que ce plan tient quand un prestataire tombe.
NIS2 attend aussi une préparation concrète. Les entités essentielles et importantes doivent prévoir des scénarios de défaillance de leurs prestataires SaaS, avec des procédures de contournement [9][11]. En clair : si le service s’arrête demain matin, que fait-on dans l’heure qui suit ?
Le RGPD est moins directif sur la continuité opérationnelle pure, mais il impose quand même des mesures techniques et organisationnelles appropriées pour assurer la confidentialité, l’intégrité, la disponibilité et la résilience des systèmes et services de traitement. Dans un environnement SaaS, cela passe, très concrètement, par des sauvegardes, des restaurations et un plan de continuité [19][21].
Au fond, ces cadres poussent tous vers le même réflexe de gestion : relier chaque SaaS critique à un niveau de criticité, à des RTO/RPO clairs et à un plan de reprise. Sans ce lien, il devient difficile de piloter les dépendances fournisseurs et de garder le service en état de marche quand un incident frappe.
Une fois l'incident géré, le risque se déplace souvent vers le contrat et le suivi du fournisseur. Et c'est justement sur ce terrain que les trois cadres se séparent le plus nettement.
DORA est le plus strict sur le contrat fournisseur. Le règlement demande un cadre très précis pour les prestataires TIC tiers critiques. On y retrouve notamment des niveaux de service (SLA) avec des RTO/RPO mesurables, des droits d'audit et d'inspection étendus, la localisation géographique des données, des plans de sortie testés, ainsi qu'une assistance définie en cas d'incident. L'idée est simple : rendre la dépendance à un SaaS vérifiable à tout moment, sans devoir renégocier dans l'urgence au pire moment.
Le RGPD, de son côté, impose un contrat de sous-traitance avec tout sous-traitant qui traite des données personnelles pour le compte du responsable de traitement. Ce contrat doit préciser la nature du traitement, les mesures de sécurité appliquées, les conditions de sous-traitance ultérieure et les droits d'audit. En pratique, cela vise une grande partie des SaaS qui manipulent des données personnelles.
NIS2 suit une logique fondée sur le risque. Les entités essentielles et importantes doivent évaluer la sécurité de leurs fournisseurs et exiger des garanties contractuelles proportionnées à leur niveau de criticité. Autrement dit, NIS2 impose une évaluation du risque fournisseur et des garanties ajustées à ce risque.
L'écart principal se joue sur trois leviers : l'audit, la sortie et le niveau de contrainte contractuelle.
| Dimension | DORA | NIS2 | RGPD |
|---|---|---|---|
| Détail contractuel | Élevé | Moyen (basé sur le risque) | Moyen (contrat de sous-traitance obligatoire) |
| Droits d'audit | Étendus et encadrés contractuellement | Requis pour la conformité | Prévu dans le contrat de sous-traitance |
| Plans de sortie | Obligatoires pour les services critiques | Attendus selon le risque et la criticité | Non spécifiés |
Dans la pratique, un pilotage SaaS trop léger reste l'un des points de défaillance les plus fréquents en audit. Le sujet n'est donc pas seulement de bien signer au départ. Il faut aussi tenir la distance : inventaire des outils, niveau de criticité de chaque application, clauses de sortie, suivi des fournisseurs.
Un contrôle continu du parc SaaS devient alors un prérequis opérationnel pour garder la main sur ces trois volets réglementaires.
Après la signature du contrat fournisseur, le risque SaaS se déplace vers l'usage au quotidien : les journaux, les accès et la gouvernance. Les trois cadres cherchent tous la traçabilité. Mais ils ne demandent pas le même niveau de détail, ni le même degré de formalisme. Sur un SaaS critique, ce point change tout : sans traces fiables, il devient beaucoup plus dur d'enquêter, de corriger un incident et de prouver la conformité.
DORA est le cadre le plus précis. Les RTS sur la gestion du risque ICT imposent de définir noir sur blanc les événements à journaliser, les durées de conservation, les mesures de protection des journaux et leur usage pour repérer les anomalies et appuyer les enquêtes d'incident[22][23]. Les journaux d'incidents ICT doivent être conservés au moins 5 ans[23]. Côté accès, DORA impose le principe du moindre privilège, l'authentification multifacteur (MFA) et une revue périodique documentée des droits. Les comptes à privilèges font aussi l'objet d'une surveillance renforcée[24][27].
Le RGPD, lui, ne prévoit pas une obligation de journalisation dédiée. En pratique, son principe de responsabilité et ses exigences de sécurité poussent quand même à tracer les opérations sensibles et les interventions techniques. La CNIL recommande de journaliser les créations, consultations, partages, modifications et suppressions, avec l'auteur, la date, l'heure et la référence des données. La durée conseillée va de 6 mois à 1 an, et peut aller jusqu'à 3 ans si cela se justifie[30][31].
NIS2 couvre au minimum le trafic réseau, les changements de comptes et de droits, les accès, les authentifications et les activités à privilèges[29]. ENISA recommande de relier ces journaux aux processus de gestion des identités et des accès, ou IAM, pour savoir qui attribue ou modifie les accès, quand, et sur quels périmètres[28].
Le contraste saute aux yeux sur trois sujets : ce qu'il faut tracer, combien de temps garder les journaux, et qui doit revoir les accès.
| Dimension | DORA | RGPD | NIS2 |
|---|---|---|---|
| Journalisation | Oui, formalisée par les RTS | Indirecte, via la responsabilité et la sécurité | Oui, pour les entités essentielles et importantes |
| Conservation | Au moins 5 ans pour les incidents ICT[23] | 6 mois à 1 an, jusqu'à 3 ans si justifié[30][31] | Selon l'évaluation des risques et les besoins d'enquête |
| Comptes à privilèges | Surveillance et journaux obligatoires | Accès limité au nécessaire | Journalisation et revue régulière des activités d'administration |
| MFA | Requis | Mesure de sécurité appropriée | Non imposé explicitement |
Au-delà des traces, le point sensible est simple : qui valide, qui contrôle, et à quel rythme ?
La gouvernance sert justement à relier les journaux, les accès et le suivi fournisseur dans un même dispositif de contrôle. DORA impose des responsabilités formalisées, une revue annuelle et des audits indépendants[22][32]. Le RGPD amène à associer le DPO aux décisions qui touchent aux traitements de données personnelles, en particulier sur la journalisation, la surveillance et le contrôle d'accès. NIS2, de son côté, renforce la responsabilité du conseil d'administration, qui doit approuver les politiques de sécurité et suivre leur efficacité[26].
Dans les faits, faire cela à la main devient vite intenable. L'automatisation s'impose donc pour centraliser les droits d'accès, repérer les comptes inactifs et sortir des preuves d'audit sans y passer des semaines.
Ce tableau met côte à côte les écarts clés entre DORA, le RGPD et NIS2 pour un SaaS déjà en production. Le but est simple : voir, sur un cas concret, quel texte impose quoi sur des sujets très terrain comme le contrat, l’incident, l’accès, la traçabilité ou la reprise. Et là, les différences sautent surtout aux yeux sur trois points : le niveau de contrainte, la gestion des incidents et la preuve de conformité.
| Dimension | DORA | RGPD | NIS2 |
|---|---|---|---|
| Périmètre | Entités financières de l'UE (banques, assurances, sociétés d'investissement) et leurs prestataires TIC, y compris les SaaS qui soutiennent des fonctions critiques [23][36] | Tout organisme qui traite des données à caractère personnel de personnes situées dans l'UE ; fréquent pour les outils RH, CRM et collaboratifs [2] | Entités essentielles et importantes dans des secteurs définis, ainsi que certains fournisseurs TIC qui les soutiennent [8][40] |
| Incidents et continuité | Le plus structuré : classification, notification initiale, tests de résilience obligatoires, délais de reporting encadrés [23][34][36] | Centré sur la violation de données : notification à la CNIL sous 72 heures si risque avéré ; le sous-traitant SaaS alerte sans délai [2][41] | Incident significatif : alerte initiale sous 24 heures, rapport de suivi sous 72 heures, rapport final sous 1 mois ; mesures de continuité obligatoires [11][8] |
| Surveillance des tiers SaaS | Le plus prescriptif : droits d'audit contractuels, clauses de sortie, localisation des données, continuité garantie [23][39][42] | Contrat article 28 obligatoire [2][41] | Sécurité des fournisseurs critiques : évaluation, clauses contractuelles de sécurité et réexamen périodique [33][40] |
| Journalisation et gouvernance | Journalisation formalisée des accès et des opérations TIC ; conservation des incidents au moins 5 ans ; audits indépendants et responsabilités documentées [22][23][38] | Journalisation des accès et des événements de sécurité ; conservation limitée dans le temps ; gouvernance RGPD centrée sur la conformité des traitements [2] | Journaux centralisés et immuables ; conservation selon le risque et les besoins d'enquête ; MFA et gestion documentée des droits d'accès [33][35][37] |
En pratique, un même SaaS peut relever des trois cadres à la fois. Il faut donc lire ce tableau dimension par dimension, pas comme un simple face-à-face entre textes.
Prenons un cas très concret : un outil RH utilisé par une banque française. Ce SaaS peut tomber en même temps sous DORA, le RGPD et NIS2. Dans ce type de situation, la bonne approche consiste à appliquer, pour chaque sujet, l’exigence la plus stricte.
Dit autrement, il ne suffit pas d’avoir un contrat RGPD propre si DORA demande, en plus, des droits d’audit, des clauses de sortie et des garanties de continuité. Sur les tiers SaaS et sur la traçabilité des fonctions critiques financières, DORA impose le cadre le plus serré.
Après avoir comparé les exigences, il faut passer à l’exécution sans refaire deux ou trois fois les mêmes contrôles. DORA, le RGPD et NIS2 se pilotent mieux avec un socle commun de processus, puis une déclinaison par cadre.
L’inventaire SaaS est le point de départ. Il doit couvrir le propriétaire, le fournisseur, le contrat, les données, l’hébergement, les intégrations, les sous-traitants et le niveau de criticité. Ce registre alimente à la fois le registre RGPD, la cartographie DORA des contrats ICT et l’inventaire NIS2 des fournisseurs critiques [43][47][48][51].
Sans cette base, tout se dérègle assez vite. La classification devient floue, la gestion des accès varie d’une équipe à l’autre, et les notifications partent sur des critères qui ne sont pas alignés. Une plateforme comme Avanoo peut automatiser cette découverte, y compris pour le Shadow IT, à partir des journaux d’identité, des dépenses et des extensions de navigateur [44][49][50].
Une fois ce socle en place, la priorité passe à la hiérarchisation des fournisseurs. L’idée est simple : classer chaque fournisseur par niveau de risque - standard, important, critique - puis faire correspondre à chaque niveau la due diligence, les clauses contractuelles et la fréquence de revue. Même logique pour les accès : moindre privilège, MFA sur les systèmes sensibles, revue périodique des droits et suppression rapide des comptes inactifs [25][45][46].
Ensuite, il faut penser opérationnel. En cas d’écart ou d’incident, mieux vaut un seul playbook que trois procédures qui se contredisent. Ce playbook doit couvrir le triage, le confinement, l’escalade, la notification et la coordination avec le fournisseur SaaS. Le triage doit répondre tout de suite à une question très concrète : est-ce qu’on touche à des données personnelles, à une fonction critique, ou aux deux ?
Centralisez aussi les logs, les rapports, les tests de continuité et les revues d’accès dans un référentiel unique, classé par cadre [51][52]. Dit autrement, il faut un seul endroit où chercher les preuves, pas une chasse au trésor entre plusieurs outils.
Le tableau ci-dessous montre l’ordre d’exécution.
| Priorité | Contrôle | Cadres couverts | Premier pas concret |
|---|---|---|---|
| 1 | Inventaire SaaS | DORA, NIS2, RGPD | Découverte automatisée + détection du Shadow IT |
| 2 | Classification des fournisseurs | DORA, NIS2, RGPD | Niveaux de criticité + qualification contractuelle |
| 3 | Playbook d'incident | DORA, NIS2, RGPD | Critères de triage + seuils de notification |
| 4 | Accès et journalisation | DORA, NIS2, RGPD | MFA + revue périodique des droits + journaux structurés |
| 5 | Tests de continuité et de reprise | DORA, NIS2 | Tests de continuité et de reprise réguliers |
Une fois les écarts de périmètre et de contrôle posés, il faut regarder ce que chaque cadre apporte, dans la pratique, au pilotage du risque SaaS.
DORA va le plus loin sur le risque lié aux tiers. C’est le cadre le plus précis sur ce point. En contrepartie, il ne vise que le secteur financier et s’accompagne d’une charge documentaire lourde.
NIS2 a un champ d’application plus large et met les dirigeants en première ligne. C’est un point fort, car la gestion du risque ne reste pas cantonnée à l’IT. En revanche, le texte entre moins dans le détail que DORA sur les clauses à prévoir dans les contrats.
Le RGPD, lui, reste le passage obligé dès qu’un SaaS traite des données personnelles. Ses règles sur la sous-traitance et la protection des données sont claires. Mais il ne traite ni la continuité d’activité ni le cas des données non personnelles.
Le tableau ci-dessous montre, de façon simple, ce que chaque cadre apporte - et là où il s’arrête - pour un SaaS déjà en production.
| Cadre | Principales forces pour le risque SaaS | Principales limites pour le risque SaaS |
|---|---|---|
| DORA | Très granulaire sur le risque tiers ; impose des droits d'audit et des plans de sortie | Périmètre limité au secteur financier ; charge documentaire élevée |
| NIS2 | Large couverture sectorielle ; responsabilité des dirigeants engagée | Moins détaillé sur les clauses contractuelles ; transposition variable selon les États membres |
| RGPD | Protection la plus forte sur les données personnelles ; s'applique à toute organisation traitant ces données via SaaS | Ne couvre pas la résilience opérationnelle ni les données non personnelles |
Ces écarts servent ensuite de base pour cadrer les contrôles SaaS de façon concrète.
Un même outil SaaS peut entrer dans le champ des trois textes en même temps. DORA, le RGPD et NIS2 se complètent : chacun traite une facette du risque SaaS. Ils s'appuient sur des bases communes, mais avec des périmètres et des demandes qui ne sont pas les mêmes.
Le bon réflexe, c'est de tout piloter dans un seul dispositif. L'idée est simple : éviter les silos. En pratique, cela passe d'abord par un registre SaaS unique, enrichi avec les bons attributs - criticité, données traitées, dépendances fournisseurs. Ce socle peut ensuite alimenter les trois cadres sans repartir de zéro à chaque fois.
La mise en œuvre tient en quatre actions : cartographier tous les SaaS en usage, y compris le Shadow IT ; classifier les données et le niveau de criticité de chaque application ; documenter les dépendances et les contrats fournisseurs ; aligner la gouvernance avec des rôles clairs entre le RSSI, le DPO, le responsable des risques ICT et la direction. Avanoo peut automatiser la découverte, la classification et le suivi des risques SaaS.
Voici les priorités à traiter d'abord :
| Action prioritaire | Cadre(s) concerné(s) | Résultat attendu |
|---|---|---|
| Cartographier | DORA / NIS2 / RGPD | Registre complet |
| Classifier | RGPD / NIS2 | Cartographie des données sensibles |
| Documenter | DORA / RGPD / NIS2 | Registre fournisseurs à jour |
| Gouverner | DORA / NIS2 | Responsabilités claires |
Un seul référentiel, un seul pilotage, trois exigences couvertes. Le sujet n'est pas de monter trois programmes séparés, mais de bâtir un programme unique de gestion du risque SaaS, capable de couvrir ces trois cadres dans la durée.
::: faq
Il faut regarder trois choses de près : la nature du SaaS, le secteur de votre entreprise et les données traitées.
Un même outil peut entrer dans le champ des trois textes à la fois. :::
::: faq
Dès le départ, alertez la personne ou l’équipe chargée de qualifier l’incident comme majeur. Le délai commence à courir à partir de cette qualification. En clair, c’est ce qui permet de lancer la notification aux autorités dans les délais prévus par DORA et NIS2, par exemple 4 heures pour DORA et 24 heures pour NIS2.
En parallèle, réunissez sans attendre les responsables de la gestion de crise. En pratique, cela vise surtout les équipes informatique, conformité, gestion des risques et juridique. Chacun a un rôle précis, et plus ils sont mobilisés tôt, plus la réponse gagne en clarté. :::
::: faq
Priorisez les SaaS à partir d’une analyse d’impact métier. L’idée est simple : commencez par ceux dont l’arrêt ferait le plus de dégâts sur l’activité.
En pratique, regardez d’abord les services dont l’interruption toucherait fortement :
La classification doit reposer sur des critères concrets, pas sur une impression générale. Appuyez-vous sur des éléments factuels comme le type de données traitées, la criticité pour les opérations, la localisation de l’hébergement et le niveau de dépendance au fournisseur.
Autre point à ne pas laisser de côté : les SaaS repérés via le Shadow IT ou le Shadow AI. S’ils traitent des données sensibles, ils doivent entrer dans le registre afin d’être évalués puis régularisés. Autrement dit, même un outil peu visible aujourd’hui peut devenir un vrai sujet s’il manipule des informations sensibles. :::
Co-fondateur & CEO
Tanguy Duthion est co-fondateur et CEO d'Avanoo. Ancien de Google et d'Asana, il a fondé Avanoo pour aider les organisations à reprendre la main sur leurs usages SaaS et IA.
Découvrez comment Avanoo peut cartographier votre paysage SaaS et IA, réduire les risques et optimiser les coûts. Une plateforme fiable avec un accompagnement humain dédié.
