9 min read Résilience

Vos trois fournisseurs LLM sont tombés le même matin : le multi-modèle n'est pas une architecture de résilience

Vos trois fournisseurs LLM sont tombés le même matin : le multi-modèle n'est pas une architecture de résilience

Le jeudi 3 septembre 2026, ChatGPT, Claude et Grok ont été indisponibles à quelques dizaines de minutes d'intervalle. OpenAI a déclaré à The Register qu'une erreur de routage démarrée vers 7h43 heure du Pacifique avait rendu ChatGPT et Codex inaccessibles à une partie des utilisateurs, avec une correction appliquée vers 8h17, l'incident ouvert sur sa page de statut listant dix-neuf composants dégradés. Anthropic a confirmé au même média « un incident d'infrastructure ayant causé une panne partielle » de Claude.ai, Claude Code, Claude Cowork et de l'API, service rétabli à 16h16 UTC après un peu plus de trois heures. xAI a ouvert un incident sur Grok vers 6h30 heure du Pacifique, puis SpaceXAI a publié dans l'après-midi des excuses attribuant la panne à « une interruption de notre centre de calcul de Memphis », en ajoutant des excuses adressées « à nos partenaires de calcul impactés ». Axios a également signalé des remontées sur Gemini, sans confirmation de Google.

Le réflexe de lecture est de voir dans cette journée la validation du multi-modèle : trois fournisseurs, trois pannes, donc trois fois plus de raisons de router vers plusieurs API. C'est l'inverse que la journée démontre. Le multi-modèle protège contre un fournisseur qui augmente ses prix, retire un modèle, change ses conditions ou dégrade sa qualité. Il ne protège pas contre une panne quand les fournisseurs choisis partagent la même couche de calcul, parce que dans ce cas la corrélation entre leurs défaillances n'est pas nulle, elle est proche de un. Le 3 septembre, le fournisseur que beaucoup d'architectures ont retenu comme troisième roue de secours louait précisément ses GPU au fournisseur qu'il était censé remplacer.

Les articles du 1er septembre sur les préavis de retrait de modèle et du 3 septembre sur les clauses de substitution dans les contrats SaaS traitaient de la dépendance contractuelle, celle qui se lit dans un document et se négocie. Celle-ci ne se lit nulle part dans vos contrats : elle vit dans la chaîne de sous-traitance de calcul de vos fournisseurs, une couche que presque aucune grille d'évaluation fournisseur ne demande à voir.

Trois cartes fournisseurs posées sur un socle unique traversé par une ligne de rupture.
Trois marques de modèles distinctes peuvent reposer sur un seul plancher de calcul, invisible depuis le contrat.

Ce que la chronologie du 3 septembre dit exactement

La lecture honnête de cette journée est qu'elle mélange une coïncidence et une dépendance réelle, et que la distinction compte pour en tirer une conclusion utile.

Du côté d'OpenAI, la cause déclarée est une erreur de routage interne, sans lien établi avec un tiers, et la fenêtre d'indisponibilité est courte. Du côté de Grok et de Claude, les éléments publics convergent vers un point commun. SpaceXAI a nommé son centre de calcul de Memphis et s'est excusé auprès de ses partenaires de calcul. Or SpaceXAI a annoncé le 6 mai 2026 avoir signé un accord donnant à Anthropic l'accès à Colossus 1, le supercalculateur de Memphis équipé de plus de 220 000 GPU NVIDIA, capacité destinée selon le communiqué à servir les abonnés Claude Pro et Claude Max. Aucune des deux entreprises n'a établi publiquement que la panne de Claude venait de là, et la formulation d'Anthropic reste volontairement générique. Le lien est plausible et documenté par ses deux extrémités, il n'est pas confirmé, et un article qui l'affirmerait irait plus loin que les faits.

Le reste des hypothèses de presse tient moins bien. Axios évoquait des perturbations Azure susceptibles de contribuer aux trois pannes ; The Register a constaté le même jour que les pages de statut d'AWS, Google Cloud et Microsoft Azure ne signalaient aucune difficulté pertinente, tout en rappelant que ces pages ne reflètent pas toujours les incidents en temps réel. Cloudflare, utilisé à des titres divers par les trois entreprises, a démenti fermement toute perturbation significative de ses services.

