Gouvernance de la Shadow AI : pourquoi une hausse de 509 % n’est pas un problème de DLP
Une étude sectorielle publiée en mai 2026 révèle que l’adoption d’applications IA natives sur les endpoints a augmenté de 509 % en un an, et celle des assistants de codage de 357 % sur la même période. Il ne s’agit pas d’une « utilisation généralisée de l’IA » : ce sont des logiciels autonomes qui s’exécutent localement sur les endpoints des employés, héritant de leur identité et de leurs autorisations, et accédant à toutes les données auxquelles ces employés ont accès.
La réponse habituelle considère cela comme un problème de visibilité : identifier les outils IA, les inventorier, bloquer ceux jugés risqués. Cette approche est erronée. Une hausse de 509 % n’est pas une courbe de visibilité, mais une courbe de gouvernance. Les contrôles déployés par la plupart des organisations — règles DLP, listes d’autorisation, extensions navigateur, garde-fous au niveau des prompts — ont été conçus pour un monde où le transfert de données était un événement ponctuel, pas un flux continu. L’essor de la Shadow AI a rendu cette hypothèse obsolète. La solution réside dans une gouvernance appliquée au niveau de la donnée, indépendamment de l’outil, du navigateur ou du endpoint ayant accédé à la donnée.
5 enseignements clés
1. Le vrai manque concerne la gouvernance de la Shadow AI, pas la Shadow AI elle-même.
L’adoption des applications IA natives sur endpoint a bondi de 509 % en un an ; celle des assistants de codage de 357 %. Le problème n’est pas que les employés utilisent l’IA, mais que personne ne peut prouver à quelles données elle a accédé. Les Prévisions Kiteworks 2026 montrent que 33 % des organisations n’ont pas de journaux d’audit exploitables et 61 % disposent de logs fragmentés. Une adoption à 509 % avec une couverture d’audit à 33 % n’est pas un manque d’outils, mais un manque d’architecture.
2. L’ère du DLP ne résiste pas aux workflows IA.
La prévention des pertes de données traditionnelle part du principe qu’un utilisateur colle des données dans un canal connu : un événement unique, observable et délimité. L’IA agentique enchaîne outils, serveurs MCP et APIs à la vitesse de la machine. Il n’y a plus de moment précis à inspecter, ni de canal unique à surveiller. Les données ont déjà été transformées en sortie de modèle, indétectable par une signature DLP. Les contrôles sur lesquels les organisations ont le plus investi sont aujourd’hui les moins adaptés à la nouvelle surface de risque IA.
3. La Shadow AI est désormais la première cause d’incidents internes par négligence.
Le rapport DTEX/Ponemon Insider Threat 2026 identifie la Shadow AI comme principal facteur d’incidents par négligence — devant le partage de fichiers non surveillé et la messagerie web personnelle. Les insiders négligents représentent 53 % du coût total des risques internes, soit 10,3 M$ par an (+17 % sur un an). Une organisation subit en moyenne 13,8 incidents de négligence par an, pour environ 747 000 $ chacun. Considérer ce problème comme un simple manque d’outils revient à sous-estimer une défaillance de gouvernance des données.
4. La principale exposition à la vie privée a un nom et un workflow.
Les données personnelles dans les prompts — citées par 35 % des organisations comme exposition majeure — sont généralement atténuées par des règles internes. Mais une règle ne peut pas empêcher quelqu’un de coller une liste de clients dans ChatGPT à 23h. Ensuite, 29 % évoquent les transferts de données à l’international via des fournisseurs IA et 26 % la fuite de PII dans les sorties IA. Chacune de ces situations relève d’un événement au niveau de la donnée, déguisé en problème d’outil. Une gouvernance IA opérant au niveau de l’outil ne répond pas aux questions posées au niveau de la donnée.
5. La réponse architecturale se situe au niveau de la donnée.
Classification automatique de chaque fichier entrant dans le système. Application de l’ABAC à chaque demande d’accès IA. Un journal d’audit unifié retraçant tout ce que l’IA a consulté, quel que soit l’outil ou le endpoint utilisé. Quand un agent IA doit demander l’accès à la couche donnée — et que cette demande est authentifiée, autorisée et journalisée — l’outil Shadow n’a aucun contournement possible. Car la couche donnée n’est pas un problème à résoudre pour l’outil.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Pourquoi le DLP a été conçu pour un monde que la Shadow AI a quitté
La prévention des pertes de données a passé vingt ans à apprendre à reconnaître les schémas d’exfiltration : une pièce jointe envoyée par e-mail personnel, un fichier copié sur une clé USB, un collage dans un formulaire de transfert. Chaque événement est observable, attribuable à un utilisateur et stoppable en temps réel. Cette architecture fonctionne car les événements sont délimités.
Les workflows IA ne le sont pas. Un employé ouvre un assistant de codage. L’assistant ingère des fichiers locaux, les tokenize dans la fenêtre de contexte du modèle, génère une sortie, qui se retrouve dans un ticket, un e-mail ou un autre outil IA. À quel moment, dans cette chaîne, a lieu l’exfiltration ? Il n’y a pas de moment unique à inspecter, ni de canal unique à surveiller. Les données ont déjà été transformées en sortie de modèle, indétectable par une signature DLP.
Les agents IA sur endpoint rendent l’écart structurel. Un agent local qui hérite des accès d’un employé à un CRM, un dépôt de code ou un SharePoint interne n’est pas un « outil Shadow » au sens classique. C’est un processus privilégié, autorisé par les contrôles d’identité légitimes et incompréhensible pour les règles DLP traditionnelles. La conséquence est directe : les contrôles dans lesquels les organisations ont le plus investi sont aujourd’hui les moins adaptés à leur surface de risque IA actuelle.
Ce que révèlent les données sur le risque interne et le coût réel
Le rapport DTEX Insider Threat 2026 avec le Ponemon Institute identifie la Shadow AI comme principal facteur d’incidents internes par négligence. Les trois principaux contributeurs : partage de fichiers non surveillé, messagerie web personnelle et Shadow AI. Les insiders négligents représentent 53 % du coût total des risques internes, soit 10,3 M$ par an (+17 % sur un an). Une organisation subit en moyenne 13,8 incidents de négligence par an, pour environ 747 107 $ chacun.
Le constat culturel est encore plus marquant. 92 % des organisations estiment que l’IA générative a profondément modifié la façon dont les employés accèdent et partagent l’information — mais seulement 13 % l’ont intégrée formellement dans leur stratégie métier. Cet écart de 79 points entre la réalité culturelle et la pratique opérationnelle est le même que celui mesuré par l’étude de mai 2026 : les outils progressent de 509 %, tandis que les contrôles peinent à suivre. Le coût moyen annuel des menaces internes, 19,5 M$, n’est pas une hypothèse de prévision : c’est le coût réel de la défaillance actuelle.
Les données de prévision montrent que la gouvernance accuse un retard
Le rapport de prévisions Kiteworks 2026 révèle que chaque organisation interrogée a l’IA agentique dans sa feuille de route — sans exception. Mais seules 37 à 40 % disposent aujourd’hui de contrôles de confinement efficaces. La limitation de finalité sur les agents IA atteint 37 %. Les « kill switches » 40 %. L’isolation réseau est encore plus faible.
Les données sur la vie privée sont tout aussi claires. L’exposition numéro un citée est la présence de données personnelles dans les prompts — signalée par 35 % des organisations. Atténuation actuelle : « principalement par des règles internes, rarement technique ». Une règle ne peut pas empêcher qu’une liste clients soit collée dans ChatGPT à 23h. Ensuite, 29 % évoquent les transferts de données à l’international via des fournisseurs IA et 26 % la fuite de PII dans les sorties. Chacune de ces situations relève d’un événement au niveau de la donnée, déguisé en problème d’outil. L’ensemble est cohérent : l’étude de mai 2026 documente la courbe d’adoption ; le rapport DTEX/Ponemon le coût ; le rapport de prévisions Kiteworks l’écart entre intention et architecture. La conclusion à laquelle aucun plan DLP ne répond : il faut rapprocher les contrôles de la donnée.
Pourquoi les cadres de conformité exigent déjà une gouvernance au niveau de la donnée
Les régulateurs ont pris les devants. Tous les cadres de protection des données en vigueur supposent que l’organisation peut prouver quelle entité a accédé à quelles données, sous quelle autorisation, à quel moment — et produire cette preuve à la demande. La Shadow AI remet en cause ces trois exigences.
La règle de sécurité HIPAA impose des contrôles d’audit et d’autorisation pour tout système accédant à des informations médicales protégées. Un assistant IA exécuté localement sur le poste d’un clinicien est, selon HIPAA, un système. Si l’organisation ne peut pas produire le journal d’accès de ce qu’a consulté l’assistant, le contrôle échoue à l’audit.
L’article 30 du RGPD sur les registres de traitement suppose que l’organisation peut décrire le traitement des données personnelles — y compris par des outils IA, y compris sur les endpoints. L’excuse « nous ignorions que nos employés utilisaient cet outil » n’existe pas dans la réglementation. La même logique s’applique au CCPA, au LGPD et à toutes les lois américaines sur la vie privée inspirées du RGPD.
L’AI Act européen impose des obligations de documentation, de journalisation et de supervision humaine pour les systèmes IA à haut risque jusqu’en 2026 et 2027. Les Prévisions Kiteworks 2026 montrent un écart de contrôle de 22 à 33 points entre les organisations prêtes pour l’AI Act et les autres. Une utilisation de Shadow AI que l’équipe conformité ne peut pas inventorier ne peut pas être documentée — donc ne peut pas être conforme. Le schéma est le même dans tous les cadres : les régulateurs ne s’intéressent pas à l’outil utilisé, mais à la donnée consultée et à l’autorisation d’accès. C’est une question de niveau donnée, à laquelle les contrôles Shadow AI au niveau de l’outil ne répondent pas.
À quoi ressemble réellement la gouvernance au niveau de la donnée
Trois propriétés architecturales sont essentielles pour une gouvernance qui s’intercale entre l’IA et la donnée — et non au niveau du endpoint, du navigateur ou de l’outil.
Classification automatique à l’ingestion. Chaque fichier entrant dans le système reçoit des attributs de politique dès son arrivée — via application web, e-mail, MFT, APIs, formulaires web ou intégrations IA. La classification n’est pas une tâche humaine : c’est une propriété de la donnée qui persiste dans toutes les décisions d’accès IA ultérieures.
Application de l’ABAC au niveau de la donnée. Chaque décision d’accès — par un utilisateur, une API, un agent IA ou une session Secure MCP Server — est évaluée selon les attributs de la donnée et l’identité du demandeur à chaque opération. Le modèle n’obtient jamais d’autorisation implicite selon qui l’a connecté. La demande est évaluée selon la politique avant toute restitution de donnée.
Journaux d’audit unifiés. Chaque opération IA génère une entrée de log de qualité probante, intégrée à l’infrastructure SIEM et conformité existante. Une infrastructure unifiée d’échange de données est la seule base permettant d’obtenir une preuve unifiée.
Le point structurel clé : lorsqu’un employé exécute un agent IA Shadow sur un endpoint géré, l’agent doit toujours demander l’accès à la couche donnée. Soit la demande est authentifiée, autorisée et journalisée — soit elle est refusée. Le Réseau de données privé Kiteworks, l’AI Data Gateway et le Secure MCP Server appliquent ce schéma sur la messagerie électronique, le partage de fichiers, le MFT, le SFTP, les formulaires web et le trafic IA, sous un moteur de politique unique et un journal d’audit consolidé.
Ce que la gouvernance de la Shadow AI exige concrètement
Premièrement, auditez vos journaux d’audit avant d’évaluer tout nouvel outil de sécurité IA. 33 % des organisations n’ont pas de logs exploitables et 61 % ont des logs fragmentés. Si vous ne pouvez pas produire un historique défendable des accès IA aux données sur les 90 derniers jours, la décision d’outillage dépend de la décision d’architecture.
Deuxièmement, classez à l’ingestion, pas à l’inspection. Les organisations qui attendent que la donnée circule pour la classifier auront toujours un temps de retard sur les workflows IA. Les tags appliqués à l’ingestion persistent dans chaque décision d’accès IA ultérieure.
Troisièmement, appliquez la limitation de finalité au niveau de la donnée, pas du modèle. 63 % des organisations ne peuvent pas imposer de limites de finalité aux agents IA. Les instructions au niveau du modèle ne résistent pas à l’injection de prompt. L’ABAC évalué à chaque opération, si.
Quatrièmement, traitez les données d’exposition à la vie privée comme une liste d’actions. Données personnelles dans les prompts (35 %), transferts internationaux via des fournisseurs IA (29 %) et fuite de PII dans les sorties (26 %) correspondent chacune à un contrôle au niveau de la donnée : classification empêchant la sortie de données personnelles taguées, contrôle de souveraineté liant le traitement à une juridiction, et filtrage des sorties basé sur les attributs de la donnée.
Cinquièmement, consolidez les échanges de données fragmentés avant de déployer l’IA à grande échelle. 61 % des organisations utilisent des approches partielles, spécifiques à un canal ou minimales pour l’échange de données. Ajouter l’IA par-dessus la fragmentation produit des logs IA fragmentés. Consolidez d’abord. Déployez l’IA ensuite.
Pour en savoir plus sur la protection des données contre l’ingestion par l’IA, réservez votre démo personnalisée dès aujourd’hui.
Foire aux questions
La règle de sécurité HIPAA impose l’application des autorisations et des journaux d’audit complets pour tout système accédant à des informations médicales protégées — y compris les assistants IA sur endpoints gérés. Selon les Prévisions Kiteworks 2026, 33 % des organisations n’ont pas de logs d’audit exploitables. Sans application de l’ABAC au niveau de la donnée et logs unifiés, un assistant IA dépassant l’accès strictement nécessaire crée une violation à déclarer sans trace défendable de ce qu’il a consulté.
La surveillance des endpoints et navigateurs détecte l’utilisation des outils. Elle ne détecte pas ce que l’outil fait avec les données. L’exposition principale concerne les données personnelles dans les prompts, signalée par 35 % des organisations et atténuée « principalement par des règles internes, rarement technique » selon les Prévisions Kiteworks 2026. La gouvernance au niveau de la donnée évalue chaque accès IA selon la classification de la donnée — quel que soit le endpoint, le navigateur ou l’outil ayant initié la demande.
L’article 30 du RGPD exige que l’organisation décrive le traitement des données personnelles, y compris par des outils IA. Les Prévisions Kiteworks 2026 documentent un écart de contrôle de 22 à 33 points sur la préparation à l’AI Act européen. Une utilisation de Shadow AI que l’équipe conformité ne peut pas inventorier ne peut pas figurer dans les registres de traitement — c’est donc une défaillance structurelle de conformité, pas un simple oubli d’outil.
Les familles AC, AU et IA du CMMC Niveau 2 imposent l’application des autorisations et une journalisation complète pour chaque entité accédant aux CUI. Seuls 46 % des organisations du DIB se considèrent prêtes selon le rapport Kiteworks 2026 sur la préparation au CMMC. Un employé lançant un agent IA non autorisé sur un endpoint accédant à des CUI crée immédiatement une anomalie d’audit sans application de l’ABAC au niveau de la donnée pour empêcher l’accès.
Auditez les logs d’audit avant d’auditer les outils. 33 % des organisations n’ont pas de logs exploitables et 61 % ont des logs fragmentés sur la messagerie électronique, le partage de fichiers, le MFT et les outils IA selon les Prévisions Kiteworks 2026. Pour répondre de façon défendable à la question « à quelles données la Shadow AI a-t-elle accédé », il faut une journalisation unifiée des échanges de données, existant avant le projet d’inventaire IA — classification à l’ingestion, application de l’ABAC à l’accès, logs unifiés comme preuve.
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 face à l’IA - eBook
L’écart de gouvernance IA : 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é.