Contrôler les sorties IA : conformité au schéma JSON, decoding contraint et sélection de format

Le contrôle des sorties opère à trois niveaux distincts — par prompt, par schéma et decoding contraint — chacun offrant des garanties de format progressivement plus fortes, au prix de compromis progressivement plus élevés sur la qualité du raisonnement.

Le formatage par prompt instruit le modèle en langage naturel ("Return JSON with fields: name, email, score"). Cela fonctionne dans 80–95 % des cas mais échoue silencieusement sur les cas limites, sans garantie de type, nécessitant une gestion d'erreurs pour les 5–20 % de réponses malformées. Les approches par schéma (function calling / tool use) définissent formellement la structure de sortie à 95–99 % de conformité — mais le schéma reste une suggestion forte, pas une contrainte absolue. Le decoding contraint natif utilise des automates à états finis pour masquer les tokens invalides lors de la génération, produisant des sorties valides à 100 % avec certitude mathématique.

L'approche en deux étapes — laisser Claude Opus 4.7 (Anthropic) ou GPT-4o (OpenAI) raisonner librement en étape 1, puis passer la sortie à un petit modèle spécialisé (Osmosis-Structure-0.6B, entraîné sur 500 000 transformations synthétiques non structurées → structurées) en étape 2 — atteint les garanties de format sans la pénalité de qualité du decoding contraint.

En un mot : adaptez le niveau de contrainte de sortie à la tâche — utilisez le decoding contraint uniquement quand la correction de format importe plus que la profondeur de raisonnement.

Des instructions de schéma de sortie explicites — placées au début du prompt système pour Claude Opus 4.7 et immédiatement avant le contenu utilisateur pour GPT-4o — produisent des taux de conformité de 85–95 % sans la pénalité de qualité du decoding contraint natif.

Claude Opus 4.7 (Anthropic) répond mieux aux instructions de format placées en début de prompt système avec des balises XML. GPT-4o (OpenAI) performe mieux avec le schéma placé juste avant le contenu utilisateur sous forme de règles numérotées. Gemini 3.1 Pro (Google DeepMind) produit les sorties structurées les plus fiables quand le schéma est rappelé en début et en fin de prompt.

Mauvais prompt — non structuré, sans spécification de format :

Bon prompt — Claude Opus 4.7

Le prompt structuré XML ancre le contrat de format de sortie tout en préservant le raisonnement libre dans le bloc `<task>`. Aucun decoding contraint requis — Claude Opus 4.7 se conforme dans plus de 93 % des appels en production avec cette structure.

Bon prompt — GPT-4o

Chaque grand LLM a des préférences structurelles distinctes pour la conformité au format de sortie :

Temperature (T), Top-P, Top-K, max_tokens, frequency_penalty et presence_penalty sont six paramètres indépendants qui déterminent conjointement la longueur, l'aléatoire et la répétition des sorties — et doivent être définis de façon cohérente, sans contradiction.

Temperature (T) redimensionne la distribution softmax : à T = 0.0, le modèle sélectionne toujours le token de plus haute probabilité (déterministe) ; à T = 2.0, la distribution est quasi-plate et la sortie devient incohérente. Top-P (nucleus sampling) sélectionne parmi le plus petit ensemble de tokens dont la probabilité cumulée atteint P — à Top-P = 0.9, le modèle ne considère que les tokens couvrant les 90 % supérieurs de la masse de probabilité. Top-K restreint la génération aux K tokens de plus haute probabilité à chaque étape ; Top-K = 1 équivaut au décodage glouton.

Formule softmax avec temperature : P(token) = exp(logit / T) / sum(exp(logits / T)). Quand T tend vers 0, le token au logit le plus élevé tend vers la probabilité 1.0. Quand T tend vers l'infini, tous les tokens tendent vers une probabilité égale.

Règle critique : Ne définissez pas simultanément Temperature et Top-P à des valeurs élevées. Temperature redimensionne d'abord la distribution complète ; Top-P échantillonne ensuite depuis la masse de probabilité déjà redimensionnée. Combiner T = 1.5 et Top-P = 0.95 produit des sorties plus erratiques que chaque paramètre seul — les deux paramètres sont conçus comme des alternatives, pas à empiler.

`frequency_penalty` réduit la probabilité des tokens proportionnellement à leur nombre d'occurrences — les valeurs positives éliminent les formulations répétitives ; les valeurs négatives encouragent activement la répétition. `presence_penalty` applique une pénalité forfaitaire unique à tout token déjà apparu, indépendamment de la fréquence — il pousse le modèle à introduire nouveau vocabulaire et nouveaux sujets plutôt que répéter les existants.

Forcer JSON via le decoding contraint réduit la précision du modèle de 2,26 points de pourcentage sur les benchmarks de function calling — le parsing libre aligné sur le schéma de BAML a atteint 93,63 % de précision sur BFCL contre 91,37 % pour le decoding contraint strict d'OpenAI sur le même benchmark.

