04 28 29 40 72 Devis gratuit
Explicatif · Continuité

PRA et PCA : reprendre, ou ne pas s'arrêter

Ce que recouvrent ces deux sigles, comment se chiffrent le RTO et le RPO, et quel niveau de solution correspond à quel délai. La plupart des PRA de PME sont en réalité des sauvegardes rebaptisées, et la différence se découvre le jour où il faut repartir.

Par , fondateur d'Infranat Publié le

Définition

Le PRA, plan de reprise d'activité, décrit comment remettre le système d'information en marche après un sinistre, et dans quel ordre. Il suppose une interruption : on tombe, puis on repart.

Le PCA, plan de continuité d'activité, est plus large et plus ambitieux : il décrit comment continuer à travailler malgré le sinistre, y compris sans informatique, y compris sans les locaux. Il englobe le PRA et y ajoute l'organisation humaine.

La distinction n'est pas qu'une affaire de vocabulaire. Un PRA est un document technique, qu'un prestataire informatique peut produire. Un PCA est un document de direction, parce qu'il traite de questions qui ne sont pas informatiques : qui décide, qui prévient les clients, où travaillent les équipes si le site est inaccessible, comment facturer sans l'ERP.

Ce qu'un PRA contient réellement

Un PRA qui mérite son nom répond à des questions précises, et il est utilisable par quelqu'un qui n'a pas participé à sa rédaction.

  • Quels services sont vitaux, et dans quel ordre les relever. Rétablir la messagerie avant l'ERP, ou l'inverse, selon ce que fait l'entreprise.
  • Où sont les données, et comment on les récupère. Avec les emplacements, les identifiants d'accès au coffre, et la procédure exacte.
  • Qui fait quoi. Nommément, avec des suppléants, et des numéros de téléphone personnels.
  • Combien de temps chaque étape prend. Non pas estimé, mais mesuré lors d'un test.
  • Quelles dépendances externes bloquent. Opérateur, éditeur de logiciel, hébergeur, et le délai de leur propre engagement.

Le piège du plan rangé au mauvais endroit

Nous l'avons constaté plusieurs fois : le PRA est un document stocké sur le serveur de fichiers, c'est-à-dire exactement l'élément qui est indisponible au moment où on en a besoin. Un plan doit être accessible hors du système d'information : sur papier dans un classeur, et dans un emplacement indépendant que plusieurs personnes savent atteindre depuis leur téléphone.

RTO et RPO : les deux chiffres qui décident de tout

Ce sont deux décisions de direction, pas deux paramètres techniques. Tant qu'elles ne sont pas prises, aucun arbitrage technique n'est possible, et c'est la raison pour laquelle tant de projets tournent en rond.

  • Le RTO, recovery time objective, est la durée d'interruption acceptable. Combien de temps l'entreprise peut-elle fonctionner sans cet outil avant que les conséquences deviennent graves ?
  • Le RPO, recovery point objective, est la quantité de travail qu'on accepte de perdre. Si la dernière sauvegarde exploitable date de la nuit dernière, le RPO est de 24 heures : une journée de saisie est à refaire.

Ces deux chiffres se décident par application et non globalement. La messagerie, l'ERP, le serveur de fichiers et la téléphonie n'ont pas la même criticité, et vouloir le même niveau partout coûte très cher pour rien.

La bonne façon de les établir est de poser une question simple à chaque responsable : « si cet outil s'arrête un mardi matin, à partir de quand est-ce que ça devient un vrai problème ? » Les réponses sont souvent plus nuancées que ce que la direction informatique imagine, et parfois dans les deux sens. Notre calculateur du coût d'une panne aide à mettre un montant derrière ces durées, ce qui rend l'arbitrage budgétaire possible.

Quel niveau de solution pour quel délai

Le coût croît très vite quand le RTO diminue. C'est pourquoi le chiffrer d'abord évite de payer une protection dont vous n'avez pas besoin.

