PRA et HA: ce que les tests réels révèlent, pas les slides

Dans beaucoup d'organisations, PRA et HA sont traités comme des synonymes. En production, ce n'est pas vrai. Une HA locale correcte peut coexister avec un PRA fragile.

Sur un dossier SaaS B2B, tout semblait "sous contrôle": cluster stable, supervision propre, documentation validée. Le premier exercice de bascule complet a raconté une autre histoire.

Ce qui a coincé

Pas de panne spectaculaire. Une série de petits écarts, cumulés:

• dépendance DNS sous-estimée dans la séquence de reprise,
• validation applicative arrivée trop tard,
• rôles d'escalade connus en théorie, flous dans le rythme réel,
• runbook détaillé mais peu actionnable sous pression.

C'est le point que j'insiste souvent en atelier: un runbook long n'est pas un runbook robuste.

RTO déclaré vs RTO mesuré

Le RTO cible était ambitieux et crédible sur le papier. En test réel, la reprise complète a pris presque trois fois plus de temps.

Pourquoi?

• la plateforme redémarrait vite,
• les services dépendants, eux, redémarraient dans un ordre différent de celui prévu,
• la validation métier rallongeait la fenêtre de décision.

Autrement dit: l'infrastructure n'était pas le goulet principal. La chaîne de dépendances l'était.

Le sujet organisationnel derrière le sujet technique

Quand un PRA est rarement exercé, la qualité de coordination se dégrade avant la qualité technique.

On le voit dans les incidents:

• décisions retardées faute d'autorité claire,
• arbitrages contradictoires entre infra et applicatif,
• fatigue opérationnelle qui pousse à "tenir" au lieu de rollbacker proprement.

Ce n'est pas un problème d'outillage uniquement. C'est un problème de gouvernance opérationnelle.

Ce qui a vraiment amélioré la résilience

Pas une refonte complète. Des ajustements ciblés.

• Scénarios de test non nominaux, trimestriels, avec compte-rendu mesuré.
• Runbooks raccourcis et orientés action.
• Critères de rollback explicites et acceptés en amont.
• Validation applicative intégrée tôt dans la séquence, pas à la fin.

On a aussi ajouté une règle simple: si la situation est ambiguë au-delà d'une timebox fixée, on exécute le plan de retour. Pas de débat prolongé en salle de crise.

Un point qui dérange parfois

Certaines équipes préfèrent éviter les tests complets pour ne pas "prendre de risque". En réalité, elles déplacent le risque vers le premier incident réel.

Le test ne crée pas la fragilité. Il la révèle.

Position

Un PRA mature n'est pas un PDF bien tenu. C'est une capacité répétable, sous contrainte, avec une équipe imparfaite et un contexte imparfait.

Si ce niveau n'est pas atteint, il vaut mieux ralentir certains chantiers de migration. C'est moins élégant en comité, mais beaucoup plus responsable en production.