Atelier : tester une bascule sur table
Conduire un exercice de bascule sur table (tabletop) pour valider un runbook sans mettre la production en risque.
À retenir
- Le tabletop valide la logique et les rôles avant tout test technique risqué en production.
- Un animateur neutre injecte des aléas pour tester la résilience réelle du processus.
- Un exercice sans liste d'actions correctives n'a rien testé de rigoureux.
- Le compte-rendu structuré alimente directement la mise à jour du runbook.
Pourquoi tester sur table avant de tester en réel
Un test de bascule en production réelle comporte un risque intrinsèque : si le runbook est défaillant, l'exercice devient lui-même l'incident. Le tabletop permet de valider la logique, les rôles et les critères de décision avant tout test technique impactant.
Préparer l'atelier
| Élément | Détail |
|---|---|
| Scénario | Panne réaliste et documentée (ex. perte du site primaire suite à coupure électrique prolongée) |
| Participants | Astreinte technique, responsable exploitation, communication, un observateur neutre |
| Matériel | Runbook imprimé ou affiché, chronomètre, main courante |
| Durée | 60 à 90 minutes incluant le débriefing |
| Animateur | Une personne qui ne joue pas de rôle opérationnel, garante du rythme et du réalisme |
Point clé
l'animateur injecte des événements imprévus (ex. « le responsable astreinte ne répond pas ») pour tester la résilience du processus, pas seulement son déroulement nominal.
Déroulé d'un exercice type
- Annonce du scénario sans préavis aux participants.
- Chronologie imposée par l'animateur : chaque décision est chronométrée et consignée.
- Les participants suivent le runbook réel, étape par étape, en verbalisant leurs actions.
- L'animateur injecte un aléa au tiers du scénario (ex. données de réplication incohérentes).
- Debrief immédiat : écarts entre le runbook et l'exécution réelle, points de blocage, délais réels vs cibles.
Sur le terrain
dans un exercice mené sur un site ouest-africain, l'équipe a découvert en tabletop que le contact du prestataire de secours électrique n'était plus à jour depuis un an — une faille invisible en revue documentaire mais immédiatement détectée dès la première simulation d'appel.
Critères de réussite mesurables
- Temps de décision de bascule inférieur au seuil défini dans le runbook.
- Toutes les étapes critiques exécutées dans l'ordre, sans improvisation non documentée.
- Communication envoyée aux parties prenantes dans le délai contractuel.
- Aucune ambiguïté de rôle constatée (deux personnes pensant être décisionnaires, ou personne ne l'étant).
Attention
un exercice jugé « réussi » simplement parce qu'il s'est terminé sans blocage majeur passe à côté de l'objectif : chaque tabletop doit produire une liste d'actions correctives, sinon il n'a rien testé de rigoureux.
Modèle de compte-rendu
Un compte-rendu d'exercice doit contenir : date, scénario, participants, chronologie réelle vs cible, écarts constatés, actions correctives avec responsable et échéance, date du prochain test. Ce document alimente directement la révision du runbook.
Astuce
planifiez le prochain tabletop avant même de clore le débriefing du précédent — cela évite que les actions correctives ne soient jamais vérifiées faute d'échéance de test suivant.