Un plan de continuité informatique sert à maintenir les fonctions essentielles du système d’information quand une crise, une panne majeure ou un sinistre perturbe l’activité. Pour beaucoup d’organisations, ce sujet n’est plus réservé aux grandes entreprises. La dépendance aux applications métiers, au cloud, à la messagerie, au réseau et à la téléphonie rend la continuité indispensable, y compris pour des structures de taille moyenne.
Le sujet est aussi très concret. Une indisponibilité de quelques heures peut bloquer la production, empêcher la facturation, retarder les soins, couper la relation client ou exposer des données sensibles. Début 2025, un sondage relayé par Wikipedia indiquait que 76 % des collectivités françaises interrogées ne disposaient ni d’un PCA ni d’un PRA. Ce chiffre montre l’écart entre le niveau de dépendance numérique et le niveau réel de préparation.
Un plan solide repose sur une méthode, des priorités métier, des choix techniques réalistes et des tests réguliers. Les normes ISO 22301, ISO 27001-27002 et ISO 24762, ainsi que les guides du SGDSN, de la CNIL et de l’Agence du Numérique en Santé, fournissent un cadre utile pour structurer la démarche.
Qu’est-ce qu’un plan de continuité informatique
Le plan de continuité informatique, souvent abrégé PCI, est une composante du plan de continuité d’activité ou PCA. Il regroupe les dispositifs organisationnels, techniques et humains qui permettent au système d’information de continuer à fonctionner, totalement ou partiellement, malgré un incident majeur.
Son objectif est double :
- redémarrer l’activité du SI le plus rapidement possible,
- minimiser la perte de données.
Dans les faits, le PCI définit ce qui doit rester disponible, ce qui peut fonctionner en mode dégradé, ce qui doit être relancé en priorité, et comment organiser la réponse de crise. Il ne s’agit pas seulement d’un document technique. Un bon plan précise aussi les rôles, les procédures d’alerte, les circuits de décision, les dépendances entre services et les moyens de communication internes et externes.
Selon le contexte, on parle aussi de plan de secours informatique. Le vocabulaire varie, mais la logique reste la même, assurer la continuité des opérations critiques lorsque l’informatique est touchée.
Pourquoi mettre en place un plan de continuité informatique
La majorité des activités dépendent aujourd’hui du système d’information. Gestion commerciale, ERP, GPAO, CRM, téléphonie IP, dossiers métiers, outils RH, messagerie, accès Internet, authentification, sauvegardes, applications cloud, tout est interconnecté. Quand un maillon tombe, l’impact se propage vite.
Mettre en place un plan de continuité informatique permet de :
- réduire les interruptions de service,
- protéger les données sensibles et les traitements essentiels,
- limiter les pertes économiques liées à l’arrêt de production ou de vente,
- préserver la réputation de l’organisation,
- rassurer clients, partenaires, assureurs et donneurs d’ordre,
- maintenir certaines activités en mode dégradé,
- mieux répondre aux obligations contractuelles, réglementaires ou sectorielles,
- améliorer la résilience opérationnelle de l’entreprise.
Une interruption prolongée peut coûter très cher, autant sur le plan financier qu’humain. Elle peut aussi désorganiser durablement les équipes. Le PCI sert donc à préparer l’entreprise avant la crise, pas à improviser pendant la crise.
La CNIL, sur une page datée du 14 mars 2024, rattache d’ailleurs la continuité et la reprise à la sécurité des données. Cette approche rappelle qu’un incident informatique ne concerne pas uniquement la disponibilité des outils, mais aussi la protection des informations personnelles et stratégiques.
Quelle est la différence entre un plan de continuité informatique et un plan de reprise d’activité
Le plan de continuité informatique et le plan de reprise d’activité sont liés, mais ils ne couvrent pas exactement le même besoin.
| Élément | Plan de continuité informatique | Plan de reprise d’activité |
|---|---|---|
| Objectif principal | Maintenir ou rétablir un service minimal sans arrêt total si possible | Relancer un système ou une activité après un arrêt |
| Logique | Continuité, mode dégradé, limitation de l’impact | Reprise après sinistre ou interruption |
| Moment d’action | Pendant la perturbation | Après l’arrêt ou la destruction du service |
| Contenu typique | Mesures préventives, palliatives, organisation de crise, bascule, procédures de maintien | Restauration, reconstruction, remise en route, réintégration des données |
| Finalité métier | Éviter l’arrêt complet quand c’est possible | Programmer le redémarrage dans des délais acceptables |
Le PRA gère l’arrêt de l’activité et la remise en route du SI. Le PCI, lui, cherche d’abord à éviter cet arrêt ou à en réduire l’ampleur grâce à des mesures de continuité. Dans une organisation mature, les deux dispositifs sont cohérents et documentés ensemble ou de manière très articulée.
Que doit contenir un plan de continuité informatique
Un PCI utile n’est ni un simple inventaire technique, ni un document théorique. Il doit décrire les priorités métier, les scénarios retenus, les solutions de continuité, les procédures de crise et les limites assumées.
Le périmètre, les activités critiques et les dépendances
Le point de départ consiste à définir le périmètre du plan. Tous les systèmes ne se valent pas. Il faut identifier :
- les activités essentielles de l’organisation,
- les processus indispensables à ses objectifs et à ses obligations,
- les applications critiques,
- les ressources techniques associées, serveurs, réseau, postes, téléphonie, accès Internet, cloud,
- les dépendances internes et externes, dont les prestataires et sous-traitants.
Cette cartographie permet de comprendre ce qui doit être rétabli en premier et dans quel ordre. Une application peut sembler secondaire sur le papier, mais devenir critique si elle conditionne la connexion à d’autres services, la traçabilité, la production ou la relation client.
Le guide du SGDSN, publié en 2013, propose d’ailleurs des fiches pratiques sur le périmètre, les activités essentielles, la cartographie des processus et l’identification des besoins de continuité. Il comprend 27 fiches pratiques, ce qui en fait une base de travail solide.
Les risques et scénarios à couvrir
Le PCI doit reposer sur une analyse de risque et une analyse d’impact. La première identifie les menaces. La seconde mesure les conséquences d’une interruption et le moment à partir duquel l’impact devient intolérable.
Les scénarios à couvrir incluent souvent :
- incendie,
- inondation, tempête, séisme,
- panne de courant,
- défaillance matérielle,
- erreur humaine ou mauvaise manipulation,
- cyberattaque, hacking, violation de sécurité,
- acte de malveillance interne ou externe,
- grève, pandémie, indisponibilité d’équipe,
- incident affectant seulement le SI,
- incident affectant la structure mais pas le SI,
- incident affectant la structure et le SI,
- interruption partielle et planifiée du SI.
Les guides recommandent aussi d’intégrer des scénarios extrêmes, y compris la destruction totale du bâtiment. Cette approche évite de construire un plan trop optimiste, incapable de tenir face à une vraie rupture.
Les procédures, responsabilités et moyens de communication de crise
Le document doit expliquer clairement qui fait quoi, quand et avec quels moyens. Cela comprend :
- les critères de déclenchement du plan,
- la chaîne d’alerte,
- les rôles de la cellule de crise,
- les coordonnées des intervenants internes et externes,
- les procédures techniques de bascule, de restauration et de reprise,
- les moyens de communication de crise,
- les messages types pour les utilisateurs, prestataires, partenaires ou clients,
- les conditions de retour à la normale.
Les utilisateurs, prestataires et sous-traitants doivent savoir qui alerter en cas d’incident. Ce point paraît basique, mais il fait souvent la différence entre une gestion rapide et plusieurs heures perdues.
Le guide de l’Agence du Numérique en Santé, publié en août 2022, version v1.1, insiste justement sur l’organisation, les scénarios d’incident, les besoins métiers, les mesures existantes, les tests et le maintien à jour du PCI. Il inclut aussi un chapitre sur les limites du PCI, sujet souvent négligé.
Comment définir le RTO et le RPO
Le RTO et le RPO sont deux indicateurs centraux d’un plan de continuité informatique.
- RTO (Recovery Time Objective) : durée maximale pendant laquelle un service, une application ou une ressource peut rester indisponible.
- RPO (Recovery Point Objective) : volume maximal de données qu’il est acceptable de perdre, exprimé en temps.
Le RTO dépend du métier. Pour une entreprise industrielle, le guide cité donne l’exemple d’un logiciel de GPAO avec un RTO de quelques minutes. À l’inverse, une application secondaire peut tolérer plusieurs heures, voire une journée.
Le RPO pilote directement la stratégie de sauvegarde. Si l’objectif est un RPO de 4 heures, il faut organiser des sauvegardes ou des réplications compatibles avec cette contrainte. Deux sauvegardes quotidiennes peuvent suffire dans certains contextes, mais deviennent insuffisantes dès que la volumétrie, la criticité ou la fréquence des transactions augmentent.
| Niveau de criticité | Exemple de service | RTO indicatif | RPO indicatif |
|---|---|---|---|
| Très critique | ERP de production, GPAO, dossier patient, paiement | Quelques minutes à 1 heure | 0 à 15 minutes |
| Critique | Messagerie, CRM, fichiers partagés stratégiques | 1 à 4 heures | 15 minutes à 4 heures |
| Important | Intranet, reporting, outils support | 4 à 24 heures | 4 à 24 heures |
| Secondaire | Archives, environnements non critiques | 24 à 72 heures | 24 heures ou plus |
Le bon niveau de RTO et de RPO résulte d’un arbitrage entre :
- l’impact métier d’une interruption,
- le coût des solutions techniques,
- la faisabilité opérationnelle,
- les engagements réglementaires ou contractuels.
Une architecture de haute disponibilité peut aller très loin. Certains environnements virtualisés avec deux salles serveurs actives et une réplication synchrone des données visent un RPO à 0 et un RTO à 0. C’est efficace, mais coûteux et rarement nécessaire pour tout le système d’information.
Les étapes pour construire un plan de continuité informatique
La méthode varie selon les guides, mais les grandes étapes se recoupent. Le SGDSN parle d’une démarche en 10 étapes, Adenium en 5 phases, et l’ANS en plusieurs blocs allant du recueil du besoin métier jusqu’au maintien à jour du dispositif.
Préparer le projet et recueillir les besoins métiers
La première étape consiste à cadrer le projet. Il faut fixer les objectifs, nommer les responsables, choisir le périmètre et recueillir les besoins des métiers. Cette phase sert à éviter un PCI purement informatique, déconnecté de la réalité opérationnelle.
Les travaux à mener incluent :
- l’inventaire des processus essentiels,
- la cartographie des flux,
- l’identification des ressources critiques,
- l’analyse d’impact métier,
- l’évaluation des temps d’interruption admissibles,
- le recensement des mesures déjà en place.
Un audit d’infrastructure peut être utile pour établir un cahier des charges fiable. Certaines approches recommandent qu’il soit piloté par le responsable informatique, le responsable qualité ou un spécialiste externe indépendant.
Choisir les mesures de continuité, de secours et de reprise
Une fois les priorités et les risques connus, il faut sélectionner les solutions. Le guide ANS distingue trois familles de mesures :
- mesures de prévention, pour réduire la probabilité d’incident,
- mesures palliatives, pour maintenir le service en mode dégradé,
- mesures de secours, pour assurer la continuité ou la reprise.
Les choix peuvent porter sur :
- la redondance de stockage, par exemple en RAID,
- les onduleurs pour les traitements essentiels, recommandés par la CNIL,
- les sauvegardes locales et externalisées,
- les sites de secours,
- la réplication de données,
- la virtualisation,
- les accès réseau de secours,
- les postes clients de remplacement,
- la téléphonie de continuité,
- les procédures de fonctionnement dégradé.
Chaque solution doit être évaluée selon son coût, son efficacité, ses contraintes techniques et son impact sur le reste de l’activité. Il faut aussi anticiper la réversibilité et la réintégration des données au retour à la normale.
Rédiger, documenter et diffuser le plan
Le PCI doit ensuite être formalisé dans une documentation exploitable sous stress. Les documents trop lourds ou trop abstraits sont rarement utiles en situation réelle.
Un plan opérationnel comprend souvent :
- une synthèse de gouvernance,
- les scénarios de déclenchement,
- les fiches réflexes par type d’incident,
- les procédures techniques détaillées,
- la liste des contacts et astreintes,
- les dépendances fournisseurs,
- les modèles de communication,
- les check-lists de retour à la normale,
- l’historique des versions et mises à jour.
La diffusion doit être maîtrisée. Les bonnes personnes doivent avoir accès au bon niveau d’information, y compris hors du SI principal si celui-ci devient indisponible.
Les mesures techniques à prévoir pour le système d’information
Le plan de continuité informatique doit couvrir toute la chaîne technique, du poste client aux serveurs, en passant par le réseau, les sauvegardes, la téléphonie et les services cloud.
Sauvegardes, restauration et réintégration des données
Les sauvegardes restent la base de nombreux dispositifs. Elles servent à limiter la perte de données et à restaurer un niveau de service acceptable après incident. Le plan doit préciser :
- quelles données sont sauvegardées,
- à quelle fréquence,
- où elles sont stockées,
- qui peut lancer une restauration,
- dans quels délais,
- comment se fait la réintégration dans l’environnement nominal.
Les données à protéger ne se limitent pas aux bases de production. Messagerie, courriels, contacts clients, fournisseurs et prestataires doivent aussi être pris en compte selon les besoins de l’organisation.
Le point décisif reste le test de restauration. Une sauvegarde non testée n’apporte aucune garantie réelle.
Redondance, serveurs de secours, réseau et téléphonie
Quand l’indisponibilité n’est pas tolérable, la redondance devient nécessaire. Elle peut concerner :
- les baies de stockage,
- les hyperviseurs,
- les liens Internet,
- les équipements réseau,
- la téléphonie,
- les alimentations électriques,
- les sites d’hébergement.
Le guide Adenium, daté de septembre 2018, cite notamment les sites de secours, les sauvegardes, le LAN/WAN/Internet, les postes clients et la téléphonie. Cette vision est utile car un PCI échoue souvent non pas sur le serveur principal, mais sur une dépendance périphérique oubliée.
Cloud, haute disponibilité et mode dégradé
Le cloud peut faciliter la continuité à condition d’être bien cadré. Il ne remplace pas un PCI, mais il peut améliorer la résilience grâce à :
- la duplication géographique,
- les services managés,
- les mécanismes natifs de réplication,
- la montée en charge rapide,
- les environnements de secours.
Il faut toutefois vérifier les engagements contractuels, les dépendances réseau, les modalités de réversibilité et les responsabilités exactes entre le client et le fournisseur.
Le mode dégradé mérite une attention spécifique. Continuer à fonctionner partiellement peut être préférable à un arrêt complet, mais pas au prix d’une baisse incontrôlée du niveau de sécurité. Toute procédure dégradée doit intégrer les nouveaux risques qu’elle crée, notamment pour la confidentialité, l’intégrité et la traçabilité des données.
Qui doit rédiger un plan de continuité informatique
La rédaction d’un PCI ne doit pas être laissée à une seule personne. Le responsable informatique joue souvent un rôle central, mais le document doit associer plusieurs fonctions :
- direction générale ou direction de site,
- DSI ou responsable informatique,
- métiers responsables des processus critiques,
- RSSI, quand la fonction existe,
- responsable qualité ou conformité,
- prestataires techniques clés,
- partenaires externes selon les dépendances.
Une stratégie de protection informatique peut être pilotée par le responsable informatique ou le responsable qualité, avec l’appui de spécialistes indépendants. Cette approche aide à objectiver les priorités, à challenger les hypothèses techniques et à construire un budget cohérent.
Le plus utile consiste à nommer un pilote du PCI, responsable de la coordination, tout en confiant à chaque domaine des fiches précises et des responsabilités claires.
À quelle fréquence faut-il tester un plan de continuité informatique
Un PCI non testé vieillit vite. Les infrastructures changent, les applications évoluent, les prestataires bougent, les équipes tournent. Sans vérification régulière, le plan devient théorique.
Exercices, tests ciblés et test de restauration
La bonne fréquence dépend du niveau de criticité, mais un principe s’impose, tester régulièrement et sous plusieurs formats.
Les exercices peuvent prendre plusieurs formes :
- revue documentaire et validation des contacts,
- test de restauration de sauvegardes,
- simulation de crise sur table,
- test ciblé d’un composant critique,
- bascule partielle vers une solution de secours,
- test de continuité d’une application prioritaire,
- arrêt complet du SI, ponctuellement, quand cela est possible et utile.
Les bonnes pratiques recommandent de réaliser des exercices avec toutes les parties prenantes, tout en privilégiant parfois des tests ciblés pour limiter l’impact sur la production. Les éléments les plus critiques doivent être vérifiés de temps à autre dans des conditions proches du réel.
Mise à jour du plan et retour d’expérience
Chaque test, incident ou crise réelle doit produire un retour d’expérience. C’est à ce moment que le PCI progresse vraiment. Il faut analyser :
- ce qui a fonctionné,
- ce qui a pris trop de temps,
- les dépendances oubliées,
- les écarts entre le document et le terrain,
- les évolutions du SI non intégrées,
- les besoins de formation des équipes.
Le maintien en conditions opérationnelles repose sur cette boucle d’amélioration. Un PCI vivant suit le développement de l’infrastructure, les changements de prestataires, les nouveaux usages cloud et les modifications d’organisation.
Combien coûte la mise en place d’un plan de continuité informatique
Le coût d’un plan de continuité informatique varie fortement selon le périmètre, le niveau d’exigence et les objectifs de RTO et de RPO. Il n’existe pas de budget universel.
Les principaux postes de dépense sont :
- l’audit initial et l’analyse d’impact,
- la rédaction du plan et de la documentation,
- les sauvegardes et solutions de stockage,
- les onduleurs et protections électriques,
- la redondance matérielle et réseau,
- les licences logicielles ou services cloud de secours,
- les sites de secours ou ressources d’hébergement alternatives,
- les tests, exercices et formations,
- la maintenance et les mises à jour du dispositif.
Le bon raisonnement consiste à comparer le coût du PCI avec le coût d’une interruption. Perte de chiffre d’affaires, arrêt de production, pénalités contractuelles, surcharge des équipes, image dégradée, perte de données, exposition juridique, chaque organisation doit chiffrer ces impacts.
Un dispositif simple peut déjà apporter une vraie réduction de risque, à condition d’être aligné sur les activités critiques. À l’inverse, viser une haute disponibilité généralisée avec réplication synchrone, doubles salles serveurs et bascule automatique peut représenter un investissement important, justifié seulement pour certains environnements.
La meilleure décision n’est pas de dépenser le plus possible. C’est de choisir un niveau de continuité cohérent avec les enjeux métier, les obligations de l’organisation et le risque résiduel accepté. C’est aussi le moyen le plus concret d’éviter qu’une panne sérieuse se transforme en crise durable.
