Le jeudi 3 septembre 2026, trois des principaux services d’intelligence artificielle générative ont rencontré des problèmes de disponibilité au cours de la même journée. OpenAI a signalé des erreurs élevées sur ChatGPT et Codex. Anthropic a constaté des erreurs sur plusieurs modèles Claude ainsi que sur Claude.ai, son API, Claude Code et Claude Cowork. Grok, le service de xAI désormais rattaché à SpaceX, a lui aussi connu une interruption. Pendant une partie de l’après-midi européen, ces incidents distincts se sont chevauchés.

L’image est spectaculaire : trois géants de l’IA perturbés presque simultanément. Elle appelle pourtant une lecture précise. Les informations disponibles ne démontrent pas une panne générale de l’intelligence artificielle ni la défaillance d’un fournisseur technique commun. Les descriptions rendues publiques diffèrent et ne permettent pas d’établir une cause unique. Ce que l’épisode révèle, en revanche, est très concret : une entreprise qui a transformé ces plateformes en composants de production peut perdre plusieurs solutions qu’elle croyait indépendantes dans une même fenêtre opérationnelle.

OpenAI : une mitigation appliquée en 34 minutes, puis surveillée pendant environ 1 h 38

Selon OpenAI, l’incident a commencé le jeudi 3 septembre à 7 h 43, heure du Pacifique, soit 14 h 43 UTC et 16 h 43 en Belgique. Une erreur de routage a rendu ChatGPT et Codex indisponibles pour une partie des utilisateurs sur plusieurs plateformes. Le terme est important : OpenAI n’a pas annoncé une extinction totale de tous ses services pour tous ses clients, mais une hausse d’erreurs et une indisponibilité affectant certains utilisateurs.

La première phase technique a été relativement courte. Un porte-parole d’OpenAI a indiqué qu’une solution avait été appliquée vers 8 h 17, heure du Pacifique, soit 15 h 17 UTC. Il s’est donc écoulé environ 34 minutes entre le début annoncé de l’erreur de routage et l’application de la mesure corrective. À ce moment-là, OpenAI n’a toutefois pas immédiatement fermé l’incident : l’entreprise est passée en phase de surveillance afin de vérifier la reprise.

La page d’état publique a finalement classé l’événement comme résolu à 18 h 55 CEST, l’heure d’été d’Europe centrale, soit 16 h 55 UTC. Si l’on mesure la durée administrative entre l’ouverture de l’investigation à 14 h 43 UTC et la clôture de l’incident à 16 h 55 UTC, on obtient environ 2 heures et 12 minutes. Cette durée ne signifie pas que chaque utilisateur est resté bloqué pendant tout ce temps. Elle comprend les 34 minutes précédant la mitigation, puis environ 1 heure et 38 minutes de reprise et de surveillance.

OpenAI a aussi signalé une conséquence spécifique : certains utilisateurs du contrôle à distance de Codex pouvaient devoir réappairer leur appareil mobile après l’incident. Il s’agit d’un exemple utile de l’effet secondaire que peut produire une panne, même après le retour du service principal. Une reprise technique ne garantit pas toujours que toutes les sessions, connexions ou automatisations retrouvent instantanément leur état antérieur.

Anthropic : près de trois heures d’impact sur plusieurs modèles et interfaces

L’incident Anthropic a commencé plus tôt. À 13 h 26 UTC, l’entreprise a annoncé enquêter sur une hausse d’erreurs affectant des requêtes adressées à plusieurs modèles Claude. À 13 h 41, Anthropic indiquait avoir identifié la cause, sans en publier le détail technique sur sa page d’état. Un porte-parole a ensuite décrit à The Register un « problème d’infrastructure » ayant provoqué une panne partielle.

