Microsoft a reconnu un incident qui touche un point sensible pour toute entreprise qui a misé sur les labels de sensibilité et la Data Loss Prevention (DLP) comme garde-fous : Copilot Chat a pu générer des résumés à partir d’e-mails confidentiels qui auraient dû être exclus.

Le bug a été détecté le 21 janvier 2026 et est lié à l’expérience Copilot « work tab » chat.

Ce qui inquiète, ce n’est pas « Copilot a lu un document qu’on lui a donné ». C’est plus insidieux : la promesse de gouvernance (labels + DLP) n’a pas été respectée dans un flux conversationnel conçu pour devenir le réflexe quotidien des employés.

Un contournement centré sur « Brouillons » et « Éléments envoyés »

Selon les informations partagées par Microsoft, une erreur de code a permis à Copilot d’« attraper » des éléments des dossiers Brouillons et Éléments envoyés, puis d’en produire des résumés malgré la présence d’un label de confidentialité et d’une politique DLP configurée pour empêcher ce traitement.

Ces deux dossiers sont précisément ceux où la matière sensible s’accumule :

Brouillons : négociations, chiffres non publiés, formulations juridiques « en chantier ».
Envoyés : wording final transmis à un client, un partenaire, un régulateur.

Dans ce contexte, un résumé « pratique » peut devenir un accélérateur de circulation interne d’informations qui, elles, étaient censées rester confinées.

Ce que Microsoft corrige… et ce que l’entreprise ne détaille pas (encore)

Microsoft dit avoir démarré le déploiement d’un correctif début février et indique surveiller la situation pour confirmer que la mitigation fonctionne. En revanche, deux informations cruciales pour les équipes sécurité restent floues dans les comptes rendus publics :

combien de tenants ont été touchés ;
depuis quand exactement le comportement existait avant la détection du 21 janvier.

Sans fenêtre d’exposition claire, on passe d’un audit « ciblé » à une revue potentiellement plus large des usages et logs.

« L’IA de travail » met la gouvernance au défi

Ce cas illustre une réalité de 2026 : l’IA n’est plus un outil de génération, c’est une interface de lecture qui synthétise, reformule, recoupe — et donc change la surface de risque. Même lorsque les données ne « sortent » pas de l’organisation, une fuite peut se produire à l’intérieur un résumé recopié dans Teams, une capture partagée, un extrait glissé dans un ticket, ou simplement une information qui devient « facile à re-raconter » parce qu’elle a été condensée.

Autrement dit, la question n’est pas seulement « Copilot a-t-il accès ? » mais « Copilot rend-il l’accès plus fluide que la politique de sécurité ne l’avait anticipé ? ».

Voici une approche pragmatique, inspirée de ce que recommandent plusieurs observateurs IT et sécurité :

Vérifier l’état du correctif dans votre tenant (Message Center/communication incident/canaux support) et consigner la date de saturation du déploiement.
Tester explicitement le scénario : e-mail labélisé « Confidential » + politique DLP censée bloquer → vérifier si Copilot « work tab » peut encore le résumer depuis Brouillons et Éléments envoyés.
Capturer des preuves (sans exposer de contenu sensible) : captures de l’interface, horodatages, IDs de politiques/labels, et conserver un mémo interne pour votre équipe RSSI.
Revoir les paramètres Copilot et, si nécessaire, appliquer une restriction temporaire d’usage pour les populations les plus à risque (juridique, finance, M&A, RH, sécurité).

Côté terrain, le réflexe le plus sûr est simple : considérer les résumés comme une aide à la lecture, pas comme une preuve de conformité. Tant que votre IT n’a pas confirmé que le correctif est effectif chez vous, évitez d’utiliser Copilot pour « récapituler » des échanges dont la diffusion interne serait problématique.