Quand confier la vérification au code plutôt qu’à l’IA ?

Un contrôle dont la règle est explicite peut souvent être exécuté directement par le logiciel. Il n’est pas nécessaire de demander à un modèle de décider si une date possède le bon format ou si un identifiant existe dans une liste accessible.

La difficulté est de séparer ces contrôles de ceux qui exigent une interprétation. Une structure valide peut contenir une information fausse. La répartition doit donc porter sur chaque question de validation, pas sur le document entier.

Partir d’une demande simple

Exemple fictif. Une demande d’intervention indique « le ventilateur du local B fait un bruit anormal depuis lundi ». Le traitement propose un équipement, une observation et une date souhaitée.

Le modèle peut aider à comprendre le signalement. Le logiciel peut vérifier que l’équipement proposé appartient au site concerné. Ces contrôles établissent la validité de la référence. L’origine du bruit reste à confirmer.

Le résultat doit conserver cette différence entre information décrite, interprétation proposée et fait confirmé.

Répartir les contrôles

Un schéma déclaratif comme JSON Schema exprime les champs requis, les types et les valeurs autorisées ; le code applicatif porte les règles que le schéma ne sait pas dire, comme l’appartenance d’un équipement à un site.

Les contrôles de droits ne doivent pas dépendre de la bonne volonté du modèle. L’application doit vérifier l’autorisation au moment où elle agit, avec l’identité et la ressource concernées.

Rendre les échecs exploitables

Un rejet peut renvoyer le champ en cause et la règle attendue : identifiant inconnu, valeur hors liste ou référence absente. Cela permet de corriger une sortie sans demander au modèle de réécrire tout le document.

La reprise doit rester bornée. Après plusieurs tentatives infructueuses selon la limite définie pour le traitement, conservez le résultat partiel et signalez le problème. Une boucle qui répète la même demande sans nouvel élément ne rend pas la sortie plus digne de confiance.

Ne remplacez pas une valeur inconnue par une valeur plausible pour faire passer le schéma. L’erreur de validation indique parfois qu’il manque une information à obtenir du métier.

Tester chaque frontière

Préparez un identifiant inexistant, un identifiant réel d’un autre dossier, une date bien formée mais incorrecte et une demande sans date. Ces cas vérifient des propriétés différentes.

Ajoutez une sortie qui respecte toutes les contraintes techniques mais déforme le signalement. Elle rappelle pourquoi le contrôle de fidélité reste nécessaire après la validation structurelle.

Ce que je fais sur mon propre site

Sur ce site, la même répartition s’applique au texte. Un test automatique vérifie ce qui se décrit par une règle : un seul H1 par page, un titre de moins de 60 caractères, une description entre 50 et 160 caractères, chaque mot du mot-clé présent dans le titre ou le H1, un lien interne qui pointe vers une page existante. Un script relève ensuite des tournures à relire — parallélisme négatif, honnêteté déclarée, absolu sans preuve — et sa documentation précise qu’il « fournit des pistes, pas un verdict ». Le sens passe par une relecture : le 6 septembre 2026, les trente articles ont été relus par un second modèle avec une consigne écrite, puis chaque remarque a été acceptée ou écartée par moi. Aucun des trois contrôles ne remplace les deux autres.

Une représentation d’échange claire facilite cette séparation. Pour une intégration, je propose de définir les informations attendues, leurs preuves et les actions permises avant de choisir ce que le modèle pourra proposer et ce que le logiciel devra garantir.