PRA informatique entreprise : le guide complet ANSSI/NIS2 (méthode, coûts, conformité 2026)

Le PRA informatique entreprise, vu de l’intérieur.

Une cyberattaque coûte en moyenne 466 000 € à une PME française. C’est le chiffre que personne en COMEX ne veut entendre, et pourtant il provient des analyses croisées de l’ANSSI, du baromètre CESIN et de l’étude Asterès pour le CRiP. Ce qui sépare les survivants des autres ? Pas le hasard.

Un plan. Plus précisément, un PRA informatique d’entreprise pensé en amont, testé régulièrement, et capable de remettre l’activité debout en quelques heures.

Soyons directs : en 2026, la question n’est plus « est-ce que je dois mettre en place un PRA ? » mais « combien de temps me reste-t-il avant que la directive NIS2, mes clients grands comptes ou un ransomware me forcent la main ? ».

Entre la loi Résilience qui transpose NIS2 en France, le règlement DORA déjà actif sur le secteur financier depuis janvier 2025, et des assureurs cyber qui refusent désormais d’indemniser les entreprises sans MFA ni sauvegardes déconnectées, le terrain a profondément changé.

Ce guide est celui que j’aurais aimé avoir quand j’ai démarré sur ces sujets. On va y parler définitions — mais aussi méthode, chiffres réels sourcés, normes (ISO 22301, ISO/IEC 27031:2025), erreurs concrètes que je vois en mission, cas réels publics documentés, et obligations 2026.

L’essentiel à retenir Un PRA informatique entreprise est un dispositif technique et organisationnel qui redémarre votre SI après un sinistre. Trois éléments structurent tout : la criticité par application (BIA), les indicateurs RTO/RPO, et la stratégie technique choisie (cloud, externalisé, hybride). En 2026, il devient une exigence NIS2 pour environ 15 000 entités françaises, avec une responsabilité personnelle des dirigeants en cas de manquement. Compter de 8 000 à 250 000 € selon la taille. Cadre normatif : ISO/IEC 27031:2025 (résilience IT) et ISO 22301:2019 (continuité d’activité globale).

Qu’est-ce qu’un PRA informatique en entreprise ?

Définition du PRA informatique Le PRA (Plan de Reprise d’Activité) informatique, ou Disaster Recovery Plan, regroupe l’ensemble des procédures, ressources et moyens techniques qui permettent à un système d’information de redémarrer après un sinistre. Il est encadré depuis 2025 par la norme ISO/IEC 27031:2025 et constitue une exigence de la directive NIS2 article 21.

Le PRA, ou Plan de Reprise d’Activité informatique (Disaster Recovery Plan en anglais, DRP pour les intimes), regroupe l’ensemble des procédures, ressources et moyens techniques qui permettent à votre système d’information de redémarrer après un sinistre. Pas une simple sauvegarde.

Pas un script de restauration sur un coin de bureau. Un vrai dispositif documenté, testé, opérationnel — encadré depuis 2025 par la nouvelle norme internationale ISO/IEC 27031:2025 dédiée à la résilience IT.

Un PRA informatique d’entreprise répond à trois questions : qu’est-ce qui doit absolument repartir, en combien de temps, et avec quelle perte de données maximale ? Tout le reste — l’infrastructure de secours, les outils de réplication, les runbooks, la gouvernance de crise — découle de ces réponses.

Précision qui sauve des heures de réunion : le PRA ne couvre pas que les cyberattaques. Il couvre tout sinistre majeur affectant le SI :

Panne matérielle, incendie dans le datacenter, dégât des eaux, erreur humaine massive (oui, ça existe — j’en ai vu une effacer 4 To de production en deux clics), perte d’un fournisseur cloud, catastrophe naturelle. La cyberattaque est juste devenue la cause numéro un en France ces trois dernières années — et de loin.

Vu sur le terrain Sur une intervention récente chez un industriel français de taille moyenne, le sinistre n’était pas un ransomware. C’était une climatisation HS un week-end férié. Trois serveurs grillés, 36 heures d’arrêt de production, environ 280 000 € de pertes estimées par le client. Pas de PRA, pas de procédure documentée. Tout reposait sur un admin système qui « savait » comment faire. Sauf que le jour J, il était en vacances à l’autre bout de la France. C’est ce genre de détail qu’un PRA empêche.

Anecdote anonymisée avec accord client — mission d’audit de continuité d’activité réalisée en 2024 par i-leadconsulting.

PCA vs PRA : la différence en une phrase

Quelle différence entre PCA et PRA ? Le PCA (Plan de Continuité d’Activité) cherche à éviter ou contourner l’interruption en agissant avant et pendant l’incident. Le PRA (Plan de Reprise d’Activité) intervient après le sinistre pour reconstruire le système d’information. Le PCA protège, le PRA répare. Les deux sont complémentaires : le PCA suit ISO 22301:2019, le PRA suit ISO/IEC 27031:2025.

On les confond tout le temps. C’est même devenu un running gag en COMEX. Pourtant la distinction est simple : le PCA cherche à éviter l’interruption, le PRA répare une fois qu’elle a eu lieu.

