Boîte à outils anti-biais

Savoir qu'un biais existe ne protège presque jamais ; changer la procédure, si. Huit listes à imprimer ou à copier.

≈ 4 min de lectureLecture

En bref

Huit moments du travail, chacun avec cinq à six gestes concrets.
Chaque geste renvoie au biais qu'il combat et, le cas échéant, à la méthode détaillée.
Imprimable : cochez les cases en réunion de lancement, de revue ou de décision.

Sur cette page

Avant d'estimer
Avant un go / no-go ou une décision de continuer
Démonstration, preuve de concept, choix d'un fournisseur
En comité, en revue de conception, en réunion
Pour recruter ou évaluer une personne
Pour concevoir, documenter, choisir un composant
Pour comprendre le besoin du client
Après un incident ou un échec
Avec l'IA

Les fiches expliquent chaque biais ; cette page rassemble ce qu'on fait au bon moment. L'idée est de transformer les réflexes d'évitement en habitudes de procédure : on ne compte pas sur la vigilance de chacun, on change la façon de décider. Les trois méthodes les plus polyvalentes ont leur fiche : le pré-mortem, l'estimation par classe de référence et l'avocat du diable.

Avant d'estimer#

Écrire sa propre estimation avant d'entendre un chiffre, une enveloppe ou une date souhaitée (ancrage).
Estimer en fourchette (au mieux, probable, au pire), jamais en point unique (erreur de planification).
Chercher trois à cinq projets comparables et regarder leurs écarts réels (classe de référence).
Lister ce qui a retardé les derniers projets et le compter dans le plan (optimisme irréaliste).
Ne pas corriger l'estimation à la baisse parce qu'on connaît la loi de Hofstadter : prévoir un suivi et des points de réestimation (loi de Hofstadter).

Avant un go / no-go ou une décision de continuer#

Ne comparer que les coûts et bénéfices à venir : ce qui est déjà dépensé ne reviendra pas (coûts irrécupérables).
Avoir fixé dès le départ des critères d'arrêt et des jalons de validation (escalade d'engagement).
Conduire un pré-mortem : « le projet a échoué, pourquoi ? ».
Faire décider quelqu'un qui n'a pas engagé la dépense ni défendu le projet.
Se demander : « si nous partions de zéro aujourd'hui, ferions-nous ce choix ? » (statu quo, aversion à la perte).
Chiffrer le coût de l'inaction au même titre que celui du changement (biais d'omission).

Démonstration, preuve de concept, choix d'un fournisseur#

Faire choisir les cas de test par un tiers, sans les communiquer à l'avance (pensée désidérative, confirmation).
Exiger une contre-expertise indépendante avant que le dossier ne monte (autorité).
Distinguer ce qui a été vu de ce qui a été dit ; demander ce qui ferait échouer la solution.
Se méfier de la nouveauté pour elle-même : quel problème précis résout-elle (biais pro-innovation) ?
Confronter l'avis d'un expert à une base de comparaison chiffrée (biais de l'expert).

En comité, en revue de conception, en réunion#

Recueillir des avis écrits avant la discussion (pensée de groupe, effet d'entraînement).
Le décideur ou le plus ancien parle en dernier.
Désigner un avocat du diable et lui donner le temps d'argumenter.
Nommer une personne responsable de chaque action : « quelqu'un s'en occupera » ne suffit pas (effet spectateur).
Rendre les contributions individuelles identifiables (paresse sociale).
Vérifier le consensus : demander à chacun sa position, ne pas supposer l'accord (faux consensus).

Pour recruter ou évaluer une personne#

Écrire les critères avant de voir les candidats ou les résultats (effet de halo).
Utiliser un entretien structuré : mêmes questions, notes par critère, avant la discussion (primauté, ressemblance).
Consigner des faits dans la durée pour ne pas ne retenir que les derniers mois (récence).
Noter chaque personne par rapport aux critères, pas à celle qui précède (contraste).
Chercher d'abord l'explication par le contexte avant le trait de caractère (erreur fondamentale d'attribution).
Croiser deux indicateurs qui se contrarient (effet Goodhart) ; surveiller ses attentes (effet Pygmalion).

Pour concevoir, documenter, choisir un composant#

Faire relire la documentation par quelqu'un qui découvre le sujet (malédiction du savoir).
Comparer les options sur des critères fixés à l'avance, y compris les solutions venues de l'extérieur (« pas inventé ici »).
Faire relire le code ou l'architecture par quelqu'un qui ne l'a pas écrit (effet IKEA).
Demander : « quelle est la solution la plus simple qui fonctionne ? » (sur-ingénierie).
Se demander si l'outil maîtrisé est le bon, pas seulement le familier (effet marteau, fixation fonctionnelle).

Pour comprendre le besoin du client#

Partir du problème avant la solution ; poser des questions ouvertes (confirmation du besoin).
Observer le travail réel plutôt que se fier à la description qu'on en fait.
Remettre en cause le périmètre déjà spécifié : tient-il à sa valeur ou à l'effort passé (effet de dotation) ?
Fixer des objectifs communs de bout en bout, pas seulement par équipe (optimisation locale).
Traiter l'incertitude explicitement plutôt que de choisir ce qu'on connaît (aversion à l'ambiguïté).

Après un incident ou un échec#

Reconstituer ce qu'on savait à l'époque, pas ce qu'on sait maintenant (biais rétrospectif).
Chercher les causes sans chercher de coupable ; ne pas s'attribuer les succès et blâmer les circonstances (auto-complaisance).
Regarder aussi les échecs silencieux, pas seulement les succès visibles (biais de survie).
Rapporter l'incident à sa fréquence réelle, pas à sa visibilité (biais de disponibilité).
Tester les sauvegardes et les reprises avant d'en avoir besoin (biais de normalité).

Avec l'IA#

Chaque fiche contient des prompts prêts à l'emploi pour détecter, remédier ou atténuer un biais. Deux règles pour tous : demander explicitement l'avis contraire (l'IA a tendance à approuver ce qu'on pense déjà), et ne jamais lui confier seule la vérification de son propre travail. La page sur la courbe d'apprentissage de l'IA explique pourquoi.