LangGraph contre Pydantic AI : pourquoi c’est le modèle et non le framework qui a déterminé la précision
Une étude de référence contrôlée portant sur 160 points de score entre LangGraph et Pydantic AI montre une précision identique dans l’appel des outils, et révèle que le choix du modèle ainsi que la conception de l’évaluation sont bien plus importants.
Le choix entre les frameworks d’agents fait l’objet de débats très animés dans le domaine de l’ingénierie en IA, mais une étude de référence menée avec soin suggère qu’il pourrait s’agir d’une des décisions les moins influentes sur la correction des résultats. Lorsque LangGraph et Pydantic AI ont été exécutés sur des tâches identiques, avec les mêmes outils et paramètres de modèle, ils ont obtenu exactement le même score, tandis qu’un changement de modèle modifiait un quart des résultats. Cet article décrit en détail cette expérience, ce que ses chiffres montrent et ne montrent pas, ainsi que la manière d’orienter ses propres efforts d’évaluation là où cela a réellement un impact sur les résultats.
Comment l’étude de référence a isolé le framework
La comparaison a opposé LangGraph 1.2.9 à Pydantic AI 2.13.0 sur quatre tâches, avec 20 exécutions par tâche et par framework : 160 exécutions au total, un seul modèle, température 0. L’ensemble de l’étude a coûté 0,3767 dollar en frais d’API. La méthodologie est documentée et le cadre de test est open source, ce qui permet de vérifier et de réexécuter la configuration.
Toutes les quatre tâches sont déterministes et évaluées selon une correspondance exacte ; chacune met à l’épreuve une compétence différente de l’agent :
inventory-reorder: une seule appel à outil suivi de calculs arithmétiques sur son résultatdependent-shipping-quote: un deuxième appel à outil dont les entrées dépendent des sorties du premierrecover-stale-revision: l’agent doit se rendre compte que ses données sont obsolètes et les récupérer à nouveaurefund-policy-minimal-tools: calculs de dates selon des critères de politique de remboursement, avec un nombre intentionnellement limité d’outils disponibles
Tout ce qui entourait la bibliothèque a été maintenu constant : chaque framework recevait des instructions identiques pour chaque tâche, était équipé d’outils décrits par des schémas JSON identiques et reposait sur une même implémentation, et était évalué par un seul juge. Le modèle utilisé était gpt-4o avec une température de 0, et les appels aux outils en parallèle étaient désactivés. Seule la bibliothèque d’orchestration était autorisée à changer.
Cette discipline constitue l’essence même de l’expérience. De nombreuses comparaisons de frameworks publiées modifient en même temps les instructions, les outils et la bibliothèque, puis attribuent toute différence à la bibliothèque elle-même. Si vous souhaitez effectuer une comparaison fiable, le premier critère est de maintenir tout le reste inchangé.
Égalité parfaite en termes de correction
Les deux frameworks ont terminé correctement les 80 essais effectués. Résumé :
LangGraph 1.2.9 Pydantic AI 2.13.0
Completed 80 / 80 80 / 80
Wilson 95% CI 0.954 - 1.0 0.954 - 1.0
Total cost $0.1881 $0.1886
Median wall time 3.863 s 5.526 s
Ce n’est pas un cas de « comparabilité approximative » ou de résultats « dans les limites du bruit ». Avec les mêmes tâches, schémas, modèles et données d’entrée, les scores étaient identiques. L’intervalle de Wilson allant de 0,954 à 1,0 correspond à un score parfait de 80 sur 80 : il indique que, avec cet échantillon, le taux de réussite réel est très probablement supérieur à environ 95 % pour les deux solutions. Si l’une des bibliothèques rendait les agents plus susceptibles de trouver la bonne réponse à ces tâches, l’expérience aurait compté suffisamment d’exécutions pour révéler un effet significatif, ce qui n’a pas été le cas. Elle pourrait toutefois manquer des différences très faibles, ce qui constitue une limite normale pour tout échantillon de cette taille.
Le signe le plus évident que la comparaison était équitable réside dans les tokens d’entrée. Ils correspondaient exactement dans les deux frameworks à chaque exécution : 311 pour inventory-reorder, 791 pour dependent-shipping-quote, 615 pour recover-stale-revision et 926 pour refund-policy-minimal-tools. En d’autres termes, les deux bibliothèques ont transformé le même schéma en la même requête API, mot pour mot en termes de tokens. Les tokens de sortie différaient de quelques unités lors de quelques exécutions, ce qui constitue une variation normale du modèle même à une température de 0, et cela explique l’écart de moitié de centime dans le coût total. La surcharge du framework n’y est pas pour rien.
Un match nul donne un titre peu intéressant, mais il répond à la question pratique : en ce qui concerne la correction des appels aux outils, à cette échelle et avec ce modèle, le framework n’a pas été le facteur décisif.
Latence : un écart constant avec une explication limitée
Ces frameworks présentaient effectivement une différence sur un axe, et ce de manière constante. La liste ci-dessous indique, pour chaque tâche, d’autant plus LangGraph était en avance en termes de temps médian par rapport à Pydantic AI, suivie de l’intervalle de confiance bootstrap à 95 % correspondant à cette économie de temps :
inventory-reorder: LangGraph devance de 1,669 s (intervalle allant de 1,481 à 1,918 s)dependent-shipping-quote: avance de 1,430 s (intervalle allant de 1,241 à 1,686 s)recover-stale-revision: avance de 1,842 s (intervalle allant de 1,658 à 2,101 s)refund-policy-minimal-tools: avance de 1,645 s (intervalle allant de 1,427 à 1,911 s)
Pour les quatre tâches, l’intervalle entier reste très éloigné de zéro. LangGraph termine chaque exécution environ 1,4 à 1,8 seconde plus tôt, soit environ 1,4 fois plus rapidement en moyenne.
Ne transformez pas cela en recommandation sans avoir lu l’explication. L’écart provient du passage de code asynchrone à code synchrone : l’outil utilisé est synchronique, et Pydantic AI a été exécuté via ce chemin synchrone. Cela ne montre pas pour autant que le cycle d’agent de Pydantic AI est intrinsèquement lent. Ce chiffre est réel et reproductible pour ce style d’intégration spécifique, mais c’est aussi le résultat le moins transférable dans cette étude. Dans une application déjà asynchrone de bout en bout, on peut s’attendre à ce que la différence diminue ou disparaisse.
Un cas atypique contredit la médiane
Un détail notable contredit le résultat concernant la latence. La seule exécution la plus lente de l’étude a été réalisée par LangGraph : 16,196 secondes pour la tâche dependent-shipping-quote, contre 10,228 secondes pour la pire exécution avec Pydantic AI. La deuxième exécution la plus lente de LangGraph sur cette tâche a nécessité 5,232 secondes, ce qui suggère plutôt un cas isolé qu’une tendance générale. Cependant, avec seulement 20 exécutions par tâche, il est impossible de distinguer ces deux possibilités, et un seul point de données ne constitue pas une distribution.
Leçon pratique : ici, les médianes favorisent LangGraph, mais si vous fixez des objectifs de latence, c’est le comportement de la queue qui importe, et vous devez le mesurer sur votre propre charge de travail plutôt que de vous fier au médian d’autrui.
Le changement de modèle a modifié un quart des résultats
Lors d’une exécution distincte sur le même outil, les quatre tâches ont été réalisées avec deux modèles, soit 40 exécutions pour chacun :
gpt-4o-mini gpt-4o
Completed 30 / 40 40 / 40
Cost (40 runs) $0.0057177 $0.094275
Les frameworks, les tâches et les outils sont restés inchangés. Seul le modèle a changé, ce qui a entraîné un renversement de 25 % des résultats.
La manière dont gpt-4o-mini a échoué est la partie la plus instructive. Son appel aux outils se passait bien : avec n’importe quel framework, il a réussi toutes les exécutions sur toutes les tâches à l’exception d’une. L’exception concernait refund-policy-minimal-tools, qu’il a échoué à traiter lors des 10 exécutions effectuées sur cette tâche, cinq pour chaque framework, et toujours de la même manière. Il a calculé days_since_delivery = 19 en comptant à la fois la date de début et celle de fin, alors que le nombre exclusif correct est 18, avant de conclure que le client se trouvait en dehors de la période de remboursement.
Ce n’est ni une défaillance du framework ni une erreur d’utilisation d’outil. Il s’agit d’un modèle qui se trompe dans le calcul des dates inclusives par rapport aux exclusives, au sein d’un agent qui a agi fidèlement en se basant sur le mauvais nombre. Aucune bibliothèque d’orchestration ne peut détecter seule une telle erreur. Ce qui permet de la repérer, c’est une vérification déterministe : calculer les différences de dates à l’aide d’un outil plutôt que de demander au modèle de faire les calculs, ou valider le résultat avant d’y agir.
Ainsi, la comparaison sur laquelle insiste l’industrie s’est terminée par un match nul, tandis que la comparaison sur laquelle presque personne ne débat a entraîné une différence de 25 points. Obtenir un score plus élevé a coûté environ 16,5 fois plus cher.
Que retenir de cela pour votre propre stack
Choisissez le framework en fonction de son ergonomie
Décidez en fonction des éléments avec lesquels vous travaillerez tous les jours : la sécurité de type, la pertinence d’un modèle graphique pour votre problème, l’expérience de débogage, ainsi que la lisibilité du code pour votre équipe en cas d’incident. Ces différences sont réelles. Sur cette base, la correction n’en fait pas partie. Pour une comparaison plus approfondie des options dans ce domaine, consultez le choix d’un framework Python pour les agents IA.
Investissez votre budget d’évaluation dans le modèle
Ici, le choix du modèle a influencé 25 % des résultats et modifié les coûts par un facteur de 16,5. Si vous disposez de peu de temps pour tester quelque chose, testez le modèle sur vos propres tâches. Notez également que les deux modèles étudiés sont des modèles OpenAI anciens et spécifiques ; les modèles plus récents peuvent se comporter différemment, il convient donc de relancer la comparaison avec les modèles que vous prévoyez réellement d’utiliser.
Étudiez plutôt les modes de défaillance que le taux global de réussite
La partie la plus informative de cet étalonnage n’était pas le tableau des scores, mais refund-policy-minimal-tools, la tâche conçue pour être difficile. Chaque modèle et framework a réussi les trois autres tâches, ce qui ne révélait rien. Un ensemble d’évaluation n’a de valeur que lorsque quelque chose échoue. Concevez des tâches ciblant les faiblesses spécifiques que vous craignez, comme une logique de date erronée, des données obsolètes ou des appels en chaîne à des outils, et développez cet ensemble à partir d’échecs réels en production.
Méfiez-vous des étalonnages qui désignent un gagnant
Abordez avec scepticisme tout test de référence d’un framework qui déclare un gagnant, y compris celui-ci. Ce qui permet de vérifier cette étude, c’est que les résultats bruts au format JSONL, un manifeste contenant les versions et les hachages fixés, ainsi que l’outil de test lui-même sont tous publiés, accompagnés des données complètes pour chacune des 160 exécutions. Appliquez le même standard à tous les tests de référence sur lesquels vous comptez.
Limites des preuves
Le champ d’application est restreint : une famille de modèles, quatre tâches, un ensemble d’outils unique et une date fixe. Les essais ont eu lieu les 24 et 25 juillet 2026, avec les modèles gpt-4o et gpt-4o-mini, ainsi que les versions de la bibliothèque LangGraph 1.2.9 et pydantic-ai-slim[openai] 2.13.0 ; les résultats pourraient varier avec des versions ultérieures. La correction des appels d’outils n’est qu’une dimension d’un framework d’agent, et ce n’est probablement pas celle qui vous intéresse le plus ; la gestion de l’état, la persistance, le streaming et l’observabilité ne sont pas évalués ici.
Ainsi, ce que les données permettent de conclure est plus modeste qu’un titre accrocheur : pour ces tâches et à cette échelle, le framework n’a pas pu prédire si l’agent avait trouvé la bonne réponse, contrairement au modèle.
Points clés
- Le fait de contrôler tout sauf la bibliothèque est ce qui rend significative une comparaison de frameworks ; un nombre identique de tokens d’entrée constitue un bon indicateur d’équité.
- LangGraph et Pydantic AI obtiennent tous deux 80 sur 80 en termes de précision dans les appels d’outils avec
gpt-4o. - L’écart de latence reflétait un passage du mode synchrone au mode asynchrone dans le framework, et non une boucle d’agent lente ; un seul cas atypique explique pourquoi la latence finale doit être mesurée séparément.
- Changer de modèle modifiait 25 % des résultats, en raison d’une erreur constante dans le calcul des dates que aucun framework ne parvenait à détecter.
- Consacrez les efforts d’évaluation aux choix de modèles et à des tâches difficiles visant à détecter les échecs, et retirez la logique déterministe telle que le calcul des dates du modèle.
Lectures complémentaires
- Choisir un framework pour des agents IA en Python en 2026 : Un comparatif pratique — Compare cinq frameworks pour des agents IA en Python selon leur manière de gérer les échecs et la complexité, afin d’aider les lecteurs à trouver l’outil adapté à leur flux de travail.
- De texte brut en pipelines : analyseurs, LCEL, éléments exécutables et mémoire dans LangChain — Comment LangChain transforme le texte brut des modèles en données structurées, organise les étapes à l’aide de LCEL et de l’interface Runnable, ainsi qu’il gère la mémoire conversationnelle aujourd’hui.