GPT-5.6 : Appel d'outils programmatique – Le modèle écrit le code d'orchestration

L'appel de fonction classique suit une boucle connue : le modèle demande un outil, votre application l'exécute, vous renvoyez le résultat, puis le modèle demande l'appel suivant. Quatre outils impliquent quatre allers-retours ; quarante outils, quarante. Chaque passage ajoute de la latence réseau et réinjecte du contexte facturé. Lorsque OpenAI a rendu GPT-5.6 généralement disponible le 9 juillet 2026, l'API de Réponses a introduit l'appel d'outil programmatique pour éliminer cette orchestration répétitive.

Essayez Apidog dès aujourd’hui

L'idée est simple : au lieu de renvoyer les appels d'outils un par un pour les exécuter dans votre boucle applicative, le modèle écrit du JavaScript qui orchestre lui-même plusieurs appels. Ce code s'exécute dans un environnement V8 isolé, sans accès réseau. Vos outils restent l'unique moyen d'interagir avec des systèmes externes : la limite de sécurité reste donc la même que pour les appels de fonction OpenAI. Ce qui change est l'emplacement de la logique de contrôle : boucles, conditions et agrégations passent de votre application au modèle.

Chaque outil que vous exposez devient ainsi un contrat que le modèle peut appeler en rafale, et non plus une seule fois par tour. La précision du schéma, les réponses d'erreur, les limites de débit et l'idempotence deviennent essentiels. Ce guide explique le changement, montre la boucle remplacée et détaille comment préparer vos endpoints avec Apidog.

TL;DR

• GPT-5.6 a été mis à disposition générale le 9 juillet 2026. L'API de Réponses a alors reçu l'appel d'outil programmatique.
• Le modèle peut écrire du JavaScript pour composer boucles, conditions et agrégations autour de vos outils.
• Le code généré s'exécute dans un bac à sable V8 isolé, sans accès réseau.
• Vos définitions d'outils restent la seule voie d'accès aux systèmes externes : la frontière de sécurité ne change pas.
• La latence et le coût des jetons ne s'accumulent plus mécaniquement avec le nombre d'appels d'outils.
• Testez chaque endpoint et chaque schéma avant de laisser le modèle les orchestrer.

Ce qui a été livré le 9 juillet

GPT-5.6 est arrivé sous la forme d'une famille à trois niveaux :

• gpt-5.6-sol pour un raisonnement approfondi ;
• gpt-5.6-terra pour un travail équilibré ;
• gpt-5.6-luna pour des volumes rapides et rentables.

L'alias gpt-5.6 redirige vers Sol. Les trois modèles sont disponibles en libre-service via l'API, après une prévisualisation limitée de deux semaines terminée lorsque la restriction d'accès a été levée le 8 juillet.

La famille de modèles a reçu beaucoup d'attention au lancement, mais la nouvelle surface d'API est le point le plus important pour les développeurs d'agents. Selon la couverture de lancement de MarkTechPost et la documentation d'OpenAI, l'API de Réponses a intégré quatre nouveautés lors de cette disponibilité générale :

1. l'appel d'outil programmatique ;
2. une version bêta multi-agents ;
3. le raisonnement persistant entre les tours ;
4. des paramètres de détails visuels qui préservent les dimensions originales des images.

L'appel d'outil programmatique est le changement central : OpenAI le décrit comme du JavaScript généré par le modèle pour orchestrer les appels d'outils, dans un environnement V8 isolé sans accès réseau.

La boucle que l'appel d'outil programmatique remplace

Voici un appel de fonction classique avec l'API de Réponses :

import OpenAI from "openai";

const client = new OpenAI();

const tools = [
  {
    type: "function",
    name: "get_flight_status",
    description: "Return live status for a flight by IATA flight number.",
    parameters: {
      type: "object",
      properties: {
        flight_number: {
          type: "string",
          description: "IATA flight number, for example SQ317"
        }
      },
      required: ["flight_number"]
    }
  }
];

let response = await client.responses.create({
  model: "gpt-5.6",
  input: "Which of these 12 flights are delayed: SQ317, BA15, UA857...",
  tools
});

Le modèle émet un appel de fonction, puis votre application doit l'exécuter, ajouter un élément function_call_output et relancer l'API :

