Guide complet de gouvernance du Shadow AI en environnement Microsoft 365 Business Premium pour PME suisses : MDCA, Purview DLP, DSPM for AI, Insider Risk Management, DLP inline Edge for Business. Conformité nLPD.
View the Project on GitHub doit4everyone/shadow-ai-governance-microsoft-365-nLPD
Le terme Shadow AI (ou IA fantôme) désigne l’utilisation non contrôlée et non autorisée d’outils d’intelligence artificielle par les collaborateurs d’une organisation, sans validation préalable du service informatique ni de la direction. Tout comme le « Shadow IT » désignait l’utilisation non autorisée de logiciels ou services cloud, le Shadow AI représente la même problématique appliquée aux outils d’IA générative : ChatGPT, Claude.ai, Gemini, Midjourney, Perplexity, et des dizaines d’autres services accessibles depuis n’importe quel navigateur web.
Voici des situations réelles que vous pouvez rencontrer dans votre organisation :
🚫 IMPORTANT Dans tous ces cas, les données quittent le périmètre de sécurité de l’entreprise et sont traitées par un tiers sans aucun contrat de sous-traitance (art. 9 nLPD), potentiellement utilisées pour réentraîner les modèles d’IA (ce qui rend l’effacement inexécutable), sans information des personnes concernées et sans chiffrement garanti. Ces données sont en outre fréquemment transmises à des serveurs hors de Suisse. L’ordre importe : c’est l’absence de contrat et l’entraînement sur les données qui fondent l’illicéité, pas la seule localisation des serveurs.
Lorsqu’un collaborateur colle des données dans une IA externe ces données sont envoyées vers les serveurs du fournisseur de l’IA, généralement aux États-Unis ou dans d’autres pays hors Suisse. Le fournisseur peut :
Un point particulièrement important pour les équipes techniques : Purview seul ne peut pas bloquer les API appelées directement depuis du code ou des scripts. Voici pourquoi c’est dangereux :
Exemple concret : API non bloquée par Purview
Un développeur crée un script Python qui appelle directement l’API OpenAI (api.openai.com) depuis son poste de travail.
Il envoie automatiquement les fichiers du dossier /Projets vers GPT-4 pour analyse.
Purview voit cette activité comme du trafic réseau chiffré standard, il ne peut pas inspecter le contenu des appels HTTPS directs.
Les données sensibles quittent l’entreprise sans aucune alerte DLP.
=> C’est pourquoi MDCA (Microsoft Defender for Cloud Apps) est indispensable : il identifie et catégorise ces applications via Cloud Discovery. Le blocage effectif des appels API est ensuite appliqué par MDE Network Protection (section 1.3.5) sur la base de cette catégorisation : MDCA identifie, MDE bloque.
Les vecteurs d’exfiltration via API incluent :
La Suisse dispose depuis le 1er septembre 2023 de la nouvelle Loi fédérale sur la Protection des Données (nLPD), révisée pour s’aligner en grande partie sur le RGPD européen.
Une précision de cadrage, essentielle pour ne pas se tromper de combat : la violation ne réside pas d’abord dans la géographie des serveurs. Elle réside dans l’absence de contrat de sous-traitance, dans l’entraînement du modèle sur les données transmises, dans l’absence d’information des personnes concernées et dans la disproportion du traitement. Un serveur situé à Zurich, exploité sans contrat de sous-traitance, est tout aussi illicite qu’un serveur au Texas. Le transfert international (art. 16) est un problème réel, mais ce n’est ni le premier ni le plus grave.
Les articles concernés :
| Article nLPD | Risque lié au Shadow AI |
|---|---|
| Art. 5 let. c - Données sensibles | Les données de santé, biométriques, d’appartenance syndicale, religieuse ou politique envoyées à une IA externe constituent une violation grave. |
| Art. 6 - Finalité & Proportionnalité | Les données collectées pour un usage précis ne peuvent pas être réutilisées pour entraîner un modèle IA externe. |
| Art. 7 - Protection des données dès la conception et par défaut | La protection doit être intégrée dès la conception du traitement (by design) ET les préréglages doivent limiter le traitement au minimum requis par la finalité (by default). Un collaborateur utilisant une IA non validée contourne ces deux principes. |
| Art. 8 - Sécurité des données | L’obligation de mesures techniques et organisationnelles (MTO) est violée si des données peuvent librement quitter le périmètre sécurisé. |
| Art. 9 - Sous-traitance | L’article le plus directement violé par le Shadow AI. Confier un traitement à un sous-traitant suppose que la loi ou un contrat le prévoie. Un collaborateur qui colle un dossier RH dans une IA grand public crée un rapport de sous-traitance de fait, sans aucun contrat. Le traitement est illicite indépendamment de la localisation des serveurs. ⚠️ L’absence de contrat de sous-traitance est pénalement sanctionnée (art. 61 let. b nLPD, amende jusqu’à CHF 250’000.-). |
| Art. 16 - Communication de données personnelles à l’étranger | La licéité du transfert dépend de l’entité juridique destinataire, pas de la notoriété du fournisseur. → Fournisseurs établis dans l’UE/EEE ou au Royaume-Uni (ex. Mistral AI, société française) : ces pays figurent à l’annexe 1 OPDo (États à protection adéquate). Le Data Privacy Framework, cadre exclusivement américain, ne leur est pas applicable et l’art. 16 ne constitue pas ici l’obstacle. → Fournisseurs américains : le transfert requiert soit une certification active au titre du Swiss-U.S. Data Privacy Framework (reconnu par le Conseil fédéral le 14 août 2024, effet au 15 septembre 2024), soit des clauses contractuelles types (CCT). ⚠️ Trois pièges de vérification : (1) une certification EU-U.S. DPF ne s’étend pas automatiquement aux données suisses — l’entité doit avoir souscrit séparément à l’extension suisse ; (2) la certification s’apprécie entité par entité et par type de données (HR / Non-HR) ; (3) l’entité contractante pour les utilisateurs suisses n’est pas toujours l’entité américaine (ex. OpenAI Ireland Ltd). Vérification obligatoire sur dataprivacyframework.gov/list avant toute conclusion. |
| Art. 19 - Devoir d’informer | Les personnes concernées doivent être informées de la collecte et de ses finalités. Un collaborateur qui transmet des données clients à une IA externe rend cette information impossible : ni le client, ni l’employeur ne maîtrisent le traitement réel. Ce même article conditionne l’activation de la surveillance comportementale (IRM, Partie 5). |
| Art. 22 - Analyse d’impact (AIPD) | Un traitement susceptible d’engendrer un risque élevé impose une AIPD préalable. La loi vise notamment le traitement de données sensibles à grande échelle et le recours à de nouvelles technologies. Un usage IA non gouverné portant sur des données RH, médicales ou financières entre dans ce périmètre — et aucune AIPD n’a évidemment été conduite. |
| Art. 24 - Notification PFPDT | En cas de violation entraînant un risque élevé pour les personnes concernées, vous devez notifier le Préposé Fédéral dès que possible (art. 24 nLPD). Note : seules les violations à risque élevé nécessitent une notification PFPDT ; les violations de faible risque font l’objet d’une documentation interne uniquement. Sans journaux d’audit, vous ne pouvez pas reconstituer l’incident ni respecter cette obligation. |
| Art. 32 al. 2 - Effacement des données | La personne concernée peut exiger l’effacement ou la destruction de ses données. Cette obligation devient inexécutable dès lors que le fournisseur d’IA entraîne son modèle sur les données transmises : les poids du modèle ne sont pas effaçables sur demande. C’est l’argument le plus difficile à contrer contre l’usage des IA grand public en contexte professionnel. |
| Art. 62 nLPD + art. 321 CP + art. 47 LB - Secret professionnel | L’art. 62 nLPD (violation du devoir de discrétion, dit « petit secret professionnel ») prévoit une amende jusqu’à CHF 250’000.- ; c’est un délit poursuivi sur plainte. ⚠️ Mais pour les professions protégées (médecins, avocats, ecclésiastiques), le véritable couperet est l’art. 321 CP : peine privative de liberté jusqu’à 3 ans ou peine pécuniaire. Le secret bancaire relève quant à lui de l’art. 47 LB. Aucune décision d’adéquation ni certification DPF ne lève cette contrainte : le secret professionnel est une obligation distincte de la protection des données. |
nLPD SUISSE La violation de la nLPD peut entraîner des sanctions pénales allant jusqu’à CHF 250’000.- pour les personnes physiques responsables (art. 60-63 nLPD). L’amende s’applique à la personne physique (le responsable), Exception : l’art. 64 nLPD prévoit que l’entreprise peut être condamnée à payer une amende jusqu’à CHF 50’000.- si l’identification de la personne physique responsable exigerait des efforts disproportionnés. Le Préposé Fédéral à la Protection des Données et à la Transparence (PFPDT) dispose de pouvoirs d’enquête et de sanction renforcés depuis la révision de la loi.
Pour bloquer efficacement le Shadow AI, il faut agir sur deux niveaux complémentaires : Ce guide se concentre sur la couche MDCA (gouvernance du flux). La couche Purview (protection de la donnée — étiquettes, DLP, chiffrement RMS) est traitée dans le guide complémentaire Configuration_Microsoft_Purview_2026.docx — obligatoire uniquement si Purview n’a jamais été configuré dans votre organisation (Cas A, voir section 2.1). Plusieurs sections de ce guide y font référence sans en dupliquer le contenu.
| Couche | Rôle |
|---|---|
| Microsoft Defender for Cloud Apps (MDCA) | Surveille et contrôle le trafic réseau. Détecte les applications cloud non autorisées (dont les IA externes). Peut bloquer l’accès à des domaines ou des applications entières. Visible dans le portail Microsoft Defender. |
| Microsoft Purview | Protège les données elles-mêmes. Classe et étiquette les fichiers sensibles. Applique des règles DLP qui empêchent le partage de fichiers confidentiels. Audite toutes les activités. Surveille les interactions avec Copilot M365. |
Analogie simple pour comprendre
Imaginez votre entreprise comme un bâtiment sécurisé :
MDCA = le garde à l’entrée qui contrôle qui peut sortir et vers où.
Purview = les casiers à clé à l’intérieur qui protègent les documents sensibles.
Les deux sont nécessaires : un garde sans casiers laisse les documents accessibles à l’intérieur. Des casiers sans garde n’empêchent pas de copier le contenu avant de sortir.
🎯 À LIRE EN PREMIER - Périmètre réel de protection Correctement déployée avec Network Protection en mode Block, cette pile native Microsoft (Business Premium + extension Defender et Purview) traite efficacement les vecteurs où la donnée sort par le réseau : sites d’IA dans les navigateurs gérés, appels API directs, partage externe par email/SharePoint, appareils BYOD non conformes et flux Power Platform. Elle ne couvre pas totalement trois vecteurs, qui restent le risque résiduel principal : le copier-coller manuel de texte vers un outil IA autorisé ou non encore catalogué (l’usage le plus fréquent), le mobile (smartphones personnels hors MDE) et les SaaS tiers à IA native (Notion AI, Salesforce Einstein) dont le trafic passe par des canaux déjà approuvés. Ces vecteurs exigent des mesures complémentaires (Intune App Protection pour le mobile, sensibilisation, revue contractuelle), détaillées en section 9.7. Objectif réaliste : réduire fortement les fuites par les canaux réseau, documenter la surveillance pour la nLPD et identifier clairement ce qui reste ouvert. Ce guide ne prétend pas à une couverture totale du Shadow AI, et la section 9.7 énonce sans détour les angles morts.
Ce guide couvre la configuration complète des éléments suivants :
| Composant | Ce que vous allez configurer |
|---|---|
| MDCA - Discovery | Inventaire automatique de toutes les applications IA utilisées dans votre organisation. |
| MDCA - App Control | Blocage ou restriction des applications IA non approuvées. |
| MDCA - Policies | Alertes automatiques en cas d’utilisation d’une IA non autorisée. |
| Purview - Labels | Étiquettes de sensibilité sur vos documents (Public, Interne, Confidentiel, Secret). |
| Purview - DLP | Règles qui empêchent l’envoi de fichiers sensibles vers l’extérieur. |
| Purview - DSPM for AI | Surveillance spécifique des interactions IA (Copilot M365 inclus). |
| Conditional Access | Bloquer l’accès aux ressources M365 depuis les appareils non gérés (BYOD). Note : le CA ne peut pas bloquer les URLs publiques (chatgpt.com, etc.), utilisez MDCA + MDE Network Protection (sections 1.3.4-5) et Edge BlockList (section 6) pour cela. Note : le Web Content Filtering MDE (section 9.4) ne dispose pas de catégorie IA en mai 2026. |
| Endpoint DLP | Bloquer le copier-coller de données sensibles vers des applications non autorisées. |
Cette classification permet de comprendre quels profils sont couverts et lesquels représentent un risque résiduel. Elle sert de base pour prioriser les investissements complémentaires hors périmètre Microsoft.
| Profil | Description | Exemple PME suisse | Probabilité | Impact / Couverture guide |
|---|---|---|---|---|
| Opportuniste | Employé productif sans intention malveillante | Comptable colle un No. AVS dans Claude pour résumer | Élevée | Élevé : ✅ Couvert : DLP + MDCA non-sanctionné |
| Automatisé | Script ou pipeline CI/CD qui appelle une API IA | Développeur avec pipeline GitHub → api.openai.com | Moyenne | Élevé : ✅ Couvert : indicateurs MDE URL/API |
| Intégré | IA native dans un outil SaaS autorisé ou LLM local | Copilot Teams ou Ollama installé sur le laptop | Croissante | Très élevé : ⚠️ Partiel : SaaS natif = fuite possible ; LLM local = évasion (pas d’exfiltration) |
| Malveillant | Exfiltration délibérée via canal IA avant départ | Employé en partance reformulant des données via LLM local avant exfiltration par un canal personnel | Faible | Critique : ❌ Non couvert ; exfiltration via canal personnel (USB, webmail), le LLM local n’étant qu’une étape d’évasion |
⚠️ Le LLM local ne fait pas sortir de données du périmètre : ce n’est pas un vecteur d’exfiltration mais une surface d’évasion (reformuler une donnée sensible pour déjouer la DLP par contenu). Le vrai risque résiduel le plus élevé est l’insider malveillant qui exfiltre par un canal personnel (USB, webmail), à traiter par AppLocker/WDAC + surveillance comportementale MDE + politique RH.
Ce modèle mappe chaque couche de l’architecture IT aux menaces Shadow AI correspondantes et aux contrôles déployés dans ce guide. Il permet de prouver la couverture systémique et d’identifier les lacunes résiduelles. Note de lecture : cette architecture représente la couverture théorique cible ; la section 9.7 documente la couverture réelle avec les risques résiduels et l’efficacité estimée par vecteur.
| Couche | Menace Shadow AI | Contrôle déployé | Section | Statut |
|---|---|---|---|---|
| Utilisateur | Usage volontaire ou inconscient d’IA non validée | Communication nLPD + charte + sensibilisation | 9.5 | ⚠️ Partiel, dépend de l’adoption |
| Appareil | Apps IA installées localement (LLM, extensions) | MDE onboarding + Intune + Network Protection Block | 1.3, 1.3.5 | ✅ Windows gérés ❌ Mobile hors périmètre |
| Réseau | Trafic vers domaines IA externes | MDCA non-sanctionné + indicateurs MDE + URLBlocklist Edge | 1.5, 6.2, 6.3 | ✅ Couverture effective sur endpoints Windows gérés, sans contournement réseau (VPN, DNS externe, DoH) (Network Protection actif). Hors périmètre : iOS/Android |
| Application | Apps cloud IA non autorisées | MDCA Cloud Discovery + sanctionner/non-sanctionner + AutoBlock | 1.5, 1.6 | ✅ Couvert catalogue MDCA ❌ SaaS tiers hors catalogue |
| Données | Fuite de données sensibles (AVS, IBAN, santé) | DLP Purview + IRM + DSPM for AI + Endpoint DLP | 3, 4, 5 | ✅ Couvert sur appareils MDE ⚠️ Copier-coller résiduel |
| Comportement | Patterns anormaux non détectés | MDCA alertes + MDE Advanced Hunting + MDCA-DET policy | 1.7, 9.3 | ✅ Détection, réponse manuelle requise |
| ← Retour à l’index | Partie 0 — Avant de commencer → |