Programmatic Tool Calling : les outils orchestrés par le modèle

État au 5 novembre 2026. La famille GPT-6 reprend les capacités d’API de GPT-5.6, dont le Programmatic Tool Calling, et l’Agents API l’active par défaut (leçon 10). OpenAI recommande de vérifier la fiche du modèle avant de l’activer.

Pour comprendre ce qu’apporte le Programmatic Tool Calling, il faut d’abord regarder ce que coûte l’appel de fonctions classique. Le modèle demande l’exécution d’un outil, votre code l’exécute, le résultat repart vers le modèle, qui le lit et décide de la suite. Un aller-retour, ce n’est pas grave. Dix allers-retours sur une même tâche, c’est autre chose : chaque étape ajoute sa latence, et chaque résultat intermédiaire, même volumineux, même inutile pour la réponse finale, repasse dans le contexte du modèle et se facture en jetons. Sur une tâche riche en outils, ce sont les allers-retours qui dominent la latence et la facture.

Ce qui change

Le Programmatic Tool Calling est arrivé avec GPT-5.6, le 9 juillet 2026, dans la Responses API. Au lieu de demander les outils un par un, le modèle écrit un petit programme JavaScript qui coordonne ses outils : il peut lancer des appels en parallèle, utiliser des boucles et des conditions, et garder les résultats intermédiaires dans l’environnement d’exécution. Seul le résultat réduit, celui qui compte pour la suite, remonte dans le contexte.

Prenez une API paginée. En appel de fonctions classique, chaque page de résultats traverse le contexte pour que le modèle décide s’il faut demander la suivante. Avec le Programmatic Tool Calling, le modèle écrit une boucle qui parcourt les pages, additionne ce qui doit l’être et ne lui rapporte que les totaux : moins de jetons, moins de latence, et moins de code de pilotage à maintenir de votre côté.

OpenAI exécute chaque programme dans un environnement V8 neuf et isolé. Il n’y a ni Node.js, ni installation de paquets, ni accès direct au réseau, ni système de fichiers général, ni état conservé d’un programme à l’autre : le programme n’agit sur le monde qu’à travers les outils que vous lui ouvrez. Pour la Responses API, ce fonctionnement est compatible avec la conservation zéro des données (ZDR), à condition qu’elle soit activée pour l’organisation ou le projet.

L’activer dans la Responses API

Deux réglages suffisent. Vous ajoutez l’outil hébergé programmatic_tool_calling à la requête, puis vous indiquez sur chaque outil éligible qui peut l’appeler, avec allowed_callers : ["direct"] (le comportement par défaut, le modèle appelle l’outil lui-même), ["programmatic"] (seul un programme peut l’appeler) ou les deux. La documentation conseille aussi de décrire la sortie de chaque fonction avec output_schema, pour que le code généré puisse s’appuyer sur ses champs.

from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "name": "lire_stock",
        "description": "Renvoie un objet avec sku (texte) et unites (nombre).",
        "parameters": {
            "type": "object",
            "properties": {"sku": {"type": "string"}},
            "required": ["sku"],
            "additionalProperties": False,
        },
        "output_schema": {
            "type": "object",
            "properties": {"sku": {"type": "string"}, "unites": {"type": "number"}},
            "required": ["sku", "unites"],
            "additionalProperties": False,
        },
        "allowed_callers": ["programmatic"],
    },
    {"type": "programmatic_tool_calling"},
]

response = client.responses.create(
    model="gpt-5.6-terra",
    input="Vérifie le stock des références A12, B07 et C33 et signale celles sous 10 unités.",
    tools=tools,
)

Les types d’outils qui peuvent être appelés depuis un programme sont les fonctions et outils personnalisés, les outils MCP, apply_patch, le shell local ou hébergé et l’interpréteur de code. Pour un outil MCP soumis à approbation, le programme s’interrompt jusqu’à votre accord.

Ce que votre application reçoit

La réponse reste un objet Responses ordinaire, avec trois types d’éléments à reconnaître. Un élément program contient le JavaScript généré. Des éléments function_call correspondent aux appels de vos fonctions faits par ce programme ; leur champ caller désigne le programme appelant. Enfin, un élément program_output livre le résultat final du programme, avec un statut completed ou incomplete.

Votre application n’exécute jamais le JavaScript : c’est OpenAI qui le fait tourner. Elle exécute seulement vos propres fonctions, puis renvoie chaque résultat dans un function_call_output en recopiant le champ caller sans le modifier, pour que le bon programme reprenne. On boucle ainsi jusqu’à ce que la réponse ne contienne plus d’appel à exécuter.

Reconnaître les tâches qui en profitent

Toutes les intégrations d’outils ne gagnent pas à migrer. Le guide d’OpenAI propose une règle claire : le Programmatic Tool Calling convient aux étapes dont le déroulement est prévisible et dont le code peut renvoyer un résultat plus petit et structuré. Il est fait pour filtrer, joindre, classer, dédoublonner, agréger ou valider plusieurs résultats, ou pour enchaîner des appels dépendants dont le flux de données est prévisible. L’appel direct reste préférable pour une recherche ou une action unique, pour une recherche adaptative où chaque résultat doit orienter la décision suivante, et pour la validation finale des citations. Il reste aussi le choix par défaut pour les écritures et les actions soumises à approbation, afin de garder une frontière d’autorisation nette.

Le critère de décision tient en une question : où votre agent passe-t-il son temps ? Si la réponse est « à attendre des allers-retours d’outils », le Programmatic Tool Calling est le premier chantier à évaluer. Si vos appels d’outils sont rares et leurs résultats courts, gardez votre architecture et concentrez l’effort ailleurs.

À vous de jouer

Repérer un candidat. Prenez un flux de votre agent qui appelle plusieurs outils. Pour chaque étape, notez le nombre d’appels, la taille des résultats intermédiaires et s’il s’agit d’une lecture ou d’une écriture. Classez chaque étape selon la règle ci-dessus. Pour l’étape la plus prometteuse, rédigez une consigne qui précise les outils autorisés, la forme du résultat attendu, la condition d’arrêt, le nombre maximal de nouvelles tentatives et ce qui reste en appel direct.

Sources officielles : Programmatic Tool Calling · Using GPT-6 (documentation de l’API OpenAI) · Annonce de GPT-5.6 (OpenAI, 9 juillet 2026)

Points clés à retenir

• Le modèle écrit et exécute du JavaScript qui coordonne ses outils, dans un environnement isolé géré par OpenAI
• On l’active avec l’outil programmatic_tool_calling et le champ allowed_callers de chaque outil
• Votre application exécute seulement ses fonctions et renvoie le champ caller intact
• À privilégier pour filtrer, agréger ou enchaîner des appels prévisibles ; l’appel direct reste la règle pour les écritures et les approbations