Programme Shadow AI : guide gouvernance RSSI 2026

Le programme gouvernance Shadow AI RSSI est devenu l'un des chantiers les plus urgents de la sécurité des systèmes d'information en 2026. Selon Gartner, 78 % des entreprises comptent déjà des employés utilisant des outils d'intelligence artificielle générative sans validation de leur DSI ou de leur RSSI. Cette réalité — que l'on appelle Shadow AI par analogie avec le Shadow IT — n'est plus un phénomène marginal : c'est un risque systémique qui touche la confidentialité des données, la conformité RGPD, l'AI Act et la continuité opérationnelle. Face à cette menace, le RSSI ne peut plus se contenter de bloquer des URLs ou de rédiger des notes de service. Il doit construire un programme complet de gouvernance du Shadow AI, articulé autour de cinq phases successives : audit de l'exposition existante, rédaction d'une politique adaptée, constitution d'un catalogue d'outils approuvés, déploiement d'une architecture de détection et mise en place d'une culture IA responsable. Ce guide détaille chacune de ces phases avec des outils concrets, des grilles d'évaluation, des tableaux comparatifs et un modèle de maturité pour piloter la progression dans le temps. Il est conçu comme le pendant stratégique et programmatique du guide de détection technique du Shadow AI, qui traite en profondeur les méthodes DNS, CASB et proxy logs. Ensemble, ces deux ressources forment un référentiel complet pour le RSSI qui souhaite maîtriser l'intelligence artificielle non contrôlée dans son organisation.

Pourquoi le Shadow AI exige un programme dédié, pas une simple politique IT

Le Shadow AI se distingue du Shadow IT classique par trois caractéristiques qui justifient un traitement programmatique spécifique. Premièrement, la vitesse de propagation : un collaborateur peut adopter un nouvel outil IA en trente secondes depuis son navigateur, sans installation locale, sans trace dans les journaux d'inventaire classiques. Deuxièmement, la nature des données exposées : contrairement à un logiciel de comptabilité piraté, les outils IA collectent activement les données que l'utilisateur leur soumet — contrats, données clients, code source, documents RH — et les envoient vers des serveurs souvent localisés hors de l'Union européenne. Troisièmement, l'opacité des modèles : même quand un éditeur affirme ne pas utiliser les données pour l'entraînement, la politique de confidentialité de son modèle peut prévoir des exceptions larges.

Ces caractéristiques rendent les approches réactives insuffisantes. Bloquer ChatGPT.com n'empêche pas l'usage de GPT-4 via une API tierce, d'un plugin VSCode non validé ou d'un assistant IA intégré à un SaaS déjà approuvé. C'est pourquoi le RSSI doit adopter une démarche proactive et structurée, inscrite dans la durée, avec des indicateurs de pilotage et une gouvernance formalisée.

Phase 1 — Audit de l'exposition Shadow AI : photographier la situation réelle

Avant de construire quoi que ce soit, le RSSI doit mesurer l'exposition réelle de son organisation. Cette phase d'audit combine plusieurs sources complémentaires pour obtenir une image fidèle des usages IA non sanctionnés.

Le questionnaire RSSI : recueil déclaratif

Le point de départ est un questionnaire anonyme diffusé à l'ensemble des collaborateurs, co-porté par les RH pour maximiser le taux de réponse. Ce questionnaire doit explorer : les outils IA utilisés dans le cadre professionnel (nommément), la fréquence d'usage, le type de données soumis (documents internes, données clients, code, données personnelles), et la connaissance des règles en vigueur. L'anonymat est essentiel pour obtenir des réponses sincères. Un taux de réponse supérieur à 60 % est atteignable si le questionnaire est court (moins de 10 questions) et si la direction appuie la démarche.

L'analyse des logs : recueil technique

En parallèle, l'analyse des journaux proxy, DNS et firewall permet de corroborer les déclarations et de détecter les usages non déclarés. Le guide de détection technique du Shadow AI détaille les méthodes précises. À ce stade de l'audit, l'objectif n'est pas d'investiguer des individus mais de quantifier l'exposition : combien de domaines IA distincts sont contactés, quelle fréquence, quel volume de données transféré.

