Un incident de Shadow AI touche une organisation sur cinq

Votre politique de gouvernance de l’IA ne sert à rien si un collaborateur peut accorder à un outil d’IA l’accès à Microsoft 365 avant même que l’IT n’en soit informé. C’est le constat central d’une nouvelle étude menée par DNSFilter, qui révèle que 20,1 % des organisations interrogées ont déjà subi un incident de sécurité lié à une connexion IA non approuvée. Ce chiffre s’accompagne d’un autre, plus difficile à expliquer : plus de la moitié de ces mêmes organisations affirment disposer de contrôles de gouvernance ou de surveillance de l’IA.

DNSFilter a publié ces résultats le 3 novembre 2026 dans The Cost of Shadow AI, dans le cadre de sa série d’enquêtes Visibility Deficit 2026. L’entreprise a interrogé 400 professionnels IT et cybersécurité, managers ou plus, dans des sociétés de 150 à 5 000 employés aux États-Unis et au Canada, entre le 15 et le 26 juin 2026, en partenariat avec le cabinet d’études Censuswide. Les réponses sont auto-déclarées et collectées par un fournisseur de solutions de filtrage DNS, ce qui reflète les déclarations des répondants, et non les résultats d’un audit. Considérez ces chiffres comme un indicateur fort de la situation des organisations nord-américaines de taille moyenne, sans généraliser au-delà.

Pour un RSSI ou un Chief Compliance Officer, le message est clair. Le contrôle que les régulateurs et auditeurs exigeront ne se limite pas à un document de politique. Il s’agit de prouver que chaque système d’IA ayant accès à du contenu sensible a été autorisé, encadré et journalisé, et que vous pouvez fournir cette preuve en quelques jours. Kiteworks secure data exchange a été conçu pour répondre à cette problématique de preuve, et la suite de cet article explique pourquoi les chiffres de DNSFilter rendent ce sujet urgent.

Résumé des points clés

1. Une organisation sur cinq a déjà connu un incident lié à une IA fantôme.

L’enquête de DNSFilter révèle que 20,1 % des répondants ont associé un incident de sécurité à une connexion IA non approuvée.

2. Les contrôles de gouvernance coexistent avec les connexions non approuvées.

54 % des répondants utilisent des contrôles de gouvernance ou de surveillance de l’IA, mais 46,1 % ont eu un collaborateur qui a connecté un outil d’IA non approuvé à Google Workspace, Microsoft 365 ou à une solution d’authentification unique.

3. La notification a posteriori reste le modèle d’approbation dominant.

DNSFilter constate que 43 % des organisations découvrent l’accès IA seulement après qu’il a été accordé, voire jamais.

4. La prolifération des agents est la prochaine version du même problème.

Les conseillers de Morgan Stanley ont tenté près de 50 000 créations d’agents IA, et les agents non adoptés par les utilisateurs ne sont pas systématiquement revus.

5. La preuve prévaut sur la politique.

Les régulateurs contrôlent les données, pas les modèles. La position défendable repose sur un enregistrement indiquant qui ou quoi a accédé à quel contenu, selon quelle politique, avec quel résultat.

Ce que mesure réellement l’enquête DNSFilter

Le chiffre principal est 20,1 %. Environ un répondant sur cinq indique qu’une connexion IA non approuvée a déjà conduit à un incident de sécurité. Le communiqué ne précise pas comment les répondants définissent un « incident », il ne faut donc pas lire ce chiffre comme un taux de violation. Il s’agit du pourcentage de répondants ayant vécu un événement que leur organisation a classé comme incident de sécurité.

Le second chiffre explique comment ces incidents surviennent. Selon l’enquête, 46,1 % des organisations ont eu un collaborateur qui a connecté un outil d’IA non approuvé à Google Workspace, Microsoft 365 ou à leur fournisseur d’authentification unique. Ces trois plateformes hébergent les contenus sensibles de l’entreprise, ce qui signifie qu’une connexion IA non approuvée n’est pas une simple expérimentation dans le navigateur. C’est un nouvel acteur qui détient une autorisation OAuth sur les systèmes contenant contrats, dossiers clients et données réglementées.

Concrètement, que signifie cette autorisation ? Un collaborateur clique sur « Autoriser » dans un écran de consentement. L’outil d’IA accède alors aux e-mails, fichiers ou agendas sous l’identité de ce collaborateur, indéfiniment, jusqu’à révocation. Aucun ticket n’a été ouvert, aucun contrôle de sécurité n’a été effectué. L’accès est légitime du point de vue du fournisseur d’identité, car l’utilisateur l’a autorisé.

