Le PCA organise le maintien des activités essentielles pendant une interruption ; le PRA prépare la restauration des systèmes et données. Une démarche efficace part des impacts métier, fixe des objectifs RTO et RPO réalistes, documente les dépendances, les rôles et les procédures, puis vérifie la capacité réelle par des tests réguliers.
DSI, RSSI, Directions générales, Responsables continuité, PME et ETI.
Explorer les outils DSILe plan de continuité d’activité vise à maintenir les activités prioritaires, éventuellement en mode dégradé. Le plan de reprise d’activité organise le redémarrage des systèmes après l’interruption. Les deux sont liés : les besoins métier déterminent les priorités et délais de reprise que la DSI doit rendre techniquement réalisables.
Identifiez les activités, leurs périodes sensibles, les conséquences d’une interruption et les ressources minimales afin de déterminer les priorités de reprise. Déterminez les dépendances à des personnes, locaux, applications, données, réseaux et fournisseurs. Cette analyse permet de fixer les objectifs plutôt que de reprendre des délais théoriques non validés.
Le RTO exprime le délai cible de remise en service ; le RPO représente la perte de données maximale acceptable dans le temps. Ces objectifs doivent être cohérents avec les architectures, sauvegardes, contrats et moyens disponibles. Documentez aussi le service minimum et les traitements à rattraper.
Une sauvegarde n’apporte de résilience que si elle est protégée, surveillée et restaurable. Vérifiez périmètre, fréquence, rétention, séparation, accès, chiffrement adapté et copies hors ligne lorsque le risque le justifie, en veillant à vérifier les engagements de reprise des fournisseurs. Testez la restauration complète avec les dépendances et mesurez les délais réels.
Précisez qui décide, qui coordonne, comment alerter, quels contacts utiliser et comment communiquer si les outils habituels sont indisponibles. Les procédures doivent être accessibles hors du SI affecté, ordonnées selon les dépendances et suffisamment concrètes pour être exécutées sous contrainte.
Alternez revues documentaires, exercices sur table, restaurations techniques et simulations plus complètes. Chaque test produit des mesures, des écarts, des responsables et des échéances. Mettez à jour le dispositif après les projets, changements de fournisseurs, incidents et évolutions des activités critiques.
Le plan de continuité d’activité organise le maintien ou la reprise minimale des activités métier pendant une perturbation. Le plan de reprise d’activité informatique décrit la restauration des systèmes, données et infrastructures qui les soutiennent. Le PRA contribue donc au PCA sans le remplacer. Les deux doivent partager les mêmes priorités, responsables, hypothèses de crise et critères de retour à la normale.
Réalisez une analyse d’impact métier avec les responsables opérationnels. Pour chaque activité, estimez les conséquences d’une interruption dans le temps : sécurité, clients, obligations, finance, production et réputation. Identifiez la période maximale tolérable, les volumes minimaux, les échéances et les solutions de contournement. Les activités déclarées critiques doivent être comparées entre elles afin de résoudre les priorités contradictoires.
Le RTO fixe le délai cible pour restaurer un service ; le RPO fixe la perte de données maximale admissible exprimée dans le temps. Définissez-les à partir de l’impact métier, puis vérifiez qu’ils sont techniquement atteignables et financés. Un RPO de quatre heures exige des sauvegardes ou réplications compatibles ; un RTO très court peut nécessiter une architecture redondante et des équipes mobilisables.
Testez des scénarios qui rendent indisponibles des ressources différentes : site, système d’information, données, réseau, fournisseur, équipe clé ou énergie. Incluez une cyberattaque avec suspicion de compromission des sauvegardes, car la restauration y diffère d’une panne classique. Choisissez des scénarios crédibles mais exigeants, puis variez les hypothèses pour éviter qu’un plan ne fonctionne que dans un cas écrit à l’avance.
Testez au moins annuellement les services critiques et après une évolution majeure d’architecture, de fournisseur ou d’équipe. Complétez l’exercice complet par des tests plus fréquents de restauration, de communication et de mobilisation. La fréquence doit suivre la criticité et la vitesse de changement. Chaque test doit produire des preuves, des écarts, un responsable de correction et une date de nouveau contrôle.
Identifiez les services dépendants, les engagements contractuels, les contacts de crise, les sites de secours, les sauvegardes et les sous-traitants du fournisseur. Comparez ses objectifs de reprise à vos besoins métier et demandez des preuves de tests. Prévoyez les solutions de contournement, l’accès aux données et la réversibilité. Une clause contractuelle ne garantit pas la capacité opérationnelle lors d’une crise simultanée chez plusieurs clients.
Un test de sauvegarde consiste à restaurer réellement des données dans un environnement isolé, puis à vérifier leur intégrité, leur date, leurs droits et leur utilisabilité applicative. Testez plusieurs générations, y compris une copie hors ligne ou immuable, et mesurez le temps complet de reprise. La réussite d’un job de sauvegarde prouve seulement qu’une copie a été créée, pas qu’elle peut restaurer le service.
Définissez des rôles plutôt qu’une liste figée de personnes : direction de crise, opérations, informatique, sécurité, communication, juridique et relation fournisseurs. Prévoyez suppléants, canaux alternatifs, annuaire hors ligne, règles de décision et fréquence des points de situation. La cellule doit distinguer faits, hypothèses, décisions et actions. Des exercices courts permettent de tester la coordination avant une crise réelle.
Reliez chaque activité critique aux applications, interfaces, données, infrastructures, identités et fournisseurs nécessaires. Ajoutez RTO, RPO, ordre de restauration, dépendances et procédure de contournement. Cette vue empêche de restaurer une application avant son annuaire, son réseau ou son flux de données indispensable. La cartographie doit être revue à chaque changement majeur et utilisée comme entrée des scénarios de test.
À lire aussi : Cartographie applicative DSI
Ce sujet fait partie des fiches pratiques du livre Pilotegest consacré au pilotage des systèmes d’information. L’article apporte une méthode originale en texte ; la planche complète reste réservée à l’ouvrage.
Découvrir les 40 fiches dans le livrePar Équipe Pilotegest · Dernière mise à jour : 25/08/2026