Pourquoi la haute disponibilité ne doit pas être un réflexe ?
La haute disponibilité a un coût direct en infrastructure, mais surtout un coût durable en complexité, supervision, exploitation et tests. Elle n’a de sens que si le coût d’une panne dépasse réellement ce surcoût.
Le bon sujet pour un dirigeant ou un CTO n’est donc pas “comment viser le maximum de disponibilité”, mais “quel niveau d’arrêt l’activité peut accepter, sur quel périmètre et à quel prix”.
Quand une architecture standard suffit-elle encore ?
Une architecture standard reste souvent rationnelle pour un produit jeune, un service interne, un outil à usage limité ou une activité capable d’accepter une fenêtre d’arrêt planifiée et un rétablissement non instantané.
Le sujet change quand le service porte un engagement client, une continuité opérationnelle, un flux financier, une exploitation terrain ou un coût d’indisponibilité qui dépasse largement le coût d’une architecture plus robuste.
Quels critères doivent guider l’arbitrage ?
Les critères utiles sont la criticité réelle du service, les engagements clients, la fenêtre d’arrêt acceptable, le niveau de perte de données toléré, les dépendances uniques encore présentes et la capacité de l’équipe à exploiter une architecture plus complexe.
Une architecture multi-zone ou multi-région n’apporte pas la résilience attendue si la base de données, le DNS, un fournisseur tiers, un secret critique ou la procédure de bascule restent des points uniques de défaillance.
Quels surcoûts et quelles exigences cachées faut-il anticiper ?
Le surcoût ne vient pas seulement des machines dupliquées. Il vient aussi des environnements supplémentaires, des réplications de données, des tests de bascule, de la supervision plus fine, des déploiements plus sensibles et de la discipline nécessaire pour garder la plateforme cohérente.
C’est pourquoi une architecture haute disponibilité sérieuse s’accompagne presque toujours d’un meilleur run : procédures de bascule, observabilité, revue des dépendances, sauvegardes testées et responsabilités d’exploitation plus explicites.
Quels livrables permettent une décision sérieuse ?
Les livrables utiles sont une cartographie des points uniques de défaillance, un comparatif des scénarios possibles, une hypothèse de bascule, les dépendances à traiter en priorité, les prérequis de supervision et un niveau de service cible assumé.
La meilleure sortie n’est pas toujours “faire du multi-région”. C’est parfois confirmer qu’une architecture standard reste suffisante tant qu’un autre maillon du service reste le vrai risque.
