Le middleware du SDK Anthropic : arrêtez d'écrire vos propres wrappers d'observabilité

Trois choses livrées. Un seul pattern.

@anthropic-ai/sdk 0.101.0 est sorti le 5 juin avec une API middleware. @anthropic-ai/claude-agent-sdk 0.3.168 est sorti le 6 juin — dixième release en sept jours. Nuxt 4.4.7 est sorti le 2 juin comme correctif de sécurité.

Pris isolément, aucun de ces événements n'est spectaculaire. Ensemble, ils formulent un constat sur la maintenance des stacks AI en production en 2026 : c'est hebdomadaire, ça se cumule, et les plages semver passives ne suffisent plus.

Les équipes qui traitent leur SDK Anthropic comme "on installe, on met à jour au prochain trimestre" ont maintenant plusieurs features de retard. Cette semaine, au moins une de ces features est quelque chose qu'elles ont probablement construit elles-mêmes.

L'API middleware : votre wrapper de logging est désormais de la dette technique

@anthropic-ai/sdk 0.101.0 livre une API middleware qui intercepte chaque requête HTTP du client.

La surface est un tableau de middleware fetch-level passé à la construction du client : new Anthropic({ middleware: [fn] }). Chaque middleware a la signature async (request, next, ctx) => Response et enveloppe chaque tentative HTTP, y compris les retries. On l'installe une fois ; tous les appels (messages.create, exécutions d'outils, streaming) passent par la même couche, sans wrapper par appel ni fetch override custom.

Une seule registration, et on dispose d'un point d'interception propre pour le logging, le tracing, la logique de retry, le circuit-breaker, ou une intégration Langfuse quasi sans configuration.

0.102.0, sorti le 6 juin, corrige l'ordre d'exécution : le middleware tourne désormais avant la signature de la requête. Cet ordre importe pour tout ce qui lit ou modifie les headers avant signature. Si vous avez installé 0.101.0, passez à 0.102.0.

L'implication concrète est directe. La plupart des équipes qui opèrent de l'AI en production ont déjà une version de cette couche : un wrapper autour du client SDK, une implémentation fetch custom, un décorateur qui logue inputTokens / outputTokens / latence avant de passer la main.

Certains de ces wrappers sont propres. La majorité ont accumulé des cas limites. Que se passe-t-il en cas de retry ? Le logger double-comptabilise-t-il les tokens sur une erreur de stream ? Se compose-t-il correctement avec le backoff exponentiel du SDK ?

Voici la forme de ce que la plupart des équipes ont écrit à la main, et ce qui le remplace :

// Avant : un wrapper que chaque appel doit traverser
async function tracedCreate(client, params) {
  const start = performance.now();
  const res = await client.messages.create(params);
  log({ tokens: res.usage, ms: performance.now() - start });
  return res;
}

// Après : un middleware fetch-level, posé une fois à la construction.
// Signature (request, next, ctx) ; il tourne par tentative HTTP,
// à l'intérieur de la boucle de retry du SDK.
const tracing = async (request, next, ctx) => {
  const start = performance.now();
  const response = await next(request);
  log({ status: response.status, ms: performance.now() - start });
  return response;
};
const client = new Anthropic({ middleware: [tracing] });

