Les entreprises parlent de sauvegarde comme si c’était synonyme de continuité, mais ce n’est pas le cas. Une sauvegarde dit que les données existent quelque part. La continuité opérationnelle dit si vous pouvez refacturer, expédier les commandes, traiter les incidents et clôturer la journée après une panne. Ce sont deux sujets différents. Et les confondre coûte cher.
Avoir une copie n’est pas la même chose que pouvoir reprendre l’exploitation.
La différence semble théorique jusqu’au jour de l’incident. Alors les questions inconfortables apparaissent : que restaure-t-on en premier, qui valide l’ordre, quelles dépendances existent, combien de temps avant de découvrir que la restauration ne démarre pas ou qu’il manque des identifiants ? Beaucoup d’entreprises n’échouent pas faute de sauvegardes. Elles échouent parce qu’elles n’ont jamais répété une reprise complète.
L’erreur de penser en données alors que l’entreprise a besoin de processus
Une sauvegarde protège des fichiers, des bases de données et des machines virtuelles. Mais l’entreprise ne fonctionne pas avec des fichiers : elle fonctionne avec des processus. Si l’ERP revient avant l’ecommerce, mais que le stock n’est pas réconcilié, l’exploitation entre en conflit. Si la messagerie revient avant l’authentification, l’équipe peut recommencer à travailler, mais pas avec une vraie sécurité. Si la base est restaurée mais que le paiement est encore indisponible, les ventes ne reprennent pas.
C’est pourquoi il faut penser en “services critiques” et pas seulement en systèmes. Un service critique combine souvent plusieurs briques :
- Identité et accès
- ERP ou gestion des commandes
- Ecommerce ou canal de vente
- Base de données et stockage
- Intégrations logistiques, facturation ou support
La bonne question n’est pas “Est-ce sauvegardé ?”. C’est “Qu’est-ce qui doit être prêt pour reprendre cette fonction précise ?”.
Ce qu’il faut vraiment mesurer : RTO, RPO et dépendance opérationnelle
Trois indicateurs devraient sortir de la théorie pour entrer dans les réunions de direction :
- RPO : combien de perte de données vous tolérez.
- RTO : combien de temps l’activité peut rester à l’arrêt.
- Ordre de reprise : ce qui revient en premier et pourquoi.
Dans beaucoup d’entreprises, le RPO est mesuré en heures parce que “la sauvegarde tourne chaque nuit”, mais le RTO est inconnu. Ce vide est dangereux. Si vous ne savez pas combien de temps il faut pour reprendre, votre sauvegarde n’est qu’une assurance partielle.
Règle pratique : définissez par processus, pas par technologie. Par exemple, “traiter les commandes” peut nécessiter l’ERP, l’ecommerce, le stock, la passerelle de paiement et les étiquettes logistiques. Si un seul de ces éléments manque au plan, le processus reste cassé même si le reste fonctionne.
Autre point important : les restaurations doivent être testées dans un environnement isolé, avec des données réelles anonymisées ou clonées, et avec toute la chronologie. Restaurer un fichier de test ne prouve presque rien. Restaurer une exploitation complète, oui.
Mini-cas : la copie existait, mais personne ne pouvait revendre
Une entreprise de distribution de taille moyenne avait des sauvegardes quotidiennes, une réplication cloud et un prestataire convaincu que tout était couvert. Après un incident de ransomware, les fichiers critiques existaient, mais l’environnement restauré a échoué pour trois raisons : les identifiants avaient changé, une intégration avec le transporteur n’était pas documentée et l’ERP nécessitait une validation manuelle que personne ne savait exécuter.
Le résultat n’a pas été une perte totale de données. C’était plus gênant : trois jours d’exploitation partielle, des commandes bloquées et des équipes qui improvisaient avec des emails et des tableurs. La leçon n’a pas été “il nous faut plus de sauvegarde”. Elle a été : “il nous faut une séquence de reprise testée, avec des responsables et des dépendances visibles”.
Ce scénario est courant parce que beaucoup d’organisations protègent des composants, pas des flux métier.
La décision inconfortable : tout ne doit pas revenir en même temps
Voici le point qui dérange souvent la direction : dans une reprise sérieuse, tout ne revient pas en même temps. Et ce n’est pas grave.
Essayer de remettre tous les systèmes en route simultanément aggrave souvent la situation. Cela crée des collisions de données, des accès incohérents et une fausse impression d’avancement. Mieux vaut accepter une hiérarchie :
- Identité et accès
- Données et transactions critiques
- Ventes et expédition
- Systèmes auxiliaires et analytique
Cela oblige à trancher une question que beaucoup évitent : quels processus ont une vraie priorité et lesquels peuvent attendre quelques heures ? Ce n’est pas une décision purement technique. C’est une décision de pilotage.
Il faut aussi décider ce qu’on automatise et ce qu’on garde manuel pendant la reprise. Parfois, une étape manuelle documentée est plus fiable qu’une automatisation jamais testée. L’obsession du “tout automatique” peut masquer de la fragilité.
Les signes que votre plan n’est pas prêt
Certains signaux sont très clairs :
- Personne ne connaît le RTO de l’ERP ou de l’ecommerce.
- Le dernier test était partiel ou réalisé “sans impacter personne”.
- Les dépendances aux prestataires externes ne sont pas inventoriées.
- La reprise dépend d’une seule personne.
- Les identifiants, clés ou secrets ne sont pas inclus dans le plan.
- L’ordre de reprise est décidé pendant l’incident.
Si vous en reconnaissez deux ou plus, vous n’avez pas un plan de continuité solide ; vous avez une documentation de sauvegarde.
Ce qu’il faut faire avant le prochain incident
Commencez par une cartographie simple des services critiques et de leurs dépendances. Puis définissez :
- RTO et RPO par service
- Priorité de reprise
- Responsable de chaque étape
- Test trimestriel ou semestriel avec preuve
- Procédure pour identifiants, accès et changements de configuration
Le but n’est pas de bâtir une forteresse parfaite. C’est de réduire le temps d’hésitation quand quelque chose casse. Parce qu’en crise, le coût principal n’est pas toujours la perte de données ; c’est souvent le temps perdu à décider comment reprendre.
Chez Codefuente, nous constatons souvent que les meilleures améliorations commencent non pas par plus de technologie, mais par une définition sérieuse de ce que veut dire “reprendre” pour chaque entreprise.