Ces dernières années, « un agent utilise un outil » signifiait un mécanisme spécifique : le modèle émet un blob structuré — généralement JSON — nommant une fonction et ses arguments, un runtime l''analyse, appelle la fonction et alimente le résultat dans le contexte du modèle. Ce motif d''appel d''outil a alimenté la première génération de frameworks d''agent et cela fonctionne. Mais il a une inefficacité tranquille qui devient évidente une fois que tu la cherches : chaque action est un round-trip séparé à travers le modèle. Veux-tu appeler trois outils et combiner leurs résultats ? C''est au moins trois appels de modèle, chacun relisant le contexte accumulé, parce que le modèle ne peut émettre qu''un appel d''outil JSON à la fois et doit attendre de voir chaque résultat avant de décider le suivant. Une école de pensée croissante en 2026 soutient qu''il y a un meilleur chemin, et il se cache à vue : laisse l''agent écrire du code.
C''est le paradigme de l''agent orienté code, et il remodèle comment fonctionnent les frameworks d''agent les plus efficaces. Au lieu d''émettre JSON, l''agent écrit un snippet de Python — qui peut appeler plusieurs outils, boucler, utiliser les variables et combiner les résultats — et le runtime l''exécute. Ce guide explique pourquoi ce changement importe, comment il change les performances et le coût de l''agent, et comment les frameworks principaux l''implémentent, via smolagents (l''approche orientée code dans sa forme la plus pure) et Pydantic AI (agents typé-sûrs de l''équipe Pydantic). Il couvre aussi le flip-side essentiel : exécuter le code généré par le modèle en toute sécurité.
Le problème avec les appels d''outils JSON
Pour voir pourquoi orienté code importe, regarde de près ce que les appels d''outils JSON coûtent. Considère une tâche qui nécessite de chercher les données d''une API, les filtrer et calculer un résumé. Avec les appels d''outils, le modèle émet un appel à l''outil de fetch, attend le résultat, émet un appel à un outil de filtre, attend, puis émet un appel à un outil de calcul, attend, et finalement compose une réponse. C''est quatre invocations de modèle, et chacune re-traite tout le contexte croissant — la tâche originale, plus chaque résultat intermédiaire accumulé jusqu''à présent. Le coût en tokens et la latence augmentent avec le nombre d''étapes, et les tâches complexes ont plusieurs étapes.
Il y a un problème plus subtil aussi : les appels d''outils JSON contraignent comment l''agent peut composer les actions. Chaque étape c''est un appel de fonction unique avec des arguments littéraux. Le modèle ne peut pas facilement exprimer « appelle cet outil pour chaque élément de cette liste », ou « si le résultat est vide, essaye une requête différente », ou « combine ces deux résultats avec un calcul », sans briser chacun d''eux en round-trips séparés et raisonnant à propos de l''état intermédiaire à travers les appels de modèle. L''expressivité de la programmation ordinaire — boucles, conditions, variables, composition — est exactement ce qui manque, et ceux-ci sont les construits qui rendent la logique multi-étape naturelle. L''appel d''outil demande au modèle d''être un compteur de programme émettant une instruction à la fois, alors que ce que la tâche a besoin c''est un programme.
L''insight orienté code
L''approche orientée code résout les deux problèmes à la fois. Au lieu d''émettre un appel d''outil JSON unique, l''agent écrit un bloc de code Python qui peut appeler plusieurs outils, utiliser le contrôle de flux, tenir les valeurs intermédiaires dans les variables et retourner un résultat. Le runtime exécute ce code, et les outils que l''agent peut appeler sont simplement les fonctions Python disponibles dans son environnement d''exécution. L''API fetch, le filtre et le calcul du précédent exemple deviennent un bloc de code unique avec trois appels de fonction et un peu de logique entre eux — exécutés en une seule étape, à partir d''une seule invocation de modèle.
Le gain d''efficacité est réel et mesurable. Parce qu''un bloc de code unique peut accomplir ce qui a pris précédemment plusieurs round-trips d''appel d''outil, les agents orientés code font significativement moins d''appels LLM — les réductions signalées autour de 30% — ce qui réduit à la fois le coût et la latence. Et parce que l''agent exprime les actions dans un vrai langage de programmation, il gère les tâches compositionnelles (itérer sur les résultats, branchement sur les conditions, combinaison des calculs) bien plus naturellement qu''une séquence d''appels JSON isolés ne pourrait. Il y a aussi un argument basé sur les données d''entraînement : les modèles ont vu des quantités énormes de code et sont vraiment bons à l''écrire, arguably meilleur qu''ils ne produisent du JSON d''appel d''outil parfaitement formaté pour les schemas nouveaux. Demander à un modèle d''exprimer son intention comme du code joue sur une force.
smolagents : le paradigme dans sa forme la plus pure
smolagents, de Hugging Face, est l''expression la plus claire de l''idée orientée code. C''est une bibliothèque délibérément minimaliste construite autour du CodeAgent : un agent dont les actions sont du code Python. Donne-lui un ensemble d''outils (fonctions Python ordinaires) et un modèle, confie-lui une tâche, et cela fonctionne en écrivant et exécutant du code qui appelle ces outils, boucle et calcule jusqu''à ce qu''il ait une réponse. La bibliothèque reste petite et modifiable exprès — sa philosophie c''est que la boucle de l''agent devrait être assez simple à lire et modifier, avec l''intelligence venant du modèle et de l''approche d''exécution de code plutôt que d''un framework lourd.
Ce qui rend smolagents convaincant au-delà de l''efficacité c''est comment il gère naturellement les vraies tâches. Parce que l''agent écrit du code, une tâche de recherche peut chercher, analyser les résultats, les filtrer et calculer sur eux en une étape cohérente ; une tâche de données peut charger, transformer et analyser sans un round-trip JSON par opération. C''est agnostique au modèle — fonctionnant avec les modèles Hugging Face, les modèles locaux ou n''importe quel fournisseur via LiteLLM — donc tu n''es pas verrouillé à un backend, et il supporte l''exécution sandboxée que l''approche orientée code requiert fondamentalement (plus à ce sujet ci-dessous). Pour les équipes qui veulent l''efficacité orientée code dans un paquet petit et compréhensible, smolagents c''est l''implémentation de référence, et le cheatsheet smolagents couvre ses agents, ses outils et son sandboxing.
Le tradeoff du minimalisme de smolagents c''est qu''il fournit moins d''échafaudage qu''un framework lourd — moins d''abstractions intégrées pour l''orchestration multi-agent complexe, l''état durable ou le contrôle de flux élaboré. Pour les boucles de code agent unique c''est une fonctionnalité, pas une limitation ; pour les systèmes stateful massifs tu pourrais atteindre quelque chose de plus lourd. Mais comme l''expression la plus pure, la plus efficace des agents orientés code, c''est difficile de battre.
Pydantic AI : la sécurité des types rencontre les agents
Pydantic AI, de l''équipe derrière Pydantic (la bibliothèque de validation qui soutient FastAPI et une grande partie de l''écosystème AI Python), aborde les agents d''un angle différent : la sécurité des types et l''expérience du développeur. Son pari c''est que le même rigor que Pydantic a apporté à la validation des données — déclarer la forme de tes données avec les indices de type Python et obtenir la validation automatique — devrait s''appliquer aux agents. Chaque entrée d''agent, sortie et appel d''outil est typé, le framework valide que les sorties du modèle correspondent à la structure attendue, et il peut automatiquement demander au modèle de se corriger quand la sortie ne conforme pas. Le résultat c''est une expérience du développeur style FastAPI pour la construction d''agents : familière, vérifiée par les types et orientée production.
La sécurité des types importe pour les agents plus qu''il pourrait sembler. Une douleur récurrente des applications LLM c''est que la sortie du modèle est du texte non structuré, et la transformer de manière fiable en les données structurées que ton programme a besoin — les bons champs, les bons types, les valeurs valides — c''est fiddly et sujet aux erreurs. Pydantic AI rend la sortie structurée une garantie de première classe : tu déclares le type de sortie, et le framework l''impose, reessayant avec le modèle si nécessaire. Cela transforme « analyser le texte du modèle et espérer qu''il soit valide » en « recevoir un objet validé et typé », ce qui est exactement ce que le code production veut. Son redesign V2 en 2026 a poussé plus loin avec un modèle harness-first qui groupe les outils, les instructions et les paramètres dans les capacités composables. Le cheatsheet Pydantic AI couvre ses agents typés et ses outils.
Pydantic AI et smolagents ne sont pas vraiment des concurrents autant que des expressions de priorités différentes. smolagents optimise pour l''efficacité et l''expressivité du code-comme-action ; Pydantic AI optimise pour la sécurité des types, la sortie structurée validée et l''ergonomie production. Une équipe qui valorise moins d''appels LLM et la logique multi-étape naturelle penche smolagents ; une équipe qui valorise la sécurité des types, la validation et le code agent style FastAPI penche Pydantic AI. Les deux représentent le mouvement 2026 loin des frameworks première-génération, JSON-uniquement vers quelque chose de plus programmeur-natif.
Le problème de sécurité : exécuter le code généré par modèle
Les agents orientés code ont une attrape évidente et sérieuse : ils exécutent le code écrit par un modèle de langage, et le code généré par modèle est non fiable par définition. Un agent qui peut écrire et exécuter du Python arbitraire peut, s''il est compromis par une injection de prompt ou simplement par erreur, supprimer les fichiers, exfiltrer les données, faire les appels réseau ou consommer les ressources sans limite. Ce n''est pas une préoccupation hypothétique — c''est le risque opérationnel central de tout le paradigme, et le prendre au sérieux c''est non-négociable pour n''importe quel déploiement production.
La réponse c''est le sandboxing : exécuter le code généré dans un environnement isolé avec les capacités limitées. Les frameworks le supportent directement — smolagents peut exécuter du code dans les sandboxes distants comme E2B, ou dans les conteneurs Docker ou Modal, plutôt que dans le processus hôte, et tu peux restreindre quels modules le code généré est même autorisé à importer. Le principe c''est le privilege minimum : le sandbox devrait avoir uniquement l''accès que la tâche requiert genuinely — pas d''accès filesystem qu''elle n''a pas besoin, pas d''egress réseau au-delà de ce qui est nécessaire, pas d''capacité à affecter l''hôte. Exécuter le code généré par agent directement dans ton processus application, avec les permissions de ton application, c''est l''erreur qui transforme un agent utile en une vulnérabilité d''exécution de code à distance portant une interface amicale.
La guidance pratique c''est simple mais doit être suivi. En développement, l''exécution locale c''est commode et acceptable pour les tâches fiables non sensibles. Dans n''importe quoi approchant la production, ou n''importe quelle tâche touchant l''entrée non fiable ou les systèmes sensibles, exécute le code dans un sandbox avec l''accès privilege minimum, restreint les imports et traite la sortie de code de l''agent la manière dont tu traiterais n''importe quelle entrée non fiable — parce que c''est ce qu''elle est. L''efficacité et la puissance des agents orientés code sont vraies, mais elles viennent avec une responsabilité que les appels d''outils JSON (qui sont plus limités par conception) n''imposaient pas aussi nettement. Accepte cette responsabilité et sandbox proprement, et le paradigme c''est à la fois puissant et sûr.
Quand les appels d''outils JSON sont toujours le bon choix
Les agents orientés code sont plus efficaces et expressifs, mais ce serait une erreur de conclure que les appels d''outils JSON sont obsolètes. Il y a les vraies situations où le modèle limité, un-appel-à-la-fois c''est la meilleure adaptation, et comprendre les garder le choix honnête. Le plus clair c''est quand les actions doivent être étroitement contrôlées et auditées. Un appel d''outil JSON c''est un événement discret, inspectable, facilement-validable : l''agent veut appeler cette fonction avec ces arguments, et tu peux approuver, logger ou rejeter avant que n''importe quoi s''exécute. Cette auditabilité c''est précieux dans les domaines à enjeux élevés — les actions financières, les changements d''infrastructure, n''importe quoi avec les side-effects irréversibles — où tu veux un humain ou une vérification de politique entre l''intention de l''agent et son exécution. Le code qui s''exécute comme un bloc c''est plus difficile de gater à cette granularité.
Le second cas c''est la simplicité. Beaucoup d''agents genuinely ont uniquement besoin d''appeler un outil à la fois dans une boucle simple — répondre à une question en appelant un outil de recherche, regarder quelque chose, accomplir une action. Pour ceux-ci, l''expressivité du code-comme-action c''est la capacité non utilisée, et la machinerie extra d''un sandbox de code c''est du surcharge sans payoff. Un agent d''appel d''outil simple c''est plus facile à raisonner et déployer quand la tâche n''a pas besoin de la composition multi-étape. Le troisième cas c''est la posture de sécurité : parce que les appels d''outils JSON ne laissent que l''agent invoquer les fonctions prédéfinies avec les arguments structurés, c''est inherentement plus limité que l''exécution du code arbitraire, et pour certains modèles de menace ce rayon d''explosion plus petit vaut le coût d''efficacité même quand une tâche pourrait bénéficier du code.
La vue mature c''est que ce sont deux outils pour les travaux différents, pas un gagnant et un perdant. Atteindre pour orienté code quand les tâches impliquent la véritablement composition multi-étape, l''itération ou le calcul sur les résultats intermédiaires, et tu peux sandbox proprement. Atteindre pour l''appel d''outil JSON quand les actions ont besoin du contrôle fin-grained et de l''audit, quand la tâche c''est assez simple que le code-comme-action c''est du overkill, ou quand la contrainte plus serrée des fonctions-prédéfinies-seulement s''adapte à vos requirements de sécurité. Plusieurs frameworks, inclus smolagents, supportent à la fois un CodeAgent et un agent appelant d''outils pour exactement cette raison — le paradigme c''est un choix tu fais par cas d''usage, pas une doctrine tu adoptes en gros.
Le résumé
Le mouvement des appels d''outils JSON vers les agents orientés code c''est un des changements significatifs dans comment les agents sont construits en 2026, et c''est piloté par une observation simple : laisser un agent écrire du code, plutôt que d''émettre un appel d''outil à la fois, c''est plus efficace et plus expressif. Moins d''appels LLM, logique multi-étape naturelle et modèles jouant à leur force d''écriture de code c''est le payoff, visible dans les réductions d''appel rougly 30% que les frameworks orientés code rapportent. smolagents exprime le paradigme dans sa forme plus pure et minimaliste ; Pydantic AI apporte la sécurité des types et la sortie structurée validée à la construction d''agent. Les deux pointent loin de la première génération de frameworks JSON-uniquement vers quelque chose de plus programmeur-natif. L''une règle tu ne peux ignorer : le code généré par modèle c''est non fiable, donc sandbox-le avec le privilege minimum. Fais cela, et les agents orientés code c''est la voie plus rapide, plus capable de construire.
Références et Ressources
Frameworks
Contexte et analyse
- The best open source frameworks for building AI agents in 2026 — Firecrawl
- Python AI Agent Library Comparison 2026 — Pydantic AI vs Instructor vs Smolagents
- Best Python AI Agent Frameworks in 2026 — Uvik
Cheatsheets connexes 1337skills