Les erreurs de raisonnement dans le commerce numérique - 1ère partie

Malheureusement, la nature de la pensée humaine n'est pas nécessairement rationnelle et des erreurs de raisonnement que nous préférerions éviter se glissent souvent dans notre esprit. Dans le contexte du développement de logiciels également, il existe de nombreuses erreurs de raisonnement qui peuvent conduire à des hypothèses erronées et à des décisions parfois assez coûteuses. Dans cet article, nous donnons des conseils sur la manière de reconnaître ces erreurs de raisonnement et, dans le meilleur des cas, de les éviter. 

L'idée d'écrire un blog sur le thème des erreurs de raisonnement dans le développement de logiciels m'est venue en lisant le livre de Rolf Dobelli intitulé "Mieux savoir bien vivre". Ce livre contient 52 erreurs de raisonnement qui m'ont permis de faire des découvertes passionnantes de manière divertissante et compréhensible. 

Comme ces erreurs de raisonnement sont assez nombreuses dans le "digital business", nous avons divisé le blog en deux parties. Voici donc les six premières - la deuxième partie suivra dans un avenir proche.

1. Le piège de la surestimation de soi : Overconfidence Bias

Se surestimer est une erreur de raisonnement que nous rencontrons souvent dans le développement d'applications comme dans la vie quotidienne. On utilise une app ou un autre logiciel connu et on pense "je peux faire beaucoup mieux !" Cette erreur de jugement n'arrive pas seulement à nos clients, mais aussi à nous-mêmes, notamment lorsqu'il s'agit d'évaluer précisément les coûts d'un projet, sa durée ou le succès potentiel de produits et services numériques.

Exemples de surestimation de soi dans les projets logiciels

Il n'est pas rare que nous recevions des demandes de développement d'applications avec des déclarations telles que : "Je sais comment on pourrait par exemple améliorer Facebook ou Instagram, il suffirait d'ajouter ceci ou cela et de ne pas collecter de données. Veuillez me donner un prix pour cette meilleure version de Facebook".

Beaucoup de gens ne réalisent pas que Facebook a écrit plus de 60 millions de lignes de code et qu'il faut un très grand nombre d'utilisateurs pour que la plateforme fonctionne, afin d'offrir une valeur ajoutée dans le contexte de la communauté. 

Non seulement nos clients surestiment leurs connaissances et leurs capacités, mais nous aussi, en tant que chefs de projet, développeurs de logiciels et spécialistes du design, souffrons parfois de ce phénomène. Lorsqu'il s'agit d'estimer de manière réaliste le temps de développement d'un nouveau projet de logiciel, il n'est pas rare que nous partions du principe que tous les travaux peuvent être effectués de manière efficace et efficiente, au lieu de partir du cas réaliste où des défis imprévisibles apparaissent dans presque chaque projet et nécessitent alors plus de temps que prévu. 

Dans le cas de l'estimation de la charge de travail, s'ajoute à l'effet de surestimation la "tendance à l'incitation et à la super-réponse", c'est-à-dire la tendance à réagir aux systèmes d'incitation en maximisant le bénéfice personnel. Les chances de décrocher un nouveau contrat sont ressenties comme plus élevées lorsque l'estimation est plus serrée que lorsque nous prenons en compte une réserve importante pour les imprévus. Dans le pire des cas, cela peut conduire à une déception des deux côtés. Pour l'équipe de développement, cela entraînera des modifications de la planification et des discussions ; du point de vue du client, cela peut entraîner des retards et des coûts supplémentaires, donc une mauvaise expérience client.

Possibilités de réduire l'effet de surestimation :

• Partir d'un scénario pessimiste plutôt qu'optimiste.

• Diversité : les personnes différentes évaluent les choses différemment. L'erreur de raisonnement peut souvent être évitée si l'on fait valider ses propres hypothèses par d'autres personnes. Dans le meilleur des cas, sans que la propre conclusion soit déjà communiquée à l'avance. 

• Rendre explicites les hypothèses sur lesquelles se basent les suppositions et les tester sérieusement en fixant des objectifs quantitatifs et qualitatifs clairs et des valeurs de mesure. 

