Comment structurer les sorties LLM avec Outlines ?

Résumer ce contenu avec :

Perplexity ChatGPT Claude Grok Mistral

Outlines sert à forcer un LLM à répondre dans un format précis, au lieu d’espérer qu’il respecte la consigne. Je vais vous montrer pourquoi c’est utile, comment ça marche avec des choix fermés, du JSON Pydantic et des payloads d’API propres.

Pourquoi Outlines aide vraiment ?

Outlines aide parce qu’il contraint la génération du modèle au moment où les tokens sont produits, au lieu de vérifier le résultat après coup. C’est ça le point clé. On ne demande pas juste au modèle d’être sage, on l’empêche techniquement de sortir du cadre.

Le problème classique avec les LLM, je le vois tout le temps dès qu’on passe en production. On demande un JSON propre, une catégorie précise, une structure avec trois clés, et le modèle répond presque bien. Presque. Il ajoute une phrase avant le JSON. Il oublie une clé. Il écrit “Negative” au lieu de “negatif”. Il met une virgule en trop. Ou il renvoie un format impossible à parser.

AI

Comment réduire la latence LLM et les coûts en production ?

juillet 31, 2026

Dans une démo, ce n’est pas grave. Dans une automatisation, ça casse vite. Si vous enrichissez un CRM, traitez des tickets support, alimentez une API ou mettez à jour une base, le “presque bon” devient un vrai problème. Une API ne devine pas vos intentions. Un parseur JSON non plus.

Outlines est une bibliothèque open-source de génération structurée. Elle enveloppe le modèle et le tokenizer. Le tokenizer, c’est la brique qui découpe le texte en tokens, donc les petits morceaux que le modèle produit un par un. Outlines masque les tokens syntaxiquement illégaux pendant la génération.

Concrètement, on peut imposer des contraintes avec des choix fermés, des types Python, des modèles Pydantic ou des schémas JSON. Pydantic, pour faire simple, permet de définir une structure de données attendue avec des champs et des types. Par exemple un champ “sentiment” qui ne peut prendre que “positif”, “neutre” ou “negatif”.

AI

Comment fonctionnent les VLMs modernes en IA ?

juillet 31, 2026

L’idée derrière, c’est une machine à états finie. Le nom fait un peu académique, mais le principe est simple. À chaque étape, le modèle n’a accès qu’aux tokens compatibles avec la structure attendue. Si une accolade est nécessaire, il ne peut pas inventer une phrase. Si une valeur doit être dans une liste fermée, il ne peut pas écrire une variante créative.

Petite nuance importante. Outlines améliore fortement le respect du format, mais ça ne transforme pas une réponse fausse en réponse vraie. La structure peut être garantie, pas la vérité métier. J’ai eu le cas avec un client qui voulait classer automatiquement des tickets support. Il ne pouvait pas se permettre que le modèle réponde parfois “Negative”, parfois “negatif”, parfois “Le client semble mécontent”. Outlines règle ce problème de format. Il faut quand même travailler le prompt, les exemples et l’évaluation pour que la classification soit correcte.

Comment fermer les choix ?

On ferme les choix avec Outlines en définissant explicitement les valeurs autorisées, par exemple avec un type Literal Python.

AI

Quels algorithmes machine learning utiliser ?

juillet 31, 2026

Le cas le plus simple, et franchement l’un des plus utiles, c’est la classification à choix multiples. Prenez un ticket client. Vous voulez savoir si le sentiment est Positive, Negative ou Neutral. Rien d’autre.

Sans contrainte, un LLM peut répondre “Le client semble mécontent”, “Négatif”, “Negative sentiment”, “Plutôt négatif”, ou même une phrase complète. C’est humainement compréhensible, mais côté automatisation c’est pénible. Si derrière vous avez un workflow, un dashboard ou une règle métier, vous voulez une valeur exacte. Pas dix variantes à nettoyer.

pip install "outlines[transformers]"

from typing import Literal

import outlines
from transformers import AutoModelForCausalLM, AutoTokenizer

# Chargement d'un modèle Hugging Face Transformers
model_id = "microsoft/Phi-3-mini-4k-instruct"

tokenizer = AutoTokenizer.from_pretrained(model_id)
hf_model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map="auto"
)

# Outlines enveloppe le modèle Transformers
model = outlines.from_transformers(hf_model, tokenizer)

# Liste fermée des réponses possibles
Sentiment = Literal["Positive", "Negative", "Neutral"]

ticket = "J'ai commandé mon produit il y a 3 semaines et je ne l'ai toujours pas reçu. Le support ne répond pas."

prompt = f"""
Classe le sentiment de ce ticket client.

Ticket:
{ticket}

Réponds uniquement avec une de ces valeurs:
Positive, Negative, Neutral
"""

result = model(prompt, Sentiment)

print(result)
# Résultat attendu : Negative

