Le matin du 20 octobre 2025, des millions d’utilisateurs ont constaté que Snapchat, Fortnite, Airbnb et Reddit étaient figés. De plus, les assistants vocaux restaient muets, tandis que les écrans affichaient des pages blanches. À l’origine, une panne DNS AWS chez Amazon Web Services (AWS), partie de la région AWS US-EAST-1 en Virginie, qui a perturbé la résolution DNS et provoqué des erreurs DynamoDB lors de l’accès à l’API. Premier signal vers 09 h 11 à Paris, rétablissement progressif en fin de matinée : notre dépendance au cloud s’affiche à nu. À 09 h 11 à Paris, l’indisponibilité des services AWS s’impose. La reprise sera progressive, et notre dépendance au cloud, criante.
Ce que l’on sait à cette heure
Le lundi 20 octobre 2025, une défaillance sur Amazon Web Services (AWS), la filiale cloud d’Amazon, a provoqué des taux d’erreur et des latences élevées dans la région AWS US-EAST-1 située en Virginie. Des plateformes parmi les plus utilisées au monde ont vacillé, de Snapchat à Fortnite et Roblox, de Airbnb à Canva, de Reddit à Prime Video, sans oublier Alexa, Perplexity, Signal, Zoom, Tinder ou Ring. Les difficultés ont été ressenties en Europe, dans les Amériques et en Afrique, causant des problèmes de connexion. En France, cela s’est traduit par une pluie de messages d’erreur et des impossibilités de connexion. Le suivi en temps réel a convergé vers l’AWS Health Dashboard (tableau de bord AWS Status (Health)), tandis que Downdetector (panne AWS) agrégait des vagues de signalements.
Premiers signaux à 09 h 11 à Paris ; retours notables entre 11 h 27 et 11 h 35 ; à 13 h 06, AWS indique une amélioration majoritaire. Des lenteurs locales ont cependant persisté selon les zones et les services.
D’où vient la panne
Les indications publiées par AWS et reprises par la presse spécialisée convergent vers une panne Route 53 (résolution DNS) qui aurait entravé l’accès à l’API de DynamoDB, générant des erreurs DynamoDB. La défaillance, localisée en AWS US-EAST-1, a essaimé par effet de cascade vers d’autres briques, déclenchant des pics d’erreurs et des latences sur des services dépendants. Dans un écosystème où les composants managés — bases, files, équilibreur de charge, passerelles API — s’entrelacent, un nœud qui déraille et l’orchestre s’enraye. Rien n’indique à ce stade un acte malveillant. Tout indique, au contraire, la présence d’un bug réseau. Sa propagation est spectaculaire car elle affecte des millions d’utilisateurs.
Les répercussions concrètes pour les usagers
La panne a pris la forme d’un quotidien soudain grippé.Applications indisponibles (panne AWS), et assistants vocaux muets, sont des symptômes. De plus, les alarmes d’Alexa deviennent capricieuses. Les pages de connexion n’affichent que des pages blanches. Du côté des messageries chiffrées, Signal a reconnu des perturbations. Les services de visioconférence tels Zoom ont aussi subi des à-coups. Les plateformes de jeux ont vu leurs files d’attente s’allonger, et certaines sessions se clore abruptement. Pour les créateurs et indépendants, dépendant d’outils en ligne, l’entracte forcé a rappelé cette fragilité. En effet, leur activité est devenue nativement connectée.
Entreprises et institutions face au grain de sable
Dans les entreprises, l’incident a convoqué l’ensemble des équipes IT. Les SLA ont été mis sous tension, les canaux de support saturés, et les directions de la sécurité comme de la production ont suivi au cordeau les mises à jour du fournisseur. Au Royaume-Uni, des institutions et acteurs majeurs comme Lloyds Bank, Vodafone, BT ou l’administration fiscale HMRC ont constaté des perturbations de services AWS, en parallèle des signaux relevés par Downdetector (panne AWS). Les pertes d’exploitation sont difficiles à quantifier immédiatement. Cependant, l’arrêt brutal d’un paiement, d’une réservation ou d’un service client engendre rapidement des coûts mesurables. De plus, cela affecte l’image de l’entreprise.
Le précédent qui ne surprend plus
Cette panne souligne une fois encore la concentration extrême du marché du cloud, dominé par AWS, Microsoft et Google. Elle souligne notre hyper-dépendance à des couches techniques invisibles au grand public. Cependant, chaque application familière représente la pointe émergée de ces technologies. L’architecture moderne, distribuée et élastique, promet la résilience. Cependant, cette promesse est tenue uniquement si l’on anticipe les scénarios noirs. De plus, il faut accepter le coût d’une véritable redondance. Une région unique, si vaste soit-elle, reste un point de fragilité. Un fournisseur unique, si puissant soit-il, demeure un risque systémique.
Chronologie précise d’une matinée chahutée
Au fil des heures, les marqueurs se sont empilés. 09 h 11 : les premières anomalies remontent des consoles et des métriques. 11 h 27 puis 11 h 35 : des services essentiels recommencent à répondre correctement, parfois avec des temps de latence supérieurs à la normale. 13 h 06 : la majorité des opérations est annoncée comme rétablie. Cependant, une vigilance est maintenue sur certains sous-systèmes susceptibles d’accumuler des arriérés et des files d’attente internes. À l’échelle de la planète, l’impact s’est déplacé par vagues. En effet, les salves horaires de connexions testaient sans relâche la capacité restante.
Comment les géants réparent à chaud
Dans la coulisse, les équipes d’AWS ont d’abord stabilisé la couche DNS, puis dégorgé les arriérés dans les files et caches, avant de rétablir progressivement les points d’entrée des services managés. Les clients, eux, ont déclenché des plans PCA/PRA calibrés pour ces aléas : bascule de trafic, bascule et failover via Route 53, limitation des fonctionnalités non critiques, activation de modes dégradés, suspension de certaines écritures le temps de retrouver un chemin sûr. Dans les jeunes pousses comme chez les très grands, la communication d’incident a occupé une place centrale. En interne, elle servait à coordonner les gestes, tandis qu’en externe, elle informait sans en dire trop.
Pistes de résilience pour demain
La résilience ne se décrète pas, elle s’architecture. Un multi-cloud pragmatique peut protéger les services stateless en les répliquant chez plusieurs fournisseurs, à condition d’investir dans une gestion des identités portable, des secrets synchronisés et une neutralité réseau réelle. Une stratégie multi-région, en actif-actif ou actif-passif, s’impose pour les charges vitales, avec un failover automatisé testé régulièrement via Route 53 chez AWS ou ses équivalents. Les objectifs RTO/RPO doivent être assumés, mesurés, disputés même, puis entraînés par des exercices de chaos engineering. Côté client, des circuit breakers évitent d’acharner les requêtes quand l’aval s’effondre. Des files et événements — SQS ou Kafka — permettent d’absorber les à-coups et de lisser les pics. Les modes offline et les caches locaux soutiennent les fonctions essentielles quand le réseau se tait. Enfin, une observabilité unifiant logs, métriques et traces sur plusieurs fournisseurs offre une vision moins myope. Cela est particulièrement utile lors des nuits de tempête.
À l’usage des lecteurs : où s’informer et que faire
Pour connaître l’état des lieux, le tableau de bord AWS Health publie les incidents par service et par région ; sa documentation rappelle la signification des alertes. Les mises à jour officielles passent aussi par @awscloud et par le tableau de bord AWS Status (Health), tandis que la vue terrain reste alimentée par Downdetector (panne AWS) et sa cartographie des signalements en France.
En cas d’erreurs liées au DNS côté utilisateur, on peut vider le cache de la machine. Ensuite, il est recommandé de redémarrer la box. Ensuite, il est possible de tester un résolveur public comme 8.8.8.8 ou 1.1.1.1. Enfin, purgez le cache du navigateur ainsi que les cookies du site visé. En entreprise, les réflexes immédiats portent sur les résolveurs internes, les règles de pare-feu, un éventuel split-horizon DNS et la santé des proxies ou d’un SD-WAN.
Ce que cela dit de notre présent numérique
On aurait tort de ne voir dans l’incident du jour qu’un mauvais moment à passer. Cette panne illustre la fragilité d’un monde ayant externalisé sa mémoire dans des nuages privés. De plus, la puissance de calcul y est également externalisée. Toutefois, cela entraîne une dépendance parfois irréfléchie. Elle interroge les clauses contractuelles, les pénalités liées aux SLA, les exclusions de responsabilité, mais aussi la gouvernance des données et des architectures. Elle oblige à arbitrer entre la simplicité du tout-intégré et la complexité d’une redondance multiforme. Elle rappelle enfin que la sobriété n’est pas l’ennemie de la performance. En effet, des services frugaux et tolérants à l’intermittence misent sur le cache. De plus, la dégradation gracieuse leur permet de mieux encaisser l’imprévu. Cela est plus efficace que des cathédrales de micro-services où chaque geste dépend d’un autre.
Le visage d’AWS et le poids du cloud
À la tête d’Amazon depuis 2021, Andy Jassy a longtemps dirigé AWS. En effet, il fut l’artisan de sa montée en puissance. Sous son impulsion, la division cloud est devenue la vache à lait du groupe et son laboratoire d’innovations, des fonctions serverless aux bases managées, en passant par l’apprentissage automatique à la demande. Ce succès a ancré AWS au cœur d’une économie où l’informatique à la carte est devenue la norme. Cette centralité explique la portée des incidents : quand une épine dorsale se dérobe, c’est une part sensible du trafic mondial qui se trouve ralentie. Les régulateurs et les DSI considèrent cela comme un enjeu de souveraineté et de dépendance technologique. Pendant ce temps, les architectes s’interrogent sur la juste mesure entre spécialisation et portabilité.
La concentration du marché nourrit un débat récurrent sur les coûts de sortie et le verrouillage induit par des services différenciants. L’adoption de standards ouverts peut desserrer cet étau. Cependant, l’usage généreux des conteneurs et des interfaces communes entraîne souvent des coûts. Par ailleurs, il y a rarement des compromis sur la performance. À l’inverse, la promesse d’une intégration serrée peut justifier l’attachement à un fournisseur unique. De plus, un écosystème riche peut également le justifier, mais cela concerne surtout le court terme. L’incident du jour force à re-poser ces arbitrages.
Ce qu’il faut retenir : résilience, prudence, diversité
Il suffit d’une zone en panne, en l’occurrence AWS US-EAST-1, pour que le monde prenne conscience de la part d’ombre de son confort numérique. L’incident du 20 octobre 2025, où l’on a vu de Snapchat à Reddit, de Airbnb à Prime Video, trébucher dans le même élan, offre une leçon simple : la résilience n’est pas une option. Elle est une intention qui se conçoit, se finance et se teste. Les heures suivantes diront si la cause racine — une panne de résolution DNS dégradant l’accès à DynamoDB — se confirme. Elles n’effaceront pas l’essentiel : pour demeurer fluide, notre présent numérique exige de changer d’échelle, non en puissance brute, mais en prudence et en diversité. Pour les mises à jour en temps réel, on se reportera au tableau de bord AWS Health.