Critère	PCA — Plan de Continuité d’Activité	PRA — Plan de Reprise d’Activité
Quand ?	Avant et pendant l’incident	Après l’incident
Objectif	Éviter ou contourner l’interruption	Reconstruire après interruption
Périmètre	Global (IT, RH, locaux, fournisseurs)	IT (système d’information)
Norme de référence	ISO 22301:2019	ISO/IEC 27031:2025
Indicateur clé	Niveau de service maintenu	RTO / RPO
Responsable	Direction générale + COMEX	DSI / RSSI

Le PCA (Plan de Continuité d’Activité)

Le PCA agit avant et pendant l’incident. Son objectif est de maintenir les fonctions critiques de l’entreprise même si le SI principal tombe. Il englobe l’IT, mais aussi les locaux, les RH, les fournisseurs, la communication.

Il s’inscrit dans le cadre de la norme ISO 22301:2019. Un PCA réussi, c’est l’incident que vos clients ne voient jamais.

Le PRA (Plan de Reprise d’Activité)

Le PRA, lui, intervient après. Il acte que quelque chose s’est cassé et organise la reconstruction. C’est le côté « ambulance et bloc opératoire » de la continuité d’activité.

Référentiel applicable : ISO/IEC 27031:2025. Vous ne pouvez pas espérer survivre à une grosse crise avec uniquement l’un des deux : ils sont complémentaires.

La règle que je donne à tous mes clients Le PCA évite l’arrêt. Le PRA gère l’arrêt qui arrive quand même. Aucun des deux ne remplace l’autre. Une entreprise mature a les deux, formalisés, à jour et — point critique — testés au moins une fois par an. Pour aller plus loin, voir notre article dédié « PCA vs PRA : la différence en 5 minutes ».

Pourquoi le PRA est devenu non-négociable en 2026

Pourquoi un PRA est-il indispensable en 2026 ? Trois raisons rendent le PRA non-négociable : (1) une cyberattaque coûte en moyenne 466 000 € à une PME française et 60 % des entreprises victimes ferment dans les 18 mois ; (2) la menace s’est industrialisée avec 1 361 incidents traités par l’ANSSI en 2024 ; (3) la directive NIS2 et le règlement DORA imposent désormais un PRA documenté et testé.

Il y a cinq ans, un PRA était une bonne pratique. Aujourd’hui, c’est devenu une condition de survie. Trois raisons à cela, et les trois sont chiffrées et sourcées.

Raison 1 : le coût d’une cyberattaque a explosé

466 000 € Coût moyen d’une cyberattaque pour une PME française

Selon les analyses croisées de l’ANSSI (ssi.gouv.fr), du baromètre CESIN 2025 (cesin.fr) et de l’étude Asterès pour le CRiP, une PME française paie en moyenne 466 000 € quand elle se fait attaquer pour de bon.

Pas 466 € de licence — 466 000 € de coûts réels : remédiation, reconstruction, expertise externe, perte de marges, sanctions CNIL, communication de crise. Pour une ETI, ce chiffre grimpe vite à plusieurs millions d’euros.

Et le pire : selon l’étude Infolegale 2024, près de 60 % des entreprises victimes ne s’en relèvent pas et ferment dans les 18 mois suivant l’incident.

Raison 2 : la menace s’est industrialisée

Les chiffres du Panorama de la cybermenace 2025 de l’ANSSI (publié le 11 mars 2026, cert.ssi.gouv.fr) sont sans appel : 4 386 événements de sécurité traités, 1 361 incidents confirmés, et 128 compromissions par rançongiciel recensées en 2025.

Le Verizon DBIR 2025 va plus loin : dans la famille « system intrusion », le rançongiciel est associé à environ 75 % des brèches confirmées.

Les PME, TPE et ETI représentent 48 % des victimes de ransomware en France selon l’ANSSI. Les attaquants ne ratissent plus large par hasard : ils ratissent large parce que ça paie.

Raison 3 : la réglementation s’est durcie

C’est le changement le plus profond. La directive NIS2, transposée en France via la loi Résilience attendue à l’été 2026, élargit drastiquement le périmètre des entreprises obligées d’avoir un PRA documenté et testé.

Environ 15 000 entités françaises sont concernées — ETI, PME des secteurs régulés, sous-traitants critiques de grands comptes.

Les sanctions atteignent 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles. Et — c’est nouveau — la responsabilité personnelle des dirigeants peut être engagée.

Ajoutez à cela le règlement DORA, en vigueur depuis le 17 janvier 2025 pour le secteur financier, qui impose des exigences renforcées de résilience opérationnelle numérique.

Et les cyberassureurs qui refusent l’indemnisation si vos sauvegardes ne sont pas immuables ou si la MFA n’est pas activée. Le filet de sécurité s’est resserré de partout.

Vu sur le terrain Lors d’un audit cyber chez un sous-traitant industriel d’environ 180 salariés, le DG m’a sorti la phrase classique : « On est trop petits, ça ne nous concerne pas. » Trois mois plus tard, son client grand compte (un équipementier automobile coté au CAC 40) lui envoie un questionnaire NIS2 de 47 questions à remplir sous quinzaine, sous peine de perdre le marché. Coût estimé du marché : 2,4 M€/an. C’est ça, le vrai déclencheur 2026 — pas la sanction NIS2 directe, mais la pression de la chaîne d’approvisionnement.

