Biais cognitifs et développement : pourquoi notre cerveau nous joue des tours
S'acharner sur un bug imaginaire, refuser de jeter une mauvaise architecture ou sous-estimer un risque : quand notre cerveau sabote nos projets techniques sans qu'on s'en aperçoive ;)
On a souvent tendance à imaginer le développement logiciel et l'administration système comme des disciplines de pure logique : des conditions if/else, des architectures réseau carrées, des scripts déterministes. Soit ça compile et ça tourne, soit ça plante.
Pourtant, derrière le clavier, c'est toujours un cerveau humain qui prend les décisions. Et ce cerveau adore prendre des raccourcis inconscients : les fameux biais cognitifs.
Ces réflexes mentaux ont été bien utiles à nos ancêtres pour réagir vite face aux prédateurs, mais face à une pile de logs ou à un choix d'architecture serveur, ils peuvent nous faire perdre des heures (voire des jours) sur de fausses pistes.
Voici un tour d'horizon des biais les plus fréquents en informatique, et comment les déjouer dans la pratique.
1. Le biais de confirmation : le tunnel du débugger
C'est probablement le biais le plus universel chez les développeurs : on ne cherche que les indices qui valident notre première intuition, en ignorant tout le reste.
Le cas classique :
Vous déployez un service, il est inaccessible. Vous êtes absolument convaincu que le problème vient du pare-feu ou d'un routage réseau capricieux. Vous passez deux heures à vérifier les règles iptables, à tester des traceroute et à modifier la configuration du reverse proxy... alors que la deuxième ligne du fichier de log indiquait clairement qu'une variable manquait dans le fichier .env.
La parade :
- Formulez l'hypothèse inverse : demandez-vous activement : « Si mon intuition était complètement fausse, qu'est-ce qui pourrait expliquer ce comportement ? »
- La méthode du canard en plastique (Rubber Duck Debugging) : expliquer le problème ligne par ligne à un objet (ou un collègue) force le cerveau à sortir du mode intuitif pour repasser en mode analytique.
- Lisez les logs du début à la fin, sans sauter les lignes que vous jugez d'avance « sans importance ».
2. Le piège des coûts irrécupérables (Sunk Cost Fallacy)
« J'y ai déjà passé trois jours entiers, je ne vais pas abandonner maintenant ! »
C'est la tendance à s'entêter dans une mauvaise direction simplement parce qu'on a déjà investi du temps, de l'énergie ou de l'argent dedans.
Le cas classique :
Vous avez commencé à monter une stack ultra-complexe avec quatre conteneurs, deux bases de données et un orchestrateur lourd pour un besoin au départ tout simple. Rien ne s'emboîte correctement, c'est fragile, mais vous refusez de tout jeter pour écrire un script autonome de 30 lignes parce que cela reviendrait à « admettre » que vous avez perdu trois jours.
La parade :
- Le code n'a pas d'ego : le temps passé est déjà perdu, qu'on continue ou qu'on s'arrête. La seule question qui compte est : « Aujourd'hui, quelle est la solution la plus simple et la plus maintenable pour avancer ? »
- Savoir supprimer du code est une compétence : les meilleurs refactorings sont souvent ceux où l'on supprime des centaines de lignes superflues.
3. L'effet Dunning-Kruger : l'illusion de maîtrise
Moins on maîtrise un sujet complexe, plus on a tendance à surestimer ses compétences. À l'inverse, plus on progresse, plus on mesure l'immensité de ce qu'il reste à apprendre.
Confiance
▲
│ "C'est hyper facile !"
│ ▲ (Montée de l'illusion)
│ / \
│ / \
│ / \ "En fait, c'est bien plus complexe..."
│ / ▼ (Vallée de l'humilité)
│ / \__________/‾‾‾‾‾► Véritable maîtrise
└────────────────────────────────────────► Compétence réelle
Le cas classique :
Après avoir réussi à lancer son premier serveur et à ouvrir deux ports, on se sent capable de monter une infrastructure de production complète sans sauvegardes automatisées ni durcissement de sécurité. C'est généralement là que survient le premier crash sévère ou la première intrusion.
La parade :
- La modestie technique : partez toujours du principe qu'un système finira par tomber en panne ou faire l'objet d'une fausse manipulation.
- La règle 3-2-1 pour les sauvegardes et le principe de moindre privilège doivent être en place dès le premier jour, quel que soit votre niveau de confiance.
4. Le biais d'optimisme en cybersécurité : « Pourquoi on m'attaquerait moi ? »
C'est l'erreur de croire que le risque ne concerne que les autres (les grandes entreprises du CAC 40 ou les banques).
Le cas classique :
Laisser un port SSH ouvert avec un mot de passe simpliste ou une interface d'administration exposée sans authentification multifacteur (MFA), sous prétexte que son serveur personnel ou son homelab « n'intéresse personne ».
En réalité, les attaquants humains ne ciblent pas votre machine en particulier : ce sont des bots et des scripts automatisés qui scannent aveuglément l'intégralité d'Internet 24h/24. Si une porte est ouverte, elle sera franchie dans les minutes qui suivent.
La parade :
- Considérer toute machine connectée à Internet comme une cible par défaut.
- Fermer tout ce qui n'a pas besoin d'être public et passer systématiquement par des clés SSH ou un VPN (type WireGuard).
5. La loi de Hofstadter et l'illusion de planification
« Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter. » — Douglas Hofstadter
Nous avons tous tendance à sous-estimer systématiquement le temps nécessaire pour accomplir une tâche technique, parce que notre esprit imagine le scénario idéal où aucun imprévu ne survient.
Le cas classique :
« J'en ai pour une petite heure histoire de migrer la base et de relancer le service. » ➔ 6 heures plus tard, un problème de version de bibliothèque vous bloque encore.
La parade :
- Découpez vos chantiers en étapes minuscules et testables indépendamment.
- Multipliez vos estimations par deux : cela laisse la marge nécessaire pour gérer les inévitables imprévus sans stress.
Synthèse des biais et des réflexes à adopter
| Biais cognitif | Manifestation en informatique | Le réflexe salvateur |
|---|---|---|
| Confirmation | S'enfermer dans une fausse piste de débug. | Lire tous les logs et tester l'hypothèse inverse. |
| Coûts irrécupérables | S'entêter sur une usine à gaz bancale. | Ne pas hésiter à jeter du code pour repartir sur du simple. |
| Dunning-Kruger | Sous-estimer la complexité d'une techno. | Rester humble, documenter et blinder ses sauvegardes. |
| Optimisme / Invulnérabilité | Négliger la sécurité sur un serveur perso. | Se rappeler que les bots scannent tout le monde. |
| Planification | « J'en ai pour 30 minutes ». | Découper petit et doubler ses marges de temps. |
En résumé
Avoir des biais cognitifs ne signifie pas qu'on est un mauvais développeur : c'est simplement le fonctionnement normal du cerveau humain.
L'important est d'apprendre à reconnaître ces moments où notre intuition commence à nous enfermer dans un tunnel. Savoir faire une pause de 10 minutes, prendre un café et poser son raisonnement à plat permet souvent de résoudre en 30 secondes un problème sur lequel on butait depuis deux heures ;)