La nuit du mardi 14 juillet 2026, ChatGPT est devenu instable. En quelques minutes, DownDetector a enregistré plus de 1 596 signalements. De son côté, OpenAI a confirmé la panne sur sa page de statut. Selon l’entreprise, des difficultés de connexion et des erreurs intermittentes affectaient le service. Et pendant ce temps, la perspective de retour à la normale ne s’est tout simplement pas dessinée.
Pour l’utilisateur final, l’épisode est devenu une plaisanterie dans le fil d’actualité. En revanche, pour ceux qui gèrent une application en production, la nuit a généré des alertes, des tickets et des retouches. Autrement dit : la dépendance est sortie du papier et a fait payer son coût.
Par conséquent, il faut changer la question. Plutôt que de se demander quand OpenAI reviendra, demandez ce qui se passe dans votre système pendant qu’elle prend son temps à revenir.
ChatGPT instable révèle une faille qui habite votre stack
Le problème n’est presque jamais la panne en elle-même. Toutes les API tombent, même les meilleures. En pratique, le souci, c’est que votre code traite le modèle comme s’il était infaillible.
Repérez le schéma classique. Tout commence lorsque l’utilisateur clique sur un bouton. Ensuite, votre route appelle l’API et attend une réponse. Puis l’attente bloque un worker. Rapidement, la file d’attente s’allonge et le pool de connexions se sature. Ainsi, l’instabilité d’un tiers devient votre indisponibilité.
De plus, les erreurs de connexion et les erreurs intermittentes se comportent de manière différente. La première répond généralement rapidement avec 401 ou 403. La seconde renvoie 429, 500 ou 503 de manière irrégulière. C’est pourquoi traiter tout comme une erreur générique conduit à de mauvaises décisions.
Timeout court sauve plus de nuits que les retries infinis
Un timeout court bat le retry infini dans presque tous les scénarios. Toutefois, beaucoup de personnes configurent le contraire. Un timeout de soixante secondes paraît généreux et patient. En réalité, il ne fait que transférer la file d’attente à l’intérieur de votre application.
Commencez par fixer un plafond agressif par appel. Puis appliquez des retries avec backoff exponentiel et jitter. Ainsi, vous évitez l’effet de troupeau lorsque le service revient. Néanmoins, limitez les tentatives à deux ou trois.
Un détail passe souvent inaperçu. Le retry n’est pertinent que pour une erreur transitoire et idempotente. Par conséquent, respectez l’en-tête Retry-After lorsque l’API l’indique. De plus, propagez une clé d’idempotence dans les opérations qui écrivent des données.
Notez chaque tentative avec le motif réel de l’échec. Ainsi, le post-mortem cesse d’être une devinette.
Disjoncteur : le fusible qui empêche l’effet domino
Le disjoncteur résout ce que le retry, seul, aggrave. La logique est simple. Tant que le taux d’erreurs reste sous la limite, le circuit reste fermé. Lorsque le taux d’erreur dépasse le seuil, le circuit s’ouvre. Alors, les appels suivants échouent immédiatement, sans toucher le réseau.
Après une pause, le disjoncteur passe à l’état semi-ouvert. À ce moment-là, il autorise quelques requêtes de test. Si elles passent, le circuit se referme à nouveau. Sinon, le disjoncteur se remet à s’ouvrir et le cycle recommence.
En pratique, trois paramètres comptent. Premièrement, la limite d’erreurs qui déclenche l’ouverture du circuit. Deuxièmement, la fenêtre d’observation. Troisièmement, le temps d’attente avant le test. Ajustez ces chiffres à partir de données réelles de production, et non d’estimations issues de la documentation.
Le bulkhead complète bien la stratégie. Isolez le pool de connexions de l’IA du reste du système. De cette manière, le checkout peut rester opérationnel même lorsque l’assistant est muet.
Ce que votre écran montre lorsque ChatGPT se tait
La dégradation élégante permet de distinguer un produit mature d’un prototype qui tient par hasard. La question est directe. Que rend votre interface au milieu d’une panne ?
Il existe des chemins meilleurs que de regarder tourner un spinner à l’infini. Par exemple, servir une réponse en cache pour les prompts répétés. De plus, proposer un flux déterministe comme plan B. Dans bien des cas, une simple recherche suffit pour satisfaire la demande de l’utilisateur.
Pour les tâches asynchrones, poussez le travail dans une file durable. Puis, avertissez l’utilisateur lorsque le résultat est prêt. Ainsi, la chute devient un retard plutôt qu’une erreur.
La communication compte aussi. Un message clair réduit les tickets de support. Indiquez que l’assistant est indisponible et proposez l’alternative sur le même écran.
Abstraire le fournisseur avant que la prochaine chute de ChatGPT ne le fasse à votre place
L’idée paraît évidente, bien que peu d’équipes s’y mettent réellement. Créez une interface interne pour la génération de texte. Ensuite, masquez le SDK derrière elle.
Avec cette couche, changer de modèle devient une configuration. Par conséquent, maintenez au moins un fournisseur alternatif homologué. Anthropic, Google et des fournisseurs open source répondent bien en tant que réserve. De plus, un petit modèle local couvre les cas simples avec un coût réduit.
Attention à un détail silencieux. Un prompt affiné pour un modèle ne fonctionne pas nécessairement de la même façon avec un autre. Par conséquent, versionnez les prompts par fournisseur et réalisez une batterie d’évaluations. Sans ce test, le failover livrera une réponse de mauvaise qualité et détruira la confiance.
Une feature flag clôt le tout. Avec un drapeau, vous désactivez la fonctionnalité IA en quelques secondes. Ainsi, la décision échappe au déploiement et passe au runtime.
Surveillez la page de statut d’OpenAI comme si elle était la vôtre
L’observabilité transforme la panique en diagnostic. Surveillez automatiquement la page de statut du fournisseur. De plus, collectez le statut HTTP, la latence et le coût de chaque appel.
Quelques signaux méritent une alerte dédiée. Une latence au 95e percentile supérieure à l’attendu indique une dégradation avant l’erreur. Un taux de 429 croissant pointe une rate limit. Une séquence de 401 suggère un problème d’identifiant ou de connexion chez le fournisseur.
En attendant, maintenez un tableau de bord simple et honnête. Trois panneaux suffisent au début : disponibilité, latence et bascule activée. Ensuite, évoluez selon les exigences opérationnelles.
Checklist pour la prochaine madrugada de instabilidade
En résumé, traitez l’IA comme toute dépendance externe critique. Elle chutera de nouveau, et probablement au pire moment.
Passez ce checklist dès cette semaine. Premièrement, définissez un timeout par appel. Deuxièmement, configurez le retry avec backoff, jitter et plafond de tentatives. Troisièmement, installez un disjoncteur côté client. Quatrièmement, isolez le pool de connexions de l’IA. Cinquièmement, écrivez le chemin dégradé de l’interface. Sixièmement, homologuez un fournisseur de secours derrière une interface propre. Septièmement, créez la feature flag de désactivation. Huitièmement, surveillez le statut, la latence et l’erreur par type.
Aucun élément n’exige une refonte héroïque. Toutefois, pris ensemble, ils modifient le déroulement de la prochaine virée nocturne. La prochaine fois que ChatGPT tombera, votre application restera debout.
Suivez notre profil sur Instagram !