Anecdote anonymisée avec accord client — audit cyber NIS2 réalisé en mars 2026 par i-leadconsulting.

Cadre normatif : ISO 22301 et ISO/IEC 27031:2025

Quelles normes ISO encadrent le PRA ? Deux normes structurent le PRA : ISO 22301:2019 pour la continuité d’activité globale (cadre PCA) et ISO/IEC 27031:2025 pour la résilience IT spécifiquement (cadre PRA). En France, le ReCyF publié par l’ANSSI le 17 mars 2026 reprend ces principes pour la conformité NIS2. DORA exige des tests TLPT supplémentaires pour le secteur financier.

Beaucoup d’articles sur le PRA passent à côté du cadre normatif. C’est dommage parce qu’il structure exactement ce qu’on attend d’un PRA mature et auditable. Deux normes à connaître.

ISO 22301:2019 — la continuité d’activité

Cette norme internationale décrit les exigences pour mettre en place un système de management de la continuité d’activité (SMCA). Elle couvre l’analyse d’impact, la stratégie de continuité, la mise en œuvre, l’évaluation de la performance et l’amélioration continue.

Une entreprise certifiée ISO 22301 démontre qu’elle a une gouvernance documentée de sa résilience — un signal fort pour les clients grands comptes et les régulateurs.

ISO/IEC 27031:2025 — la résilience IT spécifique

Publiée en 2025, cette norme est la référence internationale pour la préparation des technologies de l’information et de la communication à la continuité d’activité.

Elle s’inscrit dans la famille ISO/IEC 27000 (sécurité de l’information) et complète ISO 22301 par une approche plus technique et IT-centrée.

Elle décrit notamment les bonnes pratiques pour la mise en place du PRA, les tests, la documentation et l’amélioration.

Comment ces normes s’articulent avec NIS2 et DORA ?

• ISO 22301 sert de socle à la conformité PCA exigée par NIS2
• ISO/IEC 27031:2025 répond directement aux exigences PRA de l’article 21 de NIS2
• DORA exige des tests TLPT (Threat-Led Penetration Testing) qui vont au-delà des deux normes pour le secteur financier
• Le ReCyF (Référentiel Cyber France) publié par l’ANSSI le 17 mars 2026 reprend les principes de ces normes pour les adapter au contexte français

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

Qu’est-ce que RTO et RPO dans un PRA ? Le RTO (Recovery Time Objective) est le temps maximum d’indisponibilité acceptable d’une application après un sinistre. Le RPO (Recovery Point Objective) est la quantité de données qu’on accepte de perdre, exprimée en temps. Plus ces deux valeurs sont basses, plus le PRA est sophistiqué et coûteux. Ces deux indicateurs sont des décisions métier, pas IT.

Si vous ne devez retenir qu’une chose technique de cet article, c’est ceci : RTO et RPO. Ces deux acronymes structurent toute la conception d’un PRA. Et ils sont mal compris dans 80 % des entreprises que j’audite.

RTO : Recovery Time Objective

Le RTO, c’est le délai maximal pendant lequel vous acceptez que l’application soit indisponible. Si votre RTO est de 4 heures sur l’ERP, ça veut dire que 4 heures après le sinistre, l’ERP doit avoir redémarré.

Pas commencé à redémarrer : être effectivement opérationnel. Plus le RTO est bas, plus la solution technique est sophistiquée — et plus elle coûte cher.

RPO : Recovery Point Objective

Le RPO, c’est la quantité maximale de données que vous acceptez de perdre, exprimée en temps. Un RPO de 15 minutes signifie qu’on peut redémarrer avec un état du système datant d’au plus 15 minutes avant le sinistre.

Tout ce qui a été créé ou modifié dans le quart d’heure précédent l’incident est perdu. Là encore, plus le RPO est faible, plus il faut sauvegarder fréquemment, et plus le coût de stockage et de réseau augmente.

Comment positionner RTO et RPO sur vos applications ?

Voici la grille que j’utilise en mission, et qui marche dans 90 % des cas. Elle n’est pas universelle — elle est indicative, à ajuster en fonction du métier et du secteur.

Les solutions techniques citées correspondent aux stratégies de référence AWS et Azure (Pilot Light, Warm Standby, Hot Standby, Multi-Site Active/Active).

Niveau de criticité	RTO cible	RPO cible	Solution technique typique
Vital (paiement, ERP cœur, e-commerce live)	< 1 heure	< 15 min	Multi-Site Active/Active, Hot Standby, réplication synchrone
Critique (CRM, messagerie, ordonnancement)	2 à 4 heures	1 heure	Warm Standby AWS, DRaaS cloud (Veeam, Zerto)
Important (BI, GED, applis métier secondaires)	8 à 24 heures	4 à 8 heures	Pilot Light AWS, sauvegarde immuable 3-2-1
Standard (intranet, outils support)	24 à 72 heures	24 heures	Backup & Restore quotidien (Veeam, Commvault)
Bas (archives, dev, sandbox)	> 72 heures	Variable	Sauvegarde hebdomadaire, cold storage (S3 Glacier)

