Plan de continuité d'activité (PCA) : BIA, RTO/RPO et exemple
de structure

Dans l'édition 2025 de son enquête State of Ransomware, menée auprès de 3 400 responsables informatiques dans 17 pays, Sophos relève que 53 % des organisations touchées par un rançongiciel avaient retrouvé un fonctionnement normal en moins d'une semaine. Présenté comme un progrès (elles étaient 35 % l'année précédente), le chiffre dit surtout qu'une victime sur deux a passé plus de sept jours sans son système d'information. Coveware, qui négocie les rançons pour le compte des victimes, mesurait en 2021 une durée moyenne d'interruption de 23 jours au deuxième trimestre. Entre le jour du chiffrement et le jour où la reconstruction est finie, il y a donc une, deux ou trois semaines pendant lesquelles il faut quand même livrer, payer les salaires et répondre au téléphone.

C'est à cette fenêtre-là que sert le plan de continuité d'activité. Il ne restaure aucun serveur, c'est le travail du PRA, mais il décide avant l'incident ce que l'entreprise continue de faire, avec quoi, et pendant combien de temps elle tiendra comme ça. Vous ne trouverez pas ici de modèle Word à télécharger, pour une raison qui tient en une phrase : un PCA recopié sur un modèle générique décrit une entreprise qui n'existe pas.

Plan de continuité d'activité et plan de reprise : deux questions différentes

Le PCA répond à une question métier : comment produit-on, facture-t-on et soigne-t-on pendant que l'informatique est par terre ? Le PRA répond à une question technique : dans quel ordre, depuis quelles sauvegardes et en combien de temps remet-on le système d'information debout ? L'article consacré au plan de reprise d'activité face au rançongiciel traite de l'immuabilité des sauvegardes, de l'annuaire à reconstruire et du point de restauration sain. Ici, on reste du côté de l'activité : ce que l'entreprise fait pendant que la restauration dure.

Le cadre de référence international est la norme ISO 22301:2019 (sécurité et résilience, systèmes de management de la continuité d'activité), seconde édition qui annule et remplace celle de 2012. Sa clause 8 décrit l'enchaînement que cet article suit : analyse d'impact et appréciation des risques (8.2), stratégies et solutions de continuité (8.3), plans et procédures (8.4), programme d'exercices (8.5), évaluation (8.6). En France, le texte de référence reste le "Guide pour réaliser un plan de continuité d'activité" du SGDSN, édition 2013, 80 pages, écrit pour les administrations comme pour les entreprises, qui pose le même vocabulaire en français : activités essentielles, durée maximale d'interruption admissible, scénarios. Le mot rançongiciel n'y figure pas une seule fois, et ça se voit dans une partie des PCA qu'on trouve aujourd'hui dans les entreprises françaises.

Rédiger ce document, animer un BIA avec les métiers ou conduire un exercice de continuité relève du conseil en gouvernance, un métier qu'own2pwn n'exerce pas. Le PCA est donc regardé ici depuis l'autre bout, celui de l'attaquant qu'on simule, c'est-à-dire par la face mesurable du triptyque GRC.

Le BIA : trouver les processus qui ne peuvent pas attendre

Le bilan d'impact sur l'activité (BIA, pour business impact analysis) est l'étape que les PCA bâclés sautent, et ça se voit tout de suite : le plan protège "le SI" en bloc, comme si la paie et le site vitrine avaient le même poids. Le BIA prend chaque processus de l'entreprise et demande ce que coûte son arrêt après une heure, quatre heures, un jour, trois jours, une semaine. Le coût n'est pas seulement financier : pénalités contractuelles, déclaration réglementaire qui ne part pas, sécurité des personnes, image. Le résultat est une courbe par processus, et le point où la courbe devient inacceptable a un nom.

DMIA, RTO, RPO : trois chiffres, dans cet ordre

La durée maximale d'interruption admissible (DMIA, que l'ISO appelle MTPD, maximum tolerable period of disruption) est le délai au-delà duquel l'interruption du processus fait un dommage dont l'entreprise ne se relève pas, ou pas facilement. C'est une décision de direction, pas de DSI. Le RTO (recovery time objective) est le délai que l'on se fixe pour rétablir le processus, à un niveau de service minimal, et il doit être nettement plus court que la DMIA parce que tout, le jour J, prend plus de temps que prévu. Le RPO (recovery point objective) est la quantité de données que l'on accepte de perdre, exprimée en temps : un RPO de quatre heures veut dire qu'on retrouvera au pire l'état d'il y a quatre heures, donc que la sauvegarde ou la réplication doit tourner au moins à cette fréquence. Le ReCyF de l'ANSSI emploie DMIA et "point de rétablissement des données" (PRD) ; même chose, en français.

L'ordre compte. On fixe la DMIA d'abord, avec le métier, sans regarder ce que l'infrastructure sait faire. Ensuite seulement on en déduit le RTO et le RPO, et c'est là qu'on découvre l'écart avec la réalité : une sauvegarde nocturne donne un RPO de 24 heures quoi que dise le document, et un RTO de 4 heures sur un ERP hébergé chez un prestataire qui promet une intervention "sous 48 heures ouvrées" est un vœu. Le tableau qui suit est un exemple construit pour une PME industrielle d'une centaine de personnes ; les valeurs sont des ordres de grandeur à confronter à vos métiers avant d'être reprises.

La paie tolère un RPO d'un mois parce qu'on peut la reconduire, alors que la supervision d'atelier n'en tolère qu'une heure : le RPO dépend de ce qui est reconstructible à la main, pas de l'importance perçue du processus. Quant à la dernière colonne, celle du mode dégradé, elle coûte le moins et manque le plus souvent, alors qu'elle est la seule à transformer une intention en procédure applicable un lundi matin.

Les dépendances, ou ce que le BIA révèle qu'on ne savait pas

Chaque processus critique s'appuie sur des applications, des personnes, des fournisseurs et des locaux, et le BIA les liste. C'est en le faisant qu'on découvre que la prise de commande dépend d'une macro Excel que seule une personne sait relancer, ou que la téléphonie est de la VoIP hébergée sur le même réseau que tout le reste. Ce travail rejoint l'appréciation des risques ISO 27005 : mêmes actifs, mêmes dépendances, une question différente. Là où l'analyse de risques demande "qu'est-ce qui peut arriver ?", le BIA demande "et si ça arrive, combien de temps on tient ?".

Le rançongiciel comme scénario dimensionnant

Les PCA d'avant le rançongiciel sont dimensionnés sur l'incendie, la crue ou la pandémie, des scénarios qui frappent un lieu ou des personnes en laissant saine l'informatique du site de repli. Le rançongiciel casse cette hypothèse. Il détruit en même temps la production, l'annuaire, la messagerie, la téléphonie sur IP, le partage de fichiers où est rangé le PCA, et très souvent les sauvegardes atteignables depuis le domaine. Le site de repli branché sur le même annuaire est chiffré avec le reste. L'anatomie d'une attaque par rançongiciel montre en plus que l'attaquant est présent depuis des jours ou des semaines avant de chiffrer : le point de restauration sain n'est pas la veille, et ça change le RPO réel de tous les processus du tableau.

Un cas documenté par une source primaire donne la mesure. Dans le guide "Attaques par rançongiciels, tous concernés" publié par l'ANSSI en août 2020 avec la direction des affaires criminelles et des grâces du ministère de la Justice, le responsable sécurité de Fleury Michon raconte l'attaque de la nuit du 10 au 11 avril 2019 : coupure de toute liaison Internet et applicative, arrêt total de l'activité pendant trois jours, puis deux semaines de fonctionnement en mode dégradé. Trois jours d'arrêt, c'est le PRA. Deux semaines en mode dégradé, c'est le PCA, et c'est la partie longue. Le même guide recommande un "plan de continuité informatique" qui permette de fonctionner pendant l'altération du système, distinct du plan de reprise qui remet les systèmes en service, avec des moyens de communication de secours qui lui soient propres.

Dimensionner sur le rançongiciel impose donc trois hypothèses dures au plan. Le mode dégradé doit fonctionner sans aucun composant du domaine Windows, authentification comprise. Les moyens de communication de crise doivent être hors du système d'information principal : la mesure 14.2 du ReCyF demande une liste imprimée des personnes mobilisables, et la 14.10 des moyens de communication de secours quand les moyens habituels sont indisponibles. Enfin, la durée à tenir se compte en semaines, ce qui disqualifie les modes dégradés qui reposent sur la mémoire d'une personne ou sur un stock de formulaires pour deux jours.

Les stratégies de continuité : mode manuel, site de repli, fournisseurs de secours

Une stratégie de continuité est le moyen choisi pour tenir un processus sous sa DMIA. Il y en a peu, et chacune a un coût et un domaine de validité.

• Le mode manuel : le processus tourne au papier, au téléphone et au tableur local, puis on ressaisit. Il ne coûte rien et reste hors de portée d'un attaquant, mais il ne tient qu'à cadence réduite et suppose que les formulaires, les tarifs et les coordonnées clients existent hors du SI. Un stock de bons de commande imprimés et un export mensuel de la base clients sur une clé chiffrée dans un coffre font plus pour la continuité que bien des équipements.
• Le site ou l'environnement de repli : une seconde infrastructure, chez un hébergeur ou dans un cloud, capable de faire tourner les applications critiques. Contre le rançongiciel, sa valeur tient à une question : est-il joignable avec les comptes du domaine principal ? Si oui, il partira avec lui. L'article 12.3 de DORA exige, pour le secteur financier, que la restauration des sauvegardes faite avec ses propres systèmes s'appuie sur des systèmes séparés physiquement et logiquement du système source ; la règle vaut pour tout le monde.
• Le fournisseur de secours : pour les processus qui dépendent d'un tiers (transport, hébergement, paiement, paie), un second prestataire pré-contractualisé ou au moins qualifié, avec les données nécessaires à la bascule déjà exportées. C'est ce que la mesure 13.7-EE du ReCyF appelle s'appuyer sur la cartographie de l'écosystème.

Le choix se fait processus par processus, en regardant la DMIA. Un processus qui tolère cinq jours n'a pas besoin d'un environnement de repli chaud, un mode manuel documenté suffit ; un processus qui tolère quatre heures ne se sauvera pas avec du papier, et c'est en arbitrant ainsi, ligne par ligne, que le BIA finit par coûter moins cher qu'il ne rapporte.

Exemple de structure d'un plan de continuité d'activité

Un PCA lisible tient en huit chapitres. Le tableau ci-dessous donne la structure, le contenu attendu et surtout qui tient chaque partie à jour, parce qu'un plan dont le RSSI est seul propriétaire vieillit en six mois.

Le chapitre 7 est celui qu'on oublie. Deux semaines de commandes prises sur papier, ce sont deux semaines de commandes à ressaisir dans un ERP restauré à une date antérieure, avec des numéros qui se chevauchent et des stocks qui ne collent plus. Le retour à la normale se planifie comme la bascule, et prend souvent plus longtemps qu'elle. Le chapitre 5 recoupe largement le plan de gestion de crise cyber : la cellule est la même, seule la question posée change. Le plan de crise décide, le PCA exécute.

Tester : l'exercice sur table ne suffit pas

Un PCA jamais joué se reconnaît au premier exercice : la liste des personnes mobilisables date d'avant la dernière réorganisation, le kit de continuité est rangé sur un partage réseau, et le mode manuel suppose une imprimante qui s'authentifie sur le domaine. L'exercice sur table, où la cellule déroule un scénario à voix haute, attrape ces défauts-là pour pas cher ; c'est le minimum que le ReCyF fixe à la mesure 15.1 pour toutes les entités. Sa limite est qu'il ne produit aucune mesure. La seule donnée utile d'un PCA reste l'écart entre le RTO écrit et le délai constaté, et on ne l'obtient qu'en basculant un processus pour de vrai, un vendredi, chronomètre en main.

Les textes convergent sur la fréquence. La clause 8.5 d'ISO 22301 exige un programme d'exercices. La mesure 13.2 du ReCyF impose de tester sauvegarde et restauration au moins une fois par an, entités importantes comme essentielles. L'article 11.6 de DORA demande aux entités financières de tester leurs plans de continuité et de rétablissement des TIC au moins une fois par an et à chaque modification substantielle des systèmes qui soutiennent des fonctions critiques ou importantes ; hors microentreprises, les plans de test doivent inclure des scénarios de cyberattaque et de basculement vers la capacité redondante. Et l'article 21.2 (f) de NIS2, qui demande des procédures pour évaluer l'efficacité des mesures, s'applique au PCA comme au reste : un plan classé sans test n'évalue rien. Pour la partie métier, le seul indicateur honnête est le nombre de commandes, de dossiers ou de patients traités en mode dégradé par rapport à un jour normal.

Ce que NIS2, le ReCyF et DORA exigent d'un PCA

L'article 21.2 (c) de la directive NIS2 liste, parmi les mesures minimales, "la continuité des activités, par exemple la gestion des sauvegardes et la reprise des activités, et la gestion des crises". Le texte ne prescrit ni format ni méthode. C'est le ReCyF, le référentiel de cybersécurité de l'ANSSI (version 2.5 du 17 mars 2026, document de travail) qui le décline en France, dans son objectif de sécurité 13, "Continuité et reprise d'activité", avec une gradation nette entre entités importantes et essentielles.

• Pour toutes les entités (mesures 13.1 à 13.3 et 13.5) : des procédures de sauvegarde et de restauration testées au moins une fois par an, des sauvegardes protégées d'un incident qui les rendrait inexploitables (le référentiel cite le stockage hors ligne face au rançongiciel), et des mécanismes dimensionnés sur les besoins de disponibilité de chaque activité.
• Pour les entités essentielles seulement (13.4, 13.6, 13.7) : une DMIA et un point de rétablissement des données documentés pour chaque activité et service, puis un PCA et un PRA "adaptés aux scénarios de crises d'origine cyber et cohérents" avec ces deux valeurs, en s'appuyant sur la cartographie de l'écosystème et sur les procédures de gestion des incidents et des crises.

Une entité importante peut donc, au sens du référentiel, se limiter à des sauvegardes testées, là où une entité essentielle doit produire le BIA et le plan. Ce référentiel accompagne le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025, puis adopté en commission spéciale à l'Assemblée nationale le 10 septembre 2025, sans passage en séance publique à ce jour. Au moment de la rédaction (septembre 2026), je n'ai pas trouvé trace de sa promulgation, et les objectifs du ReCyF ne deviendront opposables qu'avec la loi et ses textes d'application. Pour savoir dans quelle catégorie vous tomberiez, le guide de la directive NIS2, entités concernées et calendrier français détaille les seuils.

Le secteur financier n'a pas cette latitude. Le règlement DORA, applicable depuis le 17 janvier 2025, impose à son article 11.1 une politique de continuité des activités de TIC intégrée à la politique globale de continuité, à l'article 11.5 une analyse des incidences sur les activités (le BIA, sous son nom réglementaire) fondée sur des critères quantitatifs et qualitatifs et sur des scénarios, et à l'article 12.6 des objectifs de délai et de point de rétablissement fixés pour chaque fonction selon son caractère critique. Le détail des obligations est dans l'article consacré au règlement DORA. Un PCA hors finance a tout à gagner à lire ce règlement, qui décrit avec précision ce qu'un auditeur d'un autre secteur tiendra pour l'état de l'art : BIA formel, RTO et RPO par fonction, test annuel avec scénario de cyberattaque.

À retenir

• Le plan de continuité d'activité décide comment l'entreprise fonctionne pendant l'incident ; le PRA décide comment on remet l'informatique debout. Le second est un chapitre du premier.
• Le BIA fixe, processus par processus, la DMIA (décision de direction), puis le RTO et le RPO qui en découlent. Le RPO se déduit de ce qui est reconstructible à la main, une notion indépendante de l'importance ressentie du processus.
• Dimensionner sur le rançongiciel impose un mode dégradé qui tourne sans le domaine, des moyens de communication hors du SI, et une durée à tenir qui se compte en semaines.
• Trois stratégies, choisies selon la DMIA : mode manuel, environnement de repli séparé du système source, fournisseur de secours pré-contractualisé.
• Un PCA sans chapitre "retour à la normale" et sans exercice réel chronométré ne démontre rien. NIS2 21.2 (c) et (f), ReCyF objectif 13 et DORA articles 11 et 12 convergent sur ce point.

Avant d'écrire ou de reprendre un PCA, il vaut la peine de savoir si vous êtes entité importante ou essentielle, le référentiel n'attendant pas la même chose des deux : le diagnostic NIS2 en ligne répond à cette question en quelques minutes. Et si le scénario rançongiciel de votre plan repose sur des hypothèses que personne n'a vérifiées depuis l'extérieur, le volet technique d'un audit NIS2 les confronte à ce qui est joignable depuis internet, console de sauvegarde et environnement de repli compris. C'est la preuve d'efficacité attendue par l'article 21.2 (f), celle qu'un plan, seul, ne fournit jamais.

Questions fréquentes sur le plan de continuité d'activité