Ce que Microsoft 365 ne restaurera jamais à votre place

Que dit exactement le modèle de responsabilité partagée ?

Microsoft publie un principe simple, que peu de dirigeants ont lu : dans le cloud, la responsabilité se partage entre le fournisseur et le client, et la ligne de partage dépend du type de service.

Pour un service en mode logiciel comme Microsoft 365, Microsoft prend en charge l'infrastructure physique, les serveurs, le réseau, la disponibilité de la plateforme et la sécurité du service lui-même. Trois éléments restent toujours du côté du client, quel que soit le modèle : les données, les identités et les accès, et la configuration des appareils.

Autrement dit : vos données vous appartiennent, donc leur intégrité, leur conservation et leur récupération vous appartiennent aussi. Microsoft s'engage à ne pas les perdre par sa faute. Il ne s'engage pas à vous les rendre après votre propre erreur.

La confusion vient du fait que la plateforme est très fiable. Elle réplique les données entre centres, elle bascule automatiquement en cas de panne, elle propose des corbeilles. Tout cela ressemble à une sauvegarde. Rien de tout cela n'en est une.

Quelle différence entre une corbeille et une sauvegarde ?

La distinction tient en trois critères, et une corbeille échoue sur les trois.

• La durée. Une corbeille conserve quelques semaines. Une sauvegarde conserve des mois ou des années, selon votre politique.
• L'indépendance. Une corbeille vit dans le même système que la donnée d'origine. Un compte administrateur compromis peut la vider. Une sauvegarde tierce est hors de portée du tenant.
• La granularité de restauration. Une corbeille rend un élément. Une sauvegarde rend un état complet à une date donnée : une boîte aux lettres entière, une bibliothèque, une arborescence, avec les permissions.

Ce troisième point est le plus sous-estimé. Après un incident sérieux, la question n'est pas « où est ce fichier », mais « comment revenir à mardi dernier sur l'ensemble d'un service ». Une corbeille ne répond pas à cette question.

Un quatrième critère mérite d'être ajouté : le délai de découverte. La plupart des pertes de données ne sont pas constatées le jour où elles surviennent. Un dossier client effacé par erreur lors d'un rangement de fin d'année se remarque au moment où quelqu'un le cherche, c'est-à-dire souvent des mois plus tard. Une politique de conservation se dimensionne donc sur le délai réaliste de découverte, pas sur le délai théorique de réaction.

Combien de temps vos données restent-elles récupérables ?

Le tableau ci-dessous donne les durées par défaut des principaux services. Ce sont des valeurs par défaut : elles sont modifiables par l'administrateur, elles varient selon le plan, et Microsoft les fait évoluer. Vérifiez-les sur votre propre tenant à date.

Deux lignes méritent un commentaire.

L'historique de versions n'est pas une protection temporelle. Il conserve un nombre de versions, pas une profondeur en jours. Un ransomware qui chiffre puis rechiffre les fichiers consomme les versions disponibles en quelques passages.

La conservation Purview est une politique de rétention légale, pas un outil de reprise. Elle empêche la disparition d'un contenu et permet de le retrouver par recherche. Elle ne reconstruit pas une bibliothèque avec sa structure et ses permissions.

Que se passe-t-il après un ransomware ou un départ ?

Deux scénarios concrets, parce que ce sont ceux qui arrivent réellement.

Le ransomware. Le poste d'un utilisateur est compromis. Son OneDrive est synchronisé, les fichiers chiffrés remontent dans le cloud, la synchronisation propage le chiffrement sur les bibliothèques partagées auxquelles il a accès. Microsoft n'a rien à détecter d'anormal : ce sont des écritures légitimes par un compte légitime. La restauration repose alors sur l'historique de versions, qui peut avoir été consommé, ou sur une sauvegarde tierce. L'origine du problème est presque toujours une identité compromise, sujet que nous traitons dans notre article sur les limites du MFA en 2026.