• En tant que client, il ne faut pas exercer de pression sur une estimation sérieuse de l'équipe de développement. Pourquoi quelqu'un devrait-il estimer beaucoup plus que nécessaire ? La concurrence sur le marché est trop forte pour que quelqu'un puisse se permettre de faire des estimations irréalistes. Notre expérience montre que les prix/estimations fortement négociés reviennent généralement au prix initial à la fin du projet.

• Prévoir une réserve fixe pour les imprévus dans le budget afin d'avoir une image réaliste des coûts.

2. Piège des coûts irrécupérables : Sunk Cost Fallacy 

Aussi désagréable que cela puisse paraître, le mieux serait souvent de parvenir à oublier le passé et à ne considérer que les perspectives d'avenir sans avoir en tête tous ces efforts passés. 

En tant qu'êtres humains, nous voulons paraître cohérents, c'est pourquoi nous nous comportons de manière irrationnelle lorsqu'un "dérapage" ou une contradiction se présente. En adoptant un comportement cohérent, nous voulons créer de la crédibilité et de la confiance. Abandonner un projet de logiciel à mi-parcours parce que l'on n'a pas atteint les objectifs que l'on s'était fixés est clairement en contradiction avec une prestation par ailleurs cohérente. Cependant, poursuivre un projet inutile ne fait que retarder la douleur. L'adage "mieux vaut une fin qui fait peur qu'une horreur sans fin" devrait donc être définitivement pris à cœur. 

Trop souvent, nous accordons une valeur aux coûts passés lorsque nous décidons de l'avenir d'un projet. Bien que les objectifs soient loin d'être atteints, on se dit : "Maintenant que nous sommes allés si loin et que nous avons investi tant de temps dans ce projet, nous ne pouvons pas simplement l'abandonner". Dans la plupart des cas, l'échec n'est que retardé et rendu plus coûteux. 

Conseils pour éviter le "sunk cost fallacy" :

• Fixer dès le départ des objectifs clairs, réalistes et mesurables et décider en fonction de leur réalisation.

• Mieux vaut s'y prendre tôt que tard.

• Impliquer dans la décision des personnes neutres qui apportent leur objectivité.

• Réfléchir aux alternatives possibles si le budget prévu était investi dans d'autres projets / produits.

3. Le piège de la confirmation - Confirmation Bias

Une erreur de raisonnement omniprésente que nous connaissons tous - et qui nous rattrape pourtant régulièrement. 

Exemple tiré du discours public

Bien sûr, les opinions et les positions sont diverses. Mais ce qui est souvent passionnant dans le débat public, c'est de voir comment toutes les positions, armées de "preuves" et de "faits", sont très sûres de leur propre opinion. Chaque partie trouve sur le web suffisamment de matériel qui offre des arguments pour l'une ou l'autre partie. Nous aimons trouver des vidéos, des blogs et des articles qui confirment notre propre opinion et ignorons généralement les faits et opinions contraires. S'il y a quelque chose que nous ne pouvons pas "nier", nous l'appelons "cas particulier".

Exemple tiré du développement de logiciels

À tous les niveaux des tests de logiciels, nous avons pour objectif de tester le code dans son intégralité afin de détecter les erreurs logicielles et d'améliorer ainsi la qualité du logiciel. Les développeurs et les testeurs de logiciels ont toutefois tendance à effectuer des tests positifs plutôt que négatifs, car un test négatif n'est pas une confirmation, mais justement une réfutation. Cela est dû au phénomène connu sous le nom de biais de confirmation, qui conduit les gens à préférer confirmer leurs propres hypothèses plutôt que d'essayer de les réfuter. C'est entre autres pour cette raison que nous attachons tant d'importance à avoir une équipe d'assurance qualité aussi indépendante que possible.

Exemple du biais de confirmation chez les app-preneurs

De nombreux fournisseurs d'apps qui assument une responsabilité en matière de produit ou de marketing sont beaucoup plus ouverts aux indications qui donnent raison à leurs hypothèses, stratégies et mesures. La disconfirming evidence (les choses qui vont à l'encontre de mes hypothèses) n'est généralement pas recherchée ou, si elle existe, il vaut mieux ne pas en tenir compte. Concrètement, cela signifie qu'en tant qu'App Manager, je préfère rassembler et communiquer largement tous les indices possibles qui parlent en faveur du succès de l'application ou de mes mesures, plutôt que tous les indices qui parlent contre mon succès.

