Le plan de continuité commence par les dépendances métier

13 novembre 2026

Situation illustrative : un lundi matin, les serveurs de l’ERP répondent, la base est intacte et le réseau du site fonctionne. Pourtant, aucune commande ne peut être libérée. Le service d’identité hébergé ailleurs refuse les connexions, les certificats d’une interface ont expiré et le seul administrateur habilité n’accède plus à son poste de secours. Sur le tableau technique, plusieurs voyants sont verts. Pour l’entreprise, le processus est arrêté.

Cette contradiction résume une faiblesse fréquente des plans de continuité : ils protègent des composants sans démontrer que le métier peut encore vendre, produire, livrer, encaisser ou satisfaire une exigence de conformité. La première décision du DSI ou du RSSI n’est donc pas « quel serveur redémarrer ? », mais « quelle capacité métier devons-nous rétablir, avec quelles dépendances et dans quel ordre ? ».

Partir de l’impact, pas de l’inventaire technique

Un plan utile commence par quelques processus nommés en langage opérationnel : enregistrer une commande, expédier un produit, payer les salariés, publier un résultat contrôlé. Pour chacun, le responsable métier précise le niveau minimal acceptable, la durée d’interruption supportable et la perte de données tolérable. La DSI traduit ensuite ces choix en objectifs de reprise, sans les décider seule.

Le RTO indique le délai maximal visé pour reprendre ; le RPO, la perte de données admissible. Leur valeur n’a de sens qu’adossée à une situation précise. Un RTO ambitieux pour l’application principale reste fictif si l’identité, le DNS ou une interface indispensable revient plus tard. La vraie unité de continuité n’est pas l’application : c’est la capacité métier de bout en bout.

Déplier la chaîne qui rend le service possible

À partir du processus, l’équipe remonte les dépendances visibles puis invisibles. Elle examine l’application, les données et les interfaces, mais aussi le réseau, la résolution de noms, les annuaires, les clés, les certificats, les postes d’administration, les sauvegardes, les outils de supervision et les moyens de communication de crise. Elle ajoute les fournisseurs, leurs sous-traitants critiques, les compétences rares et les procédures détenues par une seule personne.

Chaque dépendance reçoit un propriétaire, une criticité, un délai de remplacement et une solution de contournement éventuelle. La cartographie doit répondre à une question testable : si cet élément disparaît, le processus peut-il continuer, être repris autrement ou doit-il s’arrêter ? Les dépendances sans réponse deviennent des décisions à instruire.

Construire des scénarios qui obligent à choisir

Tester seulement la panne d’un serveur favorise les réponses déjà maîtrisées. Les scénarios utiles coupent un maillon transversal : indisponibilité de l’identité, perte du fournisseur SaaS, corruption de données, rupture d’une liaison, impossibilité d’utiliser les postes d’administration ou absence simultanée de compétences clés.

Pour chaque scénario, le dirigeant arbitre le service minimal à préserver. Faut-il accepter une saisie différée, limiter les opérations à certains clients, suspendre une interface automatique ou revenir temporairement à une procédure manuelle ? Le mode dégradé doit préciser qui l’active, pendant combien de temps, avec quels contrôles compensatoires et comment les opérations seront réconciliées ensuite. Sans ces règles, le contournement improvise une dette de données ou une faille de sécurité.

Décider pas à pas, avec un dossier d’une page

La démarche peut rester sobre. Première étape : sélectionner les processus dont l’arrêt produit un impact inacceptable. Deuxième étape : fixer avec le métier le niveau minimal, le RTO et le RPO. Troisième étape : relier chaque processus à sa chaîne technique, humaine, contractuelle et documentaire. Quatrième étape : tester un scénario de rupture et mesurer la reprise réelle. Cinquième étape : soumettre les écarts à arbitrage, puis attribuer un responsable et une échéance.

Le dossier présenté au comité de direction tient sur une page : décision attendue, options, coût complet, délai, risques réduits, dépendances restantes et recommandation. Le langage porte sur la continuité, la conformité, la marge et le risque accepté. Refuser une redondance ou une solution de repli devient ainsi un choix explicite et traçable.

Mesurer la capacité de reprise, non la qualité du document

Le nombre de pages du plan ne mesure rien. Les indicateurs utiles suivent la part des processus critiques dotés d’un propriétaire métier, la couverture de leurs dépendances, la proportion de restaurations réellement testées, le respect du RTO et du RPO pendant les exercices, ainsi que le délai de correction des écarts. Il faut aussi surveiller les dépendances sans alternative, les contrats sans modalités de sortie vérifiées et les procédures reposant sur une seule compétence.

Un exercice réussi produit des preuves : heure de détection, décision d’activation, ordre de reprise, accès d’urgence utilisés, données restaurées, contrôles effectués et anomalies constatées. Après chaque changement majeur d’application, de fournisseur ou d’identité, la chaîne concernée doit être revue.

Éviter les faux raccourcis et rendre l’arbitrage visible

Trois erreurs reviennent. La première consiste à confondre sauvegarde et continuité : des données restaurables ne garantissent ni accès, ni interface, ni compétence pour reprendre. La deuxième consiste à acheter de la redondance sans traiter les points communs de défaillance. La troisième est de laisser la DSI promettre seule un niveau de service dont le coût et les contraintes n’ont jamais été acceptés par le métier.

L’arbitrage final oppose rarement continuité et absence de continuité. Il compare plusieurs niveaux : reprise rapide et coûteuse, service dégradé contrôlé, ou interruption assumée avec réparation prioritaire. Le DSI apporte la faisabilité et le coût ; le RSSI fixe les limites de sécurité et les contrôles compensatoires ; le métier qualifie l’impact ; la direction accepte le risque résiduel. Cette décision doit être réexaminée lorsque le processus, le fournisseur ou l’exposition change.

Le plan de continuité devient alors un instrument de gouvernance plutôt qu’un classeur d’urgence. Il montre où l’entreprise dépend d’un tiers, d’une technologie, d’une donnée ou d’une personne, et transforme cette dépendance en choix explicite. C’est avant l’incident que se gagne la reprise : lorsque chacun sait quel service protéger, quel maillon restaurer d’abord et quel risque l’organisation a réellement décidé d’assumer.