C’est ce qu’on appelle le fossé d’autorisation, et c’est la raison pour laquelle les autorisations ne déterminent pas ce que l’IA devrait pouvoir utiliser. Les systèmes d’identité répondent à la question « cet utilisateur a-t-il approuvé cette application ? » mais pas à « cette application, agissant pour cet utilisateur, doit-elle accéder à ce contenu ? » C’est dans cet écart que l’IA fantôme s’installe.

Pourquoi les politiques échouent à l’écran de consentement

Les données de DNSFilter sur les workflows d’approbation sont particulièrement instructives. Parmi les organisations dont les collaborateurs utilisent des outils d’IA au travail, 36,8 % laissent les employés accorder un accès OAuth ou API et informent l’IT après coup. 6,5 % ne préviennent même pas. Au total, l’enquête estime à 43 % la part des organisations qui découvrent l’accès IA seulement après qu’il a été accordé, voire jamais.

Considérez ces chiffres comme une architecture, non comme un manque de rigueur. Une organisation qui laisse ses collaborateurs s’auto-approuver et prévenir l’IT après coup privilégie la rapidité à la revue, souvent pour de bonnes raisons business. Mais ce modèle de notification ne produit qu’un enregistrement de l’autorisation, sans décision sur le contenu exposé par cette autorisation.

L’autre moitié du problème, c’est le nombre de contrôles. Avec 54 % des répondants ayant mis en place des contrôles de gouvernance ou de surveillance de l’IA, on pourrait s’attendre à ce que les connexions non approuvées soient rares. Or, près de la moitié en signalent une. En réalité, la surveillance indique qu’une connexion existe, tandis que la gouvernance décide de ce à quoi la connexion peut accéder. La plupart des organisations ont investi dans la première. C’est le fossé entre détection et contrôle que peu de programmes ont comblé.

Cette distinction est cruciale pour l’audit. Un auditeur ne demande pas si vous pouvez voir le trafic IA. Il veut savoir si vous pouvez prouver que l’accès à une donnée réglementée a été autorisé, que cette autorisation a été appliquée au moment de l’accès, et qu’un journal infalsifiable l’a enregistré. Un tableau de bord qui compte les outils IA connectés ne répond pas à ces questions.

Le déficit de visibilité est plus large que ce que pensent les dirigeants

Ken Carnesi, CEO de DNSFilter, avance un constat qui mérite réflexion. Environ une organisation sur sept sur le réseau DNSFilter utilise plus de 10 outils IA, alors que moins d’un leader IT sur 100 pense que c’est le cas dans son environnement. Le rapport complet donne des chiffres pour les deux aspects. Les données réseau couvrent 3,4 milliards de requêtes vers des outils d’IA générative, provenant de plus de 43 000 organisations nord-américaines en août 2026. En comptant les fournisseurs IA distincts par jour ouvré, l’organisation médiane en voit cinq, et 15,2 % en voient plus de 10. Dans l’enquête, seuls 0,5 % des professionnels IT déclarent que leurs collaborateurs utilisent plus de 10 outils IA, soit un écart de 1 à 30.

Notez ce que mesure la donnée réseau : elle compte les fournisseurs IA distincts apparaissant dans le trafic DNS, ce qui reflète l’usage, pas nécessairement une intégration approuvée ou autorisée. Les deux sources proviennent de DNSFilter, dont les données réseau sont issues de ses propres clients et dont le rapport se termine par une invitation à tester son produit. Aucune n’est indépendante. Pourtant, la tendance rejoint ce que rapportent d’autres professionnels, ce qui justifie d’y prêter attention.

Le volet contrôle apparaît tout aussi faible dans ce rapport. Sur l’ensemble de ce trafic, seuls 0,75 % des requêtes IA générative ont été bloquées, ce que DNSFilter interprète comme une absence de contrôle effectif malgré les investissements en gouvernance. Par ailleurs, 61,5 % des répondants ne peuvent pas affirmer que chaque outil de sécurité de leur environnement est correctement configuré, et 61,8 % ne peuvent pas garantir que tous sont activement surveillés. Autoriser l’IA est un choix de politique légitime. L’autoriser par défaut, sans décision, en est un autre.

