# Le code pour les règles. Le modèle pour le jugement. Une matrice de décision pour choisir entre code, regex, schéma, recherche et jugement du modèle sans confondre structure valide et vérité. Version 1.0 · 2026-07-29 · 9 min ## Réponse courte Utilisez du code déterministe pour ce que le système peut calculer ou imposer exactement : authentification, droits, totaux, seuils, transitions, champs obligatoires et invariants métier. Réservez les parseurs ou les regex aux formats stables dont la grammaire est connue. Interrogez les sources nommées pour les faits. Appelez un modèle lorsque le travail demande d’interpréter un langage ambigu, de classer une intention, de rédiger ou de comparer des éléments. Une sortie structurée peut garantir une forme exploitable dans les limites du schéma pris en charge. Elle ne prouve ni la vérité des valeurs, ni leur autorisation, ni leur cohérence métier. ## À retenir - L’authentification, les totaux et les invariants restent dans le code même si un modèle prépare les données. - Une regex convient à une syntaxe stable, pas au sens d’un langage ambigu. - Un objet JSON valide peut tout de même contenir un mauvais montant, un mauvais dossier ou une mauvaise décision. ## L’erreur coûteuse consiste à demander un jugement quand la réponse était déjà exacte Un modèle peut lire une facture, décrire une anomalie et proposer une catégorie. Il ne doit devenir ni la calculatrice de référence pour le total, ni l’autorité qui décide si l’utilisateur peut la comptabiliser. Ces réponses appartiennent déjà au code, aux données et aux règles de l’entreprise. L’erreur inverse existe aussi. Une accumulation de regex et de conditions comprend mal un email fournisseur, une note de maintenance ou une demande de support dont les formulations changent. Le bon design place chaque décision dans la couche qui sait réellement la traiter. ## Une matrice de décision concrète Classez d’abord la décision avant de choisir un modèle, une bibliothèque ou un prompt. ### 1. Imposer les règles exactes avec du code Conserver dans l’application l’identité, les droits, les seuils, les totaux, les transitions, l’unicité et les invariants. ### 2. Analyser les syntaxes stables Utiliser un parseur, une regex ou un validateur de schéma pour les identifiants et formats à grammaire connue. Refuser ou normaliser explicitement au lieu de demander au modèle de deviner. ### 3. Lire les faits dans leur source Récupérer les valeurs changeantes dans le système de référence et les règles stables dans les sources autorisées. Conserver leur origine et leur fraîcheur. ### 4. Confier le jugement au modèle Utiliser le modèle pour une intention ambiguë, une classification sémantique, un résumé, une rédaction ou une comparaison de preuves lorsque plusieurs formulations sont valables. ### 5. Contraindre l’interface Demander une sortie typée et la valider. Traiter la structure comme un contrat d’interface, puis vérifier les identifiants, les valeurs et les droits dans l’application. ### 6. Transmettre les cas non résolus Si les preuves se contredisent ou si l’incertitude reste trop forte, la montrer et remettre le cas à une personne plutôt que fabriquer une réponse binaire. ## Exemples ### Écriture comptable Le modèle classe un message fournisseur et extrait des champs candidats. Le code recalcule les totaux, contrôle la période et valide le compte avant toute proposition. ### Accès sur un chantier Le modèle résume la demande. L’application vérifie l’identité, l’habilitation et les accords requis dans les données de référence. ### Support SaaS Le modèle relie une demande libre à une catégorie. Un schéma contrôle la charge utile, puis le produit retrouve le vrai client, son offre et ses droits. ## Pièges fréquents - Demander au modèle si une personne peut lire ou modifier un dossier. - Utiliser un calcul généré pour les montants financiers ou les seuils stricts. - Empiler des regex pour imiter la compréhension d’un langage ouvert. - Considérer une sortie conforme au schéma comme factuellement juste. - Présenter un second modèle comme un validateur déterministe du premier. ## Checklist 1. Chaque décision est classée comme exacte, syntaxique, issue d’une source ou fondée sur un jugement. 2. L’authentification, les droits et les invariants restent hors du modèle. 3. Les montants et les totaux sont recalculés depuis les valeurs sources. 4. Les parseurs et regex possèdent des cas acceptés et refusés explicites. 5. Les sorties structurées sont validées puis confrontées aux données actuelles. 6. Les jugements du modèle gardent leurs preuves et un chemin visible en cas d’incertitude. 7. Les évaluations contiennent des valeurs plausibles et conformes au schéma, mais fausses. ## Limites - Un code déterministe peut tout de même contenir une règle métier erronée ou dépassée. - La couverture des schémas et du décodage contraint varie selon les modèles et les bibliothèques. - Certaines catégories métier restent subjectives et demandent des critères de revue humaine partagés. ## Sources 1. [Artificial Intelligence Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — NIST, 2023; nature: standard. 2. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks](https://openreview.net/forum?id=m1YYAQjO3w) — Debenedetti et al., 2025; nature: research. 3. [Outlines: Structured Outputs](https://github.com/dottxt-ai/outlines) — Outlines maintainers, 2026; nature: official-documentation. 4. [JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language Models](https://arxiv.org/abs/2501.10868) — Geng et al., 2025; nature: research. ## Questions fréquentes ### Une sortie structurée supprime-t-elle les hallucinations ? Non. Elle peut contraindre la syntaxe et les formes autorisées. Un champ bien formé peut encore contenir une valeur inventée ou ancienne. ### Quand une regex est-elle le bon choix ? Quand l’entrée suit une grammaire stable, comme un identifiant connu ou un format délimité. Elle juge mal une intention exprimée librement. ### Le modèle peut-il proposer un total ou un résultat de droits ? Il peut expliquer ou afficher un résultat calculé par l’application. Le calcul officiel et la décision d’accès doivent rester déterministes. --- Canonical: https://scoperail.fokalabs.io/fr/guides/code-deterministe-ou-jugement-ia Author: Ramzi Laieb, FokaLabs