Panne mondiale frappe ChatGPT, l’API et Codex d’OpenAI

Les services principaux d’OpenAI ont vacillé dans le monde entier le matin du 25 juillet 2026, avec la page de statut de l’entreprise reconnaissant des taux d’erreur élevés dans ChatGPT, son API de développeur et l’assistant de codage Codex. Les utilisateurs des États-Unis à l’Inde et en Australie ont signalé qu’ils ne pouvaient pas charger les conversations, accéder à l’historique de chat enregistré ou exécuter des invites, ainsi que les points de terminaison sur lesquels des milliers d’applications externes s’appuient en silence.

Sur sa page d’incident, OpenAI a déclaré qu’il « enquêtait sur le problème pour les services répertoriés », en nommant les API, ChatGPT et Codex comme étant touchés. Vers 5 h 30 du matin, HE, l’entreprise n’avait pas identifié de cause ni proposé d’estimation pour une récupération complète. Son indicateur de statut de premier niveau a vacillé pendant l’événement, montrant par moments des systèmes entièrement opérationnels même si l’incident sous-jacent restait ouvert – le type de discordance qui tend à apparaître lorsqu’une dépendance partagée, plutôt qu’un produit unique, est en défaillance.

La portée de la perturbation

Les données des utilisateurs ont indiqué une panne large et presque simultanée, plutôt qu’un problème régional. L’outil de suivi de panne DownDetector a enregistré une vague de rapports à partir d’environ 5 h 11 du matin, HE, concentrés aux États-Unis, en Europe, en Inde, au Japon et en Australie. ChatGPT a attiré la grande majorité des plaintes, suivie de l’application mobile d’OpenAI et de Codex, une répartition cohérente avec un problème de backend situé en amont des interfaces utilisateur individuelles. Les rapports ont décrit les signatures familières d’une défaillance de service : des invites qui restaient en suspens sans réponse, des conversations et des projets qui ne chargeaient pas, et des sessions de connexion qui se déconnectaient.

Cette répartition est plus importante que le nombre brut de rapports. Lorsqu’une faute apparaît à la fois sur l’application Web, le client mobile et l’API, la cause se situe généralement dans une couche partagée (authentification, routage ou infrastructure de service que chaque produit appelle), et non dans un service unique. OpenAI n’a pas dit lequel, et rien dans ses mises à jour publiques ne pointe encore vers une cause racine.

Pourquoi la panne de l’API mord le plus fort

Pour l’entreprise d’OpenAI, le chatbot de consommation qui devient sombre est le symptôme visible ; l’API et Codex qui tombent avec lui constituent la partie coûteuse. OpenAI est l’une des plateformes d’IA les plus utilisées, et une grande partie de cette utilisation est maintenant programmée plutôt qu’un utilisateur qui tape dans une boîte de chat. L’API est le produit sur lequel une grande base de startups et d’entreprises s’appuie, en intégrant les modèles d’OpenAI dans leur propre logiciel, agents et outils internes ; Codex est intégré dans les flux de travail de codage des développeurs. Lorsque ces points de terminaison d’inférence cessent de répondre, la défaillance se propage en aval : les fonctionnalités orientées client qui appellent les modèles renvoient des erreurs, et les travaux d’ingénierie qui s’appuient sur les outils sont interrompus jusqu’à ce que le service soit rétabli. Pour les équipes qui vendent des logiciels construits sur ces appels, une panne d’OpenAI devient leur panne, se manifestant à leurs propres utilisateurs sous forme de fonctionnalités cassées et d’objectifs de niveau de service manqués.

Cette exposition est le coût silencieux de la consolidation de l’industrie autour d’un petit nombre de fournisseurs d’inférence. Des milliards sont injectés dans le calcul qui forme et sert ces modèles, de la mise de 5 milliards de dollars d’AMD sur Anthropic aux accords de puissance qui sont mis en place pour les nouveaux centres de données, mais la fiabilité de ce qui est déjà déployé décide toujours si cette capacité est utilisable un matin donné. Un modèle que le client ne peut pas atteindre vaut, pour cette fenêtre, rien.

Une vacillation récurrente

L’interruption se produit dans une période de disponibilité inégale. L’historique de statut d’OpenAI consigne des incidents d’erreur élevée répétés dans ChatGPT, l’API et Codex au cours des jours précédents, dont plusieurs ont nécessité des atténuations avant la récupération. Le tableau de bord de statut de l’entreprise place la disponibilité de ChatGPT à environ 99,7 % sur les trois mois précédents, en dessous du 99,9 % qu’il rapporte pour l’API, signe que la surface de consommation reste la plus instable des trois.

La fréquence est l’histoire réelle pour les entreprises qui acheminent désormais du trafic de production via ces systèmes. Une seule panne est du bruit ; un groupe les rend plus significatifs, influençant les décisions d’architecture, des replis multi-fournisseurs aux modèles auto-hébergés pour les charges de travail qui ne peuvent pas tolérer un matin hors ligne. Chaque incident est un autre point de données dans ce calcul. La récente divulgation par OpenAI selon laquelle ses propres modèles de test ont violé Hugging Face lors des tests de sécurité avait déjà mis les équipes d’infrastructure et de sécurité en alerte ; une vacillation visible de la disponibilité ajoute une ligne opérationnelle à cette surveillance.

Pour l’instant, les ingénieurs d’OpenAI travaillent toujours sur l’incident, sans cause publiée ni calendrier de récupération. Le fait que l’entreprise publie ou non un compte-rendu post-incident, comme elle l’a fait après des défaillances plus importantes, déterminera combien le reste du marché apprendra sur ce qui a mis les points de terminaison hors ligne.