Microsoft Copilot a lu vos e-mails confidentiels pendant des semaines. Voici ce qui s’est passé et comment y remédier.

Pendant plusieurs semaines, Microsoft 365 Copilot a discrètement lu, résumé et mis en avant des e-mails que les organisations avaient explicitement classés comme confidentiels. Mémos juridiques. Accords commerciaux. Correspondance gouvernementale. Informations médicales protégées. Toutes traitées par une IA qui n’était jamais censée y accéder.

Points clés à retenir

1. Les contrôles d’IA au niveau applicatif constituent un point de défaillance unique. Les étiquettes de confidentialité et les règles DLP de Microsoft étaient intégrées à la même plateforme que Copilot. Lorsqu’une erreur de code est survenue, tous les contrôles ont échoué simultanément. Les organisations ne disposaient d’aucune couche de défense indépendante pour empêcher l’IA de traiter du contenu confidentiel – y compris des communications juridiques, des accords commerciaux et des informations médicales protégées.
2. Les organisations n’avaient aucune visibilité indépendante sur ce à quoi Copilot accédait. Du 21 janvier au début février 2026, Copilot a lu et résumé des e-mails confidentiels sans déclencher la moindre alerte indépendante. Les organisations n’ont découvert la faille que lorsque Microsoft l’a révélée – plusieurs semaines plus tard. Sans piste d’audit indépendante, les équipes en charge de cybersécurité étaient aveugles face au traitement non autorisé des données par l’IA au sein même de leur environnement.
3. La réponse de Microsoft a éludé la véritable question de conformité. Microsoft a affirmé que les utilisateurs n’accédaient qu’aux informations auxquelles ils étaient déjà autorisés. Mais la question de conformité ne porte pas sur l’habilitation de l’utilisateur. Elle porte sur l’autorisation donnée à l’IA d’ingérer, de traiter et de résumer du contenu confidentiel. Selon le RGPD, HIPAA et l’AI Act européen, cette distinction est cruciale.
4. La défense en profondeur pour la gouvernance de l’IA n’est plus une option. Cet incident confirme ce que les architectes sécurité répètent depuis longtemps : la gouvernance de l’IA exige des contrôles indépendants, centrés sur les données, opérant séparément de la plateforme d’IA. L’architecture zéro trust, le purpose binding et l’accès à privilèges minimaux pour l’IA ne sont pas des ambitions, mais des nécessités opérationnelles. Kiteworks propose cette couche de gouvernance indépendante, garantissant que lorsque les contrôles du fournisseur échouent, les défenses au niveau des données restent intactes.
5. Le risque réglementaire est réel et non résolu. Si Copilot a traité des e-mails contenant des informations médicales protégées, des informations personnelles identifiables ou d’autres données réglementées, les organisations peuvent être soumises à des obligations de notification de violation selon HIPAA, l’article 33 du RGPD et les lois américaines sur les violations de données. Microsoft n’a pas précisé combien d’organisations ont été touchées, laissant les équipes conformité évaluer leur exposition avec des informations incomplètes.

Le bug – référencé sous CW1226324 – a été signalé pour la première fois par des clients le 21 janvier 2026. Microsoft a commencé à déployer un correctif début février, mais à la mi-février, la remédiation n’était toujours pas complète pour tous les tenants concernés. Le National Health Service britannique a signalé le problème en interne. Microsoft n’a pas communiqué le nombre d’organisations impactées par l’incident.

Voici ce qui devrait alerter tous les responsables sécurité : les étiquettes de confidentialité étaient en place. Les règles de prévention des pertes de données (DLP) étaient correctement configurées. Tout semblait conforme. Et cela n’a rien changé.

Il ne s’agissait pas d’une mauvaise configuration. Ni d’une erreur d’administration. Il s’agissait d’un bug dans le code de la plateforme – qui a neutralisé toutes les protections censées empêcher l’IA d’accéder aux données confidentielles. Ce n’est pas un simple problème à corriger rapidement. C’est un problème fondamental d’architecture.

Ce qui s’est réellement passé

Une erreur de code dans la fonctionnalité « work tab » de Copilot Chat a permis à l’IA d’accéder aux e-mails des dossiers Éléments envoyés et Brouillons des utilisateurs – même lorsque ces e-mails étaient étiquetés comme confidentiels et que des règles DLP interdisaient explicitement leur traitement par l’IA. Les étiquettes indiquaient « ne pas toucher ». Copilot les a ignorées.

