Un rapport de sauvegarde entièrement vert peut masquer une entreprise incapable de redémarrer. Les fichiers ont été copiés, mais le mot de passe du coffre manque, le serveur de restauration n’est pas disponible ou la base métier ne correspond plus aux documents récupérés. Le véritable livrable d’une politique de sauvegarde est donc une restauration utilisable, dans un délai compatible avec l’activité.
En bref — Définissez la perte de données acceptable et le temps de reprise par service. Séparez les accès de sauvegarde de ceux de la production, protégez une copie déconnectée et testez le parcours complet, jusqu’à la validation métier. Une réplication ou une synchronisation ne remplace pas cette démarche.
Partir des opérations qui ne peuvent pas attendre
Inventorier des serveurs ne suffit pas. Une entreprise doit d’abord identifier ses opérations : enregistrer une commande, produire, payer un fournisseur, expédier, répondre à un client. Pour chacune, indiquez les applications, les données, les personnes et les dépendances nécessaires.
Une comptabilité peut accepter un fonctionnement temporaire sur des documents conservés séparément.
Une préparation de commandes peut devenir inutilisable dès que les stocks ne sont plus fiables. Deux applications hébergées sur le même serveur ont ainsi des besoins différents.
Associez chaque opération à un responsable métier. Il doit définir ce qui rend le service réellement disponible. Pour un logiciel commercial, afficher la page de connexion n’est pas un critère suffisant : il faut pouvoir retrouver un client, créer une commande de test et vérifier son enregistrement.
Le plan de reprise d’activité, ou PRA, organise le retour des systèmes après une interruption. La sauvegarde fournit une partie de ses moyens. Le maintien d’un fonctionnement dégradé, la communication et l’arbitrage des priorités relèvent d’un périmètre plus large, présenté dans notre dossier sur les solutions de continuité d’activité.
RPO et RTO : deux engagements à ne pas confondre
Le RPO décrit la quantité de données que l’on accepte de perdre, exprimée en durée entre le dernier état récupérable et l’incident. Le RTO décrit la durée cible pour remettre un service utilisable. Ces objectifs doivent être définis puis confrontés à des mesures.
Une sauvegarde chaque nuit peut laisser presque une journée de travail sans copie récente. Un traitement lancé toutes les heures ne garantit pas un RPO d’une heure si ses transferts échouent depuis la veille. Mesurez l’âge du dernier point effectivement restaurable, pas seulement l’heure du dernier lancement.
Voici une simulation, sans valeur de référence sectorielle : une entreprise sauvegarde à 02 h 00, puis subit un incident à 17 h 00. Si aucune autre protection ne permet une récupération intermédiaire, quinze heures d’activité sont potentiellement concernées. Une réplication permanente peut réduire ce décalage, mais elle peut aussi propager une suppression.
| Service de l’exemple | Objectif de perte maximale | Objectif de reprise | Validation attendue |
|---|---|---|---|
| Commandes | 1 heure | 4 heures | Commande et stock cohérents |
| Documents de travail | 1 journée | 1 journée | Dossiers accessibles avec leurs droits |
| Archives closes | 1 semaine pour les nouveaux dépôts | 2 jours | Consultation et intégrité contrôlées |
Ces valeurs sont des hypothèses. Leur intérêt est de rendre les compromis explicites : une exigence de reprise en quelques minutes impose généralement davantage de préparation et de ressources qu’une reconstruction en plusieurs jours.
Ce qu’il faut sauvegarder au-delà des fichiers
Une application dépend de sa base, de ses fichiers, de sa configuration et parfois de services extérieurs. Sauvegarder uniquement les pièces jointes laisse les relations métier derrière soi. Sauvegarder uniquement la base peut produire des références vers des fichiers absents.
Documentez la version du logiciel, les paramètres nécessaires, les installations disponibles et les procédures de démarrage. L’ANSSI recommande notamment d’inclure les configurations et les moyens d’installation dans la stratégie. Une vieille sauvegarde peut nécessiter une ancienne version avant toute migration vers une version récente.
Les clés de chiffrement et les secrets demandent une gestion séparée, sécurisée et documentée. Les placer en clair à côté de toutes les données augmente le risque ; les conserver uniquement sur un serveur qui peut disparaître rend la restauration impossible. Testez la récupération avec une personne habilitée, depuis un environnement qui ne dépend pas de la machine perdue.
Pour un service SaaS, examinez précisément l’offre : durée de rétention, granularité de récupération, historique, exports, délais d’assistance et responsabilité de l’entreprise. Une promesse de disponibilité ne décrit pas nécessairement la récupération d’un élément effacé par votre administrateur.
Une copie exportée doit être exploitable. Des fichiers CSV privés de leurs identifiants, des pièces jointes sans correspondance et des dates transformées ne reconstruisent pas un système. Notre dossier sur la gestion documentaire détaille les métadonnées utiles à préserver.
Des copies qui ne tombent pas avec la production
Le stockage primaire, une réplication sur un second équipement et une copie isolée répondent à des risques différents. La réplication aide à supporter certaines pannes matérielles. Elle ne protège pas automatiquement contre une erreur applicative propagée sur les deux systèmes.
La CNIL recommande notamment une copie sur un site géographiquement distinct, une sauvegarde hors ligne et des tests de restauration. Ces protections doivent être combinées selon les risques : un second disque dans la même baie ne règle pas le problème d’un sinistre local.
L’ANSSI souligne aussi l’indépendance de l’infrastructure de sauvegarde vis-à-vis des annuaires de production.
Si un compte compromis peut effacer les données et toutes leurs copies, le nombre de copies apporte peu de protection contre cet attaquant.
Dans la pratique, séparez les comptes d’administration, limitez les accès, protégez les postes utilisés pour intervenir et documentez une procédure d’isolation d’urgence. Un compte autorisé à lancer une copie n’a pas nécessairement besoin de supprimer les anciennes versions.
Le stockage immuable peut empêcher la modification ou l’effacement pendant une durée définie. Vérifiez son fonctionnement réel, les autorisations qui permettent de changer la politique et les conditions de verrouillage. Une option activée sans test n’est pas une preuve d’indépendance. Elle complète une architecture ; elle ne dispense pas de comprendre ses accès.
Ne confondez pas non plus synchronisation et sauvegarde. Notre article sur les suppressions synchronisées dans OneDrive illustre pourquoi un geste local peut affecter la copie distante.
Dimensionner avec des unités et un scénario de croissance
Prenons une autre simulation : 500 Go de données doivent être transférés sur une liaison offrant réellement 100 Mbit/s pour cette opération. En unités décimales, 500 Go représentent 4 000 gigabits. Le temps théorique minimal vaut 40 000 secondes, soit environ 11,1 heures, avant les surcharges, les limitations et les reprises.
Une fenêtre nocturne de huit heures ne suffit donc pas pour transmettre systématiquement cet ensemble dans ces conditions. Ce calcul ne prédit pas la vitesse d’un produit : il montre pourquoi il faut mesurer le débit utile et distinguer copie initiale et transferts ultérieurs.
La compression et la déduplication peuvent réduire le volume. Leur efficacité dépend des données. Des fichiers déjà compressés ne se comportent pas comme des fichiers texte répétitifs. Ne bâtissez pas votre budget sur un ratio commercial sans test représentatif.
Avec 20 Go de nouveaux changements quotidiens pendant trente jours, le cumul brut des changements atteint 600 Go. Ajoutez-y l’état initial et la politique de versions. L’espace réellement consommé dépend ensuite du mécanisme de sauvegarde, de l’expiration, des blocs réutilisés et des opérations de nettoyage.
Mesurez aussi la vitesse de lecture lors d’une restauration. Une offre adaptée à la conservation peut avoir des délais ou des coûts de récupération peu compatibles avec un redémarrage urgent. Le débit sortant, les requêtes et les temps de préparation font partie du dossier d’achat.
Un test qui suit tout le chemin de reprise
Le premier niveau consiste à restaurer un fichier et à comparer son contenu attendu. Il permet de détecter certaines erreurs, mais ne valide ni l’application ni ses dépendances. Un test complet doit reconstruire un service dans un environnement isolé.
Commencez le chronomètre au moment prévu par votre objectif : détection, décision de restauration ou début technique, selon la définition retenue. Conservez cette convention pour comparer les exercices. Sinon, une équipe peut annoncer deux heures en omettant quatre heures d’attente.
Préparez une procédure avec les accès requis, la sélection du point de récupération, les étapes, les contrôles et le retour arrière. Une personne autre que son auteur doit pouvoir la suivre. Les connaissances détenues par un seul administrateur constituent une dépendance opérationnelle.
Le test doit examiner les permissions, les liens entre pièces jointes et données, les fonctions métier et la configuration réseau. Vérifiez aussi que les intégrations ne déclenchent pas de messages ou de paiements réels depuis l’environnement restauré.
Un compte rendu utile indique la date, le périmètre, le point utilisé, la perte observée, la durée, les difficultés et les corrections décidées. Un exercice qui échoue produit une information précieuse. Une case cochée sans preuve produit surtout une impression de sécurité.
La fréquence des exercices dépend de la criticité et des changements.
Une migration, une nouvelle clé, un nouveau connecteur ou une modification importante des droits peut justifier une répétition ciblée, même si le calendrier annuel n’est pas arrivé.
Après une attaque, restaurer ne veut pas dire reconnecter immédiatement
Une copie récente peut contenir des éléments compromis. Choisir automatiquement la dernière version disponible peut remettre en place le problème. L’ANSSI recommande de privilégier des sources de confiance pour reconstruire et de vérifier les données et configurations.
Dans un scénario de compromission, isolez les systèmes concernés et faites examiner le point de restauration par les personnes compétentes. Le retour du service doit s’accompagner de la maîtrise des comptes, des accès et de la cause de l’incident. Une restauration technique sans cette étape peut conduire à une nouvelle interruption.
Définissez les responsabilités avant la crise : qui autorise le retour, qui vérifie le service, qui informe les utilisateurs et qui conserve les éléments nécessaires à l’analyse. Les arbitrages entre reprise rapide et investigations doivent être pilotés, pas improvisés par la personne qui dispose du mot de passe.
Prévoyez également un mécanisme de rapprochement. Si des commandes ont été enregistrées temporairement ailleurs, elles devront être réintégrées sans doublon. Les données perdues ne se récupèrent pas toujours depuis la sauvegarde : elles peuvent nécessiter une reconstruction métier à partir de pièces disponibles.
Ce que doit contenir le budget de protection
Le prix du stockage ne couvre pas l’ensemble. Incluez les logiciels, l’administration, les supports déconnectés, le transport sécurisé, les tests, les récupérations et les équipements de secours. Une équipe qui n’a aucun temps réservé aux exercices finit souvent par les reporter.
Pour comparer deux offres, utilisez un même scénario de reprise. Demandez le coût d’une récupération de 500 Go, les conditions d’assistance, les délais annoncés et les moyens nécessaires pour exploiter les données. Une facture mensuelle moindre peut cacher un travail de reconstruction plus important.
Le coût d’une interruption doit également être estimé avec prudence. Additionner toutes les ventes d’une journée comme si elles étaient définitivement perdues peut exagérer l’impact. Séparez les commandes reportées, les pertes non récupérables, le temps de reconstruction, les pénalités éventuelles et les dépenses supplémentaires.
Une estimation basse et une estimation haute rendent l’incertitude visible. Elles aident à choisir les services à protéger en priorité. Elles ne remplacent pas la validation des besoins par ceux qui connaissent l’activité.
La fiche opérationnelle à conserver hors du système principal
Constituez une fiche courte par service critique : responsable, objectif de perte, objectif de délai, emplacement des copies, accès de secours, procédure et critères de validation. Les secrets eux-mêmes doivent rester dans un dispositif approprié ; la fiche explique comment y accéder avec les autorisations nécessaires.
Conservez cette documentation dans un endroit utilisable si le système principal est indisponible. Un plan de reprise accessible uniquement grâce à l’annuaire en panne ou à l’application perdue ne remplit pas sa fonction.
Lors d’un exercice, notez chaque dépendance découverte : un numéro de support introuvable, une licence attachée à l’ancien matériel, un compte d’administrateur expiré. Affectez les corrections et vérifiez leur clôture. Le niveau de protection progresse lorsque ces obstacles disparaissent, pas lorsque le volume de sauvegardes augmente.
La bonne question à poser au prochain comité informatique est donc concrète : quel service avons-nous réellement restauré, avec quelles données, en combien de temps ? La réponse doit tenir dans un compte rendu vérifiable et un service testé par son utilisateur.
Surveillez enfin les échecs silencieux : un travail exécuté avec succès peut exclure un nouveau dossier ou un nouveau serveur. Comparez régulièrement le périmètre sauvegardé à l’inventaire réel. Un changement d’application doit déclencher la mise à jour de cette correspondance avant que l’ancien dispositif soit retiré.
Je suis Alaa Zerroud, entrepreneur dans le numérique et CEO de XNext. Je conçois des solutions web, SaaS et d’intelligence artificielle pour accompagner les entreprises et les ONG dans leur transformation digitale. Sur Sefior.fr, je décrypte l’actualité technologique avec un regard de professionnel, en m’appuyant sur mon expérience du terrain pour proposer des analyses fiables, claires et utiles.
