Microsoft 365 : retrouver qui a supprimé un courriel, un fichier ou un utilisateur

Un objet disparu ne désigne pas automatiquement un responsable

Un courriel manque dans une boîte partagée, un dossier Teams a disparu ou un utilisateur n’existe plus. La première question est de confirmer ce qui est arrivé : suppression, déplacement, changement de permissions, règle automatique ou problème de synchronisation. Ensuite seulement, on cherche l’identité associée à l’événement.

Ce guide propose une collecte ciblée dans Exchange Online, Microsoft Purview et Microsoft Entra ID. Les commandes consultent les services; les exports écrivent uniquement sur le poste d’administration. Les dates, adresses et identifiants sont fictifs. Une investigation complète peut exiger d’autres sources, surtout lorsqu’un compte est compromis ou qu’un différend existe.

1. Fixer le périmètre et préserver les premières traces

Documenter l’intervalle de recherche en UTC et garder l’heure locale d’origine. Une recherche trop étroite peut manquer une synchronisation retardée; une recherche portant sur plusieurs mois peut noyer l’événement utile. Commencer avec une fenêtre raisonnable, puis l’élargir de façon documentée.

• Ouvrir un dossier d’incident : personne ayant signalé le problème, heure de découverte, dernière présence connue, fuseau horaire et impact opérationnel.
• Identifier la cible : boîte et détails du message, URL complète du fichier et bibliothèque, ou identifiant objet Entra de l’utilisateur. Un nom d’affichage seul est insuffisant.
• Capturer l’état actuel, la corbeille et les messages d’erreur sans purger ni déplacer les données. Préserver les journaux avant l’expiration de leur rétention.
• Séparer les accès d’enquête des droits de restauration. Désigner un responsable pour les changements afin que deux administrateurs ne restaurent pas simultanément le même contenu.

2. Choisir le journal selon l’objet

Un fichier visible dans Teams peut être stocké dans SharePoint ou OneDrive : identifier son emplacement réel. La suppression d’un compte et celle d’un courriel sont deux opérations différentes; ne pas chercher uniquement dans le journal de connexion Entra pour expliquer une disparition de message.

• Microsoft — catalogue des activités auditées ↗

3. Permissions, licences et fenêtres de conservation

Pour consulter Purview, utiliser un groupe de rôles donnant View-Only Audit Logs, par exemple Audit Reader, avec la portée appropriée. L’accès aux cmdlets d’audit doit aussi être autorisé dans Exchange. Les lectures de configuration Exchange ci-dessous exigent les droits RBAC correspondants; un rôle de lecture des journaux ne donne pas nécessairement accès à Get-Mailbox.

Audit Standard conserve normalement les événements pendant 180 jours. Une rétention plus longue dépend des licences et des stratégies. Les droits E5 ou les compléments admissibles concernent notamment l’utilisateur qui génère l’événement; acheter une licence pour l’enquêteur ne prolonge pas automatiquement tous les journaux. Examiner la stratégie effective, pas seulement le nom de l’abonnement.

Les journaux d’audit Entra ont une fenêtre distincte : 7 jours en Free, 30 jours en P1/P2. Une exportation configurée à l’avance peut fournir un historique externe. La rétention Purview ne se déduit pas de celle d’Entra. Une modification de licence ne recrée pas des événements déjà expirés.

• Microsoft — accès à la recherche d’audit ↗
• Microsoft — stratégies de rétention d’audit ↗
• Microsoft — rétention Entra ↗

4. Vérifier l’audit Exchange sans modifier la configuration

Exécuter Get-AdminAuditLogConfig dans Exchange Online PowerShell : la même propriété peut donner False dans Security & Compliance PowerShell. UnifiedAuditLogIngestionEnabled renseigne sur l’ingestion, tandis qu’AuditDisabled concerne l’audit des boîtes au niveau de l’organisation.

Examiner les actions Owner, Delegate et Admin, ainsi que DefaultAuditSet. Des personnalisations ou des exceptions de contournement peuvent expliquer une couverture incomplète. La propriété AuditEnabled prise isolément ne démontre pas que chaque action recherchée était enregistrée. Un état actuel correct ne prouve pas l’état historique au moment de l’incident.