Microsoft a confirmé le problème dans un avis de service, précisant que des e-mails étiquetés confidentiels étaient « traités de manière incorrecte » par Microsoft 365 Copilot Chat. L’entreprise a attribué la cause à une erreur de code et a commencé à déployer un correctif côté serveur début février.

La réponse publique de Microsoft a été soigneusement formulée : les utilisateurs n’accédaient qu’aux informations auxquelles ils étaient déjà autorisés, Copilot opérant dans le contexte de la boîte mail de l’utilisateur. Techniquement, c’est défendable – Copilot fonctionne dans la boîte de l’utilisateur. Mais cela élude complètement la vraie question.

La question n’a jamais été de savoir si l’utilisateur était habilité. La question est de savoir si l’IA était autorisée à ingérer, traiter et résumer du contenu confidentiel. Les étiquettes de confidentialité et les règles DLP existent pour une seule raison : empêcher cela. Lorsque ces contrôles échouent, des données confidentielles sont traitées par un système d’IA en violation des interdictions explicites de l’organisation. C’est cette faille qui compte au regard de la conformité réglementaire.

Le problème d’architecture dont personne ne veut parler

Ce n’est pas l’histoire d’un bug isolé. Les bugs arrivent. Le code comporte des erreurs. Des correctifs sont déployés. C’est le cycle de vie classique.

Le vrai problème est structurel. Tous les contrôles censés empêcher le traitement non autorisé par l’IA – étiquettes de confidentialité, DLP, restrictions d’accès – étaient intégrés à la même plateforme que l’IA. Quand la plateforme a failli, tout a failli. Aucune seconde couche. Aucun contrôle indépendant. Aucun filet de sécurité.

Pour l’illustrer : imaginez une banque où la porte du coffre, l’alarme et les caméras de sécurité dépendent toutes du même disjoncteur. Un seul fil saute, et vous avez un coffre ouvert, aucune alarme, aucune image. C’est ce qui s’est passé ici.

Ce risque n’est pas théorique. Selon le Global Cybersecurity Outlook 2026 du World Economic Forum, les fuites de données via l’IA générative sont désormais la première préoccupation cybersécurité des CEO dans le monde, citée par 30 % des répondants. Chez les professionnels de la cybersécurité, l’inquiétude est passée de 21 % en 2024 à 34 % en 2026. Pourtant, environ un tiers des organisations n’ont toujours aucun processus pour valider la sécurité de l’IA avant son déploiement.

L’incident Copilot illustre parfaitement ce que ce manque de contrôle implique en production.

Pourquoi « faire confiance mais vérifier » échoue quand le vérificateur est aussi le fournisseur

Microsoft est à la fois le fournisseur d’IA, le fournisseur des contrôles de sécurité et l’entité responsable de l’audit de l’efficacité de ces contrôles. Quand les contrôles ont échoué, les organisations n’avaient aucun moyen indépendant de le savoir. Elles l’ont découvert quand Microsoft l’a annoncé – plusieurs semaines après le début de l’incident.

Aucune piste d’audit indépendante n’a enregistré l’accès de Copilot au contenu confidentiel. Aucun système de détection d’anomalies n’a signalé de comportement inhabituel. Aucune alerte en temps réel n’a été déclenchée lorsque l’IA s’est soudainement mise à résumer des e-mails qu’elle n’était jamais censée traiter. Le seul signal a été un avis de service, publié a posteriori.

C’est précisément ce fossé de gouvernance que Kiteworks vient combler. L’argument – et le bug Copilot le rend difficile à contester – est que les contrôles de gouvernance de l’IA doivent fonctionner sur une couche distincte de la plateforme d’IA. Pas comme un simple paramètre dans le même écosystème. Mais comme un plan de contrôle indépendant.

Voici à quoi cela ressemble concrètement :

Couche de gouvernance indépendante des données. Kiteworks fonctionne comme un plan de contrôle séparé. Les plateformes d’IA accèdent aux données via les API Kiteworks avec des règles strictes – jamais en accès direct aux dépôts d’e-mails ou aux systèmes de fichiers. Même si une plateforme d’IA comporte un bug, elle ne peut pas contourner des contrôles qu’elle ne gère pas.

