LangGraph, CrewAI, Agents SDK : écarts des docs

Ces trois noms se retrouvent souvent dans le même titre. Les docs lues le 2026-10-18 ne les présentent pas comme des remplaçants. LangGraph est un runtime d’orchestration bas niveau. CrewAI sépare un flow, qui tient l’ordre, et un crew, qui fait collaborer des agents. L’Agents SDK Python d’OpenAI laisse un Runner enchaîner les tours. Aucun test n’a été exécuté pour écrire cette page, et aucun prix n’est recopié.

La lecture ne classe pas. Elle note ce que chaque documentation dit, puis les cas où l’autre option reste préférable.

LangGraph, d’après sa documentation

Page lue : LangGraph overview.

LangGraph s’y décrit comme un framework et un runtime d’orchestration, bas niveau, pour des agents longs et à état. Il ne prend pas en charge les prompts ni l’architecture à votre place. On peut y mélanger des étapes écrites à la main et des étapes décidées par un modèle, dans le même graphe. La page dit qu’on peut s’en servir sans LangChain. Si vous débutez, ou si vous voulez une abstraction plus haute, elle renvoie vers les agents LangChain, qui fournissent des boucles modèle et outils déjà écrites.

L’exemple de cette page construit un StateGraph, ajoute un nœud et des arêtes, appelle compile(), puis invoke(). Le débogage cité juste après passe par LangSmith, avec LANGSMITH_TRACING=true. LangSmith est présenté comme un produit à part. Cette page ne dit pas ce qu’il facture.

La persistance est sur Persistence. Un checkpointer enregistre l’état du graphe pour un fil, identifié par thread_id. Un store garde des données que vous définissez, au-delà d’un fil. InMemorySaver et MemorySaver vivent en RAM. Un redémarrage du processus les efface. Pour garder les checkpoints, la page cite PostgresSaver et SqliteSaver. Elle signale aussi qu’un thread_id trop long casse PostgresSaver : rester sous 255 caractères.

Les interruptions sont sur Interrupts. interrupt() suspend le graphe à l’endroit de l’appel, enregistre l’état, et attend. La page dit que l’attente n’a pas de délai annoncé : le graphe reste en pause jusqu’à une reprise. Il faut un checkpointer, et un thread_id. Sans ces deux-là, il n’y a pas d’état à recharger. Reprendre le même thread_id recharge le checkpoint. Un nouvel identifiant ouvre un fil vide.

CrewAI, d’après sa documentation

Pages lues : Introduction, Crews, Flows.

L’introduction présente deux objets. Un crew est une équipe d’agents qui collaborent sur des tâches. Un flow tient l’état et l’enchaînement. La page dit de commencer par un flow pour une application qu’elle appelle production-ready. Le crew sert à l’intérieur d’une étape, quand la tâche a besoin d’autonomie. Pour une automatisation simple, elle indique un flow avec des tâches Python, sans crew.

La page Crews décrit deux processus. sequential est le défaut : les tâches se suivent. hierarchical ajoute un manager. Il faut alors un manager_llm ou un manager_agent. La page documente aussi akickoff() pour une exécution async native, et kickoff_async(), qui enveloppe l’exécution synchrone dans un thread. Ce n’est pas le même mécanisme.

Un flow se code avec @start() et @listen(). Plusieurs méthodes @start() dont la condition est satisfaite peuvent partir ensemble. kickoff() renvoie la sortie de la dernière méthode terminée. L’état, dictionnaire ou modèle Pydantic, traverse les étapes. Après un run, flow.usage_metrics additionne les tokens de tous les appels de modèle du flow, y compris ceux des crews et des appels directs. La page prévient que kickoff().token_usage ne reflète que le dernier CrewOutput, pas ce total.

La même page Flows dit que chaque flow a remember, recall et extract_memories, et que cette mémoire survit aux runs parce qu’elle s’appuie sur LanceDB sur disque. Je n’ai pas ouvert la page Memory en entier. Si le stockage par défaut a bougé, c’est cette page-là qu’il faut relire.

Agents SDK Python, d’après sa documentation

La lecture porte sur openai-agents-python. Je n’ai pas ouvert un SDK du même nom dans un autre langage.