Les interviews managers et DRH

Les entretiens semi-directifs avec les responsables de département et les RH révèlent souvent des usages institutionnalisés que ni le questionnaire ni les logs ne capturent complètement — par exemple, un manager qui a recommandé à toute son équipe d'utiliser un outil IA pour rédiger les comptes-rendus de réunion. Ces interviews doivent rester dans un cadre bienveillant, orienté amélioration des pratiques et non sanction.

Classification par risque et score d'exposition

Les usages identifiés sont ensuite classifiés selon une grille à trois dimensions :

• Sensibilité des données exposées : données publiques (faible risque), données internes (risque modéré), données confidentielles ou données personnelles (risque élevé), données secrètes ou stratégiques (risque critique).
• Capacité d'exfiltration du fournisseur : politique de rétention des données, localisation des serveurs, clauses d'entraînement sur les données utilisateur, certifications (SOC 2, ISO 27001).
• Étendue de l'usage : usage individuel isolé, usage d'équipe, usage département, usage généralisé.

Le croisement de ces trois dimensions produit un score d'exposition global qui permet de prioriser les actions : les usages à risque élevé et étendue large sont traités en premier, les usages à risque faible et isolés peuvent être tolérés temporairement en attendant leur validation officielle.

Phase 2 — Politique Shadow AI : poser le cadre juridique et organisationnel

La politique Shadow AI est le document fondateur du programme. Elle ne se substitue pas à la PSSI mais la complète et la précise sur le périmètre spécifique de l'intelligence artificielle. Elle doit être validée par la direction générale, la DRH et le DPO, puis intégrée à la charte informatique.

Que couvre la politique Shadow AI

La politique doit définir clairement : la définition opérationnelle du Shadow AI dans le contexte de l'entreprise, le périmètre d'application (tous les collaborateurs, tous les appareils y compris BYOD), la liste des catégories d'outils concernés (IA génératives, assistants de code, outils d'automatisation, plugins IA dans les suites bureautiques), les responsabilités de chaque acteur (RSSI, DPO, managers, utilisateurs), les procédures de demande d'autorisation d'un nouvel outil, les sanctions applicables en cas de violation, et les modalités de révision annuelle de la politique.

Un lien explicite doit être établi avec la PSSI de l'organisation pour assurer la cohérence du corpus documentaire. La politique Shadow AI doit référencer les articles pertinents de la PSSI (classification des données, gestion des tiers, incidents) et inversement.

La charte informatique et le contrat de travail

La politique Shadow AI doit être annexée à la charte informatique et portée à la connaissance de chaque collaborateur, avec accusé de réception. Pour les nouveaux embauchés, elle fait partie des documents remis à la signature lors de l'onboarding. Sans cette formalisation, les sanctions disciplinaires en cas de violation seraient juridiquement fragiles.

Le comité IA : gouvernance formalisée

La gouvernance opérationnelle du programme repose sur un comité IA dont la composition et le fonctionnement doivent être définis dans la politique :

• Membres permanents : RSSI (président), DPO, DSI, représentant DRH, représentant Direction Générale.
• Membres invités selon l'ordre du jour : juriste, CISO tiers, représentants métiers concernés par les demandes de validation.
• Fréquence : réunion mensuelle en régime de croisière, bimensuelle lors du déploiement initial.
• RACI : le comité IA est Responsable de la validation des outils, Accountable devant la direction, Consulté pour les cas limites, Informé de tous les incidents Shadow AI.

Phase 3 — Catalogue d'outils IA approuvés : le processus de validation

Le catalogue d'outils approuvés est la pièce centrale du programme. Sans lui, la politique ne peut pas fonctionner : interdire sans proposer d'alternative crée de la frustration et de la résistance, ce qui amplifie le Shadow AI au lieu de le réduire.

Le processus de validation en 4 étapes

Toute demande d'ajout d'un outil IA au catalogue suit un processus formalisé en quatre étapes :

