Accueil / Vérifier ce qu'il rend

Compter toute la population, et nommer la mesure pour ce qu'elle capte

Mesurer sur les quelques cas remarqués par hasard plutôt que sur toute la population rend une conclusion pleine d'assurance et pourtant fausse, et cette même conclusion reste fausse si le nom qu'on donne au résultat dit autre chose que ce que l'instrument a réellement capté.

Deux réflexes distincts protègent contre la même erreur, conclure avant d'avoir vu l'ensemble des faits : compter la population entière avant de recommander un changement, et écrire ce qu'une mesure capte réellement avant de la nommer. Sauter l'un ou l'autre produit une conclusion pleine d'assurance qui peut être entièrement fausse tout en paraissant rigoureuse.

Compter avant de recommander

Repérer quelques cas qui enfreignent une convention et en tirer une recommandation générale, abandonner la convention entière, est un raisonnement séduisant et presque toujours prématuré. Mesurer la population complète raconte souvent une autre histoire : une large majorité des éléments suivait déjà la convention, de façon cohérente et délibérée : les quatre cas remarqués au départ ne représentaient qu'une fraction des onze éléments réellement non conformes sur l'ensemble de la population, un défaut plus étroit, sans rapport avec la convention elle même. Une convention massivement respectée est une décision que quelqu'un a prise exprès, pas un accident qui attend d'être corrigé. Et le fait qu'une équipe accepte d'avancer sur ce diagnostic ne valide que l'autorisation d'agir, jamais l'exactitude du diagnostic lui même : on peut consentir de bonne foi à corriger un mauvais compte.

La figure qui suit ce paragraphe illustre la même discipline sur un second exemple, un dossier de neuf fichiers fabriqué pour la démonstration, où un coup d'œil sur le premier fichier venu ne dit rien du compte réel :

$ mkdir -p /tmp/demo-v2m3l9
$ for i in 1 2 3 4 5 6 7; do echo '{"sources":["x"]}' > /tmp/demo-v2m3l9/lecon$i.json; done
$ for i in 8 9; do echo '{"sources":[]}' > /tmp/demo-v2m3l9/lecon$i.json; done
$ node -e "const fs=require('fs');const d='/tmp/demo-v2m3l9';const f=fs.readdirSync(d).filter(x=>x.endsWith('.json'));let a=0;f.forEach(x=>{const j=JSON.parse(fs.readFileSync(d+'/'+x));if(j.sources&&j.sources.length)a++});console.log(a+' sur '+f.length+' avec une source declaree');"
7 sur 9 avec une source declaree

Deux fichiers sur les neuf ont un champ source vide, et rien dans leur nom ni leur position ne le laissait deviner : il fallait les ouvrir un par un pour le savoir, exactement comme pour les quarante trois éléments du premier exemple.

Nommer une mesure pour ce qu'elle capte

Un graphique intitulé journée de travail peut, en réalité, mesurer autre chose : l'écart entre le premier et le dernier message envoyé dans la journée, en excluant silencieusement chaque heure passée loin du clavier entre les deux. Le chiffre n'est pas faux, il est mal nommé, ce qui est pire. Un chiffre faux finit par être remarqué et corrigé. Une étiquette fausse se propage sans bruit et contamine chaque conclusion qui s'appuie dessus, sans qu'un lecteur extérieur ait le moindre moyen de le voir en regardant simplement le titre. Le même piège touche tout signal indirect présenté comme s'il mesurait directement autre chose : une fréquence de majuscules plus élevée dans une série de messages a par exemple été baptisée signal de frustration croissante, alors que l'instrument ne capte, littéralement, qu'une fréquence de majuscules. La figure qui suit ce paragraphe reprend cet exemple et met en regard l'étiquette supposée et ce que l'instrument capte réellement. Où vous regardez détermine ce que vous trouvez repose sur le même manque de dénominateur que l'habitude de compter avant de conclure.

Avant de titrer tout graphique, toute tuile de tableau de bord, toute colonne, écrire en une phrase simple ce que l'instrument capte littéralement, puis vérifier que le titre dit exactement cela, rien de plus.