Accueil / Cas réels de bout en bout

Vérifier avant de croire, quatre pièges réels

Un rapport rédigé par l'agent d'un tiers, une skill payante vendue comme un lot de fonctionnalités, un connecteur de données annoncé comme synchronisé et une page concurrente qui affiche une fonctionnalité absente partagent la même faille : chacun remplace une mesure directe par une affirmation qu'il faudrait vérifier avant de la citer.

Un rapport rédigé par l'agent d'un tiers, une skill payante vendue comme un lot de fonctionnalités, un connecteur de données annoncé comme synchronisé et une page concurrente qui affiche une fonctionnalité absente partagent la même faille. Chacun remplace une mesure directe par une affirmation, et rien ne distingue une affirmation vraie d'une affirmation fausse tant que personne ne l'a vérifiée indépendamment.

Le rapport qui se cite lui même

Un agent chargé d'exécuter une tâche pour un tiers produit souvent, en fin de mission, un rapport qui résume ce qu'il a fait. Ce rapport est rédigé par le même système qui a exécuté la tâche : il décrit son propre travail, avec la même autorité qu'il aurait pour décrire un travail réussi ou un travail raté. Un message de commit, un changelog ou un rapport d'agent décrivent une intention, jamais un état mesuré. La seule façon de savoir ce qui a réellement été produit consiste à ouvrir le résultat lui même, le fichier livré, la base modifiée, le tableau rempli, et non le texte qui prétend le décrire.

La skill vendue en lot, le connecteur et le concurrent

Une skill payante présentée comme un lot de fonctionnalités pose le même problème sous une autre forme. La fiche produit énumère des capacités, mais une fiche n'exécute rien : seule l'exécution réelle de chaque fonctionnalité, une par une, prouve qu'elle existe et fonctionne comme annoncé. Un connecteur de données affiche de son côté un compteur dans son tableau de bord, un nombre d'enregistrements prétendument synchronisés. Ce chiffre vient du même système qui effectue la synchronisation : il ne prouve rien de plus qu'un rapport d'agent. Le compte qui compte est celui obtenu par un export direct des mêmes données, recompté indépendamment du tableau de bord qui l'affiche. Une page concurrente qui affirme qu'une fonctionnalité manque chez vous suit la même logique inversée : l'affirmation vient d'une partie qui a intérêt à ce qu'elle soit crue, et seul un test mené sur le produit concurrent lui même, pas la lecture de sa page marketing, confirme ou réfute l'affirmation.

Le geste qui force la mesure

Dans les quatre cas, le correctif est identique : avant de citer un chiffre, une fonctionnalité ou un verdict venu d'un tiers, on ouvre cette source par une commande qui produit le même résultat de façon indépendante. L'exemple ci dessous fabrique ses propres données pour illustrer le principe, un chiffre rapporté par un système externe comparé à un compte obtenu directement.

node -e "
const rapporte = 1200;
const fixture = Array.from({ length: 947 }, (_, i) => ({ id: i }));
console.log('rapporte par le connecteur :', rapporte);
console.log('compte obtenu par export direct :', fixture.length);
"

Le chiffre rapporté et le compte obtenu directement diffèrent de 253 unités sur cet exemple fabriqué. Rien dans le seul affichage du connecteur n'aurait permis de le voir. Cette même exigence de réfutation active, plutôt que de confiance passée, est celle que pose déjà la recherche en éventail avec vérification contradictoire : une affirmation retenue est une affirmation qui a résisté à une tentative de la contredire, pas une affirmation qui n'a simplement pas été contestée.

Ce que cela coûte de ne pas vérifier

Le coût de la vérification directe est presque toujours inférieur au coût de l'erreur qu'elle évite. Recompter un export prend quelques minutes. Découvrir six mois plus tard qu'une part des enregistrements annoncés comme synchronisés ne l'était jamais coûte bien plus. La même proportion tient pour une fonctionnalité de skill jamais testée ou une comparaison concurrentielle jamais rejouée sur le produit réel.