La règle d’or RTO/RPO Ne définissez jamais le RTO et le RPO depuis l’IT. Ce sont des décisions métier : seul le directeur opérationnel ou le directeur financier peut chiffrer le coût d’une heure d’arrêt. La DSI traduit ensuite ces objectifs en architecture technique. C’est un dialogue, pas un monologue.

La méthode I-lead en 7 étapes pour construire un PRA solide

Comment construire un PRA informatique en 7 étapes ? 1) Cartographier le SI et les processus métier. 2) Réaliser le BIA (analyse d’impact). 3) Définir les RTO et RPO par application. 4) Choisir la stratégie technique (interne, externalisée, cloud, hybride). 5) Rédiger les runbooks et la gouvernance de crise. 6) Tester en conditions réelles. 7) Maintenir le PRA dans le temps.

J’ai vu beaucoup de méthodologies PRA. Certaines tiennent en deux pages, d’autres en 400. Voici la version pragmatique que j’applique chez nos clients ETI, validée par des dizaines de missions terrain et alignée sur ISO/IEC 27031:2025. Sept étapes. Ni plus, ni moins.

Étape 1 — Cartographier le SI et les processus métier

Tout part de là. On ne protège pas ce qu’on ne connaît pas. Cette première phase recense les actifs (serveurs, bases de données, applications, postes critiques, équipements réseau), les flux entre eux, les dépendances et les processus métier qui s’appuient dessus.

C’est souvent la phase la plus longue — comptez 2 à 4 semaines pour une ETI standard — mais elle conditionne tout le reste.

Le piège classique : se concentrer sur les seules applications « visibles ».

Ce qui tombe le plus souvent et paralyse tout, ce sont les briques techniques sous-jacentes — Active Directory, DNS, équipements réseau, certificats. Cartographiez aussi ces couches-là.

Étape 2 — Réaliser le BIA (Business Impact Analysis)

Le BIA, c’est la quantification financière et opérationnelle de l’arrêt. Pour chaque application identifiée à l’étape 1, on chiffre :

Combien coûte une heure d’arrêt ? une journée ? trois jours ? Quels sont les impacts régulatoires, contractuels, réputationnels ? Quel est l’effet domino sur les autres applications ?

C’est l’étape qui donne le levier pour parler budget en COMEX. Quand vous arrivez avec « le PRA va coûter 80 000 € », vous vous faites jeter.

Quand vous arrivez avec « voici le coût de l’arrêt de l’ERP — 47 000 € par heure ouvrée — et voici ce qu’un PRA à 80 000 € permet d’éviter », là vous avez une conversation sérieuse.

Étape 3 — Définir les RTO et RPO par application

Maintenant qu’on connaît la criticité, on fixe pour chaque application le RTO et le RPO cibles. Cette étape se fait en atelier avec les directions métier. Pas avec la DSI seule. Encore une fois : c’est une décision métier, traduite par l’IT.

Étape 4 — Choisir la stratégie technique

Avec les RTO/RPO en main, on peut enfin parler architecture. Datacenter secondaire ? DRaaS dans le cloud ? Sauvegardes immuables ? Réplication synchrone ou asynchrone ? La table comparative un peu plus bas dans cet article détaille les quatre grands modèles.

Le bon choix dépend du RTO visé, du budget, des contraintes de souveraineté des données et — c’est sous-estimé — de la maturité de l’équipe IT interne. Comparatif détaillé : « DRaaS : qu’est-ce que c’est et pour qui ? » (lien interne).

Étape 5 — Rédiger les runbooks et la gouvernance de crise

Un PRA, ce n’est pas seulement de l’infrastructure. C’est aussi du papier. Beaucoup de papier. Concrètement : runbooks pas-à-pas pour chaque scénario de bascule, arbres de décision pour la cellule de crise, annuaires d’urgence (pas dans la messagerie d’entreprise — elle sera peut-être down), procédures de communication interne et externe, modèle de communiqué de presse, contacts ANSSI et CERT-FR, contacts CSIRT régional, contacts assureur, contacts juridique.

Tout ce qui devra être trouvé en 30 secondes le jour J.

Conseil que personne ne donne et qui sauve : imprimez tout. Un PRA stocké uniquement dans le SharePoint de l’entreprise est inutile si le SharePoint est down.

Étape 6 — Tester en conditions réelles

Un PRA non testé est un PRA qui ne fonctionnera pas. Statistiquement, j’observe entre 30 et 50 % d’écart entre ce qui est prévu sur le papier et ce qui se passe réellement le jour J.

L’ANSSI le martèle : une sauvegarde qui n’a jamais été testée n’est pas une sauvegarde.

Trois niveaux de test, du plus simple au plus exigeant : test sur table (parcours papier en réunion), test partiel (bascule de quelques applications), test complet (simulation grandeur nature, parfois sans préavis pour les équipes).

Une organisation mature combine les trois sur une année.

Étape 7 — Maintenir le PRA dans le temps

Un SI évolue tous les jours. Une nouvelle application qui arrive, un changement de fournisseur cloud, une mise à jour majeure d’OS, une fusion-acquisition — tout cela impacte le PRA.

