Aller au contenu
Ekotel
Bureautique

PRA informatique : ce que la sauvegarde seule ne couvre pas

Avoir des sauvegardes ne veut pas dire savoir redémarrer. RTO, RPO, ordre de redémarrage, test de restauration : ce qui sépare un plan de reprise d'activité d'un simple dispositif de sauvegarde.

5 min de lecture

Corentin Belier

Fondateur d'Ekotel · Conseil télécom pour PME et ETI

PRA informatique : ce que la sauvegarde seule ne couvre pas

Dernière mise à jour le

Partager sur

L'essentiel

  • Avoir des sauvegardes ne suffit pas : un plan de reprise d'activité dit combien de temps il faut pour redémarrer, et dans quel état.
  • Deux décisions métier structurent le plan : la perte de données acceptable (RPO) et la durée d'interruption acceptable (RTO).
  • L'ordre de redémarrage des systèmes et les dépendances externes (accès internet, téléphonie, logiciels hébergés) sont l'angle mort le plus fréquent.
  • Seul un test de restauration réel, chronométré au moins une fois par an, prouve que les sauvegardes fonctionnent.
  • Face aux rançongiciels, il faut une copie hors d'atteinte du réseau ou immuable, et plusieurs points de restauration échelonnés dans le temps.
Sommaire
  1. Deux chiffres qui structurent tout le reste
  2. L'ordre de redémarrage, l'angle mort du PRA
  3. Le test de restauration : la seule preuve qui compte
  4. Le rançongiciel a changé la donne
  5. Dimensionner sans surdimensionner
  6. Ce qui n'a pas besoin d'être écrit dans un classeur

« On a des sauvegardes. » C'est la réponse la plus fréquente quand on demande à une PME ce qu'elle a prévu en cas de sinistre informatique. Elle est rassurante, et elle répond à côté de la question.

Avoir des sauvegardes signifie que les données existent quelque part. Un plan de reprise d'activité répond à une autre question : combien de temps pour redémarrer, et dans quel état ? Entre les deux, il y a tout ce qui fait la différence entre une journée perdue et trois semaines de désorganisation.

Deux chiffres qui structurent tout le reste

Un PRA ne commence pas par un choix technique, mais par deux décisions métier que le dirigeant est seul à pouvoir prendre.

Le RPO, ou perte de données acceptable. Si le système tombe maintenant, quelle quantité de travail acceptez-vous de refaire ? Une sauvegarde quotidienne à 22 h signifie qu'un incident à 17 h fait perdre une journée de saisie. Pour une entreprise qui facture peu d'opérations, c'est absorbable. Pour un cabinet qui saisit des dossiers toute la journée, c'est une semaine de rattrapage.

Le RTO, ou durée d'interruption acceptable. Combien de temps l'activité peut-elle tourner sans le système ? Quelques heures pour beaucoup de structures. Quelques minutes pour un atelier dont la production s'arrête, un commerce dont les encaissements passent par le réseau, ou un cabinet qui reçoit du public.

Ces deux chiffres déterminent le coût du dispositif, et il est utile de le savoir avant de demander des devis : passer d'un RTO de vingt-quatre heures à un RTO de deux heures ne double pas le budget, il change de nature technique.

L'ordre de redémarrage, l'angle mort du PRA

C'est le point que presque personne n'a documenté, et celui qui coûte le plus de temps le jour venu.

Un système d'information ne se rallume pas d'un bloc. L'annuaire doit démarrer avant les serveurs applicatifs, qui doivent démarrer avant les postes, et certaines applications refusent de se lancer si leur base de données n'est pas déjà disponible. Le réseau et la résolution de noms passent avant tout le reste.

Quand cet ordre n'est écrit nulle part, la restauration se fait par tâtonnements, souvent un dimanche, par une personne qui n'a pas construit l'installation. Une page de procédure rédigée à froid vaut plus, ce jour-là, que le meilleur logiciel de sauvegarde.

