PCA/PRA et cartographie SI : construire la résilience de votre ETI

Le 19 juillet 2024, une mise à jour défectueuse de CrowdStrike a paralysé 8,5 millions de machines Windows dans le monde entier. Des aéroports fermés, des hôpitaux en mode dégradé, des entreprises à l'arrêt complet pendant des heures, voire des jours. Le coût estimé : plus de 5 milliards de dollars. Cet incident n'était pourtant ni une cyberattaque, ni une catastrophe naturelle. Juste une mise à jour logicielle qui a mal tourné.

Si un tel événement peut mettre à genoux des organisations disposant d'équipes IT de plusieurs centaines de personnes, imaginez l'impact sur une ETI de 200 ou 500 collaborateurs. La question n'est pas si un incident majeur frappera votre système d'information, mais quand. Et la différence entre une entreprise qui survit et une qui sombre tient en deux acronymes : PCA et PRA.

PCA et PRA : de quoi parle-t-on exactement ?

Le Plan de Continuité d'Activité (PCA)

Le PCA est un dispositif global qui définit comment votre entreprise continue de fonctionner pendant et après un sinistre. Il ne se limite pas à l'informatique : il couvre l'ensemble des activités critiques, y compris les aspects humains, logistiques et organisationnels.

Le PCA répond à la question : "Comment maintenir nos activités essentielles même en mode dégradé ?"

Exemples concrets pour une ETI :

Si le siège est inaccessible (incendie, inondation), où et comment les équipes travaillent-elles ?
Si le système de commande est hors service, comment continue-t-on à enregistrer et traiter les commandes ?
Si un fournisseur critique fait défaut, quelle est l'alternative ?

Le Plan de Reprise d'Activité (PRA)

Le PRA est le volet informatique du PCA. Il définit les procédures techniques pour restaurer le système d'information après un incident majeur. C'est le mode d'emploi pour "rallumer les machines" dans le bon ordre et dans les bons délais.

Le PRA répond à la question : "Comment rétablir nos systèmes informatiques le plus rapidement possible ?"

Le PRA se concentre sur deux métriques fondamentales :

RPO (Recovery Point Objective) : la quantité maximale de données que vous acceptez de perdre. Un RPO de 4 heures signifie que vous devez sauvegarder au minimum toutes les 4 heures.
RTO (Recovery Time Objective) : le temps maximal acceptable pour remettre un système en service. Un RTO de 2 heures pour votre ERP signifie que vous devez être capable de le relancer en moins de 2 heures après un incident.

La relation entre PCA et PRA

Le PRA est un sous-ensemble du PCA. Vous pouvez avoir un PCA sans PRA (continuité des activités non informatiques), mais en pratique, dans une ETI moderne où quasiment tous les processus dépendent du SI, le PRA est le pilier technique du PCA.

Pourquoi les ETI sont particulièrement vulnérables

Les grandes entreprises disposent d'équipes dédiées à la continuité d'activité, de datacenters redondants et de budgets conséquents. Les très petites entreprises ont peu de dépendances IT complexes. Les ETI, elles, se trouvent dans une zone de vulnérabilité maximale :

Dépendance IT élevée : comme les grands groupes, les ETI ont numérisé la quasi-totalité de leurs processus. ERP, CRM, outils de production, logistique : tout passe par le SI. Le Shadow IT amplifie encore cette complexité.
Ressources limitées : contrairement aux grands groupes, les ETI disposent rarement d'une équipe sécurité dédiée, d'un SOC (Security Operations Center) ou d'un responsable continuité d'activité à temps plein.
Complexité croissante : avec la multiplication des outils SaaS, des API et des interconnexions, le SI d'une ETI peut être aussi complexe que celui d'un grand groupe, mais sans la même capacité de gouvernance.
Impact business concentré : une ETI a souvent moins de clients mais des contrats plus importants. La perte d'un client majeur suite à une indisponibilité prolongée peut être fatale.

