Sauvegarder Microsoft 365 : service natif et solutions tierces

Microsoft Teams n’efface pas vos messages, SharePoint conserve une corbeille à deux niveaux, OneDrive garde 30 jours après désactivation. Cela suffit-il pour parler de sauvegarde ? Non. Une corbeille n’est pas une sauvegarde, et les rétentions natives ne couvrent ni les attaques par rançongiciel qui chiffrent les fichiers de tous les utilisateurs simultanément, ni les suppressions massives volontaires, ni la rétroactivité de plusieurs mois. Ce tutoriel met en place une stratégie de sauvegarde réelle pour Microsoft 365, en combinant le service natif Microsoft 365 Backup et, le cas échéant, un outil tiers pour les contenus que le service natif ne couvre pas.

Article principal : Microsoft 365 pour PME — architecture et gouvernance.

Prérequis

• Un locataire Microsoft 365 actif avec licences attribuées.
• Un abonnement Azure rattaché au locataire pour la facturation à l’usage du service Microsoft 365 Backup (l’abonnement Azure est gratuit à créer ; on n’est facturé que si l’on consomme).
• Un compte avec le rôle Administrateur global ou Administrateur Microsoft 365 Backup.
• Une politique de sauvegarde validée par la direction : quels sites/utilisateurs sauvegarder, quelle durée de rétention, quelles métriques de RTO/RPO cibles.
• Niveau attendu : administrateur Microsoft 365 confirmé, à l’aise avec la facturation Azure.
• Temps : 2 heures pour la mise en place initiale.

Étape 1 — Comprendre les rétentions natives et leurs limites

Microsoft 365 inclut plusieurs filets de sécurité qu’il faut bien connaître pour comprendre ce qu’ils ne couvrent pas. Une boîte aux lettres Exchange Online conserve les courriels supprimés dans le dossier Éléments supprimés (visible par l’utilisateur), puis dans le sous-dossier Deletions du dossier Recoverable Items, accessible par l’utilisateur via Outlook → Récupérer les éléments supprimés. La rétention par défaut est de 14 jours, configurable jusqu’à 30 jours par boîte. À l’expiration, sans politique de conservation Microsoft Purview ni mise en attente Litigation Hold, l’élément est purgé définitivement. Avec une politique de conservation, l’élément reste accessible aux administrateurs via eDiscovery pour la durée fixée par la politique — typiquement plusieurs années.

SharePoint et OneDrive proposent une corbeille à deux niveaux. Le premier niveau est visible par l’utilisateur final, le second niveau (corbeille du site) est accessible aux administrateurs de site. La rétention totale dans cette double corbeille est de 93 jours, fixée et non configurable : au-delà, les fichiers sont purgés du premier ou du second niveau, où qu’ils résident à ce moment (Microsoft documente cette mécanique sur la page Restore deleted sites de SharePoint et dans la documentation de rétention OneDrive). Pour OneDrive après suppression d’un utilisateur, la mécanique est différente : 30 jours par défaut sous le contrôle de Set-SPOTenant -OrphanedPersonalSitesRetentionPeriod, puis 93 jours supplémentaires dans la corbeille de collection de sites avant purge.

Microsoft Teams stocke les messages de conversation 1:1 dans la boîte aux lettres Exchange des participants, et les messages de canal dans la boîte aux lettres du groupe Microsoft 365 associé. Les fichiers échangés vivent dans SharePoint. Les politiques de conservation s’appliquent donc indirectement, par le sous-jacent. Une équipe Teams supprimée disparaît avec son groupe Microsoft 365 ; l’ensemble est restaurable pendant 30 jours.

Ces rétentions natives couvrent la suppression accidentelle isolée. Elles ne couvrent ni le rançongiciel qui chiffre des milliers de fichiers en quelques heures, ni la suppression malveillante par un administrateur compromis, ni le besoin de revenir à un état précis cinq mois en arrière. La sauvegarde au sens propre commence là.

Étape 2 — Activer Microsoft 365 Backup côté tenant