À 13 h 50 UTC, Anthropic a élargi la liste des modèles concernés : Mythos et Fable 5.1, Mythos et Fable 5, Opus 5, Opus 4.8 et Opus 4.6. L’incident ne concernait pas uniquement l’interface conversationnelle. La page officielle précise qu’il a touché Claude.ai, l’API Claude, Claude Code et Claude Cowork. Pour une organisation, cette distinction est importante : lorsqu’une API et des outils intégrés sont atteints en même temps que le site web, les effets potentiels dépassent l’impossibilité de lancer une conversation manuelle.

Anthropic a continué à travailler sur le correctif pendant l’après-midi. À 15 h 25 UTC, la plupart des modèles étaient revenus à leur taux d’erreur habituel, mais Opus 4.8 et Opus 5 restaient affectés. Un correctif a été déployé à 16 h 06 UTC, puis l’entreprise a indiqué que l’impact avait pris fin à 16 h 16 UTC. La clôture officielle a été publiée sept minutes plus tard, à 16 h 23.

Entre la première alerte publique à 13 h 26 et la fin déclarée de l’impact à 16 h 16, il s’est écoulé environ 2 heures et 50 minutes. En prenant la publication finale à 16 h 23, le ticket est resté ouvert pendant 2 heures et 57 minutes. L’heure technique de début des erreurs n’est toutefois pas précisée. The Register évoque une panne de 3 heures et 6 minutes, un chiffre qui ne correspond pas exactement aux bornes actuellement affichées sur la page d’état d’Anthropic. Cette divergence renforce la nécessité de distinguer la durée technique, la durée d’impact et la durée administrative du ticket. Dans tous les cas, la reprise a été progressive : seuls deux modèles restaient encore affectés à 15 h 25.

Grok : un incident lié au centre de calcul de Memphis

Le troisième incident concernait Grok. La page d’état de xAI indiquait que l’entreprise avait commencé à examiner les problèmes vers 6 h 30, heure du Pacifique, soit 13 h 30 UTC. Le message initial restait général : Grok rencontrait des difficultés et les équipes travaillaient au rétablissement du service.

Plus tard dans la journée, SpaceX a présenté ses excuses pour les problèmes rencontrés et a attribué l’incident à une panne de son centre de calcul de Memphis. L’entreprise a également présenté ses excuses à des partenaires de calcul affectés, puis a indiqué que les systèmes avaient été restaurés et fonctionnaient normalement.

Il n’est pas possible, à partir des informations publiques accessibles, d’établir une heure de rétablissement aussi précise que pour OpenAI ou Anthropic. Le début de l’investigation, vers 13 h 30 UTC, est documenté ; l’heure exacte à laquelle l’impact a cessé ne l’est pas suffisamment pour calculer une durée fiable. Toute durée chiffrée plus précise pour Grok serait donc une estimation et non un fait confirmé.

Combien de temps les incidents se sont-ils chevauchés ?

Anthropic avait publié son alerte à 13 h 26 UTC lorsque xAI a commencé à enquêter vers 13 h 30. OpenAI a ensuite ouvert son incident à 14 h 43. Entre 14 h 43 et 15 h 17 UTC, les trois fournisseurs avaient donc simultanément des incidents publiquement ouverts ou rapportés, tandis qu’OpenAI n’avait pas encore appliqué sa mesure corrective et qu’Anthropic poursuivait ses travaux.

Cette fenêtre de 34 minutes documente avec certitude un chevauchement des signalements. Elle ne permet pas d’affirmer avec la même précision que chaque utilisateur des trois services a subi 34 minutes d’indisponibilité simultanée, faute d’heure publique exacte de rétablissement pour Grok. Elle ne doit pas non plus être confondue avec la durée complète de chacun des incidents : Anthropic a déclaré un impact jusqu’à 16 h 16 UTC et OpenAI a surveillé sa reprise jusqu’à 16 h 55.

Des causes publiées différentes, pas de panne commune démontrée

