Que faire quand ChatGPT tombe - le playbook du développeur

ChatGPT est down. Twitter est une galerie d’écrans d’erreur. Votre pull request attend toujours. La panne n’est pas le sujet. Le sujet : vous vous figez, ou vous continuez à livrer.

OpenAI s’est éteint en 2023, 2024, 2025 et 2026. Claude, Gemini et Copilot aussi, les jours plus discrets. La question utile n’est pas « est-ce que ça va se reproduire ». C’est : dans l’heure qui vient, qu’est-ce qui est vraiment bloqué - et qu’est-ce qui ne l’est que parce que l’onglet de chat renvoie un 500.

Ne mélangez pas deux incidents. Vous avez perdu un copilote. Ou les appels OpenAI de votre produit renvoient 500. Le premier est un problème de workflow. Le second est un incident. Ce sont deux pièces différentes.

1. Les cinq premières minutes : est-ce vraiment down ?

Rafraîchir n’est pas un diagnostic. Avant d’ouvrir trois autres chats et un fil sur « la fin de l’IA », prenez cinq minutes pour nommer la panne.

• Vérifiez status.openai.com, puis status.anthropic.com et le statut Google AI si vous les utilisez déjà. Downdetector, c’est l’humeur. La page de statut du vendeur, c’est un signal.
• ChatGPT le site n’est pas l’API, et ni l’un ni l’autre n’est Cursor. chatgpt.com peut être mort pendant que gpt-4o dans un éditeur, ou Claude dans le même éditeur, répond encore. Nommez la surface : app web, API, Copilot, sélecteur de modèle dans Cursor.
• Éliminez votre côté : VPN, DNS, proxy d’entreprise, bloqueur de pubs, session périmée. Les limites de l’offre gratuite ressemblent à une panne si vous collez le même fichier depuis une heure.
• Si la page de statut du vendeur est rouge pour votre région, arrêtez de rafraîchir quarante fois. Vous ne le ferez pas revenir par la volonté. Changez de surface ou changez de tâche.

2. Remplacez le chat, pas tout le cerveau

À 14 h, vous n’avez pas besoin d’une nouvelle philosophie du travail. Vous avez besoin d’un autre modèle qui finisse le ticket. Connectez-vous à une alternative et continuez la même tâche. Ne migrez pas votre « stack » au milieu d’une panne.

• Claude (Anthropic) : souvent plus solide sur les longs diffs et les refactors soigneux. Si vous avez déjà l’onglet, c’est la première porte.
• Gemini / Google AI Studio : utile quand il faut un second avis ou un modèle qui a encore du quota. Pas une religion. Une batterie de secours.
• Cursor, Claude Code, Copilot, Windsurf : si l’IDE a déjà un autre modèle branché, changez le sélecteur avant d’ouvrir un chat dans le navigateur. Le contexte du dépôt est déjà là. C’est tout l’intérêt d’un éditeur agentique.
• La recherche dans la doc, les issues GitHub et le changelog officiel battent une API hallucinée quand la question est « est-ce que Next.js a renommé ça ». Un LLM est un junior rapide. Le changelog est la source.

3. Modèles locaux : quand ils sauvent l’après-midi

Ollama, LM Studio, llama.cpp : un modèle sur votre portable se fiche que chatgpt.com renvoie 500. Il ignore aussi la release Next.js de la semaine dernière. Servez-vous-en pour les bons jobs.

• Bon : finir une fonction à partir du contexte collé, expliquer une stack trace, réécrire une regex, rédiger un message de commit, transformer des notes en nom de test.
• Mauvais : l’architecture d’un dépôt que le modèle n’a jamais vu ; « c’est quoi l’API App Router actuelle » ; tout ce qui doit coller à la doc de ce mois-ci.
• Si vous n’avez jamais tiré de modèle local, une panne est un mauvais moment pour commencer. Faites-le un vendredi calme : installez Ollama, tirez un modèle instruct 7B ou 14B, lancez un vrai prompt de votre boulot. Trente minutes, une fois.

4. Le travail qui n’a jamais eu besoin de ChatGPT

