Agents SDK 2026 : OpenAI, Claude, Microsoft, LangChain, CrewAI

La question utile : “quel runtime d’agent ?” (pas “quel LLM ?”)

On voit souvent la conversation partir comme ça :

“On prend Claude / GPT / Gemini, et on fait un agent.”

Oui. Et non.

Parce que le modèle, c’est le moteur. Un agent, c’est la voiture plus :

• la boîte de vitesses (tool calling),
• le tableau de bord (traces, métriques),
• les freins (permissions, policies),
• la mémoire (état, RAG, profil),
• et la mécanique (retry, timeouts, idempotence).

Donc en vrai, votre décision n’est pas “un modèle”. Votre décision est un contrat d’exploitation.

Si vous voulez une base sur l’architecture, je vous conseille de lire d’abord : Architecture d’un agent IA.

Deux grandes familles : provider-first vs framework-first

1) Provider-first (SDKs “officiels”)

Le principe : vous prenez l’écosystème du fournisseur (modèles + outils + observabilité), et vous construisez dedans.

Exemples :

• OpenAI Agents SDK (Node.js/Python).¹
• Claude Agent SDK (dans l’écosystème Claude/Anthropic).²

Avantages :

• intégration rapide,
• tool calling bien cadré,
• traçabilité intégrée (souvent),
• patterns “batteries included”.

Inconvénients :

• dépendance au fournisseur,
• certaines abstractions imposées,
• migration parfois coûteuse si vous changez de stack.

2) Framework-first (orchestration neutre)

Le principe : vous construisez une architecture “agnostique”, puis vous branchez un ou plusieurs modèles.

Exemples :

• LangChain Agents.³
• LangGraph (state machines / graph).⁴
• CrewAI (multi-agent orienté rôles).⁵
• LlamaIndex (data + retrieval, souvent utilisé dans des agents).⁶

Avantages :

• liberté de design,
• multi-providers plus naturel,
• migrations plus simples si vous changez de modèle,
• meilleure séparation “agent runtime” vs “fournisseur”.

Inconvénients :

• plus d’ingénierie (observabilité, évaluations, guardrails),
• plus de décisions à prendre (et donc plus de façons de se tromper),
• “ça marche” vite, “ça tient” plus lentement.

OpenAI Agents SDK : vite, traçable, tool-first

OpenAI documente son Agents SDK (Node.js et Python) comme une approche orientée “agents” avec tool calling et traçabilité (“full trace”).¹

Ce qui est intéressant dans ce type de SDK :

• une API agent “haut niveau” plutôt qu’un patchwork de prompts,
• un vocabulaire explicite (agents, tools, traces),
• des primitives d’évaluation (ex. trace grading).⁷

En clair : vous gagnez du temps sur la plomberie. Mais vous acceptez que la plomberie ressemble à OpenAI.

Agent Builder : la voie rapide (et quand l’éviter)

OpenAI documente aussi Agent Builder comme un canvas visuel pour construire des workflows multi-étapes.¹³

C’est utile pour :

• prototyper vite un flux,
• rendre un workflow lisible par une équipe non-dev,
• tester l’enchaînement (sans écrire d’orchestrateur).

Mais il y a une loi physique des projets : ce qui marche en démo finit en prod.

Donc posez-vous une question simple :

Est-ce que je dois versionner, tester, rejouer, auditer, et déployer via CI/CD ?

Si oui, vous aurez tôt ou tard besoin d’un socle “code-first”. Agent Builder peut être le début. Rarement la fin.

Claude Agent SDK : subagents, permissions, MCP (et un ton très “prod”)

Anthropic documente un Claude Agent SDK avec des notions utiles pour le monde réel : subagents, hooks, permissions et intégrations via MCP.²

Deux points à retenir :

1. Subagents : vous externalisez des rôles spécialisés (ex. “auditeur”, “extracteur”, “rédacteur”), au lieu de mettre tout dans un seul prompt géant. C’est plus stable, parce que vous réduisez la charge cognitive du modèle.

2. Permissions : l’agent n’est pas “admin”. Il fonctionne avec un modèle d’autorisation qui force à expliciter ce qui est permis. Très bon signal.

Et sur la question des intégrations, l’écosystème Claude met en avant MCP (Model Context Protocol) comme standard d’outils.²⁸

Point de gouvernance important (et souvent mal compris)

Anthropic précise qu’il n’est pas autorisé pour un tiers de réutiliser les rate limits / login de Claude.ai pour proposer un produit (y compris des agents) : il faut passer par de l’authentification API (API keys).²

Traduction : si vous bricolez une intégration qui “emprunte” une souscription grand public (ou un jeton OAuth) pour faire tourner un agent chez vos clients, vous vous exposez à des restrictions, voire une suspension.

Ce n’est pas un détail “juridique”. C’est un risque opérationnel.

Microsoft : Agents SDK, Semantic Kernel, AutoGen (et l’entreprise autour)

