- ▸ Le café du matin, la requête qui ne part pas
- ▸ La thèse : la fiabilité n'est plus un détail technique
- ▸ D'un outil expérimental à un service infrastructurel
- ▸ Analyse technique : diagnostiquer en cinq minutes
Depuis octobre 2025, OpenAI dénombre plus de quatre-vingt-dix ruptures de service sur son portail public. La plateforme traite 2,5 millions de requêtes par jour, concentrées sur deux pics quotidiens en heures ouvrées. Quand l’interruption coïncide avec ces fenêtres, le coût d’opportunité devient mesurable et tangible. Diagnostic en cinq minutes, contournements éprouvés, conditions structurelles : ce dossier cartographie ce que la fiabilité de ChatGPT dit aujourd’hui du risque opérationnel.
Points clés 1. Plus de 90 incidents recensés sur status.openai.com depuis octobre 2025, soit en moyenne un événement perceptible tous les deux à trois jours. 2. La plateforme traite 2,5 millions de requêtes par jour, concentrées sur deux créneaux : 9h-12h et 14h-17h, heure de Paris. 3. Avec 500 millions d’utilisateurs hebdomadaires, la dépendance à un service unique entre dans le champ du risque opérationnel mesurable. 4. Un débit descendant inférieur à 1 Mbps ou un ping supérieur à 200 ms dégradent la qualité de service avant tout incident côté serveur. 5. Le basculement sur réseau mobile 4G ou 5G constitue le contournement le plus rapide en cas de défaillance de la connexion fixe.
Le café du matin, la requête qui ne part pas
Il est 10h12, mardi. Une consultante relit son brief en cours et lance une dernière instruction à ChatGPT. La requête reste suspendue. Trente secondes plus tard, un message s’affiche : « service unavailable ». Aucune précision, aucun délai de rétablissement annoncé. Le navigateur est relancé, l’historique vidé. Rien ne bouge.
La scène se rejoue tous les jours dans des dizaines de milliers d’organisations, à des heures dont la régularité n’est pas une coïncidence statistique. Selon les données publiées par OpenAI, la plateforme connaît ses sollicitations les plus fortes entre 9h et 12h, puis entre 14h et 17h, heure de Paris. Ce sont les mêmes plages où s’exécutent les tâches à haute valeur — synthèses, brouillons, comparaisons documentaires, mises au propre de code.
Quand le service tombe à ces heures-là, l’impact dépasse l’inconfort. Il devient économique. Cette concomitance, ignorée tant que tout fonctionne, devient un point d’analyse central dès qu’on cherche à mesurer la résilience réelle d’un outil devenu infrastructurel pour des chaînes de production entières.
La thèse : la fiabilité n’est plus un détail technique
Plus de quatre-vingt-dix incidents en sept mois sur un service utilisé chaque semaine par 500 millions de personnes : la statistique change de nature. Elle cesse de relever du service client pour entrer dans le champ du risque opérationnel.
Tant que la plateforme était un outil exploratoire, une panne signifiait une pause. Devenue maillon d’une chaîne de production — éditoriale, juridique, technique —, le même incident provoque une rupture qu’il faut documenter, contourner, parfois facturer auprès d’un client. Ce dossier examine la mécanique du diagnostic, les contournements éprouvés, et ce que la régularité des incidents révèle des choix d’infrastructure et de dépendance qui sous-tendent l’usage quotidien.
D’un outil expérimental à un service infrastructurel
Le statut de ChatGPT a basculé bien avant que la communauté technique ne l’admette explicitement. Lorsque la plateforme franchit le seuil des 500 millions d’utilisateurs hebdomadaires, elle entre dans une catégorie réservée à un très petit nombre de services numériques mondiaux. Cette base d’usage la place, en ordre de grandeur, dans le voisinage des principales plateformes sociales et de messagerie occidentales — et change profondément les attentes de fiabilité associées.
Cette bascule n’a pas été accompagnée d’une refonte explicite des engagements de service grand public. Le portail status.openai.com publie les incidents au fil de l’eau, mais ne contractualise pas, pour l’utilisateur standard, un niveau de service garanti. La régularité observée — plus de 90 incidents publiés depuis octobre 2025 — équivaut à un événement perceptible tous les deux à trois jours en moyenne. Aucun de ces événements n’est, pris isolément, une défaillance majeure. Cumulés, ils dessinent une signature : celle d’une plateforme qui gère sa croissance par incidents successifs plutôt que par stabilisation préalable.
Les sept derniers mois marquent ainsi une période charnière. Avant octobre 2025, le service restait perçu comme un outil avec son cortège de pannes acceptables. Depuis, les usages se sont structurés : intégrations dans des chaînes éditoriales, instructions répétables, automatisations partielles. Chaque incident vient désormais heurter une chaîne, pas un usage isolé. La même panne, à la même heure, ne produit plus la même conséquence aujourd’hui qu’il y a deux ans.
À cette mutation structurelle s’ajoute l’effet du volume. 2,5 millions de requêtes par jour ne se distribuent pas uniformément : la concentration entre 9h-12h et 14h-17h, observée sur le périmètre parisien, suggère une charge inégale partagée entre les zones géographiques actives. Quand un incident frappe sur l’un de ces pics, l’effet ressenti dépasse largement la moyenne quotidienne. Une heure de panne en plein milieu de la journée n’a pas le poids d’une heure de panne au cœur de la nuit.
Analyse technique : diagnostiquer en cinq minutes
Avant toute manipulation, la première étape consiste à isoler la cause. Trois sources possibles existent : panne côté OpenAI, problème de connectivité, configuration locale du navigateur. La séquence de vérification doit suivre cet ordre, car elle reflète la probabilité décroissante des causes en heures de pic.
Étape 1 — Statut OpenAI. L’accès à status.openai.com fournit l’information autoritaire. Un bandeau coloré y indique tout incident en cours sur les composants concernés (API, ChatGPT, vision, etc.). Quand l’incident est confirmé, aucune action locale ne le résoudra. L’attente est la seule réponse rationnelle. La page documente également l’historique des incidents — c’est cet historique cumulé qui permet de reconstituer le décompte des quatre-vingt-dix événements et plus depuis octobre 2025.
Étape 2 — Connectivité locale. Si le statut OpenAI est vert mais le service reste inaccessible, le diagnostic se déplace vers le réseau. Deux seuils techniques structurent l’expérience utilisateur : un débit descendant minimal de 1 Mbps et un temps de latence inférieur à 200 ms. Sous ces seuils, l’interface peut sembler fonctionner sans rendre de réponse, ou rendre des réponses tronquées. Un test rapide (mesure de débit, ping vers une IP de référence) tranche la question. Le basculement vers les données mobiles 4G ou 5G constitue le contournement le plus immédiat ; il isole le problème éventuel du réseau filaire local.
Étape 3 — État du navigateur. Si le réseau est sain et le statut OpenAI vert, la cause se trouve souvent dans l’état du navigateur. Le nettoyage du cache et des cookies de la session se fait via le menu « Confidentialité et sécurité », puis « Effacer les données de navigation ». Cocher « Images et fichiers en cache » ainsi que « Cookies et autres données des sites », sélectionner la plage « Toutes les périodes », et valider « Effacer les données » résout une part significative des cas de blocage persistant. Le même résultat s’obtient par « Effacer l’historique » sur certains navigateurs.
Le tableau ci-dessous synthétise la séquence diagnostique :
| Étape | Indicateur observé | Action recommandée | Temps moyen |
|---|---|---|---|
| 1. Statut serveur | status.openai.com — bandeau coloré | Patienter, basculer sur outil tiers | < 1 min |
| 2. Connectivité | Débit < 1 Mbps ou ping > 200 ms | Bascule 4G/5G ou redémarrage routeur | 1-3 min |
| 3. Navigateur | Statut vert + réseau sain + erreur | Effacer cache + cookies, plage totale | 2-3 min |
Cette grille appelle deux remarques. Elle hiérarchise d’abord les causes par fréquence statistique : sur la fenêtre 9h-12h et 14h-17h, les incidents serveur dominent ; en dehors de ces fenêtres, la connectivité ou le navigateur reprennent la première place. Elle suggère, ensuite, un seuil de bascule simple : si après cinq minutes la séquence n’a pas levé le blocage, le coût d’opportunité d’une recherche supplémentaire dépasse celui d’un contournement par un service tiers. Cette règle de cinq minutes mérite d’être documentée dans les procédures internes des organisations qui ont fait de l’outil un poste de production.
Le seuil de 1 Mbps mérite un commentaire supplémentaire. Une fibre française médiane offre des débits qui en sont plusieurs centaines de fois supérieurs. Pourtant, le seuil compte : dans des conditions dégradées (Wi-Fi saturé, partage de connexion, déplacement en zone à faible couverture), il peut être atteint sans qu’on s’en rende compte. La latence est plus sensible encore : un ping de 200 ms se rencontre dès qu’on s’éloigne géographiquement des centres de données ou que le réseau introduit des sauts supplémentaires. Cette sensibilité explique pourquoi la 5G en situation professionnelle sort souvent gagnante du basculement.
L’impact terrain : ce que coûte une heure de panne
Le coût ressenti d’une panne varie selon le profil d’usage. Pour une exploration ponctuelle, l’incident est une contrariété. Pour un usage intégré à une chaîne de production, il devient un blocage chiffrable.
La structure des pics quotidiens en éclaire la portée. Les fenêtres 9h-12h et 14h-17h, heure de Paris, correspondent exactement aux heures de production des organisations européennes. Une panne à 10h30 frappe simultanément le travail de rédaction, la préparation de présentation, la mise au propre de code, la synthèse de réunion. Sur un effectif de plusieurs centaines de collaborateurs partageant l’outil, une interruption d’une heure se traduit en heures-collaborateur perdues sans équivalent immédiat. C’est cette équation, plutôt que la fréquence brute des incidents, qui justifie la mise en place d’un plan de continuité.
L’effet est amplifié par la concentration des usages. Lorsque la plateforme est sollicitée 2,5 millions de fois par jour, une part substantielle de ces sollicitations émane d’utilisateurs professionnels en situation d’attente synchrone : la réponse est attendue dans la minute pour pouvoir continuer une tâche. À la différence d’un envoi de courriel différé, cette attente n’a pas de tampon implicite. La latence se transforme directement en temps mort.
Les organisations matures ont commencé à documenter cette exposition. Les premiers réflexes observés relèvent de trois niveaux. Le premier, individuel : tenir prête une procédure de basculement (4G/5G, navigateur secondaire, contournement par cache). Le deuxième, d’équipe : disposer d’au moins un service alternatif maîtrisé pour les tâches critiques. Le troisième, organisationnel : tenir un registre des incidents et de leur impact, ne serait-ce que pour arbitrer la dépendance contractuelle aux moments du renouvellement.
La nature des tâches les plus impactées dessine une géographie. Les fonctions à forte composante rédactionnelle — communication, marketing, support — sont les plus directement exposées car l’usage y est synchrone. Les fonctions à composante analytique — études, finance, juridique — supportent mieux les latences car le travail s’y accommode d’un report. Cette distinction utile rappelle qu’une stratégie de continuité IA n’a pas la même forme dans tous les services d’une même entreprise.
Reste enfin la question, plus discrète, de la confiance utilisateur. Une organisation qui présente comme « propulsé par IA » un service public-facing prend le risque d’un incident visible à chaque panne d’OpenAI. Le portage de ce risque sur la perception client n’a pas encore fait l’objet d’évaluation publique consolidée. Mais le seul cumul de quatre-vingt-dix incidents et plus en sept mois suggère qu’il devient impossible de l’ignorer dans la conception d’un service exposé.
Perspectives contradictoires : ce qu’on peut opposer au tableau
Il serait excessif, à la lecture des chiffres, d’en tirer un verdict de fragilité. Plusieurs arguments invitent à nuancer.
Premier argument : la base d’usage. 500 millions d’utilisateurs hebdomadaires, 2,5 millions de requêtes quotidiennes — ces volumes appartiennent à une catégorie où aucun service informatique ne tient un taux de disponibilité parfait sans interruption visible. Rapporté à d’autres services à grande échelle, le rythme de quatre-vingt-dix incidents en sept mois ne sort pas nécessairement du cadre observé. La question, pour les utilisateurs, n’est pas tant la fréquence brute que la corrélation avec leurs propres heures de pic — dont les données existantes confirment qu’elles coïncident souvent.
Deuxième argument : la transparence. Le maintien public d’une page status.openai.com, mise à jour en temps quasi-réel, est en soi un engagement éditorial. Tous les acteurs comparables n’offrent pas cette traçabilité. Le décompte des quatre-vingt-dix incidents et plus n’aurait pas été possible sans cet historique : la donnée elle-même est un signe de sérieux opérationnel, pas son contraire. Sa publication continue donne aux utilisateurs avancés une matière de pilotage que d’autres plateformes ne leur fournissent pas.
Troisième argument : l’effet de signalement. Avec 500 millions d’utilisateurs hebdomadaires, un incident même bref génère un afflux de signalements qui en amplifie la perception. Des plateformes de remontée tierces ajoutent à l’écho. Une part des « incidents » comptabilisés peut relever de dégradations partielles, géographiquement bornées ou rapidement résolues. La granularité du compte mérite donc d’être interrogée avant toute conclusion catastrophiste.
Reste qu’aucune de ces nuances n’invalide la nécessité d’un plan de secours. La question utile n’est pas « ChatGPT est-il fiable » mais « quel niveau de dépendance est acceptable ». Cette reformulation déplace le débat du jugement de qualité vers la conception d’architecture — qui est la bonne échelle de raisonnement pour une organisation.
Prospective : vers une architecture distribuée
Le prochain horizon n’est pas celui d’une disponibilité parfaite. Il est celui d’une architecture multi-modèles où la défaillance d’un service est anticipée par la conception.
Trois tendances paraissent se dessiner à la lecture des chiffres disponibles. D’abord, la standardisation des procédures de bascule au niveau utilisateur : la séquence en cinq minutes documentée plus haut a vocation à entrer dans les supports internes des directions des systèmes d’information. Ensuite, l’émergence d’usages multi-fournisseurs : plutôt que de s’engager sur un service unique, des équipes commencent à répartir leurs tâches entre plusieurs interfaces pour lisser le risque. Enfin, la pression pour des engagements de service formalisés. Le seuil des 500 millions d’utilisateurs hebdomadaires, croisé avec le rythme observé d’incidents, devrait précipiter l’apparition d’offres adossées à des indicateurs contractuels lisibles.
La question ouverte reste celle du seuil collectif. À quel point de dépendance les utilisateurs cesseront-ils d’accepter qu’un service de ce volume publie des incidents tous les deux ou trois jours ? La réponse ne sera pas seulement technique. Elle sera économique, et elle se lira dans les conditions de renouvellement des abonnements à mesure que la maturité des usages s’affirme.
FAQ
Comment savoir si la panne vient de ChatGPT ou de ma connexion ?
La page status.openai.com tranche la question en moins d’une minute. Un bandeau coloré y indique tout incident en cours. Si le statut est vert et que le service reste inaccessible, le diagnostic se déplace vers la connectivité locale : un débit inférieur à 1 Mbps ou un ping supérieur à 200 ms suffisent à dégrader l’usage sans qu’un incident côté serveur ne soit déclaré.
Que faire concrètement en cas de panne en pleine journée ?
La séquence éprouvée enchaîne trois actions. Vérifier status.openai.com pour exclure un incident côté serveur. Basculer sur les données mobiles 4G ou 5G pour neutraliser un problème de connexion fixe. Effacer le cache et les cookies du navigateur via « Confidentialité et sécurité » puis « Effacer les données de navigation », plage « Toutes les périodes ». Si après cinq minutes le service reste indisponible, recourir à un outil alternatif maîtrisé.
Faut-il prévoir un plan B même quand le service fonctionne bien ?
Le calcul est statistique. Avec quatre-vingt-dix incidents recensés en sept mois et une utilisation hebdomadaire par 500 millions de personnes, l’événement reste relativement rare à l’échelle individuelle. Mais dès qu’un usage devient répétable et intégré à une chaîne professionnelle, la probabilité d’être confronté à une panne en heure de pic — 9h-12h ou 14h-17h, heure de Paris — justifie de documenter une procédure de continuité.
Le basculement vers la 4G règle-t-il toujours le problème ?
Pas systématiquement. Le basculement neutralise les causes liées à la connexion fixe (routeur, saturation Wi-Fi, congestion locale). Il reste inopérant si l’incident vient des serveurs d’OpenAI, ce qu’indique le statut officiel. La 5G, lorsqu’elle est disponible, restitue généralement une latence inférieure à la 4G — un atout face au seuil de 200 ms évoqué dans la section technique.
Sources
- OpenAI, page de statut officielle — historique des incidents publiés depuis octobre 2025.
- « ChatGPT ne marche plus — Solutions et alternatives », mission-open-data.fr, 10 avril 2026.