1. Instruction technique : la DSI analyse l'architecture de l'outil (modes d'authentification, API exposées, localisation des données, politique de rétention, certifications de sécurité).
2. Instruction juridique et RGPD : le DPO vérifie la base légale du traitement, les clauses contractuelles types (CCT) ou les mécanismes de transfert vers les pays tiers, la conformité AI Act (catégorie de risque de l'outil), et l'existence d'un DPA (Data Processing Agreement) signable.
3. Instruction AI Act : classification de l'usage prévu selon les catégories de l'AI Act (risque inacceptable, risque élevé, risque limité, risque minimal) et vérification des obligations de transparence applicables.
4. Décision du comité IA : approbation, approbation conditionnelle (avec restrictions d'usage ou de données), ou refus motivé.

Grille d'évaluation des outils IA

Un outil scoring 0 sur l'un des critères est automatiquement refusé. Le score minimum pour approbation est de 11/21. Un score entre 8 et 10 peut donner lieu à une approbation conditionnelle avec restrictions d'usage.

Exemples d'outils approuvés vs refusés

Pour illustrer le fonctionnement du catalogue, voici des exemples concrets de décisions :

• ChatGPT Enterprise vs ChatGPT gratuit : ChatGPT Enterprise propose un DPA, des garanties zero data retention, une intégration SSO et des logs d'audit — approuvé pour les usages non confidentiels. Le ChatGPT gratuit ou Plus entraîne ses modèles sur les conversations par défaut et ne propose pas de DPA — refusé pour tout usage professionnel.
• Microsoft Copilot for M365 vs Copilot personnel : la version M365 traite les données dans le tenant Azure de l'entreprise, sous les termes du DPA Microsoft Enterprise existant — approuvé. La version personnelle (copilot.microsoft.com) utilise un compte personnel et des conditions grand public — refusé.
• Claude.ai Team/Enterprise vs Claude.ai gratuit : la version Team ou Enterprise d'Anthropic propose un DPA, une politique de non-entraînement sur les données, et un hébergement aux États-Unis couvert par des CCT — approuvé conditionnel. La version gratuite ne propose pas de DPA — refusé pour les données internes.

Ce catalogue doit être publié sur l'intranet et mis à jour à chaque décision du comité IA. La transparence sur les motifs de refus est essentielle pour que les collaborateurs comprennent la logique et ne contournent pas les règles par frustration.

Phase 4 — Architecture de détection : stack recommandée par taille d'entreprise

La détection technique est le volet opérationnel qui permet de vérifier que la politique est effectivement respectée. Le guide de détection Shadow AI développe en détail les méthodes DNS, CASB et proxy. Cette section propose une synthèse orientée budget et taille d'entreprise, pour aider le RSSI à choisir la stack adaptée à sa maturité et ses ressources.

Quel que soit le niveau, la détection ne doit pas être présentée aux collaborateurs comme de la surveillance, mais comme une mesure de protection de l'entreprise et des individus eux-mêmes — les responsabilités personnelles en cas de fuite de données via Shadow AI sont réelles.

Phase 5 — Formation et culture IA responsable : le levier humain

La formation est le facteur de succès le plus sous-estimé du programme. Un collaborateur qui comprend pourquoi certains outils sont refusés et comment utiliser les alternatives approuvées n'a pas besoin d'être surveillé — il devient lui-même un acteur de la gouvernance.

Programme de sensibilisation Shadow AI

Le programme de sensibilisation des collaborateurs à la cybersécurité doit intégrer un module spécifique Shadow AI. Ce module couvre : ce qu'est le Shadow AI et pourquoi il représente un risque, les types de données qui ne doivent jamais être soumis à un outil IA non approuvé (données clients, données personnelles, données contractuelles, secrets d'affaires, code source propriétaire), comment accéder au catalogue des outils approuvés et comment soumettre une demande pour un nouvel outil, les conséquences juridiques personnelles d'une fuite de données causée par un usage Shadow AI.

La formation doit être proposée en trois formats pour maximiser la couverture :

• Module e-learning de 20 minutes (obligatoire, suivi dans le LMS, renouvellement annuel)
• Session présentielle de 90 minutes pour les équipes à fort usage IA (développeurs, équipes marketing, RH)
• Capsule de rappel mensuelle de 5 minutes intégrée à la newsletter interne (actualités réglementaires, nouveaux outils au catalogue)

La simulation Shadow AI : exercice de sensibilisation avancé

Sur le modèle des campagnes de phishing simulé, le RSSI peut organiser des simulations Shadow AI : un faux outil IA non approuvé est rendu accessible depuis les postes de travail (par exemple via un lien dans un email interne). Les collaborateurs qui l'utilisent reçoivent immédiatement un message d'information expliquant pourquoi cet outil était un test et quels risques ils auraient courus. Cette approche, conduite en accord avec les RH et les représentants du personnel, est très efficace pour ancrer les bons réflexes sans être punitive.

Métriques d'adoption des outils approuvés

Le succès de la phase formation se mesure par l'évolution de trois indicateurs clés : le taux d'adoption des outils IA du catalogue (nombre d'utilisateurs actifs sur les outils approuvés vs total collaborateurs), la réduction du nombre de domaines IA non approuvés détectés dans les logs, et le taux de complétion du module e-learning. Ces métriques doivent être reportées au comité IA lors de chaque réunion mensuelle.

AI Act et conformité : les obligations concrètes pour le RSSI

L'AI Act européen (règlement UE 2024/1689) crée des obligations directes pour les organisations qui déploient des systèmes d'IA, y compris via des outils SaaS tiers. Le Shadow AI rend ces obligations particulièrement complexes à respecter.

Article 4 — AI Literacy : obligation de formation

L'article 4 de l'AI Act impose aux organisations de veiller à ce que leurs employés disposent d'un niveau suffisant de culture IA (AI Literacy) pour utiliser les systèmes d'IA de manière appropriée. Cette obligation s'applique dès qu'un outil IA est déployé dans l'organisation — y compris les outils du catalogue approuvé. Le RSSI doit documenter le programme de formation IA et être en mesure de prouver que les collaborateurs exposés aux outils IA ont reçu une formation adaptée. Source : règlement UE 2024/1689 sur l'IA (AI Act).

Article 28 — Obligations du déployeur

L'article 28 de l'AI Act définit les obligations des déployeurs de systèmes d'IA — c'est-à-dire toute organisation qui utilise un système d'IA à finalité professionnelle. Les obligations principales incluent : utiliser les systèmes d'IA conformément aux instructions du fournisseur, veiller à ce que les données d'entrée sont pertinentes pour l'usage déclaré, surveiller le fonctionnement des systèmes et signaler les incidents graves, et conserver une documentation des usages des systèmes d'IA à risque élevé. Le Shadow AI empêche structurellement de respecter ces obligations, puisqu'un outil non sanctionné n'est par définition pas documenté ni supervisé.

Registre IA interne

Le RSSI doit mettre en place un registre des usages IA interne, analogue au registre des traitements RGPD. Ce registre recense pour chaque outil IA approuvé : le nom et la version du système, le fournisseur, la catégorie de risque AI Act, les données traitées, les usages autorisés et les restrictions, la base légale RGPD applicable, et le responsable de l'usage côté métier. Ce registre est l'outil principal de preuve de conformité lors d'un contrôle CNIL ou d'un audit AI Act.

DORA et le secteur financier

Pour les organisations du secteur financier, le règlement DORA (Digital Operational Resilience Act, règlement UE 2022/2554) ajoute une couche d'exigences. Les outils IA tiers utilisés dans des processus opérationnels critiques entrent dans le périmètre de la gestion des risques liés aux tiers ICT. Le RSSI d'une banque ou d'une compagnie d'assurance doit donc s'assurer que les fournisseurs d'outils IA approuvés font l'objet d'une évaluation de risque tiers DORA et, pour les fournisseurs critiques, d'une notification à l'autorité de supervision compétente.

RGPD et Shadow AI : responsabilités et risques de sanctions

Le cadre RGPD s'applique pleinement au Shadow AI, avec des implications souvent méconnues des collaborateurs et parfois sous-estimées des directions.

Responsabilité du responsable de traitement

Lorsqu'un collaborateur soumet des données personnelles (données clients, données RH, données de patients) à un outil IA non approuvé, cet acte constitue un traitement de données personnelles réalisé sous la responsabilité de l'organisation employeur. Le fait que l'employé ait agi de sa propre initiative ne décharge pas l'organisation de sa responsabilité de responsable de traitement. C'est l'organisation — et non l'employé individuel — qui risque une sanction CNIL. L'ANSSI rappelle dans ses guides sur la maîtrise des risques liés à l'IA que les organisations doivent mettre en place des mesures organisationnelles et techniques pour prévenir ces usages non autorisés.

Obligation de notification en cas de fuite

Si des données personnelles sont transmises à un outil IA non approuvé et que cela constitue une violation de données (accès non autorisé, divulgation à un tiers non prévu, perte de confidentialité), l'organisation est soumise à l'obligation de notification CNIL dans les 72 heures suivant la prise de connaissance de l'incident (article 33 du RGPD). La CNIL a précisé dans ses recommandations 2025 que le transfert de données personnelles vers un service IA tiers sans base légale ni DPA constitue bien une violation de données notifiable. Plus d'informations sur la position de la CNIL sur l'intelligence artificielle.

Jurisprudence CNIL 2025

En 2025, la CNIL a sanctionné plusieurs organisations pour des violations liées à des usages IA non maîtrisés. Les motifs les plus fréquents sont : absence de base légale pour le transfert de données hors UE via un outil IA, absence de DPA avec le fournisseur d'IA, et défaut d'information des personnes concernées sur le traitement de leurs données par un système IA. Ces décisions établissent clairement que l'ignorance de la direction concernant l'usage d'outils IA par les collaborateurs n'est pas une circonstance atténuante — elle est au contraire retenue comme un défaut de gouvernance.

Cas pratiques sectoriels : risques et mesures adaptées

Ces exemples illustrent que les risques sectoriels nécessitent des adaptations de la politique générale. Le RSSI doit travailler avec les responsables de chaque département pour identifier les flux de données spécifiques qui ne doivent jamais transiter par un outil IA non approuvé, et s'assurer que ces restrictions sont comprises et acceptées.

Modèle de maturité Shadow AI : se situer et progresser

Le modèle de maturité Shadow AI à cinq niveaux permet au RSSI de situer son organisation sur un continuum de gouvernance et de définir les priorités d'action. Il s'inspire du CMMI (Capability Maturity Model Integration) et des frameworks de maturité RSSI.

Niveau 1 — Initial (Shadow AI non détecté) : L'organisation n'a pas conscience de l'étendue des usages Shadow AI. Aucune politique spécifique n'existe. Les incidents liés au Shadow AI, s'ils surviennent, ne sont pas reconnus comme tels. Actions prioritaires : lancer l'audit d'exposition, sensibiliser la direction.

Niveau 2 — Conscient (Shadow AI inventorié) : L'organisation a réalisé un audit et dispose d'une image de ses usages Shadow AI. Une alerte a été donnée à la direction. Aucune politique formelle n'existe encore mais les équipes IT ont commencé à surveiller les logs. Actions prioritaires : rédiger la politique Shadow AI, initier le catalogue, former le comité IA.

Niveau 3 — Structuré (politique et catalogue en place) : La politique Shadow AI est validée et communiquée. Un catalogue d'outils approuvés existe et est maintenu. La formation initiale des collaborateurs a été réalisée. La détection technique est opérationnelle mais non temps réel. Actions prioritaires : améliorer la couverture de détection, systématiser les métriques, conduire les premières simulations Shadow AI.

Niveau 4 — Géré (contrôlé et mesuré) : Le programme est pleinement opérationnel. La détection est automatisée avec alertes temps réel. Les métriques sont suivies par le comité IA. Le registre IA interne est à jour. Les incidents Shadow AI sont traités selon un processus formalisé. La conformité AI Act et RGPD est documentée. Actions prioritaires : optimiser les processus, étendre la couverture aux filiales et sous-traitants, préparer les audits de conformité.

Niveau 5 — Optimisé (gouvernance IA mature) : La gouvernance Shadow AI est intégrée dans la gouvernance IA globale de l'organisation. Les collaborateurs sont de véritables ambassadeurs de l'IA responsable. Le programme fait l'objet d'une amélioration continue basée sur les incidents, les évolutions réglementaires et les nouvelles technologies. L'organisation est capable de gérer proactivement les nouveaux risques IA avant qu'ils ne se matérialisent. Actions prioritaires : partager les bonnes pratiques avec l'écosystème, contribuer aux travaux sectoriels de normalisation, anticiper les évolutions de l'AI Act.

Intégration dans la stratégie RSSI externalisé ou interne

La question de savoir qui pilote ce programme — un RSSI interne ou un RSSI externalisé — influence son déploiement mais pas sa structure. Un RSSI externalisé peut très efficacement piloter le programme Shadow AI pour des PME ou ETI, en apportant à la fois la méthodologie et l'expérience de cas similaires. La clé est de disposer d'un relais interne (correspondant RSSI, DPO, ou responsable IT) qui assure la continuité opérationnelle entre les interventions. Les outils de détection doivent dans ce cas être accessibles au RSSI externalisé via des tableaux de bord SaaS ou des exports SIEM, sans nécessiter une présence permanente sur site.

Pour les organisations soumises à NIS 2, le programme Shadow AI s'inscrit dans le cadre plus large des obligations NIS 2, notamment les mesures de gestion des risques liés aux tiers et la politique de sécurité des systèmes d'information et de communication. Les organisations concernées doivent s'assurer que le Shadow AI est explicitement adressé dans leur plan de mise en conformité NIS 2.

Indicateurs de pilotage du programme (KPI Shadow AI)

Un programme sans indicateurs ne peut pas être piloté. Le comité IA doit suivre mensuellement un tableau de bord comprenant :

• Taux de couverture catalogue : pourcentage des usages IA identifiés couverts par le catalogue (objectif : 90 % à 12 mois).
• Nombre de nouveaux domaines IA détectés par mois hors liste blanche (tendance décroissante attendue).
• Délai moyen de validation d'un outil IA soumis au processus (objectif : moins de 15 jours ouvrés).
• Taux de complétion du module e-learning Shadow AI (objectif : 95 % à 6 mois).
• Nombre d'incidents Shadow AI traités par trimestre (fuite de données confirmée ou suspectée via outil non approuvé).
• Score de maturité Shadow AI (auto-évaluation semestrielle selon le modèle à 5 niveaux).

Ces indicateurs permettent de rendre compte de l'avancement du programme à la direction générale et au conseil d'administration, de justifier les investissements et d'identifier les axes d'amélioration. Pour les organisations soumises à des audits de conformité (ISO 27001, NIS 2, AI Act), ils constituent également des éléments de preuve précieux. Le lien avec les pipelines MLOps conformes ISO 27001 et les audits des copilotes IA complète le tableau de bord global de la gouvernance IA.

Foire aux questions sur le programme de gouvernance Shadow AI

Quelle est la différence entre Shadow IT et Shadow AI ?

Le Shadow IT désigne tout logiciel, service ou infrastructure utilisé sans l'accord de la DSI. Le Shadow AI est un sous-ensemble du Shadow IT qui concerne spécifiquement les outils d'intelligence artificielle — assistants génératifs, outils de code, plateformes de traitement automatique du langage naturel. Le Shadow AI présente des risques supplémentaires par rapport au Shadow IT classique : les outils IA collectent activement les données soumises, les modèles peuvent apprendre de ces données, et la capacité d'exfiltration involontaire d'informations confidentielles est bien plus grande qu'avec un simple SaaS de gestion de projet. C'est pourquoi le Shadow AI mérite une gouvernance spécifique, au-delà de la gestion du Shadow IT traditionnelle.

Le RSSI peut-il interdire totalement l'IA générative en entreprise ?

Techniquement, le blocage total de tous les services IA au niveau réseau est possible mais très difficile à maintenir dans le temps — les outils IA se multiplient et les interfaces d'accès se diversifient (extensions navigateur, plugins dans des suites SaaS déjà approuvées, API directes). Stratégiquement, une interdiction totale est contre-productive : elle génère de la frustration, pousse les usages vers des canaux encore moins détectables (usage sur mobile personnel), et prive l'organisation d'un gain de productivité réel. La bonne approche est de canaliser plutôt qu'interdire : mettre à disposition des outils approuvés répondant aux besoins légitimes, tout en bloquant les usages clairement inadaptés (outils sans DPA pour les données sensibles). L'interdiction totale peut toutefois être une mesure temporaire pendant la phase d'audit initial, avant que le catalogue ne soit opérationnel.

Comment mesurer le ROI d'un programme de gouvernance Shadow AI ?

Le retour sur investissement d'un programme de gouvernance Shadow AI se calcule en comparant le coût du programme (audit, outils de détection, formation, temps RSSI et DPO) au coût évité des incidents. Une fuite de données via Shadow AI implique : coût de notification CNIL (72h de travail d'équipe au minimum), coût potentiel de sanction (jusqu'à 4 % du chiffre d'affaires mondial pour une violation RGPD grave), coût de réputation (perte clients, coût de communication de crise), et coût opérationnel (investigation, remédiation). Un seul incident sérieux suffit généralement à justifier plusieurs années de programme. Les gains de productivité liés à la mise à disposition d'outils IA approuvés — que les collaborateurs n'auraient pas eu sinon — peuvent également être comptabilisés comme bénéfice indirect du programme.

Quelles sanctions RGPD pour une fuite via Shadow AI ?

Les sanctions RGPD applicables en cas de fuite de données provoquée par un usage Shadow AI dépendent de la nature des données exposées et du manquement constaté. Pour une violation de l'article 28 (absence de DPA avec le sous-traitant IA), la CNIL peut prononcer un avertissement pour un premier manquement, une mise en demeure avec délai de mise en conformité, ou une amende administrative pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial annuel. Pour une violation plus grave impliquant des données sensibles (santé, données bancaires) ou un défaut de notification, l'amende peut atteindre 20 millions d'euros ou 4 % du chiffre d'affaires. En 2025, la CNIL a explicitement conditionné l'appréciation de la gravité au fait que l'organisation avait ou non mis en place des mesures préventives — un programme de gouvernance Shadow AI documenté constitue une circonstance atténuante significative.

Comment traiter un employé qui refuse d'utiliser les outils IA approuvés ?

Le refus d'utiliser les outils IA approuvés n'est pas une faute disciplinaire en soi — un collaborateur n'a pas d'obligation d'utiliser des outils d'IA, et certains peuvent avoir des réserves légitimes (éthiques, pratiques, ou liées à la nature de leur mission). La question se pose différemment si le collaborateur continue d'utiliser des outils non approuvés après avoir été informé de la politique. Dans ce cas, selon le degré de gravité de l'infraction (données concernées, fréquence, préjudice potentiel), la réponse RH peut aller d'un entretien de recadrage à une procédure disciplinaire, en passant par une nouvelle formation. La politique Shadow AI doit prévoir explicitement ces cas et les sanctions associées, avec validation par les RH et les représentants du personnel pour assurer leur légitimité juridique.

Conclusion : le RSSI comme architecte de la gouvernance IA

Le programme de gouvernance Shadow AI n'est pas un projet ponctuel mais un programme permanent, qui évolue avec les usages, la réglementation et les technologies. En 2026, le RSSI qui n'a pas encore lancé ce programme prend un risque croissant : le risque réglementaire (AI Act, RGPD, NIS 2, DORA), le risque de sécurité (exfiltration de données, compromission via des vulnérabilités de type jailbreak et injection de prompts), et le risque stratégique (perte de contrôle sur les actifs immatériels de l'organisation). La bonne nouvelle est que ce programme, bien construit et bien communiqué, peut devenir un vecteur de confiance plutôt qu'un frein : en dotant l'organisation d'un catalogue d'outils IA validés, le RSSI permet à ses collègues de bénéficier des gains de productivité de l'IA de manière responsable, ce qui transforme la gouvernance en avantage compétitif.