« Nous avons des sauvegardes » est une bonne nouvelle. Ce n'est pas une réponse à la question posée. Récupérer des données et redémarrer une entreprise sont deux problèmes différents.
Nous voyons régulièrement le même scénario après un incident : la sauvegarde était bonne, elle a été restaurée correctement — et l'entreprise est restée à l'arrêt une semaine parce que personne ne savait sur quel matériel remonter, dans quel ordre, ni qui appeler.
Les deux chiffres à poser
Ils n'ont rien de technique. Ce sont des décisions de direction, et tout le reste en découle.
La perte de données acceptable
C'est l'écart maximal entre le dernier point de sauvegarde et l'incident. Si vous sauvegardez une fois par nuit, vous acceptez de perdre au pire une journée complète de saisie. Pour un cabinet, c'est souvent supportable. Pour un service qui enregistre des commandes en continu, refaire une journée à partir des e-mails et des bons papier représente un coût considérable.
La durée d'interruption tolérable
C'est le temps pendant lequel l'activité peut fonctionner sans l'outil. Attention : la réponse spontanée est presque toujours « le moins possible », ce qui ne permet rien d'arbitrer. La bonne question est : à partir de quand est-ce que ça devient grave ? Une demi-journée ? Deux jours ? Une semaine ?
Le test qui fait avancer la discussion. Demandez à chaque responsable de service ce qu'il fait, concrètement, si l'informatique s'arrête maintenant. Certains ont des solutions de contournement pour une journée. D'autres s'arrêtent en trois heures. Ces écarts définissent les priorités de remontée.
Tout n'a pas la même criticité
C'est ce qui rend un plan de reprise abordable pour une PME : on ne protège pas tout au même niveau.
| Niveau | Ce qu'on y met généralement | Conséquence sur l'architecture |
|---|---|---|
| Vital | Application métier, messagerie, accès aux dossiers en cours | Justifie un moyen de reprise rapide : réplication, matériel de secours |
| Important | Fichiers de travail, impression, téléphonie | Restauration prioritaire, sans redondance permanente |
| Différable | Archives, outils internes secondaires, historiques | Remontés une fois l'activité reprise |
Ce classement seul fait souvent gagner plus que n'importe quel investissement : il évite de dépenser pour sécuriser des données que personne ne réclamera avant trois semaines.
Ce que contient un plan utile
Un plan de reprise de PME n'a pas besoin d'être un document de cinquante pages. Il doit répondre à six questions, par écrit, et être accessible même quand le système est à l'arrêt.
- Quoi remonter, dans quel ordre. Les dépendances comptent : inutile de démarrer l'application avant l'annuaire et la base de données.
- Sur quel matériel. Serveur de secours, hôte de remplacement, environnement loué : la réponse doit exister avant l'incident.
- Avec quels accès. Comptes d'administration et mots de passe conservés hors du système concerné. Un gestionnaire de mots de passe hébergé sur le serveur chiffré ne sert à rien.
- Qui fait quoi. Qui décide du déclenchement, qui exécute, qui informe les clients et les salariés.
- Qui appeler. Prestataire informatique, éditeurs des applications, opérateur, assurance.
- Comment on travaille en attendant. Les procédures de secours, même papier, pendant la remontée.
Le plan non testé n'est pas un plan
C'est le point sur lequel nous insistons le plus. Un plan de reprise écrit et jamais rejoué est une hypothèse. Le test révèle systématiquement des écarts : un mot de passe qui a changé, une dépendance oubliée, une licence liée au matériel d'origine, un temps de restauration trois fois supérieur à l'estimation.
Mieux vaut découvrir ces écarts un mardi matin, calmement, que le jour où toute l'entreprise attend.
Un test annuel, plus une révision après chaque changement significatif de l'infrastructure, suffit dans la plupart des PME. Ce qui compte, c'est que le temps de reprise constaté soit écrit noir sur blanc — c'est le seul chiffre sur lequel la direction peut réellement s'appuyer.
Par où commencer
- Posez la question aux responsables de service : à partir de quand est-ce grave ?
- Classez les applications en trois niveaux de criticité.
- Vérifiez que les accès d'administration sont disponibles hors du système.
- Écrivez l'ordre de remontée, même sommairement.
- Testez une restauration réelle et notez le temps constaté.
Les quatre premiers points ne coûtent que du temps. C'est déjà l'essentiel du bénéfice.
Sources & pour aller plus loin
Les références officielles sur lesquelles s'appuyer pour approfondir. Les liens ouvrent des sites tiers, dont le contenu peut évoluer.
- ANSSI — continuité d'activité et gestion de crise informatique
- Documentation Veeam — réplication et reprise après incident
Questions fréquentes
Un PRA est-il réservé aux grandes entreprises ?
Non. Ce qui est réservé aux grandes entreprises, c'est le site de secours complet.
Une PME peut avoir un plan de reprise utile qui tient en trois pages : ce qui est critique, dans quel ordre on remonte, qui appelle qui, et où sont les accès. L'essentiel du bénéfice vient de là.
À quelle fréquence tester le plan ?
Au moins une fois par an, et après chaque changement significatif de l'infrastructure.
Un plan écrit il y a trois ans décrit un environnement qui n'existe plus : serveurs remplacés, application migrée, prestataire changé.
Faut-il un second serveur pour avoir un PRA ?
Pas nécessairement. Le niveau de moyens se déduit de la durée d'interruption tolérable : si l'entreprise peut absorber deux jours, une restauration sur du matériel de remplacement suffit. Si elle ne peut pas absorber deux heures, la question du second hôte se pose réellement.