Microsoft 365 Backup est le service natif de sauvegarde introduit par Microsoft. Il sauvegarde les sites SharePoint, les comptes OneDrive et les boîtes Exchange dans la frontière de confiance de Microsoft 365 (les données ne sortent pas du locataire), avec une rétention d’un an maximum. La facturation est à l’usage, à 0,15 USD par Go par mois pour les données protégées (en juin 2024, prix annoncé par Microsoft) — les restaurations elles-mêmes sont gratuites.

L’activation se fait dans le centre d’administration Microsoft 365, section Setup → Microsoft 365 Backup. Au premier accès, on rattache le service à un abonnement Azure (l’abonnement n’est facturé que pour la consommation effective). Une fois lié, le tableau de bord Backup s’ouvre.

# Vérifier l'éligibilité Microsoft 365 Backup côté tenant via Microsoft Graph
Connect-MgGraph -Scopes "BackupRestore-Configuration.Read.All"
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/solutions/backupRestore/serviceStatus"

L’appel retourne le statut du service. Si la propriété service est égale à active, le tenant est correctement provisionné. Si la valeur est inactive, l’activation côté centre d’administration n’est pas encore terminée — on retourne dans Setup → Microsoft 365 Backup pour finaliser le rattachement Azure. Cette vérification programmatique est utile pour scripter le statut dans un tableau de bord global du parc.

Étape 3 — Définir une politique de protection

Une politique de protection désigne ce qui est sauvegardé. On crée trois politiques distinctes en pratique : une pour les sites SharePoint, une pour les comptes OneDrive, une pour les boîtes Exchange. Chaque politique cible explicitement un sous-ensemble (par utilisateur, par groupe de sécurité, par site) ou la totalité des objets du locataire.

Pour une PME, la stratégie qui équilibre couverture et coût consiste à protéger entièrement Exchange (toutes les boîtes) et OneDrive (tous les comptes), et à protéger SharePoint sélectivement : les sites de Direction, RH, Comptabilité, Commercial, et le site concentrateur Intranet. Les sites projet temporaires et les sites d’archives ne sont pas inclus dans cette première phase.

# Création d'une politique de protection SharePoint via Graph
$body = @{
  displayName = "Protection-Sites-Critiques"
  siteProtectionUnits = @(
    @{ siteId = "exemple.sharepoint.com,GUID-direction" },
    @{ siteId = "exemple.sharepoint.com,GUID-rh" },
    @{ siteId = "exemple.sharepoint.com,GUID-comptabilite" },
    @{ siteId = "exemple.sharepoint.com,GUID-commercial" },
    @{ siteId = "exemple.sharepoint.com,GUID-intranet" }
  )
  status = "active"
} | ConvertTo-Json -Depth 4
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/solutions/backupRestore/sharePointProtectionPolicies" -Body $body -ContentType "application/json"

L’appel crée une politique active qui sauvegarde les cinq sites listés. Il faut au préalable récupérer leurs siteId côté SharePoint (Get-PnPSite | Select Id ou via Graph). La création est asynchrone : Microsoft documente un délai d’environ 60 minutes pour le provisionnement initial, puis 60 minutes supplémentaires pour la création des premiers points de restauration. La sortie immédiate ne garantit pas que les sauvegardes sont exploitables ; on revient deux heures plus tard pour valider.

Étape 4 — Comprendre les points de restauration disponibles

Microsoft 365 Backup conserve plusieurs types de points de restauration. Pour SharePoint et OneDrive : un point toutes les 10 minutes pendant les deux semaines précédentes, puis un point hebdomadaire jusqu’à 52 semaines en arrière. Pour Exchange Online : un point toutes les 10 minutes sur les 52 dernières semaines. Cette granularité fine permet, en cas de chiffrement par rançongiciel, de revenir à l’état de la veille à 9h45 plutôt qu’à un point de la semaine précédente.

La restauration s’effectue au choix sur l’URL d’origine (le site est écrasé par sa version sauvegardée) ou sur une nouvelle URL (la sauvegarde devient un site séparé qu’on consulte). Pour un événement de récupération massif après attaque, la restauration sur l’URL d’origine est plus rapide et plus claire pour les utilisateurs. Pour récupérer un fichier précis sans toucher au reste du site, on restaure d’abord sur une nouvelle URL puis on extrait le fichier voulu.