Le point important, c’est que Literal vient bien du module typing de Python, mais Literal tout seul ne bloque rien. Ce n’est pas Python qui empêche le modèle de sortir autre chose. C’est Outlines qui lit cette définition et qui pilote la génération pour forcer une sortie dans cette liste précise.

AI

Quels frameworks Python pour agents IA locaux ?

juillet 31, 2026

Le modèle reste un LLM. Il “comprend” le ticket, il raisonne sur le sentiment, mais au moment de répondre, il n’a plus le droit d’inventer une formulation libre. Il doit choisir dans le menu.

Dans les projets d’automatisation, c’est souvent ce détail qui change tout. J’ai vu des équipes passer plus de temps à nettoyer des petites variations de réponses qu’à écrire le prompt initial. Avec ce genre de contrainte, on évite beaucoup de règles fragiles derrière. Et ça, c’est du temps gagné pour de vrai.

Comment générer du JSON fiable ?

On génère du JSON fiable avec Outlines en décrivant d’abord la structure attendue, par exemple avec un modèle Pydantic.

Pydantic est pratique parce qu’on pose le contrat côté Python. On dit clairement ce qu’on attend. Un champ name en texte, un champ description en texte, un champ age en nombre entier. Ce n’est pas juste une consigne vague dans un prompt, c’est une forme d’objet que le code connaît déjà.

from pydantic import BaseModel
import outlines

class Character(BaseModel):
    name: str
    description: str
    age: int

model = outlines.models.transformers("mistralai/Mistral-7B-Instruct-v0.2")

generator = outlines.generate.json(model, Character)

character = generator(
    "Create a character named Anya, with a short description and age 25."
)

print(character.model_dump_json(indent=2))

La sortie attendue ressemble à ça, et surtout elle respecte le modèle demandé.

{
  "name": "Anya",
  "description": "A calm and curious young woman.",
  "age": 25
}

La différence importante, c’est celle-ci. Demander à un LLM de répondre en JSON, c’est lui donner une instruction. Contraindre un LLM à générer du JSON, c’est limiter ce qu’il a le droit de produire pour que la sortie colle au contrat.

Dans le premier cas, le modèle peut ajouter une phrase avant, oublier une virgule, mettre l’âge entre guillemets, ou sortir un champ en trop. Dans le second cas, Outlines guide la génération pour rester dans une structure valide. Ça change tout quand derrière, vous avez du code qui fait un parsing JSON, c’est-à-dire qui transforme le texte en objet exploitable.

J’ai vu ça souvent chez des clients. Dans un prototype, un JSON cassé une fois sur vingt peut sembler acceptable. Dans un workflow automatisé qui tourne tous les jours, c’est juste une panne différée. Et après on ajoute des scripts de réparation, des regex, des retries, des conditions bizarres. Tout ce bruit vient souvent d’un problème simple : la sortie n’était pas vraiment contrainte.

Comment préparer un payload API ?

On prépare un payload API propre en faisant générer au LLM uniquement les champs attendus par l’endpoint, dans un JSON strictement valide.

Après Pydantic, le vrai sujet n’est plus juste d’avoir un joli JSON qui rassure dans une démo. C’est d’obtenir un objet exploitable. Un objet qu’on peut envoyer à une API REST, donc une API appelée via HTTP, ou utiliser pour mettre à jour une base de données sans bricoler derrière.

Dans un cas support, on peut vouloir des champs simples comme customer_id, sentiment, priority, summary, action_required. Les noms exacts dépendent toujours du système cible. Un CRM, un outil ticketing ou une base interne n’auront pas forcément les mêmes conventions. Mais le principe ne change pas : Le LLM ne doit produire que ce que le système suivant sait recevoir.

from typing import Literal
from pydantic import BaseModel, Field

class SupportTicketPayload(BaseModel):
    ticket_id: str = Field(description="Identifiant unique du ticket support")
    customer_id: str = Field(description="Identifiant du client")
    sentiment: Literal["Positive", "Negative", "Neutral"]
    priority: Literal["Low", "Medium", "High"]
    summary: str = Field(description="Résumé court du problème client")
    action_required: bool = Field(description="Indique si une action humaine est nécessaire")

Avec Outlines, je peux contraindre le modèle à sortir un objet compatible avec ce schéma. Une sortie cohérente ressemblerait à ça :

{
  "ticket_id": "TCK-98421",
  "customer_id": "CUS-4478",
  "sentiment": "Negative",
  "priority": "High",
  "summary": "Le client signale une double facturation et demande une correction rapide.",
  "action_required": true
}

Ce que je garde en tête avant d’envoyer ce payload, c’est simple mais important :

• Garder un schéma minimal : Plus il y a de champs, plus il y a de risques d’erreurs.
• Éviter les champs inutiles : Si l’API n’en a pas besoin, je ne les génère pas.
• Valider les données sensibles : Un email, un identifiant client ou un montant ne doivent pas être acceptés aveuglément.
• Ne pas confondre format valide et décision métier valide : Un JSON peut être parfait techniquement et mauvais fonctionnellement.

