Après OpenAI DevDay 2026, comment change le développement d'agents ?

Le « après DevDay » du titre pousse à écrire des prédictions de keynote. Le changement côté agents a déjà eu lieu : l'appel d'outil est passé de « le modèle dit une fois par tour » à « le modèle écrit un morceau de code d'orchestration » ; MCP est devenu un type d'outil de premier rang de Responses API, plus un plugin d'éditeur. Ce que la conférence figera plutôt : comment écrire ces contrats, qui approuve, comment valider le résultat.

Ce que DevDay 2026 permet déjà de figer

La page officielle indique : 2026-09-29, Fort Mason à San Francisco, keynote à 10:00 heure du Pacifique, ouverture par Sam Altman. Les inscriptions sur place sont closes ; la keynote sera diffusée. OpenAI n'accroche aucun nom de produit sur la page. GPT-6, Astra, la prochaine génération de Codex restent du bruit de couloir — pas un item de calendrier.

Changements de plateforme déjà utilisables comme faits avant la conférence :

• 2026-07-09 : GPT-5.6 (Sol / Terra / Luna) en GA. L'alias phare gpt-5.6 pointe vers gpt-5.6-sol.
• Responses API apporte en même temps Programmatic Tool Calling, le multi-agent beta et le persisted reasoning d'un tour à l'autre.
• MCP distant et Connectors partagent le type d'outil mcp ; facturation selon la définition importée et les tokens réellement consommés, pas de surcoût à l'appel.
• Agents SDK continue de gérer boucle, handoff, session et tracing ; une boucle maison reste du côté Responses API.

Deux chemins : Responses API et Agents SDK

Choisissez d'abord qui tourne la boucle, ensuite on parle JSON d'outil. La doc officielle tranche net : boucle à vous — Responses API ; boucle déléguée au SDK — Agents SDK.

Ne maintenez pas deux définitions d'outils. Les parameters / output_schema d'une function et le schema d'entrée MCP sont le même contrat JSON. Le SDK n'est que la coque qui tourne la boucle.

Tool Calling : direct et programmatic

Jusqu'à mi-2026, la forme par défaut était : le modèle jette un function_call, vous l'exécutez, vous renvoyez le résultat, le tour suivant décide. Quatre appels d'outil, c'était quatre tours. GPT-5.6 a fait du second chemin une capacité de premier rang de Responses API.

1. Un tour, un appel : toujours le défaut

direct reste le défaut. La doc officielle déconseille programmatic ici :

• Une seule recherche suffit.
• Les résultats intermédiaires sont petits ; une couche programme n'apporte rien.
• Chaque résultat change le jugement suivant (recherche adaptative, évaluation sémantique).
• Écritures, virements, suppressions, actions à faire approuver.
• La réponse finale doit garder les citations ou l'artefact d'origine.

En une phrase : le jugement au modèle, l'exécution à vous, la frontière d'approbation visible.

2. Le modèle écrit du JS : Programmatic Tool Calling

Programmatic Tool Calling (PTC) fait écrire au modèle un morceau de JavaScript, exécuté dans un V8 isolé tout neuf. Ce programme peut await, boucler, brancher, appeler en parallèle les outils autorisés, puis rendre un résultat condensé via text(...) ou image(...). À l'exécution : pas de Node, pas d'install de paquets, pas de réseau direct, pas de système de fichiers général. La seule sortie du bac à sable, ce sont les outils ouverts dans la requête.

L'activer, c'est deux gestes en même temps : ajouter {"type": "programmatic_tool_calling"} à la liste d'outils ; poser allowed_callers sur les outils que le programme a le droit d'appeler.

Types actuellement appelables depuis un program : function, custom, mcp, apply_patch, shell local / hosted, code_interpreter. Tool Search reste un outil de premier niveau : un program déjà en cours ne découvre pas tout seul les outils defer_loading: true — le modèle doit d'abord les charger, le program du tour suivant pourra les utiliser.