Le 2026 Data Breach Investigations Report de Verizon offre un éclairage complémentaire. S’appuyant sur des données de prévention des pertes de données plutôt que sur une enquête, il révèle que 67 % des utilisateurs accèdent à des services IA via des comptes personnels sur des appareils professionnels, et que 45 % des collaborateurs utilisent régulièrement l’IA sur leur appareil professionnel, contre 15 % l’année précédente. L’IA fantôme devient la troisième action interne non malveillante la plus courante, soit une multiplication par quatre.

En croisant ces deux sources, une tendance se dessine : l’utilisation de l’IA au travail n’est plus marginale, et une grande partie se fait via des comptes que l’organisation ne peut ni voir ni contrôler, un phénomène que les équipes de cybersécurité qualifient désormais de déplacement de l’IA fantôme vers le navigateur. Les chiffres de Verizon couvrent la période d’octobre 2024 à novembre 2025, issus de données d’incidents et DLP partagées volontairement, donc non exhaustives. Mais la méthode diffère et aboutit à une conclusion similaire.

Pour un Chief Compliance Officer, la conséquence est claire : « nous avons une politique IA » et « nous savons où l’IA accède à des données réglementées » sont deux affirmations distinctes. Seule la seconde résiste à une question de suivi d’un régulateur.

La prolifération des agents chez Morgan Stanley en avant-première

L’IA fantôme ne se limite pas au copier-coller dans un chatbot. L’étape suivante, ce sont les collaborateurs qui créent des agents. American Banker rapportait le 2 novembre 2026 que les conseillers Morgan Stanley ont tenté près de 50 000 créations d’agents IA via des instructions en langage naturel, principalement pour automatiser des tâches répétitives.

Le détail important concerne la suite. Koren Maranca, responsable IA pour la gestion de patrimoine du groupe, explique : « Parfois, quelqu’un crée un agent, l’utilise deux fois, puis ne s’en sert plus jamais. » Les agents adoptés par une équipe passent en revue et sont approuvés après utilisation, tandis que les agents orphelins ne sont pas systématiquement revus.

Morgan Stanley est une entreprise dotée de moyens importants, fortement réglementée, et décrit ses contrôles comme en place. Elle mène aussi un vaste effort de revue, avec plus de 1 000 personnes qui examinent les résultats des modèles avant la mise en production, et indique qu’environ la moitié des demandes des conseillers sont désormais traitées en premier lieu par un agent IA. L’entreprise prend le sujet au sérieux. Pourtant, le modèle de revue a posteriori laisse subsister une population d’agents abandonnés dont l’accès a été accordé et jamais réexaminé.

Observez le parallèle avec le constat de DNSFilter. Dans les deux cas, l’accès est accordé d’abord, revu ensuite. Dans les deux cas, une autorisation persistante reste attachée à une identité humaine. Un agent oublié conserve ses identifiants, tout comme une autorisation OAuth oubliée.

C’est pourquoi les agents doivent être gouvernés au même titre que les humains qui les créent, sous le même moteur de politique et le même registre d’audit. Un agent n’est pas un risque à part qui nécessiterait un programme distinct. Il agit pour le compte d’une personne, hérite de ses droits, et ne doit pas aller au-delà. Le problème sous-jacent, c’est l’autorité déléguée dans les workflows IA, qui doit avoir un responsable identifié. Toute approche qui laisse les agents sans gouvernance jusqu’à l’arrivée d’un nouvel outil passe à côté du vrai problème, car les contrôles d’accès existent déjà et doivent simplement s’appliquer.

Les praticiens le constatent, et la politique seule ne suffit pas

Une quatrième source apporte le point de vue des praticiens. L’enquête O’Reilly auprès de 209 professionnels de la sécurité, menée en septembre 2026, révèle que 49 % considèrent la fuite de données sensibles via des outils IA commerciaux comme une préoccupation majeure, à égalité avec la dépendance excessive à des résultats IA non vérifiés. L’échantillon est restreint et auto-sélectionné, sans marge d’erreur annoncée, il s’agit donc d’une tendance, non d’une mesure précise.

Dans cet échantillon, l’IA fantôme est signalée comme répandue par 17 % des répondants dont l’organisation dispose d’une politique IA aboutie, contre 35 % là où la politique est basique et 37 % en l’absence de politique. Les sous-groupes sont petits et leurs tailles non précisées, et la corrélation ne prouve pas que la politique réduit l’IA fantôme. Néanmoins, l’écart suggère que la qualité de la politique compte, et qu’une politique superficielle est aussi inefficace que l’absence de politique.