# Read-only tenant checks; requires ExchangeOnlineManagement
Connect-ExchangeOnline -ShowBanner:$false
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled
Get-OrganizationConfig | Select-Object AuditDisabled
Get-Mailbox -Identity 'support@contoso.com' |
  Select-Object DefaultAuditSet, AuditOwner, AuditDelegate, AuditAdmin,
    RetainDeletedItemsFor

• Microsoft — rechercher des éléments de boîte supprimés ↗
• Microsoft — fonctionnement de l’audit des boîtes ↗

5. Rechercher le courriel et distinguer les trois suppressions

Dans Purview > Audit, choisir l’intervalle UTC et les opérations pertinentes. Laisser le filtre des utilisateurs vide lorsque l’auteur est inconnu : le propriétaire de la boîte peut être différent du délégué ayant agi. Inspecter les détails des résultats avant de conclure.

MoveToDeletedItems correspond au déplacement vers Éléments supprimés. SoftDelete mène vers Recoverable Items. HardDelete correspond à une purge depuis Recoverable Items; ce nom ne suffit pas à déterminer toutes les possibilités de récupération ou de conservation.

Pour une extraction ponctuelle, le bloc suivant pagine une fenêtre limitée. Il conserve le même identifiant de session et s’arrête au plafond de 50 000 résultats. Si ce plafond est atteint, fractionner l’intervalle et recommencer; ne pas présenter l’export comme exhaustif. Les résultats ne sont pas nécessairement triés.

# Fictional UTC interval: replace with the incident window
$start = [datetimeoffset]::Parse('2026-10-20T12:00:00Z').UtcDateTime
$end   = [datetimeoffset]::Parse('2026-10-20T14:00:00Z').UtcDateTime
$operations = @('MoveToDeletedItems', 'SoftDelete', 'HardDelete')
$session = [guid]::NewGuid().ToString()
$rows = [System.Collections.Generic.List[object]]::new()
$query = @{
  StartDate = $start; EndDate = $end; Operations = $operations
  SessionId = $session; SessionCommand = 'ReturnLargeSet'
  ResultSize = 5000; ErrorAction = 'Stop'
}
do {
  $page = @(Search-UnifiedAuditLog @query)
  foreach ($row in $page) { $rows.Add($row) }
} while ($page.Count -gt 0 -and $rows.Count -lt 50000)
if ($rows.Count -ge 50000) {
  Write-Warning 'Limit reached: split the interval and repeat with new session IDs.'
}
# Preserve $rows before filtering; an empty response is not proof of no deletion.

• Microsoft — paramètres et pagination Search-UnifiedAuditLog ↗

6. Conserver l’export brut avant de filtrer

Créer à l’avance un répertoire de dossier avec accès limité aux enquêteurs autorisés, sur un stockage protégé. Consigner le tenant, le compte utilisé, la commande, l’intervalle, les filtres, le nombre de lignes et les avertissements. Les exports contiennent des renseignements personnels; ne pas les déposer dans un partage public ou un outil de partage de texte.

Le CSV brut garde AuditData. La vue dérivée ci-dessous cible la boîte fictive support@contoso.com, sans confondre MailboxOwnerUPN et UserId. Certains événements regroupent plusieurs éléments : examiner aussi les objets imbriqués plutôt que compter une ligne comme un seul message.

Une empreinte SHA-256 permet de détecter une modification ultérieure du fichier si l’empreinte de référence est protégée. Elle ne certifie ni l’auteur de l’action ni l’exhaustivité de la collecte. Garder l’original intact et analyser une copie; documenter qui a reçu les preuves.

# LOCAL WRITES ONLY. Use an existing, access-restricted case directory.
$caseDir = 'C:\Cases\INC-2026-042'
if (-not (Test-Path -LiteralPath $caseDir -PathType Container)) {
  throw 'Create and secure the case directory before exporting.'
}
$stamp = [datetime]::UtcNow.ToString('yyyyMMddTHHmmssfffZ')
$rawPath = Join-Path $caseDir "ual-$stamp.csv"
$rows | Export-Csv -LiteralPath $rawPath -NoTypeInformation -Encoding utf8
Get-FileHash -LiteralPath $rawPath -Algorithm SHA256 |
  Export-Csv -LiteralPath "$rawPath.sha256.csv" -NoTypeInformation