Selon une étude du CESIN, 54 % des entreprises françaises ont subi au moins une cyberattaque réussie en 2023. Et parmi celles qui subissent un sinistre majeur sans PCA/PRA, 40 % ne survivent pas au-delà de deux ans.

La cartographie SI : fondation indispensable du PCA/PRA

Voici le constat que font toutes les ETI qui tentent de construire un PCA/PRA : il est impossible de protéger ce que l'on ne connaît pas. Et c'est là que la cartographie du système d'information devient le prérequis incontournable.

Pourquoi la cartographie est la première étape

Sans cartographie complète de votre SI, votre PCA/PRA repose sur des hypothèses et des approximations :

Vous pensez connaître vos applications critiques, mais en avez-vous la liste exhaustive ?
Vous savez que votre ERP est important, mais connaissez-vous toutes les applications qui en dépendent ?
Vous avez des sauvegardes, mais couvrent-elles l'intégralité de vos données stratégiques ?
Vous avez un contrat d'hébergement, mais savez-vous précisément quelles applications tournent sur chaque serveur ?

La cartographie SI transforme ces approximations en certitudes documentées.

Les quatre dimensions à cartographier

Pour construire un PCA/PRA robuste, votre cartographie doit couvrir quatre dimensions :

1. L'inventaire applicatif complet

Listez l'ensemble des applications utilisées dans votre organisation, en documentant pour chacune :

Son nom, son éditeur, sa version.
Son rôle fonctionnel (quel processus métier elle supporte).
Ses utilisateurs (quels départements, combien de personnes).
Son modèle d'hébergement (on-premise, IaaS, SaaS).
Son propriétaire métier (qui décide de son évolution) et son responsable technique (qui la maintient).

2. La cartographie des dépendances

C'est la dimension la plus critique et la plus souvent négligée. Les dépendances entre applications déterminent l'ordre de redémarrage en cas de sinistre et les effets de cascade d'une panne.

Types de dépendances à documenter :

Dépendances applicatives : l'application A appelle l'API de l'application B. Si B est hors service, A fonctionne-t-elle en mode dégradé ou est-elle totalement bloquée ?
Dépendances de données : l'application C lit des données produites par l'application D. Que se passe-t-il si ces données sont corrompues ou indisponibles ?
Dépendances d'infrastructure : cinq applications tournent sur le même serveur. Si ce serveur tombe, les cinq sont impactées simultanément.
Dépendances humaines : seule une personne connaît le mot de passe admin de cette application critique. Que se passe-t-il si elle est indisponible ?

3. La classification par criticité

Toutes les applications n'ont pas la même importance. Classez-les selon une échelle de criticité :

Critique (Tier 1) : l'arrêt de cette application bloque immédiatement les activités génératrices de revenus. Exemples : ERP, système de commande en ligne, outil de production. RTO cible : moins de 4 heures.
Important (Tier 2) : l'arrêt dégrade significativement les opérations mais ne bloque pas la génération de revenus. Exemples : CRM, messagerie, outil de gestion de projet. RTO cible : moins de 24 heures.
Standard (Tier 3) : l'arrêt est gênant mais supportable pendant plusieurs jours. Exemples : intranet, outil de veille, application de notes de frais. RTO cible : moins de 72 heures.
Non critique (Tier 4) : l'arrêt n'a pas d'impact opérationnel significatif. Exemples : outil de sondage interne, application de réservation de salles. Pas de RTO formel.

4. La cartographie des flux de données

Documentez les flux de données entre applications pour identifier :

Quelles données transitent entre quels systèmes.
Par quels canaux (API, fichiers, base de données partagée, transfert manuel).
À quelle fréquence (temps réel, batch horaire, quotidien).
Quel est le volume (pour dimensionner les sauvegardes et les bandes passantes de secours).

Construire votre PCA/PRA : méthodologie en 6 étapes

Etape 1 : Analyser les risques (BIA - Business Impact Analysis)

