Merci à Alexis Lebec, lead developer chez CosaVostra, pour cet apprentissage !

Je me suis retrouvé dans un écueil oh trop familier récemment et j’ai découvert le biais cognitif des coûts irrécupérables.

TL;DR

À l’instant T quand un projet patine, vaut-il mieux (financièrement, humainement, etc) :

1. finir ce qu’on a commencé,
2. repartir à 0,
3. tout arrêter.

Si on part du principe que toute ressource dépensée est irrécupérable, donc perdue (financière, humaine, etc), répondre à cette question devient incroyablement simple : je compare simplement un reste à faire entre deux options.

En pratique

Si j’ai dépensé 500€ pour deux billets d’avion non remboursables pour un week-end à Dublin, qu’au dernier moment on m’annonce que la météo sera exécrable et qu’on me propose un week-end chez un ami à la campagne, j’aurai naturellement tendance à quand même partir pour Dublin pour ne pas gâcher les 500€ déjà dépensés. Alors qu’il faudrait les considérer comme perdus (puisque non remboursables), et comparer le reste à dépenser (hôtels et sorties à Dublin versus rien chez mon ami) et le gain attendu (se balader sous la pluie battante versus de bonnes soirées au coin du feu).

Autre exemple hypothétique dans notre domaine. Un projet m’a déjà coûté 300 jours-hommes ; le finir me prendra une centaine de jours (j’ai sous-estimé la techno, la recette, l’environnement, peu importe) ; si je repartais de 0 sur une autre techno ou environnement ultra-maîtrisé, il me faudrait 80 jours pour tout refaire de A à Z. Le biais cognitif – tout à fait naturel – est de mettre dans la balance de cette décision les 300 jours-hommes déjà consommés afin de ne pas les gâcher. Or, en réalité, il faudrait que je compare les 100 jours pour finir aux 80 pour tout refaire.

En vrai, même si tout refaire me coûtait 100 jours – soit autant que de finir le projet initial – mais sur une techno que je maîtrise à 100%, le risque serait moindre si je partais sur cette option.

Ne rien gâcher

Ce qui a inspiré cette discussion – et donc cette découverte, c’est ceci. Nous développons beaucoup de projets internes chez CosaVostra, et ce, pour diverses raisons. Très souvent afin de réaliser une montée en compétences rapide sur une technologie ; parfois pour tester de nouveaux outils ; enfin, pour appliquer de nouveaux paradigmes et méthodes de conception.

Quelques exemples qui nous occupent actuellement :

• Une progressive web app de lecture de podcasts pour la communication interne d’un GAFAM — problématiques : vue.js, gestion de cache, intégration de flux Art19 ;
• SocialVault : un outil qui maximise les candidatures spontanées en limitant les frictions pour les candidats — problématiques : création d’un addon javascript ultra-light, intégration de l’API Dropbox, parsing d’une boîte mail et création d’adresses emails à la volée ;
• AdBoard : outil de monitoring de campagnes éditoriales développé avec Usbek & Rica ;
• Un timesheetinterne nous permettant de tracker les temps vendus et consommés par projet — et donc la rentabilité de l’agence en temps réel.

Ce dernier projet (appelons-le TimeTime !) est typiquement le genre de projet “caprice” d’agence 🙂 On a décidé de “refactorer” (reconstruire) un outil de time-tracking développé il y a 3 ans en Meteor.js. Cet outil nous permet de suivre le temps que les employés passent sur leurs projets. Un mélange de Toggl, Harvest, et des 150 autres outils de time-tracking qui existent déjà. En revanche, parfaitement adapté à notre agence qui vend du temps-homme, léger, simple, pas usine à gaz, etc. Super pratique.

Pour TimeTime, nous sommes partis sur un modèle avec backend Firebase, front React.js, gestion de droits aux petits oignons, utilisation optimale du client-side et server-side pour les données. Mais c’était pas ça le problème. Le problème, c’est d’abord que le projet – estimé entre 20 et 30 jours hommes – est passé pendant 1 an après les projets clients en terme de priorité. Ensuite, il est également passé de mains en mains en interne (devs, projet, design), pour servir de terrain de jeu (Vue.js, React, etc). On est déjà à 50 jours-hommes consommés.

Au final, au moment de la recette, on réalise que le débug prendrait une vingtaine de jours-hommes. Et surtout, que les évolutions seraient de véritables casse-tête. Damn it.

J’interroge mon associé et CTO, Pierre. Les principales qualités de Pierre sont d’être pragmatique et cohérent. On en discute aussi avec Alexis, lead dev, et on arrive à la conclusion que pour tout refaire avec un coeur en API Symfony et un front HTML ultra simple, une quinzaine de jours suffirait.

Au final

On a tout re-développé en 16 jours – API Symfony, SQL pour la base, front HTML. Il y a même plus de fonctionnalités que ce qu’on avait développé initialement, et le “socle” est plus solide pour les itérations évolutives.

Bilan : on n’a pas perdu 50 jours – ils nous ont servi à appréhender et nous faire la main sur de nouvelles technos (gains, limites, contraintes). Qu’on maîtrise aujourd’hui mieux que beaucoup d’autres agences.

Merci !

Ne ratez surtout pas cette vidéo de David Louapre si le sujet vous intéresse, ni ses livres pour creuser un peu plus. David est certainement plus pédagogue que moi si je n’ai pas été clair 🙂

Mais attention ….

Crucial : en société, quand vous parlerez de ce sujet et cet article, pensez à la liaison “z” entre “coûts” et “irrécupérables”. Sinon ça peut être mal compris 🙂

Répétez “les coûts irrécupérables” sans liaison 5 fois à haute voix, vous comprendrez….

Pour en savoir plus sur l’agence, n’hésitez pas à nous suivre sur LinkedIn, Instagram et Facebook ! Sinon, vous pouvez directement nous contacter !