Pourquoi une réponse lisible ne suffit pas
Un assistant peut rédiger une fiche parfaitement compréhensible tout en produisant des données inutilisables par un logiciel. Une virgule oubliée, une date ambiguë ou un champ renommé suffit pour interrompre une automatisation. Le risque augmente lorsqu’une réponse doit alimenter un système comptable, un outil de soutien ou un registre interne. Prenons un scénario fictif inspiré d’une PME québécoise. Un assistant doit convertir des demandes reçues par courriel en quatre champs : numéro de dossier, catégorie, date d’échéance et niveau de priorité. Le résultat doit être transmis à une application sous forme de JSON, un format courant pour échanger des données entre logiciels. La première étape consiste à séparer deux critères. La syntaxe indique si le document respecte les règles du JSON. La conformité métier indique si son contenu correspond réellement aux besoins. La valeur « bientôt » peut être valide sur le plan syntaxique, mais elle demeure inutilisable si l’application attend une date au format année-mois-jour. Il faut donc vérifier le contenant et le contenu avant toute intégration.
Définir un contrat de sortie minimal
Avant de demander quoi que ce soit à l’IA, écrivez un contrat de sortie assez précis pour être vérifié automatiquement. Dans notre exemple, chaque réponse doit contenir exactement quatre champs. Le numéro de dossier est une chaîne de caractères. La catégorie doit être « facturation », « livraison », « soutien » ou « autre ». L’échéance doit prendre la forme 2026-10-05 ou être nulle si aucune date n’apparaît. La priorité doit être « basse », « normale » ou « élevée ». Indiquez aussi ce que l’assistant ne doit pas faire. Il ne doit pas créer de numéro absent, convertir une date incertaine en certitude ni ajouter un commentaire à l’extérieur du JSON. Une consigne utile serait : « Retourne uniquement un objet JSON conforme aux champs définis. Utilise null lorsqu’une information est absente. Ne déduis pas une échéance à partir du ton du message. » Un contrat court facilite la maintenance. Si vous définissez 25 champs dès le premier essai, il devient difficile de savoir pourquoi un test échoue. Commencez avec quatre à six champs indispensables, puis ajoutez les autres lorsque la structure de base tient le coup.
Construire douze cas qui cherchent les failles
Ne testez pas seulement des demandes propres et complètes. Préparez plutôt douze messages fictifs couvrant des situations normales et problématiques. Trois peuvent contenir tous les renseignements attendus. Deux devraient omettre l’échéance. Deux autres peuvent présenter des dates québécoises ambiguës, comme « vendredi prochain » ou « le 5 octobre ». Ajoutez un doublon, un message bilingue, une demande hors sujet, un numéro de dossier mal écrit et une consigne malveillante cachée dans le texte. Pour chaque cas, rédigez manuellement le résultat attendu avant d’interroger l’assistant. Le message « Pouvez-vous vérifier ma facture avant le 5 octobre? Dossier QC-1842 » devrait, par exemple, recevoir la catégorie « facturation ». Toutefois, l’année de l’échéance devrait rester absente si le contexte ne permet pas de la déterminer avec certitude. Ce petit jeu étalon transforme une impression subjective en vérification reproductible. Douze cas ne prouvent pas qu’un système fonctionnera toujours, mais ils permettent de repérer rapidement les erreurs les plus coûteuses : invention de données, mauvais type de champ, valeur non permise ou interprétation excessive.
Valider en trois passages distincts
Faites d’abord passer chaque réponse dans un validateur JSON local ou dans la fonction équivalente de votre langage de programmation. Cette étape détecte les guillemets incorrects, les virgules manquantes et les caractères ajoutés avant ou après l’objet. Une réponse qui échoue ici ne devrait jamais atteindre l’application suivante. Le deuxième passage vérifie le schéma. Confirmez que les quatre champs existent, qu’aucun cinquième champ inattendu n’a été ajouté et que chaque valeur respecte son type. Une date ne doit pas devenir une phrase. Une priorité ne doit pas prendre la valeur « urgente » si cette option ne figure pas dans le contrat. Le troisième passage compare le contenu au résultat attendu. Créez un tableau avec une ligne par cas et cinq colonnes : syntaxe valide, schéma valide, catégorie exacte, date exacte et invention détectée. Un résultat de 11 réussites sur 12 est utile pour diagnostiquer le système, mais insuffisant pour prétendre qu’il est fiable. Examinez surtout la nature de l’échec. Une catégorie discutable exige un ajustement métier; un numéro inventé révèle un problème plus grave.
Prévoir l’échec avant l’automatisation
Une sortie invalide ne devrait pas être réparée silencieusement par une deuxième IA, car celle-ci pourrait modifier le sens des données. Prévoyez plutôt une règle simple : si la syntaxe ou le schéma échoue, la réponse est mise en attente et le texte original est conservé. Si seule une valeur métier est incertaine, le dossier peut être dirigé vers une personne avec le champ problématique clairement signalé. Conservez aussi la version du contrat, le modèle utilisé, la date du test et les douze entrées fictives. Vous pourrez ainsi répéter exactement l’essai après un changement de modèle, de consigne ou de fournisseur. Pour une organisation québécoise, cette discipline est particulièrement utile lorsque les demandes mélangent le français, l’anglais, les abréviations locales et des formats de date variables. Le but n’est pas d’obtenir une démonstration spectaculaire, mais une chaîne prévisible. Une bonne intégration refuse proprement une donnée douteuse, indique pourquoi elle a été refusée et permet à une personne de reprendre le dossier sans perdre le message d’origine.