Étape 5 — Compléter par un outil tiers pour ce que Microsoft 365 Backup ne couvre pas

Le périmètre actuel de Microsoft 365 Backup couvre Exchange Online, SharePoint et OneDrive. Il ne couvre pas, à date, les conversations Teams (qui s’appuient sur Exchange et SharePoint, donc une partie est indirectement couverte mais pas le contexte), Microsoft Planner, Microsoft Project for the Web, les bases Dataverse, les flux Power Automate, les applications Power Apps. Pour ces objets, on garde l’option d’un outil tiers.

Les acteurs établis sur ce marché sont Veeam Backup for Microsoft 365, Druva, AvePoint, Barracuda Cloud-to-Cloud Backup, Acronis Cyber Protect Cloud, et Dropsuite. Tous proposent une approche similaire : ils s’authentifient à Microsoft 365 via OAuth (lecture des données via Microsoft Graph), copient les contenus dans un stockage tiers (souvent Azure Blob ou AWS S3), proposent une interface de restauration. La différence se joue sur la profondeur de couverture (Teams chat oui ou non, OneNote oui ou non), la rétention (illimitée chez certains, 1 an chez d’autres), le pays d’hébergement, le mode de facturation (par utilisateur ou par Go).

Pour une PME ouest-africaine, deux critères dominent le choix. La présence d’une zone d’hébergement européenne ou africaine pour la conformité : Veeam, Druva et AvePoint proposent l’Europe (Irlande, Allemagne, France selon l’éditeur). La capacité à payer en monnaie locale via un partenaire revendeur : tous les éditeurs cités ont des distributeurs régionaux qui facturent en francs CFA et acceptent le virement bancaire ou le mobile money via convention.

Étape 6 — Tester une restauration réelle

Une sauvegarde non testée est une non-sauvegarde. On programme un test de restauration dans les 30 jours qui suivent l’activation, puis tous les six mois. Le scénario type consiste à choisir un fichier représentatif (un classeur Excel collaboratif, par exemple), à le supprimer côté production, à attendre la mise à jour du point de restauration suivant, puis à lancer une restauration sur une nouvelle URL et vérifier que le fichier réapparaît avec sa version exacte d’avant suppression.

# Lancement d'une restauration SharePoint via Graph (sur nouvelle URL)
$body = @{
  destinationUrl = "https://exemple.sharepoint.com/sites/restauration-test"
  restorePointDateTime = "2026-05-04T08:30:00Z"
  sourceSiteId = "exemple.sharepoint.com,GUID-comptabilite"
} | ConvertTo-Json
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/solutions/backupRestore/sharePointRestoreSessions" -Body $body -ContentType "application/json"

La requête lance la restauration de l’état du site Comptabilité au 4 mai 2026 à 8h30 vers une nouvelle URL temporaire. La sortie immédiate retourne un identifiant de session. On consulte la progression avec GET sur /solutions/backupRestore/sharePointRestoreSessions/{id} jusqu’à voir le statut completed. Pour un site moyen, Microsoft documente une fenêtre de 30 minutes pour les sites isolés et environ 250 unités de protection à l’heure pour les restaurations massives.

Étape 7 — Documenter le plan de continuité

L’étape qu’aucun outil ne fait à votre place : le plan de continuité écrit. Un document court (3 à 5 pages) qui répond à dix questions. Quelles données sont sauvegardées, par quel outil, avec quelle rétention. Qui peut déclencher une restauration. Quel délai de récupération est acceptable (RTO) et quelle perte maximale de données est acceptable (RPO). Comment communique-t-on aux collaborateurs en cas de crise. Comment vérifie-t-on périodiquement les sauvegardes. Quel est le plan de bascule si Microsoft 365 lui-même est indisponible plusieurs heures.

Ce document est rangé dans le site SharePoint Direction, partagé avec les administrateurs et le sponsor exécutif, et révisé annuellement. C’est lui qu’on sort en cas d’incident, pas l’interface du Backup : l’interface répond aux questions techniques, le document répond aux questions humaines (qui décide, qui informe, dans quel ordre).

Étape 8 — Vérification mensuelle

