Le logiciel de sauvegarde affiche une série de voyants verts. Puis un dossier disparaît, une base devient incohérente ou un attaquant chiffre les systèmes. L’entreprise découvre que ses copies sont trop anciennes, que les clés manquent ou que personne ne sait dans quel ordre relancer les applications.
Le problème n’est pas forcément l’absence de sauvegarde. C’est l’absence de preuve de restauration.
Une stratégie solide relie les copies à des besoins métier : quelles données peut-on perdre, combien de temps une activité peut-elle s’arrêter et comment vérifier que le résultat restauré est exploitable ? Elle prend aussi en compte les dépendances, les identités et les moyens humains. Copier un fichier n’équivaut pas à remettre un service en fonctionnement.
En bref — Le RPO décrit le point de reprise visé, donc la perte de données tolérée dans le scénario étudié. Le RTO fixe un délai cible de rétablissement. Seul un exercice chronométré, incluant les contrôles métier, permet de confronter ces objectifs à la réalité. Les copies doivent être protégées contre les incidents qui affectent la production.
Définir ce qui doit repartir en premier
Un serveur arrêté n’a pas la même conséquence selon son rôle. Le système de commandes, les dossiers de conception et les archives administratives peuvent partager une infrastructure tout en ayant des priorités différentes. Commencez par inventorier les processus, pas seulement les machines.
Pour chaque activité, nommez les données indispensables, le responsable capable de valider leur cohérence et les dépendances techniques. Une base peut être intacte, mais inutilisable sans service d’identité, certificat, configuration ou stockage documentaire. Ce sont ces relations qui déterminent l’ordre de reprise.
Dans une PME fictive, les commerciaux peuvent travailler quelques heures avec un catalogue exporté. L’entrepôt ne peut plus préparer les commandes si les réservations de stock sont perdues. Le retour du stock devient alors prioritaire, même si l’application commerciale paraît plus visible.
Cette hiérarchie évite de traiter tout le patrimoine informatique au même niveau. Elle permet aussi d’expliquer les choix budgétaires. Protéger une donnée rarement utilisée avec le dispositif le plus coûteux n’est pas automatiquement pertinent ; sous-protéger une donnée qui conditionne toutes les ventes peut être très dommageable.
La définition des objectifs de disponibilité d’un service aide à poser le contexte. Elle ne remplace pas le plan de reprise : la fiabilité quotidienne et la récupération après un incident grave sont deux questions complémentaires.
Traduire RPO et RTO en scénarios vérifiables
Le Recovery Point Objective, ou RPO, porte sur le point temporel auquel les données doivent pouvoir être récupérées. Un RPO de quatre heures signifie que l’entreprise vise une perte limitée aux modifications survenues pendant cette durée, dans le scénario défini. Cela ne garantit pas que n’importe quel incident laissera exactement quatre heures de données à reconstruire.
Le Recovery Time Objective, ou RTO, porte sur le délai cible de reprise. Il faut préciser son départ et son arrivée. Part-il de la survenue de l’incident, de sa détection ou de la décision de restaurer ? Se termine-t-il quand le serveur démarre ou lorsque le métier peut effectivement travailler ? Sans convention, deux équipes peuvent annoncer des délais identiques pour des réalités différentes.
| Processus fictif | RPO visé | RTO visé | Validation attendue |
|---|---|---|---|
| Commandes et réservations | 1 heure | 6 heures | Commandes cohérentes, stock rapproché |
| Documents de projet | 4 heures | 1 journée ouvrée | Versions utiles présentes et lisibles |
| Archives clôturées | 1 jour | 3 jours ouvrés | Échantillon consultable, accès corrects |
Ces valeurs sont pédagogiques. Il faut les définir avec les métiers, puis vérifier que la technique et l’organisation peuvent les atteindre. Une fréquence de copie ne suffit pas à prouver le RPO : une sauvegarde peut échouer, contenir une corruption ou attendre trop longtemps avant son transfert.
Une restauration peut également prendre plus de temps qu’annoncé si l’incident impose une reconstruction sécurisée. Après une compromission, remettre l’ancienne machine en ligne sans déterminer ce qui a été altéré expose l’entreprise à une récidive immédiate.
Séparer les copies du risque qui menace la production
Une copie stockée dans le même espace, accessible avec les mêmes privilèges, peut disparaître lors du même incident. Une erreur d’administration, un compte compromis ou une panne de stockage peuvent affecter simultanément l’original et sa sauvegarde.
La protection doit donc viser plusieurs dimensions : emplacement, droits, identités d’administration, durée de conservation et possibilité de modification. Une copie externe ne suffit pas si l’attaquant dispose du compte capable de la supprimer. Une copie immuable n’élimine pas non plus les problèmes de contenu ou de clés indisponibles.
Les recommandations de l’ANSSI insistent notamment sur la protection de l’infrastructure de sauvegarde et l’organisation des restaurations. Pour appliquer ce principe à une petite structure, commencez par dessiner qui peut lire, écrire et supprimer chaque génération de copie. Identifiez les droits qui traversent production et sauvegarde.
Le chiffrement mérite une attention particulière. Il protège la confidentialité, mais il ajoute une dépendance : sans clé accessible dans les bonnes conditions, la copie peut être inutilisable. Le stockage et la récupération des clés doivent faire partie du scénario, avec des contrôles d’accès adaptés et un accès d’urgence documenté.
L’objectif n’est pas de multiplier les systèmes sans contrôle. C’est de ne pas faire dépendre toute la reprise du même compte, du même équipement ou du même site. La séparation doit être réelle, testée et compatible avec les ressources disponibles.
Sauvegarder un SaaS : préciser ce qui vous appartient
La disponibilité d’une application hébergée ne répond pas à toutes les questions de récupération. Le prestataire peut restaurer son infrastructure après une panne générale sans proposer à chaque client le retour à un état choisi après une suppression accidentelle.
Vérifiez les fonctions disponibles pour votre abonnement : export, historique, restauration granulaire, pièces jointes, configurations et identités. Demandez quels délais et quelles limites s’appliquent. Une corbeille accessible pendant une courte période n’est pas équivalente à une politique de conservation documentée.
Dans un CRM, un export de contacts ne restitue pas nécessairement les associations avec les sociétés, les activités, les champs personnalisés et les pièces jointes. Il faut examiner l’ensemble du modèle, comme dans une migration CRM préparée par la qualité des données.
Un export peut constituer une mesure de protection utile sans permettre une restauration identique. Distinguez donc ce que vous récupérez, ce que vous pouvez réimporter et ce qui doit être reconstruit. Le plan de réversibilité d’un SaaS permet de vérifier ces différences avant qu’une urgence ne les rende coûteuses.
Calculer un délai de transfert, puis ajouter le reste
Le volume et le débit donnent un plancher physique. Dans un calcul fictif simplifié, transférer un téraoctet décimal représente huit téra-bits. À un gigabit par seconde réellement soutenu, la division donne 8 000 secondes, soit environ 2 heures, 13 minutes et 20 secondes.
Ce délai ne couvre que le transfert idéal. Il ignore les protocoles, la contention, la décompression, le déchiffrement, les lectures de petits fichiers, la reconstruction des index et les vérifications. Le débit affiché sur une liaison ne correspond pas automatiquement au débit utile de restauration.
Prenons un exercice fictif : une heure pour préparer l’environnement, 2 heures 45 pour restaurer, 1 heure 30 pour contrôler les données et 30 minutes pour rouvrir le service. La reprise prend 5 heures 45. Annoncer seulement le temps de restauration technique aurait sous-estimé l’interruption de trois heures.
Le stockage cible doit lui aussi être disponible. Un plan qui suppose l’achat urgent d’une machine, l’accès immédiat à un abonnement ou la disponibilité d’un administrateur absent n’a pas encore démontré son délai de reprise. La préparation préalable de ces ressources coûte parfois moins que l’accélération du transfert.
Organiser un exercice qui révèle vraiment les faiblesses
Un test utile commence avec un scénario nommé : suppression d’un dossier, perte d’une base, indisponibilité d’un site ou compromission d’un compte administrateur. Il ne prétend pas valider tous les incidents possibles.
Choisissez une date de reprise, un environnement isolé et des critères d’acceptation. La personne exécutant l’exercice doit pouvoir suivre la documentation sans dépendre exclusivement de celui qui l’a écrite. Gardez toutefois une supervision adaptée pour éviter qu’un essai ne perturbe la production.
La restauration doit vérifier le contenu, pas seulement la présence des fichiers. Pour une application de commandes, comptez les objets attendus, rapprochez les montants, contrôlez quelques cas complexes et vérifiez les liens entre commandes, clients et factures. Pour des documents, ouvrez un échantillon et contrôlez les versions.
Un échantillon n’établit pas une garantie sur tous les fichiers. Il apporte une preuve limitée qu’il faut décrire : périmètre, date, contrôles, anomalies. Combiner contrôles systématiques disponibles et validation métier ciblée donne une information plus utile qu’une formule vague comme « restauration testée ».
L’exercice doit aussi tester les droits. Un service qui redémarre mais expose les dossiers d’un client à un autre n’a pas retrouvé son état acceptable. Pensez aux comptes désactivés, aux secrets renouvelés et aux certificats expirés depuis la sauvegarde choisie.
Gardez une fiche de résultat : temps de détection, décision, préparation, transfert, vérification et réouverture. Notez les opérations manuelles, les accès manquants et les écarts avec les objectifs. Chaque anomalie doit avoir un responsable et une échéance.
Traiter la cohérence entre plusieurs applications
Une entreprise utilise rarement un seul système. Si le CRM est restauré à midi et la comptabilité à dix heures, des événements peuvent apparaître dans l’un et manquer dans l’autre. Les sauvegardes individuellement valides produisent alors un ensemble incohérent.
La solution dépend de l’architecture : points de reprise coordonnés, journaux d’événements, exports de rapprochement ou reprise contrôlée des échanges. Les numéros de commande, identifiants de transactions et horodatages doivent permettre de retrouver ce qui a déjà été transmis.
Il faut en particulier éviter de rejouer aveuglément les traitements. Une facture ou un prélèvement déjà déclenché ne doit pas être produit une seconde fois. La gestion de l’idempotence dans les automatisations devient donc un élément du plan de reprise, pas un simple détail de développement.
Préparez une procédure de réconciliation : quels événements comparer, quels écarts bloquent la réouverture, qui autorise une correction et comment conserver sa trace. Une anomalie documentaire peut attendre ; une incohérence de paiement demande souvent une décision avant la remise en service.
Donner un rythme et un budget à la preuve
La fréquence des tests doit tenir compte de la criticité et du changement. Un exercice ancien perd de sa valeur après une migration, une modification du chiffrement ou une nouvelle dépendance applicative. Testez les changements qui affectent directement les hypothèses du plan.
Un programme peut combiner des contrôles réguliers sur des objets limités et des exercices plus larges. L’entreprise choisit leur rythme en fonction du risque et de sa capacité ; aucun calendrier unique ne convient à tous les systèmes. Les tests courts servent à détecter les problèmes courants, les exercices complets à vérifier la coordination.
Le coût ne se limite pas au stockage. Exemple fictif : 150 euros mensuels de service et quatre heures de préparation ou de contrôle valorisées à 45 euros représentent 330 euros. Ajoutez, selon le cas, la capacité de restauration, l’environnement de test, la conservation et l’assistance. Ces montants ne sont pas une estimation du marché.
Décider quand conserver plusieurs points de reprise
La copie la plus récente n’est pas toujours la copie utile. Une corruption peut être découverte plusieurs jours après son apparition. Une erreur de synchronisation peut avoir remplacé progressivement des valeurs correctes. Restaurer systématiquement la dernière génération reproduirait alors le problème.
La rétention doit donc tenir compte du délai probable de détection et du rythme des changements. Garder plusieurs points permet une investigation, mais augmente le stockage et la complexité. Le choix doit aussi considérer les règles applicables aux données et la finalité de leur conservation ; un besoin de sauvegarde ne justifie pas automatiquement une conservation illimitée.
Dans un scénario fictif, une équipe découvre le vendredi qu’un import du mardi a dégradé des adresses clients. Une copie du lundi peut aider à retrouver les valeurs, mais une restauration totale supprimerait les modifications légitimes intervenues depuis. Une récupération ciblée suivie d’un rapprochement peut être préférable, si les outils et les procédures le permettent.
Ce scénario montre pourquoi la granularité compte. Pouvez-vous retrouver un objet, une table ou un dossier sans rétablir tout le système ? Qui vérifie que les liens avec les autres objets restent cohérents ? Le choix du produit de sauvegarde doit être examiné à travers ces opérations concrètes.
Ne confondez pas non plus sauvegarde et archivage. La première prépare une reprise après incident ; le second peut répondre à des besoins de conservation et de consultation qui ont leurs propres exigences. Les mêmes fichiers peuvent intervenir dans les deux dispositifs, sans que leurs règles ni leurs garanties soient identiques.
Le dernier contrôle est simple : une personne nommée peut-elle aujourd’hui retrouver une copie utilisable, obtenir les accès nécessaires, suivre une procédure et présenter une preuve de cohérence dans le délai visé ? Si la réponse reste théorique, la prochaine priorité n’est pas forcément une nouvelle licence. C’est un exercice de restauration qui transforme la promesse en résultat mesurable.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
