De quoi la redondance entre fournisseurs vous protège-t-elle réellement ?

Jeudi 3 septembre, trois pages de statut sont passées au jaune dans la même matinée. Côté OpenAI, les articles fondés sur ses mises à jour décrivent environ une demi-heure pendant laquelle ChatGPT et Codex étaient indisponibles pour certains utilisateurs. L'incident d'Anthropic a duré bien davantage, avec des taux d'erreur élevés sur plusieurs familles de modèles Claude. Les récits divergent sur sa durée : The Register donne trois heures et six minutes, d'autres reconstituent un peu moins de trois heures à partir de la chronologie du statut. Cela permet de dire près de trois heures. Prétendre être plus précis serait malhonnête. xAI enquêtait sur Grok depuis plus tôt dans la matinée et n'a publié aucune durée que nous puissions citer. Nous n'en donnons donc pas. The Register citait aussi les excuses de l'entreprise pour des problèmes dans son centre de calcul de Memphis et, séparément, à ses "impacted compute partners" (partenaires de calcul touchés). Nous n'avons trouvé ce récit que dans ce média, sans confirmation ailleurs. Nous le présentons donc comme une information rapportée, pas comme un fait établi.

Voilà tout ce qui est solidement établi. Cela mérite tout de même un article, précisément à cause de ce qui manque.

Personne à l'extérieur ne peut vous dire pourquoi

Quatre jours après, aucune cause commune n'est confirmée. Plusieurs médias ont attribué cette série d'incidents à une panne de région cloud, en nommant une région précise. Aucun fournisseur n'a confirmé cette attribution. Des articles ultérieurs ont explicitement précisé qu'elle n'était pas établie. Les excuses aux partenaires de calcul pointent dans une tout autre direction. Nous n'allons pas arbitrer entre ces récits. Sur ce site, une affirmation exige deux sources indépendantes concordantes avant d'entrer dans un article. Les explications concurrentes du 3 septembre ne passent pas ce seuil, séparément ou ensemble.

Une objection légitime arrive ici. C'est celle qu'un bon DSI vous opposera en réunion : trois laboratoires qui passent une mauvaise matinée ne prouvent rien sans fréquence de référence. Chacun de ces fournisseurs publie régulièrement des incidents. Trois incidents qui se chevauchent peuvent être une simple coïncidence présentée comme une tendance. L'objection est juste. Nous ne pouvons pas y répondre, car la fréquence qui permettrait de trancher n'est pas publiée sous une forme calculable de l'extérieur.

C'est précisément le constat. Si votre production repose sur deux ou trois fournisseurs de modèles et qu'ils vacillent tous le même matin, vous ne pouvez pas déterminer de l'extérieur si vous étiez exposé à une dépendance commune ou à trois coïncidences sans lien. Votre schéma d'architecture montre trois fournisseurs. Le nombre réel de domaines de panne vous était inconnu avant l'incident et le reste après. Une redondance impossible à vérifier est une croyance sur vos fournisseurs plutôt qu'une propriété de votre système.

Ce qu'apporte l'indépendance vis-à-vis des modèles, et ses limites

Nous avons abordé ce sujet deux fois dans ce Journal, sous un autre angle. "GLM-5.2: dependence on American AI is already no longer inevitable" défendait la souveraineté au sens de poids téléchargeables et d'un accès que personne ne peut révoquer. "Is a cheaper model good enough for everyday production work?" défendait l'affectation de chaque tâche au modèle le moins cher capable de l'accomplir. Les deux arguments tiennent toujours. Aucun n'a aidé quiconque le 3 septembre.

L'indépendance vis-à-vis des modèles vous protège d'un événement commercial : hausse de prix, point d'accès abandonné, licence devenue inacceptable, laboratoire qui décide de refuser votre usage. Elle vous donne la capacité de changer en quelques semaines. Ce bénéfice est réel et mérite qu'on le finance. Elle ne dit rien des quatre-vingt-dix prochaines minutes. Changer de fournisseur pendant un incident n'aide que si l'alternative fonctionne. Ce jeudi-là, les alternatives étaient justement le problème.

L'exposition se situe le plus vraisemblablement à l'étage inférieur, opaque pour les clients par construction. Un acheteur voit quatre logos et en déduit quatre systèmes indépendants. Aucun fournisseur ne publie assez d'informations sur ses dépendances physiques pour vérifier cette déduction. Un client peut ainsi découvrir sa propre chaîne de fournisseurs en lisant la note d'incident d'un concurrent. La posture honnête consiste donc à cesser d'assimiler diversité des fournisseurs et diversité des infrastructures. Gardez la première pour la protection commerciale qu'elle apporte, puis concevez votre système comme si tous vos modèles pouvaient être injoignables au même moment. Vous n'avez pas de quoi affirmer le contraire.

Concevoir le système pour l'absence du modèle

C'est là que se trouve le travail, sans prestige particulier. Dans les chaînes de traitement que nous construisons, un modèle est un composant qui peut tomber en panne. Le code autour est écrit pour y survivre comme il survivrait à un disque lent. Le moteur qui publie ce Journal est celui que nous pouvons montrer entièrement : il fonctionne publiquement et ses incidents sont racontés ici.