Les mots de la dépendance

Substrat de calcul : l'ensemble des centres de données, accélérateurs et réseaux sur lesquels un modèle est réellement servi, indépendamment de la marque commerciale du modèle.

Corrélation de panne : probabilité que deux composants tombent en même temps. Une architecture de secours ne vaut que si cette corrélation est faible entre le composant principal et son remplaçant.

Mode dégradé : comportement produit défini à l'avance quand une capacité n'est plus disponible, par opposition au basculement, qui suppose qu'une capacité équivalente existe ailleurs.

Registre d'information : inventaire réglementaire des contrats avec les prestataires informatiques, imposé aux entités financières européennes par DORA, et qui doit couvrir les chaînes de sous-traitance soutenant une fonction critique.

La couche que votre grille fournisseur ne décrit pas

Le point aveugle n'est pas la qualité des fournisseurs, il est dans la granularité de ce que vous évaluez. Une grille d'évaluation type porte sur le modèle, l'API, les conditions de traitement des données, le SLA affiché et la trajectoire de versions. Elle s'arrête à la marque. Elle ne demande jamais dans quels centres de données l'inférence s'exécute, quels accélérateurs la portent, ni quels prestataires interviennent en sous-traitance de deuxième rang.

Le cas d'Anthropic illustre à quel point cette couche est mouvante. L'entreprise sert Claude depuis un parc réellement multi-fournisseurs, avec AWS comme partenaire d'entraînement principal, une capacité TPU Google massive montée en charge sur 2026, des GPU NVIDIA, et depuis mai la capacité de Colossus 1. Ce n'est pas une faiblesse, c'est la stratégie explicite de l'entreprise. Mais elle a une conséquence directe pour vous : la composition du plancher sous un même nom de modèle change plusieurs fois par an, sans notification client, et votre analyse de corrélation d'il y a six mois est périmée sans que rien ne vous l'ait signalé.

L'ampleur du problème est structurelle plutôt qu'anecdotique. L'enquête Dataiku menée avec Harris Poll auprès de 600 DSI d'entreprise indique que 81 % d'entre eux comptent s'appuyer sur au moins deux fournisseurs de LLM en 2026, et que 55 % ont déjà changé de fournisseur au moins une fois, la réduction de coûts étant le premier motif. La motivation dominante est la performance par cas d'usage et le prix, pas la disponibilité. Le multi-modèle s'est donc généralisé pour de bonnes raisons, mais il est ensuite présenté en comité de risque comme une couverture de continuité qu'il n'a jamais été conçu pour fournir.

Schéma opposant trois chemins de secours indépendants à trois chemins convergeant vers un substrat partagé.
Le basculement suppose deux chemins indépendants ; il ne vaut rien quand les deux chemins se rejoignent au niveau du sol.

Sur le terrain, le symptôme est presque toujours le même. La bascule multi-fournisseurs existe, elle est câblée dans la passerelle, elle est documentée dans le schéma d'architecture, et elle n'a jamais été exécutée hors d'un test unitaire. La première fois qu'elle s'exécute en conditions réelles, c'est pendant l'incident, et l'équipe découvre ce jour-là que les quotas du fournisseur de secours sont dimensionnés pour du test, que les formats de sortie diffèrent assez pour casser le parsing en aval, et que le basculement se déclenche sur un code d'erreur HTTP qui ne se produit pas quand le fournisseur répond lentement au lieu de répondre faux.

Le cadre réglementaire demande déjà cette cartographie

Pour une partie des lecteurs, cette cartographie n'est pas une bonne pratique optionnelle. DORA impose aux entités financières européennes de tenir un registre d'information couvrant les contrats de services informatiques, y compris les chaînes de sous-traitance qui soutiennent une fonction critique ou importante, et d'évaluer explicitement le risque de concentration. L'article 30 fixe les clauses obligatoires : droits d'audit et d'accès, stratégie de sortie, contrôle des sous-traitants, niveaux de service portant notamment sur la localisation des données et la capacité de calcul.

