Comment tester réellement une sauvegarde : fichier, dossier, machine complète

1. Définir le périmètre : ce qui doit être restaurable

Un test de restauration commence par une question métier, pas par un outil : de quelles données l'entreprise a-t-elle besoin pour fonctionner demain matin ? La réponse dessine le périmètre à prouver — serveurs, applications, postes, données cloud — et c'est ce périmètre, pas la configuration existante de l'outil de sauvegarde, qui sert de référence au protocole.

Cette étape révèle souvent le premier écart : des données critiques absentes des travaux de sauvegarde. Un test ne peut valider que ce qui est effectivement sauvegardé ; si un dossier partagé, une base métier ou un poste sensible manque au périmètre, aucune restauration d'essai ne le fera apparaître. Croisez donc la liste des besoins métier avec la configuration réelle avant de tester quoi que ce soit.

• Serveurs et machines virtuelles, applications et bases de données métier
• Postes de travail détenant des données locales
• Microsoft 365 : boîtes aux lettres, fichiers OneDrive, sites SharePoint, espaces Teams
• Dossiers partagés et données soumises à des obligations de conservation

2. Préparer le test sans toucher à la production

Un test de restauration ne doit pas créer l'incident qu'il cherche à prévenir. La règle de base : restaurer vers un emplacement alternatif — un dossier de test, une machine virtuelle isolée du réseau de production, une boîte aux lettres dédiée — et non par-dessus les données en exploitation. L'isolement permet de démarrer une machine restaurée sans conflit d'adresses ni doublon d'identité sur le réseau.

Préparez aussi le cadre : qui réalise le test, à quelle date, avec quels accès, et selon quels critères de réussite. Ces critères se fixent avant de lancer la restauration : le fichier s'ouvre et son contenu est conforme, l'application démarre et accepte une connexion, les données correspondent à la date attendue. Sans critères posés à l'avance, on conclut trop vite que « ça a marché ».

3. Tester la restauration d'un fichier, puis d'un dossier

Le premier niveau du protocole est granulaire. Restaurez un fichier récent : il valide le cycle courant de sauvegarde. Restaurez ensuite un fichier ancien, proche de la limite de rétention : il vérifie que la profondeur d'historique prévue existe réellement. Dans les deux cas, ne vous contentez pas de constater la présence du fichier restauré : ouvrez-le, contrôlez son contenu et son horodatage.

Poursuivez avec un dossier complet, droits d'accès compris : une arborescence restaurée dont les permissions ont disparu peut bloquer une équipe aussi sûrement qu'une donnée perdue. Si vous utilisez Microsoft 365, ce niveau s'applique aussi au cloud : restaurez un message, un fichier OneDrive ou un document SharePoint depuis la sauvegarde indépendante du tenant. Les corbeilles natives, conçues pour la suppression accidentelle récente, ne constituent pas ce test.

4. Tester la restauration d'une machine complète

C'est le niveau qui sépare une sauvegarde de fichiers d'une capacité de reprise. Restaurez une machine virtuelle ou une image de serveur vers l'environnement isolé préparé à l'étape précédente, puis allez au bout du scénario : la machine démarre, une session s'ouvre, l'application métier se lance, la base de données répond. Une image qui se restaure mais ne démarre pas est un échec du test, pas une réussite partielle.

Chronométrez l'opération de bout en bout, préparation comprise. Cette durée réelle se compare à l'objectif de délai de reprise (RTO) que vous vous êtes fixé — ou à celui formalisé dans votre contrat de service. C'est ce test qui révèle les écarts invisibles sur le papier : dépendances entre serveurs, ordre de redémarrage, restauration depuis la copie hors site plus longue qu'attendu. Mieux vaut les découvrir en exercice qu'en pleine crise.

5. Consigner la preuve écrite du test

Un test sans compte rendu ne laisse rien : quelques mois plus tard, personne ne peut dire ce qui a été vérifié, ni quand, ni avec quel résultat. Chaque exercice produit donc un document daté : périmètre restauré, copie utilisée (locale ou hors site), durée mesurée, résultat au regard des critères définis, écarts constatés, actions correctives décidées, nom du testeur.

Cette preuve écrite a des destinataires concrets : la direction, qui arbitre les budgets en connaissance de cause ; l'assureur ou le client donneur d'ordre, qui peuvent la demander ; l'auditeur, le jour d'une vérification. Et si vos sauvegardes sont opérées par un prestataire, le compte rendu de test est un livrable à exiger, pas une faveur.

6. Répéter chaque trimestre, en variant le périmètre

Un test réussi valide un instant, pas une année : le système d'information change, les volumes croissent, les outils évoluent. Le rythme que nous appliquons est trimestriel — des rendez-vous inscrits au calendrier, avec compte rendu à chaque échéance. D'un trimestre à l'autre, faites tourner les éléments testés : un serveur différent, une autre application, une restauration depuis la copie hors site plutôt que locale, un élément Microsoft 365.

Ajoutez des tests hors calendrier après tout changement significatif : nouveau serveur, migration d'application, changement d'outil ou de destination de sauvegarde. Enfin, si l'exploitation est confiée à un prestataire, la fréquence des tests et leur périmètre se formalisent dans le contrat de service, au même titre que les objectifs de reprise (RTO) et de perte de données maximale (RPO).