Presque toutes les organisations disposent de sauvegardes. Très peu savent réellement combien de temps il leur faudrait pour reprendre leur activité après une interruption grave, ni quels processus relever en premier. Cet écart, entre avoir des sauvegardes et avoir une continuité, est précisément ce qu'ISO 22301 met en ordre. Dans cet article, je vous explique ce qu'exige la norme, comment mener une analyse d'impact qui serve vraiment à décider, ce que signifient RTO et RPO quand il y a de l'argent en jeu, pourquoi un plan jamais testé ne compte pas, et comment tout cela s'articule avec ce que vous demandent déjà ISO 27001, NIS2 et DORA.
Ce qu'est ISO 22301 et le problème qu'elle résout
ISO 22301:2019 est la norme internationale des systèmes de management de la continuité d'activité. Ce n'est pas un manuel de reprise informatique : c'est un cadre qui permet à une organisation d'identifier les activités qu'elle ne peut pas se permettre de perdre, pendant combien de temps, et ce qu'elle a préparé pour les soutenir lorsque quelque chose lâche.
La différence avec un plan de reprise d'activité tient à la portée et à l'objet. La reprise regarde les systèmes ; la continuité regarde l'activité : les personnes, les locaux, les fournisseurs, les processus et les données. Un centre de données répliqué ne sert à rien si l'équipe qui opère le processus critique ne peut pas travailler et que personne n'a décidé qui déclare la crise.
Comme les autres normes de systèmes de management, elle suit la structure de haut niveau de l'Annexe SL, avec ses chapitres de contexte, leadership, planification, support, réalisation, évaluation des performances et amélioration. Si votre organisation travaille déjà avec ISO 27001, la charpente vous sera familière et une bonne partie du système est réutilisable.
Le BIA : là où tout se décide
L'analyse d'impact sur l'activité, le BIA, est la pièce qui soutient tout le reste de la norme. C'est là que l'on répond à une question inconfortable : si cette activité s'arrête, que se passe-t-il et à partir de quand cela commence à faire mal.
Un BIA qui sert à décider mesure l'impact dans la durée, et non à un instant unique. Le même arrêt d'un service de facturation peut être sans conséquence pendant deux heures, gênant au bout de huit et grave au bout de trois jours, quand tombent les échéances. C'est ce profil temporel qui fixe ensuite les priorités et le budget.
D'un BIA bien mené sortent trois choses qui serviront partout ailleurs : les activités priorisées, la durée maximale d'interruption admissible de chacune, et les ressources minimales nécessaires pour les soutenir, y compris les fournisseurs dont vous dépendez sans l'avoir jamais écrit.
L'erreur la plus fréquente que je rencontre en mission consiste à mener le BIA par direction et non par activité. Une direction ne s'interrompt pas : c'est un processus qui s'interrompt, et il traverse presque toujours plusieurs directions et un prestataire externe.
RTO et RPO, expliqués par un cas
Ce sont les deux chiffres qui commandent l'investissement, et on les confond sans arrêt. Mieux vaut les fixer sur un exemple.
Imaginez un cabinet qui établit des bulletins de paie. Le RTO, objectif de temps de reprise, c'est la durée pendant laquelle le service peut rester indisponible avant que le dommage ne devienne inacceptable : disons huit heures ouvrées. Le RPO, objectif de point de reprise, c'est le volume de données que vous pouvez vous permettre de perdre, mesuré en temps : si la sauvegarde est nocturne, le RPO est de vingt-quatre heures, et cela signifie qu'une panne à dix-huit heures efface une journée entière de travail qu'il faudra refaire à la main.
La conséquence pratique est directe : abaisser le RPO coûte de la technologie (réplication, sauvegardes plus fréquentes) et abaisser le RTO coûte de la préparation (environnements de repli, procédures répétées, personnes formées). Mettre les deux à zéro est une fiction coûteuse, et les fixer sans BIA revient à deviner.
Un troisième chiffre, souvent oublié, décide si les deux autres sont crédibles : la durée maximale d'interruption admissible. Si le RTO que vous avez retenu la dépasse, le plan ne protège rien : il documente seulement le moment où il échouera.
De la stratégie au plan que quelqu'un exécute
Une fois les objectifs fixés, la norme demande de choisir des stratégies de continuité et de les traduire en procédures concrètes. Les options habituelles sont de maintenir l'activité ailleurs, de la dégrader vers un mode manuel convenu, de la confier à un tiers, ou d'accepter le risque de façon explicite et documentée.
Accepter le risque est une réponse légitime, et il faut le dire, car la crainte de l'écrire conduit à inventer des plans que personne n'exécutera. Ce qui n'est pas légitime, c'est de ne pas l'avoir décidé.
Du côté du plan, ce qui distingue l'utile du décoratif, c'est qu'il réponde à quatre questions sans que personne ait à interpréter quoi que ce soit : qui décide de l'activer, qui est prévenu et par quel canal quand la messagerie d'entreprise est justement en panne, que fait-on dans les deux premières heures, et comment revient-on à la normale, la partie qui manque presque toujours.
Vous souhaitez vous certifier ISO 22301 Lead Implementer ?
Formation officielle PECB avec un consultant en activité, à votre rythme ou avec un coaching individuel.
Un plan jamais testé n'est pas un plan
C'est ici que se séparent les systèmes de management qui fonctionnent de ceux qui n'existent que dans un classeur. La norme exige un programme d'exercices et de tests, et ce n'est pas du formalisme : un plan jamais exécuté contient, sans exception, des hypothèses fausses.
Les exercices vont du plus léger au plus lourd et il n'est pas nécessaire de commencer par le plus coûteux : revue sur document, exercice sur table avec les responsables réels, simulation d'un composant précis, et enfin test avec bascule réelle. Chaque niveau révèle des choses différentes.
La valeur de l'exercice n'est pas de le réussir. C'est la liste de ce qui a mal tourné, avec un responsable et une date derrière chaque ligne.
La continuité ne se démontre pas le jour de l'incident : elle se démontre le jour de l'exercice. Celui qui n'a que le document découvre ses hypothèses fausses au pire moment, et devant des clients.
Articulation avec ISO 27001, NIS2 et DORA
C'est la partie qui intéresse le plus ceux qui sont déjà engagés dans un projet de conformité, car elle évite de payer deux fois le même travail.
Avec ISO/IEC 27001, le recouvrement est important : structure de haut niveau commune, analyse du contexte, maîtrise documentaire, audit interne et revue de direction. Ce qu'ISO 27001 traite comme une mesure, la continuité, ISO 22301 le développe comme un système complet.
NIS2 l'exige expressément : parmi les mesures de son article 21 figure la continuité d'activité, y compris la gestion des sauvegardes, la reprise après sinistre et la gestion de crise. Un système conforme à ISO 22301 est la manière la plus ordonnée de démontrer ce bloc devant une autorité.
Et pour les entités financières, DORA va encore plus loin : il impose une politique de continuité des TIC, des plans de réponse et de rétablissement, et des tests périodiques dont les résultats sont documentés. Les concepts sont les mêmes et le travail se réutilise presque intégralement.
Concrètement, cela signifie que le BIA mené pour ISO 22301 vous servira à justifier des décisions dans les trois autres cadres. Il vaut la peine de le faire bien une fois.
Se former et se certifier
Si vous souhaitez passer à la certification officielle PECB, trois niveaux existent selon votre besoin. ISO 22301 Foundation pour maîtriser le cadre et le vocabulaire. Lead Implementer si vous allez bâtir le système de management. Lead Auditor si vous allez l'auditer, pour votre compte ou celui d'un organisme de certification.
Les trois se suivent en auto-formation, avec le matériel officiel PECB et à votre rythme, ou avec un accompagnement en séances individuelles avec moi si vous préférez traiter vos questions sur votre cas réel plutôt que sur un exemple de manuel.