Pydantic AI : l'approche type-first pour les agents Python

Pydantic AI est un framework d'agents open source (licence MIT) de Pydantic Inc. (Royaume-Uni) pour Python 3.11 et versions ultérieures. Il transpose la bibliothèque Pydantic, bien connue pour la validation de données, au travail avec les large language models : les agents fournissent des sorties structurées et vérifiées par typage, conformes à des modèles Pydantic définis, au lieu de textes formulés librement. S'y ajoutent l'injection de dépendances et une connexion agnostique vis-à-vis du modèle. L'objectif de conception affiché est la qualité d'ingénierie et la maturité pour la production, pas le chemin le plus rapide vers une démo.

• Ce que c'est : un framework Python type-first pour agents IA, avec des sorties validées via des modèles Pydantic.
• Pour qui : les équipes backend Python rompues au type checking qui placent la fiabilité et la qualité de production avant le time-to-demo.
• Quand l'éviter : si .NET est imposé, si le besoin porte sur du low-code ou si des orchestrations multi-agents complexes constituent l'exigence principale.

Pourquoi l'approche « type-first » est essentielle

La plupart des bugs d'agents en production apparaissent à la frontière entre la sortie du LLM et le code en aval : un modèle renvoie un JSON légèrement différent, un champ manque, un type de données ne correspond pas, et le pipeline ne casse que trois étapes plus loin. C'est précisément là qu'intervient Pydantic AI. Il utilise la même couche de validation, déjà considérée comme le standard de facto dans l'écosystème Python : l'OpenAI SDK, Google ADK, l'Anthropic SDK, LangChain, LlamaIndex et CrewAI, entre autres, reposent sur Pydantic Validation. Pydantic AI fait de cette validation le contrat central entre l'agent et l'application.

Concrètement, l'équipe définit le résultat attendu sous forme de modèle Pydantic. L'agent reçoit l'instruction de fournir exactement cette structure ; si la réponse du modèle s'en écarte, Pydantic valide la sortie, renvoie des erreurs typées et permet une nouvelle tentative contrôlée. Résultat : une sécurité de typage de bout en bout. De la définition des outils jusqu'à la valeur de retour validée, en passant par l'appel au modèle, le type checker (et donc l'IDE) connaît les structures de données.

Les quatre piliers

Des sorties structurées et validées. Au lieu de devoir parser des chaînes, tu déclares le schéma cible sous forme de modèle Pydantic. L'agent fournit à coup sûr un objet conforme à ce schéma, ou une erreur de validation propre.

Injection de dépendances. Les dépendances comme les connexions à la base de données, les clients HTTP, la configuration ou le contexte d'autorisation sont injectées dans l'agent de manière typée. Cela découple la logique métier de la définition de l'agent et simplifie les tests unitaires avec des mocks, un pattern que les équipes backend Python connaissent grâce à des frameworks comme FastAPI.

Agnosticisme vis-à-vis du modèle. Pydantic AI se connecte à tous les grands fournisseurs, dont OpenAI GPT, Anthropic Claude, Google Gemini et Mistral, ainsi qu'à des modèles locaux via Ollama. Tu peux ainsi intégrer aussi des modèles allemands ou des modèles destinés à des cas où la souveraineté est critique, puis changer de fournisseur plus tard sans réécrire la logique de l'agent.

Définition d'outils à typage sûr. Les outils sont des fonctions Python typées ; le framework déduit leurs signatures et leurs schémas de paramètres à partir des annotations de type. La couche d'outils reste ainsi aussi vérifiée que la sortie.

En complément, Pydantic AI embarque avec Monty une sandbox Python sécurisée et prend en charge les standards d'interopérabilité MCP et A2A. MCP est inclus dans le paquet pydantic-ai (pour pydantic-ai-slim, via l'extra mcp) et la connexion passe par MCPToolset. La version 2 est stable depuis le 23 juin 2026. Avec cette mise à jour majeure, Pydantic a déplacé A2A dans le paquet autonome fasta2a, qui s'installe séparément ; les anciens extras a2a et fastmcp n'existent plus depuis. Pour l'observabilité, Pydantic Logfire est la solution maison, conforme à OpenTelemetry, qui propose depuis mars 2025 une région UE ainsi qu'une version auto-hébergée.

