L’intelligence artificielle générative s’est imposée dans les pratiques professionnelles bien avant que les politiques de sécurité ne rattrapent leur retard. Dès que les employés ont découvert que ChatGPT ou Gemini pouvaient rédiger un rapport, analyser un contrat ou générer du code en quelques secondes, le recours spontané à ces outils s’est généralisé, en dehors de tout cadre de gouvernance. Ce phénomène, le shadow AI, constitue aujourd’hui l’un des vecteurs d’exposition involontaire les plus difficiles à cartographier pour les équipes sécurité.
Contrairement au shadow IT classique (une application SaaS non validée), le shadow AI présente une caractéristique supplémentaire : les données ne sont pas seulement stockées ou traitées ailleurs, elles alimentent potentiellement un modèle tiers, deviennent un historique de conversation accessible à d’autres utilisateurs, ou servent de matériau d’entraînement futur.
Ampleur réelle du phénomène : les chiffres 2025
Les enquêtes convergent vers des taux d’adoption non supervisée élevés. Selon le rapport State of Shadow AI 2026 publié par Unseen Security{rel=“nofollow”}, plus de 80 % des travailleurs du secteur tech, dont près de 90 % des professionnels de la sécurité eux-mêmes, utilisent des outils IA non approuvés par leur employeur. La recherche BlackFog (novembre 2025){rel=“nofollow”} portant sur 2 000 répondants retient 49 % tous secteurs confondus. L’implication des dirigeants est frappante : 69 % des membres du C-suite reconnaissent privilégier la vitesse d’adoption sur la conformité.
Du côté des données effectivement exposées, le rapport Netskope Cloud and Threat Report : Shadow AI and Agentic AI (2025){rel=“nofollow”} quantifie la volumétrie : la quantité de données envoyées mensuellement vers des applications GenAI a progressé de 250 Mo à 7,7 Go en moyenne sur l’année, avec une projection au-delà de 15 Go mensuels fin 2025. Sur ces flux, 47 % des utilisateurs d’IA recourent à des comptes personnels depuis leur poste de travail professionnel, un angle mort complet pour les équipes de détection. Netskope recense par ailleurs une moyenne de 223 tentatives mensuelles par organisation d’inclure des données sensibles (code source, données personnelles réglementées, identifiants, propriété intellectuelle) dans des prompts GenAI, chiffre qui monte à 2 100 dans le quartile supérieur.
Cyberhaven (2024-2025) estime que 27,4 % des données d’entreprise saisies dans des outils IA sont sensibles, contre 10,7 % un an auparavant. Les catégories les plus fréquentes : recherches et jeux de données (33 %), données RH telles que fiches de salaire ou évaluations (27 %), états financiers et données de ventes (23 %).
Vecteurs de risque : au-delà de la simple fuite de données
Le shadow AI ne se limite pas à une question de fuite sortante. Il crée plusieurs classes de risques distincts qui relèvent à la fois de la sécurité et de la conformité réglementaire.
Exfiltration passive via l’historique des conversations
La plupart des services GenAI SaaS conservent par défaut un historique utilisateur. Un employé qui colle un extrait de contrat client, une procédure interne sensible ou des credentials de test dans un prompt crée un historique persistant sur des serveurs tiers hors du périmètre de sécurité de l’organisation. Si le compte n’est pas correctement sécurisé ou si le fournisseur subit une violation, ces données sont exposées sans que l’organisation en soit informée ni en mesure d’agir.
Prompt injection et attaques sur les agents IA
MITRE ATLAS (Adversarial Threat Landscape for AI Systems){rel=“nofollow”}, l’extension du framework ATT&CK dédiée aux systèmes IA, référence la technique AML.T0051 (LLM Prompt Injection) comme vecteur d’attaque significatif. En juin 2025, la vulnérabilité EchoLeak a démontré en conditions réelles la première exploitation zero-click d’une injection de prompt dans un système de production (Microsoft 365 Copilot), permettant l’exfiltration de fichiers internes sans interaction utilisateur. Les agents IA autonomes, de plus en plus déployés dans les pipelines DevOps ou les workflows métier, multiplient cette surface d’attaque : ils accèdent à des outils, persistent un contexte entre sessions, et peuvent être manipulés via des contenus malveillants tiers.
Risque de ré-entraînement et de propriété intellectuelle
Certains fournisseurs de LLM SaaS incluent dans leurs conditions d’utilisation la possibilité d’utiliser les données de conversation pour améliorer leurs modèles. Le code source propriétaire saisi par un développeur, une stratégie commerciale dictée à un assistant IA, ou des spécifications techniques d’un produit en cours de brevet peuvent ainsi se retrouver incorporés dans un modèle accessible à des tiers, voire à des concurrents directs.
Amplification des attaques sociales
L’ENISA Threat Landscape 2025{rel=“nofollow”} (analyse de 4 875 incidents, juillet 2024 à juin 2025) souligne que plus de 80 % des campagnes de phishing observées en 2025 ont recours à des outils IA pour la génération de contenu, notamment via des modèles jailbreakés. Des outils comme Xanthorox AI automatisent l’ingénierie sociale et le développement de malwares. Le shadow AI crée donc un paradoxe opérationnel : les employés s’exposent via des outils non approuvés, et ces mêmes catégories d’outils alimentent les capacités offensives des attaquants ciblant l’organisation.
Exposition réglementaire : RGPD, AI Act, NIS2, DORA
Le cadre réglementaire européen crée une pression cumulative sur les organisations qui ne gouvernent pas leurs usages IA.
| Référentiel | Obligation clé | Conséquence du shadow AI |
|---|---|---|
| RGPD (art. 32) | Sécurité du traitement : mesures techniques et organisationnelles appropriées | Traitements de données personnelles sur outils tiers non évalués = violation potentielle |
| AI Act (GPAI : août 2025 ; haut risque : août 2026) | Registre des systèmes IA déployés, gestion des risques, surveillance humaine | Systèmes IA non inventoriés = non-conformité directe |
| NIS2 (transposition FR 2024) | Gestion des risques de la chaîne d’approvisionnement, sécurité des SI | Dépendance à un service SaaS IA tiers non audité = risque fournisseur non traité |
| DORA (janv. 2025, secteur financier) | Gestion du risque TIC, registre des tiers critiques | Tout service IA en production dans un processus financier doit être répertorié |
La CNIL a publié ses recommandations{rel=“nofollow”} pour le développement et le déploiement de systèmes d’IA respectueux du RGPD, en insistant sur la minimisation des données, la base légale du traitement et l’information des personnes concernées. Ces recommandations s’appliquent aussi bien aux fournisseurs qu’aux organisations qui déploient des outils IA sur des données personnelles.
L’ANSSI{rel=“nofollow”} a produit le guide ANSSI-PA-102 portant 35 recommandations de sécurité pour les systèmes d’IA générative, complémentaire au bulletin CERT-FR 2026-CTI-001 (février 2026) qui documente les vulnérabilités spécifiques des LLM face aux attaques informatiques. Ces référentiels posent le principe d’une analyse de risque systématique avant tout déploiement, et d’une intégration de la sécurité dans l’intégralité du cycle de vie du système IA.
Stratégies de maîtrise : visibilité, gouvernance, contrôle technique
Une approche structurée combine trois couches complémentaires.
Couche 1 : Cartographie et visibilité
L’angle mort est le premier problème à résoudre. Un CASB (Cloud Access Security Broker) moderne, Microsoft Defender for Cloud Apps, Netskope ou Zscaler, permet de découvrir les applications GenAI SaaS accédées depuis le réseau de l’entreprise, d’en évaluer le score de risque (présence d’un DPA, localisation des données, politique d’entraînement), et d’appliquer des politiques DLP sur les flux sortants. L’inspection TLS est un prérequis : sans déchiffrement HTTPS sur le proxy, le trafic vers des services IA reste opaque.
L’audit des OAuth tokens actifs dans les tenants Microsoft 365 et Google Workspace révèle souvent des dizaines d’applications IA tierces autorisées par des utilisateurs, avec des permissions larges (lecture d’emails, accès aux fichiers). Un inventaire régulier via les API d’administration de ces plateformes est une action à fort rapport effort/visibilité.
Couche 2 : Gouvernance et politique
La politique d’usage acceptable de l’IA (AUP-IA) doit classifier les outils en trois tiers : approuvés sans restriction de données sensibles (exemple : Copilot M365 dans un tenant contrôlé avec Data Residency EU) ; approuvés avec restrictions de données (données internes uniquement, pas de données à caractère personnel ni de données client) ; interdits (tout outil sans Data Processing Agreement valide, sans engagement de non-utilisation pour le ré-entraînement, ou sans localisation EU des données).
Cette politique doit s’intégrer dans le registre de traitement (RGPD) et dans l’inventaire des systèmes IA que l’AI Act requiert désormais. Un responsable IA peut être désigné, éventuellement en complément du DPO, pour piloter ce registre et suivre les évolutions réglementaires auprès de l’AI Office européen. La formation des collaborateurs reste incontournable : selon BlackFog (2025), 60 % des employés admettent prendre des risques avec les données pour tenir leurs délais. Une sensibilisation ciblant les comportements concrets, ne pas coller un contrat dans un chatbot public, ne pas soumettre du code avec des secrets en dur, est plus efficace qu’une politique abstraite non ancrée dans les usages réels.
Couche 3 : Contrôles techniques compensatoires
Pour les organisations disposant d’une DSI structurée, plusieurs contrôles techniques réduisent l’exposition résiduelle :
- Déploiement d’une passerelle IA privée (Azure AI Foundry, Amazon Bedrock, Google Vertex AI) avec des modèles frontières ou open-source (Mistral, Llama) sur infrastructure contrôlée, offrant une alternative sanctionnée sans recourir à des services publics non évalués.
- DLP contextuel au niveau de l’endpoint pour détecter les tentatives de copier-coller de données sensibles vers un navigateur, indépendamment de la destination finale.
- Contrôle des extensions de navigateur à risque via la politique de gestion des extensions (Chrome Enterprise, Edge Policies) : de nombreux assistants IA s’installent comme extensions et accèdent au contenu de toutes les pages ouvertes.
- Pour les équipes de développement : revue des dépendances IA dans les pipelines CI/CD, audit des OAuth App integrations dans GitHub/GitLab, et détection des appels non autorisés vers des API LLM tierces depuis les environnements de build.
Impact financier et priorisation des actions
L’IBM Cost of a Data Breach Report 2025{rel=“nofollow”} établit le coût moyen global d’une violation de données à 4,88 millions de dollars, en hausse de 10 % par rapport à 2024. Les violations impliquant un recours à l’IA non gouvernée tendent à présenter une durée de détection plus longue, facteur aggravant direct sur le coût final : chaque jour supplémentaire de persistance non détectée alourdit la facture de remédiation et d’investigation forensique. Le risque shadow AI mérite à ce titre une inscription au registre des risques de l’organisation et une couverture explicite dans le plan de traitement des risques.
La priorisation doit intégrer la valeur des actifs exposés : le code source d’un éditeur logiciel, les données de patients d’un établissement de santé, ou les modèles prédictifs d’une institution financière représentent des actifs critiques dont la fuite via un LLM tiers peut avoir des conséquences irréversibles sur la compétitivité ou la conformité réglementaire. Un mapping des données les plus sensibles et des populations les plus exposées (développeurs, juristes, équipes fusion-acquisition) permet de concentrer les contrôles là où le risque est le plus élevé, sans bloquer l’adoption de l’IA là où elle est maîtrisée.
Pour aller plus loin sur le cadre réglementaire applicable aux déploiements IA en entreprise, consultez la page obligations DSI et AI Act ainsi que les enjeux transversaux de cybersécurité d’entreprise.