Un plan de continuité d'activité (PCA, ou BCP en anglais) est le document qui décrit comment votre entreprise continue de fournir ses produits et services critiques quand un événement l'interrompt : quels processus redémarrent en premier, en combien de temps, avec quelles ressources et qui prend les décisions. Un plan qui fonctionne comporte toujours les mêmes éléments : périmètre et critères de déclenchement, équipes et rôles, processus critiques avec leurs délais de reprise, stratégies et procédures pour les rétablir, communication, et calendrier de tests et de revue.
Vous trouverez plus bas trois exemples selon le type d'entreprise et un sommaire type à reprendre dans Word et à compléter avec vos propres éléments.
Les trois valeurs sur lesquelles repose le plan
Avant d'écrire la moindre page, le plan a besoin de trois valeurs pour chaque processus critique. Elles découlent du bilan d'impact sur l'activité (BIA), pas de l'intuition du responsable informatique.
- MTPD (durée maximale d'interruption tolérable). Le délai au-delà duquel le préjudice devient inacceptable : perte de clients, sanctions, manquements contractuels ou atteinte à la réputation dont on ne se relève pas.
- RTO (délai de reprise visé). Le délai dans lequel vous vous engagez à remettre le processus en fonctionnement, même en mode dégradé. Toujours inférieur au MTPD, avec une marge pour les imprévus.
- RPO (perte de données maximale admissible). La quantité de données que vous pouvez vous permettre de perdre, exprimée en temps. Un RPO de 15 minutes signifie qu'à la restauration, il peut vous manquer au plus les 15 dernières minutes d'opérations.
Avec ces trois valeurs, vous pouvez choisir une stratégie. Un RTO de quatre heures exige un site de secours prêt à l'emploi ; un RTO de cinq jours permet de contractualiser la solution de repli au moment de l'incident.
Exemples de plan de continuité d'activité selon le type d'entreprise
Les trois cas sont illustratifs : nous les avons construits pour montrer le raisonnement, il ne s'agit ni de clients ni de chiffres réels. Les délais varient selon la taille de l'entreprise, ses contrats et sa réglementation : voyez-les comme une façon de raisonner, pas comme des valeurs à recopier.
Établissement financier : paiements et virements des clients
Scénario. Une attaque par rançongiciel paralyse le centre de données principal à 10 heures, un jour ouvré. Le core banking et la plateforme de paiement ne répondent plus.
MTPD de 8 heures. Si les paiements de salaires et de fournisseurs des clients entreprises ne partent pas le jour même, on passe de la gêne au manquement : des clients qui ne paient pas leurs salariés, des réclamations et une discussion difficile avec le superviseur. La clôture de la journée fixe la limite.
RTO de 4 heures et RPO proche de zéro. Quatre heures laissent une marge pour, si la première reprise échoue, régler malgré tout avant la clôture. Le RPO doit être minimal, car perdre des transactions confirmées oblige à rapprocher à la main, avec un risque de doubles paiements.
Stratégie. Centre de données de secours avec réplication de la base transactionnelle et sauvegardes isolées du réseau, pour que le rançongiciel ne les atteigne pas. Pendant la restauration, une procédure manuelle pour les paiements de montant élevé, avec double signature et liste fermée d'opérations autorisées. Communication préparée pour les clients, les agences et le superviseur.
Distribution ou logistique : expéditions depuis l'entrepôt
Scénario. Une inondation ferme pendant une semaine le centre de distribution qui approvisionne 80 magasins. Le système de gestion d'entrepôt (WMS) fonctionne toujours, mais le bâtiment est inutilisable.
MTPD de 72 heures. Supposons que les magasins disposent de trois jours de stock sur les produits à plus forte rotation. Au-delà, ce sont des rayons vides, des ventes qui partent chez les concurrents et des pénalités avec les centres commerciaux si le magasin n'ouvre pas bien approvisionné.
RTO de 48 heures. Le temps nécessaire pour faire tourner un entrepôt de repli si l'accord est déjà signé. S'il faut le chercher pendant l'incident, le délai ne sera pas tenu.
Stratégie. Contrat-cadre avec un prestataire logistique (3PL) capable de réceptionner la marchandise et de faire du cross-docking dans une autre ville, liste de références prioritaires (inutile de déplacer tout le catalogue pour sauver les ventes) et accords avec les principaux fournisseurs pour qu'ils livrent directement en magasin pendant la crise.
Société de services ou entreprise tech : plateforme destinée aux clients
Scénario. Le fournisseur cloud subit une panne régionale et la plateforme que l'entreprise propose à ses clients devient indisponible.
MTPD de 24 heures. Ici, ce sont les contrats qui fixent la limite. Si les accords de niveau de service promettent 99,9 % de disponibilité mensuelle, la marge est d'environ 43 minutes par mois ; au-delà commencent les crédits de service, et après une journée les grands comptes commencent à reconsidérer le renouvellement.
RTO de 4 heures et RPO de 15 minutes. Le RTO s'aligne sur ce que le contrat tolère sans pénalité lourde, et le RPO sur la quantité de travail des clients qu'il est raisonnable de perdre.
Stratégie. Infrastructure déployable dans une deuxième région avec des sauvegardes répliquées, procédure de bascule testée, page de statut et modèles de message aux clients, et télétravail pour l'équipe support si les bureaux sont aussi perdus.
| Entreprise | Processus critique | MTPD | RTO / RPO | Stratégie principale |
|---|---|---|---|---|
| Établissement financier | Paiements et virements | 8 heures | 4 h / quasi nul | Site de secours avec réplication et sauvegardes isolées |
| Distribution ou logistique | Expéditions vers les magasins | 72 heures | 48 h / minimal (le WMS reste actif) | Prestataire logistique sous contrat préalable |
| Services ou tech | Plateforme destinée aux clients | 24 heures | 4 h / 15 min | Deuxième région et bascule testée |
Remarquez qu'aucune stratégie n'est improvisée le jour de l'incident. Dans les trois cas, ce qui permet de tenir le RTO, c'est quelque chose qui a été contractualisé, configuré ou testé à l'avance.
Structure d'un plan de continuité d'activité à reprendre
Voici le sommaire que nous utiliserions pour le plan de continuité d'activité d'une entreprise de taille moyenne ou grande. Si vous le reprenez dans Word, gardez le titre de chaque rubrique et remplacez les descriptions par votre contenu.
- Gestion documentaire. Version, date, propriétaire du plan, approbateur et date de la prochaine revue.
- Objectif et périmètre. Les sites, processus, produits et services couverts, et ce qui est explicitement exclu.
- Critères de déclenchement. Les événements qui déclenchent le plan, qui peut le déclencher et comment on décide de passer de l'incident à la crise.
- Organisation et rôles. Cellule de crise, coordinateur de la continuité, équipes de reprise par service, suppléants de chaque personne et arbre d'appel.
- Processus critiques. Liste priorisée issue du BIA, avec le MTPD, le RTO et le RPO de chacun et les ressources minimales pour fonctionner : personnes, systèmes, locaux, fournisseurs et informations.
- Scénarios retenus. Perte de locaux, de systèmes, de personnel ou d'un fournisseur critique. Mieux vaut peu de scénarios par type de perte qu'une longue liste de catastrophes.
- Stratégies de reprise. Pour chaque processus et chaque scénario, la solution retenue : site de secours, travail à distance, fournisseur de remplacement, procédure manuelle.
- Procédures de reprise. Fiches pas à pas par équipe, avec responsable, durée estimée et critère d'achèvement. C'est la partie que l'on lit pendant la crise : elle doit tenir en quelques pages.
- Communication. Messages préparés et canaux pour les salariés, les clients, les fournisseurs, les autorités et les médias, et qui s'exprime au nom de l'entreprise.
- Retour à la normale. Comment revenir du mode dégradé au fonctionnement habituel sans perdre de données ni dupliquer d'opérations.
- Tests et maintien en condition. Calendrier des exercices, résultats du dernier test, actions d'amélioration en attente et événements qui déclenchent une revue (changement de fournisseur, de système ou de site).
- Annexes. Annuaire des contacts, inventaire des ressources critiques, contrats des fournisseurs de repli et registres de déclenchement.
Plan de continuité d'activité, plan de continuité des opérations, PRA et plan de gestion de crise
Ces quatre appellations se mélangent dans les politiques, les cahiers des charges et les audits. Chacune répond à une question différente, et il vaut mieux qu'elles existent comme des éléments reliés entre eux plutôt que comme un document unique qui veut tout couvrir.
| Plan | Question à laquelle il répond | Périmètre | Qui le pilote |
|---|---|---|---|
| Plan de continuité d'activité (PCA) | Comment continuer à fournir l'essentiel ? | Toute l'organisation : processus, personnes, sites, fournisseurs et technologie | Continuité ou risques, avec la direction |
| Plan de continuité des opérations | Comment ce service ou ce processus continue-t-il de fonctionner ? | Un processus, une usine ou un service opérationnel | Le responsable de cette activité |
| Plan de reprise d'activité informatique (PRA, ou DRP) | Comment rétablir les systèmes et les données ? | Infrastructure et applications | DSI |
| Plan de gestion de crise | Qui décide et que communique-t-on ? | Prise de décision, communication et réputation | Cellule de crise ou direction générale |
« Plan de continuité des opérations » est l'appellation qui varie le plus d'une entreprise à l'autre. Certaines l'emploient comme synonyme de PCA ; d'autres, surtout dans l'industrie et la logistique, désignent ainsi les plans par usine ou par processus rattachés au plan général. L'important est que votre politique précise ce qu'il recouvre chez vous. Le PRA est l'une des stratégies du PCA : sans lui, pas de reprise technique, mais un PRA parfait ne règle ni un entrepôt inondé ni un site privé de personnel.
Ce qu'exige l'ISO 22301 et la place du BIA
L'ISO 22301:2019, Security and resilience. Business continuity management systems. Requirements, est la norme internationale certifiable pour les systèmes de management de la continuité d'activité. L'ISO l'a publiée en octobre 2019 et lui a ajouté en février 2024 un amendement (ISO 22301:2019/Amd 1:2024) qui impose d'évaluer si le changement climatique est un enjeu pertinent dans le contexte de l'organisation. L'ISO prépare déjà une nouvelle édition, au stade de projet de comité (ISO/CD 22301) : mieux vaut surveiller sa date de publication.
La norme ne fournit pas de modèle de plan. Elle exige un système : le BIA et l'appréciation des risques (paragraphe 8.2), les stratégies qui en découlent et des plans de continuité (paragraphe 8.4.4) testés et revus. C'est pourquoi un plan rédigé sans BIA ne passe pas un audit de certification, même si le document est bien écrit. Pour le détail de la norme, nous l'expliquons dans ce qu'est l'ISO 22301 et à quoi elle sert, et le passage du risque au BIA est traité dans le webinaire sur l'appréciation des risques et le BIA.
Si vous travaillez dans un établissement financier en Colombie, au Mexique ou dans un autre pays de la région, votre superviseur a en outre ses propres exigences en matière de continuité. Nous les passons en revue dans l'article sur la réglementation de la sécurité et de la continuité dans le secteur financier en Amérique latine.
Là où les plans de continuité échouent
D'après notre expérience, les plans échouent plus souvent à cause de ce qu'ils tiennent pour acquis que de ce qu'ils disent. Voici les points que nous examinerions en premier dans n'importe quel plan :
- Des RTO sans BIA derrière. « Quatre heures pour tout » sonne bien, mais si personne n'a demandé aux métiers à partir de quand le préjudice commence, le plan protège ce que l'informatique connaît et laisse de côté les processus qui n'ont pas de système dédié.
- Des fournisseurs hors du plan. Le plan suppose que le cloud, le transporteur ou le centre d'appels externalisé seront toujours là. Si un processus critique dépend d'un tiers, sa défaillance doit être un scénario, et son contrat doit permettre ce dont le plan a besoin.
- Des contacts et des suppléants périmés. L'arbre d'appel est la première chose utilisée et la première à se périmer. Un plan dont la moitié des numéros sont faux retarde le déclenchement dès la première minute.
- Des documents trop longs. Un plan de deux cents pages ne se lit pas pendant une crise. Ce sont les fiches réflexes par équipe, d'une ou deux pages, qui servent ; le reste est du contexte pour l'audit.
- Des tests qui ne testent rien. Un exercice sur table par an vaut mieux que rien, mais il ne prouve pas que le site de secours démarre. Nous alternerions exercices sur table et tests techniques réels du processus le plus critique.
Par où nous commencerions
Si vous partez de zéro, nous ferions le BIA de cinq à dix processus avant d'écrire quoi que ce soit, avec le responsable de chacun autour de la table. Ensuite, les stratégies pour ces processus, et seulement alors le document, avec le sommaire ci-dessus. Élargir le périmètre une fois le premier plan testé coûte bien moins cher que de corriger un plan que personne n'a jamais éprouvé.
Dans le module Continuité d'activité de GlobalSuite®, le BIA se fait au moyen de questionnaires adressés à chaque responsable, consolidés automatiquement, qui donnent le RTO et le RPO par processus ; les plans se construisent par scénario, avec leurs ressources critiques et la date de leur dernière revue. Les tests sont planifiés avec leurs résultats et leurs preuves, c'est-à-dire précisément ce que demande l'auditeur. Pour le voir sur vos propres processus, demandez une démo.
Sources officielles : fiches de l'ISO 22301:2019, de son amendement ISO 22301:2019/Amd 1:2024 et du projet ISO/CD 22301 sur iso.org. Les exemples de cet article sont illustratifs et ne correspondent à aucun client. Contenu revu en octobre 2026.
