Une panne majeure a frappé Amazon Web Services ce 20 octobre 2025, affectant des dizaines de services numériques dans le monde. Si l’incident semble circonscrit à la région us-east-1, sa résonance souligne à nouveau la fragilité des architectures dépendantes d’un unique fournisseur ou d’une seule zone cloud.
Déclenchée en début de journée en Amérique du Nord, la panne s’est propagée à l’échelle mondiale, avec des effets visibles en Europe dès la fin de la matinée. Plusieurs plateformes grand public comme Snapchat, Signal, Duolingo ou Perplexity AI ont connu des interruptions totales ou partielles. Les premières analyses publiées sur le tableau de bord AWS Health pointent un dysfonctionnement au niveau du service DNS interne, impactant l’accès aux API critiques, notamment celles d’Amazon DynamoDB.
L’incident a provoqué une cascade d’erreurs sur les services qui s’appuient sur cette région historique d’AWS, us-east-1 (Virginie du Nord), fréquemment utilisée comme point d’entrée par défaut dans les déploiements cloud. Des entreprises clientes ont signalé des anomalies dans l’authentification, le traitement des requêtes API, la gestion des workflows ou encore la connectivité réseau dans leurs environnements hébergés.
Effet de levier mondial d’une panne localisée
Si la panne ne concerne qu’une seule région physique, ses effets sont structurellement systémiques. De nombreuses organisations n’activent pas de configuration multi-régions par défaut, exposant l’ensemble de leur chaîne applicative à un point unique de défaillance. Ce biais s’explique par la complexité technique et les surcoûts associés à la redondance interrégionale chez les hyperscalers.
En Europe, plusieurs services de transport, d’assistance client, de veille technologique et d’analyse de données ont vu leur fonctionnement ralenti ou suspendu. Des institutions publiques, notamment au Royaume-Uni, ont également rapporté des indisponibilités partielles. En France, les effets restent diffus, mais plusieurs éditeurs SaaS hébergés sur AWS ont discrètement activé leurs protocoles de reprise sans bascule complète.
Amazon temporise, mais l’écosystème s’alerte
AWS a rapidement reconnu l’incident sur son tableau de bord officiel et déclenché une procédure de remédiation. Les services touchés ont progressivement été rétablis au cours de la journée, sans que la cause racine n’ait encore été publiée. Des spécialistes évoquent un problème de propagation DNS ou de saturation interne des services de gestion réseau, deux points sensibles dans l’historique des précédentes pannes chez AWS.
La réaction rapide n’efface pas l’inquiétude de nombreux responsables techniques. L’événement est le dernier d'une série d’incidents récents qui soulignent l’absence de tolérance réelle aux pannes dans une partie des architectures cloud actuelles. Plusieurs analystes relèvent que les entreprises ont multiplié leurs charges cloud sans toujours renforcer leur résilience opérationnelle.
Trois leviers pour une résilience réelle
Au-delà de l’incident, cet épisode remet en lumière les conditions concrètes d’une architecture robuste. D’abord, la diversification géographique des déploiements, en s’appuyant sur au moins deux régions dans le même cloud. Ensuite, la stratégie multi-cloud, encore marginale dans les faits, mais plus souvent évoquée par les responsables IT depuis l’émergence des IA critiques. Enfin, la cartographie des dépendances implicites (services managés, identifiants, passerelles internes) reste essentielle pour éviter les effets de bord.
Les plans de continuité d’activité doivent intégrer des scénarios de panne partielle sur un fournisseur, incluant l’échec des solutions de contournement automatisées. Tester ces scénarios, notamment sur les fonctions cœur métier, devient un impératif. Car même chez les fournisseurs les plus fiables, les incidents techniques, bien que rares, produisent des effets disproportionnés si les systèmes clients ne sont pas conçus pour s’en isoler temporairement.
Le cloud public sous tension, la souveraineté relancée
Si cette panne AWS n’est pas inédite, elle intervient dans un contexte de tension sur les usages intensifs de l’IA et des données temps réel, qui rendent l’interruption d’un service cloud particulièrement coûteuse. La multiplication des agents conversationnels, des modèles embarqués et des flux événementiels accroit l’effet de bord d’une défaillance d’infrastructure. Le besoin de souveraineté, technique autant que géopolitique, redevient un argument tangible pour diversifier les fournisseurs et relocaliser certains workloads critiques.
Amazon n’a pas encore communiqué de calendrier pour la publication d’un rapport d’analyse détaillé. L’enquête interne devrait préciser l’origine exacte du dysfonctionnement et les correctifs engagés. En attendant, les DSI sont nombreuses à réévaluer la tolérance au risque de leurs chaînes applicatives, et à rappeler que le cloud n’est pas, par nature, synonyme de continuité automatique.
