Pourquoi votre fonctionnalité IA a besoin de garde-fous déterministes, pas d'un modèle plus puissant

Les LLMs sont probabilistes : chercher à leur faire produire des sorties cohérentes de manière systématique est un combat perdu d'avance. La solution n'est pas un modèle plus puissant ni un prompt plus long — c'est une couche déterministe de règles placée entre le modèle et vos utilisateurs, qui décide à chaque fois, de la même façon, ce qui est fatal et ce qui ne l'est pas.

Les fondateurs qui évaluent une fonctionnalité IA (ou une agence qui la développe pour eux) posent généralement la mauvaise question en premier : « quel modèle est le plus fiable ? » Chaque modèle — y compris la dernière version d'Anthropic ou d'OpenAI — échantillonne depuis une distribution de probabilité sur les tokens. Exécutez le même prompt deux fois et vous pouvez obtenir deux réponses différentes, même à une température basse, en raison du batching et du non-déterminisme de la virgule flottante côté inférence. Ce n'est pas un défaut qu'on corrige avec un meilleur prompt. C'est ainsi que fonctionne la technologie.

L'erreur classique : chercher le déterminisme dans la couche modèle

Les équipes qui n'ont pas encore déployé de l'IA en production ont tendance à résoudre le problème de « modèle inconsistant » en :

• Baissant la température à 0 en supposant que cela signifie déterministe (ce n'est pas tout à fait le cas)
• Ajoutant davantage d'exemples few-shot pour « fixer » le format
• Relançant le même prompt plusieurs fois et retenant la réponse majoritaire — ce qui multiplie les coûts pour un gain marginal
• Passant à un modèle plus grand et plus coûteux alors que le vrai problème est architectural

Nous avons essayé les trois premières approches sur notre propre moteur d'outreach avant de le reconstruire : plus d'exemples dans le prompt d'extraction pour tenter de fixer le format, température abaissée à 0 sur l'appel de rédaction, et à un moment une étape « relancer et choisir la meilleure réponse » qui a simplement doublé la facture de tokens sans régler le problème sous-jacent. Rien n'a tenu, parce que la sortie restait un jugement émis par un processus stochastique à chacun de ces enchaînements, et aucun prompt engineering ne change cette nature fondamentale. Si votre logique métier dépend du fait que le modèle classe, note ou route toujours de la même façon, cette logique doit vivre en dehors du modèle.

La solution : séparer le jugement de la conséquence

Le schéma qui fonctionne : laissez le LLM faire ce pour quoi il est réellement doué (jugement ouvert, extraction, rédaction) et transmettez sa sortie à une couche de règles déterministes qui décide de la suite. Concrètement :

1. Le modèle note ou classe. Il peut varier d'un appel à l'autre ; c'est acceptable, car rien en aval ne lui fait confiance aveuglément.
2. Un ensemble fixe de règles décide ce qui est fatal ou non. Il s'agit de code ordinaire : un frozenset de conditions disqualifiantes, un validateur JSON Schema conforme à la spécification JSON Schema, ou une petite table de règles métier. Il n'appelle jamais le modèle et ne change jamais entre les requêtes.
3. Seule la décision de la couche de règles est enregistrée et appliquée. Le score brut du modèle devient une entrée, pas le verdict.

Cela signifie que votre suite de tests peut être véritablement déterministe, même si ce qu'elle teste ne l'est pas. Vous écrivez des tests unitaires contre la couche de règles (simples, rapides, sans appels API) et vous surveillez la distribution des sorties du modèle dans le temps (détection de dérive) plutôt que d'asserter sur une réponse unique. Ce sont deux problèmes distincts, et les confondre explique pourquoi tant d'équipes se retrouvent avec des suites de tests IA instables qu'elles finissent par ignorer.

Où ce principe se manifeste dans des projets réels

Nous avons vu ce même principe porter ses fruits dans nos propres outils, au-delà des fonctionnalités de chat. Lors du développement de notre moteur d'outreach, nous avons initialement enchaîné plusieurs appels LLM : scraper le site du prospect, le résumer, en extraire des faits, puis rédiger l'email. Chaque étape ajoutait un nouveau point où la variance pouvait s'amplifier, et déboguer pourquoi un mauvais email était produit signifiait retracer quatre enchaînements non déterministes. Réduire le tout à un seul appel qui extrayait les faits et rédigeait l'email simultanément, avec une post-vérification déterministe sur la longueur, les phrases interdites et les champs de personnalisation obligatoires, a surpassé la chaîne multi-étapes tant sur le coût que sur la qualité. Moins d'enchaînements stochastiques signifiait moins d'endroits où la couche de règles devait intercepter des problèmes, et les problèmes interceptés étaient plus faciles à rattacher à un seul appel. C'est le même enseignement fondamental que le schéma des garde-fous : réduire la variance au minimum d'endroits possibles, puis encapsuler ce qui reste dans des règles réellement testables. Si vous choisissez entre un seul appel bien ciblé et une chaîne d'agent multi-étapes, les compromis sont les mêmes que ceux abordés dans appel unique vs chaînes d'agents.

Les bonnes questions à poser à un prestataire ou à une agence

Si vous évaluez qui va développer une fonctionnalité IA pour vous, « comment rendez-vous les sorties fiables ? » est une question légitime — et « nous utilisons le dernier modèle » n'est pas une vraie réponse. Posez plutôt ces questions :

• Quelle est la couche déterministe ? La réponse devrait ressembler au frozenset de conditions disqualifiantes ou au validateur JSON Schema décrit plus haut, pas à « le modèle est invité à être prudent. » S'ils ne peuvent pas nommer l'ensemble de règles spécifique en une phrase, c'est qu'ils n'en ont pas construit.
• Comment testez-vous cela ? Vous devriez entendre parler de tests unitaires contre la couche de règles ainsi que d'une surveillance de la dérive de la distribution du modèle — pas « nous l'avons lancé quelques fois et ça semblait correct. »
• Que se passe-t-il quand la couche de règles rejette une sortie ? Relancer avec un prompt différent, basculer sur un défaut sûr, ou escalader vers un humain. Les trois sont valides ; « rien, on se contente de l'enregistrer » ne l'est pas.
• La couche de règles figure-t-elle dans le contrat ? Si la fiabilité est suffisamment importante pour être payée, elle devrait être spécifiée au même titre que le livrable, pas laissée implicite. Cela rejoint ce que nous abordons dans les evals dans les contrats avec des prestataires IA.

Il y a aussi un angle coût direct : chaque relance ou appel en vote majoritaire est une facture de tokens que vous payez pour compenser l'absence d'une couche de règles. Les équipes qui sautent la couche déterministe finissent souvent par résoudre le problème de coût plus tard avec du rate limiting et du caching — ce qui est un schéma valide en soi, mais traite un symptôme que le garde-fou aurait prévenu ; consultez le rate limiting des fonctionnalités IA pour maîtriser les coûts si vous en êtes déjà là.

En résumé

Ne cherchez pas « le modèle qui hallucine le moins ». Cherchez l'équipe capable de vous montrer concrètement ce qui arrive à une mauvaise sortie après que le modèle l'a produite. Un frozenset décidant ce qui est fatal est un gage de fiabilité plus honnête que n'importe quelle affirmation sur la qualité du modèle — parce qu'il est testable, qu'il ne dérive pas, et que vous pouvez le lire en cinq minutes lors d'une revue prestataire.

Si vous cadrez une fonctionnalité IA et souhaitez un second avis sur l'emplacement idéal de la couche déterministe, parlons-en.