Que se passe-t-il chez vous quand AWS tombe ? Le test en 4 questions
Si un hyperscaler tombe demain matin, la seule vraie question est : que se passe-t-il chez vous, concrètement, dans l'heure qui suit ? 55 % des organisations subissent déjà des perturbations hebdomadaires, mais seules 20 % se disent pleinement préparées aux pannes. Quatre questions suffisent à savoir dans quel camp vous êtes.
La panne n'est plus une hypothèse, c'est une condition d'exploitation
L'enquête menée par Cockroach Labs auprès de 1 000 dirigeants tech, relayée notamment par TechTarget et Bacancy, pose deux chiffres : 55 % des organisations subissent des perturbations au moins hebdomadaires, et 20 % seulement s'estiment pleinement préparées aux pannes.
Autrement dit, l'indisponibilité est devenue une condition normale d'exploitation, pas un événement exceptionnel. Les crédits de SLA d'un fournisseur cloud remboursent quelques pourcents de facture ; ils ne remboursent ni les ventes perdues, ni les pénalités contractuelles, ni la confiance des clients. Et pour une organisation installée à Maurice, la dépendance à des régions cloud distantes ajoute une couche supplémentaire : la connectivité elle-même repose sur une poignée de câbles sous-marins.
Ce constat rejoint un principe que les contrats cloud énoncent depuis toujours, mais que peu d'organisations ont tiré jusqu'au bout : le fournisseur est responsable de la disponibilité de sa plateforme, pas de celle de votre service. La redondance de vos applications, la réplication de vos données et le chemin de bascule restent à votre charge. C'est exactement ce que la plupart des architectures « cloud par défaut » n'ont jamais formalisé — et ce que les quatre questions suivantes mettent au jour.
Le test en 4 questions
1. Savez-vous exactement ce qui dépend du cloud public ?
La panne révèle toujours des dépendances que personne n'avait cartographiées : l'application principale, bien sûr, mais aussi l'authentification (SSO), le DNS, l'envoi d'e-mails, les paiements, et les SaaS métier qui tournent eux-mêmes chez le même hyperscaler. Bon signe : un inventaire à jour listant, pour chaque service critique, le fournisseur, la région et les dépendances indirectes. Signal d'alerte : « il faudrait demander à chaque équipe ».
2. Votre RTO est-il mesuré, ou espéré ?
Le RTO (durée maximale d'interruption tolérable) et le RPO (perte de données maximale) n'ont de valeur que confrontés à un exercice réel, chronométré, en conditions proches de la production. Un plan jamais exercé produit des RTO « espérés » qui explosent au premier incident : dépendances oubliées, procédures obsolètes, personnes clés absentes. Pour fixer des objectifs sensés, commencez par chiffrer ce que coûte une heure d'indisponibilité de vos services — la méthode tient dans un tableur. L'exercice a une vertu secondaire : il révèle les écarts entre la documentation et la réalité pendant qu'ils sont encore indolores.
3. Où redémarrez-vous si toute la région est indisponible ?
Multi-AZ n'est pas multi-région, et multi-région n'est pas multi-fournisseur. La réplication entre zones de disponibilité protège d'une panne de salle, pas d'un incident de région entière ni d'une défaillance de plan de contrôle qui traverse tout le fournisseur. Un vrai repli suppose une cible indépendante — autre région, autre fournisseur, ou infrastructure privée — avec des données déjà répliquées et un chemin de bascule exercé. C'est le même raisonnement qui structure un PRA à l'épreuve de la saison cyclonique : la cible de secours ne doit pas partager les faiblesses de la source.
4. Qui fait quoi pendant les 60 premières minutes ?
Une panne est aussi un problème d'organisation : qui détecte (votre supervision doit être hébergée hors du périmètre susceptible de tomber), qui décide la bascule, qui informe les clients, dans quel ordre se déroulent les runbooks. Une astreinte structurée, avec des critères de décision écrits, fait la différence entre une interruption maîtrisée et une soirée d'improvisation. C'est précisément ce que formalise une supervision avec astreinte sous SLA — celle qu'opère SOVALYX est volontairement indépendante des clouds qu'elle surveille.
Interprétez vos réponses
| Question | Bon signe | Signal d'alerte |
|---|---|---|
| 1. Dépendances | Inventaire écrit, à jour, incluant les dépendances indirectes | Cartographie partielle, ou uniquement dans les têtes |
| 2. RTO / RPO | Objectifs écrits, validés par un exercice chronométré | Chiffres jamais confrontés à un test réel |
| 3. Repli | Cible indépendante, données répliquées, bascule exercée | Multi-AZ chez le même fournisseur, ou rien |
| 4. Organisation | Runbooks, astreinte, critères de décision écrits | « On avisera le moment venu » |
Quatre bons signes : vous faites partie des 20 %. Deux ou moins : chaque semaine de statu quo est un pari sur la chance — que la statistique de l'enquête rend de moins en moins tenable. La bonne nouvelle : les questions 1 et 4 se traitent en quelques semaines, sans refonte d'architecture, et donnent immédiatement de la visibilité pour prioriser le reste. Et si l'exercice révèle un écart trop grand entre le RTO espéré et le RTO mesuré, la suite est un arbitrage de direction, pas un simple chantier technique : réduire l'écart, ou accepter le risque en connaissance de cause — mais par écrit.
Comment SOVALYX peut vous aider
SOVALYX vous aide à répondre aux quatre questions. Un diagnostic infrastructure cartographie vos dépendances au cloud public, y compris les indirectes. Notre cloud privé hébergé à Maurice fournit une cible de repli indépendante, avec un PRA automatisé dont les bascules testées et chronométrées transforment un RTO espéré en RTO mesuré. Et notre supervision 24/7 sous SLA, indépendante des clouds qu'elle surveille, couvre la détection et l'astreinte pendant les 60 premières minutes.
Parler PRA avec un ingénieur🧰 L'outil qui va avec : Combien vous coûte une heure d'arrêt ? — gratuit · 2 minutes.
Relu et optimisé par IA.