Pourquoi même les experts les plus expérimentés échouent dans leurs projets ?

Les biais cognitifs : nous les connaissons à force d’en parler et d’y être confronté, pourtant, ils se répètent sans cesse. Dans les projets informatiques, ils influencent la planification et les estimations, les décisions d'architecture, les exigences, le pilotage et les daily stand-ups. Ce n'est pas parce que les équipes sont incompétentes, mais simplement parce que les êtres humains ne sont pas des machines à prendre des décisions purement rationnelles. C'est particulièrement dangereux dans les projets informatiques. Nous travaillons avec de l'incertitude, des dépendances, des risques techniques, des exigences incomplètes et une forte pression sur les résultats. Et c'est précisément là que les biais cognitifs se plaisent le plus. Mon article vous montre, comment remettre en question vos décisions de manière critique, être plus réaliste face aux charges et évaluer les nouvelles informations de façon neutre.

Le biais de confirmation : quand nous ne voyons plus que ce qui nous arrange

Le biais de confirmation décrit la tendance à sélectionner ou à interpréter les informations de manière à confirmer nos convictions existantes. Ce qui ne correspond pas est ignoré, relativisé ou traité comme une exception. Dans les projets informatiques, cela arrive étonnamment souvent. Un Product Owner est convaincu que les utilisateurs et utilisatrices ont besoin d'une fonctionnalité spécifique. Les chefs de projet croient que leurs plannings sont réalistes. Ensuite, on perçoit surtout les signaux qui soutiennent cette vision. Les retours critiques sont alors perçus comme dérangeants. Un commentaire négatif lors d'un entretien avec un utilisateur est qualifié de « cas isolé ». Une partie prenante qui mentionne d'autres priorités ? « Il poursuit simplement d'autres objectifs que le projet ».

Pourquoi le biais de confirmation est-il dangereux ?

Le biais de confirmation fait que les projets reposent sur de fausses hypothèses. Les exigences ne sont pas correctement validées, les risques restent invisibles et les décisions semblent fondées alors que la base d'informations est biaisée. Le plus problématique dans tout cela, c'est que les erreurs ne deviennent souvent visibles que tardivement. À ce stade, les adaptations coûtent cher et la discussion devient émotionnelle.

Comment y remédier ?

1. Forcer activement les contre-hypothèses

Tout d'abord, il faut distinguer clairement ce qui relève d'une exigence explicite et ce qui relève d'une hypothèse implicite liée à cette exigence. Pour chaque hypothèse importante, il convient de se poser la question suivante :

« Que devrait-il se passer pour que nous considérions notre hypothèse comme fausse ? »

Exemples :

• « À quoi reconnaîtrions-nous que cette fonctionnalité n'est pas du tout importante pour les clients ? »
• « Quels signaux techniques montreraient que notre décision ne tient pas la route ? »
• « Quels retours remettraient en question notre priorisation ? »

Ces questions semblent simples, mais elles changent l'état d'esprit. Au lieu de chercher une confirmation, nous testons une hypothèse. Au lieu de « nous croyons bien faire », nous nous rapprochons du « nous savons que nous faisons ce qu'il faut ».

2. Documenter les hypothèses

De nombreuses hypothèses restent tacites. C'est précisément ce qui les rend dangereuses. Un simple registre des hypothèses est très utile, car il transforme les vérités implicites en éléments vérifiables. En voici un exemple :

• Hypothèse : les utilisateurs ont besoin d'une fonction d'exportation
• Impact si erronée : effort de développement élevé sans valeur ajoutée
• Comment la valider ? : entretiens utilisateurs, test de prototype
• Pour quand ? : Sprint 3
• Responsable : Product Owner

3. Planifier des revues par des personnes externes