Le départ de salarié. Un commercial quitte l'entreprise. Pour économiser une licence, son compte est supprimé le jour même. Six mois plus tard, un litige impose de retrouver ses échanges avec un client. La boîte n'existe plus. La bonne pratique est l'inverse : convertir la boîte en boîte partagée, transférer les fichiers OneDrive vers un espace d'équipe, et seulement ensuite libérer la licence. Ce sujet touche directement les organisations soumises à des obligations de conservation, notamment les cabinets d'expertise comptable.

Un troisième scénario, plus banal, produit autant de dégâts : la suppression massive par erreur. Un utilisateur qui synchronise une bibliothèque volumineuse sur un poste dont le disque se remplit, une resynchronisation qui tourne mal, et plusieurs milliers de fichiers disparaissent côté cloud. L'opération est légitime du point de vue du système. La restauration élément par élément depuis la corbeille est théoriquement possible, mais elle devient impraticable au-delà de quelques centaines de fichiers, et elle ne restitue pas toujours l'arborescence d'origine.

Dans les trois cas, la perte n'est pas causée par une défaillance de Microsoft. Elle est causée par une hypothèse fausse sur ce que Microsoft fait.

Que faut-il mettre en place, concrètement ?

Notre position est nette : une sauvegarde tierce de Microsoft 365 n'est pas une option de confort, c'est une brique de base, au même titre que l'antivirus. Elle doit couvrir Exchange Online, SharePoint, OneDrive et Teams.

Quatre critères déterminent la qualité du dispositif.

1. L'immuabilité. Les points de restauration ne doivent pas pouvoir être supprimés, y compris par un administrateur du tenant compromis.
2. La séparation. Le stockage de sauvegarde doit être indépendant du tenant, avec des identifiants distincts.
3. La profondeur de rétention. Elle se décide à partir de vos obligations légales et de vos délais de découverte d'incident, pas à partir du prix.
4. Le test de restauration. Au moins une restauration réelle par an, chronométrée, portant sur une boîte aux lettres complète et sur une bibliothèque avec ses permissions — pas sur un fichier isolé, qui ne prouve rien.

À cela s'ajoutent trois réglages internes gratuits, souvent négligés : allonger la rétention des éléments récupérables au maximum autorisé, activer la conservation sur les boîtes sensibles, et définir une procédure écrite de sortie de salarié.

Par où commencer sur ce sujet ?

Le déroulé d'une mission de mise à niveau tient en quatre étapes.

Étape 1 — État des lieux, une demi-journée. Relevé des durées de rétention réellement appliquées sur votre tenant, des politiques de conservation existantes et de la présence ou non d'une sauvegarde tierce. Livrable : un tableau de ce qui est récupérable et pendant combien de temps.

Étape 2 — Définition de la cible, quelques jours. Confrontation de vos obligations légales et contractuelles avec les durées constatées. C'est le moment où l'on décide ce que l'on conserve, combien de temps et pourquoi.

Étape 3 — Mise en œuvre. Réglages de rétention, politiques de conservation, procédure de départ de salarié, et déploiement de la sauvegarde tierce si elle est retenue. Ce chantier s'articule avec le durcissement général du tenant décrit dans notre page sécurité Microsoft 365.

Étape 4 — Test et surveillance. Restauration test documentée, puis suivi des travaux de sauvegarde dans le cadre d'une infogérance Microsoft 365. Une sauvegarde en échec silencieux depuis trois mois est le pire des scénarios : elle donne une confiance qui n'existe pas.

L'absence de sauvegarde tierce n'est presque jamais un choix assumé : elle résulte d'une confusion, la rétention native de Microsoft 365 ayant été prise pour une sauvegarde. Personne n'a donc jamais eu à arbitrer, ni à écrire ce que l'entreprise accepte de perdre. Le point de départ est toujours la même question posée à la direction : combien de jours de données pouvez-vous perdre sans que l'activité s'arrête. Tant que ce chiffre n'est pas écrit quelque part, aucune décision de sauvegarde n'est possible.