Machine Learning Mastery montre comment créer des agents IA en Python avec Pydantic AI

Le 29 avril 2026, Machine Learning Mastery a publié une analyse détaillée de Pydantic AI, un framework Python pour créer des agents IA avec typage, validation et outils intégrés. L'article montre comment faire passer le travail avec les LLM d'un assemblage de chaînes de caractères et de parsers fragiles à un processus de production plus prévisible.

Pourquoi c'est important

L'idée centrale de l'article est simple : la plupart des infrastructures d'agents ressemblent encore à du glue code. Le modèle renvoie une chaîne, le développeur espère qu'elle contient un JSON correct, puis analyse la réponse à la main, intercepte les erreurs et ajoute des exceptions à chaque étape.

Pydantic AI propose une autre voie. Au lieu de réponses non structurées, il s'appuie sur des modèles Pydantic, des schémas, la vérification des types et des nouvelles tentatives automatiques lorsque la sortie du modèle ne correspond pas à la structure attendue. Pour les développeurs Python, cela signifie moins de magie et plus de code que l'on peut tester, lire et maintenir.

L'article le démontre dès l'exemple le plus simple : l'agent se crée en quelques lignes, et le modèle est indiqué par une chaîne au format provider:model-name. L'auteur utilise openai:gpt-4o-mini, mais souligne que le même schéma fonctionne avec d'autres fournisseurs, dont Anthropic et Gemini. Les instructions de l'agent se définissent une seule fois, puis on peut lancer un appel synchrone avec run_sync ou une variante asynchrone avec la même API. Le ticket d'entrée reste bas, et l'architecture ne s'effondre pas dès que la logique se complique.

Les composants de l'approche

La partie la plus utile de l'article est l'analyse des quatre mécanismes sur lesquels repose le workflow d'agents concret de Pydantic AI. L'auteur ne se perd pas dans l'abstraction et ne décrit pas le framework en termes de promesses : chaque bloc est accompagné d'un court exemple de code et d'une explication du problème précis de production qu'il résout, sans théorie superflue. Résultat : l'article se lit comme une carte de l'ensemble minimal de solutions pour un premier agent fonctionnel en Python.

• output_type oblige le modèle à renvoyer les données sous la forme d'un objet Python validé, et non d'un texte libre.
• @agent.tool_plain transforme une fonction Python ordinaire en outil que l'agent peut appeler au fil de son raisonnement.
• deps_type et RunContext offrent l'injection de dépendances sans état global ni dépendances cachées.
• capabilities ajoutent des fonctions supplémentaires comme WebSearch et Thinking sans surcharger le constructeur.

L'auteur montre aussi ce que cela donne pour extraire des données d'une offre d'emploi. Le développeur décrit un modèle JobPosting avec des champs tels que l'intitulé du poste, l'entreprise, la liste des compétences, le niveau de seniority et un indicateur de travail à distance, et l'agent renvoie un objet prêt à l'emploi plutôt qu'un texte brut. Si un champ manque ou si un type ne correspond pas, le framework valide la réponse et réessaie avant que l'erreur n'atteigne le reste de l'application. Cela supprime le problème classique de tout système où un LLM doit produire des données utilisables immédiatement dans le code.

Comment cela mène à la production

Le deuxième grand exemple de l'article porte sur le tool calling. L'auteur prend une base nutritionnelle simple et enregistre une fonction qui, à partir du nom d'un ingrédient, renvoie les calories, les protéines, les glucides et les lipides pour 100 grammes. L'agent reçoit ensuite une requête, comme l'analyse d'un plat, appelle lui-même l'outil pour chaque ingrédient, additionne les valeurs et rend le résultat sous la forme d'un modèle MealSummary.

On obtient non pas une réponse de chat libre, mais une synthèse structurée avec les totaux, un verdict sur la composition et une recommandation. Détail important : la docstring de la fonction n'est pas cosmétique, mais fait partie du contrat qui permet au modèle de comprendre quand et pourquoi appeler l'outil.

Le bloc sur l'injection de dépendances est encore plus important. Au lieu d'un dictionnaire codé en dur, l'auteur encapsule la source de données dans une classe de service, NutritionService, puis la transmet à l'agent via deps et un RunContext typé. Le code se rapproche ainsi nettement d'une exploitation réelle : à la place du dictionnaire, on peut avoir une base de données, un client d'API, une session utilisateur ou toute autre dépendance d'exécution. La testabilité s'améliore aussi. Dans l'exemple, le service est facilement remplacé par un mock, et l'agent continue de fonctionner sans changement dans sa logique principale.

La dernière couche, ce sont les capabilities intégrées. L'article en examine au moins deux : WebSearch, pour accéder à des données actuelles sur internet, et Thinking, pour un raisonnement pas à pas plus poussé sur les tâches complexes. Elles peuvent être combinées dans un même agent, par exemple un assistant de recherche qui décide de ce qu'il faut chercher, obtient des résultats récents et ne formule sa réponse qu'ensuite. En conclusion, l'auteur signale l'intégration avec Logfire pour l'observabilité : on peut voir les appels au modèle, les déclenchements d'outils et les nouvelles tentatives de validation.

Ce que cela signifie

L'article de Machine Learning Mastery est utile parce qu'il fait passer la discussion sur les agents IA du mode démo à la pratique d'ingénierie. Pydantic AI y apparaît non comme une énième surcouche de LLM, mais comme un moyen d'imposer de la discipline aux types, aux dépendances et aux outils. Pour les équipes Python, c'est un bon signal : on peut construire des agents sans orchestrateur lourd, à condition de s'appuyer dès le départ sur des schémas validables, des contrats explicites et des composants d'exécution testables.