Quand on dit “Microsoft Agent SDK”, on parle souvent de trois choses différentes. Et mélanger les trois est une source de réunions inutiles.

Microsoft 365 Agents SDK

Microsoft documente un Microsoft 365 Agents SDK pour construire des agents intégrés à l’écosystème Microsoft 365 (Teams, etc.).⁹

Ce type de SDK est pertinent si :

• votre surface produit est déjà dans M365,
• vous voulez déployer des agents “là où les gens travaillent” (Teams),
• vous privilégiez le gouvernable (tenant, permissions, admin).

Azure AI Foundry Agent Service : l’agent “enterprise” côté Azure

Si votre terrain est Azure, Microsoft documente aussi Foundry Agent Service : une couche agentique qui fournit des outils pour accéder à de la connaissance d’entreprise (ex. SharePoint, Azure AI Search) et déclencher des actions (ex. Azure Functions, Logic Apps, OpenAPI).¹⁴

C’est typiquement le choix “plateforme” quand :

• vous avez déjà un socle Azure fort,
• vous voulez des intégrations enterprise out-of-the-box,
• et vous priorisez la gouvernance (tenant, IAM, ressources).

Le piège, là aussi, est humain : croire que “plateforme” remplace “design produit”. Un agent enterprise sans KPI métier reste… une expérience.

Semantic Kernel

Semantic Kernel est un SDK open source de Microsoft, orienté construction d’applications IA (fonctions, planification, connecteurs).¹⁰

L’intérêt en agentic : vous structurez le raisonnement en modules. Moins “agent magique”, plus “application IA propre”.

AutoGen

AutoGen (Microsoft) se présente comme un framework de programmation pour construire des applications agentiques et multi-agents.¹¹

AutoGen devient intéressant quand vous voulez :

• modéliser des conversations entre agents,
• orchestrer des rôles (planner, executor, critic),
• tester des stratégies d’interaction.

LangChain / LangGraph : l’orchestration neutre (et les garde-fous à construire)

LangChain documente le concept d’agents comme des systèmes qui choisissent des outils de manière dynamique.³

Le souci (et c’est normal) : LangChain ne peut pas prendre vos décisions à votre place.

Donc vous devez construire :

• la gouvernance des outils,
• les logs / traces,
• l’évaluation,
• et les stratégies d’échec.

LangGraph est souvent utilisé quand vous voulez rendre l’agent moins “imprévisible”, via des graphes d’états et des transitions explicites (un agent comme state machine).⁴

CrewAI et LlamaIndex : deux philosophies utiles

CrewAI : rôles, équipe, coordination

CrewAI met l’accent sur des “crews” : plusieurs agents spécialisés avec un objectif commun, coordonnés via des rôles et des tâches.⁵

C’est utile pour :

• la recherche + synthèse,
• la production de contenu,
• des workflows où la spécialisation “par rôle” est naturelle.

En B2B, la limite arrive vite : la conformité et l’audit. Donc CrewAI marche très bien… si vous ajoutez une couche de gouvernance.

LlamaIndex : la donnée d’abord

LlamaIndex se définit comme un framework de données pour applications LLM : ingestion, indexation, retrieval, et intégration de sources.⁶

Dans les agents, LlamaIndex sert souvent à :

• construire un RAG robuste,
• structurer des sources,
• ajouter du versioning et des métadonnées.

MCP : standardiser les outils (et arrêter d’écrire 200 connecteurs)

Le rêve d’un agent, c’est d’avoir des outils propres. Le cauchemar d’un agent, c’est d’avoir 37 intégrations bricolées.

MCP (Model Context Protocol) vise à standardiser comment un modèle/agent se connecte à des outils et des contextes externes (serveurs MCP, clients).⁸

Vous le verrez apparaître partout :

• dans des stacks provider-first (Claude Agent SDK le mentionne),
• dans des stacks multi-outils,
• et dans des orchestrateurs qui veulent “plugger” des connecteurs sans réinventer.

OpenClaw : orchestrer des “harness” externes (Claude Code, Gemini CLI, etc.)

OpenClaw documente un système d’“ACP sessions” qui permet de piloter des harness externes (ex. Claude Code, Codex, Gemini CLI) depuis OpenClaw.¹²

Pourquoi c’est intéressant ?

• vous pouvez réutiliser des environnements outillés,
• lancer des agents spécialisés (coding, browsing, etc.),
• et centraliser l’orchestration.

Pourquoi ça mérite une alerte ?

• la surface d’attaque augmente (vous pilotez des CLIs),
• la gestion des secrets devient critique,
• et surtout : les conditions d’utilisation des fournisseurs doivent être respectées.

Si vous routez des workloads “produit” via une souscription grand public (Claude Code, Gemini, etc.) dans un orchestrateur, vous jouez avec le feu : quotas, détection d’abus, suspension, rotation de tokens… et incident lundi matin.

Si vous voulez une lecture centrée sur la messagerie, la sécurité et le self-hosting : OpenClaw : faut-il l'utiliser pour des agents en messagerie ?

