Plan de continuité d’activité : construire, chiffrer et tester

Un plan de continuité d’activité (PCA) décrit comment une entreprise continue de fonctionner pendant une interruption, et en combien de temps elle revient à la normale. Il ne se juge pas à son épaisseur mais à deux chiffres, et au fait qu’on les ait déjà vérifiés en conditions réelles.

La plupart des plans échouent pour les mêmes trois raisons : ils ont été écrits par l’informatique seule, ils traitent toutes les fonctions au même niveau, et ils n’ont jamais été joués.

PCA ou PRA : la distinction utile

Le PCA est le volet métier : comment on continue de travailler pendant que le système est indisponible, en mode dégradé, avec des procédures temporaires et une communication organisée. Le PRA est le volet technique : dans quel ordre on restaure, vers quel environnement, et avec quelles vérifications avant remise en production.

L’un sans l’autre laisse un trou. Un PRA seul restaure un système pendant que l’entreprise est à l’arrêt depuis trois jours faute de mode dégradé. Un PCA seul organise la survie sans jamais dire comment on revient. Les définitions précises de ces sigles, ainsi que celles de RTO, RPO, DMIA et PDMA, figurent dans notre glossaire BCDR.

Les deux chiffres qui commandent tout

Le RTO est la durée d’interruption maximale acceptable. Le RPO est la quantité de travail que vous acceptez de perdre, exprimée en temps. Tout le reste du plan, et tout son coût, découle de ces deux nombres.

L’erreur la plus fréquente est de les fixer une fois pour toute l’entreprise. Un RTO de quatre heures appliqué uniformément coûte une fortune et n’a de sens pour presque aucune fonction. Le travail utile consiste à les fixer fonction par fonction.

• Fonctions vitales : leur arrêt stoppe l’activité ou déclenche une obligation réglementaire. RTO de quelques heures, RPO proche de zéro, moyens en conséquence.
• Fonctions importantes : leur arrêt dégrade sans bloquer. RTO d’une journée, RPO de quelques heures.
• Le reste : RTO de plusieurs jours, restauration depuis la sauvegarde ordinaire. Assumer qu’une partie du système redémarrera tard est ce qui rend le plan finançable.

Ce classement n’est pas une décision informatique. Il découle de l’analyse de risques, où la direction arbitre ce qui compte, et il s’acte dans la politique de sécurité.

Chiffrer le coût d’un arrêt

Un arbitrage n’est réel que si le coût de l’indisponibilité est posé en face du coût du dispositif. Le calcul n’a pas besoin d’être savant, il a besoin d’exister : marge perdue par jour d’arrêt, coût du personnel immobilisé, pénalités contractuelles éventuelles, coût de la reconstitution manuelle des données perdues, et effet commercial d’une indisponibilité visible par vos clients.

Confronter ce montant au prix d’un environnement de secours transforme une discussion technique en décision de gestion. C’est souvent à ce moment qu’une direction découvre qu’elle acceptait implicitement un risque qu’elle refuse dès qu’il est chiffré.

Ce que contient le plan

• La liste des fonctions avec leur criticité, leur RTO et leur RPO.
• Les dépendances de chaque fonction : applications, données, prestataires, réseau. Une fonction ne redémarre jamais seule.
• L’ordre de restauration, qui découle des dépendances et non de l’importance ressentie.
• Le mode dégradé : ce qu’on fait à la main, avec quels supports, et pendant combien de temps au maximum.
• Les rôles, nommés, avec un suppléant, et les coordonnées accessibles hors du système.
• Les seuils de déclenchement : à partir de quand on active le plan, et qui décide.
• La communication vers les salariés, les clients et, le cas échéant, le régulateur.
• Le calendrier des tests et l’archive des procès-verbaux précédents.

Les scénarios à couvrir

Un plan qui ne prévoit que la panne technique couvre le scénario le plus probable et le moins grave. Quatre familles méritent d’être traitées.

• La panne. Matériel, connectivité, électricité. Fréquente, généralement courte, bien couverte par les dispositifs classiques.
• La cyberattaque. Le scénario dimensionnant, traité plus bas, parce qu’il met en échec une partie des réflexes habituels.
• L’indisponibilité des locaux. Incendie, dégât des eaux, accès interdit. Le travail à distance a rendu ce scénario plus facile à absorber, à condition que les accès existent et aient été testés.
• La défaillance d’un prestataire. Votre hébergeur, votre éditeur métier, votre opérateur. C’est le scénario le plus négligé et celui que DORA regarde le plus attentivement, parce que vous ne le maîtrisez pas.

Le cas du rançongiciel

Il mérite un traitement à part parce qu’il met en échec deux dispositifs auxquels on fait spontanément confiance.

La haute disponibilité ne protège pas. Elle réplique en temps réel, donc elle réplique aussi le chiffrement. Un cluster parfaitement redondé se retrouve intégralement chiffré, des deux côtés, en quelques minutes. La haute disponibilité protège de la panne, jamais de la corruption.