(API vérifiée sur 0.102.0, core/middleware.ts. Le middleware est fetch-level : il voit la requête/réponse HTTP, pas l'objet usage déjà parsé — pour compter les tokens, lis le corps de la réponse sans le consommer, ou garde ce calcul au niveau du résultat de messages.create.)

Point de vigilance : le middleware tourne à l'intérieur de la boucle de retry — il est invoqué une fois par tentative HTTP. Un appel retenté 3 fois déclenche donc le middleware 3 fois, et un logger naïf sur-compte sur les retries (l'inverse d'un wrapper placé autour de messages.create, qui ne voit que le résultat final). L'avantage : vous observez chaque tentative — précieux pour tracer les retries — sans ré-implémenter le backoff. La contrepartie : agrégez ou dédupliquez par requête logique si vous comptez des coûts ou des tokens. Vérifiez ce comportement sous votre charge avant de supprimer l'ancien code.

Pour les équipes sur Langfuse, Helicone, ou leur propre observabilité, la migration est la même : remplacer le wrapper par une registration middleware. Ce que vous avez construit en Q1 ressemble beaucoup à de la dette technique depuis le 5 juin.

Le SDK agent : 10 releases en 7 jours, deux qui comptent

@anthropic-ai/claude-agent-sdk est passé de 0.3.158 le 30 mai à 0.3.168 le 6 juin — dix releases en sept jours.

La plupart portent la même mention que les semaines précédentes : parity with Claude Code. Le SDK reflète la surface CLI ; quand la CLI livre quotidiennement, le SDK suit. Deux changements méritent attention.

Resource tools MCP à runtime. Un correctif est arrivé pour les resource tools qui n'étaient pas injectés quand des serveurs étaient ajoutés à runtime via mcp_set_servers. Si vos agents construisent leur liste de serveurs MCP dynamiquement — selon le contexte, la tâche ou l'utilisateur — c'était un mode de défaillance silencieux.

Les resource tools enregistrés après l'initialisation n'atteignaient pas le contexte du modèle. Les agents exécutaient des tâches sans les outils qu'ils auraient dû avoir, sans aucun signal côté SDK. Le correctif est dans la fenêtre 0.3.162–0.3.165 ; si vous avez besoin de la release précise, comparez le changelog avant de pinner.

Les refus sont désormais explicites. stop_reason: "refusal" se propage maintenant sur les messages refusés. Auparavant, un refus ressemblait à une completion normale — le modèle répondait, le code continuait, et sauf inspection minutieuse du contenu vous traitiez le refus comme une réponse réussie.

Avec stop_reason: "refusal", le signal est explicite. Tout pipeline qui fait du routing ou du fallback sur des critères de sécurité peut brancher proprement sans parser le texte — un petit changement qui élimine toute une classe de string-matching fragile.

Si vous avez plus de trois versions mineures de retard sur 0.3.168, vous manquez au moins l'un de ces correctifs. La vérification tient en une ligne : npm ls @anthropic-ai/claude-agent-sdk en production.

Nuxt 4.4.7 : un correctif qu'on ne reporte pas au prochain sprint

Nuxt 4.4.7 est sorti le 2 juin comme release de sécurité explicite. Trois problèmes : un contournement du comportement noSSR payload dans Nitro, un path traversal potentiel dans la configuration allowDirs de Vite, et une vérification de boundary dans le cache de build.

Le contournement noSSR et le path traversal sont les deux à lire de près. Le bypass noSSR signifie que le rendu côté serveur pourrait être déclenché dans des contextes où l'app l'a explicitement désactivé — pertinent si votre path SSR a des accès aux données ou une gestion de session différents du path CSR.

Le problème Vite allowDirs est principalement un sujet de mode dev, mais les configurations Vite dev/prod partagées sont assez courantes pour justifier le patch dans tous les cas.

Chemin de mise à jour : seul nuxt change. Verrouillez à 4.4.7, lancez votre install, vérifiez le build. Dans un monorepo avec catalog de workspace, c'est une ligne dans pnpm-workspace.yaml. Ce n'est pas une situation "prochain sprint" — Nuxt a explicitement supersédé 4.4.6 pour des raisons de sécurité.

Ce qu'il faut faire cette semaine

Trois actions concrètes, par ordre de priorité :

1. Patcher Nuxt en 4.4.7 aujourd'hui. Release de sécurité, changement d'un seul package, rayon d'impact faible.
2. Pinner le SDK Anthropic en 0.102.0 et vérifier si votre wrapper de tracing peut être retiré au profit du middleware. Laissez les deux tourner en parallèle une journée, comparez les logs, puis supprimez le wrapper.
3. Lancer npm ls @anthropic-ai/claude-agent-sdk et mettre à jour si vous avez plus de trois mineures de retard sur 0.3.168.

Ensuite, rendez la version récurrente de tout ça automatique. Un check CI hebdomadaire fait une quinzaine de lignes : récupérer la version installée avec npm ls --json, la dernière du registry avec npm view <pkg> version, et échouer (ou avertir) quand un package @anthropic-ai/* ou @google/genai a plus de cinq versions mineures de retard. Faites-le tourner sur un cron du lundi, pas à chaque push — le but est un rappel hebdomadaire, pas un pipeline bloqué.

Ce qu'on surveille la semaine prochaine

L'API middleware est le signal le plus clair à ce jour qu'Anthropic traite le SDK comme une infrastructure managée, pas un simple client d'API. La question ouverte : le SDK agent reçoit-il une couche middleware parallèle, ou reste-t-il sur un modèle event-hook ? La vélocité du 0.3.x suggère que la réponse n'attendra pas.

On surveille aussi @google/genai, qui a atteint 2.8.0 le 3 juin — huitième mineure depuis 2.0.0 le 7 mai. Une version tous les cinq jours. Les équipes encore en 2.6.0 ont deux mineures de retard, soit plausiblement deux semaines d'alignement API Gemini qu'elles n'ont pas.

Le pattern plus large tient : la surface SDK AI bouge plus vite que la plupart des cycles de mise à jour de dépendances. Les revues trimestrielles sont désormais structurellement trop lentes. Les équipes qui restent à jour ne sont pas plus disciplinées — elles ont juste déplacé la vérification d'un rappel d'agenda vers la CI.

Si vous voulez un deuxième regard sur les parties de votre stack Anthropic qui doivent rester custom et celles qui sont désormais mieux managées, discutons.