Notion · Dialoguer avec un modèle
Sortie structurée
Une réponse organisée dans un format prévu, par exemple des champs pour une fiche ou une facture. Elle permet à un logiciel de traiter le résultat sans devoir interpréter un texte libre.
Comment ça marche
Par défaut, un modèle répond par du texte libre. Pour un humain, c’est parfait. Pour un logiciel qui doit utiliser la réponse, c’est un problème : il faut la relire, en extraire les informations, gérer les variations de forme. La sortie structurée règle ça : on définit à l’avance la forme exacte de la réponse, champs, types, valeurs autorisées, et le modèle la remplit.
Techniquement, on fournit un schéma, le plus souvent en JSON, et le fournisseur garantit que la réponse s’y conforme. Le modèle lit la source, et au lieu d’écrire « la facture de Dupont SA du 12 mars s’élève à 1 240 euros », il remplit fournisseur, date, montant, devise. Le logiciel suivant lit ces champs directement, les vérifie (le montant est-il un nombre, la date est-elle valide), et poursuit. C’est ce qui transforme une conversation en traitement.
Un exemple concret
- La source : chaque technicien dicte un compte rendu libre sur son téléphone en fin d’intervention : « Chez Martin, remplacé la pompe de circulation, ref P-2240, deux heures, reste à commander un joint, le client demande un devis pour le ballon. »
- Le schéma : client, équipements remplacés (liste : référence, quantité), durée en minutes, pièces à commander (liste), demandes du client (liste), suite nécessaire (oui ou non), informations manquantes (liste).
- La sortie : le modèle remplit le schéma. Le champ « informations manquantes » contient « référence du joint ».
- La suite, automatique : la fiche d’intervention est créée, la pièce est mise en commande avec un drapeau « référence à préciser », la demande de devis part au commercial, et le technicien reçoit une question sur le joint.
Avant, la dictée était retapée par une assistante le lendemain. Le devis partait une semaine plus tard, quand il partait.
Ce que ça change pour une équipe
- Le texte libre devient des données. Dictées, e-mails, documents : tout ce qui est écrit n’importe comment devient exploitable.
- Les automatisations se fiabilisent. L’étape suivante reçoit toujours la même forme. Toute une catégorie d’erreurs disparaît.
- La vérification s’automatise en partie. Un schéma permet des contrôles : type, plage, valeurs autorisées, champs obligatoires. Ce qui ne passe pas est signalé.
- La conception du schéma devient un travail de métier. Décider des champs, c’est décider de ce qui compte dans le processus. Ça se fait avec ceux qui l’utilisent.
Les limites et les erreurs fréquentes
- Un schéma trop rigide. Pas de place pour l’inattendu, et le modèle force des informations dans les mauvais champs. Prévoir « autre » et « manquant ».
- Confondre format garanti et contenu juste. Le schéma garantit la forme. Un montant au bon format peut être faux. Les valeurs critiques se vérifient.
- Oublier les listes. Un compte rendu peut mentionner trois pièces. Un champ unique en perd deux. Les champs à plusieurs valeurs sont des listes.
- Présenter du JSON à un humain. La sortie structurée est pour les logiciels. Pour les personnes, on en fait un tableau ou une fiche.
Pour aller plus loin
Un schéma JSON ou un mécanisme équivalent définit les types et les champs attendus. La conformité au schéma ne garantit pas l’exactitude des valeurs. Les contrôles métier et la validation des permissions restent nécessaires.
Où ça se situe chez Opora
Programme 02 · AutomatiserAutomatiser les tâches répétitives
Faire produire au modèle des résultats qu’un logiciel peut traiter sans intervention, et les vérifier automatiquement, c’est un geste de base du programme Automatiser.
Questions fréquentes
Quelle différence avec demander un tableau ou une liste ?
Un tableau en texte est lisible par un humain, pas toujours par un logiciel : une colonne en plus, un format de date différent, et l’étape suivante casse. La sortie structurée fixe un schéma (quels champs, quels types, quelles valeurs possibles) que le modèle doit respecter, souvent garanti par le fournisseur. Le logiciel reçoit exactement ce qu’il attend.
Le modèle respecte-t-il toujours le format ?
Avec les modes de sortie structurée des fournisseurs, le format est garanti : la réponse est validée contre le schéma avant d’être renvoyée. Sans ce mode, une simple consigne « réponds en JSON » marche souvent, mais pas toujours. Pour une automatisation, on utilise le mode garanti.
Que faire quand l’information n’est pas dans la source ?
Le prévoir dans le schéma : un champ peut être vide ou nul, et un champ « informations manquantes » liste ce qui n’a pas été trouvé. Sans cette possibilité, le modèle remplit avec du plausible, et l’automatisation traite des valeurs inventées comme des faits.