Comparaison de six frameworks d’agents IA en Python grâce à la création du même agent.
Le même agent de recherche intégré dans LangGraph, CrewAI, PydanticAI, OpenAI Agents SDK, Smolagents et Google ADK, avec des lignes, des tokens, des scores de débogage et un guide de sélection.
Si vous demandez à un groupe quel framework d’agent utiliser, vous obtiendrez une douzaine de réponses confiantes mais contradictoires. Un camp qualifie LangGraph d’overengineered. Un autre le considère comme la seule option sérieuse. Un troisième conseille d’éviter complètement les frameworks et de communiquer directement avec l’API du modèle. Un projet client rend ces débats coûteux, donc la solution pratique est d’arrêter de discuter et de mener une expérience.
L’expérience menée ici était simple : développer l’agent identique dans six frameworks Python en un week-end, en utilisant la même tâche, le même modèle, les mêmes outils et la même méthode d’évaluation. Le projet en question correspondait à un pipeline d’analyse de documents selon les standards de 2026, ce qui impliquait de récupérer des données à partir de PDF, de les croiser avec une base de données, d’écrire un résumé et d’envoyer le résultat par e-mail. Les résultats ne sont favorables à aucun des camps les plus bruyants.
Ce qui a été développé et comment il a été évalué
L’agent de test accepte le nom d’une entreprise, recherche des nouvelles récentes sur le Web, extrait les principaux chiffres financiers, les compare avec une base de données SQLite locale et renvoie un résumé structuré en JSON. Il s’agit donc de trois outils, un agent et un schéma de sortie.
C’est fait exprès pour être ennuyeux. Presque personne ne déploie un agent de codage autonome comme premier système de production. La plupart des applications d’agents réels sont en réalité des orchestrateurs d’API avec un peu de raisonnement en plus, et tout framework devrait pouvoir gérer cela sans problème. GPT-4o a servi de modèle partout où un framework le permettait.
Cinq critères ont été mesurés :
- le nombre de lignes de code nécessaires
- le nombre de tokens par exécution, en moyenne sur 10 exécutions
- la latence moyenne
- le nombre d’heures nécessaires pour passer de zéro à un prototype fonctionnel
- un « score de débogage à 2 h du matin », indiquant la facilité avec laquelle on peut identifier la cause d’un problème lorsque le processus échoue tard dans la nuit
Cette dernière métrique est plus importante qu’il n’y paraît. Les choses se cassent toujours.
LangGraph : pour ceux qui aiment avoir le contrôle
Environ 210 lignes. Trois heures pour obtenir un agent fonctionnel. 2 847 tokens par exécution.
LangGraph a l’air d’avoir été conçu par des ingénieurs en systèmes distribués. On définit l’état, on définit les nœuds, on relie des arêtes entre eux et on compile le résultat. Cela ressemble moins à la création d’un agent IA qu’à l’organisation d’un pipeline de données, ce qui est un compliment.
La première heure est difficile. Voir StateGraph, add_node et add_conditional_edges pour un agent à trois outils semble être une procédure bien trop compliquée, ce qui pousse à envisager un autre candidat.
Alors, une panne change complètement la situation. Lors de la troisième requête de test, l’agent a échoué gravement, et l’ouverture de LangSmith a montré l’ensemble du déroulement étape par étape : quel nœud a pris la mauvaise décision, quel état il était dans, et pourquoi il a appelé l’outil de base de données avant de procéder à la recherche. Peu de frameworks permettent un diagnostic aussi direct.
La fonctionnalité que les gens mentionnent rarement : l’exécution durable. Une exécution interrompue reprend à partir de son dernier point de contrôle. C’est pratique pour des expériences le week-end. Mais dans un pipeline qui traite 10 000 documents en une nuit, cela détermine si vous pouvez dormir ou si vous serez réveillé à 3 heures du matin.
LangGraph a également utilisé le moins de tokens lors du test. Comme le graphe décrit explicitement le flux de contrôle, le modèle n’a pas besoin de gaspiller des tokens pour déterminer ce qui vient ensuite. Vous le lui avez déjà indiqué.
Le coût implique une réflexion préalable. Il n’y a pas de place pour coller des instructions et espérer du résultat. Un problème bien défini permet d’adopter une structure adaptée, mais si vous êtes encore en train de définir le flux de travail, vous créerez plus de graphiques que de fonctionnalités réelles.
Score de débogage à 2 h du matin : 9/10. LangSmith mérite sa réputation, et les problèmes ont été diagnostiqués ici plus rapidement que n’importe où ailleurs.
CrewAI : l’outil pour créer rapidement des prototypes
Environ 340 lignes de code. 45 minutes pour obtenir un agent fonctionnel. 4 216 tokens par exécution.
Il a fallu trois quarts d’heure pour passer de pip install crewai à une sortie correcte, ce qui représente le démarrage le plus rapide parmi tous les outils, à part Smolagents.
CrewAI fonctionne en équipes, et non avec des agents individuels. Chaque membre a un rôle, un objectif et une histoire personnelle ; les tâches sont attribuées au groupe, et les membres décident ensemble qui fait quoi.
researcher = Agent(
role="Financial Research Analyst",
goal="Find and verify recent financial data",
backstory="You're a senior analyst at a hedge fund...",
)
Le champ des informations contextuelles semble être une gimmick, ce qui a suscité des regards sceptiques. Cependant, les résultats générés par l’agent CrewAI étaient nettement plus détaillés que ceux obtenus avec la même demande envoyée via des appels API directs, ce qui montre bien que la définition du rôle influence la manière dont le modèle aborde la tâche.
La vitesse a un prix. CrewAI a consommé environ 48 % de tokens de plus que LangGraph pour effectuer la même tâche. L’architecture prévoit au moins deux ou trois agents collaborant, de sorte que même une tâche pouvant être accomplie par un seul agent, comme celle d’un chercheur accompagné d’un rédacteur, nécessite des allers-retours liés à la délégation. De plus, le système fonctionne de manière synchrone, et l’intégration dans un backend FastAPI asynchrone a exigé l’encapsulation des appels dans run_in_executor. C’est supportable, mais plutôt agaçant.
Les coûts augmentent rapidement. Une comparaison publiée indique que les dépenses liées aux tests avec CrewAI s’élèvent à 1 088 dollars, contre 390 dollars pour une version équivalente de PydanticAI. Si l’on exécute l’agent des milliers de fois par jour, l’écart ne cesse de croître.
Sur l’échelle de débogage, il obtient 5/10 à 2 h du matin. Les succès sont merveilleux, mais les échecs disparaissent au sein d’une chaîne de délégation qui se comporte comme une boîte noire. Un bug a pris 40 minutes avant que l’on découvre qu’il s’agissait en réalité de deux agents qui se transmettaient la même tâche sans cesse.
PydanticAI : l’overperformer discret
Environ 130 lignes. 1,5 heure pour obtenir un agent fonctionnel. 2 912 tokens par exécution.
Si LangGraph convient à ceux qui cherchent un contrôle total et CrewAI aux impatients, PydanticAI est fait pour les développeurs qui veulent que leur code soit fonctionnel en six mois. L’équipe de Pydantic l’a conçu, et quiconque a déjà utilisé FastAPI connaît déjà la moitié de son API. Les agents sont typés, les sorties sont validées et les dépendances sont injectées, de sorte que tout ce qui peut être détecté avant l’exécution l’est bel et bien.
agent = Agent(
"openai:gpt-4o",
result_type=CompanyAnalysis, # Pydantic model
system_prompt="You are a financial research assistant.",
)
L’argument result_type a des fonctions plus importantes qu’il n’y paraît. Chaque réponse du modèle est automatiquement vérifiée par rapport à votre schéma. Lorsque le modèle renvoie du JSON mal formaté, ce qui arrivera inévitablement, le framework le détecte et tente à nouveau, sans nécessiter de code de validation manuel.
Le projet full-stack-ai-agent-template a mené une comparaison contrôlée conforme à ce schéma. La même application de chat nécessitait environ 160 lignes efficaces avec PydanticAI, autour de 280 avec LangGraph et près de 420 avec CrewAI.
Un code plus court n’est pas automatiquement meilleur, mais ici on a mesuré la vitesse à laquelle chaque version pouvait être comprise. La version PydanticAI pouvait être lue et saisie ligne par ligne. La version LangGraph exigeait de reconstituer mentalement le graphe, tandis que la version CrewAI nécessitait de comprendre son modèle de délégation.
La limite réside dans le fait que PydanticAI est un framework à un seul agent. Il ne dispose d’aucune orchestration multi-agents intégrée, ni de mécanismes de transfert ou de délégation, ce qui signifie que pour un système à trois agents, il faut écrire soi-même les mécanismes de coordination. Le module pydantic-graph existe bien, mais il n’égale pas encore LangGraph ou CrewAI pour les workflows complexes.
Le débogage tard dans la nuit obtient une note de 8/10 : les erreurs de type apparaissent tôt, l’IDE signale les problèmes avant même que quoi que ce soit ne s’exécute, et les traces d’exécution indiquent directement la ligne concernée.
OpenAI Agents SDK : le succès discret
Environ 150 lignes de code. Une heure pour obtenir un agent fonctionnel. 2 791 tokens par exécution.
Un framework fourni par le fournisseur du modèle peut sembler être un moyen de verrouiller l’utilisateur, et il a failli être exclu du test. Cette attente s’est avérée fausse.
Le SDK est la version mise en production par OpenAI de son ancien projet Swarm, et il se résume à quatre primitives : les Agents, les Handoffs, les Outils et les Guardrails. Les Handoffs sont les éléments les plus remarquables : vous déterminez quels agents peuvent transférer des tâches à d’autres, et le framework s’occupe du routage. Il est moins flexible que le modèle graphique de LangGraph, mais pour environ 80 % des cas d’usage multi-agents, cela suffit et il est bien plus simple.
agent = Agent(
name="Researcher",
instructions="You are a financial research assistant.",
tools=[search_tool, db_tool],
handoffs=[summary_agent],
)
Il n’est plus non plus lié à un seul fournisseur. Le support de plus de 100 LLMs est désormais possible grâce à un adaptateur any-llm, et le même test a pu être exécuté avec Claude sans aucune modification de code.
L’efficacité en termes de tokens est équivalente à celle de LangGraph, ce qui en fait l’option la moins performante du test. Le suivi intégré est solide, bien qu’un peu inférieur à celui de LangSmith.
L’inconvénient réside dans un écosystème plus restreint. LangGraph dispose de nombreuses années d’outils communautaires, de tutoriels et de modèles éprouvés. Ici, le produit est plus récent, ce qui signifie que face à des cas particuliers, on se retrouve souvent seul.
Score de débogage à 2 h du matin : 7/10. Le suivi est intégré et utile, et les erreurs sont claires. Cependant, des lacunes dans la documentation obligent à lire le code source plus souvent que ce que l’on souhaiterait.
Smolagents : le choix des minimalistes
Environ 95 lignes. 30 minutes pour obtenir un agent fonctionnel. 3 340 tokens par exécution.
Ces chiffres ne sont pas une erreur de frappe. Hugging Face prend le minimalisme très au sérieux, avec une logique de base composée d’environ 1 000 lignes de Python que l’on peut lire en une après-midi. Essayez de faire de même avec LangGraph.
La différence ne réside pas seulement dans la taille. Tous les autres frameworks utilisent des appels d’outils JSON, où l’agent envoie un bloc indiquant quelle fonction exécuter avec quels arguments. Le CodeAgent de Smolagents, quant à lui, écrit du Python réel.
agent = CodeAgent(
tools=[search_tool, db_tool],
model=InferenceClientModel(),
)
result = agent.run("Analyze recent financial news for Acme Corp")
Écrire du code permet à un agent de composer des outils de manière naturelle, avec des boucles, des conditions et des opérations en chaîne que les appels JSON ne peuvent pas exprimer. La recherche comparative le confirme, puisque les agents basés sur du code surpassent ceux basés sur JSON dans la plupart des tests.
Le compromis réside dans la sécurité, car l’agent génère et exécute du Python. Le sandboxing est disponible via E2B, Docker et Pyodide, mais il doit être configuré manuellement. Le LocalPythonExecutor par défaut n’est pas explicitement conçu comme une barrière de sécurité, et ses documents le précisent.
L’utilisation de tokens est plus élevée que celle de LangGraph et du SDK d’OpenAI. Le Python généré est plus verbeux par rapport au JSON compact, et chaque import ainsi que chaque déclaration de variable coûtent des tokens.
Avec Gemini ou GPT, ça fonctionne bien mais c’est comme un clou carré dans un trou rond. Il brille avec les modèles et l’infrastructure de Hugging Face, et l’intégration au Hub, qui permet de partager et de charger des agents de la même manière que l’on partage un modèle, est excellente si vous êtes déjà dans cet écosystème.
Score de débogage à 2 h du matin : 8/10. Lire le code écrit par un agent vaut mieux que de déchiffrer une série d’appels d’outils en JSON, et une erreur génère un traceback Python ordinaire.
Google ADK : le cheval noir des entreprises
Environ 180 lignes. Deux heures pour obtenir un agent fonctionnel. 3 102 tokens par exécution.
Le Google Agent Development Kit est apparu discrètement en 2025, et de nombreux développeurs Python ne l’ont jamais essayé. C’est un manque à combler.
ADK est rigoureux en matière de structure mais flexible en ce qui concerne l’exécution, comme c’est généralement le cas pour les outils internes de Google. Les agents sont définis à l’aide d’un modèle, d’un nom, d’instructions et d’outils, à l’instar du SDK d’OpenAI. On y trouve également des agents de flux de travail (sequentiels, parallèles et en boucle), ainsi que la plus récente API AgentTeam permettant de coordonner plusieurs agents.
from google.adk.agents import Agent
root_agent = Agent(
model="gemini-2.5-flash",
name="financial_analyst",
instruction="You are a financial research assistant.",
tools=[search_tool, db_tool],
)
Le cadre d’évaluation est ce qui le distingue. Les cas de test sont écrits en JSON, adk eval les exécute, et vous obtenez des rapports structurés indiquant si le comportement correspond aux attentes. Aucun autre cadre de travail ne propose d’outils d’évaluation aussi matures.
Le déploiement se fait également sans problème, à condition d’utiliser Google Cloud. Vertex AI Agent Engine gère l’échelle, le suivi et les sessions, mais cette condition revêt une grande importance.
ADK est conçu pour Gemini. D’autres modèles fonctionnent via LiteLLM, mais les documents, les exemples et les outils prennent tous Gemini pour référence. L’exécution de GPT-4o a entraîné des cas limites non documentés qui ont nécessité 45 minutes pour être résolus.
Score de débogage à 2 h du matin : 6/10. L’interface de développement adk web est utile. Cependant, les messages d’erreur sont parfois énigmatiques, et la documentation est exhaustive à la manière typique de Google, ce qui la rend difficile à naviguer.
Lequel choisir
« Cela dépend » frustre tout le monde, voici donc la logique de décision issue de la création de l’agent à six reprises :
- Production d’ici vendredi : choisissez CrewAI ou Smolagents. CrewAI convient aux équipes qui ne se sentent pas à l’aise pour déboguer l’exécution de code Python. Smolagents convient plutôt à celles qui le sont et souhaitent un impact minimal en termes de dépendances.
- Doit fonctionner de manière fiable pendant des mois : choisissez LangGraph ou PydanticAI. LangGraph convient aux logiques ramifiées, aux étapes impliquant une intervention humaine et au besoin d’une exécution durable. PydanticAI convient principalement aux travaux avec un seul agent et des sorties structurées, où les lecteurs futurs doivent pouvoir comprendre le code.
- Déjà engagé dans un écosystème : choisissez le SDK OpenAI Agents sur la plateforme d’OpenAI pour ses fonctionnalités de suivi et d’évaluation, ou Google ADK sur GCP pour une intégration native avec Vertex AI et des outils d’évaluation intégrés.
Le problème, c’est que pour la plupart des projets, le framework importe moins que l’ingénierie des prompts et la conception des outils. Une fois que l’on a accordé une attention réelle aux prompts système et aux descriptions des outils, la qualité des résultats est restée presque identique pour les six approches. Ce qui différait, c’était l’expérience des développeurs, la facilité de débogage et la charge opérationnelle.
Les configurations qui ont tenu le coup sont : PydanticAI pour les tâches à un seul agent, qui représentent la majeure partie du travail, et LangGraph lorsque le flux de travail est véritablement complexe. Il n’y a pas besoin de s’excuser pour l’utilisation de deux frameworks.
Tous les six côte à côte
| Metric | LangGraph | CrewAI | PydanticAI | OpenAI SDK | Smolagents | Google ADK |
| ----------------- | ----------- | --------------- | ------------- | ---------------- | --------------- | --------------- |
| Lines of code | ~210 | ~340 | ~130 | ~150 | ~95 | ~180 |
| Time to prototype | 3 hrs | 45 min | 1.5 hrs | 1 hr | 30 min | 2 hrs |
| Avg tokens/run | 2,847 | 4,216 | 2,912 | 2,791 | 3,340 | 3,102 |
| Multi-agent | Yes (graph) | Yes (teams) | Manual | Yes (handoffs) | Yes (hierarchy) | Yes (AgentTeam) |
| Type safety | TypedDict | Pydantic config | Full generics | Generic context | Minimal | Standard |
| MCP support | Yes | Limited | Native + A2A | Native | Yes | Yes |
| Model-agnostic | Yes | Yes | Yes (20+) | Yes (100+) | Yes (LiteLLM) | Gemini-first |
| Best debugger | LangSmith | Logs | IDE/types | Built-in tracing | Code output | ADK Web UI |
| GitHub stars | ~48K | ~44K | ~15K | ~16K | ~26K | ~23K |
| 2 AM debug | 9/10 | 5/10 | 8/10 | 7/10 | 8/10 | 6/10 |
Aucun de ces chiffres ne raconte l’histoire dans son intégralité, mais ils constituent un point de départ plus honnête que la plupart des articles de comparaison.
Prévoyez que les choses évoluent
Ces frameworks évoluent plus rapidement que quiconque ne peut les documenter. LangGraph a sorti une mise à jour majeure au moment où cet article était écrit. La version entreprise de CrewAI a vu apparaître des intégrations en l’espace d’une semaine. PydanticAI a ajouté le support du protocole A2A, tandis que Google ADK a publié une fonctionnalité SkillToolset quelques jours auparavant.
Toute comparaison a une durée de validité. Dans six mois, les écarts de performance pourraient se réduire, de nouvelles fonctionnalités pourraient voir le jour, et le framework que vous aviez écarté pourrait devenir le choix évident. Choisissez donc celui que votre équipe peut déboguer à 2 heures du matin, avec le pipeline arrêté et un client qui attend, et non celui qui compte le plus d’étoiles sur GitHub.
Lectures complémentaires
- Agent Plugins 1.0.0 : Le format de packaging partagé pour les compétences et les serveurs MCP — Agent Plugins 1.0.0 standardise les dossiers de plugins, plugin.json, les compétences ainsi que mcp.json entre les clients. Ce qu’il couvre, ce qu’il omet en matière de sécurité, et un exemple d’utilisation de la CLI Google Agents.
- MCP, A2A et ACP en pratique : Comment une banque relie des outils et des agents entre eux — Comment MCP, A2A et ACP répartissent les tâches de connexion entre les modèles, les outils et les agents, illustré par le cas d’un assistant bancaire gérant les fraudes et les prêts.