Le refus de répondre est une fonctionnalité

Le refus de répondre est le comportement prévu par lequel un système d’IA déclare qu’il ne dispose pas d’éléments suffisants, ou que la question sort de son périmètre, au lieu de produire une réponse incertaine.

Il ne s’agit pas d’une panne ni d’une limite du modèle, mais d’une sortie conçue au même titre qu’une réponse. Dans un assistant documentaire, il se déclenche quand la recherche ne remonte rien de pertinent, quand les passages trouvés ne permettent pas de conclure, quand l’utilisateur n’a pas les droits sur les documents utiles, ou quand la demande relève d’un sujet que l’organisation a choisi de ne pas traiter.

Traiter le refus comme une fonctionnalité, c’est lui donner une forme, un motif, une trace et un indicateur, comme on le fait pour n’importe quelle autre fonction d’un logiciel.

Le réflexe à désapprendre consiste à pousser un système d’IA qui ne trouve pas à trouver quand même, en élargissant la recherche ou en assouplissant la consigne, ce qui produit des réponses plausibles et fausses.

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.

Un refus explicite remplace certaines réponses non étayées par un arrêt visible, mais son effet sur les erreurs et la confiance doit être vérifié sur l’usage concerné.

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 », j’ai observé deux effets. Ce sont des observations de pratique, pas des résultats garantis pour tout assistant.

Le premier est attendu : les cas où le système inventait peuvent devenir des cas où il s’arrête. Le second concerne la confiance : un utilisateur comprend mieux la portée d’une réponse quand le système reconnaît aussi ses limites.

Cette confiance reste à confronter aux réponses réellement produites. Un assistant peut refuser souvent et se tromper dans les réponses restantes. Le refus complète la citation des sources, l’autre garde-fou décrit dans chatbot RAG : sources et garde-fous.

Un refus utile explique pourquoi le système s’arrête, donne une orientation autorisée et laisse une trace exploitable sans révéler de document inaccessible à l’utilisateur.

• Le motif : rien trouvé, ou trouvé mais insuffisant, ou trouvé hors de vos droits d’accès. Ce ne sont pas les mêmes situations et l’utilisateur en fera un usage différent.
• Ce qui a été cherché, pour que la personne puisse reformuler utilement.
• Une porte de sortie : à qui s’adresser, ou quel document consulter directement.
• Une trace, parce que les refus regroupés par thème indiquent exactement ce qu’il manque au corpus.

Un système d’IA bien conçu distingue au moins quatre types de refus, parce que chacun appelle une réaction différente de l’utilisateur et une action différente de l’équipe qui exploite le système.

Regrouper ces quatre cas sous un même « je ne sais pas » prive à la fois l’utilisateur d’une orientation et l’équipe d’un diagnostic.

Le taux de refus signale un changement de comportement, mais seule la relecture des demandes et réponses permet de distinguer une amélioration d’un défaut.

Une baisse peut venir d’un corpus enrichi, d’une population de questions différente ou d’une consigne assouplie. Une hausse peut signaler un document manquant, un défaut de recherche ou une prudence accrue. Aucun de ces diagnostics ne se déduit du taux seul.

Je le rapproche du taux de réponses étayées, des erreurs constatées et des demandes effectivement reçues. La mesure automatique indique où regarder ; elle ne dispense pas du contrôle humain.

Le refus doit être expliqué avant la mise en service comme une limite assumée du système, avec une orientation pour les demandes qu’il ne peut pas traiter.

Un utilisateur voit immédiatement un « je ne sais pas », alors qu’une réponse fausse et plausible peut passer inaperçue. Sans explication, le refus risque donc d’être lu comme une panne.

Je présente le contrat ainsi : le système doit s’arrêter quand les éléments autorisés ne suffisent pas à répondre. Cela ne promet pas qu’il ne se trompera jamais. Cela précise ce qu’il doit faire dans une situation d’incertitude identifiée et à qui transmettre la demande.

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, dans la logique de ce qu’on ne délègue jamais à un modèle.

Ma méthode consiste à lire des 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.

Mettre en place un refus explicite demande de trancher le périmètre, de rédiger les messages, de fixer un seuil de pertinence, puis de tester et de suivre le taux de refus dans le temps.

1. Trancher le périmètre avec le responsable métier, sur des questions réelles.
2. Rédiger un message par type de refus, avec le motif, ce qui a été cherché et la porte de sortie.
3. Fixer un seuil de pertinence en dessous duquel les passages retrouvés ne suffisent pas à répondre.
4. Placer la détection du hors-périmètre en amont, avant toute récupération coûteuse.
5. Ajouter des questions hors périmètre au jeu de tests, avec un refus comme réponse attendue.
6. Journaliser chaque refus avec son motif, et les regrouper par thème chaque mois.
7. Suivre le taux de refus comme indicateur de comportement, et enquêter sur toute variation brusque.

Le refus est aussi une forme concrète de supervision : il rend visible ce que le système ne sait pas, ce qui permet à un humain d’intervenir, comme le développe la supervision humaine, la concevoir pas la promettre.

Le suivi du taux de refus permet de repérer une variation à examiner, sans prouver à lui seul que le système invente davantage ou devient plus fiable.

Je compare des périodes où les demandes restent comparables et je sépare les motifs : absence de document, preuve insuffisante, sujet exclu. Un total mélangeant ces situations masquerait le diagnostic.

Une variation après une modification de modèle, d’index ou de consigne déclenche une relecture des cas concernés. Elle n’annonce pas nécessairement les incidents plusieurs jours à l’avance : le délai dépend de la collecte et de la fréquence des contrôles.

Tester des questions hors périmètre vérifie que le système sait s’arrêter lorsque la demande est exclue ou que les documents disponibles ne permettent pas de répondre.

Un jeu composé uniquement de questions auxquelles il faut répondre ne mesure pas cette capacité. Une optimisation pourrait améliorer son score tout en supprimant les arrêts attendus.

J’ajoute des demandes voisines des sujets autorisés, des questions sans preuve dans le corpus et des formulations ambiguës. Pour chacune, je consigne le motif attendu du refus. La méthode de constitution figure dans construire un jeu de tests en une journée, et son suivi dans l’évaluation continue.

Un refus doit arriver assez tôt pour rester utile, mais une réponse rapide ne justifie ni un arrêt prématuré ni une divulgation hors des droits d’accès.

Une vérification simple du périmètre peut précéder la recherche. Un manque de preuve, lui, ne se constate parfois qu’après récupération des passages. Il n’impose donc pas systématiquement un petit modèle placé en amont.

Je mesure séparément le délai des refus et leur pertinence. Un seuil de latence acceptable dépend de l’usage, comme le développe la latence devient un critère de conception.

Les erreurs qui rendent le refus inutile sont celles qui le rendent soit invisible, soit inexploitable : refus sec, refus non tracé, refus supprimé en optimisation, ou refus jamais expliqué aux utilisateurs.

• Le refus sec. « Je ne peux pas répondre » sans motif ni orientation produit du contournement.
• Le refus non journalisé. Il disparaît, et avec lui l’information sur ce qui manque au corpus.
• Le refus retiré pour améliorer un score. C’est la conséquence directe d’un jeu de tests sans questions hors périmètre.
• Le refus découvert par surprise. Sans contrat annoncé, il est lu comme une panne.
• Le seuil fixé une fois pour toutes. Un changement de modèle déplace le comportement ; le seuil se revérifie à chaque bascule.

Ces points figurent parmi les vérifications d’un audit IA sur un assistant documentaire.

Lectures complémentaires : l’observabilité des systèmes IA, les trois gestes qui font tenir un système.