Continuité & résilience Mis à jour : Juin 2026

Ces trois acronymes sont souvent confondus. Ils décrivent trois niveaux d'un même système de résilience, activés à des moments différents d'un incident.

L'erreur la plus fréquente : construire un PRA détaillé sans PCA. Pendant les premières heures d'un ransomware, l'activité doit continuer — les clients appellent, les commandes arrivent, les paiements doivent être traités. Si vous n'avez pas prévu comment fonctionner sans vos systèmes, vous perdez du chiffre d'affaires même avant d'avoir commencé la restauration.

La BIA est la fondation de tout plan de continuité. Elle répond à la question : "Si ce processus s'arrête, quand l'impact devient-il inacceptable ?" Sans BIA, vos RTO et RPO sont des chiffres arbitraires.

Les 4 étapes de la BIA :

1. Identifier les processus critiques : en collaboration avec les responsables métier (pas l'IT seul). Qui sont les processus qui génèrent directement du chiffre d'affaires ou qui ont des obligations légales ? Facturé, production, logistique, service client.
2. Quantifier l'impact financier : pour chaque processus, estimer le coût d'une interruption par heure, par jour, par semaine. Incluez les revenus perdus, les pénalités contractuelles, les coûts de travailleurs supplémentaires.
3. Déterminer le MTPD (Maximum Tolerable Period of Disruption) : jusqu'à quand l'interruption est-elle tolérable ? Au-delà de ce seuil, l'impact est catastrophique (perte de clients, violation contractuelle, insolvabilité).
4. Identifier les ressources minimales : quels sont les ressources, accès, données, équipements strictement nécessaires pour fonctionner en mode dégradé ? C'est la base du PCA.

L'erreur à éviter : laisser l'IT définir le RTO et le RPO. Ce sont des décisions business. L'IT dit "voici ce qu'on peut faire techniquement et à quel coût" — les métiers disent "voici ce que l'activité nécessite". Le CISO traduit les besoins métier en exigences techniques et en budget.

RTO, RPO et coût : plus l'objectif est ambitieux (RTO = 1h, RPO = 0), plus l'infrastructure nécessaire est coûteuse (réplication en temps réel, site de secours chaud). Voici l'ordre de coût croissant :

• Cold site (reprise en jours) : infrastructure de secours à configurer manuellement. Coût le plus faible.
• Warm site (reprise en heures) : infrastructure pré-configurée mais à démarrer. Coût intermédiaire.
• Hot site / réplication (reprise en minutes) : infrastructure en miroir fonctionnelle. Coût le plus élevé.

Pour la plupart des PME, un warm site (ou un cloud avec snapshotting fréquent) offre le meilleur rapport coût/RTO.

Un PCA efficace doit pouvoir être activé et suivi par n'importe quel membre de l'équipe désigné, sans nécessiter d'interprétation. Il doit être clair, précis, et tenu à jour.

Volume cible : 10-15 pages pour une PME. Un PCA de 50 pages ne sera pas consulté pendant une crise. Complétez avec des annexes pour les détails techniques.

La résilience ne dépend pas seulement de vos propres systèmes. Les fournisseurs, prestataires IT, solutions SaaS et infrastructures cloud peuvent tous être des points de défaillance unique. Cette cartographie est souvent la révélation la plus surprenante de la préparation à la continuité.

Questions à poser pour chaque dépendance critique :

• Si ce fournisseur tombe en panne, combien de temps avant que ça impacte l'activité ?
• Avons-nous une alternative ou un plan B ?
• Quelle est la disponibilité garantie par contrat (SLA) ? Avons-nous un droit à une compensation ?
• Avons-nous nos propres copies des données hébergées chez eux ?

Les organisations qui gèrent bien les crises ne doivent pas leur résilience à la chance — elles la doivent à leurs tests. Il existe 4 niveaux de tests, du plus simple au plus complet, à combiner selon vos ressources.

Le tabletop est le meilleur rapport qualité/effort en matière de test. En 2-3 heures, il révèle les lacunes de plan, les rôles flous et les décisions qui n'avaient pas été anticipées — sans toucher aux systèmes en production.

Scénario type (à adapter) :

Questions à débattre en équipe :

• Qui prend la décision d'activer le PCA ? Quel est le premier appel téléphonique ?
• Comment continuez-vous à traiter les commandes clients ce soir ?
• Les sauvegardes sont peut-être compromises — que faites-vous ?
• Payez-vous la rançon ? Qui décide ? Quel est le processus ?
• Quand et comment prévenez-vous vos clients ? Qui rédige le message ?
• L'incident doit-il être notifié à la CAI ? Qui le détermine et dans quel délai ?

Documentez chaque décision prise pendant l'exercice — les manques révélés (contacts manquants, procédures floues, décisions non prises) deviennent la liste de travail pour améliorer le plan.

La règle d'or de la communication de crise : un seul porte-parole désigné à l'avance. Des messages contradictoires de plusieurs sources aggravent la crise au lieu de la contenir.

Les 3 règles de la communication de crise :

1. Ne pas mentir — même par omission. Une information fausse découverte plus tard multiplie les dommages réputationnels.
2. Ne pas tout dire non plus — les détails techniques de l'attaque peuvent informer les attaquants ou des concurrents. Validation juridique avant chaque communication externe.
3. Préférer un message incomplet mais honnête à un silence prolongé — "Nous avons détecté un incident, nous enquêtons, nous vous tiendrons informés" vaut mieux que 48h de silence.

Le REX (ou "lessons learned") est l'outil qui transforme une crise en investissement. Sans REX structuré, les mêmes problèmes réapparaissent lors du prochain incident. Avec un bon REX, chaque incident améliore durablement la résilience.

Le REX en 5 questions (à conduire dans les 72h suivant l'incident) :

1. Qu'est-ce qui s'est passé exactement ? Chronologie détaillée, sans interprétation. Faits seulement.
2. Qu'est-ce qui a bien fonctionné ? Les mesures qui ont limité l'impact, les décisions correctes, les communications efficaces. À conserver et renforcer.
3. Qu'est-ce qui n'a pas fonctionné ? Les mesures défaillantes, les décisions tardives, les communications manquées. Sans chercher des coupables — chercher des systèmes défaillants.
4. Pourquoi ? Quelles sont les causes racines ? Ne pas s'arrêter à "l'employé a cliqué" — pourquoi il a cliqué, pourquoi le système a pu être compromis, pourquoi la sauvegarde n'était pas accessible.
5. Que ferons-nous différemment ? Actions concrètes, responsables désignés, délais. Pas "améliorer la sensibilisation" mais "lancer une simulation phishing mensuelle dès septembre — responsable : CISO".