# Derived view; the original AuditData JSON remains in the raw export.
$records = @($rows | ForEach-Object {
  $_.AuditData | ConvertFrom-Json -ErrorAction Stop
})
$records | Where-Object { $_.MailboxOwnerUPN -eq 'support@contoso.com' } |
  Select-Object CreationTime, Id, Operation, ResultStatus, UserId,
    MailboxOwnerUPN, LogonType, ClientIP, ClientIPAddress |
  Format-Table -AutoSize

• Microsoft — schéma des événements et propriétés selon la charge ↗

7. Retrouver une suppression SharePoint ou OneDrive

Dans Purview, chercher les opérations de fichier et de dossier sur la période retenue. Une suppression de dossier, un déplacement ou une suppression propagée par le client OneDrive peut expliquer plusieurs fichiers manquants. Si les premiers filtres ne donnent rien, élargir aux opérations connexes et aux anciennes URL.

FileRecycled indique une mise à la corbeille. Les opérations FileDeletedFirstStageRecycleBin et FileDeletedSecondStageRecycleBin permettent d’examiner les étapes suivantes. Ajouter les variantes de dossier ou de version si le périmètre l’exige.

Remplacer réellement la liste d’opérations dans le bloc de collecte; ne pas simplement afficher les anciens résultats Exchange. Préserver ce nouvel export, puis reconstruire $records. Vérifier ObjectId, l’utilisateur, l’heure et les informations d’application disponibles. Un compte système ou app@sharepoint exige une analyse du contexte, pas une accusation contre un utilisateur choisi au hasard.

# Replace $operations in the search block, then rerun it in full.
# Its new session ID must not be reused from the mailbox search.
$operations = @(
  'FileRecycled', 'FileDeleted',
  'FileDeletedFirstStageRecycleBin', 'FileDeletedSecondStageRecycleBin',
  'FolderRecycled', 'FolderDeleted'
)
# After searching and preserving the raw records, decode AuditData again.
# Example narrow view; adapt the path to the actual recorded ObjectId.
$records | Where-Object {
  $_.ObjectId -like 'https://contoso.sharepoint.com/sites/Finance/*'
} | Select-Object CreationTime, Id, Operation, UserId, ObjectId, ClientIP

8. Retrouver la suppression d’un utilisateur avec Microsoft Graph

Commencer dans Entra ID > Monitoring & health > Audit logs, avec l’activité Delete user. Vérifier la cible et le résultat, puis l’initiateur. Si l’utilisateur venait d’Active Directory local, poursuivre dans les journaux et le processus de synchronisation : l’événement cloud peut décrire une conséquence.

Pour Graph v1.0, AuditLog.Read.All est la permission de lecture minimale de cette API. En accès délégué, le compte doit aussi avoir un rôle compatible, par exemple Reports Reader; le consentement doit être approuvé. Microsoft.Graph.Reports fournit la cmdlet utilisée. Aucun droit d’écriture au répertoire n’est demandé par ce bloc.

Le filtre vise l’opération initiale Delete user; si rien ne correspond, élargir la recherche aux activités UserManagement de la période et vérifier l’identifiant cible, sans présumer l’absence de suppression. Le paramètre -All gère la pagination; limiter la période réduit le volume.

Conserver TargetResources, InitiatedBy, Result et CorrelationId dans le JSON complet. Un nom d’application n’est pas unique : privilégier AppId et ServicePrincipalId pour poursuivre l’enquête. Hacher aussi cet export selon la méthode précédente.

# Requires Microsoft.Graph.Reports and approved delegated consent
Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome
$targetId = '11111111-2222-3333-4444-555555555555' # Fictional user object ID
$filter = "activityDateTime ge 2026-10-20T12:00:00Z and " +
          "activityDateTime le 2026-10-20T14:00:00Z and " +
          "activityDisplayName eq 'Delete user'"
