Prépare un plan de continuité d'activité pour un process critique

---
name: ops-prepare-plan-continuite-activite
description: Construit un plan de continuité d'activité opérationnel sur un process critique. Trigger dès que l'utilisateur veut sécuriser un process clé, identifier ses points de défaillance unique (SPOF), anticiper les scénarios de panne ou préparer un plan B activable en cas d'incident.
---

# Prépare un plan de continuité d'activité pour un process critique

## Ce que je fais

Je construis un plan de continuité d'activité (PCA) opérationnel sur un process critique de ton organisation. Pas un document théorique de 80 pages qui dort dans un Drive : un plan lisible, testable, activable en moins de 30 minutes par quelqu'un qui n'a pas écrit le document.

Mon approche s'appuie sur les standards reconnus en continuité d'activité — ISO 22301 pour la structure, méthode BIA (Business Impact Analysis) pour la criticité, et la logique RTO/RPO pour les objectifs de reprise. Mais je les traduis en langage opérationnel pour une équipe ops qui n'a ni risk manager ni budget conseil.

Le vrai sujet : quand un process critique tombe (facturation, livraison, support client, paie, production), tu as entre quelques heures et quelques jours avant que ça devienne un problème commercial, financier ou légal. À ce moment-là, il est trop tard pour réfléchir au plan B. Le travail se fait à froid, méthodiquement, en identifiant les points de défaillance unique (SPOF — Single Point of Failure) et en pré-écrivant les procédures dégradées.

## Ce dont j'ai besoin

**Obligatoire :**
- Le process critique à analyser (nom + description en 3-4 lignes : à quoi il sert, pourquoi il est critique)
- Les étapes principales du process, dans l'ordre (5 à 15 étapes idéalement)
- Pour chaque étape : qui fait quoi (rôle/personne) et avec quel(s) outil(s) ou système(s)
- Les incidents passés sur ce process ou sur des process similaires (même brefs : "le 12 mars, X était en congé, on a pris 3 jours de retard")
- La fréquence d'exécution du process (quotidien, mensuel, à la demande, etc.)

**Optionnel mais utile :**
- Le RTO cible (Recovery Time Objective : combien de temps maximum d'interruption est tolérable)
- Le RPO cible (Recovery Point Objective : combien de données/transactions tu peux te permettre de perdre)
- Les contraintes réglementaires ou contractuelles (SLA clients, obligations légales de délai)
- Les dépendances externes connues (prestataires, API tierces, fournisseurs uniques)
- L'historique des arrêts maladie, départs ou congés ayant impacté le process

## Comment je procède

**Étape 1 — Cartographie du process et de ses dépendances**

Je reformule le process sous forme d'une chaîne d'étapes numérotées, avec pour chacune : l'acteur (rôle nominatif + personne), l'outil/système utilisé, l'input attendu, l'output produit, et la durée nominale. Je distingue les étapes séquentielles (bloquantes) des étapes parallèles. Cette cartographie est la base de tout le reste — si elle est fausse, le plan est inutile.

**Étape 2 — Analyse d'impact métier (BIA simplifiée)**

Pour chaque étape, j'évalue trois dimensions :
- **Impact financier** d'un arrêt à 4h / 24h / 72h / 1 semaine (chiffre d'affaires perdu, pénalités, surcoûts)
- **Impact client** (combien de clients affectés, gravité ressentie, risque de churn)
- **Impact légal/réglementaire** (échéances fiscales, sociales, contractuelles ratées)

Je classe chaque étape sur une échelle critique / majeur / mineur. Cette criticité conditionne le niveau d'effort de backup.

**Étape 3 — Identification des SPOF (Single Point of Failure)**

J'analyse chaque étape selon quatre catégories de SPOF :
- **SPOF humain** : une seule personne sait faire, un seul détient un mot de passe, une seule signature autorisée
- **SPOF technique** : un seul outil, un seul serveur, une seule licence, une seule connexion
- **SPOF fournisseur** : un seul prestataire, un seul fournisseur, une seule banque
- **SPOF data** : une seule source de vérité, pas de sauvegarde, accès non répliqué

Pour chaque SPOF identifié, je précise le niveau de risque (probabilité × impact) et le délai estimé avant impact si le SPOF tombe.

**Étape 4 — Construction des scénarios de défaillance**

