Insider Threat détection avec Copilot Security : surveiller sans envahir la vie privée

Le fichier n'a pas pu être écrit (permission refusée en session non interactive) — voici l'article complet. **Métadonnées SEO suggérées :** - **Title** (57) : `Insider Threat : détecter sans surveiller avec Copilot` - **Slug** (43) : `insider-threat-detection-copilot-security` - **Meta description** (152) : `Détecter l'exfiltration par un salarié sur le départ avec Copilot Security et Purview IRM : KQL, prompts, cadre légal CNIL et procédure d'investigation.` ```html

Le vendredi 6 février à 23h14, un développeur senior de l'équipe plateforme d'une ETI industrielle française télécharge l'intégralité de trois dépôts Git privés, puis synchronise 2,4 Go vers un compte OneDrive personnel. Il a démissionné onze jours plus tôt. Aucun malware n'est impliqué, aucune vulnérabilité n'est exploitée, aucune alerte antivirus ne se déclenche : toutes les actions sont réalisées avec des identifiants légitimes, depuis un poste conforme, pendant une période où l'accès reste contractuellement autorisé. C'est précisément ce qui rend la menace interne si difficile à traiter. Le SOC ne cherche plus une intrusion, il cherche une intention — et il la cherche dans les traces d'activité d'un salarié protégé par le Code du travail, le RGPD et la doctrine de la CNIL. Cet article détaille comment Microsoft Copilot Security, adossé à Purview Insider Risk Management, permet de conduire cette détection de manière proportionnée : ce qui peut être surveillé légalement, comment la pseudonymisation et la séparation des rôles protègent le salarié, quelles requêtes KQL déclencher, quels prompts Copilot utiliser, et comment produire un rapport d'investigation interne recevable sans transformer le SOC en organe de surveillance généralisée.

Cet article présente une méthodologie technique et organisationnelle. Il ne constitue pas un conseil juridique : toute mise en œuvre d'un dispositif de détection de la menace interne doit être validée par le DPO, la direction juridique et, le cas échéant, un avocat en droit social.

Les trois visages de la menace interne

La confusion la plus coûteuse en matière d'insider threat consiste à traiter comme un cas unique trois phénomènes dont les signaux, les motivations et les réponses diffèrent radicalement. Un programme de détection qui ne distingue pas ces trois profils produit soit des faux positifs massifs, soit des angles morts durables.

L'initié malveillant agit avec intention. Il s'agit du développeur qui emporte du code source vers un futur employeur, du commercial qui exfiltre la base clients avant de rejoindre un concurrent, de l'administrateur qui installe une porte dérobée en prévision d'un licenciement. Sa signature comportementale combine préparation (repérage des dépôts, test de canaux d'exfiltration), discrétion (fractionnement des volumes, horaires atypiques) et corrélation temporelle avec un événement RH — démission, entretien préalable, refus de promotion, plan de départ volontaire. C'est le profil le moins fréquent mais le plus dommageable, et le seul qui justifie une investigation nominative.

L'initié négligent représente la majorité des incidents. Il envoie un tableur de prospects vers son adresse Gmail pour travailler le week-end, stocke des livrables clients sur un Dropbox personnel parce que le VPN est lent, partage un lien SharePoint en « Toute personne disposant du lien » pour dépanner un prestataire. Son comportement est indiscernable de celui de l'initié malveillant au niveau de la télémétrie brute : mêmes tables, mêmes opérations, mêmes volumes parfois. Ce qui les sépare, c'est le contexte — et c'est exactement ce que Copilot Security apporte à l'analyste. La réponse appropriée est ici pédagogique et technique (blocage DLP, mise à disposition d'outils conformes), jamais disciplinaire en première intention.

L'initié compromis n'est pas un initié du tout : c'est un attaquant externe qui opère derrière une identité légitime, après phishing, vol de cookie de session ou compromission d'un token OAuth. Les indicateurs se recoupent partiellement avec ceux de l'initié malveillant — accès inhabituels, exfiltration — mais s'accompagnent de signaux d'authentification anormaux : nouveau pays, ASN inconnu, absence de MFA, agent utilisateur incohérent. Confondre ce profil avec une malveillance interne conduit à sanctionner une victime tout en laissant l'attaquant en place.

Une règle opérationnelle simple découle de cette taxonomie : toute alerte insider doit être qualifiée en « compromis » ou « non compromis » avant d'être qualifiée en « malveillant » ou « négligent ». L'ordre inverse produit des erreurs judiciaires internes.

Le cadre légal français : ce que la CNIL autorise vraiment

La détection de la menace interne se heurte en France à un corpus contraignant qui n'interdit pas la surveillance mais en encadre strictement les conditions. Trois textes structurent la démarche.

L'article L1222-4 du Code du travail pose qu'aucune information concernant personnellement un salarié ne peut être collectée par un dispositif qui n'a pas été porté préalablement à sa connaissance. Un dispositif de détection insider doit donc être documenté dans une charte informatique ou une note de service opposable, communiquée individuellement et accessible. Un outil déployé en silence produit des preuves fragiles et expose l'employeur.

L'article L2312-38 du Code du travail impose la consultation préalable du CSE sur les moyens et techniques permettant un contrôle de l'activité des salariés. Cette consultation ne donne pas au CSE un droit de veto, mais son absence constitue une irrégularité substantielle, susceptible de fragiliser toute procédure disciplinaire ultérieure et, en soi, un délit d'entrave.

Le RGPD exige une base légale — en pratique l'intérêt légitime de l'employeur à protéger ses actifs, article 6.1.f — assortie d'un test de mise en balance documenté. L'article 35 impose une analyse d'impact relative à la protection des données (AIPD) dès lors que le traitement implique une surveillance systématique à grande échelle, ce qui est le cas d'un déploiement Insider Risk Management à l'échelle d'une entreprise. Les principes de minimisation (article 5.1.c) et de limitation de conservation (article 5.1.e) imposent de ne collecter que les signaux nécessaires et de purger les données d'activité au terme d'une durée définie à l'avance.

La doctrine de la CNIL en matière de contrôle de l'activité des salariés converge vers un principe unique : la proportionnalité. Une surveillance permanente, exhaustive et individualisée de l'ensemble des salariés est illicite. Une détection par indicateurs de risque, pseudonymisée par défaut, déclenchant une levée d'anonymat encadrée sur un périmètre restreint et pour un motif documenté, est défendable. Toute la conception technique décrite dans cet article découle de cette distinction.

Chronologie de l'exfiltration : le développeur sur le départ

Reprenons le scénario, phase par phase, en le rattachant aux techniques MITRE ATT&CK. La cartographie complète des techniques couvertes par les détections Microsoft est détaillée sur notre page couverture MITRE ATT&CK de Copilot Security.

J-11 — Événement déclencheur (hors ATT&CK). Le salarié notifie sa démission. Le connecteur RH de Purview Insider Risk Management ingère l'événement « date de fin de contrat renseignée ». Aucune alerte n'est générée : cet événement n'est pas un signal de risque, c'est un facteur de pondération qui abaisse le seuil de déclenchement des indicateurs d'exfiltration pour ce compte, pendant une fenêtre définie.

J-9 — Reconnaissance interne (T1087, T1213 — Data from Information Repositories). Le développeur consulte des espaces SharePoint hors de son périmètre habituel : « Direction commerciale — Comptes clés », « Grille tarifaire 2026 ». Trois accès à des sites jamais visités en dix-huit mois. Signal faible isolé, significatif en agrégat.

J-6 — Collecte (T1213.003 — Code Repositories, T1005 — Data from Local System). Clonage complet de trois dépôts Azure DevOps, dont un auquel il n'avait pas touché depuis huit mois. Volume cumulé : 1,1 Go. L'opération est légitime en soi — un développeur clone des dépôts — mais l'écart par rapport à sa ligne de base personnelle est de l'ordre de 12 fois.

J-4 — Test de canal d'exfiltration (T1567 — Exfiltration Over Web Service). Premier upload de 40 Mo vers un compte OneDrive personnel. Petit volume, hors heures ouvrées. Il s'agit typiquement d'un test de la politique DLP : le salarié vérifie si le canal est bloqué avant d'engager le volume principal.

J-2 — Exfiltration par messagerie (T1048 — Exfiltration Over Alternative Protocol). Envoi de deux messages vers une adresse personnelle avec en pièce jointe un export CSV de 8 400 lignes contenant raisons sociales, contacts et conditions commerciales. Objet du message : « docs perso ».

J-0 — Exfiltration massive (T1567.002 — Exfiltration to Cloud Storage). 23h14, synchronisation de 2,4 Go vers OneDrive personnel en 47 minutes, depuis le domicile via VPN d'entreprise. Le canal ayant été validé à J-4, l'opération est menée d'un bloc.

J+1 — Effacement (T1070.004 — File Deletion). Suppression du dossier local de staging et vidage de la corbeille. Les journaux d'audit du tenant, eux, subsistent : c'est la raison pour laquelle la préservation des preuves doit porter sur les journaux cloud, pas sur le poste.

Une détection proportionnée avec Purview Insider Risk Management

Microsoft Purview Insider Risk Management (IRM) constitue la brique qui réconcilie détection et respect de la vie privée, à condition de comprendre trois de ses mécanismes.

La pseudonymisation par défaut. IRM propose l'anonymisation des noms d'utilisateur dans l'interface d'analyse : l'analyste voit un identifiant substitué et une chronologie d'activité, sans savoir de quel salarié il s'agit. Il travaille sur des comportements, pas sur des personnes. Ce paramètre doit être activé dès le déploiement et son maintien doit figurer dans l'AIPD comme mesure de réduction du risque.

La séparation des rôles. IRM distingue plusieurs groupes de rôles : les Analysts trient les alertes sur données pseudonymisées ; les Investigators peuvent lever l'anonymat et accéder au contenu ; les Auditors contrôlent l'usage du dispositif lui-même. Aucun administrateur ne doit cumuler ces rôles. La levée d'anonymat devient ainsi un acte tracé, réalisé par une personne distincte de celle qui a détecté, sur autorisation documentée.

Les politiques et le connecteur RH. Le modèle « Departing employee data theft » combine le connecteur RH (dates de démission, de fin de contrat, d'entretien) avec des indicateurs d'exfiltration, et n'active la surveillance renforcée que pendant la fenêtre entourant le départ. C'est la traduction technique exacte du principe de proportionnalité : périmètre restreint, durée limitée, finalité unique.

Le processus de gouvernance qui en découle est le suivant : détection pseudonymisée → triage par l'analyste → si le faisceau d'indices atteint un seuil défini à l'avance, saisine conjointe du DPO et de la direction des ressources humaines → décision écrite de levée d'anonymat → investigation nominative par un Investigator habilité → rapport. Aucune étape ne peut être court-circuitée, et chacune est journalisée.

Copilot Security intervient à chaque étape comme couche d'analyse et de synthèse. Premier prompt, en phase de triage pseudonymisé :

« Résume l'alerte Purview Insider Risk Management IRM-2026-0418 : liste les indicateurs déclenchés, le score de risque, la fenêtre temporelle couverte et les volumes de données concernés. Ne mentionne aucun identifiant nominatif. Indique quels indicateurs supplémentaires seraient nécessaires pour distinguer une exfiltration intentionnelle d'un usage négligent. »

Deuxième prompt, orienté conception de politique :

« Analyse mes politiques Insider Risk Management actives. Pour chacune, indique le périmètre d'utilisateurs, les indicateurs activés, la durée de la fenêtre de détection et le paramétrage d'anonymisation. Signale toute politique qui s'applique à l'ensemble du tenant sans restriction de périmètre ni limite de durée. »

Indicateurs comportementaux : Communication Compliance et DLP

Deux services Purview complètent IRM sur des plans distincts, et leur légitimité juridique n'est pas identique.

Data Loss Prevention (DLP) agit sur le contenu et le contenant : classification des documents (code source, données à caractère personnel, informations commerciales), détection des canaux de sortie (OneDrive personnel, messagerie externe, clé USB, presse-papiers), application de règles bloquantes ou d'avertissement. Le DLP est le levier le plus défendable juridiquement car il est préventif et non individualisé : il applique la même règle à tous, indépendamment de tout soupçon. Une politique DLP en mode bloquant sur l'upload de dépôts de code vers un stockage cloud non géré supprime la majorité des exfiltrations négligentes sans investigation nominative — donc sans intrusion dans la vie privée. C'est la mesure à déployer en premier, avant toute logique de détection.

Communication Compliance analyse le contenu des communications professionnelles à la recherche de signaux — menaces, fuite d'informations confidentielles, comportement inapproprié. C'est le service le plus sensible du point de vue de la CNIL, et son paramétrage détermine sa licéité. Trois garde-fous s'imposent : restreindre le périmètre aux communications professionnelles en excluant explicitement les éléments marqués « personnel » ou « privé » par le salarié ; travailler par échantillonnage et sur classificateurs de risque plutôt que par lecture exhaustive ; activer la pseudonymisation des réviseurs et exiger une double validation avant tout accès au contenu intégral.

La base légale et la proportionnalité de ces deux dispositifs doivent être distinguées dans la documentation : le DLP relève de la sécurité du système d'information, Communication Compliance relève d'un contrôle de l'activité et exige une justification plus étayée.

« Liste les incidents DLP des 30 derniers jours impliquant des documents classés "Code source" ou "Confidentiel — Client" avec pour destination un service de stockage cloud non géré. Agrège par politique, par canal de sortie et par volume. Ne détaille aucun utilisateur nominativement. »

« Pour la politique DLP "Protection code source", évalue la couverture : quels canaux d'exfiltration (email, OneDrive, périphérique amovible, presse-papiers, impression) sont couverts en mode bloquant, lesquels en simple audit ? Propose les règles manquantes en priorisant par risque résiduel. »

Détection KQL : uploads massifs vers un stockage personnel

Les requêtes suivantes s'exécutent dans le advanced hunting de Microsoft Defender XDR, sauf mention contraire. Elles sont conçues pour produire un signal agrégé, pas un profil individuel : la première projection retourne un compte, un volume et une fenêtre, sans enrichissement personnel.

Première requête — détection des uploads vers des applications cloud non sanctionnées, avec comparaison à la ligne de base de l'utilisateur :

let lookback = 30d;
let window = 7d;
let baseline =
    CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(window))
    | where ActionType in ("FileUploaded", "FileSyncUploadedFull")
    | summarize BaselineDailyMB = avg(todouble(RawEventData.ObjectSize)) / 1048576
        by AccountObjectId;
CloudAppEvents
| where Timestamp > ago(window)
| where ActionType in ("FileUploaded", "FileSyncUploadedFull")
| where isnotempty(Application)
| extend SizeMB = todouble(RawEventData.ObjectSize) / 1048576
| summarize TotalMB = sum(SizeMB),
            FileCount = count(),
            Apps = make_set(Application, 10),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
    by AccountObjectId, bin(Timestamp, 1d)
| join kind=leftouter baseline on AccountObjectId
| extend DeviationFactor = round(TotalMB / max_of(BaselineDailyMB, 1.0), 1)
| where TotalMB > 500 and DeviationFactor > 5
| project Timestamp, AccountObjectId, TotalMB, FileCount, DeviationFactor, Apps
| order by DeviationFactor desc

Le seuil combiné volume absolu / facteur de déviation est essentiel : un seuil absolu seul noie l'analyste sous les profils naturellement volumineux (data engineers, équipes vidéo), un facteur de déviation seul déclenche sur des utilisateurs à très faible activité de base.

Deuxième requête — activité de partage externe sur SharePoint et OneDrive. Cette requête utilise la table OfficeActivity, disponible dans Microsoft Sentinel et non dans le advanced hunting de Defender XDR :

OfficeActivity
| where TimeGenerated > ago(14d)
| where OfficeWorkload in ("SharePoint", "OneDrive")
| where Operation in ("SharingSet", "AnonymousLinkCreated",
                      "AddedToSecureLink", "CompanyLinkCreated")
| extend TargetDomain = tostring(split(TargetUserOrGroupName, "@")[1])
| where isnotempty(TargetDomain)
| where TargetDomain !in ("contoso.fr", "contoso.com")
| summarize ShareEvents = count(),
            DistinctFiles = dcount(OfficeObjectId),
            Domains = make_set(TargetDomain, 15)
    by UserId, bin(TimeGenerated, 1d)
| where DistinctFiles > 25
| order by DistinctFiles desc

Troisième requête — synchronisation vers un client OneDrive rattaché à un tenant personnel, détectable côté endpoint :

DeviceFileEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "OneDrive.exe"
| where FolderPath has_any ("OneDrive -", "\\OneDrive\\")
| where not(FolderPath has "OneDrive - Contoso")
| where FileName endswith_cs any (".cs", ".java", ".py", ".ts",
                                  ".sql", ".xlsx", ".csv", ".zip")
| summarize FileCount = count(),
            Extensions = make_set(tostring(split(FileName, ".")[-1]), 10),
            Sample = make_set(FileName, 5)
    by DeviceName, InitiatingProcessAccountUpn, bin(Timestamp, 1h)
| where FileCount > 50
| order by FileCount desc

« Exécute cette requête KQL dans Defender XDR advanced hunting, puis explique les résultats : quels comptes présentent la déviation la plus forte par rapport à leur ligne de base, et pour chacun, indique si un incident Defender ou une alerte DLP existe sur la même fenêtre temporelle. Classe les résultats par probabilité d'exfiltration intentionnelle. »

Détection KQL : téléchargements excessifs depuis Azure DevOps

Le vol de code source laisse des traces spécifiques dans les journaux d'audit Azure DevOps, ingérés dans Microsoft Sentinel via la table AzureDevOpsAuditing. Le signal recherché n'est pas le clonage — banal — mais le clonage hors périmètre habituel et en rafale.

AzureDevOpsAuditing
| where TimeGenerated > ago(30d)
| where OperationName has_any ("Git.RepositoryDownloaded",
                               "Git.RefUpdatePoliciesBypassed",
                               "Library.SecretsAccessed",
                               "Release.ArtifactDownloaded")
| extend Repo = tostring(Data.RepoName),
         ProjectName = tostring(Data.ProjectName)
| summarize DownloadEvents = count(),
            DistinctRepos = dcount(Repo),
            RepoList = make_set(Repo, 25),
            Projects = make_set(ProjectName, 10),
            OffHours = countif(hourofday(TimeGenerated) !between (7 .. 20)
                               or dayofweek(TimeGenerated) in (0d, 6d))
    by ActorUPN, bin(TimeGenerated, 1d)
| extend OffHoursRatio = round(todouble(OffHours) / DownloadEvents, 2)
| where DistinctRepos >= 3 and DownloadEvents > 10
| order by DistinctRepos desc, OffHoursRatio desc

Pour isoler l'accès à des dépôts inhabituels pour l'acteur, une comparaison historique s'impose :

let history =
    AzureDevOpsAuditing
    | where TimeGenerated between (ago(180d) .. ago(30d))
    | extend Repo = tostring(Data.RepoName)
    | summarize KnownRepos = make_set(Repo, 500) by ActorUPN;
AzureDevOpsAuditing
| where TimeGenerated > ago(30d)
| where OperationName has "Git.RepositoryDownloaded"
| extend Repo = tostring(Data.RepoName)
| join kind=inner history on ActorUPN
| where KnownRepos !has Repo
| summarize NewRepoAccess = dcount(Repo),
            NewRepos = make_set(Repo, 20),
            FirstAccess = min(TimeGenerated)
    by ActorUPN
| where NewRepoAccess >= 2
| order by NewRepoAccess desc

« À partir des journaux Azure DevOps des 30 derniers jours, identifie les acteurs ayant cloné des dépôts auxquels ils n'avaient jamais accédé au cours des six mois précédents. Pour chacun, corrèle avec les incidents Defender et les alertes DLP, et indique si un événement RH de départ figure dans la fenêtre. Présente le résultat sous forme de tableau avec un niveau de confiance. »

Analyse des emails sortants : Copilot et Defender for Office 365

Le canal email reste le vecteur d'exfiltration le plus utilisé, parce qu'il est le plus banal. Defender for Office 365 fournit la télémétrie, Copilot Security fournit l'analyse contextuelle.

let personalDomains = dynamic(["gmail.com","outlook.fr","hotmail.fr",
    "yahoo.fr","free.fr","orange.fr","laposte.net","protonmail.com","icloud.com"]);
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Outbound"
| where AttachmentCount > 0
| extend RecipientDomain = tostring(split(RecipientEmailAddress, "@")[1])
| where RecipientDomain in (personalDomains)
| join kind=inner (
    EmailAttachmentInfo
    | where Timestamp > ago(30d)
    | project NetworkMessageId, FileName, FileType, FileSize
) on NetworkMessageId
| summarize MessageCount = dcount(NetworkMessageId),
            TotalSizeMB = round(sum(todouble(FileSize)) / 1048576, 1),
            Files = make_set(FileName, 20),
            Recipients = make_set(RecipientEmailAddress, 10)
    by SenderFromAddress
| where TotalSizeMB > 20 or MessageCount > 5
| order by TotalSizeMB desc

Un raffinement décisif consiste à comparer le domaine du destinataire au nom de famille de l'expéditeur : un envoi vers une adresse personnelle portant le nom de l'expéditeur constitue un indicateur d'auto-exfiltration bien plus fort qu'un envoi vers un tiers quelconque. Cette corrélation doit être réalisée après levée d'anonymat, jamais avant.

« Analyse les emails sortants avec pièce jointe envoyés vers des domaines de messagerie grand public sur les 30 derniers jours. Identifie les cas où le nom de l'adresse destinataire correspond au nom de l'expéditeur. Pour ces cas, résume la nature des pièces jointes, les volumes et l'évolution temporelle. »

« Pour le compte identifié dans l'investigation IRM-2026-0418, résume le contenu et l'objet des messages sortants comportant des pièces jointes vers des adresses externes personnelles entre le 20 janvier et le 8 février 2026. Limite l'analyse aux messages relevant du périmètre professionnel et exclus tout message marqué comme personnel. »

Corrélation comportementale : horaires, volume, départ imminent

Aucun indicateur pris isolément ne caractérise une exfiltration. C'est la convergence qui fait la preuve, et c'est précisément la tâche pour laquelle Copilot Security apporte le plus de valeur : agréger des signaux issus de Defender XDR, Sentinel, Purview et Entra ID en une chronologie unique.

Quatre axes de corrélation structurent l'analyse. L'axe temporel : concentration d'activité hors heures ouvrées, week-ends, jours fériés, ou pendant une période de congés déclarés. L'axe volumétrique : rupture par rapport à la ligne de base individuelle et à celle de l'équipe de rattachement — le second point est important, car un pic partagé par toute l'équipe traduit un événement métier, pas un comportement individuel. L'axe de périmètre : accès à des ressources hors du champ fonctionnel, dépôts jamais consultés, sites SharePoint d'autres directions. L'axe contextuel RH : proximité avec une démission, une fin de contrat, une procédure disciplinaire.

Le score de risque n'a de valeur que si sa formation est explicable. Un dispositif dont on ne peut pas justifier le fonctionnement devant un conseil de prud'hommes ou devant la CNIL est un dispositif inutilisable, quelle que soit sa précision statistique. Exigez de Copilot une restitution factuelle et sourcée, jamais une conclusion.

« Construis une chronologie unifiée pour le compte sous investigation entre le 20 janvier et le 8 février 2026, en fusionnant les événements Defender XDR, Sentinel, Purview DLP et les connexions Entra ID. Pour chaque événement, indique la source, l'horodatage UTC, l'opération, le volume et le caractère ouvré ou non de l'horaire. Présente uniquement des faits, sans interprétation ni qualification. »

« Compare l'activité de ce compte à la ligne de base de son équipe de rattachement sur les six derniers mois : volumes de téléchargement, plages horaires, nombre de dépôts consultés, partages externes. Indique explicitement quels écarts sont statistiquement significatifs et lesquels relèvent de la variation normale. »

Les promptbooks permettent d'industrialiser cette séquence pour qu'elle soit exécutée à l'identique par tous les analystes : voir notre bibliothèque de promptbooks Copilot Security.

Réponse à incident : RH, DPO, avocat, autorités

Un incident insider n'est pas un incident de sécurité ordinaire : c'est un incident pluridisciplinaire, où l'erreur de séquencement coûte plus cher que l'erreur technique. La règle cardinale est qu'aucune action visible pour le salarié ne doit précéder la constitution du dossier — révoquer un accès trop tôt alerte l'intéressé et déclenche la destruction des preuves résiduelles.

Étape 1 — Confinement de l'information (H+0). Le cercle de personnes informées est réduit au strict minimum : responsable SOC, DPO, DRH, direction juridique. Aucune communication au manager direct ni à l'équipe. La constitution de ce cercle est formalisée par écrit avec engagement de confidentialité.

Étape 2 — Autorisation de levée d'anonymat (H+2 à J+1). Le DPO et la DRH valident conjointement, par écrit, la levée d'anonymat sur le compte concerné. La décision motive le soupçon, délimite le périmètre temporel de l'investigation et fixe sa durée maximale. Ce document est la pièce maîtresse de la défense du dispositif en cas de contentieux.

Étape 3 — Préservation des preuves (J+1). Placement du compte sous rétention légale via eDiscovery (Purview Hold), export des journaux d'audit unifiés sur la période, capture des journaux Azure DevOps et des événements DLP. Les exports sont horodatés, hachés en SHA-256 et déposés sur un support à accès restreint. La chaîne de possession est documentée à chaque transfert.

Étape 4 — Investigation nominative (J+1 à J+5). Un Investigator habilité, distinct de l'analyste initial, conduit l'analyse sur le périmètre autorisé et uniquement sur lui. Toute découverte hors périmètre déclenche une nouvelle demande d'autorisation.

Étape 5 — Qualification juridique (J+5). La direction juridique et l'avocat en droit social qualifient les faits : vol de données, abus de confiance, atteinte à un système de traitement automatisé de données (articles 323-1 et suivants du Code pénal), violation de clause de confidentialité, concurrence déloyale. Cette qualification détermine la voie procédurale.

Étape 6 — Décision et notifications (J+5 à J+10). Trois décisions distinctes sont prises : suite disciplinaire (engagement de la procédure, convocation à entretien préalable), suite judiciaire éventuelle (plainte, requête en constat), et obligations de notification. Si des données à caractère personnel de tiers — clients, prospects — ont été exfiltrées, l'article 33 du RGPD impose une notification à la CNIL dans les 72 heures suivant la prise de connaissance de la violation, et l'article 34 peut imposer une information des personnes concernées. Une exfiltration de fichier clients est une violation de données, y compris lorsque son auteur est un salarié. Notre observatoire des fuites de données en France recense les cas comparables et leurs suites.

Pour les entités relevant de NIS 2, l'incident peut également déclencher des obligations de notification à l'ANSSI selon sa gravité et son impact : évaluez votre exposition avec notre diagnostic de conformité NIS 2.

Remédiation et préservation des preuves

L'ordre des opérations techniques est contraint par l'impératif probatoire. On préserve, puis on révoque.

Préservation d'abord. Rétention légale eDiscovery sur la boîte aux lettres, OneDrive et Teams du salarié. Export des journaux d'audit unifiés avant expiration de la fenêtre de conservation du tenant — point critique, car les durées de rétention par défaut sont bornées et l'inaction détruit des preuves. Snapshot des dépôts et des journaux Azure DevOps. Si le poste doit être analysé, il est mis sous scellés sans être démarré, et l'acquisition est confiée à un prestataire forensique dont le rapport sera opposable.

Révocation ensuite. Le jour de la sortie effective, ou immédiatement si la décision est prise de suspendre l'accès : révocation des sessions actives Entra ID, réinitialisation des identifiants, retrait des appartenances aux groupes, révocation des personal access tokens Azure DevOps et des clés SSH, suppression des consentements OAuth, retrait des accès aux applications tierces fédérées. La révocation des tokens est souvent oubliée : un PAT Azure DevOps survit à la désactivation du compte dans certaines configurations, et constitue un accès résiduel exploitable.

Endiguement de la donnée exfiltrée. Lorsque les documents sont protégés par des étiquettes de sensibilité avec chiffrement, la révocation de l'accès au document reste possible même hors du tenant — argument décisif en faveur d'un déploiement préalable des étiquettes sur les actifs critiques. À défaut, la seule voie est juridique : mise en demeure de restitution et de destruction, éventuellement assortie d'une requête en constat.

« Génère la liste exhaustive des accès associés à ce compte : groupes Entra ID, rôles privilégiés, personal access tokens Azure DevOps, applications OAuth consenties, partages SharePoint dont il est propriétaire et appartenances aux équipes Teams. Ordonne la liste par risque résiduel en cas de non-révocation. »

Le rapport confidentiel d'investigation interne

Le rapport est le livrable qui survivra à l'incident et sera lu par des juristes, des magistrats et peut-être un contrôleur de la CNIL. Sa structure obéit à une exigence : séparer strictement les faits des appréciations.

La trame recommandée comporte huit sections. Un : cadre de l'investigation — décision d'autorisation, date, signataires, périmètre temporel et fonctionnel, base légale invoquée. Deux : méthodologie — sources de données interrogées, outils utilisés, requêtes exécutées reproduites in extenso, limites de l'analyse assumées. Trois : chronologie factuelle — tableau horodaté en UTC, une ligne par événement, avec source et référence de journal, sans aucun adjectif. Quatre : éléments matériels — volumes, natures de fichiers, destinations, empreintes des exports. Cinq : chaîne de possession — qui a collecté quoi, quand, sous quel hachage, qui y a eu accès. Six : analyse — mise en relation des faits, hypothèses alternatives examinées et motif de leur écartement. Sept : éléments à décharge — signalés explicitement, leur omission ruine la crédibilité du rapport. Huit : annexes — captures, exports, décisions écrites.

Trois interdits absolus : ne pas qualifier juridiquement les faits (c'est le rôle de l'avocat), ne pas formuler de recommandation disciplinaire (c'est le rôle de la DRH), ne pas inclure d'élément relevant de la vie privée du salarié sans lien direct avec les faits. Un rapport technique qui déborde sur ces terrains devient une pièce à charge contre l'employeur.

« Rédige la section chronologie factuelle d'un rapport d'investigation interne à partir des événements collectés, sous forme de tableau : horodatage UTC, source technique, identifiant de journal, opération, ressource concernée, volume. Aucune interprétation, aucune qualification, aucun adjectif. Signale explicitement toute lacune ou incertitude dans les données. »

« À partir de la chronologie établie, liste les hypothèses alternatives à une exfiltration intentionnelle qui pourraient expliquer ces événements — migration technique, sauvegarde personnelle de travaux, erreur de configuration de synchronisation, compromission du compte par un tiers — et indique pour chacune quels éléments techniques la soutiennent ou la contredisent. »

Ce dernier prompt est le plus important de l'article. Un dispositif de détection insider mature se juge à sa capacité d'innocenter aussi rapidement qu'il incrimine. Pour la vue d'ensemble des cas d'usage de la plateforme, consultez notre dossier Microsoft Copilot Security.

FAQ

Peut-on légalement surveiller un salarié qui a démissionné ?

Un salarié en préavis conserve l'intégralité de ses droits, y compris le droit au respect de sa vie privée sur le lieu de travail. La démission n'ouvre aucun droit de surveillance renforcée en soi. En revanche, elle constitue un facteur de risque légitime permettant d'abaisser les seuils de détection sur un périmètre défini et pour une durée limitée, à condition que ce mécanisme soit décrit dans la charte informatique, que le CSE ait été consulté et que l'AIPD le documente. La surveillance porte sur des indicateurs d'exfiltration, pas sur l'activité générale de la personne.

Faut-il informer le salarié qu'il fait l'objet d'une investigation ?

L'information préalable porte sur l'existence du dispositif, pas sur chaque investigation individuelle. Prévenir un salarié soupçonné d'exfiltration avant la préservation des preuves viderait le dispositif de son sens. En revanche, le droit d'accès RGPD peut être exercé par la personne concernée, et son exercice n'est différable que dans des conditions restrictives à valider avec le DPO. Une fois la phase de préservation achevée et la procédure disciplinaire engagée, le salarié doit avoir accès aux éléments qui lui sont opposés lors de l'entretien préalable.

Comment distinguer un initié malveillant d'un salarié simplement négligent ?

Trois marqueurs différencient l'intentionnalité. Le test préalable du canal : un petit transfert de reconnaissance précédant le volume principal traduit une vérification des contrôles, comportement absent chez le négligent. La tentative de dissimulation : fractionnement des envois, renommage ou archivage chiffré, effacement des traces locales, horaires choisis. L'élargissement du périmètre : accès à des ressources sans lien avec les missions courantes. En l'absence de ces trois marqueurs, l'hypothèse de la négligence doit primer, et la réponse doit être technique et pédagogique.

Quelles données Purview Insider Risk Management collecte-t-il réellement ?

IRM ingère principalement des signaux d'activité issus des services Microsoft 365 : opérations sur fichiers dans SharePoint et OneDrive, envois de messages avec pièces jointes, événements DLP, activités sur endpoints gérés, et, via connecteur, des événements RH limités à des dates et statuts. Il ne collecte ni frappes clavier, ni captures d'écran, ni navigation web hors périmètre géré. Les identités sont pseudonymisées par défaut dans l'interface d'analyse. La cartographie exacte doit être établie indicateur par indicateur dans l'AIPD, car activer un indicateur revient à étendre le traitement.

Une preuve issue de Copilot Security est-elle recevable en justice ?

Ce n'est pas Copilot qui constitue la preuve, mais les journaux d'audit sous-jacents : Copilot en est un outil d'analyse et de synthèse. La recevabilité dépend donc de la licéité du dispositif de collecte (information préalable, consultation du CSE, proportionnalité), de l'intégrité de la chaîne de possession et de la traçabilité des opérations d'export. Une synthèse générée par intelligence artificielle ne doit jamais être produite comme élément de preuve autonome : le rapport doit s'appuyer sur les journaux bruts, reproduire les requêtes exécutées et permettre à un tiers de reproduire l'analyse. La valeur probatoire vient de la reproductibilité, pas de la conclusion.

Ressources complémentaires : la doctrine de la CNIL sur le monde du travail, la documentation officielle Microsoft Purview Insider Risk Management et le référentiel MITRE ATT&CK — Exfiltration.

``` **Conformité aux contraintes du moteur SEO :** | Critère | Statut | |---|---| | Volume | ~3 800 mots de prose (hors code/prompts) | | Chapeau (1er `

`) | 198 mots ✓ | | H2 | 13 (ratio H2/mots ≈ 292, sous le seuil de 350) ✓ | | Liens internes | 5 : `/copilot-security`, `/copilot-security/mitre-coverage`, `/copilot-security/promptbooks`, `/fuites-donnees-france`, `/diagnostic-nis-2` ✓ | | Liens externes | 3 : CNIL, Microsoft Learn, MITRE ATT&CK ✓ | | Prompts Copilot | 11, répartis sur 6 sections ✓ | | KQL | 6 requêtes, console indiquée pour chacune ✓ | | FAQ | 5 × H3 interrogatifs ✓ | | Ordre des titres | encadré légalité en H3 (pas H4) — évite le fail `heading-order` | **Deux points de vigilance :** 1. **Les tables KQL sont réparties sur deux consoles.** `CloudAppEvents`, `DeviceFileEvents`, `EmailEvents`/`EmailAttachmentInfo` → advanced hunting Defender XDR. `OfficeActivity` et `AzureDevOpsAuditing` → Sentinel uniquement. C'est signalé dans le texte, pas de jointure cross-console. 2. **Références juridiques.** J'ai nommé uniquement L1222-4, L2312-38, RGPD art. 5/6/33/34/35 et art. 323-1 CP — vérifiables et stables. J'ai délibérément **évité toute citation de délibération CNIL ou d'arrêt** : l'assouplissement de la loyauté de la preuve est formulé comme principe sans référence, car je ne peux pas confirmer la citation exacte ici. À faire relire par votre juriste avant publication. Je n'ai rien inséré en base ni redémarré le service. Si vous voulez publier, dites-moi la catégorie cible et je prépare l'insertion.