Le 3 septembre 2026, plusieurs services d'IA se sont dégradés dans la même fenêtre. L'épisode mérite d'être analysé moins pour son ampleur que parce qu'il illustre à nouveau, très proprement, l'écart entre observation tierce et confirmation par l'éditeur — et cette distinction détermine où vous investirez argent et ingénierie ensuite.

Ce qui a été confirmé

  • La page de statut d'OpenAI a signalé une hausse des erreurs sur ChatGPT et Codex. C'est une source de première main.
  • Les signalements sur Downdetector sont passés de plus de 5 000 à plus de 74 000, l'un des pics les plus élevés enregistrés cette année-là pour un service d'IA sur cette plateforme.
  • La fenêtre de perturbation s'est étendue d'environ 10:58 à 14:56, heure de l'Est — près de quatre heures.
  • Au matin du 4 septembre, les outils de suivi externes montraient ChatGPT et Codex de nouveau opérationnels.

Ce qui n'a été qu'attribué

Plusieurs médias ont attribué la dégradation simultanée de plusieurs services d'IA à une défaillance régionale d'Azure East US, indiquant que Claude et Grok avaient été touchés dans la même fenêtre, tandis que Gemini — hébergé sur Google Cloud — plafonnait autour de 500 signalements.

Or, au moment de la rédaction, l'historique public du statut Azure de Microsoft ne mentionnait aucun incident East US correspondant pour septembre 2026. La revue post-incident la plus récente visible y était datée du 23 juillet 2026 et concernait un problème de connectivité réseau en West US, identifiant de suivi ZJV6-SGG.

Cela ne rend pas les articles faux : les revues post-incident des éditeurs mettent couramment plusieurs jours, voire semaines, à paraître. Le constat est plus étroit et plus utile : tant que vous n'avez pas de confirmation de première main, cette chaîne causale reste « selon les informations rapportées » et n'a pas sa place comme fait dans vos décisions d'architecture. C'est la discipline appliquée dans « Les classements ont bougé du 1er au 3 août et Google n'a rien confirmé » : plusieurs moniteurs qui s'allument ensemble établissent une corrélation, jamais une causalité.

Quelle que soit la cause, la conclusion technique est identique

Si votre produit appelle une API de modèle hébergée, c'est une dépendance dure : quand elle casse, votre fonctionnalité casse, et vous n'avez ni la capacité de la réparer ni le droit d'être informé. Rien de cela ne change selon que la cause était Azure, l'éditeur lui-même ou autre chose. À mettre en œuvre immédiatement :

  • Fixez des délais d'expiration stricts. N'héritez pas des valeurs par défaut des SDK, souvent illimitées ou très longues. Un appel qui dépasse ce que vous tolérez doit échouer vers un chemin de repli plutôt que d'immobiliser le fil d'exécution d'un utilisateur.
  • Réessayez avec backoff exponentiel et gigue, en distinguant la limitation de débit d'une panne régionale : insister sur la seconde ne fait qu'amplifier l'embouteillage.
  • Prévoyez un mode dégradé. Une réponse en cache, une file asynchrone ou un message honnête valent tous mieux qu'un indicateur de chargement pendant quatre heures.
  • Mettez le travail en file pour découpler les requêtes utilisateurs des appels au modèle. La panne se traduit alors par « plus lent » et non « perdu » : c'est le changement d'architecture le plus rentable de cette liste.
  • Gardez le fournisseur interchangeable. Au minimum, abstrayez les appels derrière la configuration pour changer d'éditeur sans modifier le code. Si votre plan de repli est un modèle auto-hébergé, lisez d'abord le deuxième article de cette série : l'auto-hébergement apporte son propre problème d'exposition.
  • Exploitez votre propre page de statut et vos alertes. Vous devez l'apprendre avant vos utilisateurs, pas par un ticket de support.

Écrivez la liste des dépendances

Dans notre revue des schémas de panne du premier semestre 2026, nous suggérions de dessiner une carte des dépendances : DNS, CDN, émission de certificats, stockage objet, compte et facturation, accès hors bande — chacun accompagné d'une note sur ce qui se passe en cas de défaillance. Les API de modèles hébergées méritent désormais leur propre ligne.

Une instance que vous contrôlez entièrement peut y tenir plusieurs rôles irremplaçables : héberger la page de statut et la page dégradée (qui ne doivent pas partager le sort du service principal), servir d'origine temporaire après une bascule DNS, et accueillir une copie de sauvegarde qui ne vit pas chez le même fournisseur. Les stratégies de sauvegarde VPS expliquent ce qui rend cette copie réellement restaurable, et ce qu'est un CDN et quand vous en avez besoin délimite la responsabilité de l'origine. SharkCloud dispose de nœuds au Japon, à Singapour, à Hong Kong et aux États-Unis — et placer cette machine de secours chez un autre fournisseur, dans une autre région, est la case la plus facile à cocher sur cette carte.