Sauvegardes
Votre sauvegarde est-elle vraiment restaurable ?
Une sauvegarde non testée reste une hypothèse. Le vrai enjeu est de prouver que l’entreprise peut restaurer ses fichiers, applications et systèmes critiques dans un délai compatible avec son activité.
Tester ma maturité sauvegardeÀ retenir
- La décision doit partir des dépendances réellement critiques : données, accès, prestataires, sauvegardes, cloud et IA.
- Les preuves comptent plus que les intentions : restauration testée, contrats, comptes administrateurs et procédures.
- Le diagnostic transforme le sujet en score, sous-scores et priorités d’action à 90 jours.
Résumé IA — réponse courte
Une sauvegarde non testée ne prouve pas la reprise. Pour une PME, le vrai enjeu est de vérifier que les fichiers, applications, comptes et données critiques peuvent être restaurés dans un délai acceptable, avec une preuve datée et un responsable identifié.
Pourquoi tester la restauration ?
Beaucoup de PME pensent être protégées parce qu’une sauvegarde existe dans une console, chez un prestataire ou dans un cloud. Pourtant, une sauvegarde peut être incomplète, corrompue, trop ancienne, inaccessible, chiffrée par un ransomware, dépendante d’un compte perdu ou impossible à restaurer dans un délai acceptable. Le test de restauration transforme une promesse technique en preuve opérationnelle.
Le sujet est directement business. Si les fichiers clients, l’ERP, la facturation, la messagerie, la paie ou les documents de production ne reviennent pas rapidement, l’entreprise ne peut plus vendre, produire, livrer ou encaisser. Le test doit donc partir des processus critiques, pas seulement des volumes de données.
Ce qu’un test doit vérifier
Il ne suffit pas de restaurer un fichier de test. Une PME doit identifier ce qui doit redémarrer en premier : devis, factures, commandes, fichiers de production, base client, messagerie, planning, site web ou application métier. Chaque élément doit être relié à un délai acceptable de reprise.
RPO, RTO : deux notions à vulgariser
Le RPO correspond à la quantité maximale de données que l’entreprise accepte de perdre. Si la sauvegarde date de 24 heures, l’entreprise peut perdre une journée de travail. Le RTO correspond au délai de reprise acceptable : une heure, une demi-journée, deux jours. Ces deux notions doivent être décidées par la direction, car elles dépendent de l’activité réelle et pas seulement de la technique.
Une entreprise qui facture tous les jours n’a pas le même besoin qu’une structure qui peut fonctionner manuellement pendant 48 heures. Le test de restauration permet de comparer l’objectif souhaité avec la réalité mesurée.
| Notion | Question simple | Décision dirigeant |
|---|---|---|
| RPO | Combien de données peut-on perdre ? | Définir la perte acceptable par métier : facturation, ERP, fichiers clients, paie. |
| RTO | Combien de temps peut-on rester arrêté ? | Fixer le délai de reprise attendu pour chaque service critique. |
| Preuve | Quand la restauration a-t-elle été testée ? | Demander un compte rendu daté, avec périmètre et durée réelle. |
Erreurs fréquentes
La première erreur est de ne sauvegarder que les fichiers et d’oublier les applications, bases de données, paramètres, droits d’accès ou pièces jointes. La deuxième est de conserver la sauvegarde dans le même environnement que les données principales. La troisième est de ne jamais tester avec le prestataire en condition réelle. La quatrième est de ne pas documenter qui déclenche la restauration et dans quel ordre.
Une sauvegarde peut aussi dépendre d’un compte administrateur unique. Si ce compte est compromis, supprimé ou détenu uniquement par un prestataire indisponible, la sauvegarde existe mais ne protège pas réellement l’entreprise.
Cas anonymisé
Une PME pensait disposer d’une sauvegarde complète de son serveur de fichiers. Le test a montré que les fichiers récents étaient bien présents, mais que certaines bases applicatives et droits d’accès n’étaient pas restaurés. Le plan d’action a consisté à élargir le périmètre, documenter la procédure, programmer un test trimestriel et conserver une preuve lisible par la direction.
Comment organiser un premier test
Un premier test peut rester simple. Il faut choisir un périmètre représentatif, prévenir les personnes concernées, définir l’objectif et mesurer le résultat. Par exemple : restaurer un dossier client récent, une base de facturation ou une application métier dans un environnement séparé. Le test doit produire une trace : date, durée, volume restauré, personnes impliquées, difficultés rencontrées et décisions prises. Cette trace devient une preuve de maîtrise.
La direction doit aussi demander ce qui n’a pas été testé. Une restauration partielle réussie ne prouve pas forcément que l’ensemble du système peut redémarrer. Les dépendances entre applications, bases de données, droits d’accès, certificats, comptes et postes utilisateurs doivent être progressivement intégrées.
Ce qu’il faut demander au prestataire
Ces demandes ne remettent pas en cause le prestataire. Elles clarifient les responsabilités. Une PME doit savoir ce qui relève du fournisseur, de l’hébergeur, de l’éditeur logiciel et de l’entreprise elle-même. Sans cette clarification, les premières heures d’un incident peuvent être perdues à chercher qui détient l’information. La préparation évite aussi les décisions improvisées sous pression.
Diagnostic recommandé
Diag Souveraineté Numérique intègre la sauvegarde dans une lecture plus large : prestataires, cloud, accès, PRA, données sensibles et capacité de reprise. Le score permet de prioriser les tests à réaliser et les preuves à demander avant qu’un incident ne révèle les faiblesses. Il aide aussi à distinguer les actions rapides, comme obtenir un compte rendu de test, des chantiers plus structurants, comme revoir l’architecture de sauvegarde ou formaliser un véritable plan de reprise avec des responsabilités claires et régulièrement vérifiées.
Évaluer mes sauvegardes