Les agents apparaissent aussi dans cette enquête. À la question du risque agent le plus préoccupant, 28 % citent les autorisations excessives ou la propriété floue, soit la part la plus élevée. L’absence de propriétaire illustre le vide de responsabilité que montrent les agents orphelins de Morgan Stanley. Quelqu’un a créé l’agent, personne ne l’assume, et ses autorisations subsistent.

Un point de vigilance s’impose ici, dans l’esprit d’une lecture critique des données fournisseurs. Le rapport CISO 2026 de Vorlon, enquête sponsorisée auprès de 500 RSSI américains en janvier-février 2026, indique que 30,4 % ont constaté une activité suspecte d’agents IA en 2025, et que 86,8 % ne savent pas quelles données les outils IA échangent avec les applications SaaS. L’échantillon est limité aux États-Unis et le fournisseur opère sur ce marché. La cohérence entre quatre échantillons, méthodes et sponsors différents est plus convaincante que n’importe quel chiffre isolé.

Les budgets s’orientent vers la gouvernance, la preuve fait foi

Les budgets confirment la pression ressentie par les dirigeants. DNSFilter rapporte que 74,5 % des répondants disposent d’un budget cybersécurité supérieur à celui de l’an passé, 18,8 % l’ont augmenté de plus de 10 %, et 40,3 % citent la sécurité et la gouvernance IA comme priorité pour le prochain euro investi, contre 25,5 % pour la sécurité cloud. L’intention de dépenser ne garantit pas l’efficacité, et l’enquête ne précise pas quels achats combleront l’écart.

Les dépenses IA dans les fonctions conformité augmentent aussi. Compliance Week, citant une étude S-RM, rapporte que 78 % des 225 professionnels de la conformité prévoient d’augmenter leurs investissements dans des outils de conformité et de due diligence dopés à l’IA d’environ 24 % sur un à deux ans, passant de 337 000 à 416 000 dollars. L’article complet est réservé aux abonnés, seuls les chiffres d’introduction sont cités ici, et ils mesurent des attentes, non des résultats.

En croisant ces deux signaux budgétaires, le constat est limpide. Les responsables sécurité vont financer la gouvernance IA, et les équipes conformité vont exposer davantage de documents sensibles à des systèmes IA. Ces deux tendances multiplient les occasions où l’IA accède à du contenu réglementé, ce qui accroît la valeur de la preuve d’une autorisation à chaque accès.

Voici le test à appliquer à tout investissement. Imaginez qu’un régulateur, un auditeur ou un avocat adverse demande comment un système IA a accédé à un enregistrement précis à une date donnée. Pouvez-vous, en quelques jours, fournir l’identité ayant fait la demande, la politique ayant permis l’accès, le contenu retourné et la trace d’audit correspondante ? Si la réponse prend des semaines à corréler des logs issus d’outils différents, l’argent a servi à la visibilité, pas à la gouvernance.

Les régulateurs contrôlent les données, pas les modèles. HIPAA ne fait pas de distinction entre un accès humain ou agent IA, et il en va de même pour les autres cadres qui régissent les données financières, de défense ou de confidentialité. L’obligation de contrôler et de prouver l’accès suit la donnée, où que l’IA l’emmène.

Gouverner la couche données, pas seulement l’outil IA

Si le problème réside dans l’écart entre « l’utilisateur a approuvé cette application » et « cette application doit accéder à ce contenu », la solution se situe là où le contenu est consulté. Il faut donc appliquer la politique au niveau de la donnée, à chaque requête, selon les principes du zéro trust security, que le demandeur soit une personne, un assistant ou un agent créé par un collaborateur.

C’est le principe de conception de Kiteworks Compliant AI et du Secure MCP Server. Le MCP Server permet à des assistants IA comme Claude ou Copilot de travailler avec le contenu dans Kiteworks via le Model Context Protocol. L’authentification utilise OAuth 2.0, et chaque opération est évaluée selon des politiques d’accès basées sur le rôle et les attributs dans le Data Policy Engine de Kiteworks, de sorte qu’une IA hérite des autorisations de l’utilisateur pour lequel elle agit, sans pouvoir les dépasser. Chaque accès est consigné dans un journal d’audit unifié, qui constitue la preuve demandée par un auditeur.

