Sauvegarde et PRA en PME : tester la restauration

La seule preuve qu’une sauvegarde fonctionne reste le test de restauration : il remet des données en service, chronomètre l’opération et vérifie l’âge de la copie obtenue. En PME, quatre niveaux de tests (fichier, boîte de messagerie, machine virtuelle, restauration complète isolée), consignés dans un journal, alimentent un plan de reprise d’activité écrit et éprouvé.

Ce qu’un test de restauration démontre

La console de sauvegarde affiche des tâches terminées sans erreur. Ce compte rendu atteste qu’une copie a été écrite, pas qu’elle se relit, ni que l’application redémarre. Les échecs découverts le jour d’un sinistre ont des causes banales :

• un catalogue perdu avec le serveur qui l’hébergeait ;
• une clé de chiffrement introuvable ;
• un volume sorti du périmètre lors d’une migration ;
• une base copiée à chaud, incohérente au redémarrage ;
• une remise en service trop longue pour l’activité.

Deux seuils fixés par la direction

Un test se juge à l’aune d’objectifs écrits, les RPO et RTO de chaque application. Le RPO (recovery point objective) exprime en temps la quantité de données que l’entreprise accepte de perdre ; le RTO (recovery time objective), la durée d’interruption tolérable. Le guide de l’ANSSI « Sauvegarde des systèmes d’information », révisé en novembre 2025, les nomme perte de données maximale admissible (PDMA) et durée maximale d’interruption admissible (DMIA).

Ces seuils relèvent de la direction : combien de saisies refaire, combien d’heures sans facturer, la réponse diffère entre comptabilité, messagerie et production. Le même guide pose une limite utile : une PDMA inférieure à vingt-quatre heures dépasse ce que couvre la sauvegarde et appelle de la réplication. Chaque test compare ensuite le temps mesuré à la DMIA, l’âge de la copie à la PDMA.

Qui teste, et à quel rythme

Le test gagne à être mené par une autre personne que celle qui configure les sauvegardes : un regard extérieur repère l’exclusion oubliée ou la procédure connue de son seul auteur. Le rythme suit une logique simple : plus le test est léger, plus il revient souvent, et chaque changement notable appelle un contrôle dédié.

Dans une petite structure sans équipe informatique dédiée, ces contrôles relèvent de l'infogérance des TPE et PME telle que la pratique Expertis’IT, prestataire lillois de l’informatique et des télécoms : il surveille les tâches de sauvegarde, les droits d’accès et la rétention, mène des restaurations calibrées sur le périmètre réel et documente le plan de reprise, tenu à jour dans le suivi courant du parc. L’intérêt, à ce stade, tient à la prise en charge de bout en bout : un diagnostic de ce qui est réellement protégé, un plan de corrections classé par priorité, une mise en œuvre qui n’interrompt pas le travail des équipes, puis des comptes rendus archivés.

Chaque compte rendu se lit sans bagage technique : date, éléments restaurés, copie utilisée, durée, écart avec les objectifs validés. La direction y trouve la preuve que la sauvegarde rend le service attendu, et un responsable informatique interne un appui solide lors des arbitrages budgétaires.

Trois copies, dont une hors d’atteinte

Le guide de l’ANSSI recommande d’appliquer la règle 3-2-1 : trois copies distinctes des données, soit la production et deux sauvegardes conservées sur des supports différents, l’une d’elles hors ligne. Il juge cette copie hors ligne indispensable, même moins fréquente que les sauvegardes locales : bande magnétique ou disque déconnecté, rangé ailleurs.

Autre option, le WORM (écriture unique, lectures multiples) : ce stockage immuable interdit toute modification d’une donnée après écriture. Le guide l’estime envisageable mais tient la copie hors ligne pour plus robuste ; son compromis : des sauvegardes régulières sur support immuable, complétées par des copies hors ligne plus espacées.

Cybermalveillance.gouv.fr, dans sa fiche « Pourquoi et comment bien gérer ses sauvegardes ? » mise à jour en septembre 2026, conseille de déconnecter le support après usage : un rançongiciel qui atteint les postes peut aussi chiffrer une copie restée branchée. Pour les tests, chaque copie se restaure à son tour, la copie hors ligne en priorité : c’est elle qui servira après une attaque.

Quatre tests, du fichier au système entier

Chaque niveau vérifie une chose différente.

Le fichier ou le dossier

Tirez au hasard quelques fichiers dans des partages différents, restaurez-les depuis un point ancien vers un emplacement distinct de l’original, puis ouvrez-les avec leur application. Contrôlez aussi les droits d’accès : un dossier revenu lisible par tous crée un autre problème.

La boîte de messagerie

Restaurer une boîte entière vers une boîte de test, sans écraser l’originale, révèle ce que l’échantillon masque : arborescence, calendrier, contacts, pièces jointes volumineuses. Le test vaut aussi pour une messagerie hébergée, dont la copie dépend d’un outil tiers.

La machine virtuelle

La machine restaurée démarre dans un réseau isolé de la production, pour éviter tout doublon d’adresse ou de nom. Le test réussit quand le service répond : application qui accepte une connexion, base cohérente, tâches planifiées qui repartent. Notez le temps écoulé jusqu’au premier utilisateur servi.

La restauration complète sur environnement isolé

Au dernier niveau, la restauration complète reconstruit l’ensemble dans l’ordre du plan de reprise : annuaire et DNS, stockage, bases, applications, puis un poste témoin. Elle se mène sur du matériel de secours ou un espace cloud fermé, de préférence depuis la copie hors ligne, chronomètre en main face à la DMIA. Elle seule fait apparaître les dépendances oubliées, comme un serveur de licences ou un certificat expiré.

Tenir le journal