La désignation, le 18 novembre 2025, des dix-neuf premiers prestataires informatiques tiers critiques placés sous supervision directe des autorités européennes de surveillance donne la mesure de ce que le régulateur regarde. La liste est composée pour l'essentiel de fournisseurs d'infrastructure, dont AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix et Swift, sélectionnés sur quatre critères parmi lesquels la concentration de la dépendance du secteur et la substituabilité du service. La logique de supervision porte sur le plancher, pas sur la marque applicative posée dessus. Une entité financière qui déclare trois fournisseurs de LLM dans son registre sans documenter le calcul qui les porte décrit une diversification que son propre régulateur ne reconnaîtra pas comme telle.

Concevoir un mode dégradé plutôt qu'un basculement

La conclusion pratique n'est pas d'abandonner le multi-modèle, qui reste justifié pour le coût, la qualité par cas d'usage et le pouvoir de négociation. Elle est de cesser de le compter deux fois, en résilience et en performance, et de traiter la disponibilité comme un problème produit distinct.

Un mode dégradé se définit fonctionnalité par fonctionnalité, en répondant à une question simple : que fait cet écran, ce parcours, ce traitement par lot, quand aucun modèle n'est joignable pendant trois heures. Les réponses acceptables existent et se conçoivent à froid : mise en file avec reprise et engagement de délai différé, bascule vers un modèle local plus faible mais suffisant pour la classification, retour à une règle déterministe pour le sous-ensemble de cas les plus fréquents, ou message explicite et fonctionnement manuel assumé. Une seule réponse est inacceptable, celle qui consiste à afficher une erreur technique et à laisser l'utilisateur relancer en boucle, parce qu'elle transforme une panne fournisseur de trois heures en incident de confiance qui dure plus longtemps qu'elle.

À mettre en route cette semaine

Demandez par écrit à chacun de vos fournisseurs de modèles la liste des régions et des sous-traitants d'infrastructure qui servent votre trafic, ainsi que leur politique de notification en cas de changement. La réponse, y compris une réponse partielle ou un refus, est en soi une donnée d'évaluation à consigner. Une entité soumise à DORA a déjà un droit contractuel à poser cette question.

Recalculez votre corrélation de panne à partir des réponses obtenues, pas à partir des marques. Si vos trois chemins convergent vers un ou deux opérateurs d'infrastructure, votre architecture a un seul point de défaillance présenté sous trois noms, et votre plan de continuité surestime votre disponibilité d'un ordre de grandeur.

Déclenchez un exercice de panne totale sur un environnement de préproduction, en coupant l'accès à tous les fournisseurs simultanément et non l'un après l'autre. Le test à un seul fournisseur indisponible valide la passerelle ; seul le test à zéro fournisseur valide le produit. Mesurez ce que voit l'utilisateur, ce qui se perd, et ce qui se rejoue à la reprise.

Séparez, dans vos engagements internes et dans vos contrats clients, le SLA du modèle et le SLA de l'infrastructure sous-jacente. Un fournisseur ne peut vous garantir que ce qu'il maîtrise, et la partie qu'il ne maîtrise pas est exactement celle qui a produit la panne du 3 septembre.

Écrivez le mode dégradé de vos trois parcours les plus critiques, validez-le avec le métier plutôt qu'avec l'équipe plateforme, et faites-le tenir sur une page. Un mode dégradé qui n'a pas été accepté par celui qui répondra au client n'existe pas.

Conclusion

La journée du 3 septembre n'a pas révélé une fragilité nouvelle des fournisseurs de modèles, dont les taux de disponibilité restent comparables à ceux du reste de l'industrie logicielle. Elle a révélé qu'une grande partie des architectures multi-modèles ne savent pas répondre, dans l'heure, à la question de savoir si leurs fournisseurs sont indépendants les uns des autres. Tant que cette question n'a pas de réponse écrite et datée, la ligne « redondance fournisseur » de votre plan de continuité décrit une intention commerciale, pas une propriété technique de votre système.

Sources : As of September 2026

Godwin AVODAGBE