Plan de continuité d’activité IT : méthode et composants clés

Un Plan de Continuité d’Activité IT n’est pas un document produit pour satisfaire un auditeur — c’est un dispositif opérationnel que l’organisation doit pouvoir activer sous pression, dans les minutes qui suivent un incident majeur. La différence entre un PCA qui fonctionne et un PCA qui existe sur papier tient à une seule chose : il a été testé, régulièrement, dans des conditions proches de la réalité.

Les deux métriques fondamentales : RTO et RPO

Le RTO (Recovery Time Objective) est le délai maximum acceptable entre le début d’un incident et le retour à un niveau de service défini. Le RPO (Recovery Point Objective) est la quantité maximale de données qu’il est acceptable de perdre, exprimée en durée. Ces valeurs doivent être définies par la direction métier — pas par l’IT — car elles reflètent le coût acceptable d’une interruption.

Un piège fréquent : fixer des RTO et RPO théoriquement très courts sans valider la faisabilité technique et financière. Un RTO d’une heure sur un ERP critique nécessite une réplication synchrone, un site de basculement actif et des procédures de failover automatisées — un investissement substantiel. Alignez les objectifs avec ce que vous pouvez réellement atteindre et ce que le métier peut financer.

Diagramme illustrant RTO et RPO sur une timeline d’incident — Le RTO et le RPO ne sont pas des objectifs IT : ce sont des décisions métier avec un coût d’implémentation.

Les composants techniques d’un PCA IT robuste

Un PCA IT doit couvrir : la stratégie de sauvegarde et de restauration (fréquence, rétention, externalisation, test), le site de basculement (froid, tiède ou chaud selon le RTO cible), la stratégie de réplication des données (synchrone ou asynchrone, tolérance aux pertes), le plan de gestion des annuaires et identités (Active Directory ou équivalent), les procédures de basculement réseau (DNS, BGP) et le plan de communication de crise (qui informe qui, par quel canal, dans quel ordre).

Matrice de criticité des systèmes IT par impact métier et délai de récupération — La classification des systèmes par criticité permet de prioriser les investissements de résilience.

Les tests : la seule validation qui compte

Un PCA doit être testé au minimum une fois par an sur les systèmes critiques, avec des exercices partiels trimestriels. Les tests révèlent inévitablement des écarts entre ce qui a été prévu et ce qui fonctionne réellement : documentation obsolète, dépendances non identifiées, temps de récupération réel dépassant l’objectif. Chaque écart identifié lors d’un test est infiniment plus précieux qu’une découverte lors d’une véritable crise.