Le 23 octobre 2025, en fin d’après-midi, des milliers d’utilisateurs ont vu leurs écrans se figer : plus de réponse de ChatGPT, des délais interminables sur Grok, et une vague de messages d’erreur envahissant les forums et réseaux sociaux. Derrière ce chaos numérique, un seul suspect s’impose : l’infrastructure cloud d’Amazon Web Services, et plus précisément sa région us-east-1. Voici ce qui s’est réellement passé, pourquoi c’est grave, et comment éviter de se retrouver piégé la prochaine fois.
ChatGPT et Grok KO : AWS accusé – le contexte de la panne
Tout commence vers 15h00 UTC ce jeudi 23 octobre. Sur Downdetector, les signalements explosent pour ChatGPT, suivis quelques minutes plus tard par ceux concernant Grok. Les deux chatbots, pourtant développés par des entreprises distinctes (OpenAI d’un côté, xAI de l’autre), tombent presque simultanément. Cette coïncidence troublante oriente immédiatement les regards vers une cause commune : leur infrastructure partagée sur Amazon Web Services.
La région AWS us-east-1 (Virginie du Nord) est l’une des plus sollicitées au monde. Elle héberge une part colossale du trafic internet américain, incluant des dizaines de services d’IA, d’API cloud et d’applications mobiles. Quand elle vacille, c’est tout un écosystème numérique qui chancelle avec elle.
ChatGPT : l’erreur « Too Many Concurrent Requests » décryptée
Du côté d’OpenAI, les utilisateurs ont été accueillis par des messages peu rassurants : « Too many concurrent requests », roues de chargement infinies, pages blanches. La page de statut officielle d’OpenAI a rapidement confirmé deux points critiques :
- les API de ChatGPT subissaient un débit de requêtes anormalement élevé, provoquant des refus en cascade avec des codes erreur 429 (trop de requêtes) ;
- certaines fonctionnalités comme l’analyse de texte et l’interface de chat avaient été temporairement bridées pour éviter l’effondrement total des serveurs.
Le pic d’incidents a coïncidé avec les heures de bureau sur la côte Est américaine, un moment où des millions de professionnels sollicitent simultanément les API d’OpenAI. En Europe, notamment en Italie, les signalements se sont multipliés en début de soirée, transformant une panne régionale en incident mondial.
À 17h45 UTC, OpenAI publie sur sa page de statut : « Nous analysons actuellement un problème d’authentification causant des refus sur ChatGPT et l’API. » À 18h00 UTC, une lueur d’espoir : « Les erreurs sont en diminution. La reprise progressive est en cours. » Aucun post-mortem définitif n’avait été publié dans l’heure suivant l’incident, les équipes techniques préférant attendre l’analyse complète des logs.
Grok : des dysfonctionnements massifs aux États-Unis
Moins présent en Europe, Grok a néanmoins connu des perturbations sévères dans sa zone d’usage principale. Les développeurs et early adopters américains ont rapporté dès 15h00 UTC :
- des délais de réponse anormalement longs, parfois supérieurs à 30 secondes, avant une coupure brutale ;
- des erreurs serveur 500 Internal Server Error et 503 Service Unavailable se succédant en rafale ;
- une impossibilité totale de se connecter pour certains comptes, bloquant aussi bien les usages personnels que professionnels.
Sur Reddit et X (anciennement Twitter), les fils de discussion consacrés à la panne ont rapidement cumulé des milliers de réactions. Un point revenait systématiquement : d’autres services hébergés sur AWS us-east-1 affichaient des comportements similaires au même moment, renforçant la piste d’un incident d’infrastructure centralisé.
AWS us-east-1 dans le viseur : Route 53 et STS en cause
Les administrateurs système les plus aguerris ont vite ciblé deux composants critiques d’AWS comme points de défaillance probables.
Route 53 : quand le DNS flanche, tout s’arrête
Route 53 est le service de résolution DNS d’Amazon, chargé de traduire les noms de domaine en adresses IP pour acheminer les requêtes. Des perturbations dans us-east-1 ont provoqué des échecs de résolution DNS, rendant certaines URL d’API tout simplement injoignables. Résultat : même des utilisateurs avec une connexion internet parfaite ne pouvaient pas atteindre les serveurs de ChatGPT ou de Grok.
Security Token Service : l’authentification hors service
Le Security Token Service (STS) d’AWS gère la délivrance de tokens d’accès temporaires, indispensables à l’authentification des requêtes entre services cloud. Durant l’incident, des tokens invalides ou expirés prématurément ont bloqué des milliers d’authentifications, générant des erreurs en chaîne. Ce « STS outage » a eu un effet domino immédiat :
- des applications mobiles utilisant des micro-services AWS ne pouvaient plus se connecter ;
- des API de traduction et de synthèse vocale dépendantes de Route 53 sont devenues inaccessibles ;
- des bases de données en cache et des files d’attente de tâches ont enregistré des erreurs sporadiques, ralentissant l’ensemble de la chaîne de traitement.
Ces deux défaillances combinées expliquent pourquoi des services aussi différents que ChatGPT et Grok ont pu tomber en quasi-simultané : ils partagent la même couche d’infrastructure cloud, avec les mêmes points de fragilité.
Pourquoi AWS us-east-1 est un risque systémique pour l’IA
Cet incident met en lumière un problème structurel bien connu des architectes cloud : la centralisation excessive sur une région unique. AWS us-east-1 concentre une proportion démesurée du trafic mondial, ce qui en fait à la fois le pilier et le talon d’Achille de l’internet moderne. Quand cette région décroche, les conséquences se propagent à une vitesse redoutable :
- des millions d’utilisateurs finaux perdent l’accès à leurs outils quotidiens ;
- des entreprises entières voient leurs workflows automatisés s’interrompre brutalement ;
- la confiance dans les IA grand public, déjà fragile, en prend un nouveau coup.
Ce n’est pas la première fois qu’us-east-1 est au cœur d’une panne majeure. En 2021, une erreur de configuration avait déjà mis à genoux des centaines de services pendant plusieurs heures. L’histoire se répète, et les leçons semblent encore insuffisamment intégrées.
Comment se protéger des prochaines pannes d’IA
Que vous soyez développeur, chef de projet ou simple utilisateur avancé, voici des stratégies concrètes pour réduire votre exposition aux incidents cloud :
- Mettre en place un failover multi-région : distribuez vos charges entre plusieurs régions AWS (us-west-2, eu-west-1…) ou sur plusieurs fournisseurs cloud (Azure, GCP) pour éviter le point de défaillance unique ;
- Implémenter un cache local : conservez en mémoire les dernières réponses d’API pour assurer une continuité minimale pendant les coupures ;
- Configurer des retries progressifs : adoptez une logique d’exponential backoff pour éviter les boucles infinies de requêtes qui aggravent la surcharge ;
- Surveiller les pages de statut en temps réel : abonnez-vous aux flux RSS ou aux alertes de status.openai.com et des dashboards AWS pour être informé dès les premières minutes d’un incident ;
- Tester la résilience de vos systèmes : le chaos engineering (injection volontaire de pannes en environnement de test) permet d’identifier les fragilités avant qu’elles ne frappent en production.
La géo-redondance : impérative pour les services critiques
L’incident du 23 octobre 2025 est un rappel brutal : aucun service, aussi sophistiqué soit-il, n’est à l’abri d’une défaillance d’infrastructure. ChatGPT et Grok, malgré leurs milliards d’investissements, restent vulnérables dès lors qu’ils s’appuient sur un seul point de présence cloud.
Pour les entreprises qui intègrent ces IA dans leurs processus métiers, la géo-redondance n’est plus une option : c’est une nécessité absolue. Distribuer les charges, multiplier les fournisseurs, automatiser les bascules… Ces pratiques, longtemps réservées aux grandes infrastructures, deviennent accessibles à toutes les organisations grâce aux outils cloud modernes.
La prochaine panne aura lieu — c’est une certitude statistique. La vraie question est : serez-vous prêt à y faire face sans interrompre votre activité ?