PRA/PCA pour PME : définir RTO et RPO sans jargon

Un PRA/PCA doit parler métier avant technique

Le plan de reprise d’activité (PRA) et le plan de continuité d’activité (PCA) sont souvent perçus comme des documents complexes. Pourtant, la discussion de départ est très simple : que se passe-t-il si l’entreprise perd son serveur, son accès internet, sa messagerie, son logiciel métier ou ses fichiers pendant une journée ?

Un plan utile ne commence pas par une technologie. Il commence par les conséquences métier : commandes bloquées, production arrêtée, facturation impossible, clients non servis, obligations réglementaires non tenues.

PRA et PCA : deux réponses à ne pas confondre

On emploie souvent les deux sigles ensemble, mais ils ne recouvrent pas la même chose. Le plan de continuité d’activité (PCA) vise à maintenir l’activité pendant l’incident, en basculant vers un mode dégradé qui permet de continuer à travailler, même au ralenti. Le plan de reprise d’activité (PRA), lui, organise le retour à la normale après un arrêt : comment restaurer les systèmes et les données pour repartir. L’un cherche à ne jamais s’arrêter, l’autre à redémarrer proprement.

Une PME a rarement besoin des deux au même niveau de sophistication. La plupart commencent par un PRA solide, capable de garantir un redémarrage fiable après un incident, avant d’envisager les investissements plus lourds qu’exige une vraie continuité sans interruption. Savoir lequel des deux on vise, et pour quels services, évite de surdimensionner le dispositif.

Pourquoi ce sujet ne peut plus attendre

Le coût d’une interruption d’activité est aujourd’hui documenté avec précision, et il dépasse largement l’investissement nécessaire pour s’en prémunir : un incident majeur coûte en moyenne 1,7 million de dollars en interruption d’activité, sans compter les pertes de réputation. Pour une PME, à une échelle bien plus modeste, une attaque par ransomware se chiffre facilement en dizaines, voire en centaines de milliers d’euros, interruption d’activité incluse.

Un constat mérite une attention particulière : une part importante des victimes de ransomware avaient des sauvegardes sans pouvoir les restaurer intégralement, souvent parce qu’elles n’avaient jamais été testées ou étaient elles-mêmes compromises. Un PRA/PCA qui ne prévoit pas de test de restauration réel reste donc un document théorique, pas une protection effective.

RTO et RPO : deux repères indispensables

Le RTO (Recovery Time Objective) est le délai maximal acceptable avant reprise du service. Si la messagerie peut être indisponible quatre heures mais l’ERP seulement une heure, les priorités ne sont pas les mêmes.

Le RPO (Recovery Point Objective) est la quantité de données que l’entreprise accepte de perdre. Une sauvegarde quotidienne peut suffire pour certains fichiers, mais pas pour une base de commandes mise à jour toute la journée.

Ces deux chiffres doivent être validés avec la direction, pas seulement par l’IT, car ils engagent directement des arbitrages budgétaires et opérationnels qui dépassent le périmètre technique.

L’analyse d’impact métier, en pratique

Avant de fixer un seul chiffre de RTO ou de RPO, la méthode la plus fiable consiste à mener une analyse d’impact métier (Business Impact Analysis) simplifiée. Pour chaque service ou application, trois questions structurent l’échange avec la direction :

1. Quel est l’impact financier direct d’une heure, d’une journée, puis d’une semaine d’indisponibilité (commandes perdues, pénalités contractuelles, production arrêtée) ?
2. Quel est l’impact sur la relation client (promesses non tenues, image dégradée, risque de perte de contrat) ?
3. Quelles obligations légales ou contractuelles dépendent de ce service (facturation, déclarations réglementaires, engagements de service envers des clients) ?

Cette analyse, menée service par service plutôt que de façon globale, révèle souvent des écarts surprenants : un outil perçu comme secondaire par l’IT peut se révéler critique pour la facturation, tandis qu’une application jugée essentielle par les utilisateurs peut tolérer plusieurs jours d’indisponibilité sans impact réel sur l’activité.

