RIHEN
AccueilServicesLogicielsJeuxFormations
Retour au blog
Ingénierie & R&D

Votre instrument répond juste, mais pas à votre question

Onze cas relevés en une semaine sur nos outils. A chaque fois l'instrument fonctionnait et donnait une réponse exacte. Ce n'était simplement pas la réponse à la question qu'on croyait poser.

14 septembre 2026Par TEUGUIA TADJUIDJE Rodolf Séderis5 min de lecture
Votre instrument répond juste, mais pas à votre question

Je commence par le mien, parce qu'il est le plus pur.

Je venais de corriger un texte publié sur ce site. Pour vérifier, j'ai demandé la page et affiché le passage dans mon terminal. Il m'a montré un « à » remplacé par un caractère de remplacement. J'ai conclu que j'avais abîmé l'encodage, ce qui était plausible : j'avais justement écrit ce texte d'une façon qui expose à ce défaut.

J'ai écrit un réparateur. Par précaution, il balayait aussi tout le reste. Il a trouvé zéro occurrence, nulle part.

J'ai alors interrogé la base en demandant les points de code plutôt que le texte. Le passage était intact. Le caractère cassé n'avait jamais existé ailleurs que dans l'affichage de mon terminal, qui ne sait pas rendre l'UTF-8.

Mon instrument répondait juste, à sa question : comment ces octets s'affichent dans cette console. La mienne était : que contient la base. J'ai failli réparer une donnée saine sur la foi d'un affichage.

En une semaine, nous en avons relevé onze de cette nature. Ils se rangent en quatre formes.

1. Il mesure une grandeur voisine

Une comparaison de deux structures, octet par octet, incluait cinq octets de remplissage que personne n'écrit jamais. Elle pouvait donc échouer sur deux valeurs identiques, et réussir sur deux valeurs différentes.

Un compteur additionnait deux sens du mot taille, la dimension d'un objet et le corps d'une police, et accusait à tort la partie du code qui écrit les fichiers.

2. Il mesure au mauvais endroit, ou au mauvais moment

Un réglage posé après l'opération qu'il devait influencer : deux résultats identiques ressemblent alors trait pour trait à un réglage sans effet.

Un correctif jugé sur une valeur que le pilotage à la souris réécrit à l'image suivante, donc mesuré sur un geste nul. Le correctif était bon, il a été retiré.

Un contrôle qui lisait le sommet numéro zéro d'un cube, lequel n'est pas sélectionné : sur vingt-quatre coins, douze le sont, et le zéro n'en fait pas partie.

3. Il ne peut pas distinguer ce qu'il prétend distinguer

Un critère comparait un nombre à lui-même. Il ne pouvait pas échouer, et il serait resté vert après un correctif inexistant.

Un attendu comparait l'axe X à l'axe Z d'un cube, deux axes symétriques par construction, donc égaux quoi qu'il arrive.

Un témoin d'alignement vertical comparait les hauteurs d'éléments d'une rangée horizontale, qui partagent la même hauteur par définition.

4. Il répond juste, à propos d'un objet voisin

Mon interface de données répondait correctement sur la fiche, pas sur la page que le lecteur ouvre.

Et un journal affirmait « transformation restaurée, comparaison identique au bit », ce qui était vrai pour la poignée de manipulation, pendant que l'objet lui-même gardait sa position déplacée.

Deux choses qui rendent ces défauts coriaces

Deux instruments faux en même temps se composent en une erreur cohérente. Un relevé attendait 41,40 et mesurait 50. Deux causes simultanées : le détecteur attrapait le mauvais élément, et la capture était faite à une résolution 1,2 fois plus grande que l'espace de coordonnées. Or 41,40 multiplié par 1,2 donne 49,7.

Le nombre faux était plausible, et c'est ce qui le rend redoutable : une erreur cohérente se défend, une erreur aberrante s'écarte toute seule. La sortie a été de cesser de déduire et de faire imprimer à l'application la valeur qu'elle possédait déjà. Un nombre, et la question était close.

Un instrument non déterministe est pire qu'un instrument faux. La même commande a rendu 4 923 pixels une fois, et zéro cinq fois de suite. Un instrument franchement faux ment tout le temps, donc il finit par se trahir. Celui qui donne parfois le résultat attendu, jamais.

La parade, et elle n'est pas celle qu'on croit

On pourrait conclure qu'il faut mesurer deux fois. C'est inutile, pour une raison simple : on ne remesure jamais ce qui confirme. Quand le chiffre arrange, l'idée de le vérifier ne vient pas.

Ce qui sauve est autre chose. Voici ce qu'a écrit celui qui allait publier ce 4 923 :

Ce n'est pas la répétition qui m'a sauvé, c'est d'avoir voulu poser une mutation. J'allais écrire « la traversée existe, 4 923 pixels » ; c'est en préparant de quoi la casser que j'ai relancé la même commande. La mutation n'a pas servi à valider le témoin, elle a servi à révéler que je n'en avais pas.

Chercher comment faire échouer sa propre mesure oblige à la relancer, sans qu'on ait eu besoin de douter d'abord. C'est une discipline qui protège de soi-même, pas un contrôle de qualité.

Et elle a une forme précise. Pour surveiller un défaut réparé, un témoin qui relirait le code à la recherche de la ligne de protection resterait vert le jour où quelqu'un contourne cette protection autrement. Un compteur posé à l'endroit exact où le défaut se produit, lui, dit la vérité, à condition de prouver les deux sens : il monte quand on rouvre le défaut, et il ne monte pas quand il n'y en a pas. Un compteur qui monterait dans les deux cas serait une alarme générale, pas un témoin.

L'instrument qui compte n'est pas le plus proche de vous, c'est celui qui est à la place de l'utilisateur. Et la question à poser devant n'importe quelle mesure tient en une ligne : à quelle question répond-elle exactement, et est-ce la mienne ?

Blog

Articles liés

Voir tout
Votre instrument répond juste, pas à votre question