OpenAI GPT 2026 : Function Calling, Structured Outputs et JSON Schema

Vérifié le 18 août 2026. Champs et comportements suivent le guide Function Calling OpenAI et le guide Structured Outputs. Pas de latences, tarifs ou taux de succès inventés. Là où la doc publique ne fige rien, on indique « à confirmer en rejouant le trafic réel ».

Si vous basculez un backend compatible OpenAI vers un autre modèle, la sortie structurée et la boucle d’outils se valident séparément : changer le Base URL ne suffit pas. Voir la checklist de migration OpenAI API vers Kimi K3.

En bref : trois changements en même temps

Beaucoup de dépôts en sont encore au modèle mental 2024 : « renvoie du JSON » dans le prompt, puis une regex sur les blocs de code. En production 2026, ça casse le parseur via violations de schéma, champs manquants et hallucinations d’enum.

Ce qu’il faut changer, ce sont trois couches — pas un nom de modèle plus gros :

Contrat de livraison

L’objet final pour l’utilisateur ou le service aval : Structured Outputs (text.format côté Responses, response_format.json_schema côté Chat Completions).

Contrat d’exécution

Quand le modèle appelle vos outils, les arguments doivent coller au JSON Schema de l’outil. C’est Function Calling, même constrained decoding que Structured Outputs.

Contrat de compatibilité

L’ancien JSON Mode (json_object) garantit seulement « ça ressemble à du JSON », pas les champs, types ni enums contre le schéma. La doc le positionne comme prédécesseur de Structured Outputs. Ne plus en faire le chemin principal d’un projet neuf.

Autre changement produit souvent oublié : le nouveau code doit passer par l’API Responses. Chat Completions reste utilisable, mais la stratégie par défaut de strict diffère — Responses tente de normaliser le schéma en mode strict et ne recule qu’en cas d’échec ; Chat Completions reste non strict / best effort par défaut.

Modèle et voie API principale : gpt-5.6 + Responses

Structured Outputs existe depuis la génération GPT-4o. Pour les nouveaux projets, la reco officielle est gpt-5.6. Les snapshots plus anciens (gpt-4-turbo et avant) restent documentés pour JSON Mode, pas pour un json_schema strict complet.

Deux portes d’entrée à ne pas confondre

Côté SDK, prenez l’habitude de ne pas écrire à la main un schéma qui oublie additionalProperties : générez-le depuis les types avec les helpers officiels. Python : client.responses.parse(..., text_format=YourModel) ; JavaScript : zodTextFormat. Avec un schéma manuscrit et strict: true, une contrainte non respectée fait refuser la requête — ce n’est pas « le modèle sort n’importe quoi et vous retryez ».

Face à la piste Gemini, « compatible SDK OpenAI » ne veut pas dire le même comportement de schéma. Pour les upgrades Google : 10 nouvelles fonctionnalités de Gemini 3.5 Pro. En copiant le même JSON Schema d’un fournisseur à l’autre, la règle additionalProperties sur les objets imbriqués est souvent le premier point de rupture.

JSON Mode, Structured Outputs, Function Calling

Accident de prod le plus fréquent : les logs montrent du JSON, donc on croit Structured Outputs actif. Sémantique officielle :

Quand ne pas utiliser Function Calling

Si le modèle n’a pas à toucher votre système (pas de stock, pas de tickets, pas de scripts) et doit seulement découper la réponse en cartes, étapes ou scores : Structured Outputs. Dès que la sortie est « exécute cet effet de bord », passez par tools — ne déguisez pas des arguments de fonction en schéma de réponse finale.

Un refus n’est plus du « mauvais JSON »

En refus de sécurité, le modèle n’est pas forcé dans votre schéma. Responses / Chat Completions exposent un champ refusal distinct. La couche de parse doit le traiter en citoyen de première classe : d’abord refusal, ensuite output_parsed — un objet vide n’est pas un succès.

Règles dures du JSON Schema strict

Une fois strict activé, OpenAI n’accepte qu’un sous-ensemble de JSON Schema, pas n’importe quel document Draft 2020-12. Trois erreurs de requête les plus fréquentes :

1. Chaque champ de properties doit figurer dans required.
2. Chaque object (y compris imbriqué) doit avoir additionalProperties: false.
3. L’objet racine ne peut pas être un anyOf ; l’optionnel s’exprime par « required + null autorisé », par ex. ["string", "null"].

Donc : retirer le champ de required pour faire semblant qu’il est optionnel — sous strict, c’est un 400 immédiat. La bonne forme : le champ reste required, le type est une union nullable, l’appli traite null comme « non fourni ».

Objet de prod courant « extraire un ticket » — l’objet imbriqué a aussi additionalProperties :