Quand on est plongé dans une solution et qu'on y a investi beaucoup de temps, on a souvent tendance à la défendre inconsciemment. C'est pourquoi les revues indépendantes menées par des personnes n'ayant pas participé à la conception de la solution sont précieuses. Un point essentiel : ces revues ne doivent pas être perçues comme un contrôle, mais comme une protection. Il faut veiller à ce que ces revues ne se traduisent pas par des critiques destructrices, mais qu'elles apportent des contributions constructives au projet.

L'illusion de planification : quand le plan ne fonctionne que si tout va bien

L'illusion de planification décrit notre tendance à sous-estimer l'effort, la durée et la complexité. Nous planifions comme si tout allait se dérouler à la perfection : les exigences sont claires, les interfaces fonctionnent, les parties prenantes décident rapidement et sont sur la même longueur d'onde. Nous planifions le projet que nous aimerions avoir, et non celui qui va probablement se réaliser.

Pourquoi l'illusion de planification est-elle si importante dans les projets informatiques ?

Les projets informatiques sont faits d'incertitudes. Les exigences évoluent. Les systèmes existants se comportent différemment de ce qui est documenté. Les données de test manquent. Les validations de sécurité et les clarifications sur la protection des données prennent plus de temps. Nous perdons ainsi du temps précieux. Pour compenser, on effectue par exemple moins de tests ou on accumule davantage de dette technique. Résultat : la qualité baisse, les équipes sont plus stressées et insatisfaites. Le plus souvent, cela se termine par des corrections tardives et coûteuses. L'illusion de planification n'est donc pas seulement un problème de planification. Elle se transforme rapidement en un problème de qualité et de confiance. Pourtant, on exige souvent des experts qu'ils prévoient et évaluent correctement ces facteurs inconnus grâce à leur expérience.

Comment y remédier ?

1. Planifier à l'aide de projets de référence

Au lieu de se demander : « Combien de temps pensons-nous que cela va prendre ? », les équipes devraient se poser la question suivante :

« Combien de temps un projet comparable a-t-il réellement pris par le passé ? »

C'est ce qu'on appelle la vue externe. Elle nous oblige à ne pas regarder le projet uniquement de l'intérieur. Il est particulièrement utile d'utiliser des données réelles, par exemple les temps de traitement de fonctionnalités similaires, la durée des intégrations passées ou le nombre de demandes de changement de projets comparables. Si une tâche n'a jamais pris moins de 5 semaines lors des trois derniers projets, le planning du nouveau projet ne devrait pas prévoir 2 semaines pour cette même tâche, même si beaucoup de choses semblent « plus claires » cette fois-ci.

2. Légitimer la marge de sécurité plutôt que de la cacher

Les marges de sécurité sont souvent mal vues dans les projets. Pourtant, elles sont le signe d'une planification professionnelle. L'essentiel est de les rendre transparentes et de les justifier. Cela rend la marge compréhensible et négociable.

Au lieu de dire « nous prévoyons secrètement un peu de marge », il vaut mieux communiquer ouvertement et justifier : « Nous prévoyons une marge de sécurité de 15 % en raison de dépendances externes et de conditions encore floues. »

3. Planifier de manière itérative plutôt que de créer une fausse précision

Plus un projet s'étale dans le temps, plus le plan est incertain. Pourtant, on établit souvent des plannings détaillés sur plusieurs mois, qui suggèrent une précision totalement illusoire.

Un bon plan n'est pas un document figé que l'on défend à tout prix. C'est un outil de pilotage. Si, en bateau, sur la route de A à B, on aperçoit un iceberg, il vaut mieux le contourner habilement plutôt que d'espérer que la coque soit plus solide que la glace devant soi. C'est pourquoi il convient de planifier le futur proche en détail, le moyen terme de manière globale, et de traiter le futur lointain comme une vision à actualiser régulièrement.

L'illusion des coûts perdus : quand nous continuons uniquement parce que nous avons déjà investi