La même remarque vaut pour les dépendances externes : la téléphonie IP qui dépend de l'accès Internet, le terminal de paiement raccordé au même lien, le logiciel métier hébergé chez un éditeur dont vous ne pilotez pas le délai de rétablissement. Un PRA qui ne couvre que les serveurs internes laisse ces éléments hors champ.

Le test de restauration : la seule preuve qui compte

Une sauvegarde non testée est une hypothèse, pas une garantie. Les modes de défaillance sont connus et silencieux : une tâche qui échoue depuis des mois sans alerte, un périmètre qui n'a jamais été mis à jour après l'ajout d'un serveur, une archive chiffrée dont plus personne ne détient la clé.

Le test utile n'est pas de vérifier que le fichier existe, mais de restaurer réellement un élément et de l'ouvrir. Une fois par an au minimum, sur un périmètre représentatif, avec un chronomètre — la durée mesurée est votre RTO réel, qui dépasse presque toujours celui annoncé dans le contrat.

C'est aussi le moment où l'on découvre les dépendances oubliées : le mot de passe d'administration stocké dans le système qu'on essaie précisément de restaurer, ou le fichier de licences resté sur le serveur détruit.

Le rançongiciel a changé la donne

Les dispositifs de sauvegarde conçus il y a dix ans visaient la panne matérielle et l'erreur humaine. Une attaque par rançongiciel se comporte différemment : elle cherche activement les sauvegardes accessibles depuis le réseau et les chiffre en priorité, souvent après plusieurs semaines de présence discrète dans le système.

Deux conséquences pratiques :

  • Une copie doit être hors d'atteinte du réseau — déconnectée, ou immuable, c'est-à-dire techniquement non modifiable pendant une durée définie, y compris par un compte administrateur compromis.
  • La profondeur d'historique compte autant que la fréquence. Si l'intrusion date de six semaines, restaurer la sauvegarde de la veille restaure aussi l'intrus. Conserver plusieurs points de restauration échelonnés dans le temps est ce qui permet de remonter avant la compromission.

Dimensionner sans surdimensionner

Tout ne mérite pas le même niveau de protection, et c'est ce tri qui rend un PRA finançable. La méthode tient en trois étapes :

  1. Lister ce qui arrête l'activité en moins d'une journée. En général : le logiciel métier, la messagerie, l'accès Internet, la téléphonie, parfois un seul fichier partagé dont tout le monde dépend.
  2. Fixer un RTO et un RPO par élément, pas pour l'ensemble. Le serveur de fichiers d'archives et l'applicatif de production n'ont pas le même besoin.
  3. Vérifier ce que couvre réellement l'existant avant d'acheter quoi que ce soit. Beaucoup d'entreprises paient déjà pour des fonctions de sauvegarde incluses dans leurs abonnements et qui ne sont pas activées.

Le troisième point produit régulièrement des économies immédiates : un audit du parc révèle des doublons, des licences payantes pour des serveurs mis hors service, et des sauvegardes en double sur deux outils qui s'ignorent.

Ce qui n'a pas besoin d'être écrit dans un classeur

Un PRA de PME n'a pas à ressembler à un document de cinquante pages que personne ne relira. Ce qui sert le jour de l'incident tient en quelques pages :

  • qui appelle qui, avec les numéros hors du système d'information ;
  • l'ordre de redémarrage ;
  • où se trouvent les sauvegardes et comment y accéder sans le réseau ;
  • les contrats et numéros d'assistance des prestataires, imprimés ;
  • ce qu'on dit aux clients pendant l'interruption.

Ce dernier point est le plus négligé et le moins coûteux à préparer. Un message d'accueil téléphonique modifiable depuis un téléphone mobile, un renvoi d'appels pré-configuré : quelques minutes de paramétrage à froid qui évitent, le jour venu, que les clients ajoutent leur inquiétude à la panne.


Pour aller plus loin : sauvegarde et cyber-sauvegarde, le guide sauvegarde et rançongiciel et le lien de secours 4G.

CloudCybersécuritéPME

Parlons de votre projet

Un audit gratuit et sans engagement pour y voir clair sur votre internet, votre téléphonie et votre infrastructure.