La maintenance n’est pas une corvée annuelle, c’est un processus permanent. Idéalement, le PRA devient un livrable obligatoire de tout projet IT majeur. Sans validation PRA, pas de mise en production.

PRA interne, externalisé, cloud, hybride : quel modèle choisir ?

Quels sont les 4 types de PRA informatique ? 1) PRA interne : datacenter secondaire géré par l’entreprise, idéal pour grands comptes matures. 2) PRA externalisé : confié à un prestataire d’infogérance, adapté aux ETI sans datacenter secondaire. 3) PRA cloud (DRaaS) : réplication chez un hyperscaler, optimal pour PME/ETI cloud. 4) PRA hybride : combinaison, recommandée pour ETI multi-sites avec données sensibles.

La question revient à chaque mission. Il n’y a pas de réponse universelle, mais il y a une grille de lecture. Voici les quatre grands modèles, leurs forces, leurs limites, et le profil pour lequel chacun fait sens.

Critère	PRA interne	PRA externalisé	PRA cloud (DRaaS)	PRA hybride
Coût initial (CAPEX)	Élevé	Faible	Très faible	Modéré
Coût récurrent (OPEX)	Modéré	Modéré à élevé	Variable	Modéré
RTO atteignable	Très bon	Bon	Excellent (15 min)	Excellent
Souveraineté	Totale	Selon prestataire	Selon hyperscaler	Modulable
Cible idéale	Grand compte mature	ETI sans datacenter	PME/ETI cloud	ETI multi-sites

Mon angle de recommandation pour les ETI françaises

Pour une ETI française entre 50 et 5 000 salariés, le modèle hybride avec composante cloud souveraine (SecNumCloud, Outscale, OVHcloud, Scaleway) est presque toujours le bon compromis en 2026.

Il combine la maîtrise des données les plus sensibles en interne ou en datacenter qualifié, la flexibilité du cloud pour les workloads moins critiques, et un coût RUN raisonnable comparé au tout-interne.

Pour les PME, le DRaaS pur sur cloud reste imbattable en rapport coût/efficacité. Pour les grands comptes ou les entreprises sous DORA, on revient souvent vers du multi-site interne complété par du cloud — la souveraineté et l’auditabilité priment.

Combien coûte un PRA informatique en France ?

Quel est le prix d’un PRA informatique en France ? Pour une PME (moins de 50 salariés) : 8 000 à 25 000 € en conception et 6 000 à 18 000 € par an en exploitation. Pour une ETI (50 à 5 000 salariés) : 25 000 à 250 000 € en conception et 20 000 à 200 000 € par an. Au-delà de 5 000 salariés : à partir de 250 000 € en conception et 200 000 € par an en run.

Question gênante, mais elle arrive toujours en début de réunion budget. Personne n’aime y répondre parce qu’il y a 50 paramètres à prendre en compte.

Je vais quand même donner des fourchettes — celles que j’utilise pour cadrer les budgets clients chez i-lead Sentinel — en précisant qu’elles dépendent fortement du secteur, du SI existant et du RTO visé.

Taille d’entreprise	Conception (one-shot)	Run annuel	Ce que ça inclut
PME (< 50 salariés)	8 000 – 25 000 €	6 000 – 18 000 €	Audit, BIA léger, sauvegarde cloud immuable, doc, 1 test/an
ETI (50 – 250 salariés)	25 000 – 80 000 €	20 000 – 60 000 €	BIA complet, DRaaS, runbooks, 2 tests/an, formation
ETI (250 – 5 000)	80 000 – 250 000 €	60 000 – 200 000 €	Site secondaire ou DRaaS multi-zone, exercices crise, NIS2
Grand compte (> 5 000)	250 000 € à plusieurs M€	À partir de 200 000 €	Datacenter secondaire, équipe dédiée, ISO 22301

Ces chiffres incluent l’accompagnement conseil, la mise en place technique, la documentation, la formation et au moins un test annuel.

Ils n’incluent pas, en revanche, les coûts d’opportunité internes — temps des équipes IT et métier sur le projet, qui peut représenter 20 à 30 % de l’effort total.

Comment justifier ce budget en COMEX

Le bon angle n’est jamais le prix du PRA. C’est le prix de ne pas en avoir un. Trois chiffres qui font mouche en COMEX :

(1) le coût horaire d’arrêt de votre activité, calculé via le BIA — souvent entre 5 000 et 50 000 € de l’heure pour une ETI ;

(2) le coût moyen d’une cyberattaque pour une entreprise de votre taille (466 000 € pour une PME, plusieurs millions pour une ETI) ;

(3) le montant maximal de la sanction NIS2 applicable à votre structure. Quand on aligne ces trois chiffres face au budget PRA, la décision se prend en 20 minutes.

Trois cas réels de cyberattaques majeures en France

Pour ancrer la discussion dans le concret, voici trois cas publics et largement documentés qui illustrent ce qu’un PRA mature aurait pu changer — ou ce qu’il a effectivement permis de sauver.