Un contrôle mensuel léger maintient la confiance dans le dispositif.

# État de la consommation Backup et nombre de points de restauration
Connect-MgGraph -Scopes "BackupRestore-Configuration.Read.All"
$policies = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/solutions/backupRestore/sharePointProtectionPolicies"
foreach ($p in $policies.value) {
  "$($p.displayName) : statut $($p.status) — $($p.siteProtectionUnits.Count) sites protégés"
}

Le rapport liste les politiques actives et le nombre d’objets sous protection. Si le compte d’objets diminue d’un mois sur l’autre, c’est qu’un site a été supprimé ; on documente la cause. Si une politique apparaît en statut autre qu’active, on diagnostique avant qu’un incident ne révèle l’absence de couverture. Cette vérification de cinq minutes par mois est l’assurance que le dispositif vit, plutôt que de découvrir un problème en pleine crise.

Erreurs fréquentes

FAQ

Microsoft sauvegarde-t-il déjà les données par défaut ?

Microsoft assure la résilience de l’infrastructure (réplications géographiques, redondance physique) mais cette résilience couvre la disponibilité du service, pas la récupération des données après une suppression intentionnelle ou un rançongiciel. Le modèle est connu sous le nom de « responsabilité partagée » : Microsoft assure le service, le client est responsable de protéger ses propres données contre les actions humaines (accidentelles ou malveillantes). C’est exactement ce que comble Microsoft 365 Backup et les outils tiers.

Combien coûte Microsoft 365 Backup pour une PME ?

La grille publiée par Microsoft est de 0,15 USD par Go par mois pour les données protégées. Pour 50 boîtes Exchange à 10 Go en moyenne, 50 OneDrive à 20 Go, 5 sites SharePoint à 50 Go, le calcul est : (50×10 + 50×20 + 5×50) × 0,15 = (500+1000+250) × 0,15 = 262,50 USD par mois, soit environ 3 150 USD par an. C’est un coût maîtrisé pour une assurance-vie de cette nature, à comparer au coût réel d’un rançongiciel qui paralyse une PME pendant deux semaines.

Les données sortent-elles du locataire ?

Non. Microsoft 365 Backup conserve les sauvegardes dans la frontière de confiance Microsoft 365 et respecte les exigences de résidence géographique du locataire. Seules quelques métadonnées (identifiant locataire, identifiants de site) sont envoyées à Azure pour la facturation. Pour les outils tiers, c’est différent : les données sortent du locataire vers le stockage du fournisseur, ce qui impose une vigilance accrue sur la résidence et la chiffrement.

Peut-on restaurer un seul fichier sans écraser tout le site ?

Oui. Microsoft 365 Backup propose la restauration granulaire dossier par dossier ou fichier par fichier (en disponibilité générale courant 2026 selon la roadmap publiée par Microsoft). Pour un fichier isolé avant cette disponibilité, la voie est la restauration sur une nouvelle URL puis la copie manuelle du fichier voulu — moins élégant mais opérationnel.

Faut-il garder un outil tiers maintenant que Microsoft 365 Backup existe ?

Cela dépend de la couverture nécessaire. Si la PME utilise Power Apps métier critiques, Power Automate avec données historiques, Dataverse, ou des conversations Teams 1:1 jugées sensibles à archiver intégralement, un outil tiers reste pertinent. Pour une PME dont les usages se limitent à Outlook, OneDrive, SharePoint et l’usage standard de Teams, Microsoft 365 Backup natif suffit.

Tutoriels associés

• Structurer SharePoint Online — sites et bibliothèques
• Gouverner Microsoft Teams — nommage, cycle de vie, archivage
• Retour au guide : Microsoft 365 pour PME — architecture et gouvernance

Ressources officielles

• Vue d’ensemble Microsoft 365 Backup — Microsoft Learn
• API Microsoft Graph Backup & Restore
• Période de grâce et désactivation Microsoft 365 Backup
• Résilience native SharePoint et OneDrive
• SharePoint — restauration des sites supprimés (rétention 93 jours)
• OneDrive — rétention et suppression (corbeille de collection 93 jours)
• Politiques de conservation Microsoft Purview