Les frameworks Python utiles pour agents IA locaux sont ceux qui savent parler à un modèle exécuté sur votre machine, sans dépendre d’une API cloud. Je vais comparer Ollama, Smolagents, PydanticAI et CrewAI, avec leurs vrais usages, leurs limites et les bons choix selon votre besoin.
Pourquoi orchestrer des agents IA locaux ?
J’orchestre des agents IA locaux pour garder la maîtrise des coûts, des clés API et des données qui circulent.
Quand je délègue toutes les décisions à une API cloud, je loue souvent l’intelligence. Il me faut une clé API, donc un accès à protéger. Chaque requête peut coûter quelque chose, parfois quelques centimes, parfois beaucoup plus quand on automatise à grande échelle. Et surtout, les données sortent du réseau de l’entreprise. Ça peut être acceptable. Mais il faut le décider, pas le subir.
Comment démarrer avec Hermes Agent Desktop ?
Le local change un peu la logique. Une fois le modèle téléchargé, je n’ai pas un coût par requête comparable à une API. Je peux tester, casser, relancer, faire tourner des scénarios sans regarder le compteur tourner. Les données peuvent rester dans l’environnement interne, ce qui rassure tout de suite quand on manipule des tickets clients, des documents RH, du code privé ou des exports métier.
Mais je reste très prudent avec le discours magique autour du local. Le local ne règle pas tout. Il faut une machine adaptée, assez de mémoire, parfois un GPU, et un modèle qui tient la route pour le cas d’usage. Un petit modèle local peut être rapide mais limité. Un gros modèle peut être meilleur mais lourd à faire tourner. J’ai vu des équipes perdre du temps parce qu’elles avaient “un modèle local”, mais aucun cadre autour.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
C’est là que l’orchestration devient importante. Il faut une couche capable de parler proprement au modèle, d’appeler des outils, de structurer les réponses, de contrôler les entrées et sorties, et parfois de faire travailler plusieurs agents ensemble sans que ça parte dans tous les sens.
Pourquoi miser sur les Small Language Models ?
Dans cette logique, Ollama sert de runtime local simple pour lancer les modèles. Smolagents aide à garder des agents lisibles et transparents. PydanticAI sécurise les entrées et les sorties structurées. CrewAI organise la collaboration entre plusieurs agents quand on veut répartir les rôles.
| Besoin | Risque si on fait sans orchestrateur | Framework ou brique pertinente |
| Faire tourner un modèle en local | Installation fragile, appels bricolés, tests difficiles | Ollama |
| Créer un agent simple et compréhensible | Logique opaque, prompts dispersés, maintenance pénible | Smolagents |
| Obtenir des réponses structurées | JSON cassé, champs manquants, erreurs silencieuses | PydanticAI |
| Faire collaborer plusieurs agents | Rôles flous, doublons, décisions incohérentes | CrewAI |
Quand utiliser Ollama ?
J’utilise Ollama quand je veux lancer vite un LLM open-source en local et l’exposer via une API simple. Pour moi, c’est le bon réflexe quand on veut tester un modèle sans transformer son poste en chantier technique.
Ollama, c’est un runtime léger pour modèles de langage. Un peu comme Docker, mais appliqué aux LLM. Vous choisissez un modèle, vous le téléchargez, vous le lancez en local, et Ollama le sert via une API locale. Sans se perdre dans une grosse configuration Python. Sans installer à la main toute la partie CUDA, les drivers GPU, les dépendances, les versions qui se battent entre elles. Et ça, franchement, ça évite pas mal de temps perdu.
Le loop engineering rend-il les agents IA plus fiables ?
Dans une architecture d’agents IA locaux, c’est très pratique. Beaucoup de frameworks d’agents savent parler à une API compatible OpenAI, c’est-à-dire une API qui ressemble à celle d’OpenAI dans sa façon de recevoir une demande et de renvoyer une réponse. Ollama facilite cette intégration, parce qu’on peut brancher un framework dessus comme si on parlait à un service distant, sauf que tout tourne sur la machine ou sur un serveur interne.
Un cas typique que je vois souvent, c’est une équipe data ou automatisation qui veut prototyper un agent interne. L’agent doit lire des documents métier, interroger quelques outils, résumer des tickets, préparer des réponses. L’équipe ne veut pas de clé API au début, ne veut pas envoyer les données à l’extérieur, et ne veut pas monter une stack de serving lourde dès le premier jour. Ollama coche très bien cette case.
Il faut juste rester lucide. Ollama n’est pas pensé pour du très haut débit. Si vous avez beaucoup d’utilisateurs en parallèle, des contraintes fortes de latence, ou une vraie charge de production, je garderais Ollama pour le développement et les tests. Pour la production lourde, je regarderais plutôt vLLM, qui est conçu pour servir des modèles plus efficacement à grande échelle.
| Usage idéal | Prototyper vite un agent IA local avec un LLM open-source. |
| Point fort | Installation simple, API locale, peu de configuration technique. |
| Limite | Pas adapté aux usages avec beaucoup de concurrence ou de très gros volumes. |
| Alternative possible en production | vLLM pour du serving plus performant et plus scalable. |
À quoi sert Smolagents ?
Large Action Models ou agentic LLM, que choisir ?
Smolagents sert à construire des agents IA simples à comprendre, avec un comportement plus transparent que les grosses abstractions habituelles. C’est une bibliothèque minimaliste de Hugging Face, autour d’environ 1 000 lignes de code, pensée pour éviter les boîtes noires inutiles.
J’aime bien cette approche parce qu’on peut lire ce qui se passe. Pour un développeur, un profil data, ou quelqu’un qui doit maintenir l’agent après le POC, c’est précieux. Un agent IA, ce n’est pas juste “un modèle qui répond”. C’est une boucle qui choisit des actions, appelle des outils, manipule des données, puis décide quoi faire ensuite. Si cette logique est cachée derrière trop d’abstractions, on perd vite le contrôle.
Smolagents est aussi modèle-agnostique. Ça veut dire qu’il n’est pas marié à un seul fournisseur ou à une seule façon d’exécuter le modèle. On peut l’utiliser avec des transformers locaux, avec Ollama, ou avec des modèles hébergés chez des fournisseurs externes. C’est pratique quand on veut tester localement, puis comparer avec une API plus puissante sans réécrire toute la logique.
Son concept important, ce sont les CodeAgents. Ce sont des agents capables de produire du code, puis de l’exécuter pour résoudre une tâche. Par exemple, lire un fichier CSV, filtrer des lignes, appeler une API, générer un graphique, ou automatiser une petite analyse. C’est puissant, mais il faut être très clair sur un point : exécuter du code généré par un modèle demande un bac à sable. Un bac à sable, c’est un environnement isolé qui limite les dégâts si le code fait n’importe quoi.
- Docker permet d’isoler l’exécution dans un conteneur local.
- E2B fournit des environnements sandboxés prêts pour les agents IA.
- Modal permet d’exécuter du code dans une infra distante contrôlée.
Sur des projets d’automatisation, je vois souvent un truc très simple : la transparence compte autant que la performance. Un agent qui agit sans qu’on comprenne pourquoi finit rarement en production. Les équipes veulent pouvoir débugger, auditer, expliquer, corriger.
La limite, elle est surtout côté modèle. Avec des modèles locaux de moins de 7B paramètres, les performances peuvent se dégrader assez vite. Les raisonnements sont moins stables, les appels d’outils se trompent plus souvent, et les bugs deviennent plus fréquents.
Smolagents est donc surtout pertinent avec un modèle local suffisamment solide, et quand on veut garder une logique d’agent lisible, contrôlable, et pas noyée dans une usine à gaz.
Pourquoi choisir PydanticAI ?
Je choisis PydanticAI quand la priorité est d’obtenir des entrées et sorties structurées, validées et exploitables par le reste du système. Dans un vrai workflow business, une réponse jolie en texte libre, ça ne suffit pas toujours. Un agent doit parfois appeler un outil, transmettre des données, remplir un objet, alimenter une base, ou déclencher une automatisation. Là, le format compte vraiment.
PydanticAI s’appuie sur les annotations de type Python pour définir ce qu’on attend. Une annotation de type, c’est juste une façon de dire à Python : “Ce champ doit être un nombre”, “Celui-là doit être une date”, “Celui-ci doit être une liste”. Le framework utilise ça pour créer des schémas et valider les réponses du modèle.
Si le LLM répond n’importe comment, ou s’il oublie un champ, PydanticAI peut aider à corriger la sortie ou à forcer une réponse conforme. C’est très pratique quand vous attendez des données comme :
- Un montant et une devise.
- Une date d’échéance.
- Un statut de dossier.
- Un identifiant client.
- Un score de risque.
- Une recommandation exploitable.
Un exemple simple, sans rentrer dans tout le code :
Objet attendu :
{
"client_id": "string",
"amount": "float",
"currency": "string",
"status": "approved | rejected | pending"
}
Sortie valide :
{
"client_id": "C-10492",
"amount": 2490.50,
"currency": "EUR",
"status": "approved"
}Dans la finance, la santé, ou les opérations internes sensibles, ce genre de validation n’est pas du confort. C’est une barrière de sécurité. J’ai déjà vu des automatisations bloquées juste parce qu’un modèle avait répondu “environ 2 500 euros” au lieu de renvoyer 2500 dans un champ numérique. Pour un humain c’est clair. Pour une base de données, c’est cassé.
PydanticAI colle aussi bien à une logique locale. Il fonctionne avec des endpoints compatibles OpenAI, donc on peut l’intégrer assez facilement avec un serveur Ollama local. Vous gardez le modèle chez vous, tout en gardant une couche propre pour structurer les échanges. Le projet reste en développement actif, avec une version signalée 1.85.1 en avril 2026. Ce n’est pas un argument magique, mais ça montre que l’outil bouge encore.
| Format | Avantage | Limite |
| Texte libre | Facile à lire pour un humain. | Difficile à exploiter automatiquement. |
| JSON non validé | Plus structuré qu’un texte classique. | Peut manquer de champs ou contenir de mauvais types. |
| Sortie validée par schéma | Fiable pour une base, un outil ou une automatisation. | Demande de définir clairement ce qu’on attend. |
Quand passer à CrewAI ?
Je passe à CrewAI quand un seul agent ne suffit plus et que plusieurs agents doivent coopérer avec des rôles clairs.
CrewAI est vraiment pensé pour ça : organiser une collaboration multi-agent. Je définis des agents avec un rôle, un objectif, parfois des outils, puis je les regroupe dans une crew, une équipe, pour les faire travailler ensemble sur une tâche.
Un exemple simple : je veux analyser une demande métier et produire une recommandation exploitable. Je peux avoir un premier agent qui lit la demande et clarifie le besoin. Un deuxième agent prépare ou recherche les données utiles. Un troisième agent produit la synthèse finale avec une recommandation. Là, les responsabilités sont nettes. Chacun a son job.
Mais je reste prudent avec ça. Multiplier les agents ne rend pas automatiquement le système plus intelligent. Ça peut même le rendre plus pénible à déboguer. Si deux agents font presque la même chose, ou si personne n’est vraiment responsable du résultat final, on obtient vite une usine à gaz. Je l’ai vu chez un client sur un prototype interne : cinq agents, beaucoup de logs, mais personne ne savait vraiment pourquoi la réponse finale partait dans une mauvaise direction.
Le bon usage de CrewAI, c’est quand les responsabilités sont vraiment distinctes :
- Un agent comprend ou découpe le problème.
- Un agent collecte, transforme ou vérifie les données.
- Un agent rédige, arbitre ou recommande.
CrewAI peut aussi tourner avec des modèles locaux, notamment via Ollama. Dans ce cas, Ollama exécute le modèle sur votre machine ou votre serveur, et CrewAI orchestre les agents autour. C’est intéressant quand vous voulez garder la main sur vos données, vos coûts, ou votre infra.
Autre point important : CrewAI se veut autonome et ne dépend pas de LangChain. Il supporte aussi le Model Context Protocol, ou MCP, qui sert à connecter proprement des outils et des sources de contexte à un agent. Il gère plusieurs transports comme stdio, SSE et HTTP streamable.
Dans ma tête, la place de chaque outil est assez claire. Ollama exécute le modèle. PydanticAI aide quand je veux des sorties structurées et fiables. Smolagents reste très bien pour des agents simples, légers, faciles à lire. CrewAI prend le relais quand je dois organiser une vraie équipe d’agents.
| Rester sur un agent simple | Passer à une crew |
| La tâche est courte, linéaire, avec peu d’étapes. | La tâche demande plusieurs responsabilités bien séparées. |
| Un seul agent peut comprendre, agir et répondre correctement. | Plusieurs agents doivent analyser, préparer, vérifier ou synthétiser. |
| Le débogage doit rester très simple. | L’orchestration apporte plus de clarté que de complexité. |
| Smolagents ou PydanticAI suffisent largement. | CrewAI devient utile pour structurer une équipe d’agents. |
Alors on choisit quel framework pour vos agents IA locaux ?
Pour moi, le bon choix dépend moins du nom du framework que du problème à résoudre. Si je veux lancer un modèle local rapidement, je pars sur Ollama. Si je veux comprendre finement le comportement de l’agent, Smolagents est plus lisible. Si mes sorties doivent être propres, typées et fiables, PydanticAI devient très intéressant. Si plusieurs agents doivent coopérer, CrewAI prend du sens. Je resterais prudent avec les listes trop longues de frameworks quand les informations ne sont pas vérifiables. Le vrai bénéfice pour vous, c’est de choisir une stack locale plus simple, plus maîtrisée et plus adaptée à vos contraintes business.
FAQ
- Qu’est-ce qu’un agent IA local ?
Un agent IA local est un agent qui utilise un modèle exécuté sur votre propre machine ou dans votre réseau, au lieu d’appeler uniquement une API cloud. L’intérêt, c’est de mieux contrôler les coûts, les clés d’accès et la circulation des données. - Ollama suffit-il pour créer des agents IA locaux ?
Ollama suffit souvent pour lancer et servir un modèle local simplement. Mais pour créer un vrai agent, il faut généralement une couche au-dessus pour gérer les outils, les rôles, les sorties structurées ou la collaboration entre plusieurs agents. - Quel framework choisir pour des sorties fiables ?
PydanticAI est le plus adapté quand la sortie doit respecter un schéma précis. C’est utile si l’agent doit produire des données exploitables par une base, une API, une automatisation ou un processus business sensible. - Smolagents est-il adapté aux petits modèles locaux ?
Pas toujours. Smolagents peut perdre en performance et rencontrer plus de bugs avec des modèles de moins de 7B paramètres. Il devient plus intéressant avec des modèles locaux suffisamment capables, surtout quand on veut garder un agent simple et transparent. - Quand utiliser CrewAI plutôt qu’un seul agent ?
CrewAI devient pertinent quand plusieurs agents doivent travailler ensemble avec des rôles distincts. Si votre besoin peut être traité par un seul agent simple, inutile de complexifier. Si vous avez une vraie logique de coopération, CrewAI est plus adapté.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer de l’idée IA au système utile, mesurable et maintenable, sans empiler des outils au hasard. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer ou industrialiser vos agents IA locaux, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.