Les étapes d’un plan réaliste

• Identifier les activités critiques.
• Lister les applications et dépendances nécessaires.
• Définir RTO et RPO pour chaque service.
• Vérifier les sauvegardes et restaurations, notamment leur isolation face à un compte administrateur compromis, un point de faiblesse fréquemment exploité par les attaquants.
• Prévoir les scénarios : ransomware, panne serveur, incendie, coupure internet, erreur humaine.
• Documenter les rôles : qui décide, qui restaure, qui communique.
• Tester régulièrement sur un périmètre limité.

Ce qu’il faut éviter

Un document jamais testé rassure faussement. Le PRA doit être confronté au réel : temps de restauration, accès aux mots de passe, disponibilité du matériel, dépendances externes, contact des prestataires. Chaque test révèle des détails qu’aucun tableau ne montre, ce qui explique pourquoi près de 4 organisations sur 10 découvrent en situation réelle qu’elles ne peuvent pas restaurer intégralement leurs données malgré un plan écrit.

Il faut aussi éviter de viser un niveau de reprise irréaliste. Un RTO de quinze minutes coûte cher. S’il n’est pas nécessaire pour le métier, mieux vaut investir dans des mesures plus utiles : sauvegardes robustes, supervision, documentation et procédures de crise.

Exemple de matrice RTO/RPO simplifiée

Pour une PME type, une première matrice peut ressembler à ceci : messagerie et outils collaboratifs (RTO 4 heures, RPO 24 heures), logiciel métier ou ERP (RTO 1 heure, RPO 4 heures), serveur de fichiers partagés (RTO 24 heures, RPO 24 heures), site web vitrine (RTO 48 heures, RPO 24 heures). Ces valeurs ne sont qu’un point de départ : elles doivent être ajustées service par service en fonction de l’impact réel sur l’activité, pas d’une estimation générique.

Le bon point de départ

Pour une PME, un atelier de cadrage suffit souvent à clarifier les priorités : quels services sont vitaux, combien de temps l’entreprise peut tenir, quelles données sont critiques, et quelles mesures existent déjà. Ensuite, le plan se construit par étapes.

Un sujet de direction, pas seulement d’IT

L’erreur la plus répandue consiste à confier entièrement le PRA/PCA à l’informatique, sans validation métier. Le résultat est presque toujours le même : des RTO et RPO fixés selon ce qui est techniquement faisable, et non selon ce dont l’entreprise a réellement besoin. Or ces deux chiffres engagent des arbitrages budgétaires et des priorités qui ne relèvent pas de la technique : c’est à la direction de dire quels services sont vitaux et combien l’entreprise peut se permettre de perdre.

Le bon partage est clair. La direction reste décisionnaire sur les priorités et le budget ; un prestataire externe peut porter la mise en œuvre technique et les tests réguliers, particulièrement dans une PME sans DSI interne. L’essentiel est que le plan traduise des enjeux métier réels, pas seulement des contraintes d’infrastructure.

Un plan vaut par ses tests, pas par son épaisseur

Un PRA/PCA n’est pas un document que l’on rédige une fois pour se rassurer. Sa seule vraie mesure est le test : au moins une fois par an sur l’ensemble du plan, plus souvent sur les services les plus critiques. C’est en le confrontant au réel, chronomètre en main, que l’on découvre les mots de passe introuvables, le matériel indisponible ou la dépendance oubliée, autant de détails qu’aucun tableau ne révèle. Mieux vaut commencer modestement, sur les deux ou trois services les plus critiques, et étendre ensuite, plutôt que de viser l’exhaustivité d’emblée.

OLHYN peut vous accompagner via un audit du système d’information ou une migration de virtualisation.

Sources : CrowdStrike, 2025 Ransomware Report · NIST SP 800-34 Rev. 1, Contingency Planning Guide · ANSSI, Guide d’hygiène informatique