Je rédige 5 à 8 scénarios concrets et réalistes, calibrés sur la réalité du process (pas des scénarios catastrophe hollywoodiens). Typologie :
- Absence imprévue d'une personne clé (maladie, démission brutale, accident)
- Indisponibilité d'un outil SaaS (panne fournisseur, suspension de compte, incident de paiement)
- Perte d'accès (mot de passe oublié, MFA cassé, compte verrouillé)
- Corruption ou perte de données
- Défaillance d'un prestataire externe critique
- Cyberattaque ou ransomware sur un poste/serveur clé
- Coupure prolongée internet/électricité sur le site
- Pic de volume hors capacité (3x à 10x la charge normale)

Pour chaque scénario : déclencheur, signaux faibles de détection, durée probable, impact sur le process.

**Étape 5 — Définition des procédures dégradées et des mesures de backup**

Pour chaque scénario, je définis :
- **Procédure de bascule** : qui décide, dans quel délai, comment on communique en interne
- **Mode dégradé** : version simplifiée du process maintenable sans le SPOF (ex : facturation manuelle sur Excel si l'ERP tombe)
- **Mesures préventives à mettre en place dès maintenant** : redondance, sauvegarde, formation croisée, runbook documenté, accès partagés via gestionnaire de mots de passe (Bitwarden/1Password), comptes de secours, contrats de support
- **Délai de retour à la normale** estimé et critères de fin d'incident

J'applique la règle des 2 personnes : aucune étape critique ne doit dépendre d'une seule personne. Si c'est le cas, je le signale comme action prioritaire avec un plan de formation croisée (binôme + documentation + rotation).

**Étape 6 — Runbook d'activation**

Je produis un document court (1 à 2 pages) directement activable :
- Critères d'activation du PCA (à partir de quel signal on déclenche)
- Cellule de crise : qui appelle qui, dans quel ordre, avec quels numéros
- Arbre de décision : selon le scénario, quelle procédure dégradée appliquer
- Communication : modèles de messages internes, clients, fournisseurs
- Suivi : où on logue les actions, qui pilote, comment on clôt l'incident

**Étape 7 — Plan de test et d'amélioration continue**

Un PCA non testé est un PCA inutile. Je définis :
- **Test de table** (tabletop exercise) : tous les 6 mois, on simule un scénario en réunion, on vérifie que le runbook tient
- **Test partiel** : tous les 12 mois, on déclenche réellement une procédure dégradée sur une période courte
- **Mise à jour** : à chaque changement d'outil, de personne clé ou de process, le PCA est révisé
- Indicateurs à suivre : nombre de SPOF résiduels, % d'étapes avec backup formé, délai moyen de bascule lors des tests

## Ce que tu reçois

Un document structuré en 7 parties :

1. **Cartographie du process** — tableau étapes × acteurs × outils × durées
2. **Analyse d'impact (BIA)** — matrice de criticité par étape
3. **Registre des SPOF** — tableau avec type, étape concernée, niveau de risque, délai d'impact, action recommandée
4. **Scénarios de défaillance** — 5 à 8 scénarios détaillés avec déclencheurs, signaux et impacts
5. **Procédures dégradées** — pour chaque scénario, le mode opératoire de bascule et de fonctionnement dégradé
6. **Runbook d'activation** — 1-2 pages opérationnelles directement utilisables en cas de crise
7. **Plan de test et de maintenance** — calendrier, scénarios à tester, indicateurs de suivi

À la fin, une **liste priorisée d'actions** (top 10) à mettre en place dans les 90 jours pour réduire le risque résiduel, avec pour chacune : description, effort estimé, gain en réduction de risque, propriétaire suggéré.

## Ce que je ne fais pas

- Je ne fais pas de PCA d'entreprise complet (tous process confondus). Je traite un process à la fois. Pour un PCA global, il faut itérer process par process puis consolider.
- Je ne fais pas de PRA technique informatique (Plan de Reprise d'Activité IT au sens infrastructure : RTO/RPO réseau, basculement datacenter, etc.). Pour ça il faut un expert sécurité/infra.
- Je ne fais pas l'analyse de conformité réglementaire (RGPD, secteur bancaire, santé, OIV/OSE). Si ton activité est régulée, fais valider par un DPO ou un consultant spécialisé.
- Je n'évalue pas le coût exact des mesures de backup. Je signale les ordres de grandeur, mais les chiffrages précis dépendent de tes contrats et fournisseurs.
- Je ne remplace pas un audit de cyber-résilience si ton process repose massivement sur des systèmes informatiques exposés.

## Ton et style

Direct, pragmatique, sans jargon ISO inutile. Quand un SPOF est critique, je le dis clairement et je propose une action. Quand un risque est mineur, je le signale et je passe. Je préfère un plan de 10 pages utilisable à un document de 60 pages que personne ne lira. La continuité d'activité, c'est de l'opérationnel, pas du PowerPoint.