Panne AWS du 16 juillet : trois heures et demie sans levier

21 juillet 2026 · 4 min de lecture · SOVALYX Technologies

Le 16 juillet 2026, le réseau de diffusion de contenu d'Amazon Web Services a servi des erreurs pendant trois heures et demie. Des plateformes éducatives, un site de loterie nationale et une grande plateforme d'IA sont tombés avec lui. Aucune cyberattaque : une erreur de configuration interne, et des milliers de clients sans le moindre levier d'action.

Ce qui s'est passé

L'incident a duré de 07 h 45 à 11 h 18 UTC, soit trois heures et trente-trois minutes, pendant lesquelles CloudFront a renvoyé des erreurs serveur au lieu des sites qu'il devait diffuser. Parmi les services touchés et identifiés publiquement : les plateformes éducatives Canvas et Blackboard, la plateforme d'IA Hugging Face, et la loterie nationale britannique.

La cause racine, telle qu'AWS l'a décrite, tient en une phrase : « an internal constraint on the fleet that manages connections to private VPC origins. When this constraint was reached, the system responsible for distributing routing configuration to our network processors failed to load the updated configuration data correctly ». Une limite interne atteinte sur le parc gérant les connexions aux origines privées ; le système chargé de distribuer la configuration de routage n'a plus chargé correctement les données mises à jour.

Autrement dit : rien d'exotique, rien de malveillant, aucun acteur hostile. Un mécanisme interne a rencontré sa propre limite. C'est le mode de défaillance le plus courant des très grandes infrastructures, et le plus difficile à anticiper de l'extérieur — car par définition, vous ne connaissez ni ces mécanismes ni ces limites.

La leçon n'est pas « le cloud est dangereux »

Il serait malhonnête de conclure qu'une infrastructure interne aurait mieux tenu. Les grands fournisseurs affichent des disponibilités qu'une salle serveur d'entreprise atteint rarement, et une panne de trois heures et demie reste, en valeur absolue, un incident modeste.

La vraie leçon porte sur la nature du risque, pas sur son ampleur. Quand votre propre infrastructure tombe, vous pouvez agir : diagnostiquer, arbitrer, redémarrer, appeler quelqu'un. Quand c'est celle de votre fournisseur, vous ne pouvez que rafraîchir une page d'état et expliquer à vos clients que vous ne savez pas. Vous n'avez ni information privilégiée, ni influence sur les priorités de rétablissement, ni date de retour. C'est une perte de contrôle, et elle ne se compense pas par une meilleure négociation contractuelle.

Car le contrat, précisément, ne compense rien. Un engagement de service d'hyperscaler rembourse des crédits proportionnels à l'indisponibilité, pas le chiffre d'affaires perdu, pas les clients partis, pas les heures de vos équipes. Cette asymétrie est structurelle et connue — encore faut-il l'avoir lue avant de signer, comme nous le détaillions à propos des engagements de service en informatique.

Le point aveugle du réseau de diffusion

Cette panne éclaire une dépendance rarement cartographiée. Beaucoup d'organisations savent où leurs serveurs sont hébergés, mais bien moins savent quel service diffuse leurs pages, résout leurs noms de domaine ou termine leurs connexions chiffrées. Ces briques sont invisibles quand elles fonctionnent, et totalement bloquantes quand elles échouent : votre serveur peut être parfaitement sain et votre site rester injoignable.

La question à poser est donc plus large que « où est mon serveur ? ». Elle est : par combien de fournisseurs distincts une requête d'un de vos clients passe-t-elle avant d'atteindre votre application, et lequel d'entre eux, en tombant seul, suffit à tout arrêter ? Dans la plupart des organisations, ce recensement n'a jamais été fait — et il prend une demi-journée.

Ce qui aurait limité les dégâts

Trois dispositions, par ordre de coût croissant. La plus simple : une page de repli statique, hébergée ailleurs, expliquant la situation et donnant un moyen de contact. Elle ne rétablit pas le service mais elle évite le silence, qui est ce que les clients retiennent. La deuxième : un chemin de secours pour les fonctions vraiment critiques — un second point de diffusion, ou la capacité de servir directement depuis l'origine en contournant l'intermédiaire défaillant. La troisième, réservée à ce qui ne peut pas s'arrêter : une infrastructure locale maîtrisée pour les fonctions dont l'interruption coûte plus cher que la redondance.

Le tri entre ces trois niveaux ne se fait pas au feeling. Il se fait en chiffrant ce que coûte réellement une heure d'arrêt, activité par activité — c'est l'exercice que nous décrivons dans le coût d'une heure d'arrêt, et il donne souvent des résultats surprenants : certaines fonctions supposées critiques peuvent attendre une demi-journée, d'autres jugées secondaires bloquent la facturation.

Le test à faire cette semaine

• Lister les fournisseurs traversés par une requête client : diffusion de contenu, DNS, hébergement, authentification, paiement.
• Identifier les points uniques de défaillance : lequel, en tombant seul, arrête tout ?
• Chiffrer une heure d'arrêt pour vos deux ou trois processus les plus critiques.
• Vérifier ce que rembourse votre contrat — et constater l'écart avec le chiffre précédent.
• Préparer une page de repli hébergée chez un autre fournisseur, prête à publier.
• Écrire le mode dégradé : que fait l'équipe commerciale, le support, la production pendant l'interruption ?
• Désigner qui communique vers les clients, et avec quel message type.
• S'abonner aux pages d'état de vos fournisseurs — apprendre la panne par un client est le pire scénario.
• Tester la bascule au moins une fois, et faire auditer les dépendances que personne n'a cartographiées.

🧰 L'outil qui va avec : Combien vous coûte une heure d'arrêt ? — gratuit · 2 minutes.

Relu et optimisé par IA.