Trois fournisseurs d'IA, une fenêtre de cinq heures
ChatGPT, Claude et Grok sont tous tombés en panne dans la même fenêtre de cinq heures environ le 3 septembre 2026, une coïncidence assez rare pour attirer à elle seule l'attention des journalistes en quelques heures. La page de statut d'OpenAI a attribué sa panne à une erreur de routage débutée vers 7h43 PT, avec un correctif mis en œuvre et surveillé à partir d'environ 8h17 PT, et le problème d'erreurs élevées sur ChatGPT et Codex résolu en début d'après-midi.
La page de statut d'Anthropic a enregistré une panne partielle débutée vers 9h40-9h41 ET, touchant Claude.ai, l'API Claude, Claude Code et Claude Cowork, tous les modèles cités redevenant opérationnels vers 12h16-12h27 ET. Grok, de xAI, était en panne sur le web, l'application X, iOS, Android et deux régions d'API américaines de 9h30 environ jusqu'à 13h07 ET, xAI citant un problème dans son centre de calcul de Memphis, dans le Tennessee.
Ce que chaque entreprise a dit en être la cause
OpenAI, Anthropic et xAI ont chacune désigné une cause technique distincte et sans lien pour leur propre panne, et non une seule défaillance partagée par les trois. La cause d'OpenAI était une erreur de routage à l'intérieur de ses propres systèmes, et certains utilisateurs du contrôle à distance de Codex ont dû rejumeler leur appareil mobile une fois le service rétabli.
Anthropic n'a pas publié de cause racine détaillée, se limitant à décrire un problème d'infrastructure ayant touché plusieurs modèles avant la résolution, dont Fable/Mythos 5.1, Fable/Mythos 5, Opus 5, Opus 4.8 et Opus 4.6. xAI a été la plus précise des trois, désignant un problème dans son propre centre de calcul de Memphis, dans le Tennessee, plutôt qu'une couche cloud partagée.
La question posée par les journalistes : Azure est-il le lien commun ?
Des journalistes de The Register, 9to5Google et Decrypt ont demandé si Microsoft Azure était le lien commun derrière les trois pannes, car OpenAI, Anthropic et xAI s'appuient chacune, entre autres fournisseurs, sur Azure, et Microsoft a déclaré qu'Azure n'était pas la cause lorsqu'on l'a interrogé directement. Ce démenti, combiné à trois causes signalées séparément, signifie que les pannes du 3 septembre n'ont pas de cause racine commune confirmée, seulement une question ouverte que les journalistes ont soulevée et que Microsoft a rejetée.
Gemini, de Google, n'a signalé aucun incident pendant la même fenêtre, ce qui est en soi instructif : quoi qu'il ait aligné ChatGPT, Claude et Grok, cela n'a pas touché tous les grands fournisseurs d'IA en activité ce jour-là. Ce détail pointe soit vers une coïncidence, soit vers une dépendance commune plus restreinte qui n'a pas été nommée publiquement.
Pourquoi 'plusieurs fournisseurs d'IA' n'est pas automatiquement une stratégie de résilience
Utiliser ChatGPT à côté de Claude ou de Grok n'achète pas automatiquement de résilience d'infrastructure à une entreprise, car la diversité de fournisseurs au niveau de la marque d'IA peut toujours reposer sur des dépendances cloud partagées en dessous. Depuis deux ans, les entreprises et les organismes publics de l'UE reçoivent le conseil de répartir leurs charges de travail entre plusieurs fournisseurs d'IA pour se protéger du verrouillage fournisseur et du risque de panne, une idée qui touche aussi le règlement sur la résilience opérationnelle numérique (DORA) et les obligations NIS2 relatives au risque de concentration chez les tiers TIC.
L'événement du 3 septembre en est un test concret et daté. OpenAI, Anthropic et xAI ont signalé des causes distinctes cette fois, mais les trois s'appuient, entre autres fournisseurs, sur Microsoft Azure, et les pannes sont malgré tout tombées dans la même fenêtre de cinq heures, exactement le genre de simultanéité qu'un ensemble de fournisseurs réellement indépendants ne devrait pas produire de façon routinière.
| Fournisseur | Début de la panne | Fin de la panne | Cause déclarée |
|---|---|---|---|
| OpenAI (ChatGPT, Codex) | ~7h43 PT | Début d'après-midi PT | Erreur de routage |
| Anthropic (Claude) | ~9h40-9h41 ET | ~12h16-12h27 ET | Problème d'infrastructure non précisé |
| xAI (Grok) | ~9h30 ET | ~13h07 ET | Problème au centre de calcul de Memphis, Tennessee |
Ce qu'un registre de risque de concentration conforme à DORA devrait suivre
Un registre de risque de concentration TIC conforme à DORA devrait cartographier le risque au niveau de la couche cloud sous la marque de chaque fournisseur d'IA, et pas seulement au niveau du fournisseur d'IA lui-même. Lister OpenAI, Anthropic et un troisième fournisseur comme trois tiers TIC critiques indépendants peut sous-estimer le risque de concentration réel si deux ou trois d'entre eux tournent sur le même hyperscaler, en l'occurrence Azure, entre autres fournisseurs, pour les trois entreprises concernées le 3 septembre.
La démarche concrète pour une entreprise de services financiers ou un opérateur d'infrastructure critique consiste à demander à chaque fournisseur d'IA quels fournisseurs cloud et quelles régions se trouvent sous son service, puis à consigner cette réponse à côté du nom du fournisseur dans la carte de risque de concentration. Les régulateurs financiers de l'UE évaluant le risque des tiers TIC au titre de DORA et de NIS2 devraient précisément attendre ce niveau de détail, maintenant qu'un incident comme celui-ci a rendu la question publique.
À lire ensuite: La Garantie De Nvidia À OpenAI Est Tombée À 120 Milliards | Votre Fournisseur D'IA Vient De Recevoir Une Lettre De Bruxelles
