Obtenir du JSON avec l'IA : données structurées fiables

Tu demandes à l'IA de sortir les informations d'une facture « en JSON », et elle répond : « Bien sûr ! Voici le JSON demandé », suivi d'un bloc de code, puis d'une note qui explique ses choix. Le lendemain, le champ montant s'appelle total, la date passe en toutes lettres et le prix devient "125,50 €", une chaîne de caractères. Pour un humain, c'est lisible. Pour un script ou un tableur, c'est une panne.

JSON est un format texte qui range des données en paires nom et valeur. Tu n'as pas besoin de savoir programmer pour en profiter, et si ta destination est un tableur, le CSV fera encore plus simple. Dans les deux cas, le principe reste le même : tu décides du format à l'avance, sans marge d'interprétation.

Décrire le schéma au lieu de dire « en JSON »

Le mot « JSON » seul laisse le modèle libre de choisir la structure, les noms et les types. Il faut lui donner le moule complet. Prends un restaurateur qui veut suivre ses factures fournisseurs.

Avant :

Extrais les informations de cette facture en JSON.

Après :

Extrais les données de la facture ci-dessous. Réponds uniquement avec un objet JSON valide, sans texte avant ni après et sans balises de code Markdown.

Respecte exactement cette structure et ces noms de champs :

{
  "fournisseur": "chaîne",
  "numero_facture": "chaîne",
  "date": "AAAA-MM-JJ",
  "total_ht": nombre,
  "total_ttc": nombre,
  "lignes": [
    { "designation": "chaîne", "quantite": nombre, "prix_unitaire_ht": nombre }
  ],
  "categorie": "boissons" | "frais" | "epicerie" | "autre"
}

Règles :
- Les nombres s'écrivent avec un point décimal, sans symbole de devise.
- Si une information est absente ou illisible, mets null. Ne devine jamais et ne la calcule pas.
- N'ajoute aucun champ.

Facture :
[TEXTE DE LA FACTURE]

Quatre choix font la différence. Le schéma est montré en entier, donc les noms de champs ne bougent plus. La date a un format non ambigu : 2026-03-04 ne se confond pas selon les pays. La catégorie est une liste fermée, ce qui évite d'avoir « Boissons », « boisson » et « Vins » dans le même fichier. Enfin, le null donne à l'IA une issue honnête quand l'information manque.

Les champs manquants, source de la plupart des erreurs

Quand un champ est obligatoire dans ton schéma et que l'information n'est pas dans le document, le modèle a tendance à en produire une. Un numéro de TVA peut apparaître là où il n'y en avait pas. Le JSON sera parfaitement valide et faux.

Deux précautions aident. La première, c'est la règle du null ci-dessus, pour chaque champ. La seconde, c'est de demander la preuve quand l'enjeu le justifie : ajoute un champ extrait_source qui recopie le passage d'où vient la valeur. Tu peux alors comparer rapidement sur un échantillon. Pour la logique générale, l'article pour réduire les hallucinations va plus loin.

Le cas le plus courant : un CSV pour Excel

Si ta destination est un tableur, oublie JSON : demande directement un CSV. Une difficulté française à connaître : avec des réglages régionaux français, Excel attend en général un point-virgule comme séparateur et une virgule pour les décimales. Un CSV avec des virgules peut donc s'ouvrir avec tout dans une seule colonne.

Exemple pour une trésorière d'association qui transforme des inscriptions reçues par e-mail, en données fictives ici :

Transforme les messages ci-dessous en un tableau CSV, sans aucun texte autour et sans balises de code.

Paramètres :
- séparateur : point-virgule ;
- décimales : virgule ;
- première ligne, exactement : nom;prenom;activite;montant;moyen_paiement;a_verifier
- activite : parmi [LISTE DES ACTIVITÉS]
- moyen_paiement : cheque, virement, especes ou vide si non précisé.

Une ligne par personne inscrite. Si un message inscrit deux personnes, fais deux lignes. Si une information est absente ou ambiguë, laisse la case vide et mets « oui » dans a_verifier.

Messages :
[COLLE LES MESSAGES]

Colle le résultat dans un fichier .csv, ou dans ton tableur en passant par la fonction d'import de texte. Attention aux données personnelles : avant de coller les messages de vraies personnes, regarde ce qu'il ne faut pas mettre dans un chatbot et les conditions de ton offre.

Valider le résultat, à chaque fois

Une sortie structurée peut casser de trois manières : le texte n'est pas du JSON valide, la structure ne correspond pas au schéma, ou les valeurs sont fausses. Les deux premières se contrôlent automatiquement. Voici un script Python court qui s'arrête dès qu'un problème apparaît :

import json

CHAMPS = {"fournisseur", "numero_facture", "date", "total_ht",
          "total_ttc", "lignes", "categorie"}
CATEGORIES = {"boissons", "frais", "epicerie", "autre"}

def valider(reponse: str) -> dict:
    data = json.loads(reponse)  # plante si ce n'est pas du JSON
    if set(data) != CHAMPS:
        raise ValueError(f"Champs incorrects : {set(data) ^ CHAMPS}")
    if data["categorie"] not in CATEGORIES:
        raise ValueError(f"Catégorie inconnue : {data['categorie']}")
    ttc, ht = data["total_ttc"], data["total_ht"]
    if ttc is not None and ht is not None and ttc < ht:
        raise ValueError("Total TTC inférieur au total HT")
    return data

Le contrôle du TTC relève du bon sens métier, et il attrape des erreurs qu'aucun schéma ne verrait. Pour les valeurs, prévois un contrôle par sondage : compare dix documents à la main avant de faire confiance au traitement, puis quelques-uns de temps en temps.

Sans code, tu peux demander au modèle de te signaler les lignes suspectes dans une nouvelle conversation, mais il peut en rater. Une somme recalculée dans le tableur reste plus sûre.

Passer à l'API quand le volume monte

Si tu traites des dizaines de documents par un programme, le prompt seul n'est pas la meilleure solution. Les API des principaux fournisseurs proposent des options pour contraindre la sortie à un schéma JSON. Leurs noms et leurs garanties évoluent, regarde la documentation de ton fournisseur au moment où tu t'y mets. Ces options te garantissent une structure conforme, pas des valeurs justes : garde la règle du null et les contrôles métier.

Pour un flux en plusieurs étapes, une sortie JSON sert aussi de pont entre deux modèles ou deux prompts, comme dans une chaîne de prompts.

Fais l'essai sur trois documents réels

Choisis trois documents du même type, dont un mal fichu : une facture scannée, un message incomplet. Passe-les dans le prompt de ton choix avec un schéma de cinq champs seulement, puis compare chaque valeur à l'original. Le document mal fichu te dira quelles règles ajouter avant d'élargir le schéma.