Résumé
- OpenAI a ouvert l'incident le 22 juillet à 07:32:04 UTC pour des erreurs élevées affectant les fichiers et les images.
- À 07:54, l'enquête continuait; à 09:26:27, le problème était identifié et une atténuation était en cours de mise en œuvre.
- La clôture canonique est fixée à 09:40:04: l'incident y reste actif et identifié.
- OpenAI n'est passé en surveillance qu'à 09:44:41, soit après la fenêtre.
- Aucune cause, population, proportion de requêtes, région, perte de données ou liaison avec l'incident précédent n'était publiée.
Une page d'état modifiée quatre minutes après une clôture éditoriale pose un choix simple: respecter l'heure ou réécrire le passé. Ici, respecter l'heure signifie ne pas annoncer la surveillance dans un article dont l'état factuel s'arrête à 09:40:04 UTC.
À ce moment, OpenAI disait avoir identifié les erreurs et travailler à une atténuation. Pour un client, cela signifie encore incertitude: envoyer ou non un fichier, libérer ou non une file d'images, attendre ou changer de fournisseur.
L'entrée et la sortie du flux étaient nommées
Le téléversement de fichiers conditionne l'entrée de matière. La génération d'images conditionne la sortie visuelle. Leur présence dans le même dossier crée plusieurs points d'échec possibles.
OpenAI ne précise pas les types de fichiers, produits, régions ou niveaux d'abonnement. Il ne donne pas de taux d'erreur. On peut donc dire que les deux fonctions ont connu des erreurs élevées, pas que toutes les requêtes ont échoué.
Une file peut alors mélanger des tâches refusées avant ingestion, acceptées sans résultat, ou terminées sans retour visible. Les relancer en bloc risque de produire des doublons ou de perdre la trace du coût réel.
La proximité avec la panne précédente n'est pas une cause
Le nouvel incident a commencé environ quatre heures et quarante-deux minutes après la résolution à 02:50 d'une longue panne distincte de génération d'images dans ChatGPT.
Cette proximité intéresse l'exploitation: les équipes dépendantes de l'image retrouvent presque immédiatement une période d'incertitude. Elle ne prouve ni le même composant, ni un correctif permanent défaillant. Le nouveau dossier ajoute les fichiers et possède son propre identifiant.
OpenAI n'avait publié aucune cause commune à l'heure de clôture. Il faut donc parler de récurrence fonctionnelle, non de causalité technique.
« En cours » est un état éditorial complet
Un article sur une panne n'a pas besoin d'attendre la fin pour être exact. Il doit annoncer son horodatage et limiter ses verbes. À 09:40:04, l'atténuation était en préparation. La mise à jour de 09:44 peut nourrir un suivi, pas cette photographie.
Même la surveillance ne signifierait pas résolution. Elle indiquerait qu'une mesure est appliquée et que le fournisseur observe le retour. Une entreprise cliente doit encore exiger plusieurs succès synthétiques et une période stable avant de rejouer son arriéré.
Conserver l'état inconnu dans la file
Les systèmes robustes distinguent un fichier rejeté, accepté, traité ou laissé sans réponse finale. Ils conservent les identifiants et utilisent l'idempotence lorsque disponible. Pour les images, une petite sonde régulière vaut mieux qu'une relance massive au premier changement de couleur.
Il faut aussi tester séparément les deux fonctions. Une image générée à partir d'un contenu déjà présent ne prouve pas qu'un nouveau fichier peut entrer; un fichier accepté ne prouve pas que l'image sortira.
À la clôture, l'incident OpenAI était toujours actif. Le récit suivant pourra intégrer la surveillance. Celui-ci garde la décision que les opérateurs devaient prendre à 09:40, sans bénéficier d'une information arrivée quatre minutes plus tard.