from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()

class Ticket(BaseModel):
    title: str
    priority: str
    assignee: str | None
    tags: list[str]

response = client.responses.parse(
    model="gpt-5.6",
    input=[
        {"role": "system", "content": "Extraire les champs du ticket à partir de la description utilisateur."},
        {"role": "user", "content": "Page de connexion 500, assigner à Noah, priorité haute, tags auth et api."},
    ],
    text_format=Ticket,
)
ticket = response.output_parsed
print(ticket.title, ticket.priority, ticket.assignee)

Si la requête est refusée, lisez d’abord quelle contrainte manque dans le message d’erreur — ne descendez pas le modèle en premier. Les schémas du Playground arrivent déjà en strict ; les copier tels quels dans le dépôt est souvent plus rapide que de recycler d’anciens prompts json_object.

En multi-fournisseurs, revérifiez : le même schéma « chaque object à false » peut devenir HTTP 400 sur certaines passerelles compatibles ou d’autres modèles. Faites une transformation par fournisseur, pas trois schémas métier.

Function Calling 2026 : strict, tool_search, custom tools

Function Calling et tool calling sont officiellement la même chose : un JSON Schema décrit les fonctions appelables, l’exécuteur applicatif joue les effets de bord. Quelques points 2026 changent directement votre boucle d’agent.

Ne pas deviner la valeur par défaut de strict

• Mettez toujours strict: true explicitement.
• Responses : si vous omettez strict, le serveur tente de normaliser le schéma ; en échec, repli non strict, l’outil dans la réponse affiche strict: false.
• Chat Completions : omission = non strict par défaut.
• Sur un modèle fine-tuné qui appelle plusieurs fonctions dans un tour, la doc indique que strict peut être désactivé pour ce tour.

Les définitions d’outils entrent dans le contexte et sont facturées en tokens d’entrée. Descriptions trop longues et 40 outils d’un coup gonflent la facture et dégradent le choix d’outil. Beaucoup d’outils : chargez les rares en différé avec tool_search — gpt-5.4 et plus seulement. La boucle peut d’abord voir tool_search_call / tool_search_output, puis le vrai function_call.

Custom tools : n’enfoncez pas un DSL dans un objet JSON

Les function tools collent aux paramètres structurés ; les custom tools au texte libre, éventuellement contraint par une grammaire hors contexte (CFG). Fragments SQL, langages de requête internes, formats dont les terminaux s’excluent : une CFG est plus stable qu’un champ string + un roman de prompt. Si la CFG signale unexpected tokens, cherchez d’abord des terminaux qui se chevauchent, pas la faute du modèle.

tools = [{
    "type": "function",
    "name": "get_order",
    "description": "Consulter le statut d'une commande par numéro. N'appeler que si l'utilisateur donne un numéro de commande explicite.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {"type": "string"},
            "locale": {"type": ["string", "null"]},
        },
        "required": ["order_id", "locale"],
        "additionalProperties": False,
    },
}]

La boucle d’exécution n’a pas changé : finish_reason / type d’item = appel d’outil → fonction locale → renvoyer le résultat en rôle tool → nouvelle requête. Ce qui change : plus besoin de miser sur json.loads. Il faut toujours persister le message assistant complet (y compris tool_calls), sinon les identifiants d’appel disparaissent au second tour.

Checklist de migration des anciens projets

Séparez « ça tourne » et « c’est livrable ». Gardez un interrupteur vers l’ancien backend, rejouez d’abord le trafic réel dans un environnement isolé.

1. Modèle : figer la nouvelle chaîne sur gpt-5.6 (ou le palier équivalent déjà ouvert sur le compte) ; la passerelle ne doit pas mapper en silence vers un vieux snapshot.
2. Sortie : remplacer json_object par json_schema + strict: true, ou text.format côté Responses.
3. Outils : chaque function avec required complet et additionalProperties: false imbriqué ; champs optionnels en union nullable.
4. Parse : brancher parse() et la branche refusal ; en streaming, vérifier la cohérence JSON incrémental / objet parsed final.
5. Surface d’outils : au-delà d’une dizaine, évaluer tool_search ; d’abord raccourcir les descriptions, puis le chargement tardif.
6. Contrôle : mêmes tâches figées — taux de retry, champs manquants, reprise manuelle entre ancien JSON Mode et nouveau chemin schéma.

Le critère n’est pas un 200, c’est : parseur sans filet regex, types d’arguments d’outils stables, refus observables, interrupteur de rollback déjà exercé. SDK longtemps ouvert, scripts de replay et sessions navigateur : un portable qui s’endort casse l’expérience — c’est le rôle du Mac mini cloud plus bas.

FAQ