Tant que le modèle répond en prose, un humain doit le lire. Dès que sa sortie est structurée — JSON, tableau fixe, champs étiquetés — le code peut prendre le relais : la valider, la stocker, router dessus. La sortie structurée est le pattern qui transforme « un chatbot » en composant logiciel, et il se trouve qu’il économise aussi des tokens.

L’analogie

Le formulaire contre la lettre libre. Une déclaration de sinistre écrite en lettre de trois pages doit être lue, interprétée, et souvent renvoyée pour détails manquants. Le formulaire de sinistre — numéro de police, date, montant, case à cocher — est traité en minutes, en partie automatiquement. Même information ; c’est la structure qui fait le travail.

Le principe

PROSE :  « Analyse cet avis et dis-moi ce que ressent le client »
         → 150 mots de nuances qu'un humain doit lire.

STRUCTURÉ :
         « Analyse cet avis. Réponds UNIQUEMENT avec ce JSON :
          { "sentiment": "positif" | "neutre" | "négatif",
            "sujets": [string, max 3],
            "urgent": boolean,
            "citation": string  // la phrase qui le justifie le mieux
          } »
         → 40 tokens, parsable, actionnable.

Ce qui le rend robuste :

• Donnez le schéma exact, pas sa description — la forme est la consigne (et un exemple rempli en few-shot verrouille le tout).
• Fermez les énumérations. "positif" | "neutre" | "négatif" bat « décris le sentiment » — on ne fait pas de switch sur de la poésie.
• Dites « UNIQUEMENT ce JSON » — sinon vous recevez un aimable paragraphe autour, qui casse votre parseur.
• Validez programmatiquement, et en cas d’échec, une reprise avec le message d’erreur. Ce contrôle est la porte naturelle d’un chaînage de prompts. Beaucoup d’API et de harness savent aussi imposer un schéma JSON à la génération — utilisez-le quand c’est disponible.

Un exemple concret

Un triage de tickets branché sur un vrai système :

sortie LLM → {"sentiment":"négatif","sujets":["facturation","remboursement"],
              "urgent":true,"citation":"troisième fois qu'on me débite deux fois"}
code       → urgent && facturation → file prioritaire, finance notifiée
           → stocké en base, les tableaux de bord se mettent à jour

Aucun humain n’a lu le ticket ; la structure l’a porté de bout en bout. C’est aussi comme ça que fonctionnent les appels d’outils sous le capot — les agents, c’est de la sortie structurée jusqu’à la moelle.

💶 Le gain en tokens

• Les réponses structurées sont radicalement plus courtes : 40 tokens de JSON contre 150+ mots de prose — et ce sont des tokens de sortie que vous rognez, les 3 à 5× plus chers. À 10 000 appels par mois, ce seul changement coupe souvent la facture de sortie des deux tiers.
• L’échec de parsing est le chemin cher : chaque reprise « désolé, réponds en JSON valide » re-facture tout le contexte. Un schéma serré + une porte de validation gardent le taux de reprise proche de zéro.
• Le schéma est stable → il vit dans le préfixe cachable (prompt caching) avec vos consignes et vos exemples.

Le piège classique

Croire que la forme garantit le fond. Un JSON valide avec les bonnes clés peut contenir un sentiment faux ou une citation inventée — valide au schéma n’est pas correct. Validez aussi les valeurs (la citation figure-t-elle vraiment dans l’avis ?), et gardez un petit jeu d’éval qui note le contenu, pas seulement le taux de parsing.