1. INTERVENANTS

DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨

2. PROBLÉMATIQUE

Tu peux avoir une infra bien répliquée,
des runbooks testés jusqu’à l’usure,
et des scripts de bascule qui tournent comme une horloge…

Mais si, au moment critique :
• Personne ne sait quelles équipes doivent être relancées en priorité
• Aucune app n’est marquée comme vitale,
• Et on se demande qui donne le go pour la cellule de crise…

👉 Alors, tu n’as pas un PRA. Tu as juste une checklist technique

Un PRA, ce n’est pas seulement de l’infra, des scripts ou des backups. C’est d’abord du business : savoir ce qui compte vraiment, ce qui coûte cher à l’arrêt, et comment redémarrer vite quand ça plante. Dans le cloud, Azure assure le matos, mais c’est à toi de bâtir une archi qui protège tes apps critiques.

Et attention : une panne, c’est rarement tout qui s’écroule. Souvent, c’est un service ou une zone qui lâche

Ça commence dans un atelier, avec les métiers
autour d’un tableau blanc, à poser les bonnes questions :

  • Qui impacte quoi ?
  • Quel service coûte combien à l’arrêt ?
  • Et qu’est-ce qu’on fait, dans quel ordre, quand tout plante ?

🎯 Ce deuxième article de la série PRA/PCA IaaS aborde les 50 % qu’on ne code pas :

  • les arbitrages métier, les priorités d’accès, les scénarios réels
  • et la coordination humaine qu’aucun script ne remplace

3. IDENTIFIER LES RÔLES CRITIQUES

Tu veux prioriser les bons accès le jour J ?
Commence par comprendre qui fait quoi

Un PRA efficace, ce n’est pas “tout rétablir le plus rapidement possible”
C’est redonner la main rapidement aux fonctions qui portent ton service métier.

Ta mission ici : cartographier les rôles qui :

  • déclenchent des impacts financiers ou juridiques en cas de coupure prolongée
  • gèrent la relation client ou la production en temps réel
  • ont besoin d’un accès immédiat à l’application, même en mode dégradé

Exemples concrets :

  • Dans une appli RH : l’équipe paie → ⚠️ délai légal
  • Sur une plateforme logistique : l’équipe d’expédition → 💸 retards de livraison
  • Dans un call center : l’outil de ticketing → 🔥 impact direct client
💡 Optimisation possible :
Ne fais pas tout à la main. Utilise une CMDB (comme ServiceNow), une base Confluence, ou interconnecte les métadonnées de ton Cloud (tags Azure, labels Kubernetes…) pour documenter automatiquement les dépendances critiques.

Schéma de criticité des apps :

4. TRAVAILLER AVEC LES MÉTIERS

Une bonne approche PRA, c’est collaboratif.
Il faut réunir les équipes techniques et les représentants métier pour :

  • Identifier les dépendances critiques (base, proxy, ESB, stockage partagé…)
  • Valider les priorités : qui doit revenir en premier, et pourquoi ?
  • Recenser les contraintes d’accès (VPN, badge, IP filtrée, MFA…)
⚠️ Attention aux dépendances cloud :
Une panne d’Azure Blob Storage peut bloquer une app si un service en dépend. Mappe ces liens dans tes ateliers IT/métiers

Crée un fichier de travail partagé qui liste pour chaque application:

  • Rôle ou service utilisateur
  • Impact métier
  • RTO cible
  • Risques connus / limitations
  • Actions à enclencher / contacts

➡️ Ce fichier devient ton référentiel de priorisation , centralisée (Confluence, Azure DevOps Wiki), validée par IT et métiers, pour guider tous tes scénarios

💡 Optimisation possible :
Automatise le lien entre tes ressources cloud et les rôles métier via des outils comme Confluence ou une CMDB dynamique.
Tu peux même enrichir chaque ligne avec les tags Azure (‘criticité=platine’, ‘RTO=2h’) directement liés aux services concernés.

5. PAS DE REPRISE SANS PRIORITÉ CLAIRE

Quand la reprise s’enclenche, tout ne revient pas en même temps.
Les accès critiques doivent être disponibles dans les premières minutes

🔥 C’est là que se joue la différence entre un PRA théorique… et un vrai plan opérationnel.

Objectif :

👉 établir un plan de reprise lisible, priorisé, validé par les métiers ET par l’IT.

Trois leviers à croiser :

  • Les rôles critiques → Ceux qui déclenchent un impact si on ne les relance pas vite
  • Les accès vitaux → Applis, bases, VPN, qui doivent revenir avant tout
  • Les ressources techniques → Ce qu’il faut restaurer, ouvrir ou sécuriser pour que ça reparte

Choisis ton niveau de résilience

  • HA locale : Redondance dans une zone (cluster AKS) pour les apps Silver
  • Multi-AZ : Actif/actif sur plusieurs zones (VM en Availability Set) pour Gold
  • Multirégion : Réplication géo pour Platine/Diamant.

Adapte au RTO et au budget

Mode dégradé, ton joker

Si le SIRH tombe, bascule sur un fichier CSV. Tester ces plans B en simulation