Cas réel public — Sopra Steria (octobre 2020) — Ransomware Ryuk L’ESN française a été victime d’une attaque par le ransomware Ryuk en octobre 2020. Plusieurs systèmes internes ont été chiffrés. Coût estimé entre 40 et 50 millions d’euros (impact financier déclaré au marché). La maturité du PRA et des sauvegardes immuables a permis une reprise progressive sans paiement de rançon. Cas d’école sur l’importance des sauvegardes hors ligne. Source : Communiqués officiels Sopra Steria, presse économique (Les Echos, Le Monde Informatique), ANSSI.

Cas réel public — Centre Hospitalier de Dax (février 2021) — Ransomware Attaque massive par ransomware ayant paralysé les systèmes informatiques du centre hospitalier pendant plusieurs semaines. Bascule manuelle vers des procédures papier, transferts de patients vers d’autres hôpitaux, retards majeurs dans les soins. Coût estimé : plusieurs millions d’euros et impact sanitaire direct. Illustre la nécessité absolue d’un PRA testé pour les opérateurs de services essentiels. Source : ANSSI, ministère de la Santé, presse nationale (Le Monde, France Info).

Cas réel public — Université Paris-Saclay (août 2024) — Cyberattaque majeure Cyberattaque ayant affecté de nombreux systèmes de l’université. Plusieurs semaines de perturbations sur les services numériques (mail, intranet, plateformes pédagogiques). Communication de crise structurée mais reprise lente faute de PRA pleinement opérationnel sur l’ensemble du périmètre. Cas illustrant la pression croissante sur l’enseignement supérieur (32 % des incidents traités par l’ANSSI en 2025). Source : Communiqué officiel Université Paris-Saclay (août 2024), Le Monde Informatique, Panorama ANSSI 2025.

Les 7 erreurs fatales que je vois en mission

Quelles sont les erreurs les plus courantes dans un PRA ? Les 7 erreurs les plus fréquentes : confondre sauvegarde et PRA ; ne jamais tester ; oublier les sauvegardes immuables (règle 3-2-1) ; définir RTO/RPO sans le métier ; documentation indisponible le jour J ; sous-estimer la communication de crise ; croire qu’un PRA est définitif. Chacune peut suffire à transformer un PRA en mensonge organisationnel.

Après plusieurs années à auditer et déployer des PRA dans des contextes très variés — industrie, banque, secteur public, ministères, ESN — j’ai dressé une liste des erreurs qui reviennent le plus souvent. Aucune n’est nouvelle. Toutes sont évitables. Et chacune peut suffire à transformer un PRA en mensonge organisationnel.

Erreur 1 — Confondre sauvegarde et PRA

« On a Veeam, on est protégés. » Non. Vous avez une brique. Indispensable, mais vous n’avez pas un PRA. Un vrai PRA, c’est l’orchestration de la bascule, les rôles, les communications, les arbres de décision, les tests. Veeam est un outil. Le PRA est un dispositif organisationnel.

Erreur 2 — Ne jamais tester

Le PRA reste dans un PowerPoint, validé en CODIR il y a trois ans, jamais ouvert depuis. Le jour du sinistre, on découvre que la moitié des procédures sont obsolètes. C’est la cause numéro un d’échec opérationnel.

Erreur 3 — Oublier les sauvegardes immuables (règle 3-2-1)

Un ransomware moderne cible en priorité les sauvegardes. S’il les chiffre ou les supprime avant de chiffrer la prod, votre PRA s’effondre. La règle 3-2-1 (3 copies, 2 supports différents, 1 hors site) complétée par des sauvegardes immuables (WORM, air-gapped, déconnectées) n’est plus une option en 2026 — c’est aussi une exigence des cyberassureurs.

Voir notre guide « Sauvegardes immuables : guide ANSSI » (lien interne).

Erreur 4 — RTO et RPO définis par l’IT seule

Quand le RTO est fixé par la DSI sans dialogue avec le métier, on se retrouve soit avec des objectifs trop ambitieux et trop chers, soit avec des objectifs trop laxistes qui ne couvrent pas le risque réel.

Le RTO/RPO doit être validé par le directeur métier concerné, point final.

Erreur 5 — Documentation indisponible le jour J

Le PRA stocké uniquement sur le SharePoint qui est en panne. Les contacts d’urgence dans Outlook qui ne marche plus.

Le mot de passe admin dans un coffre-fort applicatif inaccessible. Toute information critique du PRA doit être disponible hors ligne et hors du SI principal.

Erreur 6 — Sous-estimer la communication de crise

Quand vous êtes en pleine bascule technique, le téléphone sonne : presse, clients, fournisseurs, autorités. Sans script, sans porte-parole identifié, sans message-clé préparé, l’entreprise dit n’importe quoi et perd autant en image qu’en CA. La cellule communication doit être activable en parallèle de la cellule technique.

Erreur 7 — Croire qu’un PRA, c’est définitif

Le SI bouge, le métier bouge, les menaces évoluent, la réglementation aussi. Un PRA non maintenu vieillit très vite. Le rythme minimum : revue annuelle complète, mise à jour à chaque changement majeur, exercice annuel obligatoire.

