Blog

En psychologie comportementale, l’effet IKEA est ce que l’on appèle un biais cognitif, une déviation systématique de la pensée logique et rationnelle par rapport à la réalité.

Mis en avant en 2011 par les études de Michael Norton, Daniel Mochon et Dan Ariely (mais déjà observé par Leon Festinger en 1957), ce biais de jugement entraine les consommateur·rice·s à accorder une valeur disproportionnée aux produits qu’ils ou elles ont partiellement créés.

Les travaux de Norton, Mochon et Ariely s’appuient sur des études antérieures relatives à la justification de l’effort.

Vous êtes peut-être en train d’attendre que je fasse le lien avec le développement.

Figurez-vous que l’on rencontre l’effet IKEA très souvent lorsque l’on écrit du code … ou plutôt lorsque l’on doit l’effacer.

Vous avez probablement déjà constaté cette réticence, à la limite de l’énervement (et parfois au delà), lorsque l’on retire une fonctionnalité déjà implémentée. Plus l’effort fourni pour cette implémentation est important, plus l’agacement va être grand.

Souvenez vous la dernière fois où l’on est venu vous demander de supprimer une fonctionnalité car on a constaté qu’elle n’apportait rien aux utilisateurs et utilisatrices, alors que vous aviez passé 4 jours à écrire le super algo qu’il y a derrière.

La bonne nouvelle, c’est que cette réaction est naturelle. Ça n’est ni le ou la PO qui n’a aucune considération pour votre travail, ni vous qui avez produit un mauvais travail.

Toute naturelle que soit cette réaction, il faut savoir la gérer. La première étape pour ça, c’est de comprendre qu’il s’agit d’un mécanisme normal du cerveau. Si vous êtes arrivé·e jusqu’à ce niveau de l’article, vous êtes au courant.

Un bon réflexe pour limiter l’effet IKEA, c’est d’adopter un vision globale du projet, de comprendre la décision d’en retirer une partie, de réaliser que finalement la base de code globale est mieux sans. C’est plus compliqué quand la personne qui a pris le code est aussi celle qui doit prendre la décision de la retirer car il n’y a pas forcément d’élément déclencheur permettant de faire cette bascule entre vison globale et vision spécifique, il faut prendre l’habitude de faire régulièrement cette bascule (c’est un peu le rôle du lead dev).

Refactorer régulièrement son travail, c’est aussi habituer son cerveau à supprimer souvent des parties du code, et donc d’avoir moins de réticences quand il faut le faire pour d’autres raisons que la qualité de l’architecture.

On peut également limiter l’effet IKEA en pratiquant l’Egoless Programming. Moins on sera personnellement attaché au code que l’on écrit, plus il sera facile de s’en séparer.