Le mécanisme : le decoding contraint applique un automate qui masque les tokens incompatibles avec la position actuelle dans le schéma. Un modèle qui veut produire `51.7` pour un champ float est contraint de produire `51` si le schéma spécifie un entier — résultat techniquement valide mais factuellement dégradé. Le prompting Chain-of-Thought (CoT) est incompatible avec le decoding contraint de la même façon : inclure un champ de raisonnement force le modèle à échapper les sauts de ligne, guillemets et caractères spéciaux dans une chaîne JSON — ce qui dégrade mesurably la qualité de raisonnement.

La solution de niveau production pour les systèmes nécessitant profondeur de raisonnement et garanties de format : (1) Étape 1 — Envoyer à GPT-4o ou Claude Opus 4.7 sans contraintes : "Analysez ceci, raisonnez étape par étape, expliquez votre logique." (2) Étape 2 — Passer la sortie de l'étape 1 à un petit modèle spécialisé (Osmosis-Structure-0.6B ou GPT-4o-mini avec `strict: true`) : "Extrayez les données clés de cette analyse et retournez-les dans ce schéma JSON exact."

Cette architecture préserve la qualité de raisonnement de l'étape 1 et atteint 100 % de conformité de format en étape 2, à une fraction du coût d'un modèle frontier complet en mode contraint.

Testé dans PromptQuorum — 30 prompts de contrôle des sorties répartis sur trois modèles : Claude Opus 4.7 a atteint 93 % de conformité JSON avec des instructions de format balisées XML sans decoding contraint. GPT-4o a atteint 89 % de conformité avec des règles de format numérotées. Gemini 3.1 Pro a atteint 91 % de conformité avec le schéma précisé en début et fin. Les trois modèles ont produit des raisonnements plus courts et moins complets quand `strict: true` était activé — cohérent avec la perte de 2,26 points observée sur le benchmark BFCL.

Les stop sequences — tokens qui arrêtent immédiatement la génération du modèle — sont le mécanisme de contrôle le plus déterministe : le modèle s'arrête dès que la chaîne spécifiée apparaît, quel que soit le contexte restant.

Les stop sequences sont passées comme un tableau de chaînes dans l'appel API (paramètre `stop` chez OpenAI, `stop_sequences` chez Anthropic). Usages courants en production :

Les contraintes négatives dans le corps du prompt — "Ne pas inclure d'explications", "Pas de markdown", "Ne pas ajouter de phrases d'introduction" — réduisent les patterns de sortie indésirables mais ne peuvent pas garantir la conformité comme le font les stop sequences. Utiliser les deux : stop sequences pour l'arrêt structurel, contraintes négatives pour la mise en forme du contenu.

JSON est le format de sortie dominant pour les pipelines LLM en production car il correspond directement aux objets API, tableaux et données typées — mais forcer JSON via le decoding contraint sacrifie 2–10 % de qualité de raisonnement, faisant du choix de format une décision architecturale significative.

TOON (Token-Optimised Output Notation) s'est imposé comme format d'entrée efficace pour les prompts structurés longs — il utilise la minimisation des espaces et des clés abrégées pour réduire la consommation de tokens d'entrée avant que le modèle génère la sortie en JSON. L'architecture de production recommandée 2026 : TOON pour l'entrée (efficacité des tokens) + JSON avec decoding contraint pour la sortie (format garanti) — appliqué uniquement après la fin du raisonnement libre en étape 1.

Les entreprises européennes construisant des pipelines LLM traitant des données personnelles doivent appliquer l'article 25 du RGPD (protection des données dès la conception) à la conception du schéma de sortie — les sorties exposant des champs de données personnelles dans des charges JSON nécessitent une base légale au titre de l'article 6 du RGPD. La CNIL a publié en janvier 2026 des orientations selon lesquelles les sorties de décision automatisée — y compris les sorties LLM structurées utilisées dans des workflows de scoring ou d'éligibilité — peuvent déclencher des droits à l'examen humain au titre de l'article 22 du RGPD.

Pour les équipes UE nécessitant une inférence on-premise avec contrôle des sorties structurées, Mistral AI (France) supporte le decoding contraint basé sur vLLM avec des paramètres JSON guidés — permettant une conformité garantie au schéma JSON entièrement dans l'infrastructure UE, satisfaisant les exigences de résidence des données du RGPD selon l'article 46. La CNIL recommande par ailleurs le recours aux modèles d'inférence locale pour le traitement de données professionnelles sensibles (financières, médicales, juridiques), afin d'éviter tout risque d'accès non autorisé lors des appels API externes. Mistral Large s'exécute on-premise avec support des sorties structurées.

Les entreprises chinoises utilisent Qwen 2.5 (Alibaba) et DeepSeek V3 (DeepSeek AI) pour les pipelines de production à sorties contrôlées. Les deux modèles supportent le mode JSON et sont déployables localement sur l'infrastructure enterprise chinoise selon les Mesures provisoires chinoises sur l'IA générative (2023). Les entreprises japonaises exécutant l'inférence locale via Ollama — LLaMA 3.1 7B à 8 Go de RAM, LLaMA 3.1 13B à 16 Go — bénéficient d'Outlines et XGrammar pour le decoding contraint sur les modèles auto-hébergés.