$events = @(Get-MgAuditLogDirectoryAudit -Filter $filter -All -ErrorAction Stop)
$matches = @($events | Where-Object { $_.TargetResources.Id -contains $targetId })
$matches | Select-Object Id, ActivityDateTime, ActivityDisplayName, Result,
  CorrelationId, @{n='ActorUPN';e={$_.InitiatedBy.User.UserPrincipalName}},
  @{n='ActorUserId';e={$_.InitiatedBy.User.Id}},
  @{n='AppId';e={$_.InitiatedBy.App.AppId}},
  @{n='ServicePrincipalId';e={$_.InitiatedBy.App.ServicePrincipalId}}
# LOCAL WRITE: same protected case directory as above
$events | ConvertTo-Json -Depth 30 |
  Set-Content -LiteralPath (Join-Path $caseDir "entra-$stamp.json") -Encoding utf8

• Microsoft — API directoryAudits et permissions ↗
• Microsoft — propriétés directoryAudit ↗

9. Attribuer une action sans dépasser ce que prouvent les journaux

Exemple fictif : un fichier Finance apparaît supprimé sous le compte d’Alice, mais le client de synchronisation était actif sur deux postes. La conclusion initiale est « suppression enregistrée sous cette identité », avec les éléments corroborants et les inconnues. Si des connexions suspectes apparaissent, traiter aussi le risque de compromission.

• Compte nominatif : l’événement associe une identité à une opération. Il ne prouve pas à lui seul que son propriétaire était au clavier.
• Boîte partagée : distinguer le propriétaire de la boîte et le délégué. Un compte partagé entre plusieurs personnes réduit fortement l’attribution individuelle.
• Application ou automatisation : identifier le principal de service, le traitement, ses propriétaires et ses journaux d’exécution; ne pas remplacer l’identité technique par le nom d’un humain sans preuve.
• Adresse IP : corréler avec les connexions, appareils et heures disponibles. Un VPN, un proxy ou un service intermédiaire peut empêcher d’identifier le poste source.
• Résultat : distinguer tentative et réussite. Une action automatisée de conservation doit être examinée avec sa stratégie et ses traces propres.

10. Aucun résultat : une checklist avant de fermer le dossier

Microsoft indique habituellement 60 à 90 minutes pour l’apparition des événements des principales charges, sans délai garanti. Un résultat vide immédiatement après un test n’est donc pas concluant. Une activation de l’audit après les faits n’ajoute pas les événements qui n’avaient pas été collectés.

11. Restaurer dans un chantier distinct

Identifier le mécanisme adapté, faire approuver la cible exacte et préserver les preuves avant le changement. Un journal d’audit ne contient pas une sauvegarde exploitable du courriel ou du fichier. La conservation légale et la restauration opérationnelle répondent à des objectifs différents.

Tester d’abord sur un objet non critique quand c’est possible. Consigner les changements et prévoir comment corriger une restauration au mauvais emplacement sans supprimer les preuves. Ne jamais lever une conservation ni purger une corbeille pour simplifier le dépannage; consulter les responsables concernés lorsque des obligations s’appliquent.

• Microsoft — rétention des éléments Exchange supprimés ↗
• Microsoft — corbeilles SharePoint ↗
• Microsoft — restauration d’un utilisateur ↗

12. Préparer la prochaine enquête

Dans une boîte et un site de test autorisés, créer puis supprimer un objet sans valeur, noter l’identité et l’heure, attendre l’ingestion et confirmer que l’événement est retrouvable. Ce pilote modifie des données de test : prévoir leur restauration et leur nettoyage contrôlé. Il valide la chaîne de collecte, sans garantir tous les scénarios de production.

Le compte rendu final devrait séparer faits observés, hypothèses, limites et actions : objet touché, opération, identité technique, résultat, sources exportées, lacunes et décision de restauration. Prévoir une rétention adaptée à l’organisation avant le prochain incident.

Les services d’audit Microsoft 365 et d’accompagnement en sauvegarde peuvent aider à valider les droits, la couverture des journaux et les scénarios de récupération. Ce diagnostic ciblé fournit un point de départ; il ne remplace pas une investigation de sécurité complète.