JSON valide, données fausses : les deux contrôles nécessaires pour une réponse d’IA

Le programme accepte le fichier. Les accolades sont bien placées, les noms de champs correspondent et aucun message d’erreur ne s’affiche. Pourtant, le montant extrait de la facture est celui d’un acompte, pas celui du total. Le JSON est exploitable par le logiciel ; l’information qu’il transporte reste fausse.

Ce décalage devient important dès qu’une réponse d’IA alimente un tableau, un CRM ou un automatisme. La validation du format et celle des faits remplissent deux fonctions distinctes.

La syntaxe répond seulement à une première question

Le JSON organise des données avec des objets, des tableaux, des chaînes, des nombres et quelques valeurs particulières. Une erreur de virgule ou de guillemet peut empêcher sa lecture. Un analyseur syntaxique vérifie cette forme élémentaire.

Il ne vérifie pas qu’un numéro de facture existe ou qu’un client a réellement accepté une offre. Le texte « accepté » est une chaîne parfaitement valide, y compris lorsque la source indique « en attente ».

Un schéma de validation ajoute des contraintes : champs requis, types, valeurs autorisées, bornes et structure des objets. Il peut refuser un montant écrit en toutes lettres si un nombre est attendu, ou un statut absent de la liste prévue.

Il faut toutefois configurer le validateur correctement. La documentation JSON Schema rappelle que le mot-clé format peut être une simple annotation par défaut. Déclarer qu’un champ est une date ne signifie donc pas que toutes les implémentations rejetteront automatiquement chaque date impossible ou mal écrite.

Même un contrôle de date actif n’établit pas que cette date est celle du document. Il démontre au mieux qu’elle respecte certaines règles de représentation.

Une valeur correcte peut occuper le mauvais champ

Supposons qu’un document comporte un sous-total, une taxe et un montant déjà réglé. Le modèle peut extraire les trois nombres sans faute, puis ranger l’un d’eux dans le champ « total à payer ». L’erreur vient de l’association entre valeur et signification.

Les règles métier permettent d’ajouter des contrôles : le total doit être compatible avec les lignes et les taxes, une date de fin ne doit pas précéder la date de début, une devise doit correspondre au document. Elles attrapent certaines incohérences que la structure seule laisse passer.

Mais elles ne suffisent pas toujours. Un montant erroné peut rester dans une fourchette plausible et satisfaire une formule parce que plusieurs champs ont été mal associés de façon cohérente. Il faut alors revenir à la preuve dans la source.

Une erreur de sens peut aussi toucher les personnes : notre exemple d’attribution erronée d’une décision dans un compte rendu automatique montre pourquoi une donnée bien rangée doit encore être vérifiée.

Pour chaque information importante, conservez un repère : page, zone, libellé ou passage court. L’application peut afficher la valeur proposée à côté de son origine pour une relecture. Demander au modèle un repère ne garantit pas son exactitude ; cela rend l’erreur plus facile à examiner.

Prévoyez également l’information absente. Si aucun délai de livraison n’est indiqué, forcer un nombre pousse le système à compléter. Une valeur nulle, accompagnée d’un motif conforme à votre modèle de données, peut être préférable à une estimation qui ressemble à un fait.

À retenir : un champ peut être présent, bien typé et plausible tout en étant faux. La validation doit porter aussi sur son sens et son appui documentaire.

Construire deux portes avant l’enregistrement

La première porte traite la conformité technique. Le fichier peut-il être lu ? Respecte-t-il la version du schéma ? Les champs obligatoires, types et valeurs autorisées sont-ils conformes ? Une erreur à ce niveau bloque le passage vers les traitements suivants.

La seconde porte traite la fiabilité des données. Les valeurs correspondent-elles à la source ? Les unités sont-elles explicites ? Les calculs tiennent-ils ? L’entité extraite correspond-elle au bon client et au bon document ? Les absences ont-elles été signalées ?

Ces deux portes peuvent être automatisées en partie. Une base de référence permet de vérifier un identifiant client ; du code peut recalculer un total ; un humain peut arbitrer un passage ambigu. Il n’est pas nécessaire de confier chaque contrôle au même modèle qui vient de produire la réponse.

Un statut « à vérifier » doit empêcher les actions qui supposent une validation terminée. Sinon, le contrôle devient une annotation décorative ajoutée à des données déjà envoyées à la facturation ou au destinataire final.

Séparez enfin l’extraction de l’action. Écrire un brouillon de ligne et créer une commande réelle ne sont pas la même opération. Les exigences de validation doivent suivre les conséquences du traitement.

Tester les cas qui donnent envie d’inventer

Un bon échantillon comprend des sources avec champ manquant, plusieurs dates, montant annulé, document corrigé, devise inhabituelle et tableau mal lu. Les cas propres ne révèlent pas comment le système réagit lorsque l’information n’existe pas ou se contredit.

Comparez les sorties aux valeurs attendues, champ par champ. Le taux d’erreur global peut masquer un défaut concentré sur les unités ou sur les références clients. Mesurez séparément les champs qui déclenchent une décision importante.

Conservez la version du schéma et la version des règles utilisées. Ajouter un champ ou changer le sens d’un statut peut casser une intégration même si le JSON reste valide. Les logiciels en aval doivent savoir quel contrat de données ils reçoivent.

Si le contrôle rejette une réponse, évitez les tentatives répétées jusqu’à obtenir un fichier simplement accepté. Une reformulation peut corriger un format ; elle ne crée pas la preuve manquante. La bonne sortie peut être un dossier à relire, avec la raison précise du blocage.

Le voyant vert utile signifie donc davantage que « le programme a réussi à lire le fichier ». Il doit indiquer quelles vérifications ont été effectuées et lesquelles restent nécessaires avant d’utiliser les données.