Le 3 septembre 2026, vers 17h heure de Paris, ChatGPT s'est arrêté de répondre. Pages blanches, erreurs 404, champ de saisie mort. En trente minutes, les signalements sur Downdetector sont passés de 5 000 à plus de 74 000. Le même jour, Claude était déjà tombé une heure et demie plus tôt. Et Gemini et Grok commençaient à toussoter.
Traduction concrète pour vous : ce jour-là, si votre production reposait sur un seul assistant IA, vous étiez à l'arrêt. Pas cinq minutes. Plusieurs heures.
Ce n'est pas un accident isolé. C'est un motif qui se répète. Et la bonne nouvelle, c'est qu'un plan de secours se monte en une après-midi. Voilà comment.
Un outil IA n'est pas une infrastructure fiable à 100 %
Beaucoup de dirigeants raisonnent comme si ChatGPT était aussi stable que leur boîte mail. C'est faux. Les chiffres sont brutaux.
- Sur les 90 derniers jours, ChatGPT a connu 57 incidents, avec une durée médiane de 2h44.
- Depuis octobre 2025, ce sont 193 incidents recensés.
- Le 10 juin 2025, une panne a duré plus de 10 heures avant retour à la normale.
- En juillet 2026, la génération d'images d'OpenAI est restée indisponible une journée entière pour une large part des utilisateurs.
Et l'incident du 3 septembre a montré autre chose de plus gênant : la panne ne touchait pas que le chat. Connexions, envoi de fichiers, mode vocal, recherche, recherche approfondie, génération d'images. Tout est tombé en même temps.
Le double incident Anthropic plus OpenAI n'est pas une exception. Le 20 avril 2026 déjà, ChatGPT, Gemini, Copilot et Claude avaient lâché ensemble. Quand un fourniseur tombe, les autres se retrouvent surchargés par le report de trafic. L'effet domino est réel.
Votre abonnement payant ne vous protège pas
C'est le piège dans lequel tombent la plupart des dirigeants. "Je paie ChatGPT Plus ou Team, donc j'ai une garantie." Non.
Le SLA de 99,9 % d'OpenAI s'applique uniquement aux clients Scale Tier et Enterprise, avec un contrat négocié. Tout le reste n'a aucune garantie contractuelle d'uptime : le pay-as-you-go API, ChatGPT Free, ChatGPT Plus et ChatGPT Team inclus. Vous payez, mais vous n'avez droit à rien si ça tombe.
Et même quand un SLA existe, il est plus étroit qu'on ne le croit. Le SLA d'Azure OpenAI ne répond qu'à une question : le service a-t-il renvoyé une réponse. Un modèle qui vous crache des erreurs 429 "trop de requêtes" sur presque tous vos appels compte quand même comme "disponible" dans leur métrique. La qualité de la sortie et la rapidité ne sont pas couvertes.
Quant aux compensations : sous 99,9 % d'uptime mensuel, vous touchez 10 % de crédit sur la facture du service affecté. Rien n'est dû tant que la coupure n'a pas dépassé 43 minutes sur le mois. Et ce crédit n'est jamais versé en argent. Jamais. Comparez ça au coût réel d'une demi-journée où votre équipe tourne en rond.
La continuité, c'est votre responsabilité, pas celle du fournisseur. Point.
Le plan de secours en 4 étapes
Objectif : pouvoir basculer en 5 minutes le jour d'une panne, sans casser votre production. Voici la méthode.
Étape 1 : lister vos usages IA vraiment critiques
Ne cherchez pas à tout sécuriser. La plupart de vos usages IA supportent très bien d'attendre deux heures. Ce qui compte, c'est d'isoler ceux qui ne peuvent pas attendre.
Prenez une feuille et posez trois colonnes : la tâche, la fréquence, l'impact si elle est bloquée pendant 3 heures. Exemples de tâches à surveiller :
- Rédaction de réponses au support client en temps réel.
- Génération de devis ou de propositions commerciales attendus dans la journée.
- Traduction ou reformulation avant un envoi client urgent.
- Tout workflow automatisé qui appelle une API IA et qui alimente une chaîne derrière (facturation, relances, publication).
Vous obtenez en général 2 ou 3 usages critiques. C'est eux, et eux seuls, qui justifient un plan de secours. Le reste peut attendre.
Étape 2 : ouvrir un compte de secours chez un concurrent
La règle est simple : ne dépendez jamais d'un seul fournisseur pour un usage critique. Si vous vivez sur ChatGPT, votre secours doit être Claude ou Gemini. Et inversement.
Le 3 septembre, quand ChatGPT et Claude étaient à terre en même temps, un seul chatbot majeur restait debout : Mistral AI. C'est aussi un argument pour choisir un plan B qui ne partage pas la même infrastructure que votre outil principal. Mistral a en plus l'avantage d'être français, ce qui simplifie la question de la confidentialité des données pour certains usages.
Concrètement, ouvrez dès aujourd'hui un compte gratuit ou payant chez au moins un concurrent. Testez-le sur vos vraies tâches, pas en démo. Vérifiez que la qualité de sortie vous convient avant d'en avoir besoin. Le jour de la panne, ce n'est pas le moment de découvrir l'outil.
Si vous hésitez sur le calcul entre deux outils, l'article Gemini 3.7 Flash divise ses prix par deux : le calcul avant de basculer vous donne une grille de décision réutilisable.
Étape 3 : documenter vos prompts réutilisables
Voilà le point que presque personne ne prépare, et qui fait la différence le jour J. Vos meilleurs prompts sont enfermés dans l'historique de votre outil principal. Si cet outil tombe, vous perdez l'accès à vos prompts en même temps que vous perdez l'outil.
La solution : sortez vos prompts critiques de l'outil et rangez-les dans un document neutre, accessible en permanence. Un fichier partagé, une note, peu importe, du moment que c'est hors de l'outil IA.
Pour chaque usage critique identifié à l'étape 1, notez :
- Le prompt exact qui marche, avec son contexte et ses consignes.
- La version adaptée pour votre outil de secours, car les formulations qui marchent sur ChatGPT ne donnent pas toujours le même résultat sur Claude ou Gemini.
- Un exemple de sortie correcte, pour vérifier vite que le secours produit du bon travail.
Attention à un détail qui casse tout : le réglage de température change la fiabilité des réponses d'un outil à l'autre. Si vous voulez comprendre pourquoi un même prompt donne des résultats instables ailleurs, lisez Température IA : le réglage caché qui fiabilise (ou casse) vos réponses.
Étape 4 : écrire la procédure de bascule
Un plan de secours qui vit dans votre tête ne sert à rien le jour où vous êtes en rendez-vous et que c'est votre assistant qui découvre la panne. Écrivez la procédure. Une demi-page suffit.
Elle doit répondre à trois questions :
- Comment on sait que c'est une panne fournisseur et pas notre connexion ? Réponse : on vérifie Downdetector et la page de statut officielle de l'outil. Deux minutes.
- Qui décide de basculer et vers quoi ? Nommez la personne et l'outil de secours. Pas de débat le jour J.
- Où sont les prompts de secours ? Le lien direct vers votre document de l'étape 3.
Faites un test à blanc une fois. Simulez une panne un matin creux, basculez toute l'équipe sur l'outil de secours pendant une heure. Vous verrez tout de suite ce qui coince. Mieux vaut le découvrir un mardi tranquille qu'un jour de rush.
Le réflexe à garder au-delà du plan
Un plan de secours, c'est bien. Mais le fond du problème est ailleurs : plus votre production dépend d'un outil unique, plus votre risque est concentré. Vos utilisateurs sont habitués aux "quatre neuf" de leurs services quotidiens. L'IA générative tourne, elle, autour de 99 % à 99,9 % au mieux. Ça fait potentiellement plusieurs jours cumulés d'indisponibilité par an.
Traitez donc l'IA comme une dépendance d'infrastructure critique, au même titre que votre connexion internet ou votre logiciel de facturation. Vous avez sûrement déjà un plan si votre box tombe. Faites pareil pour vos assistants IA.
Et gardez un principe simple : pour chaque automatisation que vous branchez sur une API IA, demandez-vous ce qu'il se passe si le fournisseur renvoie une erreur pendant trois heures. Si la réponse est "toute la chaîne s'arrête", vous avez un point de fragilité à traiter.
Concrètement, avant la fin de la semaine : listez vos 2 ou 3 usages critiques, ouvrez un compte de secours chez un concurrent, sortez vos prompts de l'outil principal et écrivez une demi-page de procédure. Une après-midi de travail. La prochaine coupure viendra. Vous, vous continuerez à tourner.