Exemple de grille de priorisation :

6. GÉRER LA CRISE HORS CONNEXION

Tu peux avoir Teams, une cellule de crise bien rôdée, et un plan de conf call par service…

Mais si la connectivité tombe, et que tout s’écroule ?
Tu te retrouves à chercher un numéro sur SharePoint… inaccessible

✅ Prévois des canaux de secours :

  • Messageries alternatives : Signal, WhatsApp, SMS natif
  • Moyens physiques : Talkies-walkies pour les équipes on-prem
  • Plan B : contacts critiques stockés hors ligne dans un PDF crypté sur clé USB ou laptop local

Et surtout, constitue un kit de crise hors ligne :

  • 🟢 Runbook et Playbook PRA en version PDF (chiffré)
  • 🟢 Contacts critiques imprimés ou exportés avec un QR code local
  • 🟢 Procédures papier pour les scénarios majeurs
  • 🟢 Fiches réflexes pour activer rapidement les bonnes personnes

Ce kit doit être stocké dans un endroit sûr… mais connu de tous les acteurs clés

🎯 Objectif : garantir la coordination, même en mode totalement déconnecté.

7. FORMALISER LES RESPONSABILITÉS ET LES RUNBOOKS

Un bon PRA
C’est une équipe prête, qui sait :

  • 🟢 quoi faire
  • 🟢 quand le faire
  • 🟢 et surtout qui le fait

Et ça, ça ne s’improvise pas le jour J

Ce qu’il faut cadrer clairement :

Bonnes pratiques terrain :

  • Liste des contacts / noms / numéros
  • Support partagé : OneNote, Git markdown, SharePoint
  • MAJ après chaque changement de rôle ou périmètre

8. ANTICIPER ET COORDONNER LES CRISES

Une crise n’est jamais prévisible, mais elle doit être gérée avec rapidité et précision. Un PRA efficace anticipe les scénarios, structure la réponse et forme les équipes à réagir sous pression.

Voici comment préparer et coordonner une crise.

Scénarios de crise

Chaque scénario doit être documenté avec des déclencheurs, impacts et actions.

Voici les principaux cas à anticiper :

Pour chaque scénario :

  • Mobiliser : Définir qui décide (DSI, Sécurité) et qui agit (Ops, Communication).
  • Coordonner : Utiliser des canaux fiables (voir kit de crise hors ligne, section 7).
  • Sortir : Valider la reprise avec des tests métiers.

Coordination en cellule de crise

La cellule de crise repose sur des rôles clairs et une communication fluide.

Posez-vous ces questions :

  • Qui déclenche la crise ? (Ex. : DSI sur alerte Azure.)
  • Qui décide du bascule ? (Ex. : Comité de crise.)
  • Qui valide le retour à la normale ? (Ex. : Référent métier.)
  • Qui informe les parties prenantes ? (Ex. : Communication.)

Fiche de coordination :

Bonnes pratiques :

  • Documenter les escalades (N1 → N2 → N3).
  • Créer un trombinoscope PRA (noms, photos, contacts) dans le kit de crise hors ligne.
  • Stocker fiches et contacts dans un PDF crypté (voir section 7).

Simulations et amélioration continue

Un PRA se muscle par la pratique. Organisez :

  • Simulations annuelles : Testez un scénario complet (ex. : panne Azure) avec IT et métiers.
  • Mini-scénarios trimestriels : 1h de jeu de rôle avec un scénario surprise (ex. : ransomware).
  • Tests expérimentaux : Simulez des pannes dans un bac à sable via Azure Chaos Studio.
🧪 Analyse post-simulation :
– Dans ton post-mortem, note les écarts (ex. : RTO dépassé, canal HS)
– Identifie les actions correctives (ex. : MAJ runbook, nouveau canal)

Boucle d’amélioration (PDCA) :

  1. Plan : Définir rôles, priorités, scénarios.
  2. Do : Simuler ou gérer un incident.
  3. Check : Analyser post-mortem (succès, échecs, actions ?).
  4. Act : Mettre à jour runbooks et playbook.

Optimisation terrain : Intégrez des canaux de secours (Signal, SMS, talkies-walkies) et testez-les lors des simulations. Ex. : Simulez une crise sans Teams pour vérifier le kit hors ligne.

PROCHAIN ARTICLE

Ton PRA est prêt ? Passe à l’action !
Azure Site Recovery (ASR) te permet de répliquer, basculer et reprotéger tes VMs avec une précision chirurgicale.

🔥 Pourquoi ASR ?
• Réplication continue : tes apps critiques (paie, CRM) restent synchronisées.
• Failover rapide : respecte tes RTO en cas de panne.
• Reprotection fluide : reprend le contrôle sans chaos.

💡 Comment faire ? Avec des scripts PowerShell pour :
• Configurer la réplication (ex. : VM multi-AZ).
• Exécuter un failover (ex. : panne Azure).
• Reprotéger tes ressources.

👉 À suivre : scripts éprouvés, bonnes pratiques, et pièges à éviter.
On met les mains dans le code !