Un agent d’intelligence artificielle peut savoir qu’il doit consulter une base de données, appeler une API météo puis lancer un calcul, tout en échouant au moment de les enchaîner. Un argument mal formé, un outil choisi trop tôt ou une réponse impossible à obtenir suffit à faire dérailler toute la tâche. Pour entraîner ces agents, il faut donc des exemples où la requête, les appels d’outils et la réponse finale forment un parcours cohérent.
Le problème est que ces exemples coûtent cher à produire. La méthode habituelle commence par inventer une demande d’utilisateur, puis laisse un autre modèle chercher, par essais et erreurs, la suite d’outils capable de la résoudre. Certaines demandes n’ont tout simplement pas de solution avec les outils disponibles. D’autres finissent par réussir après de nombreux détours inutiles, qui contaminent les données d’entraînement.
Avec ToolGrad, une équipe liée à Google, à l’université de Tokyo et au RIKEN propose de retourner le processus. Le système construit d’abord une chaîne d’API qui a réellement fonctionné, puis rédige la question à laquelle cette chaîne pourrait répondre. Google Research a présenté cette approche le 10 septembre 2026, après son acceptation parmi les Findings d’ACL 2026.
L’idée tient en une phrase, mais les résultats annoncés sont marquants : 99,8 % des échantillons générés passent la vérification, contre 63,8 % pour une méthode de référence fondée sur une recherche en profondeur. Des modèles Gemma 3 affinés sur seulement 500 exemples ToolGrad progressent nettement dans l’appel de fonctions et rivalisent, sur un banc d’essai précis, avec des modèles propriétaires beaucoup plus grands.
Ce n’est pas encore une recette universelle pour créer des agents autonomes. Les expériences portent surtout sur des appels d’outils en un seul tour, les requêtes restent synthétiques et les performances cessent de progresser quand le jeu de données grandit trop. Mais ToolGrad révèle un levier important : pour rendre un agent plus fiable, il peut être plus efficace d’améliorer la fabrication de ses exercices que d’augmenter simplement la taille de son modèle.
Pourquoi les données d’outils sont difficiles à fabriquer
Un jeu d’entraînement classique associe une entrée à une sortie. Pour un agent, l’objet à apprendre est plus riche. Il comprend la demande de l’utilisateur, la sélection des fonctions pertinentes, leurs paramètres, l’ordre des appels, les résultats intermédiaires et la réponse finale.
Prenons une requête apparemment simple : « Trouve le restaurant végétarien le mieux noté à moins de vingt minutes de mon hôtel et ajoute-le à mon itinéraire. » L’agent peut devoir localiser l’hôtel, interroger un service de cartographie, filtrer les restaurants, calculer les temps de trajet, consulter les notes puis modifier un agenda. Il faut que chaque outil soit disponible, que ses sorties soient compatibles avec l’étape suivante et que l’ensemble réponde réellement à la demande.
Les approches dites query-first inventent d’abord la requête. Un agent explore ensuite la bibliothèque d’API jusqu’à découvrir un chemin satisfaisant, souvent avec une recherche en profondeur. Cette logique ressemble à la construction d’un labyrinthe avant de vérifier qu’il possède une sortie.
ToolGrad part du côté opposé. Il choisit et exécute des outils compatibles, conserve uniquement les appels réussis, assemble progressivement un workflow, puis demande à un modèle de langage de formuler la requête et la réponse correspondantes. La solvabilité n’est plus une hypothèse : elle est inscrite dans le point de départ.
Quatre modules pour construire une chaîne valide
À chaque itération, ToolGrad examine un lot de 50 API et fait intervenir quatre fonctions.
L’API Proposer repère jusqu’à trois outils susceptibles d’enrichir le workflow en cours. Ce premier filtre évite d’exécuter toutes les API du lot. Les API Executors testent ensuite les candidates en parallèle et produisent un rapport complet : appel effectué, résultat reçu et statut de réussite.
L’API Selector compare ces rapports et choisit l’outil qui apporte le plus de valeur. Il décide aussi où l’ajouter : à la suite d’une chaîne existante ou dans une nouvelle branche parallèle. Enfin, le Workflow Updater insère mécaniquement l’appel retenu et fait réécrire par un modèle la requête synthétique et la réponse finale afin qu’elles restent cohérentes avec le nouveau parcours.
Le cycle est répété dix fois. Le résultat est un triplet composé d’une question, d’un workflow vérifié et d’une réponse. Des outils négatifs, proches mais inutiles, sont ensuite ajoutés aux choix proposés au modèle pendant l’entraînement. L’agent doit ainsi apprendre non seulement à appeler la bonne fonction, mais aussi à ignorer celles qui lui ressemblent.
Un « gradient textuel » qui n’est pas un gradient mathématique
Le nom ToolGrad vient de TextGrad, une méthode qui utilise les critiques rédigées par un modèle pour améliorer un prompt. L’analogie avec l’apprentissage automatique est volontaire : une prédiction est évaluée, un signal indique dans quelle direction progresser, puis le système est mis à jour.
Dans ToolGrad, ce signal n’est pourtant ni une dérivée ni une quantité numérique. Le sélecteur lit les rapports d’exécution et désigne l’API la plus utile ainsi que sa place dans le workflow. Cette décision discrète joue le rôle de « gradient » : elle oriente l’exemple synthétique vers une chaîne plus complexe sans modifier les poids du modèle à chaque itération.
Le vocabulaire peut prêter à confusion. ToolGrad ne rend pas une API différentiable et ne rétropropage rien à travers les services appelés. Il transpose une intuition d’optimisation à un processus de génération de données. L’avantage est pratique : les retours riches d’un modèle de langage peuvent guider une construction que des règles numériques simples décriraient mal.
99,8 % de réussite et des chaînes plus complexes
Les chercheurs ont utilisé la bibliothèque ToolBench, qui rassemble plus de 16 000 API réelles, pour comparer ToolGrad à la fabrication traditionnelle query-first. Sur 500 générations, ToolGrad atteint un taux de validation de 99,8 %, contre 63,8 % pour l’exploration par recherche en profondeur.
Les exemples réussis ne sont pas plus faciles pour autant. Ils contiennent en moyenne 3,4 appels d’outils utiles, contre 2,1 pour la référence. Le nombre d’étapes d’exécution d’outils tombe parallèlement de 34,3 à 20 par échantillon, tandis que la mesure liée aux appels de modèles reste presque stable, à 63,9 contre 64,5.
Cette combinaison est le cœur du résultat : ToolGrad obtient davantage de chaînes utilisables, plus longues, avec moins d’essais d’API. Trois générations seulement ont échoué parce qu’aucun des outils sélectionnés n’a renvoyé de réponse correcte au fil des dix itérations.
La méthode ne supprime toutefois pas tout coût. L’exécution parallèle des candidates reste l’étape la plus chère, car chacune mobilise un agent et une API externe. Elle déplace surtout la dépense depuis une exploration largement aveugle vers des essais filtrés et directement vérifiables.
Cinq cents exemples suffisent à changer Gemma 3
L’équipe a produit ToolGrad-500, un petit jeu de 500 workflows, puis l’a utilisé pour affiner par apprentissage supervisé des modèles Gemma 3 de 1, 4 et 12 milliards de paramètres. Les modèles obtenus ont été comparés à leur version de base, à des variantes entraînées sur ToolBench et à plusieurs systèmes propriétaires.
Sur le Berkeley Function Calling Leaderboard, ou BFCL, les trois tailles gagnent respectivement 8,1, 8,0 et 6,3 points par rapport aux modèles Gemma de départ. Le ToolGrad-12B atteint un score global de 83,1 sur le périmètre évalué, à un dixième de point de Gemini 2.5 Pro. Il devance également Gemini 2.5 Flash Lite, le modèle qui avait servi à générer les données synthétiques.
Ce dernier résultat illustre un phénomène intéressant : un élève peut dépasser son professeur si les exemples produits par celui-ci sont filtrés, exécutables et bien structurés. Le modèle générateur n’a pas besoin de résoudre à lui seul toutes les futures requêtes. Il doit contribuer à fabriquer un programme d’entraînement plus propre que ses propres trajectoires spontanées.
Il faut néanmoins lire le classement avec précision. Le papier utilise les versions 1 et 2 de BFCL et se concentre sur les appels d’outils en un seul tour. La comparaison ne démontre pas qu’un Gemma 3 de 12 milliards de paramètres surpasse globalement les modèles propriétaires en conversation, en raisonnement long ou dans des agents qui observent le résultat d’une action avant de décider de la suivante.
Ce que ToolGrad ne sait pas encore enseigner
La première limite est donc temporelle. Les modèles entraînés prédisent leurs appels d’outils en une fois. Ils n’apprennent pas vraiment le cycle d’un agent déployé : agir, observer une réponse, corriger son plan, demander une précision à l’utilisateur et poursuivre pendant plusieurs tours. Les auteurs reconnaissent que les cadres ReAct, la recherche arborescente et les évaluations multi-tours récentes restent hors du périmètre.
La deuxième limite concerne le réalisme des requêtes. Puisqu’un modèle rédige la question après avoir vu la solution, il risque de produire un langage trop propre, trop explicite ou trop uniforme. Les vraies demandes comportent des omissions, des ambiguïtés, des préférences implicites et des changements d’avis. Garantir qu’une requête est soluble ne garantit pas qu’elle ressemble à celle d’un humain.
La troisième limite apparaît lorsque le volume augmente. Dans l’étude d’échelle, les performances progressent d’abord entre 100 et 500 exemples, puis finissent par diminuer jusqu’à 2 000. ToolGrad tend à recréer des combinaisons d’outils similaires parce que chaque échantillon est généré indépendamment. Les auteurs proposent d’ajouter une mémoire globale pour détecter les répétitions et diversifier le programme d’entraînement.
Enfin, un appel techniquement réussi n’est pas nécessairement une action souhaitable. Une API peut répondre correctement tout en modifiant le mauvais compte, en exposant une donnée sensible ou en déclenchant une dépense. Les expériences vérifient surtout la validité fonctionnelle des chaînes ; elles ne remplacent ni les permissions, ni les bacs à sable, ni les confirmations humaines nécessaires en production.
Ce que les entreprises peuvent en retenir
ToolGrad ne doit pas être lu uniquement comme un moyen de battre un classement. Son principe peut inspirer la préparation d’agents spécialisés. Une entreprise possède souvent un catalogue d’API internes, des procédures métiers et des environnements de test, mais peu de conversations annotées montrant comment tout combiner.
Une approche answer-first permettrait de partir de workflows autorisés et exécutables : récupérer une commande, vérifier son paiement, consulter le stock puis préparer un retour ; ou extraire une facture, contrôler un contrat et créer une tâche de validation. Les questions synthétiques seraient générées ensuite autour de ces parcours connus.
Cette logique présente trois intérêts. Elle produit une trace reproductible, facilite le contrôle des données avant l’entraînement et évite d’enseigner à l’agent des tentatives erronées comme si elles faisaient partie de la bonne solution. Elle peut aussi couvrir systématiquement des combinaisons rares que les historiques réels contiennent peu.
Mais une adaptation sérieuse devrait ajouter ce que l’expérience académique laisse de côté : des requêtes humaines reformulées, des erreurs réalistes, des autorisations par rôle, des outils temporairement indisponibles et des tests sur les effets de bord. Le workflow valide devient un squelette, pas une preuve que l’agent se comportera correctement dans toutes les circonstances.
Le vrai changement est dans la fabrique des exercices
La course aux agents a longtemps mis l’accent sur le raisonnement des modèles et sur le nombre d’outils qu’on leur connecte. ToolGrad rappelle qu’entre ces deux éléments se trouve une infrastructure moins visible : la qualité des trajectoires utilisées pour l’apprentissage.
En construisant la solution avant la question, le système évite une partie du gaspillage inhérent aux scénarios impossibles. Il transforme l’exécution réelle des API en filtre de qualité et montre qu’un jeu de données très compact peut modifier fortement le comportement d’un modèle.
La prochaine étape ne consiste pas simplement à passer de 500 à cinq millions d’exemples. Les propres résultats des auteurs montrent que la répétition peut annuler les gains. Il faudra diversifier les workflows, rapprocher les requêtes synthétiques du langage humain, introduire la mémoire et tester les agents sur des interactions longues où le monde répond de manière imprévisible.
ToolGrad apporte donc moins un agent prêt à travailler qu’une meilleure manière de lui préparer ses travaux pratiques. C’est peut-être là que se jouera une part importante de la fiabilité future : dans des exercices dont on sait, avant même de poser la question, que les outils permettent réellement d’aboutir.
Références
- Google Research — présentation de ToolGrad, 10 septembre 2026
- Article scientifique ToolGrad — version révisée du 17 juin 2026
- Code source officiel de ToolGrad
- Jeu de données ToolGrad-500 sur Hugging Face
- TextGrad — méthode à l’origine de l’analogie des gradients textuels