Vu sur le terrain Sur un audit dans un cabinet d’avocats parisien (environ 220 collaborateurs), le PRA datait de 2019. Entre temps : migration partielle vers Microsoft 365, deux acquisitions, un changement complet de stack RH, déménagement du siège. Le document de référence parlait encore de serveurs Exchange on-premise et d’un site secondaire qui n’existait plus. Cinq ans d’écart. C’est commun, et c’est à corriger en priorité quand on prend la suite.

Anecdote anonymisée avec accord client — mission d’audit cyber réalisée en janvier 2026 par i-leadconsulting.

NIS2, DORA et obligations 2026

Le PRA est-il obligatoire avec NIS2 ? Oui pour les entités essentielles et importantes au sens de la directive NIS2 (loi Résilience en France). L’article 21 exige un PCA/PRA documenté et testé. Sanctions : jusqu’à 10 millions d’euros ou 2 % du CA mondial pour les entités essentielles. La responsabilité personnelle des dirigeants peut être engagée. Application probable : 17 octobre 2026.

On en a parlé en introduction, on y revient en détail parce que c’est le sujet 2026. Trois textes structurent désormais l’obligation de PRA en France et en Europe.

La directive NIS2 (loi Résilience en France)

NIS2 (directive UE 2022/2555) remplace la NIS1 de 2016. Entrée en vigueur européenne le 18 octobre 2024, sa transposition française via la loi Résilience est attendue à l’été 2026.

L’ANSSI a publié son Référentiel Cyber France (ReCyF) le 17 mars 2026 et met à disposition l’outil MonEspaceNIS2 pour l’auto-évaluation.

Concrètement, NIS2 concerne environ 15 000 entités françaises réparties en 18 secteurs (énergie, transport, santé, finance, infrastructures numériques, administration publique, espace, déchets, alimentation, fabrication, etc.).

Toute entreprise de plus de 50 salariés ou de plus de 10 M€ de CA dans ces secteurs est concernée — qu’elle soit qualifiée d’« entité essentielle » (régime renforcé) ou d’« entité importante » (régime allégé).

L’article 21 de la directive impose dix mesures techniques et organisationnelles, parmi lesquelles : la gestion de la continuité d’activité incluant un PCA et un PRA documentés et testés, la sécurité de la chaîne d’approvisionnement, l’authentification multifacteur, la notification d’incident sous 24 heures et 72 heures, la formation des dirigeants à la cybersécurité. Voir notre checklist « NIS2 : conformité pour les ETI ».

Les sanctions NIS2

Les sanctions sont structurées en deux niveaux. Pour les entités essentielles : jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial annuel, le montant le plus élevé étant retenu.

Pour les entités importantes : jusqu’à 7 millions d’euros ou 1,4 % du CA mondial. À ces sanctions financières s’ajoutent l’interdiction temporaire d’exercer pour les dirigeants, la publication des manquements (le fameux « name and shame »), et bien sûr les conséquences réputationnelles et commerciales.

Le règlement DORA pour le secteur financier

DORA (règlement UE 2022/2554) est entré en vigueur le 17 janvier 2025. Il s’applique aux établissements financiers européens : banques, assurances, gestionnaires d’actifs, et leurs prestataires ICT critiques.

Cinq piliers structurent DORA : la gouvernance des risques ICT, la gestion des incidents, les tests de résilience opérationnelle (dont les TLPT — Threat-Led Penetration Testing), la gestion des risques tiers, et le partage d’information.

Pour le PRA, DORA va au-delà de NIS2 : tests obligatoires plus fréquents, scénarios incluant des attaques avancées simulées, inspection directe possible par les régulateurs (ACPR, AMF en France).

Si vous êtes dans la finance ou prestataire de services financiers, DORA prime sur NIS2.

Et l’assurance cyber dans tout ça ?

Le marché de la cyberassurance s’est durci radicalement depuis 2023. Aujourd’hui, sans MFA généralisée, sans sauvegardes immuables et déconnectées, sans tests réguliers du PRA, l’assureur peut tout simplement refuser l’indemnisation après sinistre.

La jurisprudence française commence à se construire sur ce point : plusieurs décisions récentes ont validé le refus d’indemnisation par l’assureur en cas de manquement avéré aux mesures contractuelles minimales (notamment en l’absence d’authentification multifacteur).

Avoir un PRA opérationnel n’est donc pas seulement une exigence NIS2 : c’est aussi la condition de la couverture financière en cas de pépin.

À retenir sur la conformité 2026 Si votre entreprise dépasse 50 salariés ou 10 M€ de CA dans un secteur NIS2, ou si vous êtes prestataire critique d’une entité essentielle, vous devez avoir un PRA documenté et testé d’ici le 17 octobre 2026 — date probable de mise en application des sanctions. La pré-inscription auprès de l’ANSSI est ouverte depuis novembre 2025. Le simulateur MonEspaceNIS2 vous permet de vérifier votre éligibilité en moins d’une heure.

Pourquoi confier votre PRA à I-leadconsulting

Je vais être transparent : ce passage est promotionnel. Vous savez maintenant tout ce qu’il faut savoir sur le PRA informatique d’entreprise, et vous pouvez très bien le mettre en place avec une équipe interne mature ou un autre prestataire.