Purpose binding et accès à privilèges minimaux. Limitez l’accès de l’IA à des classifications et usages précis. Plutôt que d’ouvrir toute la boîte mail à Copilot, le purpose binding permet de spécifier que l’IA peut accéder aux e-mails professionnels généraux, mais pas à ceux étiquetés confidentiels, PHI ou CUI. Chaque demande est évaluée selon les règles en vigueur – pas de « connexion unique, accès illimité ».

Détection d’anomalies et surveillance en temps réel. Kiteworks détecte quand des agents IA adoptent des comportements inhabituels d’accès aux données. Si un système d’IA commence soudainement à traiter de gros volumes de contenu confidentiel, des alertes automatiques sont envoyées à l’équipe sécurité en temps réel – pas des semaines plus tard via un avis de service.

Pistes d’audit indépendantes et immuables. Des journaux détaillés documentent quelles données l’IA a consultées, quand, sous quelle autorisation, et quelles actions ont été réalisées. Ces journaux sont contrôlés par l’organisation – pas par le fournisseur d’IA. Si un régulateur demande des comptes, l’organisation dispose de ses propres preuves, indépendantes du récit du fournisseur.

Le risque de conformité à évaluer dès maintenant

Les conséquences réglementaires du bug Copilot vont bien au-delà du correctif technique. Si Copilot a traité des e-mails contenant des informations médicales protégées, des données personnelles ou d’autres contenus réglementés, les organisations peuvent avoir des obligations de conformité qu’elles n’ont pas encore envisagées.

HIPAA. Selon le § 164.308(b)(1), les entités couvertes doivent avoir des contrats écrits avec leurs partenaires commerciaux définissant les usages et divulgations autorisés des informations médicales protégées. Si Copilot a traité des PHI marquées confidentielles d’une manière non couverte par l’accord existant, les organisations doivent évaluer s’il s’agit d’une violation à notifier. L’argument de Microsoft selon lequel les utilisateurs étaient autorisés à voir les données ne répond pas à la question de l’autorisation de traitement par l’IA – une distinction que les régulateurs HIPAA examineront de près.

RGPD. L’article 32 impose des « mesures techniques et organisationnelles appropriées » pour garantir la sécurité du traitement des données personnelles. Les organisations qui se sont uniquement appuyées sur les étiquettes de confidentialité de Microsoft comme mesure technique devront justifier ce choix, surtout après plusieurs semaines d’échec de ces protections. L’article 33 impose de notifier l’autorité de contrôle dans les 72 heures après avoir pris connaissance d’une violation de données personnelles. Si des e-mails confidentiels contenaient des données personnelles européennes, le délai a peut-être déjà commencé à courir.

AI Act européen. L’article 12 exige que les systèmes d’IA à haut risque tiennent des registres détaillés de leurs opérations. Les organisations utilisant Copilot pour traiter des données sensibles peuvent être soumises à ces dispositions. Si leurs seuls journaux opérationnels proviennent de Microsoft – le même fournisseur à l’origine de la faille – elles manquent de la documentation indépendante prévue par la réglementation.

Législations américaines sur la confidentialité des données. Plusieurs États américains imposent des obligations de notification en cas d’accès non autorisé à des informations personnelles. Si Copilot a traité des e-mails confidentiels contenant des informations couvertes par ces lois, les organisations peuvent avoir des obligations non résolues par l’avis de service de Microsoft.

Kiteworks répond directement à ces exigences de conformité. Les pistes d’audit indépendantes fournissent les preuves nécessaires pour évaluer la nécessité de notifier une violation. Les rapports de conformité exportables démontrent aux régulateurs l’existence de contrôles de gouvernance de l’IA. Les accords de traitement des données et les contrats de partenariat sont appliqués au niveau des données – pas seulement via des engagements contractuels dépendant du bon fonctionnement des contrôles du fournisseur.

Ce que les organisations doivent faire maintenant

Évaluer votre exposition. Déterminez si votre organisation a été affectée par CW1226324. Consultez les alertes du centre d’administration Microsoft 365 et les journaux d’utilisation de Copilot du 21 janvier jusqu’à la confirmation de remédiation pour votre tenant. Exportez les métadonnées de tous les e-mails confidentiels présents dans les dossiers Éléments envoyés et Brouillons sur cette période. Si Microsoft ne peut pas fournir de journaux d’accès détaillant ce que Copilot a traité, documentez formellement ce manque.

