# Exploiter Microsoft 365 en conformité avec la protection des données en Suisse > Exploiter Microsoft 365 conformément à la protection des données : cadre légal, EU Data Boundary, chiffrement, étiquettes, journaux et configuration. - Source: https://www.sidd.swiss/fr/perspectives/exploiter-microsoft-365-en-conformite-avec-la-protection-des-donnees-en-suisse/ - Langue: fr-CH - Publié: 2026-05-24 - Mise à jour: 2026-05-24 - Auteur·e: Oliver Stutz - Éditeur: SIDD Institut pour la protection des données et la sécurité des données, une marque de Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Suisse ## Introduction Microsoft 365 est de loin l'écosystème bureautique le plus répandu en Suisse – de la PME de deux personnes à l'hôpital cantonal. Du point de vue de la protection des données, la plateforme est cependant tout sauf un produit prêt à l'emploi bien configuré. C'est un ensemble modulaire comprenant des dizaines de services (Exchange Online, SharePoint, OneDrive, Teams, Purview, Defender, Copilot), avec des promesses de résidence des données changeantes et une structure de groupe (Microsoft Corporation, Microsoft Ireland Operations Ltd., divers sous-traitants ultérieurs) qui fait de chaque *évaluation de l'impact du transfert* (TIA) un exercice à part entière. Cet article présente : - quelles bases juridiques de la LPD et du RGPD sont impératives pour M365 ; - ce que promet l'**EU Data Boundary** et quelles sont ses limites ; - quelles configurations de sécurité et de protection des données chaque tenant M365 en Suisse devrait au minimum mettre en place ; - comment *Customer Key*, *Double Key Encryption* et les *étiquettes de sensibilité* interagissent ; - quels aspects des journaux d'audit et de la rétention sont critiques pour les obligations d'accès et d'effacement ; - et à quoi ressemble une configuration de référence pratique pour les entreprises suisses. Références légales : LPD (notamment art. 6, 8, 9, 16, 22, 24), RGPD (notamment art. 28, 32, 44 ss.), Schrems II (CJUE C-311/18), Cadre de protection des données UE-États-Unis, Microsoft Products and Services DPA, circulaire FINMA 2018/3 « Externalisation » pour les établissements régulés. ## Cadre juridique – LPD, RGPD et Schrems II Lorsqu'une entreprise suisse utilise Microsoft 365, Microsoft devient le **sous-traitant** au sens de l'art. 9 LPD et – dans la mesure où le RGPD s'applique – de l'art. 28 RGPD. La base contractuelle est fournie par le Microsoft Products and Services Data Protection Addendum (DPA), qui intègre les clauses contractuelles types (SCC UE Module 2) et l'annexe suisse. Trois points sont critiques dans la pratique : 1. **Responsabilité :** En tant que client, vous restez responsable du traitement et portez l'entière charge de la preuve d'un traitement conforme à la loi – même si Microsoft fournit la plateforme technique en tant que fournisseur cloud. 2. **Transfert transfrontalier :** Après Schrems II, la seule conclusion de SCC ne suffit pas si les autorités américaines peuvent accéder aux données (FISA 702, CLOUD Act). Vous devez maintenir une évaluation documentée de l'impact du transfert – même si les données résident principalement dans des centres de données de l'UE. 3. **Traitements secondaires :** Microsoft traite des données de diagnostic et de télémétrie pour améliorer ses services. Microsoft agit ici en tant que **responsable du traitement à titre propre** – un fait que le PFPDT et les autorités de protection des données de l'UE ont critiqué à plusieurs reprises. Vous devez refléter ces traitements secondaires dans votre déclaration de protection des données et votre registre des activités de traitement. Pour les établissements réglementés par la FINMA, la logique d'externalisation supplémentaire selon la circ. 2018/3 s'ajoute : analyse des risques, droits d'audit, plan de sortie et obligations de notification à la FINMA doivent être documentés séparément. ## EU Data Boundary – promesses et limites Avec l'**EU Data Boundary**, Microsoft a depuis 2024 entièrement transféré le stockage et le traitement des principaux services de base (Microsoft 365, Dynamics 365, Power Platform, Azure) pour les clients UE et AELE vers des centres de données situés dans l'UE/AELE. Pour la Suisse, cela signifie : les charges de travail standard telles que Exchange Online, SharePoint, OneDrive et Teams sont stockées et traitées dans des centres de données de l'UE (p. ex. Dublin, Amsterdam, Francfort, Zurich), y compris les données de diagnostic et les données générées automatiquement par le service. Restrictions importantes que vous devez connaître : - L'EU Data Boundary ne couvre pas tous les services. Certaines fonctionnalités (p. ex. la protection globale contre le spam et les logiciels malveillants dans Exchange Online Protection, les jetons d'authentification via Entra ID Global, certaines fonctionnalités IA comme Microsoft 365 Copilot) peuvent continuer à être traitées à l'échelle mondiale. - En cas d'escalade d'un ticket de support Microsoft, des données peuvent être transmises à des équipes d'ingénierie situées hors de l'UE, pour autant que vous consentiez à l'escalade du support. - Les sociétés du groupe Microsoft hors UE restent juridiquement liées par le DPA – ce qui protège contractuellement, mais ne change rien à la possibilité théorique d'accès en vertu du CLOUD Act. La région des centres de données suisses (Switzerland North/West) est une option attrayante pour de nombreuses PME, car les données résident principalement en Suisse. Pour Microsoft 365, cette région n'est toutefois pas disponible pour tous les services, et Microsoft Ireland Operations Ltd. reste ici aussi le sous-traitant contractuel. ## Chiffrement et Customer Key M365 chiffre les données par défaut au repos (BitLocker, Service Encryption) et en transit (TLS 1.2+). La question critique pour les entreprises suisses ayant des exigences de confidentialité accrues est : **qui détient les clés ?** 1. **Clés gérées par Microsoft :** Option par défaut. Microsoft gère les clés, vous n'avez pas de levier technique pour bloquer un accès des autorités. 2. **Customer Key :** Vous générez et gérez les clés de chiffrement dans Azure Key Vault (ou Azure Managed HSM). Microsoft a besoin des clés pour déchiffrer en cours d'exploitation, mais vous pouvez révoquer les clés et ainsi priver Microsoft de l'accès aux données. Prérequis : Microsoft 365 E5 ou la licence *Microsoft 365 E5 Compliance*. 3. **Double Key Encryption (DKE) :** Niveau de protection maximum. Les données sont chiffrées avec deux clés : une de Microsoft et une détenue localement par vous. Microsoft ne peut techniquement pas déchiffrer les données. En contrepartie, certaines fonctionnalités cloud (recherche, Copilot, eDiscovery) ne fonctionnent plus. Recommandation pour les PME suisses : chiffrement standard pour la plupart des données, Customer Key pour les dossiers RH et données personnelles sensibles, DKE uniquement pour les ensembles de données particulièrement sensibles (données de santé, casier judiciaire ou documents du conseil d'administration) – et cela avec une claire conscience des fonctionnalités que vous perdez ainsi. ## Étiquettes de sensibilité et protection de l'information Microsoft Purview Information Protection (anciennement Azure Information Protection) propose des **étiquettes de sensibilité** permettant de classifier et protéger automatiquement des documents et des courriels. Un schéma d'étiquettes bien maintenu est l'épine dorsale de toute architecture de protection des données M365. Hiérarchie typique d'étiquettes pour les entreprises suisses : - **Public** – aucune restriction. - **Interne** – uniquement les collaborateurs, pas de tiers externes. - **Confidentiel** – uniquement un cercle de personnes défini, chiffrement AIP, pas de téléchargement sur les appareils privés. - **Strictement confidentiel / données particulièrement sensibles** (art. 5 let. c LPD) – AIP plus Customer Key ou DKE, filigrane, accès uniquement via un poste de travail de conformité. Les étiquettes peuvent être attribuées automatiquement avec des **politiques d'étiquetage automatique**, p. ex. lorsqu'un document contient des numéros AVS, des données de cartes de crédit ou des codes de diagnostic (CIM-10). Cette classification automatique est aujourd'hui généralement une condition préalable au bon fonctionnement des politiques DLP (prévention des pertes de données). Séquence pragmatique pour l'introduction : d'abord rendre les étiquettes prêtes au déploiement, puis former à la classification manuelle, puis activer l'étiquetage automatique en mode audit, puis après 4 à 6 semaines de réglage passer en mode d'application et activer en parallèle les règles DLP. ## Journaux d'audit, rétention et droits des personnes concernées Les obligations d'accès (art. 25 LPD / art. 15 RGPD), de rectification (art. 32 LPD / art. 16 RGPD) et d'effacement (art. 32 al. 2 let. c LPD / art. 17 RGPD) ne sont pas triviales dans M365. Les données sont réparties entre Exchange, SharePoint, OneDrive, chats Teams, Yammer/Viva Engage, Planner, To Do et dans les versions de sauvegarde. **Journaux d'audit :** Activez le *journal d'audit unifié* dans Purview dès le premier jour. La conservation standard est de 180 jours (E3) ou un an (E5) ; pour les secteurs réglementés, une conservation de 10 ans peut être souscrite. Les journaux sont une condition préalable à la criminalistique en cas de violation de données selon l'art. 24 LPD (délai de 72 heures dès la connaissance d'une violation à risque élevé). **Politiques de rétention :** Définissez des règles de conservation par catégorie de données. Pour les dossiers RH, typiquement 10 ans après le départ, pour les courriels professionnels généraux 5 à 7 ans, pour les contacts marketing 2 à 3 ans. Sans politique de rétention, le standard Microsoft de *durée indéfinie* s'applique – ce qui est problématique du point de vue de la protection des données. **eDiscovery vs. LPD :** Les recherches eDiscovery peuvent accéder à d'importants ensembles de données personnelles. Vous avez besoin d'un principe des quatre yeux interne, d'une base juridique documentée et – si des collaborateurs sont concernés – d'une information préalable selon l'art. 19 LPD, dans la mesure où cela ne compromet pas l'enquête. ## Configuration de référence pour la Suisse Nous recommandons à chaque tenant M365 suisse un minimum de référence : 1. **Identité :** Entra ID avec MFA pour tous les utilisateurs (accès conditionnel), MFA résistante au phishing (FIDO2, Windows Hello) pour les administrateurs. Privileged Identity Management pour les rôles éligibles. 2. **Résidence des données :** Région *Switzerland North* ou *Europe* lors de la mise en service du tenant. Un changement ultérieur n'est pas possible. 3. **Chiffrement :** Customer Key pour Exchange, SharePoint, OneDrive (licence E5 requise) pour les charges de travail sensibles. 4. **Protection de l'information :** Étiquettes de sensibilité avec étiquetage automatique pour les données personnelles particulièrement sensibles (art. 5 let. c LPD). 5. **DLP :** Microsoft Purview DLP pour Exchange, Teams, SharePoint – ensembles de règles pour les numéros AVS, IBAN, cartes de crédit, codes de diagnostic. 6. **Audit et rétention :** Journal d'audit unifié activé, politiques de rétention par catégorie de données, stratégie de sauvegarde avec procédure d'effacement explicite. 7. **Copilot :** Avant le déploiement – réaliser une AIPD, clarifier le cadre des données (quelles données Copilot peut voir, lesquelles non), les étiquettes de sensibilité sont un prérequis. Mode audit d'abord. 8. **Applications tierces :** Activer la gouvernance des applications via Entra ID, définir le consentement OAuth par les utilisateurs sur approbation administrative, effectuer des révisions régulières. Cette configuration de référence n'est pas une fin en soi, mais est directement déductible des obligations de preuve des art. 8 et 22 LPD ainsi que des art. 24, 25, 32 RGPD. Quiconque la met en place correctement dispose d'un niveau de conformité défendable en cas de contrôle. ## Comment SIDD vous accompagne SIDD accompagne les entreprises suisses, ONG et unités administratives lors de l'introduction et de l'exploitation de Microsoft 365 en conformité avec la protection des données. Nous combinons l'expertise juridique (LPD/RGPD/FINMA circ. 2018/3) avec une profondeur technique dans Entra ID, Purview, Defender et Copilot. Mandats types : - Analyse d'impact sur la protection des données (AIPD) avant le déploiement de M365 ou avant l'introduction de Copilot ; - Établissement de l'accord de sous-traitance et de la documentation TIA ; - Révision de la configuration du tenant par rapport à notre référence SIDD ; - Mandats en tant que [conseiller externe en protection des données](https://www.sidd.swiss/fr/services/conseiller-protection-donnees-suisse) ou [RSSI/RSI externe](https://www.sidd.swiss/fr/services/ciso-externe) ; - Accompagnement ISO/IEC 27001 dans lequel M365 est couvert comme plateforme principale ([ISO 27001 / SMSI](https://www.sidd.swiss/fr/services/iso-27001-smsi)) ; - Tests de pénétration et simulations de phishing contre M365 ([test de pénétration](https://www.sidd.swiss/fr/services/test-intrusion)) ; - Ateliers de sensibilisation pour les collaborateurs et les administrateurs ([atelier de sécurité informatique](https://www.sidd.swiss/fr/services/atelier-securite-informatique-pme)). Écrivez-nous via le [formulaire de contact](https://www.sidd.swiss/fr/contact) ou demandez une offre via le [formulaire d'offre](https://www.sidd.swiss/fr/devis). Nous livrons un premier diagnostic du tenant dans les 5 jours ouvrables. --- Ce document est la version Markdown de la page liée ci-dessus. Merci de citer l'URL HTML.