Si vous lisez encore, c’est que vous voulez voir ce qu’I-leadconsulting apporte de différent.

Notre offre Purple Guard est structurée en trois niveaux d’engagement (Essentiel, Standard, Avancé) avec des SLA contractuels mesurables. Trois éléments nous distinguent.

1. Une approche purple team (offensif + défensif)

La plupart des cabinets PRA viennent du monde infogérance ou hébergement. Ils savent restaurer un serveur. Ils ne savent pas toujours penser comme un attaquant.

Notre équipe combine des profils offensifs (purple teamers, découvreurs de CVE, conférenciers Black Hat MEA) et défensifs (SOC leads, ISO 27001 Lead Implementer PECB, Lead Auditors). Le PRA qu’on conçoit anticipe les scénarios d’attaque réels — pas juste les pannes matérielles.

2. Une expérience terrain ETI française

Nos clients sont des ETI françaises et des administrations publiques. CASSIOPEE (Ministère de la Justice), des comptes ETI industriels et plusieurs structures du secteur public nous font confiance sur des sujets PRA, audit cyber et infrastructure depuis plusieurs années.

On connaît les contraintes budgétaires et organisationnelles du middle-market — on ne plaque pas du méthodologique grand compte sur des structures qui ne peuvent pas l’absorber.

3. Une conformité NIS2 par design

Tous nos livrables PRA sont alignés sur le référentiel ReCyF de l’ANSSI et sur l’article 21 de NIS2. Audit de gap NIS2 inclus dans nos prestations PRA Standard et Avancé. Démarche compatible ISO 22301 si vous visez la certification.

FAQ — 18 questions fréquentes

Méthodologie de cet article

Cet article a été rédigé par Mohamed Ali Ksouri, Directeur Associé d’i-lead Consulting, à partir de retours d’expérience terrain accumulés sur des missions PRA, audits cyber et accompagnements ISO 27001 chez des clients ETI françaises et des administrations publiques.

Les données chiffrées proviennent de sources publiques vérifiables :

• ANSSI — Panorama de la cybermenace 2025 (publié le 11 mars 2026)
• ANSSI — Référentiel Cyber France (ReCyF), publié le 17 mars 2026
• Baromètre CESIN x OpinionWay 2025
• Verizon DBIR 2025 (Data Breach Investigations Report)
• Étude Asterès pour le CRiP — coût des cyberattaques réussies en France
• Étude Infolegale 2024 — taux de fermeture post-cyberattaque
• Texte officiel de la directive NIS2 (UE 2022/2555) et du règlement DORA (UE 2022/2554)

Les anecdotes terrain (encarts « Vu sur le terrain ») sont issues de missions réelles d’i-lead Sentinel, anonymisées et publiées avec l’accord des clients concernés.

Aucune information susceptible d’identifier un client ou de révéler une vulnérabilité non corrigée n’est divulguée.

Les noms d’éditeurs et de produits cités (Veeam, Stripe, AWS, Azure, OVHcloud, Outscale, Scaleway, etc.) le sont à titre informatif et n’impliquent aucun partenariat commercial sauf mention explicite.

Sources Interne

• RSSI externalisé pour ETI et PME : guide complet (coûts, délais, NIS2)
• Ransomware 2026 : comment une ETI française se protège concrètement
• Ransomware en entreprise : comment se protéger

En résumé

Le PRA informatique d’entreprise n’est plus un sujet IT. C’est un sujet de gouvernance, de finance, de réglementation et de survie.

En 2026, entre NIS2, DORA, l’explosion des ransomwares et le durcissement des cyberassureurs, l’absence de PRA opérationnel devient un risque existentiel pour l’entreprise et un risque personnel pour ses dirigeants.

La bonne nouvelle : la méthode est connue (les sept étapes décrites plus haut), les solutions techniques sont matures, le cadre normatif (ISO 22301 + ISO/IEC 27031:2025) est posé, et les coûts sont maîtrisables avec le bon accompagnement.

Le tout se joue sur trois piliers : un BIA rigoureux qui aligne IT et métier, une stratégie technique adaptée à votre profil, et — surtout — des tests réguliers qui transforment le document en réflexe organisationnel.

Si vous démarrez la démarche, la pire chose à faire est d’attendre que NIS2 vous y oblige. Le bon moment pour construire un PRA, c’est avant l’incident. Pas pendant. Pas après.

À propos de l’auteur

Mohamed Ali Ksouri est Directeur Associé d’i-lead Consulting, ESN française spécialisée dans la transformation numérique et la cybersécurité, présente à Paris et à Lyon.

Il pilote la pratique i-lead Sentinel dédiée à la cybersécurité et aux infrastructures critiques pour les ETI françaises et les administrations publiques.

Il accompagne depuis plusieurs années des projets PRA, audits cyber, et mises en conformité ISO 27001 et NIS2 dans des contextes industriels, financiers et publics — notamment au Ministère de la Justice (CASSIOPEE / SG-DNUM), pour des comptes ETI industriels et des opérateurs de services essentiels.

Contact : mohamedali.ksouri@i-leadconsulting.com

LinkedIn : linkedin.com/in/mohamed-ali-ksouri