L’essentiel
- Claude a connu deux incidents distincts le 23 juin 2026 : un le matin sur Opus 4.8, un second en début d’après-midi touchant plusieurs modèles.
- Le statut officiel d’Anthropic parle d’un « taux d’erreur élevé » : une partie des requêtes échouait, sans coupure totale du service.
- L’incident de l’après-midi a démarré à 16h19 (heure de Paris) et un correctif était en déploiement moins de dix minutes plus tard.
Claude a flanché deux fois dans la même journée. Pas un simple ralentissement passager : deux incidents séparés, confirmés noir sur blanc par le statut officiel d’Anthropic, qui ont renvoyé des erreurs à une partie des utilisateurs ce mardi 23 juin 2026.
Deux pannes le même jour
Le premier épisode passe presque inaperçu. En matinée, Anthropic ouvre un incident sur Opus 4.8, son modèle haut de gamme : investigation lancée vers 8h28, retour à la normale annoncé peu après 10h45. Quelques heures de répit, puis rebelote.
En début d’après-midi, deuxième alerte, autrement plus visible. À 16h19, le statut d’Anthropic bascule en investigation sur un taux d’erreur élevé qui touche cette fois plusieurs modèles, et plus seulement Opus. Les signalements s’envolent dans la foulée sur les traqueurs de pannes grand public.
Anthropic confirme un taux d’erreur élevé
Le terme compte : « taux d’erreur élevé », pas coupure franche. Concrètement, une partie des requêtes échouait quand le reste passait, ce qui rend un assistant erratique sans le mettre totalement hors ligne. Les premières remontées situaient le pic autour de 10 % d’appels en erreur.
La réaction a été rapide. Six minutes après l’ouverture de l’incident, Anthropic annonçait avoir identifié la cause et déployer un correctif ; à 16h53, le correctif était en place et l’entreprise surveillait les effets. Opus 4.8 aura été en première ligne sur la journée : c’est déjà lui qui faisait l’objet de l’incident du matin.
Une brique d’infrastructure qui n’a plus le droit de tomber
Une panne d’une heure, corrigée vite, ce n’est pas un drame en soi. Ce qui change, c’est la place qu’occupe désormais Claude dans les outils que l’on utilise tous les jours.
Quand le modèle vit dans un chatbot que l’on consulte de temps en temps, une panne agace. Quand il est câblé dans un IDE, un agent autonome, une chaîne de support client ou un pipeline de production, la même panne arrête net le travail. Claude n’est plus un gadget que l’on essaie : c’est de la plomberie. Et une plomberie, on ne lui demande pas d’être brillante, on lui demande de couler tous les jours.
Pour les équipes qui bâtissent un produit sur l’API, la leçon est très concrète : prévoir un plan de repli (file d’attente, bascule vers un autre modèle, dégradation gracieuse plutôt qu’erreur sèche) cesse d’être un luxe d’ingénieur prudent. C’est ce qui évite que votre service tombe chaque fois que votre fournisseur éternue.
Anthropic a éteint l’incendie en moins d’une heure, et la plupart des utilisateurs n’auront vu qu’un trou d’air. Le sujet de fond, lui, ne se referme pas : à mesure que ces modèles passent de l’outil que l’on teste à l’infrastructure dont on dépend, leur disponibilité devient un engagement, plus une faveur. Combien de produits, aujourd’hui, tiennent debout en pariant que le fournisseur ne tombera jamais ?
Mon avis
Ces micro-pannes à répétition sont le vrai test de maturité du secteur, bien plus que le prochain benchmark. Je fais le pari que la fiabilité deviendra un argument commercial aussi fort que la performance brute : d’ici un an, le SLA et la redondance pèseront autant dans le choix d’un fournisseur d’IA que les scores aux classements. Le labo qui tombe le moins, pas celui qui raisonne le mieux, prendra les usages critiques.
