RTO et RPO : définir et calculer votre plan de reprise d'activité PME
RTO, RPO, PRA, PCA : définitions claires, méthode de calcul et tableaux par système critique. Guide pratique pour DSI et dirigeants de PME. Par ECLAUD IT.
RTO et RPO : comment bâtir le plan de reprise d’activité de votre PME
Trois notions à retenir avant tout :
- RTO (Recovery Time Objective) : durée maximale d’interruption admissible après un sinistre informatique
- RPO (Recovery Point Objective) : quantité maximale de données que vous acceptez de perdre, exprimée en heures
- PRA : le plan qui traduit vos RTO/RPO en actions concrètes — sauvegardes, réplication, procédures de reprise, tests réguliers
Votre messagerie tombe un mardi matin. Votre ERP est inaccessible depuis une heure. Votre NAS est chiffré par un ransomware. Dans ces moments-là, deux questions se posent — et elles ont besoin d’une réponse préparée à l’avance : combien de temps pouvez-vous tenir sans ce système ? Jusqu’où dans le passé pouvez-vous revenir pour récupérer vos données ?
Le RTO et le RPO mesurent précisément ça. Ce guide vous donne la méthode pour les calculer, les traduire en plan de reprise d’activité, et répondre aux exigences réglementaires — notamment NIS2 dont la transposition française est attendue pour octobre 2026.
Qu’est-ce que le RTO et le RPO en informatique ?
Le RTO et le RPO sont les deux indicateurs fondamentaux de toute stratégie de continuité informatique. Ils expriment votre tolérance à l’incident — pas en ressenti, mais en chiffres définis à froid.
RTO (Recovery Time Objective) : définition et exemple concret
Le RTO mesure le temps maximum qui peut s’écouler entre un incident et la remise en service complète d’un système. Si votre serveur de fichiers tombe à 9h et que votre RTO est de 4 heures, les équipes doivent pouvoir accéder à nouveau à leurs fichiers avant 13h.
Un RTO de 4 heures ne signifie pas que la panne durera 4 heures — il signifie que vous avez conçu votre architecture pour garantir ce délai. La différence compte : un RTO est un engagement technique, pas un espoir.
Exemples concrets :
- RTO 1h : infrastructure redondante avec basculement automatique (failover). Solutions type clustering, Azure Site Recovery, Veeam avec Hot Standby.
- RTO 4h : réplication VM avec démarrage manuel du système de secours.
- RTO 24h : restauration depuis backup complet sur nouveau matériel ou VM cloud.
- RTO 72h : reconstruction depuis zéro sur matériel de remplacement.
RPO (Recovery Point Objective) : définition et exemple concret
Le RPO mesure la quantité maximale de données perdues acceptable, exprimée en durée. Un RPO de 4 heures signifie que la dernière sauvegarde utilisable ne peut pas avoir plus de 4 heures d’ancienneté.
Scénario : un ransomware chiffre votre ERP à 16h30. Votre dernière sauvegarde date de 12h. Vous perdez 4h30 de saisies, de commandes, de mouvements de stock. Si votre RPO était fixé à 4h, vous êtes en dehors des clous — et vos clients aussi.
Le RPO dépend directement de la fréquence de vos sauvegardes. Snapshot horaire = RPO de 1h. Sauvegarde quotidienne à 3h du matin = RPO potentiel de 23h59.
DMIA et PDMA : les équivalents francophones
Dans les documents normatifs français et les audits ISO, vous rencontrerez deux acronymes équivalents :
- DMIA (Durée Maximale d’Interruption Admissible) = RTO
- PDMA (Perte de Données Maximale Admissible) = RPO
Ces termes sont issus de la norme ISO 22301 sur la gestion de la continuité d’activité. Les équipes IT utilisent quasi-exclusivement RTO et RPO au quotidien — mais si votre prestataire ou votre auditeur emploie DMIA/PDMA, c’est la même chose.
Stat Box — En 2025, le coût médian d’une attaque ransomware pour une entreprise française s’élevait à 1,3 million d’euros, incluant la perte d’exploitation, la remédiation et l’impact réputationnel (CESIN, Baromètre cybersécurité 2025). Pour une PME, l’absence de RTO/RPO définis transforme un incident gérable en crise existentielle.
Quelle est la différence entre RTO et RPO ?
RTO et RPO mesurent deux dimensions distinctes d’un même risque. Les confondre conduit à des architectures inadaptées — et à des surprises lors du premier vrai incident.
Tableau comparatif RTO / RPO
| Dimension | RTO | RPO |
|---|---|---|
| Ce qu’il mesure | Durée d’indisponibilité tolérable | Volume de données perdues tolérable |
| Unité | Heures / minutes | Heures / minutes |
| Impact si dépassé | Perte d’exploitation, SLA clients | Perte de données, retravail, erreurs |
| Technique associée | Redondance, failover, réplication | Fréquence de sauvegarde, snapshot |
| Qui le ressent | Utilisateurs bloqués | Métier (comptabilité, production, ADV) |
| Question posée | ”Quand peut-on reprendre ?" | "Jusqu’où peut-on remonter ?” |
Exemple d’application : une PME sous attaque ransomware
Il est 16h30, un jeudi. Un collaborateur a ouvert une pièce jointe infectée deux heures plus tôt. Le ransomware a chiffré silencieusement tous les partages réseau. La messagerie tourne encore (Microsoft 365, cloud), mais l’ERP, les fichiers partagés et le NAS sont hors service.
Avec un RPO de 4h et une sauvegarde de midi : vous perdez 4h30 de données. Limite dépassée. Avec un RTO de 8h et une architecture de restauration prête : vous redémarrez avant minuit. Objectif tenu.
Sans ces deux chiffres définis et testés à l’avance, la décision de payer ou non la rançon se prend dans l’urgence, sous pression, sans repère.
RTO et RPO sont-ils indépendants ?
Non. Un RTO court exige souvent un RPO court aussi — et les deux tirent les coûts vers le haut. Une PME peut définir un RTO de 2h pour son ERP, mais si la dernière sauvegarde saine date de 12h, le RTO technique sera tenu alors que le RPO sera manqué.
Les deux indicateurs se dimensionnent ensemble, système par système, en partant de la Business Impact Analysis.
Comment calculer le RTO et le RPO de votre PME ?
Le calcul des RTO et RPO ne se fait pas en vingt minutes sur un coin de table. C’est une démarche structurée en quatre étapes, appelée Business Impact Analysis (BIA). Elle se mène idéalement avec le dirigeant, le responsable financier et les référents métier.
Étape 1 — Business Impact Analysis (BIA) : identifier vos systèmes critiques
Listez tous les systèmes informatiques utilisés dans votre entreprise. Pour chacun, posez une seule question : si ce système est inaccessible demain matin, quand est-ce que ça fait vraiment mal ?
Classification recommandée :
- Critique : l’arrêt bloque l’activité commerciale ou opérationnelle en moins de 4 heures
- Haute : l’arrêt crée des perturbations majeures au-delà de 4 heures
- Moyenne : l’arrêt est gênant mais des contournements manuels existent
- Faible : l’activité peut se poursuivre plusieurs jours sans ce système
Chez nos clients PME à La Réunion, les dirigeants surestiment régulièrement leur tolérance à l’interruption. Ils pensent pouvoir fonctionner 48h sans ERP — le seuil de douleur réel est à 4-6h. L’exercice BIA permet de sortir du ressenti pour aller vers des chiffres validés par ceux qui utilisent les outils au quotidien.
Étape 2 — Estimer le coût d’une heure d’interruption par système
Pour chaque système critique, estimez le coût d’une heure d’arrêt. Quelques pistes :
- Chiffre d’affaires horaire : si votre CA annuel est de 1,2M€, une heure d’arrêt vaut environ 140€ en CA non réalisé. Pour un e-commerce à forte activité, la perte directe peut être bien supérieure.
- Coût de remobilisation : combien d’heures de travail seront nécessaires pour rattraper la saisie manuelle si le système redémarre 8h plus tard ?
- Pénalités contractuelles : avez-vous des SLA avec vos clients ? Des délais de livraison à respecter ?
- Coût réglementaire : un arrêt de la comptabilité en période de clôture peut générer des pénalités fiscales.
Ce chiffre n’a pas besoin d’être exact à l’euro près. Il sert à hiérarchiser : investir 500€/mois pour protéger un système dont l’arrêt coûte 5 000€/h est raisonnable. Pour un système dont l’arrêt coûte 200€/h, le budget de protection est différent.
Étape 3 — Définir les seuils tolérables (RTO et RPO cibles)
Une fois le coût d’interruption estimé, le RTO et le RPO cibles se déduisent naturellement :
- Le RTO cible est le délai au-delà duquel le coût d’interruption dépasse le coût de la solution de protection.
- Le RPO cible est la fenêtre de perte de données au-delà de laquelle le retravail ou la perte commerciale devient inacceptable.
Exemple : votre ERP coûte 800€/h d’arrêt. Une solution de réplication VM garantissant un RTO de 4h coûte 200€/mois. Le ROI est immédiat dès le premier incident.
Étape 4 — Tableau de synthèse RTO/RPO par application
Le tableau ci-dessous reprend les valeurs typiques constatées pour des PME de 10 à 100 postes. Vos valeurs cibles peuvent différer selon votre secteur et votre tolérance au risque.
| Application | Criticité | RTO cible PME | RPO cible PME | Solution recommandée |
|---|---|---|---|---|
| Messagerie (M365) | Haute | 2-4h | 1h | M365 redondant natif + sauvegarde Veeam/Datto |
| ERP / Logiciel métier | Critique | 4-8h | 4h | Réplication VM + snapshot quotidien |
| Comptabilité / Paie | Critique | 24-48h | 24h | Sauvegarde quotidienne + test mensuel |
| Fichiers partagés (NAS/SharePoint) | Haute | 4-8h | 4h | Règle 3-2-1 + snapshot immuable |
| Site web (vitrine) | Faible | 24-72h | 24h | Hébergeur avec backup automatique |
| Site e-commerce | Critique | 1-2h | 30min | CDN + réplication temps réel |
| Active Directory | Critique | 2-4h | 1h | Contrôleur de domaine secondaire |
Key Takeaway — Un RTO de 4 heures pour votre messagerie ne se décrète pas. Il implique une architecture de secours (Microsoft 365 redondant, réplication), des procédures documentées et des tests réguliers. Sans test, c’est un objectif théorique — pas un plan.
Exemples de RTO et RPO pour une PME (par type de système)
Les valeurs abstraites prennent tout leur sens quand on les applique système par système. Voici les points d’attention spécifiques aux applications les plus courantes dans les PME françaises.
Messagerie (Microsoft 365 / Exchange)
Microsoft 365 est nativement redondant — les serveurs de messagerie de Microsoft affichent un uptime de 99,9%. Mais cette disponibilité ne protège pas contre la suppression accidentelle de boîtes mail, la corruption de données, ou l’accès illicite à vos e-mails depuis un compte compromis.
Pour la messagerie, le RPO pertinent n’est pas “est-ce que ma messagerie répond” — c’est “est-ce que je peux récupérer les e-mails supprimés il y a 45 jours”. Microsoft conserve les éléments supprimés 30 jours par défaut. Au-delà, sans solution de sauvegarde tierce, c’est perdu.
RTO recommandé : 2-4h. RPO recommandé : 1h. Solution : Veeam Backup for Microsoft 365 ou Datto SaaS Protection.
ERP / Logiciel métier (Sage, Cegid…)
L’ERP est souvent le système le plus critique et le plus complexe à restaurer. La base de données est volumineuse, les dépendances nombreuses (serveur SQL, Active Directory, licences). Une restauration complète depuis un backup peut prendre 6 à 12 heures.
Pour tenir un RTO de 4-8h, la solution efficace est la réplication de VM : une image complète de votre serveur ERP est répliquée toutes les heures sur un hébergeur cloud. En cas de panne, la VM de secours démarre en 15-30 minutes.
Fichiers partagés (NAS / SharePoint)
Le piège classique : le NAS est sauvegardé sur un disque dur externe branché en permanence. Un ransomware chiffre les deux en même temps. La stratégie de sauvegarde 3-2-1 répond à ce risque — mais seulement si la copie hors site est réellement isolée du réseau.
Pour SharePoint/OneDrive, la corbeille et le versioning natif de Microsoft 365 permettent de restaurer des fichiers écrasés sur 30 à 180 jours selon la configuration. Pour une restauration massive (ransomware, sinistre), une solution tierce reste nécessaire.
Comptabilité et paie
La comptabilité a une particularité : une interruption de 48h en période normale est souvent supportable. En période de clôture mensuelle, de télédéclaration de TVA, ou de paie, la même interruption de 48h peut générer des pénalités, des retards de paiement et une charge de retravail considérable.
Définissez vos RTO/RPO en tenant compte du calendrier fiscal et social : les seuils acceptables ne sont pas les mêmes en fin de trimestre qu’en milieu de mois.
Qu’est-ce qu’un Plan de Reprise d’Activité (PRA) ?
Un PRA est le document opérationnel qui traduit vos RTO et RPO en actions concrètes. Ce n’est pas un document théorique qu’on lit une fois par an — c’est un ensemble de procédures que vos équipes (ou votre prestataire) doivent pouvoir exécuter en situation de stress, à 22h un vendredi soir.
PRA vs PCA : quelle différence pour une PME ?
| PRA | PCA | |
|---|---|---|
| Objectif | Restaurer les systèmes après un sinistre | Maintenir l’activité pendant le sinistre |
| Interruption acceptée | Oui (durée limitée par le RTO) | Non ou très courte |
| Complexité | Modérée | Élevée |
| Coût | Accessible PME | Souvent réservé aux ETI/grands comptes |
| Cas d’usage | Ransomware, panne matérielle, sinistre physique | Trading, urgences médicales, infrastructure critique |
Pour la grande majorité des PME, le PRA est la réponse adaptée. Le PCA est réservé aux activités qui ne peuvent tolérer aucune interruption — ce qui représente un coût d’architecture multiplié par 3 à 5 par rapport à un PRA.
Les composantes minimales d’un PRA efficace
Un PRA opérationnel contient au minimum :
- L’inventaire des systèmes critiques avec leur RTO/RPO définis
- La cartographie des sauvegardes : où, quoi, à quelle fréquence, quelle rétention
- Les procédures de reprise pas à pas : qui fait quoi, dans quel ordre, avec quel outil
- Le RACI de crise : responsable, acteur, consulté, informé — pour chaque procédure
- Les contacts d’urgence : prestataire IT, hébergeur, éditeurs logiciels, assurance cyber
- La procédure de communication de crise : que dire aux clients, aux salariés, aux partenaires
- Le compte rendu post-incident : leçons retenues, ajustements des RTO/RPO
Le PRA comme engagement contractuel avec votre prestataire IT
Un PRA déposé dans un tiroir ne vaut rien. Un PRA contractualisé avec des SLA mesurables, c’est différent. Dans un contrat d’infogérance, le prestataire s’engage sur des délais de reprise (RTO) et des fenêtres de perte de données (RPO) vérifiables.
Vérifiez que votre contrat mentionne explicitement : le RTO garanti par système, la fréquence des tests de restauration, les pénalités en cas de dépassement, et la procédure d’escalade en cas d’incident majeur.
Expert Quote — L’ANSSI rappelle que la gestion de crise cyber commence avant la crise : “La résilience d’un organisme face à une cyberattaque se prépare bien en amont de tout incident.” Sans plan formalisé et testé, la réponse se fait dans la réactivité — avec des erreurs coûteuses. (Source : cyber.gouv.fr)
Comment mettre en place un PRA pour votre PME ?
La mise en place d’un PRA suit une progression logique. Voici les cinq étapes que nous appliquons chez nos clients en infogérance à La Réunion.
Étape 1 — Inventaire et classification des systèmes critiques
Commencez par lister tous les systèmes — serveurs, NAS, applications cloud, postes de travail stratégiques. Pour chaque système, renseignez : type, version, localisation physique ou cloud, dépendances, responsable métier. Un audit de vos systèmes critiques réalisé par un prestataire externe révèle souvent des systèmes oubliés (anciens serveurs sous un bureau, instances cloud non inventoriées).
Étape 2 — Définir vos RTO et RPO (méthode BIA)
Voir la section précédente. À cette étape, formalisez les chiffres dans un tableau partagé avec la direction. Un RTO et un RPO validés par le dirigeant engage l’organisation — pas seulement l’IT.
Étape 3 — Choisir les solutions techniques (sauvegarde, réplication, cloud)
Les solutions techniques se choisissent en fonction des RTO/RPO cibles, pas l’inverse :
- RTO < 1h : clustering, failover automatique, Azure Site Recovery
- RTO 2-4h : réplication VM (Veeam, Zerto), snapshot immuable
- RTO 4-24h : sauvegarde locale + cloud avec restauration manuelle
- RPO < 1h : snapshot horaire ou réplication en quasi-temps réel
- RPO 4-24h : sauvegarde quotidienne avec rétention 30 jours minimum
La règle 3-2-1 appliquée au PRA est la base : 3 copies, 2 supports différents, 1 copie hors site isolée du réseau.
Étape 4 — Rédiger les procédures de reprise (RACI)
Chaque procédure de reprise se rédige sous forme de checklist numérotée. Objectif : qu’un technicien compétent mais qui ne connaît pas votre infrastructure puisse exécuter la procédure sans ambiguïté. Évitez les formulations vagues (“redémarrer le serveur”) — préférez les actions précises (“se connecter en RDP sur 192.168.1.10, ouvrir Services.msc, démarrer le service SQL Server”).
Le RACI identifie pour chaque action : qui est responsable de l’exécuter, qui valide, qui doit être informé. En contrat de maintenance informatique, ces responsabilités sont réparties entre votre équipe interne et votre prestataire.
Étape 5 — Tester et valider le PRA
Un PRA non testé est un PRA qui échouera en situation réelle. Planifiez un test complet dans les 30 jours suivant la rédaction, puis tous les 6 mois minimum. Plus de détails dans la section suivante.
Comment tester son PRA ? (fréquence et méthode)
Sur les PME que nous accompagnons en infogérance à La Réunion, moins de 20% ont effectué un test de restauration complet dans les 12 derniers mois. Les tests que nous réalisons révèlent régulièrement des écarts entre le RTO théorique et le RTO réel. La cause la plus fréquente : une procédure rédigée mais jamais mise à jour après un changement d’infrastructure.
Test partiel vs test complet (simulation de sinistre)
Test partiel : restaurer un système isolé sur un environnement de test. Vérifier que les données sont lisibles, cohérentes, et que le système démarre correctement. Durée : 2 à 4 heures. Fréquence : trimestrielle.
Test complet : simuler un sinistre majeur sur l’ensemble des systèmes critiques. Mesurer les RTO réels (chronomètre en main), vérifier les procédures de communication, identifier les goulots d’étranglement. Durée : 1 journée complète. Fréquence : annuelle.
Fréquence recommandée des tests
| Type de test | Fréquence minimale | Systèmes couverts |
|---|---|---|
| Test de restauration partielle | Trimestrielle | Fichiers, messagerie |
| Test de redémarrage VM | Semestrielle | ERP, Active Directory |
| Simulation de sinistre complète | Annuelle | Tous les systèmes critiques |
| Test post-modification majeure | Immédiat | Système modifié |
Que faire des résultats de test ?
Chaque test produit un compte rendu : RTO mesuré vs RTO cible, RPO mesuré vs RPO cible, anomalies détectées, actions correctives. Si le RTO mesuré dépasse le RTO cible, il faut soit améliorer l’architecture technique, soit réviser l’objectif à la hausse — les deux options sont valides, mais le dirigeant doit en être informé.
Alerte — PRA non testé = PRA inopérant. D’après nos observations terrain, 70% des PME qui pensent avoir un PRA n’ont jamais effectué de test de restauration réel. Un plan qui n’a jamais été mis à l’épreuve échouera quand vous en aurez le plus besoin.
PRA et La Réunion : particularités insulaires à intégrer dans vos RTO/RPO
À La Réunion, la distance par rapport aux datacenters hexagonaux impose de repenser les objectifs de RTO pour les solutions cloud. Ce point est régulièrement sous-estimé par les PME réunionnaises qui s’appuient sur des solutions cloud hébergées en France hexagonale.
Une réplication vers un datacenter OVH à Roubaix ou Strasbourg avec une bande passante limitée (fibre FTTH partagée, ou pire, une connexion 4G de secours) peut allonger le temps de restauration de plusieurs heures par rapport à ce qu’annonce le prestataire en conditions normales. Une restauration de 500 Go depuis un datacenter hexagonal via une connexion de 100 Mbps prend au minimum 11 heures en conditions idéales — souvent beaucoup plus avec les saturations du câble sous-marin.
Notre recommandation pour les PME réunionnaises :
- Données primaires : hébergement dans un datacenter local (Réunion Télécom, ou datacenter privé à Saint-Denis) ou à Maurice pour la latence
- Backup secondaire : cloud OVH ou Scaleway en France hexagonale pour la robustesse géographique
- RTO cloud ajusté : ne pas retenir les RTO communiqués par les hébergeurs hexagonaux sans les valider avec un test de restauration réel depuis La Réunion
- Plan de continuité offline : pour les systèmes critiques, prévoir une procédure de fonctionnement dégradé (fichiers Excel, accès distant via 4G) pendant la durée de restauration
PRA et NIS2 : quelles obligations pour les PME en 2026 ?
La directive NIS2 (Network and Information Security 2) est le cadre réglementaire européen le plus structurant pour la cybersécurité des entreprises. Sa transposition en droit français est attendue pour octobre 2026.
Qui est concerné par NIS2 ?
NIS2 élargit considérablement le périmètre de NIS1. Elle couvre deux catégories d’entités dans 18 secteurs critiques :
- Entités essentielles : énergie, transports, banque, santé, eau, infrastructure numérique, administration publique
- Entités importantes : services postaux, gestion des déchets, chimie, alimentation, fabrication, fournisseurs numériques, recherche
Les PME de ces secteurs sont concernées — contrairement à NIS1 qui ciblait uniquement les grandes organisations. Les critères d’inclusion : plus de 50 salariés ou plus de 10M€ de chiffre d’affaires dans un secteur couvert.
Les obligations de continuité sous NIS2
NIS2 impose aux entités concernées des mesures techniques et organisationnelles en matière de continuité d’activité, incluant :
- Gestion des sauvegardes : politique formalisée, tests réguliers, rétention adaptée aux risques
- Reprise après sinistre : plan documenté avec RTO/RPO définis
- Gestion des incidents : procédure de détection, réponse et notification
- Sécurité de la chaîne d’approvisionnement : vos sous-traitants IT doivent être conformes — ce qui touche aussi les PME non directement soumises à NIS2
L’ANSSI est l’autorité nationale compétente pour NIS2 en France. Elle publie des guides de conformité accessibles aux PME.
Délais et sanctions
La transposition française de NIS2 est attendue pour octobre 2026. Les sanctions prévues peuvent atteindre 10 millions d’euros ou 2% du chiffre d’affaires mondial pour les entités essentielles, et 7 millions d’euros ou 1,4% pour les entités importantes.
Au-delà du périmètre réglementaire direct : si vous êtes sous-traitant d’un grand groupe soumis à NIS2, ce client peut vous imposer contractuellement des exigences équivalentes. Les PME hors périmètre NIS2 ne sont donc pas à l’abri d’exigences indirectes via leurs donneurs d’ordres.
FAQ — RTO, RPO et PRA pour PME
Quelle est la différence entre le RTO et le RPO ?
Le RTO (Recovery Time Objective) mesure le temps maximum acceptable entre un sinistre et la remise en service des systèmes. Le RPO (Recovery Point Objective) mesure la quantité maximale de données que l’entreprise peut se permettre de perdre, exprimée en durée. Exemple : un RTO de 4h signifie que les systèmes doivent être opérationnels dans les 4 heures suivant l’incident. Un RPO de 1h signifie que la dernière sauvegarde utilisable ne peut pas avoir plus d’une heure d’ancienneté.
Quelle différence entre PRA et PCA ?
Le PRA (Plan de Reprise d’Activité) définit comment restaurer les systèmes informatiques après un sinistre majeur — il accepte une interruption temporaire. Le PCA (Plan de Continuité d’Activité) vise à maintenir l’activité pendant le sinistre, avec zéro interruption ou une interruption très courte. Pour la plupart des PME, le PRA est suffisant et financièrement accessible. Le PCA est réservé aux activités critiques ne pouvant tolérer aucune interruption (trading, urgences médicales, infrastructures critiques).
Qu’est-ce que le DMIA et le PDMA en informatique ?
Le DMIA (Durée Maximale d’Interruption Admissible) est l’équivalent français du RTO. Le PDMA (Perte de Données Maximale Admissible) est l’équivalent français du RPO. Ces termes sont issus de la norme ISO 22301 sur la gestion de la continuité d’activité. En pratique, les professionnels IT utilisent plus couramment les acronymes anglais RTO et RPO — mais lors d’un audit ou d’une démarche de certification, vous rencontrerez obligatoirement DMIA et PDMA.
Combien coûte la mise en place d’un PRA pour une PME ?
Le coût d’un PRA pour une PME de 10 à 50 postes varie de 2 000 € à 15 000 € selon la complexité des systèmes et les objectifs RTO/RPO. Ce budget couvre l’audit initial, la mise en place des sauvegardes, la configuration des procédures de reprise et les tests. En infogérance, le PRA est souvent intégré dans le contrat MSP sous forme de SLA de reprise, avec un surcoût mensuel de 100 à 500 €/mois selon le niveau de service. C’est significativement moins que le coût médian d’un incident non couvert.
La directive NIS2 oblige-t-elle les PME à avoir un PRA ?
La directive NIS2, dont la transposition française est attendue pour octobre 2026, impose aux entités concernées (essentielles et importantes) des mesures de continuité incluant la gestion des sauvegardes et la reprise après sinistre. Les PME des 18 secteurs critiques couverts par NIS2 doivent donc se doter d’un PRA formalisé. Les PME hors périmètre NIS2 ne sont pas formellement contraintes — mais restent exposées aux exigences contractuelles de leurs donneurs d’ordres ou clients grands comptes soumis à NIS2.
Prêt à définir vos RTO et RPO ?
Un PRA commence par un audit de votre infrastructure. ECLAUD IT intervient auprès des PME de La Réunion pour réaliser la Business Impact Analysis, définir les RTO/RPO par système, et mettre en place les architectures de protection adaptées à votre budget.
Consultez nos services IT managés ou contactez-nous directement pour un diagnostic gratuit de votre situation actuelle.
Voir aussi : Sauvegarde informatique PME — la règle 3-2-1 expliquée, Infogérance PME — les 5 signes qu’il est temps d’y passer et Audit informatique PME — la checklist complète
Sources :