La réponse porte trois types d'items ; ne les fusionnez pas en un objet :

• program : le JS généré, call_id, fingerprint pour la reprise
• function_call émis par le programme : son propre call_id, caller.caller_id pointe vers ce program
• program_output : résultat final du programme, status completed ou incomplete

La doc le rappelle : program_output et le dernier message assistant sont deux sorties. Le programme peut déjà avoir le bon enregistrement, alors que le message final oublie un champ requis ou une citation. Testez les deux côtés.

MCP n'est plus « un second protocole à brancher »

Une fois MCP dans Responses API, MCP distant et Connectors sont tous les deux type: "mcp". La seule différence : vous passez server_url ou connector_id. Quand le modèle décide d'appeler, l'API envoie la requête au distant, la sortie porte un mcp_call. Par défaut, une approbation d'abord, sous forme de mcp_approval_request ; en faible latence, vous pouvez mettre require_approval à never par outil.

Superposé à PTC, MCP peut aussi porter allowed_callers: ["programmatic"]. Un serveur MCP existant n'a pas à changer de protocole pour être piloté par le JS généré. La politique d'approbation reste valable : une écriture qui traverse une frontière de confiance, require_approval arrête le program ; si la frontière n'est pas claire, pas de programmatic.

Beaucoup d'outils, et l'import des définitions mange des tokens. D'où allowed_tools : n'importer que ceux dont vous avez besoin. La forme la plus fréquente après DevDay ne sera pas « jeter tout le serveur MCP dans le contexte », mais « liste courte + Tool Search au besoin ».

Le contrat est en JSON : parameters et output_schema

PTC remonte d'un cran l'importance du Schema. Le JS généré ne voit pas les conventions dans votre tête, seulement la description de l'outil et les types de champs. Officiellement : parameters décrit l'entrée ; si l'outil renvoie des données structurées attendues, output_schema décrit le JSON dans function_call_output.output. Écrivez les deux, sinon le programme ne lira pas les champs de retour de façon stable.

Côté agent, il y a donc trois couches JSON — ne les aplatissez pas en une :

1. Entrée d'outil : parameters / schema d'entrée MCP. Pour le modèle et pour le program.
2. Sortie d'outil : output_schema. Pour que le program filtre, joigne, déduplique.
3. Réponse finale : Structured Output / text.format. Pour un humain ou un système aval. C'est le second verrouillage.

Comment inverser la troisième couche depuis un échantillon, c'est dans le tutoriel Structured Output précédent. Ici on complète les deux premières : le contrat d'outil.

Un échantillon d'outil qui donne un Schema

Ci-dessous une forme courante pour un rapprochement de stock — un motif adapté au PTC. Les chiffres en number, la rupture en champ calculé ; le modèle ne doit pas raconter « il manque à peu près 3 pièces ».

{
  "sku": "SKU-1024",
  "available_units": 12,
  "requested_units": 15,
  "shortage_units": 3,
  "source": {
    "inventory": "get_inventory",
    "demand": "get_demand"
  }
}

Structure de définition d'outil correspondante (esquisse, pas une requête d'auth complète) :

{
  "model": "gpt-5.6",
  "tools": [
    {
      "type": "function",
      "name": "get_inventory",
      "description": "按 SKU 返回库存。返回 sku 与 available_units。",
      "parameters": {
        "type": "object",
        "properties": {
          "sku": { "type": "string" }
        },
        "required": ["sku"],
        "additionalProperties": false
      },
      "output_schema": {
        "type": "object",
        "properties": {
          "sku": { "type": "string" },
          "available_units": { "type": "number" }
        },
        "required": ["sku", "available_units"],
        "additionalProperties": false
      },
      "allowed_callers": ["programmatic"]
    },
    {
      "type": "programmatic_tool_calling"
    }
  ]
}

Selon les règles d'inférence actuelles du site, cet échantillon métier donne :