Une bonne solution proposée par Albert Einstein

Albert Einstein connaissait lui aussi bien ce phénomène ou cette erreur de raisonnement et avait une recette plutôt pragmatique pour y remédier : il passait le plus de temps possible à trouver précisément ces "disconfirming evidences" (preuves réfutatives) et à prendre chacune d'entre elles très au sérieux afin de pouvoir éventuellement réfuter ses propres thèses avant que quelqu'un d'autre ne puisse le faire. Nous devrions penser de la même manière.

4. Authority Bias: le préjugé d'autorité

Selon l'expérience de Stanley Milgram en 1961, les gens ont tendance à attribuer une plus grande valeur à l'opinion d'"experts ou de spécialistes" ou à une personne estimée "autoritaire". Dans le domaine du commerce numérique ou de la transformation numérique de la société et de l'économie, il existe un grand nombre de soi-disant "experts" et "spécialistes" qui vendent ensuite leurs connaissances partielles à des participants ignorants du marché sous forme de mandats de conseil ou de publications. 

Peut-être quelqu'un se souvient-il de la déclaration de Mark Zuckerberg en 2016, qui prédisait la fin des applications natives et l'essor fulgurant des chatbots intelligents. De nombreux acteurs du marché y ont immédiatement cru et se sont lancés dans le développement de chatbots ou ont créé des entreprises qui développent de tels chatbots pour d'autres. Environ six ans plus tard, on peut dire que ce scénario n'est pas devenu réalité. Le marché des applications est toujours en forte croissance et le nombre de chatbots vraiment utiles et largement répandus reste très limité. Nous avons également abordé le sujet dans notre blog et écrit sur les chatbots - cliquez ici pour lire l'article.  

Je pense que nous n'aurions pas écrit ce blog sans les déclarations de M. Facebook.  

Le préjugé envers l'autorité est souvent exacerbé par la croyance que l'obéissance est un comportement correct. Pour contrer ce préjugé, il convient d'examiner ses propres hypothèses et de se demander si l'une d'entre elles a été faite en raison d'un préjugé envers une autorité. Cette autorité peut être votre propre organisation, un acteur reconnu comme Google ou peut-être même votre ancien moi. Dans tous les cas, il convient de remettre en question l'autorité plutôt que de se fier aveuglément à une opinion éventuellement biaisée.

Nous observons souvent ce biais d'autorité, notamment dans le cas de nouveaux thèmes à la mode et très en vogue, comme la blockchain et les cryptomonnaies. Dans de nombreux cas, nous fondons nos propres opinions sur les déclarations et les avis d'autres autorités, plus importantes à nos yeux, sur ces sujets. Il est bien sûr important d'écouter et de lire les différents avis et opinions des soi-disant experts, mais il est tout aussi important de toujours les remettre en question et de se demander dans quelle mesure ces déclarations sont réellement basées sur des faits et des chiffres et sont valables dans son propre contexte.

5. Le biais de la survivance

Parce que les apps à succès sont beaucoup plus connues, visibles et utilisées que les milliers d'apps qui ont moins de succès, nous surestimons systématiquement nos propres chances de lancer une app ou un service numérique à succès. La quantité de projets qui ont échoué et d'apps qui n'ont pas eu de succès est incroyablement élevée, mais cette "liste des perdants" ne retient absolument pas notre attention lorsque nous sommes euphoriques à l'idée de développer une app très réussie.

Exemple tiré de l'industrie du jeu : l'histoire de Rovio

Rovio, le studio de jeu finlandais mondialement connu, peut sembler à beaucoup un succès du jour au lendemain, mais c'était tout sauf cela. En 2009, Rovio était un petit studio de jeux vidéo finlandais au bord de la faillite. Il avait licencié la plupart de ses collaborateurs et n'employait plus que 12 personnes. L'entreprise avait été fondée en 2003 par des étudiants qui avaient gagné un concours de jeux vidéo et qui pensaient qu'il serait amusant de créer leur propre studio. Ils ont découvert qu'ils étaient capables de développer quelques jeux sympas, mais que la distribution était difficile. Avant Angry Birds, ils avaient développé 51 jeux, qui n'avaient toutefois pas rencontré le succès escompté. Le fait qu'aujourd'hui, presque personne ne prête attention aux 51 échecs, mais considère uniquement l'exemple extrêmement réussi d'Angry Birds comme une source d'inspiration et un point de départ pour ses propres projets de jeux, est un exemple clair du biais de survie. Pour en savoir plus sur l'histoire de Rovio, voir ici.

