Résumé

  • OpenAI a ouvert l’incident à 00 h 55 min 27 s UTC après une hausse d’erreurs portant le code invalid_prompt.
  • Une mesure corrective a été appliquée à 01 h 39 min 33 s, puis le service a été déclaré rétabli à 02 h 20 min 19 s, soit une chronologie publique de 1 h 24 min 52 s.
  • Le registre ne donne pas le statut HTTP des erreurs; séparément, le SDK Python associe un véritable HTTP 400 à BadRequestError et ne l’inclut pas dans ses reprises ordinaires.
  • Une file qui abandonne immédiatement tout invalid_prompt peut donc perdre un travail valide; une file qui répète tout risque au contraire les doublons et la surcharge.
  • OpenAI ne donne ni cause racine, ni taux d’échec, ni zone, ni liste de modèles ou de points d’accès, ni nombre de requêtes ou de clients touchés.

Le rejeu n’est pas un bouton de réparation. C’est une décision économique et technique: consommer de nouveau des ressources, retarder d’autres tâches et, selon l’opération, risquer de créer un deuxième effet alors que le premier a peut-être abouti.

L’incident d’OpenAI est intéressant parce qu’il retire au code d’erreur sa fonction habituelle de guide. invalid_prompt invite normalement à corriger la charge utile. Cette fois, le fournisseur a lui-même regroupé une hausse de ces erreurs dans un incident de service. L’automate ne pouvait donc choisir correctement entre abandon et nouvelle tentative à partir du seul nom.

Le statut 400 est une bonne règle générale, pas un verdict absolu

Dans le client Python officiel, une réponse HTTP 400 devient une BadRequestError. Cette classification est logique: une syntaxe invalide, un paramètre impossible ou une combinaison non prise en charge ne deviennent pas valides parce qu’on les renvoie.

La politique de reprise suit cette hypothèse. La documentation prévoit deux nouvelles tentatives par défaut pour les problèmes de connexion, le délai 408, le conflit 409, la limite 429 et les erreurs internes d’au moins 500. Le code tient aussi compte d’une instruction explicite x-should-retry. En l’absence de cette instruction, un 400 ordinaire n’entre pas dans l’ensemble rejoué.

Il ne faut pas renverser cette logique après un seul incident. Ajouter tous les 400 à la politique automatique masquerait de vraies fautes applicatives. La bonne correction consiste à introduire un état exceptionnel, activé par des preuves supplémentaires.

Une file de quarantaine vaut mieux qu’un oui ou non immédiat

Lorsqu’un type de requête connu et stable commence soudainement à produire le même rejet, l’application peut comparer ce signal au registre officiel des incidents. Si le fournisseur confirme une anomalie correspondante, les opérations concernées peuvent passer dans une file de quarantaine.

Cette file conserve le travail sans le rejouer encore. Elle mémorise l’heure, le point d’accès, le modèle, la classe d’erreur, le nombre de tentatives et la capacité de l’opération à être répétée sans danger. Une sonde limitée vérifie ensuite le retour du service avant l’ouverture progressive du stock.

La limitation est essentielle. Même lorsqu’OpenAI annonce une récupération, libérer des milliers de demandes au même instant peut recréer une pointe, épuiser des quotas ou produire des réponses qui arrivent dans le désordre. Le rejeu doit être cadencé, plafonné et observable.

L’idempotence dépend de l’effet, pas seulement du transport

Certaines demandes de génération peuvent être relancées sans modifier un registre externe; elles consomment néanmoins du temps et de la facturation. D’autres s’insèrent dans une chaîne qui publie un contenu, déclenche un courriel, met à jour un dossier ou facture un utilisateur. Dans ce cas, répéter l’appel peut dupliquer un effet aval même si l’API elle-même n’a rien créé de durable.

Avant le rejeu, le système doit savoir si la première tentative a été refusée avant traitement, acceptée puis perdue dans la réponse, ou exécutée avec un résultat que le client n’a pas reçu. L’incident public ne tranche pas ces états pour chaque requête.

Une clé d’opération côté client, un registre de résultats et une vérification de l’état aval réduisent ce risque. L’objectif n’est pas de donner à chaque appel une infinité de chances; il est de garantir qu’un résultat utile apparaisse au plus une fois dans le processus métier.

L’identifiant de requête relie le client au fournisseur

Le SDK Python expose l’identifiant de requête sur les exceptions APIStatusError échouées. Le conserver permet d’isoler une transaction précise lors d’une enquête. Sans lui, l’équipe n’a souvent qu’une heure approximative et un message d’erreur commun à de nombreux appels.

Un journal utile peut aussi garder une empreinte non réversible de la forme de la demande, la version du SDK et la décision prise par l’automate. Il ne doit pas recopier des clés, des données personnelles ou le texte brut d’une invite sensible. L’observabilité ne justifie pas de créer une deuxième fuite.

Ces traces permettent surtout de distinguer deux groupes après récupération: les charges réellement mal formées, qui doivent rester rejetées, et les demandes cohérentes avec l’incident, qui peuvent être reprises une seule fois sous contrôle.

La résolution publique ouvre le travail de réconciliation

OpenAI a publié trois étapes: enquête, mesure corrective sous surveillance, puis récupération complète des services touchés. La durée entre la première et la dernière est de 1 h 24 min 52 s. Le statut qualifie l’impact de mineur et ne nomme que la composante « APIs ».

Cette chronologie ne donne pas une durée individuelle pour chaque client. Elle ne dit pas non plus que les tâches abandonnées sont revenues toutes seules. Un lot classé définitivement invalide avant 02 h 20 restera perdu si personne ne le rapproche de l’incident.

La réconciliation doit donc fermer trois comptes: quelles opérations ont échoué dans la fenêtre, lesquelles étaient réellement incorrectes, et lesquelles ont été rejouées avec un résultat confirmé. Une annonce « résolu » ferme la bannière du fournisseur; elle ne ferme pas le registre du client.

OpenAI n’a pas encore expliqué pourquoi une panne de service s’est manifestée par invalid_prompt, ni donné le statut HTTP correspondant. Faute de cause et de statut, il serait abusif d’attribuer chaque erreur homonyme au fournisseur ou de présenter les réponses de l’incident comme des 400 établis. Mais l’incident suffit à modifier une pratique: une erreur réputée définitive peut mériter une conservation temporaire lorsqu’un signal externe fiable contredit son étiquette.

Sources