JSON strict ou texte libre : quelle sortie d'IA pour une intégration fiable ?
Une intégration fiable ne dépend pas seulement de la qualité du modèle. Elle dépend du contrat de sortie, de la validation syntaxique et du contrôle métier appliqué avant toute action.
Réponse en bref
Choisissez le texte libre lorsque la réponse est destinée à être lue par une personne et qu'aucun système ne doit l'interpréter automatiquement. Utilisez JSON Schema pour extraire, classer ou transmettre des données avec une structure vérifiable. Utilisez un appel d'outil lorsque la sortie doit déclencher une action autorisée. Dans les trois cas, validez encore les valeurs, les droits et les effets de bord : une sortie conforme à un schéma n'est pas forcément vraie, sûre ou pertinente.
Les fournisseurs ne promettent pas exactement la même chose. OpenAI et Azure distinguent le JSON mode, qui produit du JSON valide, des Structured Outputs qui suivent un sous-ensemble de JSON Schema avec un mode strict. Google documente également un sous-ensemble de JSON Schema et recommande une validation métier supplémentaire. Anthropic décrit les appels d'outils avec un input_schema, et son mode strict garantit l'adéquation de l'appel au schéma fourni (OpenAI Structured Outputs, Microsoft Azure Structured Outputs, Google Gemini Structured Outputs, Anthropic Tool Use).
Schéma Nexxom : le format est choisi après la tâche, puis la sortie passe par une validation syntaxique et métier. Il ne représente pas un taux de réussite fournisseur.
Le mauvais réflexe : demander « réponds en JSON »
Demander du JSON dans le prompt ne crée pas un contrat d'interface. Le modèle peut produire un JSON syntaxiquement valide mais oublier une propriété, choisir une mauvaise valeur d'énumération, mélanger une date et un texte, ou inventer un champ que le système ne sait pas traiter. Même un mode structuré ne vérifie pas la vérité d'une adresse, la conformité d'un dossier ou le droit d'un utilisateur.
Le JSON RFC 8259 définit la syntaxe d'échange, tandis que JSON Schema décrit des contraintes d'instance. Ces deux couches sont différentes. Un parseur confirme que le document est lisible. Un validateur confirme que sa structure respecte le schéma. Le code métier doit encore vérifier les règles propres à l'entreprise.
Un contrat robuste sépare donc trois décisions :
- Forme : l'objet peut-il être analysé sans ambiguïté ?
- Valeur : les données sont-elles plausibles, complètes et cohérentes avec le contexte ?
- Action : l'application est-elle autorisée à utiliser le résultat, et avec quelles limites ?
Matrice Plotly statique produite par Nexxom. Les valeurs de 1 à 3 sont une heuristique éditoriale pour lire les compromis, pas une mesure de qualité de modèle.
Texte libre : quand la lisibilité prime
Le texte libre convient à une réponse qui sera lue, relue ou reformulée par une personne : synthèse de réunion, explication d'une décision, réponse à une question ouverte ou brouillon à valider. Il laisse au modèle une grande liberté de ton, d'ordre et de nuance.
Cette liberté devient un problème si une expression régulière ou un script tente ensuite d'extraire des champs. Les formulations, unités, séparateurs et titres peuvent changer. Si une intégration dépend de ces détails, vous avez déjà un contrat implicite sans tests de compatibilité.
| Situation | Texte libre adapté ? | Contrôle à ajouter |
|---|---|---|
| Réponse lue par un conseiller | Oui | Relecture ou échantillonnage qualité |
| Résumé affiché dans une interface | Oui, si aucune action automatique ne suit | Limites de longueur, présence des sources, filtre de contenu |
| Donnée envoyée vers un ERP | Non par défaut | JSON Schema, validation métier et journal d'erreur |
| Décision qui déclenche un paiement | Non | Appel d'outil autorisé, seuils et approbation humaine |
Le texte libre peut néanmoins contenir des marqueurs lisibles. Ne les présentez pas comme une garantie de structure. Ils facilitent la récupération, mais la validation et le rejet doivent rester explicites.
JSON Schema : un contrat de données
JSON Schema permet de décrire des objets, tableaux, types, champs requis et énumérations. La spécification 2020-12 est publiée par le projet JSON Schema (spécification actuelle). La validation porte sur la structure et les contraintes déclarées, pas sur la véracité du contenu (vocabulaire de validation).
Les Structured Outputs d'OpenAI et d'Azure ajoutent un contrôle fournisseur pour une partie de ce contrat. Azure précise que le sous-ensemble disponible impose notamment des propriétés comme additionalProperties: false et des champs requis dans les objets. Google documente aussi un sous-ensemble, des limites de profondeur et la nécessité de gérer les sorties conformes au schéma mais incorrectes sur le plan sémantique (limites Azure, bonnes pratiques Gemini).
| Contrôle | Ce que JSON Schema peut exprimer | Ce qu'il ne prouve pas |
|---|---|---|
| Type | chaîne, nombre, entier, booléen, objet, tableau | Que la valeur est exacte dans le monde réel |
| Enumération | une liste de valeurs autorisées | Que le modèle a choisi la bonne valeur |
| Champs requis | présence des clés nécessaires | Que la clé contient une donnée complète |
| Structure imbriquée | relations entre objets et tableaux | Que la relation métier est logique |
| Validation | document valide ou rejeté | Autorisation d'exécuter une action |
Un schéma doit rester versionné comme une API. Ajoutez un identifiant de version, testez les champs ajoutés ou supprimés et conservez un exemple valide et un exemple rejeté. Une équipe qui change le schéma sans changer le contrat aval transforme une amélioration de format en incident d'intégration.
Appel d'outil : quand la sortie devient une action
Un appel d'outil est approprié lorsqu'un modèle doit demander à l'application d'exécuter une fonction : rechercher une commande, créer un ticket, réserver un créneau ou calculer un montant. Anthropic décrit un input_schema JSON pour les paramètres de l'outil et recommande de gérer le cycle tool_use puis tool_result dans l'application (vue d'ensemble Anthropic). OpenAI documente la même séparation entre la définition d'un outil et l'exécution côté application (guide Function Calling OpenAI).
Le schéma ne doit jamais être la seule barrière. L'application doit vérifier l'identité de l'appelant, le périmètre de la ressource, le montant, l'idempotence, la date d'expiration et les droits. Un outil de remboursement peut recevoir un montant conforme au type number et rester interdit par la politique métier.
| Étape | Question | Décision de sécurité |
|---|---|---|
| Proposition | Le modèle a-t-il proposé un outil prévu ? | Refuser tout nom absent de la liste autorisée |
| Paramètres | Les champs respectent-ils le schéma et les limites ? | Valider type, plage, enum et taille |
| Autorisation | L'utilisateur et le service ont-ils le droit ? | Vérifier l'identité et le contexte dans le code |
| Exécution | L'action peut-elle être répétée sans dommage ? | Utiliser une clé d'idempotence ou une approbation |
| Résultat | Le retour peut-il être réinjecté sans contrôle ? | Marquer la source, journaliser et filtrer |
Quelle approche choisir ?
La bonne sortie se choisit à partir de la conséquence d'une erreur. Plus la sortie est proche d'une action irréversible, plus le contrat doit être explicite et la validation indépendante du modèle.
| Conséquence d'une erreur | Format recommandé | Validation minimale |
|---|---|---|
| Un lecteur corrige manuellement | Texte libre | Contrôle de ton, sources et informations sensibles |
| Une fiche est créée dans un système | JSON Schema | Validation de schéma, champs métier, doublons et version |
| Une action externe est déclenchée | Appel d'outil | Schéma, identité, droits, seuils, idempotence et journal |
| Le cas est ambigu ou critique | Texte ou JSON avec revue | File d'attente humaine et décision explicable |
Le choix peut être hybride. Un agent peut produire un objet JSON pour l'interface, puis rédiger un texte séparé pour l'utilisateur. Un appel d'outil peut retourner un objet structuré qui sera résumé par un modèle, sans autoriser ce résumé à modifier la source. Séparez la donnée de référence, la formulation et l'action.
Procédure de mise en production
- Définir le consommateur : humain, interface, base de données ou outil.
- Décrire le contrat : types, champs requis, enum, unités, version et taille maximale.
- Choisir la capacité fournisseur : JSON Schema, tool use ou texte, en lisant la documentation du modèle et de l'endpoint exacts.
- Valider hors modèle : parseur, validateur JSON Schema, règles métier et contrôle des droits.
- Prévoir les erreurs : refus, reprise limitée, retour au texte ou revue humaine.
- Observer : taux de parse, taux de validation métier, champs manquants, rejets et actions annulées.
- Versionner : conserver le schéma, les exemples, les changements et la compatibilité aval.
La validation doit être testée avec des cas ordinaires, des valeurs limites, des champs absents, des langues différentes, des données malveillantes et des réponses conformes mais fausses. Le NIST AI RMF aide à rattacher ces tests à la mesure, à la gestion des risques et à la responsabilité, sans imposer un fournisseur ou un format.
Limites et pièges
Un schéma trop large ne protège rien. Un schéma trop strict rejette des cas légitimes et pousse les équipes à le désactiver. Commencez par les invariants réellement consommés par le système. Évitez de transformer une explication longue en champ string opaque si un lecteur ou un auditeur doit en vérifier la provenance.
Les sous-ensembles de JSON Schema ne sont pas identiques entre fournisseurs. Une propriété supportée dans un service peut être refusée par un autre, et la disponibilité peut dépendre du modèle ou de l'API. Vérifiez les versions et testez une migration. Ne comparez pas seulement la promesse « structured output » : mesurez le coût de validation, le comportement de reprise, les erreurs sémantiques et les droits d'exécution.
Conclusion
Le texte libre optimise la lisibilité, JSON Schema formalise un contrat de données, et l'appel d'outil encadre une demande d'action. Aucun de ces formats ne remplace une validation métier indépendante. La décision fiable consiste à choisir le contrat selon la conséquence d'une erreur, puis à tester la syntaxe, les valeurs, les droits et la reprise.
Pour aller plus loin, conservez vos schémas comme du code, reliez-les à vos tests d'intégration et documentez les cas où une personne reprend la main. Cette méthode rend les systèmes IA plus observables sans faire croire qu'un JSON bien formé est automatiquement une décision correcte.
Sources primaires vérifiées le 21 août 2026
- OpenAI, Structured Outputs
- OpenAI, Function Calling
- Microsoft Azure, Structured Outputs
- Google Gemini API, Structured Outputs
- Anthropic, Tool Use
- JSON Schema, specification
- JSON Schema, validation vocabulary
- IETF, JSON RFC 8259
- NIST, AI Risk Management Framework