// Un aller-retour par appel d'outil : cette boucle est le coût caché.
while (hasFunctionCalls(response)) {
  const outputs = await executeToolCalls(response);

  response = await client.responses.create({
    model: "gpt-5.6",
    previous_response_id: response.id,
    input: outputs,
    tools
  });
}

Pour 12 vols, cette boucle peut s'exécuter 12 fois. Chaque itération a deux coûts :

1. Latence : un aller-retour vers OpenAI, plus le temps d'inférence, souvent sérialisé car l'appel suivant dépend du résultat précédent.
2. Jetons : les sorties d'outils s'accumulent dans le contexte ; les dernières itérations retraitent les résultats des premières.

Dans une architecture multi-agents, cette accumulation devient vite coûteuse. Un agent en cinq étapes, dont chaque étape encapsule une boucle de dix appels, peut représenter cinquante invocations de modèle.

Cette boucle n'est pas de l'intelligence : c'est de l'orchestration applicative.

Comment le mode programmatique change la forme

Avec l'appel d'outil programmatique, le modèle peut écrire un programme JavaScript qui :

1. parcourt les douze numéros de vol ;
2. appelle get_flight_status pour chacun ;
3. filtre les vols retardés ;
4. trie les résultats par durée de retard ;
5. retourne une réponse agrégée.

Vos outils réalisent toujours le travail réel. La différence est que la logique de contrôle appartient désormais au modèle et s'exécute dans le bac à sable.

Trois propriétés rendent ce modèle exploitable :

• Environnement isolé : le JavaScript généré s'exécute dans un bac à sable V8 sans accès réseau. Il ne peut pas récupérer une URL, ouvrir une socket ou exfiltrer des données par lui-même.
• Outils comme seule sortie : chaque effet externe passe par les outils que vous avez déclarés. Si vous n'exposez pas delete_record, le code généré ne peut pas supprimer d'enregistrement.
• Flux de contrôle expressif : boucles, conditions, sorties anticipées et agrégations peuvent s'exécuter sans nécessiter un aller-retour par appel.

	Appel de fonction classique	Appel d'outil programmatique
Qui écrit le flux de contrôle	Votre application	Le modèle, en JavaScript
Allers-retours pour N appels d'outils	N, sérialisés	Un cycle de réponse
Où l'orchestration s'exécute	Votre infrastructure	Bac à sable V8 isolé, sans réseau
Comment les outils s'exécutent	Votre code les invoque	Via votre surface d'outils déclarée
Limite de sécurité	Définitions d'outils	Définitions d'outils, inchangées

Ce qui reste inchangé

Vous définissez toujours les outils avec des noms, descriptions et paramètres JSON Schema. Le modèle ne peut appeler que les outils déclarés.

La réponse à la question « que peut faire cet agent sur mes systèmes ? » ne change donc pas : uniquement ce que votre surface d'outils autorise.

En revanche, la qualité du schéma devient plus critique. Dans une boucle classique, une description ambiguë peut provoquer un mauvais appel isolé, que vous détectez avant le tour suivant. En mode programmatique, cette ambiguïté peut être intégrée à une boucle et répétée sur chaque itération.

Appliquez les mêmes bonnes pratiques que pour les sorties structurées :

• utilisez des types stricts ;
• employez des énumérations pour les ensembles fermés ;
• précisez les unités, formats et plages de valeurs ;
• marquez comme requis uniquement les champs réellement indispensables ;
• documentez les valeurs par défaut et les comportements attendus.

Exemple de schéma plus explicite :

{
  "type": "object",
  "properties": {
    "date": {
      "type": "string",
      "description": "Date au format ISO 8601 : YYYY-MM-DD."
    },
    "currency": {
      "type": "string",
      "enum": ["EUR", "USD", "GBP"],
      "description": "Devise de sortie."
    },
    "max_results": {
      "type": "integer",
      "minimum": 1,
      "maximum": 100,
      "description": "Nombre maximal de résultats à retourner."
    }
  },
  "required": ["date", "currency"]
}

Limites et questions ouvertes

Cette capacité est récente. Avant de reconstruire votre pile d'agents autour de cette fonctionnalité, tenez compte des points suivants :

