PydanticAI

PydanticAI est un framework d'agents Python conçu par l'équipe derrière Pydantic, dirigée par Samuel Colvin, l'ingénieur qui a créé la bibliothèque de validation Pydantic utilisée dans tout l'écosystème Python. Lancé le 2 décembre 2024, pendant la semaine AWS re:Invent, il a atteint sa version stable 1.0 le 4 septembre 2025, après 15 millions de téléchargements. Le framework est sous licence MIT et son utilisation est gratuite. Sa promesse principale : apporter la même expérience développeur qui a fait de FastAPI le framework web Python par défaut à la création d'agents IA, en remplaçant l'analyse JSON ad-hoc et le prompt engineering fragile par de véritables contrats de type et des sorties validées.

PydanticAI prend en charge nativement OpenAI, Anthropic, Google, xAI, Amazon Bedrock, Groq, Mistral, Ollama, Cohere, OpenRouter, Hugging Face et Cerebras. Ses fonctionnalités clés incluent la validation des sorties structurées via des modèles Pydantic, un système d'injection de dépendances utilisant RunContext qui transmet proprement les connexions aux bases de données et les clients API aux outils, le streaming avec validation en temps réel, la prise en charge du Model Context Protocol (MCP), l'approbation des outils par un humain dans la boucle (human-in-the-loop), des architectures multi-agents et l'exécution durable avec l'intégration de Temporal. Une intégration étroite avec Pydantic Logfire offre une observabilité basée sur OpenTelemetry pour tracer les exécutions des agents, suivre les coûts des tokens et déboguer les appels d'outils en production. En mai 2026, le dépôt compte plus de 16 800 étoiles sur GitHub, plus de 241 versions, et est utilisé en production par des équipes développant sur Amazon Bedrock AgentCore.

Ce que fait réellement PydanticAI en mai 2026

PydanticAI s'articule autour d'une classe Agent unique qui enveloppe un LLM, un ensemble d'outils, un prompt système et un schéma de sortie structuré. Lors de l'exécution de l'agent, il valide la sortie du modèle par rapport à un modèle Pydantic à chaque appel, en réessayant automatiquement avec des retours correctifs si la validation échoue. Cela élimine la plus grande catégorie de pannes en production dans les systèmes d'agents : le LLM renvoyant des données mal formées, manquantes ou de mauvais type qui font planter le code en aval.

Le système d'injection de dépendances est le deuxième différenciateur majeur. Au lieu de transmettre la configuration via un état global ou des variables d'environnement, les outils reçoivent un objet typé RunContext[Dependencies] à l'exécution. En pratique, cela signifie qu'une connexion à une base de données, un client API externe ou le contexte utilisateur peuvent être injectés proprement au moment de l'invocation de l'agent, rendant les outils testables unitairement sans appels LLM en direct. Il s'agit d'un modèle de conception emprunté au système de dépendances de FastAPI et il résout un véritable point de douleur rencontré par les équipes lors de la mise à l'échelle des bases de code d'agents au-delà d'un seul fichier. L'écriture d'un test pour un outil d'agent ne nécessite plus un appel LLM en direct ou une base de données en direct : vous passez un objet de dépendance fictif (mock) dans RunContext et vous vérifiez le résultat.