Chaque essai laisse une ligne dans le journal des tests, conservé hors du système sauvegardé :

• date, auteur et niveau de test ;
• périmètre et point de restauration utilisés ;
• durée mesurée face au RTO, âge de la copie face au RPO ;
• anomalies, correctif décidé et échéance.

Un journal sans la moindre anomalie pendant des mois mérite un doute : tests trop faciles, ou jamais faits.

Le plan de reprise, écrit pour un lecteur absent

Un PRA, ou plan de reprise d’activité, détaille la remise en route de l’informatique après un sinistre : quoi relancer, dans quel ordre, avec quels moyens. Il doit rester exécutable par une personne qui n’a pas monté l’infrastructure, en pleine nuit, sans accès au serveur qui le stocke. Il rassemble :

• l’ordre de redémarrage, déduit des dépendances : réseau, annuaire et DNS, stockage, bases, applications, postes ;
• les contacts : direction, référent informatique, prestataires, éditeurs, opérateur, assureur ;
• les accès de secours : compte d’administration d’urgence hors annuaire, secrets et clés de chiffrement conservés hors ligne ;
• de quoi reconstruire la sauvegarde elle-même : médias d’installation, catalogue, procédure d’import.

Le plan existe aussi sur papier, hors du local technique, et se corrige après chaque restauration complète selon l’ordre réellement suivi.

Rançongiciel : des copies hors de portée

Le guide de l’agence cité plus haut le souligne : un attaquant tente souvent de chiffrer, d’effacer ou de rendre indisponible l’infrastructure de sauvegarde, pour ralentir la reconstruction et peser sur la rançon. Il en découle quatre mesures pour des sauvegardes isolées :

• des comptes d’administration de la sauvegarde nominatifs et dédiés, distincts des comptes utilisés au quotidien ;
• une console protégée par l’authentification multifacteur sur les comptes sensibles ;
• un serveur de sauvegarde cloisonné, joignable depuis le seul réseau d’administration ;
• une procédure d’isolement d’urgence de l’infrastructure de sauvegarde, prévue d’avance.

Après une attaque, les copies récentes peuvent contenir les outils de l’intrus : systèmes réinstallés depuis des images de confiance, données analysées avant réimport, point de restauration antérieur à la compromission. La restauration complète annuelle gagne à simuler ce scénario. Le contexte de la menace figure dans le panorama des cybermenaces visant les PME.

Microsoft 365 : la plateforme tourne, les données vous restent

Microsoft répartit les rôles dans sa page « Shared responsibility in the cloud » sur Microsoft Learn, mise à jour en août 2026 : quel que soit le déploiement, le client conserve la responsabilité de ses données et de ses identités. Pour Microsoft 365, cette responsabilité partagée confie à l’éditeur centres de données, serveurs et systèmes d’exploitation, et laisse à l’entreprise ses données, sa configuration et ses comptes.

La rétention intégrée ne remplace pas une copie indépendante. Pour Exchange Online, la page « Recoverable Items folder in Exchange Online » indique qu’un élément supprimé reste récupérable 14 jours par défaut, 30 jours au plus, puis disparaît. Une suppression découverte tard ou un compte compromis qui purge une boîte échappe à ce filet. Une sauvegarde tierce de la messagerie, de OneDrive et de SharePoint se teste donc comme le reste. La responsabilité des données ne migre pas davantage lors d’une bascule des serveurs vers le cloud.

Prochaine étape : choisir un fichier, une boîte et une machine virtuelle, les restaurer cette semaine en chronométrant chaque opération, puis consigner les résultats dans un premier journal. L’écart avec les objectifs fixés par la direction désignera le chantier prioritaire.

Questions courantes sur les tests de restauration

À quelle fréquence tester une restauration ?

Aucune période universelle ne s’impose : la fréquence découle des objectifs de reprise et du rythme des changements. Un calendrier tenable en PME prévoit un échantillon de fichiers chaque mois, une boîte de messagerie et une machine virtuelle à tour de rôle au fil de l’année, et une restauration complète isolée au moins une fois par an. S’y ajoutent un test après chaque migration, nouveau serveur ou mise à jour majeure de l’outil de sauvegarde, et après tout incident.

Microsoft 365 sauvegarde-t-il les données de l’entreprise ?

Microsoft prend en charge l’infrastructure de son service, mais sa documentation sur la responsabilité partagée laisse au client la protection de ses données et de ses comptes. Les mécanismes natifs restent des filets limités dans le temps : selon Microsoft Learn, un site SharePoint supprimé est conservé 93 jours, puis effacé définitivement avec son contenu. Une copie indépendante, administrée par un compte distinct et vérifiée par des restaurations réelles, couvre les suppressions tardives et les comptes compromis.

Quelle différence entre un PCA et un PRA ?

Le plan de continuité d’activité (PCA) maintient les fonctions vitales pendant l’incident, au besoin en mode dégradé : site de repli, procédures manuelles. Le plan de reprise d’activité (PRA) organise le retour à la normale après l’arrêt : restauration des données, redémarrage des systèmes dans l’ordre prévu, vérifications avant remise aux utilisateurs. Une PME commence en général par le PRA, adossé à des sauvegardes testées, puis ajoute des mesures de continuité pour ses activités sensibles.

Combien de temps conserver les sauvegardes ?

La durée de conservation se décide par type de donnée et par risque, pas selon le réglage par défaut du logiciel. Le guide de l’ANSSI sur la sauvegarde cite en exemple une répartition étagée : quinze jours de sauvegardes journalières, un an de mensuelles, cinq ans d’annuelles. La rétention doit couvrir le délai de détection d’une suppression ou d’une intrusion, tout en respectant les durées prévues pour les données personnelles, à valider avec le délégué à la protection des données.