Sur certaines actions à impact fort, comme rembourser un client, bloquer un compte ou changer une priorité critique, je garde une règle métier ou un contrôle humain. C’est moins sexy, mais c’est souvent ce qui évite les vrais problèmes.

Un cas très concret que je vois souvent : Un ticket arrive, le LLM extrait et structure l’information, Outlines verrouille la sortie, puis n8n ou un script Python envoie le payload vers un CRM ou une base. Ce n’est pas magique. C’est juste plus robuste, parce que chaque bloc sait exactement ce qu’il doit recevoir.

Quelles limites garder en tête ?

La limite principale, c’est qu’Outlines garantit la forme de la sortie, pas la justesse complète du raisonnement ou des données. C’est déjà énorme, surtout en production, mais il faut bien placer le curseur. Outlines évite beaucoup de sorties bancales, de JSON cassés, de valeurs hors liste, de champs manquants. Il rend les LLM beaucoup plus simples à brancher dans des pipelines automatisés. Mais il ne transforme pas le modèle en source de vérité.

La nuance importante, c’est la différence entre déterminisme de format et déterminisme de contenu. Je peux forcer un modèle à répondre avec un champ age en entier. Très bien. Mais si l’âge n’est pas dans le document, ou si le prompt laisse une ambiguïté, le modèle peut quand même inventer ou déduire trop vite. Le format sera valide. Le contenu, lui, peut être faux.

Outlines est particulièrement adapté quand le problème est bien cadré :

• Classification à options fermées, par exemple urgent, normal, faible.
• Extraction structurée depuis un texte, avec des champs attendus.
• Génération de JSON propre pour alimenter une application.
• Préparation de payloads API, c’est-à-dire des données prêtes à être envoyées à un service.
• Automatisations qui cassent dès qu’un format change, comme un scénario Make, n8n ou un script Python.

Il faut rester plus vigilant dès que le fond devient sensible ou incertain :

• Donnée métier ambiguë, avec plusieurs interprétations possibles.
• Source incomplète ou contradictoire.
• Décision à fort impact, comme crédit, santé, juridique, recrutement.
• Hallucination factuelle possible, même dans une structure parfaitement valide.

Mon approche en production est assez simple. Je commence avec un schéma court, pas un monstre à 40 champs. Je teste sur de vrais exemples, y compris les cas moches. Je logge les entrées et les sorties, parce que sans logs on pilote à l’aveugle. Puis j’ajoute une validation métier derrière : contrôles de cohérence, seuils, règles, parfois une revue humaine. Et seulement après, j’intègre ça dans un workflow automatisé.

Et si le vrai sujet était juste la fiabilité ?

Outlines répond à un problème très concret : faire sortir un LLM du mode texte libre quand on a besoin d’une donnée exploitable. Pour une classification, un objet Pydantic, un JSON ou un payload API, l’idée reste la même : on contraint la génération au lieu de bricoler après. Ça ne règle pas tout, surtout pas la vérité métier, mais ça enlève une grosse source d’instabilité. Dans mes projets data et automatisation, c’est souvent ce qui fait passer une démo sympa à un workflow utilisable. Le bénéfice pour vous est simple : moins de parsing cassé, moins de rustines, plus de fiabilité.

FAQ

• À quoi sert Outlines avec un LLM ?
  Outlines sert à contraindre la sortie d’un LLM pour qu’elle respecte un format précis. Au lieu de demander gentiment au modèle de produire du JSON ou une valeur parmi une liste, on limite les tokens possibles pendant la génération.
• Outlines évite-t-il les hallucinations ?
  Il réduit surtout les erreurs de format et les sorties non conformes. Il ne garantit pas que le contenu soit vrai. Un JSON peut être parfaitement valide tout en contenant une information métier incorrecte si le contexte est insuffisant.
• Pourquoi utiliser Pydantic avec Outlines ?
  Pydantic permet de définir clairement la structure attendue : champs, types, objet final. Outlines peut ensuite utiliser cette structure comme contrainte pour générer une sortie JSON conforme et plus facile à exploiter dans du code.
• Quelle différence avec un simple prompt qui demande du JSON ?
  Un prompt classique demande au modèle de respecter une consigne. Outlines agit pendant la génération en empêchant certains tokens invalides. La différence est énorme dès qu’on branche la sortie à une API, une base ou une automatisation.
• Outlines est-il utile dans une automatisation low code ?
  Oui, surtout quand un outil comme n8n, un CRM ou une API attend un format strict. Outlines permet de produire des données plus propres en amont, ce qui évite beaucoup de scénarios d’erreur et de nettoyage derrière.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, IA appliquée en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes qui veulent connecter proprement leurs données, leurs outils et leurs modèles IA, sans monter des usines à gaz. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez fiabiliser vos automatisations IA et vos pipelines data, contactez-moi.

Franck Scandolera

⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA  ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.