Chaque unité de travail est enregistrée durablement avant qu'un modèle y touche. La matière est collectée et stockée d'abord, puis lue. Une panne de modèle coûte alors du délai plutôt que des données. Quand le fournisseur revient, la file d'attente se résorbe. La différence entre une panne longue et un trou dans vos dossiers se décide dans un simple ordre d'opérations : l'élément a-t-il été enregistré avant l'appel ou après ?

L'échec est visible et précis. Un appel qui échoue, dépasse son délai ou renvoie un résultat rejeté par le schéma produit un état identifiable plutôt qu'un résultat vide. Cet été, dans "Agents that fabricate facts: what a 1,355-row cleanup taught us", nous avons raconté comment un de nos systèmes enregistrait discrètement des interactions qui n'avaient jamais eu lieu. Le même principe s'applique à l'absence. Le silence et "nothing to report" (rien à signaler) doivent être deux valeurs différentes. Tout ce qui suit interprète la défaillance silencieuse d'un composant comme une matinée normale.

Le fonctionnement dégradé se conçoit. Pour chaque tâche automatisée, on décide à l'avance et on écrit ce qui se passe lorsqu'aucun modèle ne répond : mettre en attente puis réessayer, appliquer une règle déterministe moins bonne mais prévisible, ou transmettre à une personne désignée un dossier déjà préparé. Cette décision se prend, que quelqu'un la prenne délibérément ou non. La version implicite est presque toujours la pire. Notre propre moteur porte deux règles de ce type, écrites après que nous en avons eu besoin. Il compte le travail d'une journée en pages réellement en ligne, plutôt qu'en exécutions déclarées réussies. Il refuse aussi de déployer sur un site dont le propriétaire a gelé la production, et signale l'écart. Cette seconde règle existe parce que le matin du 3 septembre, pendant les pannes des trois laboratoires, le moteur gérait son propre problème de disponibilité : une page publiée la veille avait disparu lors d'un rollback (retour arrière) qui visait autre chose. Nous avons publié ici l'analyse de cet incident le même jour, en posant la question de ce qu'un rollback emporte. Chacun peut donc vérifier le récit plutôt que nous croire sur parole.

Ce travail ne nécessite pas un programme assorti d'une ligne budgétaire. Il se fait une tâche après l'autre. La première coûte le plus, car elle oblige quelqu'un à énoncer pour la première fois une règle de fonctionnement dégradé. Les suivantes consistent surtout à la reproduire.

Le calcul, avec ses hypothèses explicites

Le coût de cette omission est facile à sous-estimer : il n'apparaît jamais comme une indisponibilité dans un tableau de bord. Le travail perdu en silence ne s'annonce pas. Il ressort des semaines après, sous la forme d'une facture jamais relancée, d'un prospect jamais orienté ou d'un trou dans le journal de conformité que quelqu'un devra expliquer.

Nous n'avons aucun chiffre mesuré de ce coût et nous n'allons pas en inventer. Nous pouvons en montrer la forme avec des valeurs à remplacer par les vôtres. Prenez une file qui reçoit trente éléments par heure, dont un modèle assure le premier classement. Deux heures de panne, une durée choisie pour le calcul et non tirée de jeudi dernier, mettent soixante éléments en jeu. S'ils ont été enregistrés d'abord, le coût est un retard puis le traitement de l'attente. Sinon, quelqu'un reconstitue soixante décisions à partir de la matière brute, à raison, disons, de cinq minutes chacune. Cela représente cinq heures de travail qui ne produisent rien de nouveau, réalisées dans l'urgence, des semaines trop tard, par le responsable du processus plutôt que par la personne qui a signé le contrat du modèle. Changez une donnée d'entrée et le sens reste le même : la partie coûteuse n'est jamais la panne, c'est la reconstitution.

Le test à faire cette semaine

Prenez une tâche automatisée importante et coupez délibérément son accès au modèle. Orientez-la pendant dix minutes vers un point d'accès qui ne répond pas, sur une plage calme, puis répondez honnêtement. Tous les éléments arrivés pendant ces dix minutes sont-ils encore dans le système, marqués comme restant à traiter ? Quelque chose a-t-il signalé à une personne qu'un composant était indisponible ? Quand le point d'accès est revenu, la file s'est-elle résorbée seule, ou quelqu'un a-t-il dû s'en apercevoir ? Si la réponse honnête à cette dernière question est que personne ne l'aurait remarqué avant l'appel d'un client, vous avez trouvé la faille au prix de dix minutes.

Posséder le système qui fonctionne permet de répondre à la question "what am I depending on right now" (de quoi est-ce que je dépends à cet instant) sans avoir besoin de la page de statut d'un tiers. C'est une affirmation plus limitée que la souveraineté, qui concerne la personne capable de révoquer votre accès. Ici, il s'agit de savoir qui peut vous dire ce qui vient de se passer. Le 3 septembre, nous ne le pouvions pas. À la lecture de tout ce qui a été publié depuis, personne hors de ces trois entreprises ne le pouvait non plus.