Shadow AI : quels risques pour les entreprises soumises à DORA ?
Votre direction sait-elle réellement quelles intelligences artificielles sont utilisées par vos collaborateurs, avec quelles données et pour quels usages ?
ChatGPT pour résumer un document. Claude pour analyser un contrat. Gemini pour préparer une présentation. Copilot pour travailler sur des fichiers. Une extension de navigateur qui intègre discrètement un modèle d’IA. Une équipe de développeurs qui connecte une application métier à une API ou à une plateforme d’IA sans passer par les processus habituels de validation.
Individuellement, chacun de ces usages peut sembler anodin.
Additionnés à l’échelle d’une entreprise, ils peuvent pourtant créer un véritable système d’information parallèle autour de l’intelligence artificielle.
C’est ce que l’on appelle le Shadow AI.
Pour les entreprises soumises au règlement européen DORA, la question mérite une attention particulière.
Non, DORA n’interdit pas le Shadow AI. Le règlement ne contient d’ailleurs aucune disposition portant ce nom.
En revanche, le Shadow AI peut rendre beaucoup plus difficile l’application de principes qui sont, eux, au cœur de DORA : connaître son environnement numérique, identifier et gérer ses risques TIC, contrôler les accès, surveiller les incidents, maîtriser ses prestataires et ses dépendances technologiques ou encore maintenir un registre des services TIC fournis par des tiers.
Comment maîtriser un risque que l’on ne voit pas ?
Et comment superviser un prestataire dont on ignore parfois jusqu’à l’existence ?
Qu’est-ce que le Shadow AI ?
Le Shadow AI désigne l’utilisation de systèmes, services ou fonctionnalités d’intelligence artificielle en dehors de la visibilité, de la gouvernance ou des processus de contrôle établis par l’organisation.
C’est en quelque sorte le petit frère, particulièrement rapide, du Shadow IT.
Le cas le plus évident est celui d’un collaborateur utilisant son compte personnel ChatGPT, Claude ou Gemini depuis son ordinateur professionnel.
Mais en 2026, réduire le Shadow AI à ce seul scénario serait déjà dépassé.
Il peut également s’agir :
d’une fonctionnalité IA intégrée à une application SaaS déjà utilisée par l’entreprise ;
d’une extension de navigateur ayant accès au contenu des pages consultées ;
d’un assistant de programmation utilisé par un développeur ;
d’une API d’IA connectée à une application interne ;
d’une plateforme telle qu’Azure OpenAI, Amazon Bedrock ou Google Vertex AI utilisée sans gouvernance centralisée ;
d’un modèle exécuté localement ;
ou désormais d’un agent IA disposant d’accès à des applications, bases de données ou outils de l’entreprise.
Les recherches de Netskope illustrent cette évolution. En 2025, l’entreprise observait déjà que le Shadow AI ne concernait plus seulement les applications SaaS : plateformes GenAI, modèles exécutés localement et agents personnalisés venaient élargir la surface à superviser. Le rapport relevait notamment une progression rapide des plateformes permettant de construire des applications et agents directement connectés aux données de l’entreprise.
Le Shadow AI n’est donc plus seulement une question de chatbot.
Il devient une question d’architecture du système d’information.
Le problème n’est pas l’IA. C’est l’IA invisible.
Les collaborateurs n’utilisent généralement pas une IA non autorisée dans l’intention de contourner la politique de sécurité.
Ils cherchent plutôt à gagner du temps : traduire un texte, résumer un document, corriger un email, analyser un tableau, générer du code, préparer un rendez-vous ou rechercher une information.
L’adoption a d’ailleurs été extrêmement rapide.
Dès 2024, l’étude Work Trend Index de Microsoft et LinkedIn, portant sur 31 000 personnes dans 31 pays, constatait que 75 % des travailleurs interrogés utilisaient déjà l’IA au travail. Parmi les utilisateurs d’IA, 78 % déclaraient apporter leurs propres outils au travail — le phénomène de « Bring Your Own AI ».
Les pratiques évoluent depuis vers davantage de comptes administrés par les entreprises, mais le problème n’a pas disparu.
Dans son rapport 2026, Netskope observe encore que 47 % des utilisateurs de GenAI (outils d'IA génératives) utilisent des applications IA personnelles, tandis que les usages via des comptes administrés par l’organisation progressent. Le même rapport constate une multiplication par six du nombre de prompts envoyés aux applications SaaS de GenAI sur un an.
L’entreprise peut donc parfaitement avoir déployé Microsoft Copilot, ChatGPT Enterprise ou une autre solution officielle et conserver malgré tout une population importante d’utilisateurs travaillant parallèlement avec des comptes ou outils personnels.
C’est précisément là que commence le problème de visibilité.
Le compte personnel : une petite différence qui peut tout changer
Prenons un exemple simple.
Une entreprise a autorisé un service d’intelligence artificielle dans un environnement professionnel administré.
Un collaborateur utilise pourtant le même service avec son compte personnel parce qu’il l’utilisait déjà avant le déploiement de la solution officielle ou parce qu’il préfère certaines fonctionnalités de sa version personnelle.
Visuellement, pour l’utilisateur, la différence paraît minime.
Pour le RSSI, elle peut être considérable.
Selon les services et leur configuration, les mécanismes de gouvernance, de conservation, de contrôle des accès, de journalisation, de protection des données ou de gestion du cycle de vie peuvent différer entre un environnement d’entreprise maîtrisé et un compte personnel.
Un rapport 2026 consacré à la visibilité des usages IA constate d’ailleurs que distinguer les comptes personnels des instances professionnelles d’un même service reste l’un des principaux angles morts techniques des organisations interrogées.
La question n’est donc plus seulement :
« Autorisons-nous ChatGPT, Claude, Gemini ou Copilot ? »
Mais :
« Quelle instance est utilisée, par qui, sous quel compte, avec quelles données, avec quels droits et avec quelle traçabilité ? »
Que se passe-t-il lorsqu’un collaborateur copie une donnée confidentielle dans une IA ?
C’est probablement le risque le plus intuitif du Shadow AI.
Imaginez quelques gestes parfaitement banals :
Un commercial demande à une IA de résumer une proposition contenant les coordonnées et besoins d’un client.
Un développeur colle un morceau de code afin de comprendre une erreur.
Un juriste demande l’analyse d’un contrat.
Un financier importe un tableau pour obtenir une synthèse.
Un responsable RH utilise un assistant pour reformuler une évaluation.
Un administrateur transmet un extrait de configuration contenant par inadvertance un identifiant ou un secret.
L’ANSSI est particulièrement claire sur ce sujet.
Dans ses recommandations de sécurité concernant les systèmes d’IA générative, elle rappelle que transmettre du texte, des images ou des documents à un service d’IA générative tiers revient à remettre ces informations au prestataire qui exploite le service.
L’ANSSI recommande ainsi de ne pas transmettre de données sensibles à des services d’IA générative grand public non maîtrisés et cite notamment les données personnelles, informations contractuelles, juridiques ou financières, ainsi que les mots de passe et clés d’API parmi les informations nécessitant une vigilance particulière.
Le risque n’est donc pas théorique.
Des volumes de données qui deviennent considérables
L’enjeu change également d’échelle avec l’intensification des usages.
En 2025, Netskope constatait que le volume moyen de données envoyé mensuellement vers les applications de GenAI avait été multiplié par plus de 30 en un an. Les catégories observées comprenaient notamment propriété intellectuelle, données réglementées, code source et secrets.
En 2026, le même éditeur constate que les incidents liés à l’envoi de données sensibles vers les applications GenAI ont doublé sur un an, avec une moyenne observée de 223 incidents de violation de politiques de données par mois et par organisation dans son périmètre d’analyse.
Ces chiffres ne signifient évidemment pas que toutes les entreprises connaissent exactement 223 fuites de données par mois.
Ils montrent en revanche quelque chose de fondamental :
plus l’utilisation de l’IA augmente, plus les flux de données vers ces services deviennent un sujet de sécurité à part entière.
Quand l’IA se cache dans les outils déjà autorisés
Le Shadow AI présente une autre difficulté : l’entreprise peut utiliser de l’intelligence artificielle sans avoir installé un nouvel « outil IA ».
Les fonctionnalités génératives apparaissent progressivement dans les logiciels de bureautique, CRM, outils marketing, solutions de visioconférence, plateformes de développement, outils de création, moteurs de recherche et services SaaS.
Une étude Netskope publiée en 2025 relevait que 90 % des organisations observées utilisaient directement des applications de GenAI, mais que 98 % utilisaient des applications intégrant des fonctionnalités de GenAI.
La différence est importante.
Un inventaire consistant uniquement à demander :
« Utilisons-nous ChatGPT ? »
est devenu insuffisant.
Il faut également demander :
« Parmi les logiciels que nous utilisons déjà, lesquels intègrent désormais des fonctionnalités d’IA, et que font-elles de nos données ? »
API, agents et applications connectées : le nouveau Shadow AI
Une seconde vague est désormais en cours.
L’utilisation de l’IA sort progressivement de l’interface du chatbot pour entrer directement dans les applications.
Un développeur peut connecter une API d’IA à une base documentaire.
Une équipe peut construire un assistant interne sur Azure OpenAI, Amazon Bedrock ou Google Vertex AI.
Un agent peut obtenir l’autorisation de consulter des emails, des fichiers, un CRM ou des outils métiers et d’y réaliser certaines actions.
La CNIL souligne en 2026 que la démocratisation de l’IA agentique permet désormais à des systèmes d’agir sur leur environnement à la place de l’utilisateur et entraîne des chaînes de traitement qui peuvent être complexes et parfois opaques.
Pour la sécurité, cela change considérablement l’équation.
Un chatbot reçoit ce qu’un utilisateur décide de lui transmettre.
Un agent connecté à plusieurs systèmes peut potentiellement accéder directement à l’information et agir sur son environnement, dans la limite des autorisations qui lui ont été accordées.
La question du contrôle des identités, des permissions, des secrets, des journaux et du principe de moindre privilège devient alors centrale.
Pourquoi le Shadow AI pose-t-il particulièrement problème avec DORA ?
Il faut ici être précis.
DORA n’interdit pas le Shadow AI.
Le règlement ne dit pas : « une entreprise financière ne doit pas utiliser de ChatGPT personnel ».
L’enjeu est différent.
DORA impose aux entités financières concernées de disposer d’un cadre de gestion du risque TIC et de connaître les ressources, systèmes et dépendances nécessaires à leurs activités.
Le règlement impose également une gestion structurée du risque lié aux prestataires tiers TIC.
L’article 28 prévoit notamment que les entités financières maintiennent et mettent à jour un registre d’informations concernant les accords contractuels relatifs aux services TIC fournis par des prestataires tiers. Il impose également une stratégie de gestion du risque lié aux tiers TIC.
Le Shadow AI crée donc un paradoxe évident.
Comment évaluer le risque d’un service TIC dont l’organisation ignore l’utilisation ?
Comment documenter une dépendance qui n’a jamais été déclarée ?
Comment déterminer quelles données sont confiées à un fournisseur si l’entreprise ne connaît pas les usages ?
Comment analyser la criticité d’un service si un processus métier s’est progressivement mis à en dépendre sans décision formelle ?
Le Shadow AI ne constitue pas automatiquement une violation de DORA. Il crée en revanche des angles morts susceptibles d’affaiblir la capacité de l’organisation à démontrer la maîtrise de ses risques TIC et de ses tiers.
L’AMF commence elle-même à parler de Shadow AI
Le sujet est désormais très concret pour le secteur financier français.
Dans son étude 2026 sur l’usage de l’intelligence artificielle par les acteurs des marchés financiers, l’AMF identifie explicitement parmi les risques organisationnels l’utilisation non contrôlée ou non autorisée de l’IA dans l’entreprise, ou « shadow AI ».
Les acteurs interrogés font également ressortir des risques de confidentialité, de propriété intellectuelle, de dépendance à des fournisseurs externes et de traçabilité. L’étude insiste sur la nécessité d’une gouvernance robuste, d’une supervision humaine et d’une traçabilité des usages.
Parallèlement, l’AMF a fait de l’évolution du risque cyber lié à l’intelligence artificielle un sujet de supervision en 2026.
Elle considère que les nouveaux modèles peuvent accélérer l’identification et l’exploitation des vulnérabilités et appelle les acteurs financiers à adapter leurs dispositifs de maîtrise des risques.
Pour les entités soumises à DORA, la direction du mouvement est donc assez claire :
l’IA doit progressivement entrer dans la cartographie et la gouvernance du risque numérique.
Interdire toutes les IA ? Probablement une mauvaise réponse
Face au Shadow AI, la première réaction peut être tentante : bloquons tout.
Le problème est qu’une politique totalement déconnectée des usages réels risque simplement de déplacer ces usages encore davantage dans l’ombre.
L’histoire du Shadow IT l’a déjà montré : lorsqu’un outil apporte un gain de productivité important, les utilisateurs trouvent souvent un moyen de l’utiliser.
Les chiffres Microsoft/LinkedIn sur le « Bring Your Own AI » illustrent précisément ce phénomène.
L’objectif devrait donc être moins de « combattre l’IA » que de transformer un usage invisible en usage connu, évalué, autorisé lorsque c’est possible et contrôlé lorsque c’est nécessaire.
Comment reprendre le contrôle du Shadow AI ?
Une stratégie réaliste peut être structurée autour de huit actions.
1. Découvrir avant de bloquer
La première étape consiste à comprendre les usages réels.
Quels services sont consultés ?
Quels comptes sont utilisés ?
Quelles applications intègrent de l’IA ?
Quelles API communiquent avec des modèles externes ?
Quels agents ou outils locaux ont été installés ?
Quelles équipes développent déjà leurs propres applications IA ?
L’inventaire déclaré par les métiers est utile, mais il peut être complété par des capacités techniques de découverte : analyse des flux, CASB/SSE, journaux d’authentification, inventaire SaaS, gestion des postes, revue des extensions, analyse des environnements cloud et des API.
Le principe est simple : on ne peut pas gouverner ce que l’on ne voit pas.
2. Cartographier les données et les usages
Tous les usages ne présentent pas le même risque.
Demander à une IA de reformuler une phrase publique n’est pas équivalent à lui transmettre un portefeuille client, du code source ou un rapport d’incident.
L’organisation doit donc associer :
outil → utilisateur → usage → données → fournisseur → criticité.
Cette cartographie permet de prioriser plutôt que d’appliquer les mêmes restrictions partout.
3. Proposer des outils approuvés
Une politique efficace doit fournir une alternative.
Si l’entreprise interdit les services publics mais ne donne à ses collaborateurs aucun moyen sécurisé de bénéficier de l’IA, elle crée elle-même une incitation au Shadow AI.
Des environnements professionnels administrés permettent généralement d’ajouter des mécanismes de contrôle, d’identité, de gouvernance et de traçabilité qui n’existent pas nécessairement dans les usages personnels.
Mais l’achat d’une licence « Enterprise » ne règle pas tout.
Il faut encore configurer correctement le service, les accès, les connecteurs et les politiques de données.
4. Définir précisément les données autorisées et interdites
Une charte disant simplement « soyez prudents avec l’IA » est insuffisante.
Les utilisateurs doivent savoir ce qu’ils peuvent réellement faire.
Par exemple :
Autorisé : contenus publics, reformulations génériques, idéation sans données sensibles.
Sous conditions : documents internes non sensibles, analyse dans un environnement professionnel approuvé.
Interdit dans un service public non maîtrisé : données personnelles sensibles, secrets, mots de passe, clés API, données clients confidentielles, code propriétaire critique, données réglementées ou documents classifiés selon la politique interne.
Ces catégories doivent évidemment être adaptées au métier et à la classification de l’information de chaque organisation.
5. Maîtriser les identités et les droits
Les comptes professionnels doivent être privilégiés.
SSO, MFA, gestion centralisée des identités, cycle de vie des comptes et principe du moindre privilège permettent de reprendre le contrôle.
Cette exigence devient encore plus importante pour les agents IA et applications connectées.
Un agent capable de lire l’ensemble d’un espace documentaire alors que son utilisateur ne devrait accéder qu’à une partie de celui-ci constitue un risque évident.
Un agent IA ne devrait jamais disposer de plus de droits que ce qui est nécessaire à sa mission.
6. Journaliser les usages importants
La traçabilité est essentielle.
Qui a utilisé quel service ?
Quand ?
Avec quelles ressources ?
Quel connecteur a été activé ?
Quelle application a interrogé quelle API ?
Quelles actions un agent a-t-il réalisées ?
La réponse dépend évidemment de la criticité de l’usage et des possibilités techniques de chaque service.
L’objectif n’est pas de conserver aveuglément tous les prompts de tous les collaborateurs.
Il est de disposer d’une journalisation proportionnée permettant de comprendre les événements significatifs et d’investiguer en cas d’incident.
7. Évaluer les fournisseurs d’IA comme de vrais fournisseurs
Le logo « AI » ne dispense pas de due diligence.
Il faut comprendre :
où sont traitées les données ;
quelles garanties contractuelles existent ;
quels sous-traitants interviennent ;
quelles données sont conservées ;
quelles mesures de sécurité sont appliquées ;
quels mécanismes de notification d’incident existent ;
quelles possibilités d’audit ou d’évaluation sont prévues ;
comment récupérer ou supprimer les données ;
et comment sortir du service si celui-ci devient indisponible ou inadapté.
Pour une organisation soumise à DORA, cette analyse doit naturellement s’inscrire dans son dispositif plus large de gestion du risque tiers TIC.
8. Former plutôt que simplement interdire
Le collaborateur qui colle un document dans une IA cherche généralement à travailler plus efficacement, pas à provoquer une fuite de données.
Il faut donc expliquer le pourquoi.
Quelques scénarios concrets valent souvent mieux qu’une charte de vingt pages :
« Puis-je envoyer ce contrat ? »
« Puis-je demander à une IA d’analyser ce fichier Excel client ? »
« Puis-je utiliser mon compte ChatGPT personnel ? »
« Puis-je connecter cet assistant à ma boîte email ? »
« Puis-je installer cette extension ? »
« Puis-je utiliser une IA pour analyser un incident de sécurité ? »
La sensibilisation doit rendre les bonnes décisions faciles.
Shadow AI et DORA : 10 questions à poser à votre organisation
Un premier diagnostic peut commencer très simplement.
Savons-nous quelles applications d’IA sont réellement utilisées ?
Savons-nous distinguer les comptes professionnels des comptes personnels ?
Savons-nous quelles données sont transmises à ces services ?
Avons-nous recensé les fonctionnalités IA intégrées à nos SaaS existants ?
Avons-nous identifié les API, plateformes et agents IA utilisés par les équipes techniques ?
Les outils autorisés sont-ils intégrés à notre gestion des identités et des accès ?
Disposons-nous de journaux suffisants pour investiguer un incident lié à un usage IA ?
Nos principaux fournisseurs IA ont-ils été évalués comme des tiers TIC lorsque cela est pertinent ?
Nos collaborateurs savent-ils clairement quelles données peuvent ou non être transmises ?
L’IA et le Shadow AI apparaissent-ils dans notre gouvernance et notre cartographie des risques ?
Une organisation incapable de répondre à plusieurs de ces questions possède probablement moins un problème « d’IA » qu’un problème de visibilité et de gouvernance.
De Shadow AI à Trusted AI
Le Shadow AI est finalement le symptôme d’une transformation plus profonde.
L’adoption de l’intelligence artificielle va plus vite que les processus traditionnels de gouvernance informatique.
Chercher à stopper cette adoption est probablement illusoire.
La véritable question est de savoir comment la transformer.
Passer d’outils inconnus à un inventaire.
De comptes personnels à des environnements maîtrisés.
De données envoyées sans contrôle à des règles compréhensibles.
D’applications connectées sans gouvernance à des accès maîtrisés.
De fournisseurs invisibles à des tiers évalués.
D’usages cachés à des usages traçables et assumés.
Pour les organisations soumises à DORA, cette démarche s’inscrit naturellement dans une ambition plus large : connaître son environnement numérique et être capable d’en maîtriser les risques et les dépendances.
DORA n’interdit pas le Shadow AI.
Mais une organisation qui ne sait pas quelles intelligences artificielles utilisent ses collaborateurs, quelles données elles traitent et de quels fournisseurs elle dépend se trouve nécessairement avec des angles morts dans son dispositif de maîtrise du risque numérique.
Comment Safercy peut vous accompagner avec SaferAI ?
Avec SaferAI, Safercy accompagne les organisations qui souhaitent bénéficier des possibilités offertes par l’intelligence artificielle sans perdre la maîtrise de leurs données et de leur système d’information.
Une démarche peut notamment permettre de :
cartographier les usages IA existants et identifier le Shadow AI ;
évaluer les risques associés aux outils et fournisseurs ;
analyser les flux de données et les accès ;
définir une politique d’usage adaptée à l’organisation ;
mettre en place une gouvernance et un processus d’autorisation ;
évaluer les usages IA dans le cadre plus global du risque TIC et de DORA ;
sécuriser les applications et agents connectés au système d’information ;
définir les exigences de journalisation et de contrôle ;
et sensibiliser les collaborateurs aux usages sûrs de l’IA.
L’objectif n’est pas de choisir entre innovation et sécurité.
Il est de rendre l’innovation visible, gouvernable et maîtrisable.
Car en matière de Shadow AI, le premier risque est souvent celui que l’on ne sait pas encore que l’on prend.
Sources
AMF — DORA : règlement sur la résilience opérationnelle numérique dans le secteur financierDossier DORA de l’AMF
AMF — Étude sur l’usage de l’intelligence artificielle par les acteurs des marchés financiers (2026)Étude AMF sur l’intelligence artificielle
AMF — Résilience cyber : évolution des risques liés à l’intelligence artificielleCommunication AMF sur l’IA et la résilience cyber
ANSSI — Recommandations de sécurité pour un système d’IA générativeGuide ANSSI sur la sécurité de l’IA générative
ANSSI — Synthèse de la menace sur l’IA générative face aux attaques informatiques (2026)Synthèse ANSSI sur la menace liée à l’IA générative
CNIL — IA agentique et protection des données (2026)Note CNIL sur l’IA agentique
Microsoft & LinkedIn — 2024 Work Trend IndexMicrosoft & LinkedIn Work Trend Index 2024
Netskope — Cloud and Threat Report: Shadow AI and Agentic AINetskope — Shadow AI and Agentic AI
Netskope — Cloud and Threat Report 2026Netskope Cloud and Threat Report 2026
