Quel format demander à l’IA pour vos données métier ?

Le format demandé à une IA doit permettre de retrouver les informations nécessaires à la suite du travail. Un texte libre convient à une lecture humaine. Dès qu’un logiciel doit extraire une date, identifier un dossier ou préparer une action, les règles de lecture doivent devenir explicites.

Je propose de choisir ce format à partir du résultat à reconstruire, puis de mesurer la qualité de la sortie. Une représentation plus courte n’est utile que si elle conserve les distinctions dont le métier a besoin.

Décrire les informations avant la syntaxe

Exemple fictif. Une demande d’intervention contient un équipement, un problème signalé et une date souhaitée. La date est parfois absente. Le résultat doit conserver cette absence sans la remplacer par la date du jour.

Une fiche d’échange pourrait ressembler à ceci :

Équipement : ventilateur du local B
Observation : bruit anormal signalé
Date souhaitée : inconnue
Source : demande-exemple, paragraphe 2

Il s’agit d’un exemple pédagogique, pas d’un format prêt à importer dans un logiciel. Pour l’automatiser, il faut décider comment représenter une valeur sur plusieurs lignes, un champ répété, un caractère spécial et une référence invalide.

Choisir selon les lecteurs du résultat

Le Markdown ne devient pas un contrat simplement parce qu’il possède des titres. Le JSON ne garantit pas non plus la vérité des valeurs. Dans les deux cas, les règles d’interprétation et les informations attendues doivent être définies. Pour le Markdown, la grammaire de référence est CommonMark ; pour le JSON, la structure attendue se décrit avec JSON Schema. Aucune des deux ne vérifie le sens d’une valeur.

Séparer lecture et validation

Le logiciel commence par lire la sortie selon le format retenu. Il vérifie ensuite les champs requis, les valeurs autorisées et les références accessibles. Une erreur doit désigner l’élément concerné pour permettre une correction ciblée.

La fidélité demande un contrôle complémentaire : l’observation provient-elle bien de la source ? Une date a-t-elle été transformée en engagement ? Un élément important a-t-il disparu ? La validation par le code doit être distinguée de cette interprétation.

Tester le format sur ses cas difficiles

Préparez une valeur contenant un séparateur, plusieurs équipements dans une demande, une note longue et un champ inconnu. Vérifiez aussi qu’une lecture suivie d’une réécriture conserve les données prévues par le contrat.

Si une version du format change, indiquez comment les anciens documents seront lus. Une nouvelle règle ne doit pas modifier silencieusement le sens d’un fichier déjà enregistré.

Évaluer avant de généraliser

Comparez les formats avec les mêmes sources et des critères communs : informations conservées, erreurs de lecture, corrections et durée jusqu’au résultat accepté. Aucun format n’est préférable pour tous les usages.

Pour cadrer une intégration documentaire, un exemple partageable et la description du résultat attendu suffisent à commencer. Le choix doit rester guidé par ce que le logiciel et la personne pourront réellement vérifier.