IA et produit
La panne de Claude du 13 novembre 2026, et pourquoi les systèmes de nos clients ont continué de tourner
Publié le
Sur cette page
Le vendredi 13 novembre 2026, la page d’état d’Anthropic a enregistré deux incidents. Le premier a duré de 09 h 58 à 11 h 58 UTC et a empêché les utilisateurs de se connecter à claude.ai et à Claude Code. Le second a duré de 13 h 09 à 15 h 38 UTC et a provoqué un taux d’erreurs élevé sur claude.ai, les applications mobiles, Claude Code et l’API Claude. Cela fait 4 h 29 d’incident dans une seule journée de travail.
Si vous avez passé une partie de cette journée devant un écran de connexion, vous n’étiez pas seul. D’après Ahrefs, la requête « is Claude down » est tapée environ 62 000 fois par mois aux États-Unis.
Nous développons pour nos clients des logiciels qui fonctionnent avec Claude. Aucun d’eux ne nous a signalé de problème le 13. La raison tient surtout à la partie de Claude dont leurs systèmes dépendent, et elle mérite d’être examinée de près, car la version courte (« l’API ne tombe jamais ») est fausse.
Ce que montre la page d’état
Vendredi 13 novembre 2026, par composant
| Incident | Heure (UTC) | Durée | Services indiqués comme touchés |
|---|---|---|---|
| Échecs de connexion | 09 h 58 à 11 h 58 | 2 h 00 | claude.ai, Claude Console, Claude Code, Claude Cowork |
| Taux d’erreurs élevé | 13 h 09 à 15 h 38 | 2 h 29 | claude.ai, API Claude, Claude Code, Claude Cowork |
Le premier incident concernait l’authentification. La première note d’Anthropic indique que l’équipe enquêtait sur un problème d’authentification des utilisateurs sur claude.ai et Claude Code. L’API Claude ne figure pas dans la liste. Un système qui appelle l’API le fait avec une clé. Il ne passe jamais par le parcours de connexion, et rien chez lui ne pouvait donc tomber en panne.
Le second incident incluait bien l’API. À 14 h 36 UTC, Anthropic a signalé le rétablissement de claude.ai et de l’API. Les connecteurs, Claude Managed Agents et Claude dans les réunions étaient encore dégradés à ce moment-là. À 15 h 33, cinq minutes avant la clôture de l’incident, la mise à jour précisait que les tâches planifiées pouvaient s’exécuter avec plus de deux heures de retard et que certaines exécutions avaient été ignorées.
L’API a donc été concernée par un incident sur deux, et elle a été rétablie avant les fonctions construites au-dessus d’elle.
L’application compte plus d’éléments
Quand vous ouvrez claude.ai et lui demandez de rédiger une réponse à partir de votre agenda, plusieurs choses doivent fonctionner en même temps : votre session de connexion, l’application web ou mobile, le connecteur vers votre agenda, le fournisseur de l’agenda en face, et le modèle. Un appel direct à l’API a besoin d’une clé et du modèle.
Dans l’application5 éléments
- Session de connexion
- Application web ou mobile
- Connecteur
- Service tiers
- Modèle
Sur l’API2 éléments
- Clé d’API
- Modèle
Plus il y a d’éléments, plus il y a de façons de passer un mauvais après-midi. Certains de ces éléments ne dépendent pas d’Anthropic. Le connecteur Microsoft 365 a renvoyé des erreurs du 12 novembre à 16 h 03 UTC au 13 novembre à 16 h 40 UTC, à cause d’un incident chez Microsoft. En octobre, le connecteur Google Agenda a été touché du 26 au 28.
Voici les chiffres de disponibilité mensuelle publiés par Anthropic, relevés le 14 novembre :
| Septembre | Octobre | Novembre à ce jour | |
|---|---|---|---|
| claude.ai | 99,69 % | 99,85 % | 98,42 % |
| Claude Code | 99,69 % | 99,85 % | 99,66 % |
| API Claude | 99,73 % | 99,86 % | 99,77 % |
Part de novembre en indisponibilité, du 1er au 14 novembre 2026
Septembre et octobre sont presque identiques, et nous ne bâtirions pas un argument dessus. C’est en novembre que la différence apparaît. Si environ treize jours et demi du mois s’étaient écoulés au moment de notre relevé, 98,42 % représentent à peu près cinq heures d’indisponibilité pour claude.ai, et 99,77 % moins d’une heure pour l’API. Nous verrons comment se passe le reste du mois.
Ce qui change quand on construit sur l’API
Le taux de disponibilité n’est qu’une partie de la réponse. La différence la plus importante est de savoir qui décide de ce qui se passe quand une requête échoue.
Dans l’application, vous attendez. Il n’y a rien d’autre à faire.
Dans un système construit sur l’API, cette décision est écrite dans le logiciel. Une requête qui échoue peut être relancée après une courte pause ; les SDK d’Anthropic le font deux fois par défaut. Le travail peut rester en file d’attente jusqu’au retour du service. Les requêtes peuvent être envoyées aux mêmes modèles Claude sur AWS, Google Cloud ou Microsoft Foundry, qui sont suivis séparément sur la page d’état et n’apparaissaient dans aucun des deux incidents du 13.
C’est sur cette base que reposent les systèmes de nos clients. Le premier incident ne les a jamais atteints. Pendant le second, l’API a figuré dans la liste durant une partie de la période, et aucun client n’a pour autant signalé de perturbation.
Il serait malhonnête de s’arrêter là. L’API a aussi ses mauvais jours. Le 29 septembre, un incident a touché l’ensemble des services, API comprise, avec un impact de 14 h 00 à 14 h 59 UTC. Construire sur l’API coûte aussi plus cher au départ. Il faut que quelqu’un écrive le logiciel, vous payez à la requête au lieu d’un abonnement fixe, et l’ensemble doit être entretenu. Pour une grande partie du travail, cette dépense n’apporte rien dont vous ayez besoin.
La question des 4 h 29
La plupart des entreprises utilisent Claude par l’application, et pour l’essentiel de ce qu’elles en font, c’est le bon choix. C’est moins cher, cela ne demande aucun développement, et les nouvelles fonctions y arrivent en premier.
Un test utile consiste à reprendre le chiffre du 13 et à vous demander ce qu’il vous coûterait. Supposons que Claude soit indisponible 4 h 29 un jour de semaine.
Combien cela vous coûterait-il ?
Saisissez vos propres chiffres. Rien n’est envoyé nulle part.
- Heures-personnes d’attente
- 22.4
- Coût de l’attente
- 897
Personne en dehors de l’entreprise n’est touché. L’application est le bon choix pour ce travail.
Montrez-nous ce processusSi la réponse est que les gens travaillent sur autre chose et rattrapent plus tard, ne changez rien. Une intégration reviendrait à dépenser de l’argent pour un problème que vous n’avez pas.
Si la réponse fait intervenir un client, c’est différent. Des réponses du support qui ne partent pas. Des commandes ou des documents qui ne sont plus traités. Un rapport qu’un client attend. Ce genre de travail ne devrait pas dépendre d’une personne connectée à une fenêtre de discussion, et c’est en général celui que l’on déplace vers l’API.
Il n’est pas nécessaire de tout déplacer. Un processus, peut-être deux, suffit souvent, et le reste de l’équipe continue dans l’application comme avant.
Une façon concrète de commencer : notez ce que votre entreprise fait avec Claude chaque semaine, et cochez tout ce qu’un client remarquerait si cela s’arrêtait le temps d’un après-midi. Si rien n’est coché, vous avez terminé. S’il y a une coche, c’est le processus à examiner, et nous l’examinerons volontiers avec vous. Cela relève de notre activité de développement logiciel sur mesure.
Les pages d’incident du 13 novembre sont sur status.claude.com si vous souhaitez vérifier les horaires vous-même.