La prise en charge du streaming inclut la validation en temps réel des sorties partielles structurées, et pas seulement le streaming de tokens. C'est important pour les tableaux de bord et les interfaces utilisateur en direct qui affichent des données structurées incrémentielles plutôt que du texte brut : le framework valide chaque fragment de sortie partiel à mesure qu'il arrive, de sorte que l'application n'a jamais à gérer une erreur de validation une fois le flux terminé. Les workflows basés sur des graphes, ajoutés via l'API Graph de PydanticAI, permettent de modéliser des flux agentiques complexes sous forme de machines à états typées avec des transitions entre états vérifiées par l'IDE. La communication multi-agents (transferts d'agent à agent), la prise en charge client/serveur MCP et l'exécution durable (agents pouvant se mettre en pause, persister leur état et reprendre après interruption via Temporal) complètent l'ensemble des fonctionnalités. La feuille de route de début 2026 comprend la mise en cache des prompts, la prise en charge des embeddings, la sortie de grammaire hors contexte et une prise en charge étendue des ressources MCP.

Un exemple concret de la façon dont cela se traduit dans la pratique : un système de classification de documents juridiques basé sur PydanticAI a signalé une précision de 94 % contre 67 % avec la correspondance de mots-clés. Un agent de support client e-commerce a résolu automatiquement 38 % des tickets entrants avec des scores de satisfaction de 96 %. Une intégration CRM immobilier a traité 40 à 60 notifications simultanées en moins de 8 secondes. Ce ne sont pas des arguments marketing de PydanticAI ; ce sont des chiffres publiés par des développeurs individuels qui sont passés au framework spécifiquement pour échapper aux échecs de validation des outils précédents.

"La quatrième fois que j'ai dû déboguer un agent LangChain qui renvoyait silencieusement un JSON mal formé et faisait planter le pipeline de traitement des commandes d'un client, j'ai décidé que j'en avais fini de corriger des erreurs de type à minuit." - jahanzaibai, DEV Community, 2025

Où se situe PydanticAI par rapport à LangChain et smolagents

PydanticAI vs. LangChain : LangChain compte plus de 96k étoiles sur GitHub, une bibliothèque d'intégrations mature et des années de déploiements en production à son actif. Il n'est pas près de disparaître. Mais le framework porte une complexité accumulée importante : une empreinte d'environ 300 Mo, de multiples modèles obsolètes (l'ancien AgentExecutor vs. le plus récent LangGraph), et une architecture qui sépare ChatModel, les modèles de prompt, AgentExecutor et RunnableWithMessageHistory en couches distinctes qui doivent être connectées ensemble. Pour les sorties structurées, LangChain ne peut pas combiner with_structured_output() et des outils supplémentaires dans le même agent sans un contournement personnalisé via StructuredResponseTool. PydanticAI gère cela nativement. Pour l'injection de dépendances, LangChain nécessite de sous-classer BaseTool avec un outil basé sur une classe ; PydanticAI utilise de simples fonctions avec RunContext. Le compromis réside dans l'étendue de l'écosystème : LangChain possède des connecteurs que PydanticAI n'a tout simplement pas encore.

PydanticAI vs. smolagents : smolagents de Hugging Face fait le pari architectural opposé. Son cœur entier représente environ 1 000 lignes de Python. Les agents écrivent et exécutent directement du code Python (agents de code) plutôt que d'appeler des outils prédéfinis via des schémas JSON. Cela produit des gains d'efficacité : smolagents revendique environ 30 % d'appels LLM en moins sur des benchmarks complexes par rapport à l'utilisation d'outils de style JSON. Le coût est que smolagents n'a pas de validation de sortie structurée intégrée, pas de prise en charge asynchrone native et une gestion de la mémoire limitée. PydanticAI impose la cohérence des données à chaque frontière ; smolagents optimise la vitesse d'expérimentation et une empreinte minimale. Si vous prototypez sur des modèles hébergés par Hugging Face et que vous voulez quelque chose qui tourne en une heure, smolagents gagne. Si vous construisez un système de production sensible à la conformité où chaque sortie doit être validée par rapport à un schéma, PydanticAI gagne.

À noter : DSPy occupe un espace adjacent différent, optimisant les programmes de prompt de manière algorithmique plutôt que de fournir une couche d'exécution au runtime. LangGraph (qui fait partie de l'écosystème LangChain) est le concurrent le plus direct pour l'orchestration multi-agents avec état. LiteLLM est complémentaire : une couche de routage agnostique vis-à-vis des fournisseurs sur laquelle PydanticAI peut s'appuyer. CrewAI cible les systèmes multi-agents basés sur les rôles avec une abstraction de plus haut niveau qui sacrifie le contrôle au profit de la simplicité.

À quoi ressemble la réalité de la boucle d'agent

Un workflow PydanticAI typique commence par la définition d'un modèle Pydantic pour la sortie attendue, la création d'un Agent avec un prompt système et un backend de modèle, puis la décoration de fonctions Python en tant qu'outils. L'exécution de l'agent renvoie un objet de résultat typé, et non une chaîne de caractères. L'IDE connaît la forme de chaque argument d'outil et de chaque champ de sortie avant même l'exécution du code.

Pour l'observabilité, l'appel de logfire.configure() et logfire.instrument_pydantic_ai() active le traçage automatique de chaque appel LLM, de chaque invocation d'outil et de chaque tentative de validation. La fondation OpenTelemetry signifie que les traces peuvent être exportées vers n'importe quel backend compatible, et pas seulement vers la plateforme commerciale de Logfire. C'est une distinction importante : certaines équipes utilisent déjà Datadog ou Grafana et ne veulent pas d'un deuxième fournisseur d'observabilité.