Le BIA est l'exercice fondateur. Pour chaque processus métier identifié dans votre cartographie, évaluez :

L'impact financier d'une interruption (perte de chiffre d'affaires, pénalités contractuelles, coûts de remise en route).
L'impact réputationnel (perte de confiance des clients, couverture médiatique négative).
L'impact réglementaire (sanctions, mise en demeure, retrait d'agrément).
L'impact humain (sécurité des personnes, conditions de travail dégradées).

Pour chaque processus, définissez le DMIA (Durée Maximale d'Interruption Admissible) : combien de temps pouvez-vous survivre sans ce processus ?

Etape 2 : Définir la stratégie de continuité

En fonction des résultats du BIA, choisissez la stratégie adaptée pour chaque niveau de criticité :

Site de secours actif-actif : pour les applications Tier 1 critiques. Deux instances tournent simultanément, la bascule est transparente. Coût élevé mais indisponibilité quasi nulle.
Site de secours actif-passif : une instance de secours est prête à démarrer mais ne traite pas de trafic en temps normal. Bascule en quelques minutes à quelques heures.
Sauvegarde et restauration : pour les applications Tier 2 et 3. Les données sont sauvegardées régulièrement et restaurées sur une nouvelle infrastructure en cas de sinistre. RTO de plusieurs heures à plusieurs jours.
Mode dégradé manuel : pour les processus qui peuvent temporairement fonctionner sans informatique (prise de commande sur papier, communication par téléphone).

Etape 3 : Documenter les procédures de reprise

Pour chaque application critique, rédigez une fiche de reprise qui détaille :

Les prérequis techniques (infrastructure, réseau, dépendances).
L'ordre de redémarrage (quelles applications démarrer en premier, en tenant compte des dépendances cartographiées).
Les vérifications post-démarrage (tests fonctionnels pour confirmer que l'application fonctionne correctement).
Les contacts d'urgence (éditeur, hébergeur, prestataire de maintenance).
Les procédures de bascule vers le site de secours.

L'ordre de redémarrage est directement issu de votre cartographie des dépendances. Sans cette cartographie, vous risquez de relancer des applications qui dépendent de services pas encore disponibles, créant des erreurs en cascade.

Etape 4 : Mettre en place les dispositifs techniques

Implémentez les solutions techniques qui supportent votre stratégie :

Sauvegardes : vérifiez que vos sauvegardes couvrent l'intégralité des données critiques identifiées dans la cartographie. Appliquez la règle 3-2-1 : 3 copies, sur 2 supports différents, dont 1 hors site.
Réplication : pour les applications Tier 1, mettez en place une réplication en temps réel vers un site de secours géographiquement distant.
Monitoring : déployez des outils de supervision qui détectent les pannes avant qu'elles ne deviennent critiques.
Documentation technique : maintenez à jour les schémas d'infrastructure, les configurations réseau et les procédures d'accès.

Etape 5 : Tester, tester, tester

Un PCA/PRA qui n'a jamais été testé est un document de fiction. Planifiez des tests réguliers :

Tests unitaires (trimestriels) : restauration d'une sauvegarde, bascule d'un service isolé, test des procédures de notification.
Tests d'intégration (semestriels) : redémarrage d'une chaîne applicative complète (en tenant compte des dépendances) sur le site de secours.
Exercice de crise complet (annuel) : simulation d'un sinistre majeur avec activation du PCA, mobilisation des équipes et mesure des temps réels de reprise.

Après chaque test, documentez les écarts constatés entre les objectifs (RTO/RPO) et la réalité, et mettez à jour vos procédures en conséquence.

Etape 6 : Maintenir et faire vivre le dispositif

Le PCA/PRA est un document vivant qui doit évoluer avec votre SI. À chaque changement significatif (nouvelle application, migration cloud, changement de prestataire, réorganisation), mettez à jour :

La cartographie des applications et des dépendances.
La classification par criticité.
Les fiches de reprise concernées.
Les procédures de test.

C'est ici que la cartographie SI en tant qu'outil vivant et collaboratif prend tout son sens. Si votre cartographie est un fichier Visio stocké sur le poste du DSI et mis à jour une fois par an, votre PCA/PRA sera obsolète en quelques mois. Découvrez les alternatives à Excel et Visio pour maintenir une cartographie vivante.

Les erreurs fatales à éviter

1. Sous-estimer les dépendances

L'erreur la plus fréquente. Vous redémarrez votre ERP, mais il dépend d'un service d'authentification SSO qui n'a pas été relancé. Résultat : personne ne peut se connecter. Seule une cartographie exhaustive des dépendances prévient ce scénario.

2. Oublier les facteurs humains

Votre PRA est parfait sur le papier, mais la seule personne qui connaît la procédure de restauration de la base de données est en vacances à l'étranger. Prévoyez des binômes de compétences pour chaque procédure critique et documentez les connaissances tacites.

3. Ne jamais tester

Selon une étude Zerto, 23 % des entreprises n'ont jamais testé leur PRA. C'est comme avoir un extincteur dont on n'a jamais vérifié qu'il fonctionne.

4. Ignorer les fournisseurs SaaS

Votre PRA couvre vos serveurs internes, mais qu'en est-il de Salesforce, Microsoft 365 ou votre outil de comptabilité en ligne ? Vérifiez les SLA de vos fournisseurs et intégrez leurs engagements (ou leurs limites) dans votre PCA.

5. Confondre sauvegarde et PRA

Avoir des sauvegardes est nécessaire mais pas suffisant. Le PRA inclut les sauvegardes, mais aussi la procédure de restauration, l'infrastructure de secours, l'ordre de redémarrage et la communication de crise.

Conformité réglementaire : PCA/PRA et obligations légales

Plusieurs réglementations imposent désormais aux ETI de disposer de plans de continuité formalisés :

[NIS2](/fr/blog/nis2-pme-eti-cartographie-si-conformite) : les ETI de secteurs essentiels ou importants doivent mettre en place des mesures de gestion des risques cyber, incluant la continuité d'activité.
[DORA](/fr/blog/dora-cartographie-si-secteur-financier-2026) : pour le secteur financier, des exigences spécifiques de résilience opérationnelle numérique avec des tests obligatoires.
RGPD : l'article 32 impose d'assurer "la disponibilité et la résilience constantes des systèmes de traitement".
Code du commerce : les obligations de conservation des documents comptables imposent des sauvegardes fiables et restaurables.

La cartographie SI est un élément de preuve de votre démarche de conformité. Elle démontre aux auditeurs et aux régulateurs que vous maîtrisez votre périmètre informatique et que vos plans de continuité reposent sur une connaissance factuelle de votre SI. Pour aller plus loin sur le volet cybersécurité et cartographie SI, consultez notre guide dédié aux RSSI.

Construisez votre résilience avec UrbaHive

La construction d'un PCA/PRA robuste commence par une connaissance exhaustive et à jour de votre système d'information. Sans cette fondation, vos plans de continuité restent des documents théoriques déconnectés de la réalité opérationnelle.

UrbaHive vous fournit cette fondation en vous permettant de :

Cartographier l'ensemble de votre portefeuille applicatif avec les métadonnées essentielles (criticité, propriétaire, hébergement, données traitées).
Visualiser les dépendances entre applications pour définir l'ordre de redémarrage optimal et identifier les points de défaillance unique.
Classifier vos applications par niveau de criticité et associer à chaque niveau les objectifs RTO/RPO appropriés.
Maintenir votre cartographie vivante grâce à une collaboration en temps réel entre les équipes IT et les métiers.
Exporter vos données architecturales au format standard pour alimenter vos documents de PCA/PRA.

Ne attendez pas le prochain incident pour découvrir les failles de votre résilience. Essayez UrbaHive et posez la première pierre de votre stratégie de continuité d'activité.