Grille de décision (simple, mais qui marche)

Je vous propose une grille “anti-bullshit” : vous scorez chaque option sur 7 critères.

1. Tool calling (stabilité, schémas, erreurs)
2. Traçabilité (traces lisibles, rejouabilité)
3. Gouvernance (permissions, policies, RBAC)
4. Évaluation (datasets, scoring, regression)
5. Multi-modèles (switch provider, fallback)
6. Déploiement (cloud, on-prem, contraintes)
7. Écosystème (connecteurs, communauté, support)

Et pour rendre ça concret, voici une comparaison de philosophie (pas un classement) :

Mini arbre de décision (2 minutes)

Si vous voulez une décision rapide sans faire semblant :

• Vous devez livrer une première phase pilote en moins de quatre semaines, mono-provider assumé → provider-first (OpenAI/Claude), avec traces + évaluations dès le jour 1.
• Vous voulez rester multi-modèles (ou vous avez déjà 2 fournisseurs) → framework-first (LangGraph/LangChain), et vous investissez dans observabilité + gouvernance.
• Votre terrain naturel est M365 / Azure, et l’IT veut du contrôlable → Microsoft 365 Agents SDK / Foundry Agent Service.
• Vous orchestrez des agents “outillés” via CLIs et environnements externes → OpenClaw peut aider, mais vous montez d’un cran en sécurité et en compliance.

Ce n’est pas “le meilleur framework”. C’est “le meilleur compromis pour votre réalité”.

Et si vous hésitez encore : commencez petit, mesurez, puis élargissez.

Anti-patterns (que je vois tout le temps)

Si vous voulez aller plus vite, voici ce qu’il faut éviter.

1) Le “tool soup” (l’agent avec 40 outils)

Plus vous donnez d’outils, plus l’agent :

• hésite,
• appelle n’importe quoi,
• et devient difficile à gouverner.

Commencez avec 3 outils, pas 30. Ajoutez ensuite, quand vous avez des traces et des erreurs réelles.

2) Le multi-agent “pour faire joli”

Le multi-agent est utile quand la spécialisation est nécessaire. Mais si vous multipliez les agents sans raison, vous multipliez :

• les interactions,
• les coûts,
• les surfaces d’erreur,
• et la difficulté de debugging.

Le bon multi-agent n’est pas “une équipe”. C’est une architecture où chaque rôle est testable et observable.

3) L’observabilité “à la fin”

Sans traces et évaluation, vous pilotez à l’oreille. Et vous allez prendre des décisions à partir de ressentis (“j’ai l’impression que…”).

Je le dis sans méchanceté : la prod déteste les impressions.

4) Les identifiants partagés (ou “ça marchait sur mon laptop”)

Clés API copiées dans un prompt. Jetons OAuth dans un fichier. Compte partagé entre 12 personnes.

Ça marche jusqu’au jour où ça ne marche plus. Et quand ça casse, ça casse en incident, pas en warning.

FAQ

Questions frequentes

Quel choix pour un premier agent B2B ?+

Si vous débutez : un SDK provider-first (OpenAI Agents SDK ou Claude Agent SDK) + une tâche fermée + une couche de vérification. Vous apprendrez plus vite, et vous aurez des traces. Ensuite, vous “généraliserez” vers un framework neutre si besoin.

LangChain vs LangGraph : je prends quoi ?+

LangChain pour assembler des composants. LangGraph quand vous voulez formaliser un workflow agentique comme un graphe d’états (plus gouvernable). Les deux se combinent.

Open source = plus conforme ?+

Pas automatiquement. Open source / open-weight = plus contrôlable. La conformité dépend surtout de votre gouvernance : accès, logs, base légale, minimisation, et sécurité.

Le risque #1 en prod ?+

Une combinaison : trop de permissions + pas de traces + pas d’évaluation. C’est le trio qui transforme un incident en mystère.

Sources et references

1. [1]OpenAI, “Agents SDK” (guide).
2. [2]Anthropic (Claude), “Agent SDK overview” (subagents, permissions, MCP, policy).
3. [3]LangChain, “Agents” documentation.
4. [4]LangGraph (LangChain), “LangGraph” GitHub repository.
5. [5]CrewAI, documentation (Getting Started).
6. [6]LlamaIndex, documentation (Framework overview).
7. [7]OpenAI, “Trace grading” (agents).
8. [8]Model Context Protocol, “Introduction”.
9. [9]Microsoft Learn, “Microsoft 365 Agents SDK documentation”.
10. [10]Microsoft Semantic Kernel (GitHub).
11. [11]Microsoft, “AutoGen” (GitHub).
12. [12]OpenClaw Documentation, “ACP Agents” (sessions pour Claude Code, Codex, Gemini CLI…).
13. [13]OpenAI, “Agent Builder” (guide).
14. [14]Microsoft Learn, “What is Foundry Agent Service?”