Le SDK se décrit comme un petit jeu de primitives. Un agent est un modèle avec des instructions et des outils. Les handoffs et Agent.as_tool() délèguent. Les guardrails valident une entrée ou une sortie. Runner enchaîne les tours. L’installation documentée est pip install openai-agents. L’exemple hello world suppose OPENAI_API_KEY. Il n’a pas été lancé ici.

La page d’accueil dit d’appeler l’API Responses directement si vous voulez tenir la boucle, l’envoi des outils et l’état, surtout pour un échange court. Elle dit d’utiliser le SDK si vous voulez que le runtime gère les tours, les outils, les guardrails, les handoffs ou les sessions.

L’orchestration distingue deux façons. Soit le modèle décide. Agent.as_tool() garde le manager responsable de la réponse finale. Un handoff rend le spécialiste actif pour la suite du tour. Soit le code décide : sortie structurée, chaîne d’agents, boucle avec un évaluateur, ou plusieurs agents lancés avec asyncio.gather.

Les sessions stockent l’historique pour vous. L’exemple est SQLiteSession. Avant chaque run, l’historique est relu et placé devant la nouvelle entrée. On ne combine pas une session avec conversation_id, previous_response_id ou auto_previous_response_id dans le même run. Si un run s’interrompt pour une approbation, la page dit de reprendre avec la même session, via result.interruptions et state.approve.

Les guardrails ne couvrent pas chaque agent d’une chaîne. L’entrée n’est vérifiée que pour le premier. La sortie, seulement pour celui qui produit le résultat final. Un tool guardrail court à chaque appel d’outil gardé. Le mode parallèle est le défaut : le guardrail et l’agent partent ensemble, donc un outil peut déjà avoir tourné si le blocage arrive trop tard. Le mode bloquant (run_in_parallel=False) attend la fin du guardrail avant de lancer l’agent.

Le tracing est actif par défaut. On le coupe avec OPENAI_AGENTS_DISABLE_TRACING=1, set_tracing_disabled(True), ou RunConfig.tracing_disabled. La page dit qu’il n’est pas disponible pour une organisation en Zero Data Retention.

La page Models dit que, si l’agent ne nomme pas de modèle, le SDK utilise gpt-5.6-luna. Ce n’est pas une mesure. Le chemin par défaut est l’API Responses. La même page documente un chemin vers un autre fournisseur, et le mélange de fournisseurs. Je n’ai pas vérifié, fournisseur par fournisseur, quelles fonctions manquent sur ce chemin.

Ce que les pages lues permettent de poser côte à côte

Point relu	LangGraph	CrewAI	Agents SDK Python
Ce que vous écrivez	Un graphe, compilé avant `invoke()` dans l’exemple	Un flow, et un crew seulement si l’étape le demande	Un agent, un Runner, des outils ou des handoffs
Mémoire citée	Checkpointer par fil, store entre les fils	`remember` / `recall`, LanceDB cité pour le disque	Session, l’exemple étant SQLite
Pause	`interrupt()`, checkpointer et `thread_id` requis	Non repris : pas de page dédiée ouverte ce jour-là	`interruptions`, puis `approve`
Exécution parallèle citée	Non détaillée dans les trois pages LangGraph ouvertes	Plusieurs `@start()` satisfaits peuvent partir ensemble	`asyncio.gather` dans l’orchestration par code
Trace	LangSmith, produit séparé	`usage_metrics` sur le flow	Tracing intégré, absent en ZDR
Modèle	Non imposé par les pages lues	Nommé dans le code des exemples	Défaut documenté si l’agent n’en nomme pas

Ce tableau ne donne pas de rang. Une case vide veut dire que la page ouverte ne traitait pas le point, pas que la fonction n’existe pas.

Quand chaque option a du sens

LangGraph mérite un essai si le chemin doit rester visible : quelles fonctions tournent, et depuis quel checkpoint on reprend après un plantage. La page Persistence est écrite pour ce cas. Il convient aussi à une orchestration qui ne doit pas dépendre du SDK d’un fournisseur de modèles. Les pages lues n’imposent pas le modèle.

CrewAI mérite un essai si vous décrivez le travail comme des agents avec des rôles et des tâches, dans un flow qui fixe l’ordre. Pour une étape simple, sa documentation conseille plutôt un appel direct dans le flow. Le processus hiérarchique exige un manager_llm ou un manager_agent d’après la page Crews.

