La plupart des PME confondent sauvegarde et plan de reprise d’activité, jusqu’au jour où un incident révèle l’écart entre les deux. Un serveur chiffré par un ransomware, un incendie dans le local technique, une panne de courant prolongée : la question n’est plus de savoir si les données existent quelque part, mais combien de temps il faudra pour relancer l’activité. Cet article détaille l’erreur la plus fréquente et la méthode pour la corriger avant l’incident, pas pendant.
En bref
Un plan de reprise d’activité fixe la marche à suivre pour relancer le système d’information après un sinistre, avec un délai de reprise (RTO) et une perte de données maximale (RPO) décidés à l’avance. C’est ce document qui distingue une panne gérée en quelques heures d’une paralysie de plusieurs jours.
L’erreur qui coûte le plus cher en PME : confondre sauvegarde régulière et plan formalisé, sans jamais tester une restauration complète. Le jour de l’incident, personne ne sait combien de temps prendra le redémarrage, ni si les fichiers sauvegardés sont réellement exploitables.
PRA et plan de continuité : deux documents, pas un seul
Le plan de reprise d’activité s’occupe du système d’information après l’arrêt : relancer serveurs, applications métier et accès réseau. Le plan de continuité, lui, vise à maintenir un service minimal pendant l’incident, y compris sans outils numériques. Une PME sans PRA formalisé s’appuie souvent sur un plan de continuité implicite, porté par la mémoire de deux ou trois personnes.
Cela fonctionne tant que ces personnes sont disponibles et que l’incident reste simple. Un ransomware ou un incendie du local serveur ne laisse ni l’un ni l’autre. Les entreprises soumises à NIS2 doivent documenter cette distinction : notre article sur les obligations NIS2 pour les PME détaille le périmètre concerné.
L’erreur qui coûte cher : confondre sauvegarde et reprise organisée
La sauvegarde protège les données. Le plan de reprise protège l’activité — deux choses que beaucoup de PME confondent. La plupart s’arrêtent au premier point : un abonnement cloud, une copie quotidienne, parfois un disque externe rangé dans le bureau d’à côté.
Le jour où le serveur principal tombe, l’équipe découvre que restaurer deux téraoctets de données prend dix-huit heures, que la dernière sauvegarde valide date de trois jours, ou que le prestataire qui gérait l’infrastructure a changé sans mise à jour de la procédure. Le fichier existe. La reprise, elle, n’a jamais été chronométrée. Ce plan fixe deux repères avant l’incident : le RTO, délai maximal toléré pour relancer le système, et le RPO, volume de données acceptable à perdre. Sans ces deux chiffres validés par la direction, chaque service informatique improvise sa priorité le jour J.
RTO et RPO : ce que chaque niveau de criticité doit préciser
Toutes les données n’ont pas la même valeur le jour d’un incident. Un document efficace classe les systèmes par criticité et fixe un RTO et un RPO propres à chacun, plutôt qu’un objectif unique.
| Niveau de criticité | RTO cible | RPO cible | Exemples de systèmes |
|---|---|---|---|
| Critique | Moins de 4 h | Moins de 1 h | ERP, caisse, plateforme de paiement |
| Important | Moins de 24 h | Moins de 4 h | Messagerie, CRM, outils de prospection |
| Secondaire | 48 à 72 h | 24 h | Partage de fichiers, reporting interne |
Ce tableau reste indicatif : chaque PME doit fixer ses propres seuils selon son activité, ses contraintes clients et ses obligations contractuelles.
Construire ce plan en 5 étapes
Un plan de reprise efficace suit une méthode en cinq étapes, plutôt qu’un document générique copié-collé d’un modèle trouvé en ligne.
- Inventorier les systèmes critiques et leurs dépendances : matériel, logiciels, prestataires, accès.
- Fixer un RTO et un RPO par système, validés par la direction, pas par le seul service informatique.
- Documenter la procédure de restauration pas à pas, avec les contacts et les accès nécessaires en urgence.
- Tester une restauration complète au moins une fois par an, en dehors de l’environnement de production.
- Mettre à jour le document après chaque changement d’infrastructure, d’outil ou de prestataire.
Qui pilote le document, et à quel rythme le tester ?
Un document rangé dans un tiroir ne protège personne. La direction générale doit porter le sujet, pas seulement le prestataire informatique : c’est elle qui arbitre budget et priorités en cas de sinistre partiel.
Le test annuel constitue le minimum recommandé pour les scénarios de crise cyber, avec une restauration réelle et non une simple vérification de fichier. Un audit de cybersécurité permet de cadrer ce calendrier et son budget. Si une violation de données personnelles accompagne l’incident, par exemple un ransomware avec exfiltration, la notification à la CNIL s’ajoute au calendrier, avec un délai de 72 heures à respecter.
Note terrain Lead4you
Sur les diagnostics techniques que nous menons en PME, le point qui revient le plus souvent n’est pas l’absence de sauvegarde — presque toutes en ont une — mais l’absence de test de restauration grandeur réelle depuis la mise en place de l’outil, parfois depuis plus de deux ans. Le jour où il faut vraiment restaurer, l’équipe découvre des sauvegardes incomplètes ou un prestataire remplacé sans transfert des accès. Le fichier de sauvegarde existait ; le chemin pour l’utiliser en urgence, non.
Checklist rapide
- Liste des systèmes critiques et de leurs dépendances techniques à jour
- RTO et RPO fixés et validés par la direction pour chaque système
- Procédure de restauration documentée, avec accès et contacts d’urgence
- Dernier test de restauration complet daté de moins de 12 mois
- Procédure de notification CNIL prête si des données personnelles sont concernées
Demander un diagnostic technique Lead4you
À lire ensuite
Sources et repères utiles
FAQ
Quelle est la différence entre un plan de reprise et un plan de continuité d’activité ?
Le premier concerne le redémarrage du système d’information après l’arrêt : serveurs, applications, accès réseau. Le plan de continuité vise à maintenir un service minimal pendant l’incident, avec ou sans outils numériques. Les deux se complètent, ils ne se remplacent pas.
Qu’est-ce que le RTO et le RPO ?
Le RTO (délai de reprise) fixe le temps maximal toléré avant que le système soit de nouveau opérationnel. Le RPO (perte de données admissible) fixe le volume perdu entre la dernière sauvegarde et l’incident. Les deux se décident par système, pas globalement.
À quelle fréquence faut-il tester ce document ?
Une fois par an au minimum, avec une restauration réelle et non une simple vérification de fichier. Un test après chaque changement majeur d’infrastructure ou de prestataire complète ce rythme annuel et évite les écarts entre le document et la réalité du système.
Combien coûte la mise en place d’un PRA pour une PME ?
Le coût dépend surtout du nombre de systèmes critiques et du temps de restauration visé : un RTO court sur un ERP coûte plus cher qu’un RTO de 48 heures sur un partage de fichiers. Un diagnostic technique permet de chiffrer les options.
Ce document suffit-il sans plan de continuité ?
Non : ce document redémarre le système d’information, mais ne dit rien de ce que l’équipe fait pendant l’arrêt : accueil des clients, prise de commande, facturation manuelle. Sans plan de continuité, l’activité s’interrompt totalement le temps de la reprise technique.
Qui doit valider ce document dans une PME ?
La direction générale, pas uniquement le prestataire informatique. C’est elle qui arbitre budget, priorités entre systèmes et niveau de risque acceptable pour l’entreprise.