Deux caractéristiques de cette architecture répondent directement aux constats de DNSFilter. D’abord, l’autorisation est vérifiée à chaque requête, et non une fois à la connexion, évitant qu’une autorisation OAuth permanente ne devienne un droit d’accès global à tout ce que l’utilisateur peut voir. Ensuite, l’entrée d’audit attribue l’accès à un système IA précis agissant pour un utilisateur donné, ce qui lève l’ambiguïté du « c’est l’IA qui y a accédé » qui ralentit la réponse aux incidents et les enquêtes réglementaires. La gouvernance dépend de cette traçabilité, car on ne peut pas gouverner ce qu’on ne peut pas attribuer.

Kiteworks n’était pas impliqué dans les flux de données des entreprises ou enquêtes citées dans cet article, et cette architecture ne remplace pas les outils de détection des connexions non autorisées. La détection de l’IA fantôme et l’application de politiques au niveau du contenu sont deux missions distinctes. Les organisations ont besoin des deux, mais seule la seconde fournit la preuve exigée par les régulateurs.

Pour ceux qui construisent un programme, l’architecture repose sur quelques pratiques concrètes, à dérouler dans l’ordre.

1. Recensez les autorisations OAuth et API existantes sur Google Workspace, Microsoft 365 et votre fournisseur d’identité, et révoquez celles qu’aucun responsable métier ne revendique.
2. Remplacez la notification a posteriori par une approbation préalable pour les intégrations IA pouvant accéder à du contenu réglementé, et limitez la durée des autorisations.
3. Désignez un propriétaire pour chaque agent IA, et désactivez les agents inutilisés depuis une certaine période, afin que les agents orphelins perdent leurs droits.
4. Appliquez une politique au niveau du contenu sur les requêtes IA dans le cadre de la protection des données IA, afin que l’accès dépende de la classification de la donnée et des attributs de l’utilisateur, et non du consentement de l’application.
5. Testez la preuve. Sélectionnez un accès IA au hasard et mesurez le temps nécessaire pour retrouver l’identité, la politique, le contenu et la trace d’audit correspondants.

Pour en savoir plus sur le zéro trust data protection et comprendre pourquoi chaque requête, et pas seulement la connexion initiale, doit être vérifiée.

À faire avant la prochaine demande d’audit

Les résultats de DNSFilter doivent inciter à évaluer votre propre organisation. Ne partez pas du principe que vous faites partie des 80 % sans incident ; un rapide état des lieux des risques IA dans votre environnement est le moyen le plus rapide de le savoir. Environ un répondant sur cinq dans cette enquête n’en avait pas conscience avant qu’un incident ne survienne.

Commencez par le chiffre le plus simple à obtenir. Comptez les applications IA tierces disposant d’autorisations OAuth sur votre suite de productivité. Les plateformes d’identité les listent généralement dans une console d’administration, ce qui permet d’obtenir ce nombre rapidement.

Puis, déterminez qui est responsable. La responsabilité de la sécurité IA reste floue dans le secteur, CIO, CTO et RSSI revendiquant le rôle selon les enquêtes. Cette ambiguïté est le problème à résoudre, pas un état de fait à accepter. Désignez un responsable exécutif pour l’accès IA aux données dans votre programme de gouvernance des données, et fournissez au Chief Compliance Officer et à votre équipe GRC un reporting régulier sur la preuve d’accès.

Poursuivez avec les équipes juridiques et privacy. Un Data Protection Officer ou un General Counsel voudra savoir, avant toute enquête, quels systèmes IA ont traité quels enregistrements réglementés. Construire cette traçabilité d’audit dès maintenant coûte bien moins cher que de la reconstituer sous la pression d’un régulateur.

Enfin, remettez en question l’hypothèse du self-service IA. La rapidité est un objectif légitime, et bannir l’IA ne fait que la pousser dans l’ombre. La voie réaliste, c’est l’encadrement gouverné, où les collaborateurs accèdent rapidement à des outils approuvés et où l’approbation est appliquée par la politique au niveau des données, et non laissée à un écran de consentement. Les équipes qui explorent la gouvernance des données IA peuvent s’appuyer sur ce principe pour démarrer leur programme.

Pour en savoir plus sur la production de preuves auditables concernant l’accès IA au contenu sensible, réservez votre démo sans attendre.

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la vie privée face à l’IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données IA
• eBook
  AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.