Pydantic AI : agents Python type-safe en production 2026

Si vous avez construit quoi que ce soit de sérieux avec des LLM en Python ces deux dernières années, vous avez probablement écrit le même code répétitif trois fois : analyser la réponse du modèle, la valider contre un schéma, réessayer en cas de JSON invalide, journaliser l'appel, changer de fournisseur quand l'un tombe en panne, puis expliquer à un relecteur pourquoi votre « framework » est devenu douze fichiers de glu. La première génération de bibliothèques d'agents — LangChain, Haystack, les premières versions de CrewAI — a résolu la découvrabilité, mais pas la durabilité. Elle a appris à toute une génération d'ingénieurs ce qu'un agent pouvait faire. Elle ne leur a pas donné une manière confortable de le mettre en production.

En 2026, le projet vers lequel la plupart des équipes se tournent à la place est Pydantic AI. Il est construit par la même équipe que Pydantic, la bibliothèque de validation qui tourne déjà à l'intérieur de FastAPI, LangChain, du SDK Python d'OpenAI, et de pratiquement tous les outils que vous utilisez. La thèse est simple : si Pydantic est la couche de schéma de facto en Python, un framework d'agents construit dessus devrait être la valeur par défaut ennuyeuse et type-safe — pas une nouvelle tour d'abstraction.

La réponse en 30 secondes

Pydantic AI est un framework d'agents Python qui traite les appels aux LLM comme des appels de fonctions typées. Vous définissez les entrées et sorties comme des modèles Pydantic, vous enregistrez les outils comme de simples fonctions Python, et le framework gère la validation, les nouvelles tentatives, le streaming et le changement de fournisseur. Il fonctionne avec OpenAI, Anthropic, Google, Mistral, Groq, Cohere, Bedrock et tout point de terminaison compatible OpenAI, et il s'intègre nativement avec Logfire pour l'observabilité, sans câblage supplémentaire.

Choisissez Pydantic AI quand vous voulez des sorties structurées de qualité production, un comportement prévisible sur les retries, et une surface d'API que vous pouvez lire de bout en bout en un après-midi.

Pourquoi les équipes quittent LangChain

Le scénario de migration en 2026 est remarquablement constant. Les équipes commencent sur LangChain parce que les tutoriels sont partout, heurtent deux ou trois des murs suivants, puis évaluent les alternatives :

• Dérive de schéma entre les couches. Un changement dans un modèle de sortie Pydantic ne se propage pas automatiquement à travers les chaînes, agents et callbacks. Vous patchez la même forme à quatre endroits.
• État caché et globales implicites. Mémoire, callbacks et tracing sont configurés par effet de bord. Deux fonctionnalités sans rapport commencent à interagir en production.
• Roulement de versions. Les sorties majeures de LangChain divisent les paquets, renomment les modules et changent les API plus vite que la plupart des équipes ne peuvent refactoriser.
• Débogage par stack trace. Quand une chaîne se comporte mal, la trace est un mur de noms de classes internes. Lire ce que le modèle a réellement vu est plus difficile que ce ne devrait l'être.
• Fragmentation des fournisseurs. Chaque fournisseur de modèles a ses propres particularités pour l'appel d'outils, les sorties structurées et le streaming. Changer de fournisseur exige plus qu'un changement de configuration.

Pydantic AI a été conçu en réponse directe. Le framework a environ vingt concepts publics, aucun état global, aucun registre de callbacks, et une seule abstraction normalisée pour l'appel d'outils à travers les fournisseurs. Vous lisez le code source en un après-midi et pouvez prédire ce que fait chaque ligne.

Architecture centrale

Un programme Pydantic AI est construit autour de trois primitives : un Agent, un output_type typé, et des tools optionnels. Tout le reste — streaming, retries, dialogue multi-tours, journalisation structurée — est posé par-dessus sans changer ces primitives.

Un exemple minimal :

from pydantic import BaseModel
from pydantic_ai import Agent
 
class Order(BaseModel):
    product: str
    quantity: int
    customer: str
 
agent = Agent(
    "anthropic:claude-opus-4-7",
    output_type=Order,
    system_prompt="Extrais les détails de la commande du message utilisateur.",
)
 
result = agent.run_sync("Sarah de Tunis a commandé trois ordinateurs portables 14 pouces.")
print(result.output)
# Order(product='ordinateur portable 14 pouces', quantity=3, customer='Sarah')

Deux choses méritent qu'on s'y arrête. D'abord, result.output est une véritable instance de Order — pas un dict, pas une chaîne JSON à parser. Votre IDE connaît la forme, vos tests assertent sur de vrais champs, et une fonction en aval qui prend Order est vérifiée par le type-checker contre cet appel. Ensuite, l'identifiant du modèle est une simple chaîne. Passer à openai:gpt-5-3 ou google-gla:gemini-3-pro est un changement d'une ligne ; le framework normalise l'appel d'outils et les sorties structurées en interne.

Outils et injection de dépendances

Les vrais agents ont besoin de faire plus que transformer du texte. Ils lisent des bases de données, appellent des services HTTP, écrivent dans des files d'attente. Pydantic AI gère cela avec deux idées empruntées à FastAPI : les outils comme fonctions décorées, et un deps_type typé qui circule dans chaque appel d'outil.

