Un tech lead vous dit "on devrait passer notre chatbot interne sur l'Agent SDK". Vous demandez ce qu'il fait aujourd'hui : single-turn avec function calling, un retriever, ça tourne. Réponse : "Oui mais le SDK c'est mieux."

Le SDK n'est pas mieux. Il est différent.

C'est la confusion que je vois revenir le plus souvent depuis que l'Agent SDK Anthropic est sorti. Une équipe entend "agent", lit la doc, décide de migrer, et se retrouve à débugger des couches d'abstraction sur un cas qui n'avait besoin de rien de plus qu'un appel d'API et un tool.

Ce que fait vraiment l'agent sdk anthropic (et ce qu'il ne fait pas)

Le SDK orchestre. Concrètement, il gère la boucle d'agent (le modèle appelle un tool, lit le résultat, décide du tour suivant), le chaînage de plusieurs tools dépendants, la délégation à des sous-agents spécialisés, et la compaction de contexte quand la conversation devient longue. Tout ce que vous coderiez à la main si vous deviez vous-même boucler sur les tool_use retournés par l'API.

Ce qu'il n'apporte pas : aucun nouveau modèle, aucune capacité d'inférence supplémentaire, aucune "intelligence" en plus. Sous le capot, c'est toujours Claude qui tourne, avec les mêmes limites, les mêmes hallucinations possibles, le même comportement. Le SDK est une couche d'orchestration, pas un upgrade.

L'Agent SDK ne rend pas Claude plus intelligent. Il rend votre orchestration plus paresseuse.

C'est une bonne nouvelle quand votre orchestration mérite d'être paresseuse. C'est une mauvaise nouvelle quand vous n'avez pas d'orchestration à faire en premier lieu.

Quand ça vaut le coup

Workflows multi-étapes avec dépendances entre tools

Imaginez un agent qui lit un document, extrait des entités, les requête contre une base de données, croise le résultat avec une API externe, puis génère un rapport. Cinq étapes, chacune dépend de la sortie de la précédente. Coder cette boucle à la main, c'est faisable, mais c'est précisément ce que le SDK fait nativement, avec gestion d'erreurs et reprises.

Agents avec sous-agents spécialisés

Pattern classique : un orchestrateur qui délègue à un agent "recherche", un agent "rédaction", un agent "vérification". Chaque sous-agent a son propre contexte, ses propres tools, et renvoie un résultat structuré au parent. Sans SDK, vous codez la délégation, le passage de contexte, la sérialisation des retours. Avec SDK, c'est l'API.

Long-running tasks où le contexte explose

Un agent qui tourne 30 minutes, accumule des centaines de messages, des résultats de tools volumineux, des étapes intermédiaires. Sans gestion active, vous explosez la fenêtre de contexte. Le SDK fait de la compaction native : il résume ou élague les parties anciennes pour garder l'agent fonctionnel. Si vous deviez faire ça vous-même, vous coderiez votre propre logique de compaction, et vous la déboguerez longtemps.

Quand ça n'apporte rien

Single-turn avec function calling

L'utilisateur pose une question, le modèle appelle un tool (ou pas), répond. Un round-trip, parfois deux. Pas de dépendances, pas de boucle, pas de sous-agents. À ce niveau, l'API Claude brute fait le job en 30 lignes de code. Le SDK ajoute une couche d'abstraction qui ne sert à rien et qui rend le debug plus opaque.

Pipeline déterministe avec étapes fixes

Vous savez à l'avance que vous allez faire l'étape A, puis B, puis C, dans cet ordre, à chaque exécution. Ce n'est pas un agent. C'est un workflow. n8n, Make ou un script Python sont meilleurs pour ça : visibilité, retries natifs, logs, gouvernance. J'ai détaillé pourquoi dans ce comparatif n8n vs Zapier vs Make. Mettre un agent SDK sur du déterministe, c'est utiliser un raisonneur probabiliste pour exécuter un if/else.

Vous avez déjà une orchestration custom qui marche

Votre code maison tourne en prod depuis six mois, vos équipes le maîtrisent, les bugs connus sont fixés. Migrer vers le SDK pour migrer, c'est de la dette technique gratuite. Le SDK n'apportera pas de gain qui justifie le coût de migration et la régression de stabilité. Restez sur ce qui marche tant qu'aucune limite ne vous force à bouger.

Le piège classique : reconstruire le SDK à la main

Pattern qu'on voit dans un sens comme dans l'autre.

Premier sens : des équipes codent leur propre boucle d'agent en 800 lignes, avec gestion de contexte custom, retry logic, parsing de tool calls maison. Six mois plus tard, ils découvrent que le SDK fait tout ça en 50 lignes, mieux testé, maintenu par Anthropic. Ils ont payé pour réinventer la roue.

Deuxième sens : des équipes forcent le SDK sur un cas single-turn parce que "c'est la nouvelle façon de faire". Elles débuggent des abstractions inutiles, se battent avec la config, et finissent par revenir à un appel d'API direct trois mois plus tard.

Le bon outil, c'est celui qui correspond à la complexité réelle de votre problème. Pas à la complexité que vous projetez dessus.

La question n'est jamais "quel outil est le plus moderne". C'est "quel outil colle à ce que je fais réellement".

Mes 3 questions de décision

Avant de migrer ou de partir sur le SDK, posez-vous ces trois questions dans cet ordre :

  1. Mon agent enchaîne-t-il plus de 2 appels de tools dépendants par tâche ?
  2. Ai-je besoin de sous-agents ou de gestion de contexte longue durée ?
  3. Mon code custom existant coûte-t-il plus à maintenir que la migration SDK ne coûterait à mettre en place ?

Si deux réponses sur trois sont oui, le SDK paie. Sinon, function calling brut suffit, et vous gagnez en simplicité ce que vous perdez en abstraction.

Pour conclure

La vraie question n'est pas "SDK ou pas SDK". C'est "agent ou pipeline ?". Sur les projets Claude qui arrivent sur ma table, 80% sont des pipelines déguisés en agents. Du déterministe avec un LLM dedans, présenté comme de l'agentique parce que le mot fait moderne.

Un pipeline déterministe avec un appel Claude pour une étape de raisonnement, ce n'est pas un agent. C'est un workflow qui utilise un LLM. La distinction n'est pas cosmétique : elle change l'outil, le coût, la dette technique, et la facilité de debug.

Si vous hésitez sur le rôle de l'Agent SDK Anthropic dans votre intégration Claude, je fais ce diagnostic en 30 minutes. Direction la page consultant Claude pour voir comment je travaille, ou le formulaire de contact si vous voulez attaquer directement.