Les biais cognitifs sont des tendances systématiques susceptibles d’influencer notre manière de percevoir une situation, d’évaluer une probabilité, de mémoriser une information ou de prendre une décision.
Ils sont souvent présentés comme des « bugs du cerveau ». L’image est amusante, mais un peu injuste : notre esprit utilise constamment des heuristiques, c’est-à-dire des raccourcis permettant de décider rapidement sans analyser chaque problème comme une thèse de doctorat.
La plupart du temps, cette économie cognitive est extrêmement utile. Le problème apparaît lorsque le raccourci fonctionne mal dans le contexte rencontré et produit une erreur prévisible.
Un biais cognitif n’est pas une preuve de stupidité. C’est précisément parce que notre cerveau doit décider avec un temps, une attention et des informations limités qu’il utilise des raccourcis — parfois brillants, parfois beaucoup moins.
Heuristique, biais et rationalité limitée
Une heuristique est une stratégie simplifiée : au lieu d’examiner toutes les possibilités, nous utilisons quelques indices jugés pertinents. Cela permet de prendre rapidement des milliers de décisions quotidiennes sans recalculer l’univers à chaque fois.
Un biais cognitif apparaît lorsqu’un mécanisme de jugement conduit de manière relativement systématique à s’écarter d’un critère pertinent : probabilités, faits disponibles, logique, objectifs déclarés ou qualité réelle des preuves.
Il faut cependant éviter de transformer chaque mauvaise décision en « biais ». Une personne peut simplement manquer d’informations, faire une erreur de calcul ou choisir volontairement selon des préférences différentes des nôtres.
La notion de rationalité limitée est ici importante : nous décidons avec une quantité limitée de temps, de connaissances et de capacité cognitive. L’être humain n’est pas un solveur mathématique omniscient. Il doit produire une réponse suffisamment bonne avant la fin de la réunion.
Dix biais cognitifs particulièrement utiles à connaître
| Biais | Mécanisme général | Exemple informatique |
|---|---|---|
| Confirmation | Privilégier les informations compatibles avec une croyance préalable | Être convaincu que le dernier patch est responsable d’une panne et ne rechercher que les logs allant dans ce sens |
| Représentativité | Juger selon la ressemblance avec un prototype ou stéréotype | Attribuer immédiatement un trafic inhabituel à une attaque parce qu’il « ressemble » à un incident déjà rencontré |
| Ancrage | Accorder trop de poids à une première valeur ou information | Continuer à estimer un projet autour de « trois jours » parce que quelqu’un a lancé ce chiffre en début de réunion |
| Disponibilité | Surestimer ce qui vient facilement à l’esprit | Surévaluer le risque d’un ransomware après un incident très médiatisé et négliger des pannes beaucoup plus fréquentes |
| Statu quo | Préférer l’option déjà en place | Conserver une configuration obsolète uniquement parce qu’elle « fonctionne depuis dix ans » |
| Dunning-Kruger | Mauvaise calibration entre performance réelle et auto-évaluation, particulièrement marquée chez certains faibles performeurs | Sous-estimer massivement la complexité d’une migration après quelques heures de découverte du sujet |
| Survivant | Étudier uniquement les cas encore visibles | Analyser uniquement les startups technologiques ayant réussi pour déterminer « la recette du succès » |
| Récence | Donner un poids excessif aux événements les plus récents | Déclarer un serveur instable parce qu’il vient de connaître son premier incident en deux ans |
| Optimisme | Sous-estimer la probabilité ou l’impact des problèmes pour soi-même | Planifier une migration sans marge parce que « normalement tout devrait passer » |
| Regroupement | Percevoir des motifs significatifs dans des fluctuations aléatoires | Chercher une mystérieuse cause commune derrière trois incidents simplement parce qu’ils se sont produits à des heures proches |
Confirmation, représentativité et disponibilité : trois pièges de l’information
Le biais de confirmation
Nous avons tendance à rechercher, interpréter ou mémoriser plus facilement les éléments compatibles avec ce que nous pensons déjà.
Imaginons qu’un administrateur soit convaincu qu’une mise à jour Windows a provoqué les BSOD apparus sur une machine. Il remarque immédiatement que le premier crash s’est produit deux jours après le patch et interprète chaque événement suivant dans cette direction.
Il peut alors négliger que la RAM a été remplacée la même semaine et que les dumps montrent des erreurs mémoire très différentes.
Une méthode de diagnostic plus solide consiste à demander :
- quelles observations soutiennent mon hypothèse ;
- quelles observations devraient être présentes si elle était vraie ;
- quelles observations pourraient la réfuter ;
- quelles autres hypothèses expliquent les mêmes symptômes.
Autrement dit : chercher volontairement comment prouver que l’on a tort est souvent plus instructif que chercher une dixième raison d’avoir raison.
Le biais de représentativité
La représentativité consiste à évaluer une situation selon sa ressemblance avec un modèle mental ou un stéréotype plutôt que selon les probabilités de base.
On décrit par exemple Julie comme silencieuse, passionnée de littérature et heureuse au milieu des archives. Beaucoup imagineront spontanément une bibliothécaire plutôt qu’une personne exerçant un métier beaucoup plus courant.
Le problème n’est pas que le portrait soit incompatible avec le métier de bibliothécaire. Le problème est que notre jugement peut ignorer le taux de base : combien existe-t-il réellement de personnes dans chacune des catégories ?
En informatique, le même mécanisme apparaît lorsqu’un symptôme ressemble tellement à une panne célèbre que l’on oublie de vérifier les causes statistiquement plus fréquentes.
L’heuristique de disponibilité
Lorsqu’un événement est spectaculaire, récent ou très médiatisé, il revient facilement en mémoire. Cette facilité de rappel peut être confondue avec une forte probabilité.
Un administrateur venant de lire plusieurs articles sur les attaques de la chaîne d’approvisionnement peut commencer à attribuer le moindre comportement étrange à un compromis logiciel sophistiqué, alors que les causes les plus courantes restent parfois une mauvaise configuration, un disque plein ou un certificat expiré.
Ce biais ne signifie pas qu’il faut ignorer les scénarios rares. Il rappelle seulement qu’un souvenir frappant ne constitue pas une statistique.
Ancrage, statu quo et récence : quand le contexte décide à notre place
Le biais d’ancrage
Une première valeur peut influencer fortement les estimations suivantes, même lorsqu’elle possède peu de justification.
Si quelqu’un annonce au début d’une réunion :
« Cette migration devrait prendre trois jours. »
les estimations suivantes risquent de graviter autour de trois jours : deux, quatre, peut-être cinq. Il devient psychologiquement plus difficile de proposer trois semaines, même si l’analyse détaillée conduit à cette conclusion.
Une technique simple consiste à demander aux participants de produire leurs estimations indépendamment avant de les partager. On réduit ainsi l’influence du premier chiffre prononcé par la personne ayant parlé le plus vite.
Le biais de statu quo
Une solution déjà en place possède un avantage psychologique : elle est connue. Ses défauts sont familiers, ses contournements documentés quelque part dans un wiki et personne ne souhaite découvrir de nouveaux problèmes.
Cela peut conduire à maintenir :
- un logiciel en fin de vie ;
- une règle firewall inutile ;
- un protocole ancien ;
- une procédure manuelle fragile ;
- un mot de passe partagé dont l’origine se perd dans les archives.
Le statu quo n’est pourtant pas toujours irrationnel. Une migration possède elle-même des coûts et des risques. Le biais apparaît lorsque l’option actuelle bénéficie d’un traitement privilégié simplement parce qu’elle est actuelle.
Le biais de récence
Les événements récents prennent facilement une importance disproportionnée.
Un service ayant fonctionné correctement pendant 800 jours puis connu deux incidents successifs peut soudainement être décrit comme « constamment instable ». À l’inverse, trois semaines sans incident peuvent donner l’impression qu’un problème chronique est réglé alors qu’aucune correction durable n’a été apportée.
La solution consiste souvent à replacer les événements dans une série temporelle plus longue : fréquence, tendance, saisonnalité et historique complet.
Dunning-Kruger : beaucoup plus subtil que le mème
L’effet Dunning-Kruger est probablement l’un des biais psychologiques les plus cités et les plus mal résumés sur Internet.
Dans les travaux classiques, des participants réalisent une tâche puis estiment leur propre performance, souvent relativement aux autres. Les personnes obtenant les résultats les plus faibles ont tendance à surestimer fortement leur classement relatif.
L’explication proposée par Kruger et Dunning repose notamment sur la métacognition : certaines connaissances nécessaires pour accomplir correctement une tâche sont également nécessaires pour reconnaître ses propres erreurs.
Un débutant peut donc connaître suffisamment un sujet pour agir, mais pas encore suffisamment pour identifier tout ce qu’il ignore.
Cela ne signifie cependant pas :
« Toute personne incompétente est arrogante et tout expert souffre du syndrome de l’imposteur. »
Les meilleurs performeurs évaluent généralement mieux leur performance que les plus faibles, même si certaines expériences observent aussi une sous-estimation de leur position relative. Par ailleurs, une partie de la forme statistique de l’effet a fait l’objet de discussions scientifiques.
L’effet Dunning-Kruger doit donc servir à comprendre les limites de l’auto-évaluation, pas à diagnostiquer les personnes avec lesquelles on n’est pas d’accord.
Et il existe un paradoxe pratique délicieux : connaître le nom « Dunning-Kruger » ne confère aucune immunité contre Dunning-Kruger.
Survivant, optimisme et clustering : les statistiques maltraitées
Le biais du survivant
Le biais du survivant apparaît lorsque l’on analyse les éléments qui ont réussi à passer une sélection en oubliant ceux qui ont disparu avant d’atteindre notre échantillon.
On peut par exemple étudier dix entrepreneurs devenus milliardaires et constater qu’ils ont pris des risques, travaillé énormément et ignoré certains conseils conventionnels.
Le problème est que des milliers d’entrepreneurs ayant adopté exactement les mêmes comportements ont pu échouer et devenir invisibles dans l’analyse.
Dans l’IT, le phénomène apparaît lorsqu’on demande :
« Pourquoi ces cinq projets open source ont-ils connu un succès mondial ? »
sans examiner les dizaines de milliers de projets similaires abandonnés après trois commits et un README contenant « TODO ».
Le biais d’optimisme
Nous avons tendance à croire que certains événements négatifs sont moins susceptibles de nous concerner et que nos projets se dérouleront mieux que ne le suggère l’expérience.
Dans un projet informatique, cela donne facilement :
- aucune marge dans le planning ;
- rollback non testé ;
- sauvegarde supposée fonctionnelle ;
- migration prévue juste avant le week-end ;
- phrase « normalement, ça devrait passer » répétée plusieurs fois.
Une technique utile est le pré-mortem : imaginer que le projet a échoué, puis demander quelles causes plausibles ont conduit à cet échec. Cela force l’équipe à envisager des scénarios qu’un plan optimiste aurait facilement écartés.
Le biais de regroupement
Notre cerveau excelle à détecter des motifs. Cette capacité est extrêmement utile — jusqu’au moment où il en détecte dans du bruit.
Trois serveurs tombent en panne autour de 14 h pendant plusieurs jours. Une cause commune paraît immédiatement probable.
Il peut effectivement exister un job de sauvegarde à 14 h. Mais il faut le démontrer. Trois événements rapprochés ne suffisent pas à établir une causalité.
Avant d’invoquer un mystérieux démon temporel, vérifiez les logs, les métriques et les tâches planifiées. Le démon porte souvent le nom beaucoup moins impressionnant de backup-full.sh.
Comment réduire l’influence des biais ?
La première difficulté est qu’un biais est souvent plus facile à reconnaître chez les autres que chez soi. La simple connaissance du catalogue des biais améliore donc le vocabulaire, mais ne garantit pas de meilleures décisions.
Les méthodes les plus utiles cherchent à modifier le processus de décision plutôt qu’à demander au cerveau de « ne plus être biaisé ».
| Méthode | Intérêt |
|---|---|
| Chercher une preuve contraire | Réduit l’effet de confirmation |
| Consulter les taux de base | Limite les jugements purement représentatifs |
| Estimer indépendamment | Réduit l’ancrage collectif |
| Utiliser plusieurs hypothèses | Évite de s’enfermer trop tôt dans un diagnostic |
| Définir les critères à l’avance | Réduit les justifications construites après coup |
| Tenir un journal de décision | Permet de comparer prévisions et résultats réels |
| Faire un pré-mortem | Combat l’excès d’optimisme |
| Utiliser des données historiques | Réduit disponibilité et récence |
| Demander une revue indépendante | Introduit un point de vue moins engagé dans la décision initiale |
Exemple : diagnostiquer une panne sans tomber amoureux de sa première hypothèse
Une application devient lente après une mise à jour. La première intuition est que la mise à jour en est responsable.
Au lieu de commencer immédiatement un rollback, une méthode structurée peut consister à :
- noter l’hypothèse « mise à jour » sans la considérer comme acquise ;
- examiner CPU, mémoire, stockage, réseau et base de données ;
- comparer avec les métriques antérieures ;
- chercher ce qui a changé à la même période ;
- définir les observations qui confirmeraient ou réfuteraient chaque hypothèse ;
- tester la modification la moins risquée permettant de les départager.
La différence paraît banale, mais elle transforme :
« Je pense savoir ce qui s’est passé. »
en :
« Voici plusieurs explications et voici comment je vais essayer de les départager. »
C’est généralement une nette amélioration méthodologique.
L’automatisation n’est pas un vaccin contre les biais
Automatiser une décision peut éliminer certaines variations humaines. Une règle déterministe appliquée de la même manière à chaque dossier ne se fatigue pas, ne s’énerve pas et n’a pas passé une mauvaise nuit.
Mais un système automatisé peut hériter des biais présents dans :
- les données d’apprentissage ;
- les variables sélectionnées ;
- les critères définis par les concepteurs ;
- les objectifs de l’organisation ;
- l’échantillon utilisé pour évaluer le système.
Il peut ensuite les appliquer avec une régularité et une vitesse impossibles à atteindre pour un humain.
Automatiser une décision ne supprime pas nécessairement le biais. Cela peut simplement transformer un biais artisanal en biais industriel.
Les outils automatisés sont donc particulièrement intéressants lorsqu’ils s’accompagnent de mesures, d’audits, de contrôles et de mécanismes permettant de remettre leurs résultats en question.
Conclusion : mieux raisonner plutôt que chercher à devenir parfaitement rationnel
Les biais cognitifs ne signifient pas que l’être humain serait fondamentalement incapable de raisonner. Ils montrent plutôt que notre jugement dépend du contexte, de l’information disponible, de nos attentes et des raccourcis nécessaires pour décider rapidement.
Les connaître permet surtout de repérer certaines situations dangereuses :
- être trop certain d’une première hypothèse ;
- ignorer les statistiques parce qu’un exemple spectaculaire vient immédiatement à l’esprit ;
- conserver une mauvaise solution uniquement parce qu’elle existe déjà ;
- surestimer sa maîtrise d’un domaine encore nouveau ;
- tirer une règle générale uniquement des réussites visibles ;
- voir une tendance dans quelques événements rapprochés ;
- supposer qu’un projet se déroulera sans incident parce que cette fois « on a bien préparé ».
L’objectif réaliste n’est pas de devenir une machine parfaitement rationnelle. Aucune checklist ne supprimera complètement nos intuitions, nos préférences ou nos erreurs d’évaluation.
Une meilleure approche consiste à construire des processus qui obligent périodiquement notre première intuition à produire ses preuves.
La question la plus utile n’est peut-être pas « Quel biais affecte cette personne ? », mais « Qu’est-ce qui pourrait me faire changer d’avis ? »
Et si la réponse est « absolument rien », le diagnostic cognitif vient peut-être déjà de commencer.