La simultanéité a immédiatement soulevé l’hypothèse d’une dépendance technique partagée. Les trois entreprises utilisent en effet de nombreux services d’infrastructure, de réseau et de sécurité. The Register a interrogé Cloudflare, utilisé à des degrés différents par les trois acteurs. Cloudflare a répondu que ses services fonctionnaient normalement et qu’aucune perturbation significative n’était en cours. Les pages d’état d’AWS, de Google Cloud et de Microsoft Azure ne montraient alors aucun incident pertinent, tout en sachant que ces tableaux publics peuvent publier certains problèmes avec retard.

Les explications publiées ne permettent pas d’établir une cause commune : OpenAI cite une erreur de routage, Anthropic un problème d’infrastructure non détaillé et SpaceX une panne de son centre de calcul de Memphis. Elles ne suffisent toutefois pas non plus à démontrer que les événements étaient entièrement indépendants. Cloudflare et les pages d’état des grands clouds réduisent la plausibilité d’une panne commune visible, sans exclure toute dépendance partagée non publiée. Présenter l’épisode comme une panne coordonnée ou comme l’effondrement d’un unique fournisseur cloud serait donc trompeur.

La vraie leçon se trouve ailleurs. Plusieurs défaillances rapportées peuvent produire simultanément le même effet pour le client final, qu’elles soient entièrement séparées ou qu’elles partagent une dépendance encore inconnue. Du point de vue d’une entreprise dont les équipes ou les applications attendent une réponse d’un modèle distant, l’origine exacte ne change pas la conséquence immédiate : le travail ne peut plus être exécuté comme prévu.

Les conséquences immédiates pour les utilisateurs

Les conséquences directement documentées sont des taux d’erreur élevés, des services indisponibles pour certains utilisateurs et une dégradation de plusieurs interfaces et API. Un utilisateur humain pouvait voir une requête échouer, attendre une réponse qui n’arrivait pas ou devoir réessayer. Une application connectée à une API pouvait recevoir une erreur, dépasser son délai d’attente ou placer une tâche en file d’attente.

Les conséquences métiers décrites ci-dessous ne sont pas toutes rapportées comme s’étant effectivement produites chez les clients pendant cet incident. Elles illustrent les risques auxquels s’expose une organisation lorsque ses workflows dépendent directement d’une API distante sans mode dégradé. Un assistant de support peut cesser de préparer des réponses. Une chaîne de traitement documentaire peut accumuler du retard. Un outil de développement peut interrompre une génération ou une revue de code. Un agent automatisé peut échouer au milieu d’une procédure. Des mécanismes de relance mal configurés peuvent augmenter brutalement le nombre de requêtes au moment même où le service est fragilisé. Lorsque la reprise intervient, les files d’attente doivent encore être vidées, les erreurs réconciliées et les actions incomplètes vérifiées.

Plus l’IA quitte le stade de l’outil individuel pour devenir une brique d’automatisation, plus une panne ressemble à un incident de système d’information classique : interruption, retard, perte de contexte, opérations partielles et besoin de reprise contrôlée.

Pourquoi plusieurs abonnements ne constituent pas nécessairement une résilience

À première vue, la réponse semble simple : si un fournisseur tombe, il suffit d’en utiliser un autre. Cette stratégie fonctionne parfois pour un collaborateur qui rédige ou résume manuellement un document. Elle devient beaucoup moins évidente pour une application intégrée.

Les fournisseurs n’utilisent pas exactement les mêmes API, les mêmes modèles, les mêmes limites, les mêmes outils ni les mêmes mécanismes d’authentification. Un prompt optimisé pour un modèle peut se comporter différemment sur un autre. Le contexte métier ou l’index documentaire peut ne pas être disponible auprès du second fournisseur. Les politiques de sécurité, la journalisation, les connecteurs, les évaluations de qualité et les garanties contractuelles peuvent également différer.

Une entreprise peut donc posséder trois comptes et ne disposer d’aucun basculement opérationnel. Tant qu’elle n’a pas préparé la compatibilité des interfaces, la disponibilité des données, les règles de sélection, la gestion des secrets et la procédure de reprise, elle possède des alternatives commerciales, pas nécessairement des alternatives techniques.

