LangGraph, CrewAI, OpenAI, Google, Microsoft, Claude : quel framework d’orchestration agentique choisir ?

Que fait vraiment un framework d’orchestration ?

Un agent seul, c’est un modèle dans une boucle, avec des outils. Dès que le travail dépasse une boucle, il faut répondre à trois questions : qui décide de l’étape suivante (le code ou le modèle), où vit l’état entre deux étapes, et comment un humain reprend la main. C’est exactement ce que règle un framework d’orchestration.

Les six frameworks de l’infographie répondent différemment à la première question, et c’est la plus importante. À un bout, le développeur dessine le chemin et le modèle ne fait que remplir les cases. À l’autre, le modèle choisit lui-même ses outils et ses délégations, et le code se contente de fixer des limites. Entre les deux, toutes les nuances existent.

Quelles sont les six grandes approches ?

LangGraph : le graphe avec état. On décrit l’application comme un graphe : des nœuds (un appel de modèle, un outil, une fonction) reliés par des arêtes, dont certaines sont conditionnelles. Un état typé circule de nœud en nœud et peut être sauvegardé à chaque étape (checkpoint), ce qui permet de reprendre une exécution interrompue, de rejouer un état passé ou de mettre le graphe en pause pour une validation humaine. C’est l’option qui donne le plus de contrôle explicite, au prix d’un peu plus de code.

CrewAI : l’équipe de rôles. On définit des agents par leur rôle, leur objectif et leur contexte, puis des tâches qu’on leur confie. L’équipe (« crew ») les exécute en séquence ou sous la coordination d’un agent manager. Le modèle mental est très lisible pour les métiers : on décrit une équipe comme on décrirait une organisation. Pour les parties qui doivent rester déterministes, CrewAI propose aussi des « Flows », pilotés par événements.

Microsoft Agent Framework : le workflow d’entreprise. C’est le successeur de Semantic Kernel et d’AutoGen, publié en version 1.0 en avril 2026 pour .NET et Python. Il distingue clairement l’agent (un modèle qui appelle des outils) et le workflow : un graphe typé qui enchaîne agents et fonctions, avec branches, parallélisme, checkpoints et approbation humaine. Il reprend les schémas d’orchestration issus d’AutoGen (séquentiel, concurrent, handoff, group chat, Magentic-One) et se connecte à plusieurs fournisseurs de modèles, à MCP et à A2A.

OpenAI Agents SDK : la délégation. Le SDK repose sur peu de primitives : des agents, des outils, des « handoffs » (un agent transfère la conversation à un agent plus spécialisé) et des agents utilisés comme outils (un agent en appelle un autre et garde la main). S’y ajoutent des garde-fous sur les entrées et sorties, des sessions pour la mémoire de conversation et un traçage intégré. C’est l’approche la plus légère pour un tri suivi d’un transfert vers le bon spécialiste.

Google ADK : agents et workflows, en hiérarchie. L’Agent Development Kit combine des agents pilotés par le modèle et des agents « workflow » déterministes : séquentiel, parallèle et boucle. On les emboîte en arbre, sous un agent racine. ADK est optimisé pour Gemini et Google Cloud, mais il reste ouvert à d’autres modèles, et il prend en charge le protocole A2A pour faire dialoguer des agents entre systèmes.

Claude Agent SDK : la boucle d’agent outillée. Le SDK expose la boucle qui fait tourner Claude Code : le modèle collecte du contexte, agit avec des outils (fichiers, commandes, serveurs MCP), vérifie le résultat et recommence jusqu’à ce que la tâche soit terminée. L’orchestration passe par des sous-agents, qui travaillent dans leur propre contexte et ne renvoient que leur résultat, et par des hooks qui peuvent bloquer un appel d’outil avant son exécution. Il est taillé pour les tâches longues, riches en outils, où l’on ne peut pas dessiner le chemin à l’avance.

Lequel choisir, selon votre situation ?

Le tableau ci-dessous est ma propre lecture, pas un benchmark. Il compare ce qui compte au moment de décider.

Quelles règles appliquer pour trancher ?

Trois règles simples m’évitent la plupart des mauvais choix :

• Si vous pouvez dessiner le processus, dessinez-le. Un graphe ou un workflow (LangGraph, Microsoft Agent Framework, les workflows d’ADK) est plus facile à tester, à auditer et à faire valider par un métier.
• Si le chemin dépend de ce que l’agent découvre, laissez le modèle piloter, mais dans une boîte. C’est le terrain de la boucle d’agent et de la délégation (Claude Agent SDK, OpenAI Agents SDK), avec des limites d’étapes, de coût et d’outils.
• Choisissez d’abord l’écosystème que vos équipes savent exploiter. Un framework moyen bien exploité vaut mieux qu’un excellent framework que personne ne sait déboguer à 2 h du matin.

Quels pièges apparaissent en production ?

Le choix du framework est rarement ce qui fait échouer un projet. Ce qui coince, ce sont les mêmes sujets, quel que soit le logo.

L’état. Un agent qui travaille plusieurs minutes, ou qui attend une validation, doit pouvoir s’interrompre et reprendre sans tout recommencer. Vérifiez où l’état est stocké, s’il survit à un redémarrage et qui peut le lire. Les checkpoints de LangGraph ou de Microsoft Agent Framework répondent à cette question ; dans une approche plus libre, c’est à vous de la traiter.

L’humain dans la boucle. « Un humain valide » n’est pas une spécification. Il faut décider quelles actions exigent une approbation (envoyer, payer, supprimer, publier), qui approuve, dans quel délai, et ce qui se passe sans réponse. Concevez ces points d’arrêt dès le départ : les ajouter après coup oblige souvent à revoir toute l’orchestration.

L’observabilité. Sans trace de chaque appel de modèle et d’outil, un système multi-agents devient une boîte noire. Exigez dès le premier jour une trace par exécution : prompts, outils appelés, arguments, résultats, durée et coût. Les SDK proposent tous une forme de traçage, mais vérifiez qu’elle s’exporte vers vos propres outils (OpenTelemetry, par exemple) plutôt que de rester chez un fournisseur.

Le coût. Chaque agent supplémentaire, chaque boucle de réflexion, chaque délégation ajoute des appels de modèle. Fixez des budgets d’étapes et de jetons par exécution, mesurez le coût par tâche réussie, et alertez sur les exécutions extrêmes. Un agent qui boucle ne coûte pas seulement du temps.

La dépendance et la souveraineté. Trois des six frameworks viennent de fournisseurs de modèles, deux d’éditeurs cloud. Ils fonctionnent tous mieux avec leur écosystème d’origine, même quand ils acceptent d’autres modèles. Posez-vous trois questions avant de vous engager : peut-on changer de modèle sans réécrire l’orchestration ? Où sont hébergés les traces et l’état ? Que se passe-t-il si une fonctionnalité hébergée disparaît ou change de prix ? Pour les données sensibles, isolez la logique métier (outils, règles, prompts) dans votre propre code, et traitez le framework comme une couche remplaçable.

Par où commencer ?

Mon conseil reste le même, quel que soit le framework : commencez par un seul agent, avec deux ou trois outils et du traçage. Mesurez où il échoue. N’ajoutez un deuxième agent, un graphe ou une délégation que lorsqu’une limite mesurée l’exige. La plupart des cas d’usage en entreprise n’ont pas besoin de six agents qui discutent entre eux : ils ont besoin d’un processus clair, d’un agent fiable et d’un humain au bon endroit.