L'illusion des coûts perdus décrit la tendance à s'en tenir à une décision parce que du temps, de l'argent ou de l'énergie y ont déjà été consacrés. D'un point de vue rationnel, les coûts passés ne devraient jouer aucun rôle dans les décisions futures. Seule compte la question suivante : est-ce que le prochain franc investi, la prochaine journée ou le prochain sprint en vaut la peine ? C'est une vision très rationnelle, mais malheureusement, nous nous comportons différemment dans les projets. « Nous y avons déjà consacré tellement de temps, tout cela n’aurait-il servi à rien ?! », « Si nous ne terminons pas cela, nous allons faire mauvaise figure ! ». C'est compréhensible, car personne n'aime admettre s'être trompé.

Pourquoi l'illusion des coûts perdus est-elle particulièrement critique dans les projets informatiques ?

Les projets informatiques génèrent rapidement des investissements initiaux élevés : concepts, architecture, code, interfaces, tests, validations budgétaires. Plus l'investissement est important, plus il est difficile de changer de cap. Ainsi, les équipes continuent de développer des fonctionnalités qui n'apportent presque aucune valeur. Des sous-projets se poursuivent, alors qu'ils ne contribuent plus à atteindre les objectifs. Les coûts déjà perdus ne cessent de grimper.

Comment y remédier ?

1. Planifier systématiquement des revues « stop-or-go »

Plutôt que de considérer l'arrêt d'un projet comme une exception ou un échec, il devrait faire partie des revues régulières. Les questions suivantes doivent être posées régulièrement, et pas seulement lorsque le projet est déjà en difficulté :

• L'analyse de rentabilité initiale est-elle toujours valable ?
• Les exigences ou les conditions ont-elles changé ?
• Prendrions-nous la même décision aujourd'hui ?
• Quel avantage futur justifie la poursuite des efforts ? Existe-t-il une meilleure alternative ?

2. Définir les critères d'arrêt à l'avance

Décider de stopper le projet est plus logique si les critères d'arrêt sont définis avant toute escalade émotionnelle. Ainsi, un changement de cap n'est pas perçu comme une réaction de panique spontanée, mais comme une décision préparée de manière professionnelle, ce qui facilite son explication auprès de la direction. À titre d'exemple, on pourrait définir à l'avance que si moins de X% des utilisateurs pilotes utilisent la fonctionnalité, aucune ressource supplémentaire ne sera investie. Ou encore, que si les coûts d'intégration de la fonctionnalité dépassent le montant X prévu, une nouvelle évaluation de l'analyse de rentabilité sera effectuée.

3. Établir une culture de confiance : repenser plutôt que de chercher des coupables

De nombreux projets durent trop longtemps parce qu'un changement de cap est interprété comme un échec personnel. C'est pourquoi nous avons besoin d'une culture où les nouvelles découvertes ne sont pas considérées comme une défaite. Une bonne formule pour les équipes de projet est la suivante :

« Une décision était compréhensible compte tenu des hypothèses de l'époque. Aujourd'hui, nous disposons de nouvelles informations et nous prenons donc une nouvelle décision. »

Les projets réussis intègrent les biais cognitifs

Les biais cognitifs ne disparaissent pas simplement parce que nous les connaissons. Même les chefs de projet, les architectes, les Product Owners, les business analysts et les test managers expérimentés tombent dans ces pièges. L'expérience peut même aggraver le problème si elle nous rend trop confiants.

Les projets réussis ne se caractérisent donc pas uniquement par de bonnes méthodes et une expertise technique.

Ils créent délibérément des structures qui aident les équipes à remettre en question leurs hypothèses, à rendre les risques visibles et à adapter leurs décisions face à de nouvelles informations.

En effet, la réussite des projets informatiques ne dépend pas d'une pensée humaine parfaite. Elle découle du fait que les équipes connaissent leurs faiblesses et adaptent intelligemment leur façon de travailler en conséquence.

Quels biais cognitifs freinent votre réussite ? Parlons-en ensemble ! adesso allie expertise technique et méthodologique avec pragmatisme, pour que de bonnes décisions se transforment en projets durables. Contactez-nous !