Possibilités d'éviter cette erreur de raisonnement :

• Ne pas seulement tenir compte des projets ou des produits qui ont réussi, mais aussi analyser les projets qui ont échoué.

• Calculer le plus objectivement possible les probabilités de succès et formuler explicitement les propres hypothèses qui devraient conduire à ce succès et les vérifier régulièrement sur le chemin de la réussite.

• Il est important de tirer les leçons des marques et des produits autrefois prometteurs qui ont ensuite échoué. Le secteur de la technologie en compte un nombre incalculable, comme Nokia, Blackberry, le Windows Phone de Microsoft, MySpace, Xing, les téléviseurs 3D, etc.

• Comme nous avons tendance à surestimer nos propres chances de succès, il serait utile de partir du scénario le plus pessimiste. Cela correspondrait alors davantage à la réalité.

6. L'illusion du corps du nageur

Nous avons souvent du mal à interpréter correctement la raison de la réussite de quelque chose et, dans de nombreux cas, nous confondons même la condition préalable à quelque chose avec le résultat. Nous voyons par exemple des nageurs et nageuses qui réussissent et qui sont très beaux physiquement, ce qui nous fait penser qu'avec suffisamment d'entraînement en natation, nous aurons aussi cette apparence. Nous oublions trop souvent que ce physique était peut-être déjà la condition préalable pour que le nageur ou la nageuse ait autant de succès : voilà, l'illusion du corps du nageur.

En ce qui concerne le marché des applications, la transformation numérique et les nouvelles technologies, il est important d'être toujours très critique lorsque quelqu'un prétend avoir trouvé la recette du succès. Il existe tant de livres qui décrivent les moyens utilisés pour mener une application ou une offre numérique au succès. À la manière de "sept étapes vers le succès" ou du "principe de Google". Le fait qu'il y ait déjà eu auparavant et définitivement aussi après ce succès de très nombreuses entreprises qui ont appliqué exactement ces principes 1:1 chez elles et qui n'ont pourtant pas connu le même succès passe souvent inaperçu. On oublie souvent que dans un projet, un produit réussi a pu être créé grâce à une méthode de projet très "en cascade" et que dans d'autres, des applications tout aussi réussies ont été créées avec des méthodes agiles. Souvent, les facteurs qui ont conduit une marque ou un produit au succès sont bien différents de ceux qui semblent évidents et compréhensibles pour tous. C'est souvent le pur hasard, un événement imprévisible, des circonstances extérieures ou la pure chance/malchance qui conduisent quelqu'un au succès ou à l'échec. Attention donc aux conseils qui promettent le succès avec des recettes simples. Dans de nombreux cas, le succès est tout simplement le fruit d'un travail très dur.

Résumé de la première partie de notre mini-série de blogs sur les erreurs de raisonnement

• De nombreuses erreurs de raisonnement que nous rencontrons dans la vie quotidienne se produisent également dans le secteur des logiciels.

• Peu importe qui dit ou écrit quoi : Il faut examiner attentivement les déclarations et les prédictions d'avenir, réfléchir par soi-même et chercher aussi des avis contraires.

• Ne pas se laisser aveugler par le succès des meilleures apps et des produits numériques, mais aller au cimetière des échecs, regarder derrière les coulisses et y chercher les raisons pour lesquelles de nombreux autres projets n'ont pas pu être menés à bien. 

• Évaluer ses propres chances de réussite de manière réaliste, voire plutôt pessimiste, et se baser sur des faits et des chiffres réels grâce à des objectifs et des mesures clairement mesurables. 

• La diversité dans les équipes et une culture ouverte de l'erreur ainsi que des boucles de feedback à 360° augmentent les chances que les décisions et stratégies importantes comportent moins d'erreurs de raisonnement.
  
  

As-tu éventuellement de bons exemples où tu t'es surpris, ou quelqu'un d'autre, à commettre une erreur de raisonnement dans le développement de logiciels ? Nous nous réjouissons de toute contribution, critique ou information complémentaire sur ce thème. Et nous attendons avec impatience la deuxième partie !