• Les paramètres exacts, limites d'exécution et comportements de dépassement de délai sont documentés dans la référence de l'API et le guide du modèle OpenAI. Vérifiez-les avant d'implémenter la fonctionnalité.
• Le débogage devient une nouvelle surface. Quand l'orchestration était dans votre dépôt, vous pouviez poser des points d'arrêt. Ici, une partie du flux de contrôle est générée pour chaque requête.
• Journalisez systématiquement la séquence des appels d'outils, leurs paramètres, leurs durées et leurs résultats. Cette trace est indispensable pour comprendre le comportement du bac à sable.
• Les notes de Simon Willison sur GPT-5.6 dès le premier jour sont utiles pour suivre les résultats des tests indépendants et les éventuels cas limites.
• Commencez avec des outils en lecture seule. Observez l'orchestration générée, mesurez la consommation de jetons et comparez-la à votre boucle historique avant d'exposer des outils à effets de bord.

Vos outils sont désormais une API appelée par du code généré

Avec l'appel de fonction classique, un outil est généralement appelé une fois par aller-retour, selon un ordre contrôlé par votre code. Avec l'appel d'outil programmatique, le code généré peut appeler vos outils en rafale, se ramifier selon les réponses et agréger les résultats.

Vos endpoints doivent donc être prêts à être consommés par un client que vous ne relisez pas avant son exécution.

Concentrez-vous sur quatre aspects.

1. Précision du schéma

Indiquez systématiquement les unités, les formats et les plages.

Un paramètre date ambigu, par exemple, n'est plus un appel erroné isolé : il peut alimenter une boucle complète de requêtes invalides.

2. Formes d'erreur cohérentes

Le code généré peut se ramifier selon les erreurs. Un endpoint qui renvoie 200 OK avec une erreur cachée dans une chaîne de caractères empêche une orchestration fiable.

Retournez plutôt :

• des codes HTTP cohérents ;
• des erreurs structurées ;
• des messages actionnables ;
• des champs machine-readable si votre contrat le prévoit.

Exemple :

{
  "error": {
    "code": "FLIGHT_NOT_FOUND",
    "message": "Aucun vol ne correspond au numéro fourni.",
    "details": {
      "flight_number": "SQ999"
    }
  }
}

3. Idempotence et limites de débit

Douze appels auparavant répartis sur une minute peuvent maintenant arriver presque simultanément.

Pour chaque outil, documentez et testez :

• l'idempotence ;
• les limites de débit ;
• le comportement en cas de rafale ;
• les mécanismes de retry ;
• les délais d'expiration ;
• les réponses 429 et 5xx.

4. Latence

Un endpoint qui prend huit secondes peut être acceptable pour un appel isolé. Dans une boucle de douze itérations, il définit le temps de réponse global.

Mesurez la durée de vos outils avant de les exposer au modèle et fixez des objectifs de latence réalistes.

Un établi d'API est particulièrement utile ici. Importez ou définissez la spécification de chaque endpoint, envoyez des requêtes de test et vérifiez que chaque réponse respecte le contrat annoncé par votre outil.

Vous pouvez ensuite simuler les endpoints avec des données déterministes afin de tester l'orchestration sans toucher à la production. Téléchargez Apidog : son serveur de maquette intégré peut servir des réponses conformes au schéma pour chaque endpoint défini, ce qui permet d'observer l'orchestration du modèle avant d'accéder à des données réelles.

Checklist de préparation des outils

Avant d'activer l'appel d'outil programmatique, vérifiez cette liste :

• [ ] Chaque outil a un nom explicite et une description sans ambiguïté.
• [ ] Tous les paramètres requis sont déclarés comme tels.
• [ ] Les formats de date, devise, identifiant et unité sont documentés.
• [ ] Les ensembles fermés utilisent des enum.
• [ ] Les réponses de succès ont une structure stable.
• [ ] Les erreurs utilisent des codes HTTP et des corps structurés.
• [ ] Les endpoints supportent les rafales ou les limitent proprement.
• [ ] Les opérations d'écriture sont idempotentes lorsque c'est possible.
• [ ] Les appels, paramètres, durées et erreurs sont journalisés.
• [ ] Les outils ont été testés avec des réponses simulées avant la production.

Les autres fonctionnalités GA en bref