Positionnement face aux autres frameworks

Pydantic AI se positionne clairement comme code-first, plutôt axé sur le mono-agent. Face aux grands frameworks multi-agents, sa force ne réside pas dans l'orchestration de dizaines d'agents, mais dans la fiabilité de chaque interaction prise isolément.

Les points forts en bref : sécurité de typage de bout en bout, agnosticisme total vis-à-vis des fournisseurs, licence MIT, région UE de Logfire et la qualité d'ingénierie comme objectif de conception explicite. Les points faibles, nommés honnêtement : Python uniquement, une adoption plus récente, moins de patterns multi-agents prêts à l'emploi et une certaine verbosité des génériques, que le fondateur Samuel Colvin reconnaît lui-même. En matière de talents et de maturité de l'écosystème, Pydantic AI se situe à un niveau moyen dans la zone DACH (Allemagne, Autriche, Suisse), avec une disponibilité de freelances faible à moyenne ; en revanche, il fait partie, avec LangGraph v1, CrewAI v1 et Microsoft Agent Framework 1.0, des frameworks jugés prêts pour la production.

Quand Pydantic AI est adapté, et quand il ne l'est pas

Un guide de décision compact :

• Adapté si : le typage sûr, Python et la rigueur d'ingénierie comptent plus que la démo la plus rapide ; Pydantic fait déjà partie de la stack ; une totale indépendance vis-à-vis des fournisseurs est souhaitée ; une souveraineté européenne stricte par auto-hébergement (par exemple sur STACKIT, IONOS ou OVHcloud) est requise.
• Peu adapté si : .NET/C# est imposé (dans ce cas, Microsoft Agent Framework), des citizen developers de l'équipe ont besoin de low-code (dans ce cas, n8n), ou si le prototypage multi-agents rapide avec un modèle de rôles/crews est prioritaire (dans ce cas, CrewAI).

Exemple rapide : une sortie validée en pratique

Imaginons qu'une agence construise un agent qui extrait des données structurées d'un e-mail entrant envoyé par un lead. Le contrat est défini sous forme de modèle Pydantic :

```python
from pydantic import BaseModel
from pydantic_ai import Agent

class Lead(BaseModel):
entreprise: str
budget_eur: int # doit être un entier
priorite: int # de 1 à 5
action_suivante: str

agent = Agent(
"anthropic:claude-...", # modèle interchangeable, agnostique
output_type=Lead, # impose une structure validée
)

resultat = agent.run_sync("Extrais les données de cet e-mail : ...")
lead = resultat.output # forcément de type Lead
```

Le point décisif : lead.budget_eur est forcément un int, et non la chaîne « environ 50 000 euros ». Si le modèle renvoie quelque chose d'inadapté, Pydantic valide la sortie et l'agent peut déclencher une nouvelle tentative typée, au lieu d'écrire des données erronées dans le CRM. Dans un pipeline traitant 1 000 leads par mois, l'effort se déplace ainsi de la gestion des erreurs en aval et de la correction manuelle vers des erreurs clairement identifiées, interceptées dès l'interface. C'est exactement la différence entre une démo et un système en production.

Conclusion pour les agences et le B2B

Pour les agences marketing et les équipes B2B en Europe, Pydantic AI est le bon choix lorsque des agents IA doivent fournir des données fiables et exploitables, par exemple pour la qualification de leads, la structuration de contenus ou la connexion à des systèmes existants. La combinaison de la licence MIT, d'une totale indépendance vis-à-vis des fournisseurs, de la capacité d'auto-hébergement et de la région UE de Logfire rend le framework intéressant aussi pour les projets où la souveraineté et la conformité au règlement sur l'IA sont sensibles : le traçage conforme à OpenTelemetry facilite la traçabilité exigée. Si tu as une équipe Python rompue au type checking, Pydantic AI te donne un outil qui privilégie la fiabilité plutôt que l'effet vitrine. Blck Alpaca t'accompagne dans le choix, l'architecture et l'auto-hébergement de la plateforme d'agents adaptée à ta stack.