RTO visé Dispositif Ce qu'il implique
Plusieurs jours Sauvegarde externalisée seule Il faut du matériel de remplacement, le réinstaller, puis restaurer. Acceptable pour une activité qui tolère une semaine d'arrêt, ce qui est rare.
24 à 48 heures Sauvegarde avec redémarrage dans le cloud Le rapport le plus favorable pour une PME. Les sauvegardes peuvent être démarrées comme machines virtuelles chez un hébergeur, sans attendre du matériel.
Quelques heures Réplication vers un second site Les données sont copiées en continu vers une infrastructure d'attente. Coût sensiblement plus élevé, et exige des tests réguliers de bascule.
Quelques minutes Haute disponibilité Deux infrastructures actives en parallèle, avec bascule automatique. Réservé à ce qui ne peut réellement pas s'arrêter, car le coût est multiple.

Une nuance importante : la haute disponibilité n'est pas un PRA. Elle protège de la panne d'un équipement, pas d'un sinistre logique. Deux serveurs en parallèle reproduisent fidèlement un chiffrement par rançongiciel ou une suppression, exactement comme le fait le RAID. Les deux dispositifs répondent à des questions différentes et se cumulent.

Un plan non testé n'est pas un plan

C'est la phrase à retenir, et celle qui distingue un document d'un dispositif.

Un PRA jamais éprouvé est une hypothèse. Il repose sur des suppositions qui ne tiennent presque jamais toutes, et les écarts se découvrent au pire moment.

Ce que les tests révèlent, systématiquement :

  • La durée réelle est plus longue que prévu. Souvent d'un facteur deux ou trois. Le volume à transférer, la vitesse de la liaison et les étapes manuelles oubliées s'additionnent.
  • Une dépendance n'avait pas été identifiée. L'application métier a besoin d'une licence rattachée au matériel d'origine, ou d'un serveur de licences lui-même indisponible.
  • Les mots de passe nécessaires sont dans l'outil qui est tombé. Cas classique et bloquant : le coffre à mots de passe est dans le système d'information que l'on cherche à relever.
  • La sauvegarde est incomplète. Une machine ajoutée il y a huit mois n'a jamais été intégrée au périmètre, et personne ne s'en est aperçu parce que les sauvegardes existantes réussissaient.

Nous pratiquons trois niveaux de test, du moins au plus engageant. La revue sur table, où l'on déroule le plan à l'oral pour en vérifier la cohérence. La restauration unitaire, où l'on restaure réellement une machine ou un jeu de fichiers dans un environnement isolé et où l'on mesure le temps. Et la bascule complète, en fenêtre planifiée, qui est la seule à valider vraiment le dispositif.

Ce que nous considérons comme un minimum

Une restauration réelle mesurée au moins une fois par an, avec le temps consigné et comparé au RTO annoncé, et une revue du plan à chaque changement significatif de l'infrastructure. C'est aussi ce qu'attendent les cadres réglementaires : NIS2 comme DORA demandent des tests de résilience et leur traçabilité, pas une politique écrite jamais éprouvée.

Les six oublis les plus fréquents

  • La téléphonie. Une téléphonie IP s'arrête avec le réseau. Si votre standard est votre accueil, être injoignable pendant la crise aggrave tout. Un renvoi vers des mobiles, configuré à l'avance chez l'opérateur, règle le problème pour un coût nul.
  • L'accès Internet. Un PRA qui suppose de restaurer des données depuis le cloud a besoin d'une liaison. Si le sinistre a coupé l'accès, le plan ne s'exécute pas. Un second lien de nature différente devient alors un élément du PRA et non un confort, comme nous l'expliquons sur la page fibre et GTR.
  • Les postes de travail. Les serveurs sont relevés, et les collaborateurs n'ont pas de machine. Les ordinateurs portables du parc et une procédure de reconfiguration rapide font partie du plan.
  • Les personnes. Le plan repose souvent sur une seule personne qui sait faire. Un suppléant formé et une documentation lisible par un tiers sont la vraie redondance.
  • Les prestataires. Leurs propres engagements de délai conditionnent les vôtres. Un RTO de quatre heures est fictif si votre éditeur métier répond en deux jours ouvrés.
  • La communication. Qui prévient les clients, avec quel message, et depuis quelle adresse si la messagerie est tombée. C'est la partie PCA, et c'est souvent celle qui protège le plus la réputation.

Pour la conduite à tenir pendant les premières heures d'un incident, nous avons publié un déroulé séparé dans notre guide cyberattaque : que faire dans les 24 heures, ainsi que la marche à suivre en cas de panne de serveur.