La stack trace est toujours là. Le test en échec est toujours rouge. Git a toujours blame. Une panne rappelle brutalement que le modèle n’a jamais été la source de vérité - c’était une façon rapide de lui parler.

• Lisez l’erreur. Pas le vibe de l’erreur : le fichier, la ligne, le message. Puis ouvrez ce fichier.
• git blame, git log -p, les trois dernières PR sur ce chemin. La plupart des bugs « mystérieux » datent de mardi dernier.
• La doc officielle, MDN, le changelog de la lib, une reproduction minimale. Plus lent qu’un chat. Moins de fiction.
• Le debugger, un test rouge, un console.log que vous effacerez. Canard en plastique : écrivez le problème dans un commentaire. Souvent la réponse arrive avant la fin de la phrase.
• Si vous ne pouvez pas faire un seul pas sans chat, la tâche était sous-spécifiée - ou vous avez externalisé la pensée. C’est une information utile. Ce n’est pas un défaut de caractère. D’abord la spec, ensuite le code.

5. Si le produit appelle l’API OpenAI

Ce n’est pas « je vais coller dans Claude pendant une heure ». C’est de la réponse à incident. Les utilisateurs préfèrent « l’assistant est temporairement indisponible » à un spinner qui ne finit jamais.

• Nommez la panne : votre clé, votre quota, votre timeout, ou leurs 5xx. Le dashboard et la page de statut sont plus souvent en désaccord que vous ne le voudriez. Loggez le code de statut, pas seulement « l’IA est cassée ».
• Si un second fournisseur est déjà branché, basculez. J’ai déjà écrit comment un LLM se place derrière une étape payante et ce qu’est vraiment un provider. Une panne est un mauvais moment pour concevoir ça. C’est un bon moment pour basculer un flag préparé.
• Dégradez : mettez l’écriture en file, répondez depuis vos FAQ, affichez une phrase humaine. Pas de tempête de retries. Backoff. Un chatbot qui frappe une API mourante allonge l’incident pour tout le monde, vous compris.

6. Un kit à monter avant la prochaine panne

Trente minutes de setup un jour calme battent trois heures à rafraîchir Twitter. Vous le savez déjà. La panne, c’est juste la facture.

• Un second chat déjà connecté : Claude ou Gemini, avec un billing qui tient un après-midi chargé. Un onglet gratuit pas ouvert depuis mars n’est pas un plan.
• L’IDE avec au moins deux modèles dans le sélecteur. Si Cursor n’a que OpenAI, vous avez acheté un single point of failure et vous l’avez appelé workflow.
• Un modèle instruct local déjà tiré. Pas « un jour j’essaierai Ollama ». Déjà tiré.
• Un fichier de notes pour les one-liners que vous demandez toujours au chat : git, docker, kubectl, ce jq que vous n’arrivez jamais à retenir. Quand le chat est mort, les notes marchent encore hors ligne.
• Pour le produit : un flag de fallback, un backoff, et une phrase pour l’UI écrite à l’avance. Les incidents vont plus vite quand on n’invente pas le texte dans Slack.

7. La leçon que personne n’aime

ChatGPT est un junior rapide qui a lu Internet et aucun de vos incidents de production. Quand ce junior est en congé, le senior doit quand même livrer. J’utilise des agents tous les jours. Je dois quand même lire le diff, lancer les tests, et savoir où est la doc.

Les pannes continueront. Les modèles continueront de changer de nom. La compétence qui survit, c’est toujours : spécifier le résultat, déboguer la panne, assumer le merge. J’ai déjà écrit comment le vibe coding multiplie la discipline que vous avez - et comment un prompt flou livre le bazar plus vite. Un après-midi sans ChatGPT, c’est le même examen, non payé.

Conclusion : continuer à livrer, garder une réserve

Vérifiez la page de statut. Nommez la surface. Changez de modèle ou changez de tâche. Si l’API est le produit, dégradez-la : ne faites pas semblant que le spinner est une fonctionnalité. Puis, un jour calme, branchez la réserve : un second chat, un second modèle dans l’éditeur, un pull local, un flag de fallback.

Et une fois par mois, fermez le chat et finissez quand même le ticket. Pas par nostalgie. Pour que la prochaine panne soit un désagrément, pas un blocker. :)