← Retour au blog

Limiter les biais dans les tableaux de bord

Lucian BLETAN

Un bon dashboard aide à décider sans détour. Les biais cognitifs (ancrage, cherry-picking) et les pièges de modélisation (moyennes trompeuses, axes tronqués) peuvent déformer la lecture. Anticiper ces écueils change la qualité des décisions. L’objectif: présenter ce qui compte, montrer l’incertitude, et expliciter les limites.

prérequis

  • Glossaire partagé des KPIs (définitions, formules, périmètre).
  • Accès aux tailles d’échantillon et aux dates de changement de méthode.
  • Processus de revue avant publication (pair review rapide).

aperçu rapide

  • Afficher la distribution, pas seulement la moyenne.
  • Indiquer la taille d’échantillon et la période.
  • Signaler toute rupture de méthode ou de périmètre.
  • Éviter les axes trompeurs et les zooms non annoncés.
  • Distinguer corrélation et causalité, proposer un test quand c’est ambigu.
  • Rédiger des titres qui disent l’essentiel, sans dramatiser.

tutoriel pas-à-pas

étape 1: exposer l’incertitude

Montrez l’intervalle, les percentiles ou au minimum la taille d’échantillon.

-- tailles par segment et période (30 derniers jours)
SELECT segment, COUNT(*) AS n, ROUND(AVG(metric),2) AS avg_metric
FROM events
WHERE ts >= CURRENT_DATE - INTERVAL '30 day'
GROUP BY segment
ORDER BY n DESC;

étape 2: afficher la distribution

Une médiane et un p90 apportent plus qu’une moyenne seule.

import numpy as np
x = np.array([1,2,2,3,4,5,8,13,21])
print("mediane:", np.percentile(x,50), "p90:", np.percentile(x,90))

étape 3: clarifier titres, axes et unités

Un titre doit pouvoir se lire seul. Indiquez unités, période, périmètre et toute rupture.

titre: "temps de réponse médian stable sur 8 semaines"
sous-titre: "FR, web, 2020-08 à 2020-10"
note: "changement de routage le 2020-09-14"

étape 4: prévenir le cherry-picking

Fixez des règles d’inclusion avant l’analyse et documentez-les.

règles:
- inclure les segments avec n >= 200
- exclure les événements de test
- figer la méthode pour la durée du suivi

étape 5: proposer un test quand c’est ambigu

Si l’écart peut venir de plusieurs causes, proposez un test simple.

-- échantillonnage A/B minimal (allocation 50/50)
INSERT INTO experiments_allocation(user_id, variant)
SELECT user_id, CASE WHEN RANDOM() < 0.5 THEN 'A' ELSE 'B' END
FROM candidates
WHERE ts >= CURRENT_DATE - INTERVAL '7 day';

exemples

cas: lecture honnête d’un KPI en croissance

avant:
- titre: "conversion en forte hausse"
- graph: moyenne seule, axe tronqué à 90%

après:
- titre: "conversion +0,8 pt (médiane), p90 inchangé"
- graph: médiane + percentiles, axe à 0, unité en %
- note: "périmètre mobile uniquement depuis le 10"
-- contrôle de rupture de méthode
SELECT change_date, field, old_value, new_value
FROM kpi_changelog
WHERE kpi = 'conversion';

erreurs courantes et solutions

  • moyenne seule -> illusions -> ajouter médiane, percentiles et n
  • axes tronqués -> effets grossis -> commencer à 0 quand pertinent; sinon indiquer la rupture
  • périmètre mouvant -> comparaisons faussées -> note visible et dates de changement
  • petits n -> sur-interprétation -> avertir et regrouper si nécessaire
  • corrélation prise pour causalité -> décisions hâtives -> formuler un test, mesurer l’effet
  • langage dramatique -> biais d’interprétation -> titres factuels, verbes sobres

faq

  • faut-il tout montrer ? Non. Montrez ce qui aide la décision, mais sans cacher l’incertitude.
  • que faire quand la donnée est incomplète ? Le dire explicitement et proposer un plan de correction, ou repousser la conclusion.
  • comment lutter contre le cherry-picking ? Règles d’inclusion fixées avant analyse, et publication des critères avec le graph.

tags