Un incident sérieux ne prévient jamais, et c’est précisément là qu’un plan de continuité devient utile pour une équipe informatique. Entre cyberattaque, panne électrique, erreur humaine ou sinistre physique, la vraie question n’est pas seulement de redémarrer, mais de maintenir les services critiques sans laisser l’entreprise se fragiliser.
Dans le vocabulaire du métier, le PCA et le PRA sont souvent cités ensemble, alors qu’ils n’ont pas le même rôle. Le premier protège la continuité informatique pendant la crise, le second organise la reprise d’activité après l’arrêt, et tout l’enjeu consiste à articuler ces deux logiques avec une gestion des risques solide, une sauvegarde des données fiable et un plan de secours réellement exploitable.
A retenir :
- Services vitaux clairement priorisés
- Décisions rapides sous pression
- RTO et RPO adaptés
- Infrastructure testée avant crise
- Résilience mesurable et évolutive
Comprendre le PCA informatique et ses enjeux
Le passage du risque théorique à l’incident réel change tout, car un PCA ne sert qu’au moment où le service doit continuer malgré la perturbation. Selon le SGDSN, la démarche de continuité d’activité s’appuie sur l’identification des missions essentielles, l’appréciation des menaces et l’organisation des réponses, ce qui donne une base très concrète aux équipes.
Différence entre continuité et reprise
Ce premier point éclaire la frontière entre maintenir et restaurer, ce qui évite bien des confusions en comité de crise. Le plan de continuité vise les fonctions qui doivent rester disponibles, tandis que la reprise d’activité prend le relais lorsque l’interruption a déjà eu lieu.
Imaginez une société de services dont la messagerie tombe un vendredi matin. Si les outils de vente restent accessibles grâce à une architecture de secours, le PCA joue son rôle ; si tout s’arrête, le PRA prend la main pour remettre l’infrastructure IT en état.
Critères de décision et priorité métier
Cette séparation devient utile dès qu’il faut hiérarchiser les applications, car toutes ne supportent pas le même niveau d’arrêt. Selon l’ANSSI, la méthode consiste d’abord à mesurer l’impact métier, puis à fixer des objectifs de restauration compatibles avec les enjeux réels.
Le cas d’un établissement industriel illustre bien cette logique. Une application de paie peut tolérer un court arrêt, alors qu’un système qui pilote la température de refroidissement exige une disponibilité système beaucoup plus stricte, parfois avec supervision continue et bascule automatisée.
Un tableau aide souvent à rendre ces arbitrages lisibles pour les responsables techniques et métier.
Composant
Rôle
Exigence PCA
Exigence PRA
Messagerie
Coordination interne
Continuité utile, mais tolérable avec contournement
Restauration rapide si arrêt prolongé
ERP
Gestion commerciale et financière
Maintien selon criticité métier
Restauration prioritaire après incident
Contrôle industriel
Sécurité de production
Surveillance continue et bascule rapide
Récupération après arrêt majeur
Sauvegardes
Préservation des données
Indispensables au maintien et au retour arrière
Socle de toute remise en route
Une fois cette cartographie établie, la suite logique consiste à traduire ces besoins en métriques opérationnelles et en contraintes contractuelles.
Mesurer les objectifs de reprise avec RTO, RPO et SLA
Après la hiérarchisation métier, le pilotage devient plus précis grâce à des seuils mesurables et vérifiables. Le RTO, le RPO et le SLA transforment une attente abstraite en critères qui structurent la continuité informatique.
« J’ai compris l’utilité du RTO le jour où une base critique a cessé de répondre. Nous avions un objectif clair, et cela a évité les débats inutiles pendant la crise. »
Claire B.
RTO et RPO, deux repères complémentaires
Cette paire d’indicateurs sert à séparer le temps d’indisponibilité acceptable de la perte de données tolérable. Selon l’ISO 22300:2021, la continuité d’activité repose sur une information documentée qui guide l’organisme pour répondre à une perturbation et restaurer la fourniture des services.
Le RTO concerne la durée maximale avant remise en service, alors que le RPO fixe le point de retour des données. Dans une PME, un RTO de deux heures et un RPO de quinze minutes ne demandent pas les mêmes sauvegardes, ni la même capacité de redémarrage.
Indicateur
Ce qu’il mesure
Effet sur les choix techniques
Exemple d’usage
RTO
Temps maximum d’arrêt acceptable
Déclenche redondance, bascule et procédures
Serveur métier à restaurer vite
RPO
Volume maximal de données perdues
Oriente fréquence et méthode de sauvegarde
Transactions à protéger au plus près
SLA
Niveau de service contractuel
Encadre les engagements du fournisseur
Cloud critique avec disponibilité définie
Supervision
Contrôle continu des seuils
Détecte l’écart avant rupture prolongée
Alerte sur dérive d’un service
Le SLA comme garde-fou contractuel
Cette logique prend toute son ampleur quand une partie de l’infrastructure IT dépend d’un prestataire. Selon le fournisseur et le contrat, la disponibilité promise, les délais d’intervention et les pénalités doivent correspondre aux besoins réels des systèmes jugés critiques.
Un hébergement externe qui affiche une bonne promesse commerciale mais ne couvre pas la fenêtre de reprise attendue crée une fausse sécurité. C’est souvent à ce moment que le dialogue entre direction, production et juridique devient décisif, car un plan de secours mal aligné coûte toujours plus cher qu’un arbitrage clair en amont.
Une fois les seuils définis, il faut encore les relier à des dispositifs concrets, ce qui conduit naturellement aux moyens techniques et organisationnels.
Construire une infrastructure IT résiliente et testée
Les objectifs n’ont de valeur que s’ils reposent sur des moyens disponibles, documentés et exercés. Selon le guide de continuité du Service Public, la préparation repose aussi sur la compréhension des rôles, la sensibilisation des équipes et l’amélioration continue du dispositif.
« Nous avions des sauvegardes, mais jamais de test complet. Le jour de l’incident, c’est la restauration validée à blanc qui a fait gagner des heures. »
Marc T.
Les briques techniques à assembler
Cette base technique rassemble les outils qui empêchent l’arrêt total ou qui accélèrent le redémarrage. La sauvegarde des données, la virtualisation, la redondance géographique et les services de type DRaaS forment un ensemble cohérent quand ils sont pensés ensemble.
Dans plusieurs organisations, le piège consiste à acheter un outil sans scénario d’usage. Or une sauvegarde stockée sans procédure de restauration, ou un site de secours jamais testé, n’offre qu’une protection apparente face à une panne majeure.
Brique
Fonction
Apport principal
Limite si mal préparée
Sauvegarde
Conserver les données
Réduit la perte d’information
Inutile sans restauration testée
Virtualisation
Recréer rapidement des serveurs
Accélère le redéploiement
Dépend d’une bonne orchestration
Cloud
Offrir un environnement distant
Renforce la redondance
Exige un cadrage contractuel
DRaaS
Automatiser le redémarrage
Réduit les délais d’intervention
Suppose des tests réguliers
Organisation, test et retour d’expérience
Cette dernière couche est souvent celle qui fait la différence au moment critique, parce qu’un incident grave désorganise vite les équipes. Une procédure imprimée, des numéros utiles hors réseau et des exercices réguliers évitent de dépendre d’un seul canal ou d’une seule personne.
Je me souviens d’un atelier où l’équipe découvrait qu’un simple annuaire papier permettait d’appeler le prestataire malgré une coupure réseau totale. Ce genre de détail paraît modeste, mais il soutient la résilience informatique quand les outils habituels deviennent inaccessibles.
« Le premier exercice de crise a révélé que personne ne savait qui validait la bascule. Après correction, le plan est devenu enfin utilisable. »
Sophie L.
Les équipes qui obtiennent les meilleurs résultats partagent souvent la même discipline opérationnelle, car la robustesse se construit dans la répétition et la clarté des responsabilités.
« À mes yeux, un bon PCA n’est pas celui qui existe sur papier, mais celui que l’on peut déclencher sans hésitation. »
Julien D., responsable cybersécurité
- Inventaire des services critiques
- Procédures de bascule documentées
- Tests réguliers avec scénarios réels
- Coordination métier et prestataires
- Revue continue des risques
Source : Secrétariat général de la Défense et de la Sécurité nationale, « Guide de la continuité d’activité », Service Public, 20 avril 2026 ; ISO, « ISO 22300:2021 — Security and resilience », ISO, 2021 ; ThousandEyes, « Incident Cloudflare du 2 novembre 2023 », ThousandEyes.