Une sauvegarde reliée au domaine compromis l’est souvent aussi. C’est l’un des premiers gestes des attaquants, avant même de chiffrer. Une copie n’est une protection que si elle est isolée du domaine de production, avec ses propres identifiants, et immuable pendant une durée définie.

Le plan doit donc prévoir un environnement de reprise qui ne dépende pas de l’annuaire compromis, et un ordre de restauration qui commence par vérifier que la sauvegarde retenue est antérieure à l’intrusion, et pas seulement au chiffrement. Ces deux dates diffèrent souvent de plusieurs semaines. La conduite à tenir pendant l’événement est détaillée sur notre page gestion de crise cyber.

Tester, et le prouver

Un plan jamais joué est une hypothèse. Trois niveaux d’exercice existent, de coût très différent, et les trois sont utiles.

1. La revue documentaire. Deux heures autour d’une table à dérouler le scénario. Coût nul, et cela révèle déjà l’essentiel des trous, qui sont presque toujours organisationnels.
2. Le test technique partiel. On restaure réellement un périmètre limité et on mesure. C’est le seul moyen de savoir si le RTO annoncé est tenable.
3. L’exercice complet. Bascule sur l’environnement de secours, en conditions réalistes. Lourd, à réserver aux fonctions vitales, mais c’est le seul qui valide la chaîne entière.

Chaque exercice produit un procès-verbal : date, périmètre, durée réelle mesurée, écarts constatés, actions correctives et responsables. Un procès-verbal où tout est parfait à chaque fois inspire moins confiance qu’un procès-verbal qui documente un écart et sa correction.

Ce que DORA exige

Pour une entité financière régulée, la continuité n’est pas une bonne pratique. Le règlement impose une politique de continuité des activités informatiques documentée, des plans de réponse et de rétablissement, des objectifs de temps et de point de reprise définis, et des tests au moins annuels sur les systèmes qui supportent les fonctions critiques. Le régulateur ne demande pas si le plan existe, il demande les procès-verbaux. Le détail figure dans notre FAQ conformité et sur notre page sauvegarde et reprise pour la finance régulée.

Qui fait quoi

La criticité des fonctions et l’acceptation des délais relèvent de la direction : ce sont des arbitrages métier avec un coût en face. La construction technique, le dimensionnement et l’exécution des tests relèvent du prestataire. ITAIA met en place et supervise le dispositif de sauvegarde et de reprise, conduit les tests, en consigne les résultats et conserve les preuves. Nous ne réalisons pas l’analyse de risques amont, qui doit rester indépendante. Le partage complet des rôles figure sur notre page qui rédige quoi.

Côté moyens, le socle repose sur une sauvegarde 3-2-1 avec copie immuable et, pour les fonctions à RTO court, un environnement de reprise dans le cloud.

Questions fréquentes

Quelle différence entre un PCA et un PRA ?

Le PCA est le volet métier : comment l’entreprise continue de fonctionner pendant l’interruption, en mode dégradé. Le PRA est le volet technique : comment le système d’information est restauré, dans quel ordre et en combien de temps. Les deux sont nécessaires, et l’un sans l’autre laisse un trou.

Comment fixer son RTO et son RPO ?

Fonction par fonction, jamais uniformément pour toute l’entreprise. On classe les fonctions par criticité, on chiffre le coût d’une journée d’arrêt pour chacune, puis on confronte ce montant au prix du dispositif nécessaire. L’arbitrage appartient à la direction, parce qu’accepter un délai de reprise est une décision de gestion et pas un paramètre technique.

Un plan de continuité d’activité est-il obligatoire ?

Pas pour une entreprise ordinaire. Il l’est en revanche pour les entités financières soumises à DORA, qui doivent documenter leur politique de continuité, définir des RTO et RPO et tester au moins une fois par an. Il devient également nécessaire en pratique pour de nombreux appels d’offres et pour souscrire une assurance cyber.

La haute disponibilité remplace-t-elle un plan de reprise ?

Non, et les confondre est dangereux. La haute disponibilité protège de la panne en répliquant en temps réel, mais elle réplique aussi une suppression, une corruption ou un chiffrement par rançongiciel, qui se propagent instantanément à la copie. Elle protège de l’arrêt, jamais de la perte.

À quelle fréquence tester son plan de continuité ?

Une revue documentaire deux fois par an, un test technique de restauration au moins une fois par an, et un exercice complet sur les fonctions vitales selon leur criticité. À quoi s’ajoute un test après tout changement d’architecture significatif, car c’est précisément à ce moment que les plans se périment sans qu’on s’en aperçoive.

Savoir en combien de temps vous redémarreriez

En trente minutes, nous regardons l’isolement réel de vos sauvegardes, la date de votre dernier test de restauration et les fonctions dont vous n’avez jamais chiffré l’arrêt. Vous repartez avec les écarts et leur ordre de traitement, sans engagement. Prendre rendez-vous.