L’Agents SDK mérite un essai si vous voulez que le Runner tienne les tours, les guardrails et les handoffs, surtout avec les modèles OpenAI sur le chemin Responses. SQLiteSession évite de recoller l’historique à la main lorsque ce stockage couvre le besoin. Pour un échange court dont vous voulez tenir la boucle, la page d’accueil renvoie vers l’API Responses sans le SDK. Ce sont des orientations de documentation, pas le résultat d’un essai.

Un script sans ces trois couches reste préférable si vous avez un seul appel de modèle et pas de reprise. Je n’ai pas mesuré le surcoût de maintenance. Je note seulement que chaque doc ajoute un objet à garder : graphe compilé, flow, ou Runner.

Lecture distincte : LangGraph ou CrewAI ?

Ce choix oppose deux styles d’orchestration, pas deux scores. LangGraph représente explicitement un flux sous forme de graphe et met en avant l’état persistant, les checkpoints et les interruptions reprenables. CrewAI propose un niveau plus orienté rôles et tâches : un flow porte l’enchaînement, et un crew peut être appelé dans une étape lorsque la collaboration d’agents est utile. Pour des étapes de code prévisibles, la documentation CrewAI conseille même de garder le flow sans crew.

Les deux documentations décrivent du parallélisme, mais à des endroits différents : CrewAI indique que plusieurs méthodes @start() satisfaites peuvent partir ensemble ; les pages LangGraph déjà lues pour ce comparatif ne détaillent pas un modèle de parallélisme dans les pages citées. Ce n’est pas une preuve d’absence dans LangGraph. Pour le diagnostic, LangGraph renvoie notamment à LangSmith ; CrewAI expose des métriques d’usage du flow dans sa documentation. En production, comparez la reprise sur erreur, le stockage de l’état et l’observabilité dont votre équipe a besoin, pas seulement la concision d’un exemple.

LangGraph est une abstraction plus basse et ne choisit ni prompt ni architecture à votre place ; CrewAI fournit des objets de plus haut niveau mais la séparation flow/crew reste à maintenir. Les pages lues ne permettent pas de conclure à une dépendance obligatoire à un fournisseur de modèle. Aucune exécution, mesure de maintenance ou comparaison de latence n’a été faite.

Lecture distincte : Agents SDK ou LangChain ?

Les pages officielles présentent l’Agents SDK Python d’OpenAI comme un petit ensemble de primitives et un Runner qui gère les tours, outils, guardrails et handoffs. LangChain propose une abstraction de plus haut niveau pour construire une boucle d’agent ; LangGraph, son runtime bas niveau, peut aussi être utilisé sans LangChain. L’Agents SDK documente des sessions (dont SQLiteSession), des délégations, un tracing intégré et une voie documentée vers d’autres fournisseurs ; la page Models décrit néanmoins Responses comme le chemin par défaut et certaines fonctions peuvent dépendre du modèle ou du fournisseur. LangChain/LangGraph fournit checkpoints et store séparés pour l’état par fil et la mémoire durable, avec LangSmith présenté comme service distinct pour le traçage.

Le SDK d’OpenAI convient à qui souhaite déléguer au Runner le cycle d’agent et employer les primitives proposées. LangChain convient à qui veut un agent préconstruit et un écosystème d’intégration ; LangGraph convient à qui veut contrôler finement le flux et la reprise. Ces différences sont des choix d’abstraction et de runtime, pas une garantie de moindre maintenance. Vérifiez l’observabilité, les formats d’état, les mécanismes de reprise et les fonctions conservées lorsque vous changez de fournisseur. Les pages mentionnées ne constituent pas un test comparatif et ne suffisent pas à prédire les coûts d’exploitation.

Ce qui n’a pas été fait

Aucun test n’a été exécuté. Aucun des trois paquets n’a été installé pour cette page. Aucun prix n’est recopié : ni jeton, ni offre LangSmith, ni offre CrewAI Enterprise. Un montant lu plus tard sur une page tarifaire reste à vérifier. Il n’est pas ici.

Sources

Sources officielles revérifiées le 19 octobre 2026. Les exemples et commandes viennent de ces documentations ; ils n’ont pas été exécutés pour cet article.