3 Le stockage des sauvegardes Microsoft 365 est une question que la plupart des organisations ne se posent qu’au moment où une suppression, le départ d’un employé ou un incident de ransomware les y oblige. L’hypothèse semble raisonnable : les données résident dans le cloud de Microsoft, Microsoft exploite une infrastructure de premier ordre, donc les données sont forcément protégées. Les deux premières affirmations sont vraies. La troisième n’en découle pas, et Microsoft le dit lui-même : son contrat de services recommande de sauvegarder régulièrement le contenu des clients à l’aide de services tiers. Cet article explique pourquoi les données M365 ont besoin de leur propre sauvegarde, ce que les options natives de Microsoft offrent réellement en 2026, et le point qui reçoit le moins d’attention et cause le plus de regrets : l’endroit où ces sauvegardes doivent être stockées. Pourquoi les données Microsoft 365 ont toujours besoin d’une sauvegarde Microsoft 365 fonctionne selon un modèle de responsabilité partagée (en anglais) : Microsoft est responsable du bon fonctionnement du service (disponibilité, redondance, disponibilité des datacenters), et le client est responsable des données qu’il contient, des identités qui y accèdent et des politiques qui les conservent. La réplication de Microsoft protège contre les défaillances de Microsoft, pas contre les vôtres. Elle réplique fidèlement un OneDrive chiffré par un ransomware, une boîte aux lettres purgée par un compte administrateur compromis et un site SharePoint supprimé par erreur. La liste des menaces est banale plutôt qu’exotique : suppression accidentelle découverte après le vidage de la corbeille, initiés malveillants, identifiants d’administrateur compromis, clients de synchronisation propageant des fichiers chiffrés, et politiques de conservation mal configurées sans que personne ne s’en aperçoive avant d’avoir besoin d’une restauration. Aucune de ces situations n’est une panne, donc aucune ne relève de Microsoft. La conservation n’est pas une sauvegarde M365 intègre des mécanismes qui ressemblent à une protection : corbeilles, historique des versions, conservation pour litige (litigation hold), politiques de conservation. Ils ont une réelle utilité, principalement pour la conformité, et un tenant bien géré les configure délibérément en complément d’une véritable politique de conservation des données (en anglais). Ce qu’ils ne fournissent pas, c’est une copie restaurable à un instant donné, stockée en dehors du tenant. Les corbeilles se vident selon des calendriers qui se comptent en jours ou en semaines. L’historique des versions aide pour un fichier, pas pour revenir en arrière sur dix mille fichiers chiffrés. Et tout ce que contiennent ces mécanismes se trouve dans le même tenant, accessible avec les mêmes identifiants compromis que ceux à l’origine de l’incident. La conservation répond à la question « pouvons-nous prouver ce qui existait ? » ; la sauvegarde répond à « pouvons-nous le récupérer ? ». Ce sont deux missions différentes. Le service de sauvegarde de Microsoft, évalué en toute franchise Depuis 2024, Microsoft propose son propre service payant Microsoft 365 Backup, qui effectue des sauvegardes à un instant donné d’Exchange Online, OneDrive et SharePoint, et les restaure nettement plus vite qu’une fouille dans les corbeilles. Pour la seule rapidité de restauration après des incidents courants, c’est une option crédible, et elle suffira à certaines organisations. Sa caractéristique structurelle mérite toutefois un examen lucide : les sauvegardes sont stockées dans l’infrastructure de Microsoft, avec une conservation pouvant aller jusqu’à environ un an, en 2026. La copie de dernier recours partage donc le même fournisseur, le même plan de contrôle et la même relation de facturation que les données qu’elle protège. Pour les organisations dont la planification de la restauration intègre une défaillance du fournisseur, la compromission de compte, des litiges contractuels ou les questions des régulateurs sur l’existence de copies indépendantes, une sauvegarde qui ne quitte jamais la plateforme ne respecte pas la discipline 3-2-1, et encore moins la stratégie de sauvegarde 3-2-1-1-0 (en anglais), plus stricte, qui ajoute une copie immuable et vérifiée. La cible de stockage : où stocker les sauvegardes Microsoft 365 La sauvegarde M365 tierce se décompose en deux décisions souvent confondues : le logiciel de sauvegarde (les leaders du marché sauvegardent tous correctement Exchange, OneDrive, SharePoint et Teams) et la cible de stockage sur laquelle il écrit. La décision logicielle attire l’attention ; la décision relative à la cible détermine ce qu’un attaquant peut atteindre et ce que coûte une restauration importante. Quatre propriétés comptent pour la cible. L’indépendance : elle doit se situer en dehors du périmètre de confiance de M365, afin qu’une compromission au niveau du tenant ne puisse pas l’atteindre. L’immuabilité : les sauvegardes verrouillées avec S3 Object Lock (en anglais) ne peuvent être ni chiffrées ni supprimées pendant leur période de conservation, même avec des identifiants volés du serveur de sauvegarde, ce qui constitue le socle d’une sauvegarde à l’épreuve des ransomwares. L’économie de la restauration : les incidents M365 touchent souvent tout le tenant, et rapatrier des dizaines de téraoctets à travers le compteur d’egress d’un fournisseur cloud ajoute une mauvaise surprise à cinq chiffres à une semaine déjà difficile, ce qui plaide pour une cible que vous possédez ou sans facturation de sortie au gigaoctet. Enfin, la marge de capacité, car c’est dans la section suivante que la plupart des conceptions sous-estiment les besoins. Dimensionnement et économie Un parc de sauvegardes M365 est toujours plus volumineux que le tenant qu’il protège. Les copies quotidiennes à un instant donné multiplient l’empreinte source par le calendrier de conservation ; la prolifération des versions dans OneDrive et SharePoint aggrave le phénomène ; et les archives de messagerie ne font que croître. Un tenant de quelques téraoctets produit couramment un parc de sauvegardes de plusieurs dizaines de téraoctets en un an, et les organisations soumises à des obligations de conservation pluriannuelles atteignent les centaines de téraoctets autrefois réservées aux serveurs de fichiers. Les déploiements réels le confirment : le parc de sauvegardes M365 d’une seule banque peut dépasser 500 To. Ce profil de croissance explique pourquoi la cible doit évoluer par ajout de capacité plutôt que par remplacement complet, et pourquoi le chiffre à comparer est le coût par téraoctet stocké sur toute la période de conservation, et non la facture de la première année. Le stockage objet est devenu la réponse par défaut : il évolue sur place, parle l’API S3 sur laquelle le logiciel de sauvegarde écrit déjà et applique nativement l’immuabilité. Check-list : évaluer le stockage des sauvegardes Microsoft 365 Existe-t-il une copie de vos données M365 en dehors de l’infrastructure et du périmètre de confiance de Microsoft ? Au moins une copie est-elle immuable pendant toute sa période de conservation, intouchable même avec des identifiants d’administrateur ? Pouvez-vous restaurer une seule boîte aux lettres, une seule version de fichier ET l’ensemble du tenant, et avez-vous chronométré cette dernière restauration ? Que coûte une restauration complète du tenant en egress et en heures, et qui l’a testée ? La croissance prévue (calendrier de conservation multiplié par la taille source, plus les versions) tient-elle sur la cible pendant 3 à 5 ans ? Les politiques de conservation et les calendriers de sauvegarde ont-ils des responsables nommés, plutôt que des valeurs par défaut supposées ? Si le service natif Microsoft 365 Backup fait partie du plan, sa résidence au sein de la plateforme est-elle un risque accepté et documenté ? Synthèse Le stockage des sauvegardes Microsoft 365 est un problème résolu que la plupart des organisations n’ont tout simplement pas encore résolu. Le raisonnement est court : Microsoft protège le service, vous protégez les données ; les mécanismes de conservation servent la conformité, pas la restauration ; le service de sauvegarde de Microsoft est rapide mais réside dans la plateforme qu’il protège ; une conception complète ajoute donc une sauvegarde tierce écrivant sur une cible indépendante, immuable et économiquement restaurable. Dimensionnez-la en fonction du calendrier de conservation plutôt que du tenant, testez la restauration complète avant le jour J, et la plateforme SaaS sur laquelle repose votre activité cesse d’être l’unique copie de tout ce qu’elle produit. Questions fréquentes Microsoft ne sauvegarde-t-il pas déjà Microsoft 365 ? Microsoft réplique les données pour assurer la résilience du service et propose des corbeilles et des périodes de conservation, mais dans le cadre du modèle de responsabilité partagée, vos données relèvent de votre responsabilité, et le contrat de services de Microsoft recommande une sauvegarde tierce. La réplication protège contre les pannes matérielles de Microsoft, pas contre la suppression, la compromission ou les ransomwares dans votre tenant. Le service payant Microsoft 365 Backup suffit-il ? Il restaure rapidement après des incidents courants et peut convenir aux organisations aux exigences modestes. Ses sauvegardes résident dans l’infrastructure de Microsoft, avec une conservation pouvant aller jusqu’à environ un an en 2026 ; il ne fournit donc ni copie indépendante, ni conservation pluriannuelle, ni protection contre les défaillances au niveau de la plateforme ou du compte. À quoi ressemble la règle 3-2-1 pour M365 ? Le tenant de production constitue la première copie. Une sauvegarde tierce sur un stockage indépendant constitue la deuxième, idéalement sur un support ou une plateforme différents du tenant. Une troisième copie, hors site ou hors ligne, complète le dispositif, et les pratiques actuelles y ajoutent une copie immuable et des restaurations vérifiées (3-2-1-1-0). Les sauvegardes qui ne quittent jamais le cloud de Microsoft comptent peu, puisqu’elles partagent le domaine de défaillance du tenant. De combien de stockage la sauvegarde M365 a-t-elle réellement besoin ? Prévoyez un multiple de la taille du tenant, déterminé par la durée de conservation, la fréquence des sauvegardes et la croissance des versions. Les tenants de quelques téraoctets produisent couramment des parcs de sauvegardes de plusieurs dizaines de téraoctets en un an, et la conservation pluriannuelle pousse les grandes organisations vers les centaines de téraoctets. Modélisez la conservation multipliée par la taille source, puis ajoutez la croissance des versions. Pourquoi l’immuabilité est-elle particulièrement importante pour les sauvegardes M365 ? Parce que les incidents M365 passent généralement par les identifiants, et que des identifiants capables de supprimer des données de production peuvent souvent atteindre aussi les sauvegardes. L’immuabilité au niveau du stockage (comme S3 Object Lock en mode conformité) signifie que la sauvegarde ne peut être ni chiffrée ni supprimée pendant la conservation, quelle que soit la personne qui détient les clés, ce qui transforme un incident touchant tout le tenant en simple exercice de restauration. Pour aller plus loin Contexte plus large : stratégie de sauvegarde d’entreprise (en anglais), tests de vérification des sauvegardes et restauration instantanée de VM (en anglais).