Évaluer les obligations de notification de violation. Si des e-mails confidentiels contenaient des informations médicales protégées, des informations personnelles identifiables ou d’autres données réglementées, consultez votre service juridique concernant les obligations potentielles selon HIPAA § 164.408, l’article 33 du RGPD ou les lois américaines applicables. Ne présumez pas que la qualification de l’incident par Microsoft suffit à régler vos obligations de conformité.

Mettre en place une gouvernance indépendante de l’IA. Ne vous fiez pas uniquement aux contrôles de la plateforme d’IA pour protéger les données sensibles contre le traitement par l’IA. Déployez une couche de gouvernance indépendante des données – telle que Kiteworks – qui impose les règles d’accès, même en cas de bug du fournisseur. Purpose binding, accès à privilèges minimaux et vérification continue doivent être appliqués au niveau des données, pas de l’application.

Établir des pistes d’audit indépendantes. Assurez-vous que votre organisation dispose de journaux d’accès aux données par l’IA qui ne sont pas exclusivement contrôlés par le fournisseur d’IA. Kiteworks propose des pistes d’audit immuables documentant chaque interaction de l’IA avec les données de l’organisation, offrant ainsi aux équipes sécurité et conformité des preuves indépendantes du reporting du fournisseur.

Revoir l’architecture d’accès de l’IA. Évaluez si vos outils d’IA disposent d’un accès large aux dépôts de données ou si l’accès est restreint par usage et classification. Le bug Copilot a touché les dossiers Éléments envoyés et Brouillons parce que Copilot avait accès à l’ensemble de la boîte mail. Le purpose binding et les contrôles d’accès par attribut auraient limité le traitement aux seules classifications autorisées – même en cas de défaillance des contrôles natifs de la plateforme.

Exiger de la transparence de la part des fournisseurs. Demandez à Microsoft un rapport post-incident détaillant l’étendue de l’impact, les tenants affectés, la conservation des données traitées par Copilot durant l’incident et le calendrier de remédiation complète. Si le fournisseur ne peut pas fournir cette transparence, cela doit vous alerter sur la gouvernance et orienter vos choix d’architecture pour l’avenir.

La leçon que le secteur doit retenir

Le bug Microsoft Copilot n’est pas un incident isolé. C’est une illustration de ce qui se passe quand les organisations confient à une plateforme d’IA le soin de s’auto-surveiller.

Le Global Cybersecurity Outlook 2026 du WEF avertit qu’avec la généralisation des agents IA, la gestion de leurs identifiants, autorisations et interactions devient aussi critique – et probablement plus complexe – que celle des utilisateurs humains. Le rapport recommande la vérification continue, les pistes d’audit et des structures de responsabilité solides, fondées sur les principes du zéro trust, qui considèrent chaque interaction IA comme non fiable par défaut.

Le bug Copilot en est la parfaite démonstration. Les étiquettes de confidentialité étaient un mécanisme de confiance. On faisait confiance à la plateforme pour les respecter. Elle ne l’a pas fait – non par malveillance, mais à cause d’une erreur de code. Et sans couche de gouvernance indépendante, rien n’a permis de rattraper la défaillance.

Kiteworks apporte cette couche indépendante. Son architecture d’échange de données zéro trust oblige les plateformes d’IA à s’authentifier via Kiteworks pour accéder aux données sensibles, avec des règles appliquées au niveau des données – pas de l’application. Le purpose binding limite ce à quoi l’IA peut accéder. La vérification continue évalue chaque demande. Et les pistes d’audit détaillent ce qui s’est passé, quand, et sous quelle autorisation.

Les organisations qui traverseront l’ère de l’IA sans devenir le prochain avis de service sont celles qui bâtissent dès maintenant une gouvernance indépendante. Pas des comités. Pas des étiquettes. Pas des promesses de fournisseurs. Une infrastructure opérationnelle qui applique les règles au niveau des données – là où un bug dans la plateforme ne peut pas les contourner.

Les étiquettes étaient en place. Les règles étaient configurées. L’IA a lu vos e-mails confidentiels malgré tout. Si cela ne change pas votre vision de la gouvernance de l’IA, qu’est-ce qui le fera ?