L'appel d'outil programmatique n'est pas arrivé seul. Deux ajouts à l'API de Réponses sont également pertinents :

• Multi-agents, en bêta : exécution parallèle de sous-agents gérée par l'API. La fonctionnalité est encore précoce : surveillez-la avant d'en faire une dépendance critique.
• Raisonnement persistant : le contexte de raisonnement est réutilisé entre les tours via reasoning.context, ce qui évite de redériver les mêmes conclusions dans les longues sessions.

Ces capacités se combinent avec l'appel d'outil programmatique : un agent qui conserve son raisonnement et orchestre lui-même ses outils peut réduire le travail redondant par tâche.

Appel d'outil programmatique vs mode Ultra

Le lancement a aussi apporté le mode Ultra. Les deux fonctionnalités peuvent sembler proches parce qu'elles font davantage par requête, mais elles ciblent des goulots d'étranglement différents.

Le mode Ultra est un paramètre multi-agents qui exécute quatre agents en parallèle par défaut, en utilisant volontairement davantage de jetons pour réduire le temps réel. Selon OpenAI, il fait passer Terminal-Bench 2.1 de 88,8 % à 91,9 %. Il est disponible dans ChatGPT Work pour les plans Pro et Entreprise, ainsi que dans Codex à partir du plan Plus.

L'appel d'outil programmatique est différent : il permet à un agent d'orchestrer ses outils en code.

Si votre problème est...	Utilisez plutôt...
La latence liée aux appels d'outils	L'appel d'outil programmatique
Le temps de délibération sur des problèmes difficiles	Le mode Ultra
La répétition de boucles applicatives	L'appel d'outil programmatique
Le besoin de paralléliser la réflexion	Le mode Ultra

Pour plus de détails, consultez notre article sur le mode Ultra de GPT-5.6.

FAQ

Dois-je réécrire mes définitions d'outils existantes ?

Non. Les outils gardent la même forme JSON Schema que dans l'appel de fonction classique.

Le travail utile consiste à les affiner : ajoutez des énumérations, précisez les formats et rendez les descriptions suffisamment explicites pour éviter les interprétations erronées dans le code généré.

Le JavaScript généré peut-il accéder à Internet ?

Non. Le code s'exécute dans un environnement V8 isolé sans accès réseau.

Vos outils déclarés sont son seul moyen d'interagir avec l'extérieur. Votre surface d'outils constitue donc l'intégralité du modèle de risque : auditez-la avec la même rigueur qu'une API publique.

Quels modèles GPT-5.6 prennent en charge l'appel d'outil programmatique ?

OpenAI le documente comme une surface de l'API de Réponses pour la famille GPT-5.6. Les trois niveaux — gpt-5.6-sol, gpt-5.6-terra et gpt-5.6-luna — sont disponibles en libre-service pour les comptes API.

Vérifiez les détails spécifiques à chaque modèle dans la référence avant de vous engager. Pour la configuration de clé et les premières requêtes, consultez comment utiliser l'API GPT-5.6.

En quoi cela diffère-t-il de l'interprète de code ?

L'interprète de code exécute du code comme livrable : analyses, graphiques ou transformations de fichiers.

L'appel d'outil programmatique génère du code dont le rôle est de coordonner vos outils déclarés. Le livrable est le résultat agrégé des outils, pas le code lui-même.

Prochaine étape

La boucle d'aller-retour était la partie la moins intéressante de nombreux agents, et GPT-5.6 la rend facultative.

L'orchestration passe au modèle. En contrepartie, vous devez exposer des outils avec des contrats fiables, précis et testés sous charge.

Commencez concrètement :

1. choisissez un workflow principalement en lecture ;
2. définissez ou affinez ses schémas d'outils ;
3. testez chaque endpoint avec des entrées valides, invalides et limites ;
4. simulez les réponses pour observer l'orchestration sans toucher à la production ;
5. activez ensuite les outils à effets de bord de manière progressive.

Soumettez chaque endpoint au client API et au serveur de maquette d'Apidog jusqu'à ce que son contrat tienne sous les appels en rafale et les mauvaises entrées. Quand le modèle commencera à écrire du code contre vos outils, vous voudrez qu'il s'appuie sur une surface que vous avez déjà éprouvée.