Échantillon prêt : générez les enveloppes dans Function Calling ou Structured Output, puis relisez à la main required et additionalProperties. Les outils MCP passent par MCP Tool — ne recopiez pas deux fois les mêmes champs.

Trois choses qui bougeront vraiment après DevDay

Pas de noms de produits à deviner, seulement la couche contrat. Ce que la conférence amplifiera plutôt qu'elle ne l'inversera :

1. L'orchestration quitte le prompt pour le runtime. Boucle, filtre, join ne reposent plus sur des phrases vides du type « utilisez les outils efficacement ». PTC écrit le flux de contrôle en JS ; ce que vous écrivez, ce sont allowed_callers, les conditions d'arrêt et une erreur structurée en cas d'échec.
2. MCP passe de plugin à outil de plateforme. Le serveur MCP de l'éditeur se branche directement sur Responses API. Le prix : approbation, journaux et allowed_tools se conçoivent dans le produit — le modèle ne resserrera pas ça tout seul.
3. Le Schema s'étend de « réponse finale » à « entrée / sortie d'outil ». Valider seulement le JSON de l'assistant ne suffit plus. Si le program lit mal un type de champ, toute l'agrégation est fausse. Entrée, sortie, réponse finale : un Schema chacun, issus du même échantillon.

Le multi-agent beta et Codex ultra / sous-agents sont une autre ligne : déléguer un raisonnement indépendant à un sous-agent. PTC, c'est « orchestrer des outils avec du code » ; le multi-agent, c'est « orchestrer des modèles avec un modèle ». Si la tâche n'est pas assez large, n'ouvrez ni l'un ni l'autre.

Recetter dans la Boîte à outils JSON

1. Collez un échantillon d'entrée / sortie d'outil dans le formatage JSON, pour confirmer que ça parse.
2. Générez la définition avec Function Calling ou MCP Tool ; la réponse finale via Structured Output.
3. Passez un second vrai résultat d'outil dans la validation Schema. Le premier échantillon est toujours trop optimiste.
4. Si program_output et le message final ne s'alignent pas : Comparaison JSON pour voir si un champ a disparu ou si un type a dérivé.
5. Validation front : Zod ; doc d'API si besoin : OpenAPI 3.1.

Tout se traite dans le navigateur, rien n'est envoyé au serveur.

FAQ

Quand a lieu OpenAI DevDay 2026 ?

Officiellement le 2026-09-29, Fort Mason à San Francisco, keynote à 10:00 heure du Pacifique. Ce texte est daté du 2026-09-02 ; les noms de modèles non publiés ne sont pas des faits.

Quelle différence entre Programmatic Tool Calling et le Function Calling habituel ?

direct : le modèle appelle une fois par tour. programmatic : le modèle écrit du JS, orchestre les outils autorisés dans un V8 isolé, puis renvoie un résultat condensé. Écritures et approbations restent, par défaut, en direct.

Un outil MCP peut-il être appelé par Programmatic Tool Calling ?

Oui. Posez allowed_callers: ["programmatic"] sur MCP. require_approval met toujours le programme en pause.

Responses API ou Agents SDK ?

Boucle à vous : Responses API. Loop / handoff / session prêts : Agents SDK. Un seul contrat JSON d'outil.

output_schema et Structured Output, c'est la même chose ?

Non. output_schema contraint le retour d'un seul outil ; Structured Output contraint la réponse finale. Les deux couches ont besoin d'un Schema.

En résumé

DevDay 2026 mettra le récit sur le devant ; le changement de structure côté agents a déjà eu lieu. La boucle peut aller au SDK ou rester à vous, l'appel d'outil se choisit d'abord en direct ou programmatic, MCP se traite comme un outil ordinaire avec une politique d'approbation. Le cœur, ce sont trois Schema : entrée, sortie, réponse finale. Ils naissent du même échantillon ; validation, Zod et OpenAPI suivent.

Outils liés