Cette situation correspond au risque de concentration des technologies de l’information : une fonction devient vulnérable lorsque sa continuité dépend d’un prestataire difficile à remplacer dans le délai réellement disponible. Le règlement DORA encadre explicitement ce risque dans le secteur financier européen. Le principe est plus large : la résilience ne se mesure pas au nombre de logos figurant dans un contrat, mais à la capacité réelle de substituer un composant sans arrêter la fonction métier.

Ce que cet incident dit de la souveraineté européenne

Le problème n’est pas que ces fournisseurs soient américains. Les plateformes internationales apportent des modèles performants, une capacité considérable et une rapidité d’accès difficiles à reproduire isolément. Réduire la souveraineté à la nationalité d’un fournisseur empêcherait de comprendre le risque opérationnel.

La question est celle du contrôle. Une organisation peut-elle choisir son modèle ? Peut-elle changer de fournisseur sans reconstruire toute son application ? Ses connaissances internes restent-elles accessibles dans un format qu’elle maîtrise ? Peut-elle décider qu’une donnée sensible ne quitte pas un périmètre approuvé ? Peut-elle maintenir un service prioritaire lorsqu’un fournisseur externe devient indisponible ?

La localisation européenne des données répond à une partie de ces questions, mais pas à toutes. Une donnée peut être stockée en Europe tout en restant liée à un service, une API, un modèle ou un plan de contrôle gouverné ailleurs. La souveraineté opérationnelle suppose donc de combiner la localisation, la gouvernance, la portabilité, la réversibilité et la continuité. Le Data Act européen facilite progressivement le changement de fournisseur de services de traitement de données, mais un droit contractuel au changement ne crée pas à lui seul une architecture capable de basculer en quelques minutes.

Conclusion : l’utilité d’une capacité locale

L’incident du jeudi 3 septembre montre enfin l’intérêt concret d’une infrastructure d’IA locale : non pas remplacer systématiquement le cloud ni prétendre reproduire tous les modèles des grands fournisseurs, mais conserver un chemin d’exécution sous contrôle lorsque ceux-ci deviennent indisponibles. Un modèle open-weight installé sur une capacité locale, associé à un RAG privé et à une passerelle d’API contrôlée comme OPA Core, aurait pu fournir un mode dégradé pour certains usages compatibles, maintenir l’accès aux connaissances sensibles dans l’infrastructure approuvée et réduire l’impact d’une panne externe. Les sources de cet incident ne démontrent pas qu’une architecture locale particulière aurait effectivement assuré cette continuité ; celle-ci dépend du dimensionnement, de la supervision, des sauvegardes et surtout de tests réalisés avant l’incident. Dans ce cadre, le local devient une composante pragmatique d’une architecture hybride : un moyen de transformer une dépendance totale en capacité de continuité gouvernée.

Sources

OpenAI Status, « Elevated errors across ChatGPT and Codex », 3 septembre 2026 : https://status.openai.com/incidents/01M1KWEDH417T2CF44YYHZDFCR

Anthropic Status, « Elevated errors for multiple models », 3 septembre 2026 : https://status.claude.com/incidents/461yvfrzpwtt

xAI Status, incident Grok INC25664c15 : https://status.x.ai/grok-com/INC25664c15

The Register, « True AI-pocalypse as ChatGPT, Claude, and Grok all go down at once », 3 septembre 2026 : https://www.theregister.com/ai-and-ml/2026/09/03/chatgpt-claude-and-grok-all-had-outages-at-the-same-time/5294322

Commission européenne, COM(2020) 67, « Façonner l’avenir numérique de l’Europe » : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:52020DC0067

Règlement DORA (UE) 2022/2554 : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32022R2554

Règlement européen sur les données (UE) 2023/2854 : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32023R2854

Cette analyse porte sur la résilience opérationnelle et ne constitue pas un avis juridique.

Tom Cheniaux - rephrased using AI