Idée principale

Une réponse sur le comportement d'un produit est presque toujours partielle. Aucun test ne couvre le cas demandé ; le dépôt contient deux comportements selon l'état d'un feature flag ; la configuration de ce client-là n'est pas accessible ; la décision produit écrite dit une règle que le code semble contredire ; la documentation de support en dit une troisième.

Une réponse qui tait ces zones reste utilisable, lisible et fausse par endroits — sans que rien ne dise lesquels. Celui qui la reçoit, un agent de support face à un client ou un commercial en rendez-vous, l'emploie entièrement, y compris là où elle ne tenait pas. Le risque n'a pas diminué, il a changé de porteur : il était chez celui qui savait qu'il ne savait pas, il est maintenant chez celui qui croit savoir.

Énoncer les blocages est donc une partie de la réponse, pas un aveu de faiblesse. C'est ce que fait un humain sérieux — il signale son doute et dit quand il faut tester — et c'est ce qui permet à l'objectif réel d'être tenu : réduire le coût de recherche sans réduire la traçabilité de ce qui est affirmé.

Pourquoi c'est important

Cela fixe un critère d'acceptation pour un dispositif de réponse automatisé qui ne porte ni sur sa vitesse ni sur son taux de justesse : sait-il produire « je ne peux pas déterminer cela » ? Un système qui répond toujours complètement est disqualifié par cette complétude même.

Cela donne aussi une valeur à ce qui ressemble à un échec : signaler qu'un PDR et le code divergent, ou qu'aucun test ne couvre un cas, est une information produit en soi, parfois plus utile que la réponse demandée.

Nuances et limites

L'exercice a un seuil. Une réponse qui assortit chaque phrase d'une réserve redevient inexploitable, et le lecteur reprend l'habitude d'aller tester lui-même — le coût qu'on voulait supprimer revient intact.

Et la déclaration d'ignorance n'est pas plus fiable que le reste : un modèle peut affirmer avec aplomb ne pas savoir ce qu'il aurait pu établir, et cette erreur-là ne se voit pas non plus.

Questions ouvertes

• Comment vérifier qu'un dispositif signale ses zones d'ignorance réelles, et non celles qu'il lui est facile de nommer ?