from dataclasses import dataclass
from pydantic_ai import Agent, RunContext
 
@dataclass
class Deps:
    db: Database
    http: AsyncClient
    region: str
 
agent = Agent(
    "anthropic:claude-opus-4-7",
    deps_type=Deps,
    system_prompt="Tu es un assistant commercial pour noqta.tn.",
)
 
@agent.tool
async def get_customer(ctx: RunContext[Deps], customer_id: int) -> dict:
    return await ctx.deps.db.fetch_customer(customer_id, region=ctx.deps.region)
 
@agent.tool
async def lookup_pricing(ctx: RunContext[Deps], sku: str) -> dict:
    response = await ctx.deps.http.get(f"/pricing/{sku}")
    return response.json()

Trois propriétés adaptées à la production découlent de ce design. Les tests injectent un faux Deps et vérifient le comportement sans toucher au réseau. Le contexte par requête — un identifiant de tenant, un feature flag, un span de tracing — circule sans variables globales. Et parce que les outils sont typés, le framework peut les décrire au modèle avec précision et valider les appels d'outils du modèle avant qu'ils ne s'exécutent.

Streaming avec validation

Le streaming est l'endroit où beaucoup de frameworks d'agents abandonnent discrètement la sécurité de typage. Pydantic AI maintient le contrat : la charge utile en streaming est validée de manière incrémentale, et votre gestionnaire voit un objet typé dès qu'une portion suffisante est arrivée.

async with agent.run_stream("Résume les commandes de la semaine dernière.") as response:
    async for partial in response.stream_structured():
        render(partial)  # partial est un modèle typé, pas une chaîne

Cela compte quand un LLM diffuse un objet JSON partiel qui ferait normalement planter json.loads. Le parser de Pydantic AI tolère l'état en vol, expose ce qui est actuellement valide, et finalise la valeur quand le flux se ferme.

Observabilité sans code de glu

Pydantic AI est livré avec une intégration Logfire de première classe. Activez-la et chaque exécution d'agent, chaque appel d'outil, chaque retry, chaque coût en tokens apparaît dans un seul arbre de traces, avec les prompts, complétions et sorties validées attachés. Il n'y a aucun gestionnaire de callback séparé à enregistrer et aucune bibliothèque de logs parallèle à configurer.

import logfire
logfire.configure()
logfire.instrument_pydantic_ai()

Pour les équipes déjà sur OpenTelemetry, Pydantic AI émet des spans standards, donc les mêmes données atterrissent dans Datadog, Honeycomb ou Grafana Tempo sans changement de code. C'est la principale raison citée par les équipes d'ingénierie pour le passage : le débogage en production devient le même workflow qu'elles utilisent déjà pour les services HTTP.

Quand utiliser Pydantic AI plutôt que les alternatives

Le paysage Python des agents en 2026 s'est stabilisé autour d'un partage clair.

• Pydantic AI gagne quand vous avez besoin de sorties structurées fiables, d'une empreinte de dépendances réduite et d'une observabilité qui s'inscrit dans l'outillage existant. Le point idéal est constitué de systèmes mono-agent ou multi-agents modestes avec des contrats clairs entre les étapes.
• LangGraph gagne quand le workflow est un véritable graphe à état avec branches, boucles et points de contrôle humain. Si vous vous retrouvez à dessiner l'agent au tableau avec des flèches, c'est le signal.
• CrewAI gagne pour les équipes d'agents basées sur des rôles qui collaborent sur une tâche longue, où chaque agent a une persona et un mandat. Le modèle mental est une petite équipe, pas une fonction.
• OpenAI Agents SDK gagne dans un stack 100 pour cent OpenAI où les fonctionnalités de la plateforme (handoffs, tracing, sessions) s'alignent sur votre façon de fonctionner.

Pydantic AI ne cherche pas à tout faire. Cette retenue est précisément le point. La plupart des agents en production ne sont pas des graphes de quinze nœuds ; ce sont une ou deux étapes bien typées enroulées autour d'un appel de modèle, et Pydantic AI est le chemin le plus court vers cela.

Ce qu'il faut surveiller en 2026

Trois choses méritent d'être suivies. D'abord, l'intégration avec Pydantic Logfire devient le chemin d'observabilité par défaut pour les charges de travail IA en Python — attendez-vous à ce que d'autres frameworks se standardisent sur sa forme de trace. Ensuite, les patterns multi-agents arrivent sous forme de fine couche au-dessus des agents simples plutôt que d'une abstraction séparée, ce qui maintient la surface d'API réduite. Enfin, le framework est de plus en plus utilisé comme implémentation de référence pour les benchmarks de sorties structurées, ce qui signifie que les fournisseurs de modèles s'alignent sur les chemins de validation exacts qu'il sollicite.

Si vous démarrez un nouveau projet Python d'IA aujourd'hui, partez sur Pydantic AI par défaut, prenez LangGraph ou CrewAI quand la forme de votre problème en a réellement besoin, et résistez à la tentation d'ajouter un framework avant d'avoir écrit l'agent sans. Le code ennuyeux, typé et observable est de retour à la mode — et pour l'IA en production, c'est exactement la bonne mode.