Les équipes de production font état de résultats solides. Un développeur a documenté une précision de 94 % sur la classification de documents juridiques (contre 67 % avec la correspondance de mots-clés), 38 % de résolution automatique des tickets de support e-commerce avec des scores de satisfaction de 96 %, et le traitement de 40 à 60 notifications CRM immobilier simultanées en moins de 8 secondes. Ces chiffres proviennent d'équipes qui sont spécifiquement passées à PydanticAI pour arrêter de courir après les échecs d'analyse JSON à 2 heures du matin.

"Après avoir passé trop de temps à traquer les bugs d'accès aux attributs dans des chaînes d'agents typées dynamiquement, cela compte plus que n'importe quel chiffre de benchmark." - jahanzaibai, DEV Community, 2025

Pour qui PydanticAI est-il conçu ?

Le signal le plus clair : si vous avez utilisé FastAPI et que vous considérez le système de types de Python comme une infrastructure plutôt que comme une documentation, PydanticAI vous semblera immédiatement familier. Le framework cible les ingénieurs qui souhaitent traiter le développement d'agents comme de l'ingénierie logicielle normale, avec des tests unitaires, des contrats typés et une prise en charge de l'IDE, plutôt que comme de l'artisanat de prompt couplé à de l'espoir.

Il s'intègre bien dans les équipes qui utilisent déjà Pydantic (ce qui, à ce stade, représente la plupart des équipes Python travaillant avec des LLM, étant donné que le SDK OpenAI, le Google ADK et LangChain lui-même dépendent tous de Pydantic pour la validation). L'adoption de PydanticAI est additive plutôt qu'une réécriture complète. Il convient également aux domaines sensibles à la conformité : finance, santé, juridique, où chaque sortie de l'IA doit être auditable et structurée. Thoughtworks l'a passé en phase "Trial" (Essai) en novembre 2025, leur signal indiquant que les entreprises devraient l'utiliser sur un projet réel pour mieux comprendre cette catégorie.

C'est un choix raisonnable pour les équipes utilisant Amazon Bedrock AgentCore, où PydanticAI est un framework pris en charge en tant que solution de première partie. Il s'intègre naturellement aux côtés de LiteLLM pour les équipes effectuant du routage entre plusieurs fournisseurs.

Ce que PydanticAI n'est pas

PydanticAI n'est pas un couteau suisse agentique à usage général pour toutes les stacks. Quelques limites honnêtes :

Il est exclusivement en Python. Il n'y a pas de SDK JavaScript, TypeScript ou pour d'autres langages. Si votre backend est en Go, Java ou Node.js, vous devez vous tourner vers un autre framework.

Les entrées multimodales (image, audio, vidéo) ne sont pas prises en charge dans le cœur de l'agent à la mi-2026. Le framework traite le texte et les données structurées ; passer une image dans un outil nécessite une gestion manuelle en dehors de la couche de validation du framework.

Pour l'orchestration multi-agents à grande échelle avec des graphes d'état complexes, LangGraph dispose d'outils plus matures. L'API Graph de PydanticAI est fonctionnelle mais plus récente, et les développeurs signalent que l'ergonomie pour les systèmes multi-agents tentaculaires est encore en cours d'amélioration.

La préoccupation concernant la dépendance à Logfire mérite d'être soulignée. L'intégration de l'observabilité est excellente et véritablement utile, mais l'équipe Pydantic a des incitations commerciales à orienter les utilisateurs vers les niveaux payants de Logfire. Le framework émet des données OpenTelemetry, vous n'êtes donc pas strictement verrouillé, mais les équipes qui ont déjà une stack d'observabilité (Datadog, Honeycomb, Grafana) devraient valider le chemin d'exportation avant de s'engager.

Il y a aussi des problèmes connus dont il faut être conscient : une version v1.30.0 a accidentellement introduit une dépendance stricte à openai v2.8.0 qui a cassé des projets existants (issue GitHub #3707), la logique de réessai ne résout pas toujours les échecs de validation comme prévu (issue #739), et la prise en charge du modèle DeepSeek a connu des bugs de mapping. Une équipe de développement active avec 364 issues ouvertes signifie que le framework est réactif mais présente encore quelques aspérités.

Ignorez PydanticAI si : vous voulez quelque chose qui tourne en un après-midi sans aucune connaissance de Pydantic, votre stack n'est pas en Python, vous avez besoin d'outils d'agents multimodaux matures, ou vous avez besoin de l'étendue des plus de 300 intégrations de LangChain.