Par Olivia Dubois
·
25 juillet 2026
Le point clé : un SaaS hors radar peut faire tomber la conformité sur trois fronts à la fois. Si je ne vois pas l’outil, je ne peux ni le mettre dans mes registres, ni suivre les accès, ni tracer un incident, ni prouver quoi que ce soit en audit.
En clair, l’article montre une idée simple :
Quelques faits à retenir tout de suite :
| Cadre | Ce qu’il demande | Ce que le Shadow IT casse |
|---|---|---|
| NIS2 | Inventaire, gestion des accès, suivi des tiers, journalisation, notification | Actifs absents, comptes hors SSO, incidents mal qualifiés |
| DORA | Registre TIC, suivi des prestataires, tests de résilience, incidents | Registre incomplet, contrats hors cadre, logs dispersés |
| RGPD | Registre des traitements, DPA, transferts, preuve de conformité | Traitements non déclarés, sous-traitants sans contrôle, preuve manquante |
En bref, je retiens ceci : sans inventaire SaaS continu, sans registre fournisseurs à jour et sans traces d’accès et d’incident, la conformité reste partielle sur NIS2, DORA et le RGPD.
Avec NIS2, le Shadow IT SaaS fait sauter la maîtrise des actifs, des accès et des incidents.
NIS2 demande un inventaire complet, avec un propriétaire, une classification et un cycle de vie pour chaque service. Dès qu’un SaaS est souscrit en dehors du circuit prévu, il sort de cet inventaire et échappe au contrôle. En clair, un actif absent du registre est aussi absent du dispositif NIS2.
Et le problème va vite plus loin. Sans visibilité nette sur les outils en place, le contrôle des tiers et des accès ne tient plus.
Un SaaS non approuvé ne figure pas dans le registre des tiers. Il passe donc à côté des clauses de sécurité, de l’évaluation du fournisseur et des vérifications attendues. Les données peuvent aussi être envoyées vers une juridiction que l’entreprise ne maîtrise pas.
Côté accès, NIS2 attend du MFA, le principe du moindre privilège et des revues périodiques. Si l’outil reste hors SSO, les comptes ne sont souvent pas revus. Résultat : des accès orphelins restent ouverts, parfois pendant des mois.
NIS2 impose une alerte sous 24 heures, une notification sous 72 heures et un rapport final sous un mois. [3][2][1] Sur le papier, c’est clair. Dans les faits, si le SaaS n’est pas référencé et si les logs ne remontent pas de façon centralisée, qualifier un incident au sens NIS2 devient compliqué.
Sans logs ni inventaire, l’incident est dur à détecter. Et une fois détecté, il devient presque impossible à documenter proprement.
NIS2 attend des preuves de terrain, pas juste des politiques écrites. Pour le Shadow IT, ces artefacts n’existent souvent pas. Une plateforme comme Avanoo peut repérer les SaaS non référencés et produire les éléments attendus pour un dossier NIS2.
On retrouve ensuite le même angle mort dans DORA, avec une exigence de maîtrise opérationnelle encore plus stricte.
DORA pousse encore plus loin la logique de NIS2 : pour être conforme, il ne suffit pas de voir son SI. Il faut aussi montrer qu’il tient le choc. Depuis le 17 janvier 2025, DORA s’applique aux entités financières en France - banques, assureurs, sociétés de gestion, prestataires de paiement - avec une demande centrale : maîtriser l’ensemble des risques TIC, y compris ceux liés aux prestataires externes[13][14][5]. Et c’est là que le Shadow IT SaaS complique tout.
DORA impose un inventaire des actifs TIC, avec un responsable désigné, un classement par criticité et un lien clair avec les fonctions métier[16][17][19][20][21]. Cet inventaire doit être mis à jour au moins une fois par an, ainsi qu’après tout changement majeur[16][17][21].
Sur le papier, c’est simple. Dans la pratique, un SaaS acheté directement par une équipe métier passe souvent entre les mailles du filet. Il n’apparaît dans aucun registre. Résultat : la cartographie entre actifs, fonctions critiques et continuité devient floue. Et quand cette cartographie est incomplète, les plans de continuité et de reprise reposent sur des hypothèses fragiles.
DORA impose aussi un registre des prestataires TIC et des clauses minimales dans les contrats : droits d’audit, continuité, portabilité des données et notification en cas d’incident[12][23]. Ce registre doit être transmis au moins une fois par an aux autorités compétentes, avec des infos sur les services, les données traitées et les fonctions associées[12][23].
Un SaaS adopté sans validation interne coche rarement ces cases. Le contrat ne prévoit pas les clauses DORA. Le prestataire n’apparaît pas dans le registre. Aucune évaluation préalable n’a été faite. C’est ce décalage entre l’usage réel et le registre contractuel qui rend DORA difficile à prouver[7][9].
DORA fixe des délais stricts pour la notification des incidents majeurs : notification initiale dans les 4 heures suivant la classification, rapport intermédiaire sous 72 heures, puis rapport final sous 1 mois[15][4][18]. Pour tenir ces délais, il faut détecter vite, savoir exactement quels systèmes sont touchés et centraliser les journaux.
Avec un SaaS non référencé, ces conditions ne sont souvent pas réunies. Les événements restent bloqués dans la console d’administration du prestataire, sans remontée vers le SIEM de l’entreprise. Sans référentiel clair ni journaux centralisés, qualifier, notifier et documenter un incident devient un vrai casse-tête. Et ces écarts ressortent ensuite dans les tests de résilience et les contrôles de supervision.
DORA attend des preuves concrètes : registre complet, tests de résilience, journaux d’incidents[6][8][10][11]. Le Shadow IT rend le registre incomplet, cache des dépendances pendant les tests de résilience et déforme les indicateurs d’incidents. Le souci ne tient donc pas seulement à l’absence de preuve. Il tient à la rupture de toute la chaîne d’évidence.
Avanoo peut détecter les SaaS non référencés et alimenter le registre DORA. Le même angle mort réapparaît sous le RGPD, avec un impact direct sur les traitements de données.
Le RGPD pose une règle simple : savoir où vont les données personnelles. Quand un SaaS est adopté sans validation, ces données sortent du registre des traitements, des DPA et, bien souvent, des analyses d’impact. Le souci ne vient pas du texte lui-même. Il vient du manque de visibilité sur les traitements.
Le RGPD impose de tenir un registre des activités de traitement. Ce registre recense chaque traitement, sa finalité, les catégories de données concernées et les transferts éventuels hors UE. Si un SaaS n’est pas référencé, il n’y apparaît pas. Résultat : la base légale, la durée de conservation et les flux de données restent sans contrôle.
Des outils de collaboration, de partage, d’automatisation ou d’IA générative peuvent ainsi passer sous le radar. Et là, le risque est direct sur la base légale, la rétention et les transferts. Un SaaS non référencé crée un traitement non documenté. En pratique, il devient donc bien plus dur à justifier sur le plan juridique.
Le RGPD impose de conclure un accord de traitement des données avec chaque sous-traitant qui accède à des données personnelles. Il faut aussi vérifier que les transferts hors UE reposent sur des garanties adaptées et documenter les prestataires utilisés. Un SaaS adopté sans validation interne ne coche aucun de ces points : pas de DPA, pas de vérification de la localisation des données, pas d’évaluation préalable du prestataire.
C’est là que ça coince. Dès qu’il y a rupture entre données personnelles, sous-traitant et preuve contractuelle, les autorités de contrôle ont un angle d’attaque clair lors d’un audit.
Le RGPD repose sur l’accountability. Autrement dit, l’organisation doit pouvoir produire à tout moment des preuves de conformité : journaux d’accès, DPIA, DPA, certifications, durées de conservation et règles de suppression. Avec le Shadow IT, cette chaîne de preuve casse dès le départ.
Au fond, l’enjeu du RGPD n’est pas seulement de respecter la règle. Il faut aussi être capable de le prouver.
Avanoo peut détecter les SaaS non référencés, identifier les données personnelles exposées et générer des preuves d’audit exploitables. C’est cette rupture de preuve qui permet ensuite de comparer, cadre par cadre, la façon dont NIS2, DORA et le RGPD réagissent au Shadow IT.
Les trois cadres partagent le même point faible : un SaaS invisible sort du champ de contrôle, de preuve et d’audit. En clair, si l’outil n’apparaît nulle part, il échappe aussi au suivi. Et c’est là que le Shadow IT SaaS fait dérailler la conformité.
NIS2 demande une cartographie des actifs et des risques fournisseurs. DORA impose un registre des actifs ICT et des prestataires. Le RGPD, lui, exige un ROPA.
| Type de Shadow IT | Ce que cela masque | Cadre le plus exposé |
|---|---|---|
| SaaS non référencé | Hors cartographie et hors ROPA | NIS2 + RGPD |
| Comptes personnels (Google Drive, WeTransfer…) | Invisible au SSO et aux journaux d'authentification | RGPD |
| Services gratuits (ChatGPT, Notion free…) | Hors registre des prestataires | DORA |
Une cartographie incomplète ne crée pas juste un “petit manque”. Elle fragilise tout de suite la chaîne contractuelle et la gestion des accès.
Un SaaS non validé ouvre un trou à trois niveaux : contrat, documentation et identité.
NIS2 impose une gestion du risque fournisseur dans la chaîne d’approvisionnement. DORA demande un registre d’informations standardisé, avec une classification des prestataires par criticité. Le RGPD oblige à savoir quels sous-traitants traitent des données personnelles.
Avec le Shadow IT, cette chaîne de contrôle se casse en morceaux. Le service peut exister sans validation, sans trace contractuelle et sans vue centralisée côté sécurité ou conformité. Avanoo détecte notamment la réutilisation de mots de passe sur des SaaS non référencés et attribue un score de risque par application, ce qui aide à traiter d’abord les cas les plus urgents.
Le problème change de dimension dès qu’un incident arrive.
C’est souvent là que tout se joue. Un incident sur un SaaS non référencé passe facilement sous le radar : pas de journaux centralisés, pas de détection, pas de classification.
Pourtant, les délais de notification sont serrés : 24 heures pour NIS2 (alerte précoce), 4 heures pour DORA (incidents majeurs) et 72 heures pour le RGPD (violations de données personnelles).
Sans vue sur l’application en cause, respecter ces délais devient impossible. Et reconstituer la chronologie de l’incident pour les autorités de contrôle ? Même combat. Le souci n’est donc pas seulement technique. C’est une rupture nette de traçabilité et de notification.
Sans journaux centralisés, la preuve de contrôle reste, elle aussi, bancale.
En audit, chaque cadre demande des preuves concrètes : journaux d’accès, inventaires à jour, documentation fournisseur et registres d’incidents. Avec le Shadow IT, cette chaîne de preuves est presque toujours incomplète.
Les auditeurs tombent alors sur :
Et là, le nœud du problème apparaît. Même quand des pratiques de conformité existent sur le terrain, elles deviennent dures à démontrer. Le point central n’est pas seulement l’absence d’un outil dans un registre. C’est la chaîne de preuves cassée.
Après avoir vu comment le Shadow IT met chaque cadre sous pression, passons à ce qu’ils couvrent en pratique - et à ce qu’ils laissent de côté.
Les trois cadres abordent le Shadow IT SaaS sous des angles différents. Le point clé, c’est simple : aucun ne le couvre de bout en bout.
| Cadre | Principale force | Limite principale |
|---|---|---|
| NIS2 | Gouvernance cyber large sur 18 secteurs ; responsabilité explicite des dirigeants ; sécurité de la chaîne d'approvisionnement [24][25] | Moins prescriptif que DORA sur le suivi opérationnel des fournisseurs TIC au quotidien |
| DORA | Très granulaire sur le risque tiers TIC ; notification des incidents très encadrée (T+4 heures, T+72 heures, T+1 mois) [19][22][26] | Périmètre limité au secteur financier ; ne s'applique pas aux autres organisations |
| RGPD | Principe d'accountability fort ; obligation de démontrer la conformité sur chaque traitement de données personnelles | Ne couvre que les données personnelles, pas l'ensemble du patrimoine SaaS de l'organisation |
NIS2 pousse les organisations à raisonner en matière de gouvernance, de pilotage et de supervision par la direction. C’est utile pour poser le cadre. En revanche, le texte laisse en grande partie à chaque organisation le soin d’organiser la surveillance continue des SaaS.
DORA va plus loin sur le détail. C’est le cadre le plus précis ici, surtout sur le risque lié aux tiers TIC. Mais il y a un piège évident : il part du principe que l’organisation sait déjà quels outils elle utilise. Si l’inventaire SaaS est incomplet, les applications non repérées passent entre les mailles du filet.
Le RGPD, lui, vise bien les SaaS qui traitent des données personnelles. C’est là qu’il est le plus utile. Mais il ne regarde pas tout le parc SaaS. Un outil de collaboration, de finance ou même de sécurité peut créer un risque opérationnel net sans forcément entrer dans le champ d’un traitement de données personnelles au sens attendu pour la conformité. Résultat : il peut rester hors radar.
Au fond, ces trois cadres se complètent. Mais aucun ne tient bien sans une visibilité suivie du parc SaaS. C’est là que se trouve le vrai angle mort : pas dans le manque de règles, mais dans le manque de visibilité sur les applications utilisées au quotidien.
Tant que certaines applications ne sont pas repérées, elles échappent en même temps à la gouvernance prévue par NIS2, aux registres attendus par DORA et à l’accountability du RGPD. Autrement dit, la découverte continue du parc SaaS n’est pas un “plus”. C’est le minimum pour montrer sa conformité de façon crédible.
Sans cette couche de visibilité, la conformité reste partielle. Avanoo peut aider à cartographier ce parc et à centraliser les preuves utiles aux audits.
NIS2, DORA et le RGPD n'ont pas le même périmètre ni la même logique de contrôle. Pourtant, ils demandent tous la même chose : de la visibilité sur les SaaS, les accès, les tiers, les incidents et les preuves. Le Shadow IT n'est pas juste un sujet d'outils non validés. C'est aussi un sujet de gouvernance et de preuve.
Dans la pratique, un outil invisible casse tout de suite la chaîne de conformité. Un SaaS non répertorié passe hors du registre DORA, du registre des traitements RGPD et des contrôles NIS2.
L'enjeu n'est donc pas d'ajouter contrôle sur contrôle. Il faut d'abord rendre le parc SaaS visible. Le bon point de départ, c'est un socle unique : inventaire SaaS continu, registre des fournisseurs, traçabilité des accès et des incidents.
Dans cette logique, la découverte continue devient un prérequis d'audit. Avanoo aide à cartographier le parc SaaS, à détecter le Shadow IT et à centraliser les preuves d'audit.
Sans visibilité continue, le Shadow IT reste l'angle mort de NIS2, DORA et du RGPD.
::: faq
Commencez par rendre visible ce qui ne l’est pas : cartographiez les usages sur le terrain et repérez les trous dans la gestion de vos actifs TIC.
Ensuite, appuyez-vous sur une plateforme de gouvernance SaaS comme Avanoo pour automatiser la découverte, bâtir un inventaire complet, classer les outils selon leur niveau de criticité et mettre en place un pilotage continu. :::
::: faq
Les SaaS les plus à risque sont souvent ceux qui passent sous le radar de la DSI. On parle ici de Shadow IT et de Shadow AI.
Le vrai problème n’est pas seulement l’outil en lui-même. C’est le fait qu’il échappe à la visibilité et au contrôle internes. Dès qu’une équipe utilise un service sans validation, la DSI perd la main sur ce qui circule, sur qui y accède, et sur la façon dont les données sont stockées.
Les cas les plus critiques concernent les outils qui manipulent des données sensibles, comme :
Si ces services ne proposent pas de protections de base, comme le chiffrement ou l’authentification multifacteur, le risque grimpe vite.
Les outils d’IA posent un souci encore plus net. Beaucoup sont gratuits, simples d’accès, et disponibles directement dans un navigateur. En pratique, il suffit parfois de quelques clics pour qu’un salarié y colle un document interne, un extrait de code ou des chiffres confidentiels, sans se rendre compte de ce que cela peut entraîner. :::
::: faq
Lors d’un audit, la conformité ne se démontre pas avec des promesses. Elle se prouve avec une documentation regroupée, claire et à jour de tout votre écosystème numérique : registre des actifs et des fournisseurs TIC, évaluations des risques, rapports d’incidents, ainsi que preuves de tests.
Avanoo simplifie ce travail en automatisant la collecte des preuves et la production des rapports d’audit. En parallèle, la plateforme vous donne une vision continue du Shadow IT, des dépendances et de la gouvernance des données SaaS. :::
Shadow AI Expert & Chief AI Officer
Olivia Dubois est Shadow AI Expert et Chief AI Officer chez Avanoo. Diplômée d'HEC Paris et ancienne consultante chez BCG, elle accompagne les entreprises dans la détection et la gouvernance du Shadow AI et du Shadow IT.
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é.