Questions fréquentes

Quelle différence entre un PRA et un PCA ?

Le PRA, plan de reprise d'activité, décrit comment remettre le système d'information en marche après un sinistre et dans quel ordre : il suppose une interruption. Le PCA, plan de continuité d'activité, décrit comment continuer à travailler malgré le sinistre, y compris sans informatique et sans les locaux. Le PCA englobe le PRA et y ajoute l'organisation humaine, ce qui en fait un document de direction et non un document technique.

Qu'est-ce que le RTO ?

Le RTO, recovery time objective, est la durée d'interruption acceptable : combien de temps l'entreprise peut fonctionner sans un outil avant que les conséquences deviennent graves. C'est une décision de direction et non un paramètre technique, et elle se prend par application, la messagerie et l'ERP n'ayant pas la même criticité.

Qu'est-ce que le RPO ?

Le RPO, recovery point objective, est la quantité de travail qu'on accepte de perdre. Si la dernière sauvegarde exploitable date de la nuit dernière, le RPO est de 24 heures et une journée de saisie est à refaire. Avec le RTO, c'est le chiffre qui détermine le dispositif technique nécessaire et son coût.

Une sauvegarde suffit-elle comme PRA ?

Non. Une sauvegarde conserve les données, un PRA décrit comment repartir : avec quel matériel, dans quel ordre, par qui, en combien de temps, et avec quelles dépendances externes. La plupart des PRA de PME sont en réalité des sauvegardes rebaptisées, et la différence se découvre le jour où il faut effectivement redémarrer.

La haute disponibilité remplace-t-elle un PRA ?

Non. Elle protège de la panne d'un équipement, pas d'un sinistre logique : deux serveurs en parallèle reproduisent fidèlement un chiffrement par rançongiciel ou une suppression, exactement comme le fait le RAID. Les deux dispositifs répondent à des questions différentes et se cumulent plutôt qu'ils ne se remplacent.

Combien coûte un PRA pour une PME ?

Cela dépend entièrement du RTO visé, et le coût croît très vite quand le délai diminue. Pour la plupart des PME, le meilleur rapport se situe autour d'un RTO de 24 à 48 heures, obtenu par des sauvegardes pouvant être démarrées comme machines virtuelles chez un hébergeur, sans attendre du matériel. Chiffrer le RTO en premier évite de payer une protection dont on n'a pas besoin.

À quelle fréquence tester un PRA ?

Au minimum une restauration réelle mesurée une fois par an, avec le temps consigné et comparé au RTO annoncé, et une revue du plan à chaque changement significatif de l'infrastructure. Les tests révèlent systématiquement que la durée réelle est plus longue que prévu, souvent d'un facteur deux ou trois.

Où conserver le plan de reprise ?

Hors du système d'information. Nous constatons régulièrement que le PRA est stocké sur le serveur de fichiers, c'est-à-dire exactement l'élément indisponible au moment où on en a besoin. Un plan doit être accessible sur papier dans un classeur et dans un emplacement indépendant que plusieurs personnes savent atteindre depuis leur téléphone, avec les accès au coffre à mots de passe.

Qu'oublie-t-on le plus souvent dans un PRA ?

La téléphonie, qui s'arrête avec le réseau et rend l'entreprise injoignable pendant la crise. L'accès Internet, sans lequel une restauration depuis le cloud ne s'exécute pas. Les postes de travail, les serveurs étant relevés sans que les collaborateurs aient de machine. Les personnes, le plan reposant souvent sur une seule qui sait faire. Et les engagements de délai des prestataires, qui plafonnent les vôtres.

NIS2 et DORA exigent-ils un PRA ?

Ces textes n'imposent pas un document nommé PRA mais demandent des mesures de continuité et, surtout, des tests de résilience documentés et traçables. Une politique écrite jamais éprouvée ne répond pas à cette attente. Pour une entreprise concernée, l'exigence réelle porte donc moins sur l'existence du plan que sur la preuve qu'il a été testé.

Combien de temps vous faudrait-il pour repartir ?

Si la réponse est une estimation et non un chiffre mesuré lors d'un test, vous avez un document, pas un dispositif. Restauration réelle mesurée et comparaison avec votre RTO, incluse dans notre audit offert.

Faire tester ma reprise