Résumé
- L'incident ChatGPT a commencé le 21 juillet à 10:36:02 UTC et a été déclaré résolu le 22 juillet à 02:50 UTC, soit environ seize heures et quatorze minutes.
- La chronologie alterne atténuation et reprise de l'investigation, signe que l'amélioration n'est pas restée stable.
- Un dossier séparé pour l'API d'images a débuté à 19:33:27 UTC, a été atténué à 20:26 et résolu à 22:19.
- Le chevauchement temporel ne suffit pas à démontrer la même cause technique.
- OpenAI n'a fourni ni cause racine, ni volume de requêtes touchées, ni répartition régionale, ni perte de données ou droit à indemnité.
Pour un client, un message d'atténuation répond à une question pratique: peut-il relancer sa file de travail ? L'incident de ChatGPT montre pourquoi la réponse ne doit pas venir du bandeau seul. Plusieurs améliorations annoncées ont été suivies d'une nouvelle investigation.
Seize heures, mais plusieurs états
La période publique s'étend de 10:36:02 UTC à 02:50 UTC le lendemain. Sa durée brute ne raconte pas tout. Le service a connu des phases d'amélioration, puis un retour du problème, ce qui rend la planification plus difficile qu'une interruption franche de même durée.
« Atténué » signifie généralement qu'une mesure réduit l'impact. Le terme ne garantit ni la santé de tous les parcours, ni l'écoulement des tâches en attente, ni l'absence de rechute. Une équipe cliente doit vérifier ses propres requêtes synthétiques et attendre une période stable avant de libérer son arriéré.
La résolution a aussi un périmètre. OpenAI a considéré les composants concernés comme rétablis à 02:50. La fiche ne dit pas que toutes les créations abandonnées ont été rejouées ou livrées automatiquement.
L'API suit une autre chronologie
L'incident d'erreurs élevées de l'API a commencé plus tard, à 19:33:27 UTC. Il a reçu une mise à jour d'atténuation à 20:26 et s'est terminé à 22:19. Il chevauche donc le long épisode ChatGPT sans s'y confondre.
Deux défaillances simultanées peuvent partager une dépendance. Elles peuvent aussi être indépendantes. Les fiches ont des heures et des séquences différentes, et OpenAI ne publie pas de diagnostic. Parler d'une cause backend unique dépasserait les faits.
Il faut conserver les deux horloges dans une analyse de disponibilité. Un utilisateur de l'interface et un intégrateur API n'ont pas nécessairement rencontré la même fenêtre. Une entreprise utilisant les deux a pu cumuler les effets.
L'absence de métriques interdit un bilan global
Les pages ne précisent ni nombre de clients, ni taux d'erreur, ni régions, ni niveaux d'abonnement. Elles n'annoncent pas de perte de données. Elles prouvent une dégradation de disponibilité, pas un montant universel de pertes.
Le mécanisme opérationnel est toutefois prévisible: échecs, relances, doublons, validations retardées et surveillance humaine prolongée. Une campagne où l'image conditionne la publication peut s'arrêter; un autre client peut utiliser des actifs en cache. Les deux expériences ne doivent pas être agrégées sans données.
Un flux robuste suit séparément l'acceptation d'une requête, son état, la réception de l'actif et sa validation. Les clés d'idempotence évitent que des relances produisent plusieurs résultats quand le service revient. De petites sondes espacées valent mieux que le renvoi massif d'une file.
Les deux événements sont désormais clos. Leur leçon n'est pas une cause technique inventée, mais un problème de lecture des états: l'atténuation de ChatGPT n'était pas une récupération durable, tandis que l'API avait sa propre panne. La reprise réelle devait être mesurée côté client.