La panne d’OpenAI du 29 septembre a duré cinq heures et 22 minutes sur 30 composants

L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.

La page d’état d’OpenAI enregistre un incident le 29 septembre qui s’est déroulé de 17 h 52 à 23 h 14 UTC, soit cinq heures et 22 minutes, et répertorie 30 composants concernés dans ChatGPT, Codex et l’API. OpenAI l’a qualifié de « performances dégradées » plutôt que d’une panne pure et simple, certains utilisateurs constatant « des requêtes échouées, des difficultés de connexion ou d’inscription et des tâches qui ne se terminent pas ».

Aucune cause n’a été donnée. La mise à jour finale promet que « l’analyse détaillée des causes profondes (RCA) sera publiée dans les 5 prochains jours ouvrables », qui s’étendent du 29 septembre au 6 octobre, donc l’explication est attendue plutôt que tardive.

Le décompte se décompose 12, 14 et quatre

Douze des 30 composants se trouvent du côté de l’API, notamment les achèvements de chat, les réponses, l’API des agents et Realtime. Quatorze sont des surfaces ChatGPT, parmi lesquelles Conversations, ChatGPT Work, Deep Research et Connecteurs/Applications, la surface qui relie les plugins à votre travail et vos comptes personnels, et les quatre autres sont Codex : Codex Web, l’API Codex, la CLI et l’extension VS Code.

La connexion apparaît deux fois dans cette liste, une fois sous le groupe API et une fois sous ChatGPT, ce qui correspond à la propre description d’OpenAI des personnes ayant des « difficultés à se connecter ou à s’inscrire ». L’API de conformité et les sites, deux surfaces que la plupart des lecteurs ne toucheront jamais, sont répertoriés aux côtés des conversations et du mode vocal.

La première atténuation n’a pas tenu

OpenAI a ouvert l’incident à 17h52 UTC et l’a élargi à 19h08, en ajoutant l’API Agents au titre. À 19h39, il a publié « nous avons appliqué les mesures d’atténuation et surveillons la récupération », puis a publié à nouveau la même phrase à 21h09, à 22h03 et à 22h47.

Quatre notifications de surveillance identiques sur trois heures et huit minutes constituent la forme d’un correctif qui ne cesse de se défaire. La résolution est arrivée à 23h14, et la chronologie est le seul compte rendu de la soirée publié par OpenAI.

Le chat d’assistance a été interrompu trois minutes plus tôt

Un incident distinct s’est ouvert à 17 h 49 UTC, trois minutes avant le principal, et OpenAI a enregistré que « le chat d’assistance reste indisponible » tout en dirigeant les personnes vers une adresse e-mail. Cet incident a suivi son propre cours, avec un avis d’atténuation à 21h50 et une résolution à 23h18, quatre minutes après l’incident principal, de sorte que quiconque essayait de demander à OpenAI ce qui se passait pendant que cela se produisait devait plutôt envoyer un e-mail.

L’étiquette de gravité est restée à des performances dégradées pendant toute la soirée plutôt que de passer à une panne totale, de sorte que certaines parties de chaque service ont continué à répondre pour certaines personnes. OpenAI ne donne aucun chiffre sur le nombre de requêtes ayant échoué et affirme que ses mesures de disponibilité sont « signalées à un niveau global pour tous les niveaux, modèles et types d’erreurs ».

Jusqu’à ce que le rapport sur la cause profonde soit disponible, l’horloge et la liste des composants constituent l’intégralité du dossier public. OpenAI ne publie aucun numéro d’utilisateur, aucune répartition régionale et aucun taux d’erreur pour l’incident, et il n’a pas indiqué ce qui s’est cassé.