Le refus de répondre est une fonctionnalité

Quand un système ne trouve pas, la réaction naturelle est de le pousser à trouver quand même : élargir la recherche, remonter plus de documents, assouplir la consigne.

On obtient effectivement une réponse. On obtient surtout une réponse construite sur des éléments faiblement liés à la question, formulée avec la même assurance qu'une bonne réponse. C'est le pire des deux mondes.

Sur les systèmes où j'ai introduit un refus explicite, « je ne trouve pas d'élément suffisant dans les documents auxquels vous avez accès », deux effets se produisent, et le second surprend souvent.

Le premier est attendu : les erreurs graves chutent, parce que les cas où le système inventait sont désormais des cas où il s'arrête.

Le second l'est moins : la confiance des utilisateurs augmente. Un système qui dit parfois non devient crédible quand il dit oui. Un système qui répond toujours est traité comme une boîte à idées, pas comme une source.

Un refus est visible. Un utilisateur qui reçoit « je ne sais pas » le remonte, alors qu'une réponse fausse et plausible passe inaperçue.

Il faut donc l'expliquer avant la mise en service, sans quoi les premiers refus seront lus comme un dysfonctionnement. Je le présente comme un contrat : le système ne vous mentira pas, en échange il vous laissera parfois sans réponse.

Ce contrat est accepté partout où je l'ai proposé. Il n'est jamais accepté après coup.

Le taux de réponses « je ne sais pas », suivi dans le temps, est le signal le plus fiable d'un changement de comportement du système. Il bouge avant que quiconque ne se plaigne.

Une baisse soudaine signale que le système s'est mis à répondre là où il refusait, ce qui est une dégradation, pas un progrès. Une hausse signale l'inverse : le modèle est devenu plus prudent et une partie des questions légitimes reçoit un refus.

Dans les deux cas, l'alerte précède les signalements utilisateurs de plusieurs jours. Le tableau de bord correspondant figure dans l'observabilité des systèmes IA.

Un jeu de tests sans questions hors périmètre ne mesure que la moitié du comportement. C'est l'omission la plus fréquente, et elle se paie lors des campagnes d'optimisation.

Un système optimisé sur un jeu composé uniquement de questions légitimes voit ses garde-fous supprimés sans que rien ne l'indique : la consigne de refus « ne change rien sur le jeu de tests », donc on la retire.

J'ajoute systématiquement une dizaine de questions hors périmètre au jeu, avec pour réponse attendue un refus explicite. La méthode de constitution figure dans construire un jeu de tests en une journée.

Dans un usage rapide, le refus doit être aussi rapide que la réponse : un système qui met huit secondes à dire qu'il ne sait pas est pire qu'un système qui le dit tout de suite. C'est une contrainte de conception, pas un détail.

La raison est comportementale. Un utilisateur qui attend longtemps pour recevoir un refus cesse d'utiliser le système, alors qu'un refus immédiat le renvoie sans friction vers la bonne ressource.

Cela impose que la détection du hors-périmètre se fasse en amont, sur un petit modèle rapide, avant toute récupération coûteuse. Le raisonnement complet figure dans la latence devient un critère de conception.

Décider ce que le système ne traitera pas est une décision métier, et elle doit être prise par quelqu'un qui répond du périmètre, pas par l'équipe technique. C'est la condition qui manque le plus souvent.

La distinction est nette. L'équipe technique sait dire ce que le système est capable de faire ; elle ne peut pas dire ce qu'il a le droit de faire. Un système peut parfaitement répondre à une question qu'il ne devrait pas traiter, et c'est précisément le cas dangereux.

La méthode que j'applique tient en une heure : lire cinquante questions réelles avec le responsable métier, et trancher pour chacune, dans le périmètre, ou refus explicite. Le résultat est une liste courte, datée, qui devient la référence.

Cette liste se relit chaque trimestre, parce que les usages dérivent et que le périmètre doit suivre. C'est l'un des trois gestes décrits dans les trois gestes qui font tenir un système.