Dans les organisations, nous aimons présenter les décisions comme le résultat d’analyses objectives, d’indicateurs chiffrés et de raisonnements structurés. Pourtant, sur le terrain des projets, la réalité est plus nuancée. Les arbitrages se construisent à l’intersection des intérêts, des représentations, des émotions et des contraintes politiques. Comprendre cette dimension humaine n’est pas un aveu de faiblesse méthodologique : c’est une compétence centrale du Business Analyst, dont le rôle consiste précisément à rendre les décisions plus explicites, plus argumentées et plus traçables.
Introduction
Avez-vous déjà vu une décision validée en comité… puis remise en question quelques jours plus tard ?
Ou une demande acceptée comme « marginale »… avant de modifier profondément l’équilibre du périmètre ?
Nous aimons penser qu’un projet suit une logique rationnelle :
besoin → analyse → comparaison → décision.
En réalité, les décisions sont influencées par :
les biais cognitifs
la manière dont le problème est cadré
la dynamique collective
les engagements déjà pris
Le rôle du Business Analyst est précisément de structurer cette complexité.
Cette posture est développée dans l’article sur la profession.
1. La rationalité limitée : une réalité documentée
Les décisions humaines ne sont jamais parfaitement rationnelles. Ce principe est documenté depuis les travaux d’Herbert Simon sur la rationalité limitée.
Cela signifie que :
nous décidons avec une information incomplète
nous sommes contraints par le temps
nous utilisons des raccourcis cognitifs
Même les dirigeants expérimentés sont concernés.
Harvard Business Review analyse ces biais dans son article classique :
The Hidden Traps in Decision Making.
Le Business Analyst ne supprime pas ces biais, il les rend visibles.
La manière dont un problème est formulé oriente les arbitrages futurs.
C’est précisément l’enjeu du recueil des besoins.
Un besoin mal formulé verrouille souvent la décision avant même la comparaison des solutions.
2. Le cadrage influence la décision avant le choix
Même avec un bon cadrage, la décision se construit dans un collectif.
Le PMI documente l’impact des biais cognitifs dans la gestion de projet.
On retrouve notamment :
- effet d’ancrage
- biais de statu quo
- pression implicite du groupe
Dans un atelier, si une position forte est exprimée tôt, elle influence les échanges suivants.
Le rôle du Business Analyst est alors de structurer :
- séparer génération d’options et évaluation
- formaliser les critères
- documenter les risques
Une décision devient plus robuste lorsque les critères sont formalisés et comparables.
Les livrables essentiels du BA jouent un rôle clé dans cette structuration.
Sans formalisation, la décision repose sur des impressions.
3. Les biais collectifs dans les décisions projet
La façon dont un problème est formulé structure les décisions futures.
C’est ce qu’on appelle le framing effect.
Si un projet est présenté comme :
une opportunité stratégique
une réduction de risque
une optimisation budgétaire
Les critères implicites ne seront pas les mêmes.
Pour un Business Analyst, le cadrage est une phase déterminante. Cela rejoint le guide gratuit sur les fondamentaux de la BA.
4. L’effet des coûts irrécupérables (sunk cost)
Un biais très fréquent en projet est la sunk cost fallacy : continuer une décision simplement parce qu’on y a déjà investi.
En projet, cela peut conduire à :
maintenir un périmètre inadapté
refuser une réorientation
justifier des investissements supplémentaires
Le Business Analyst peut objectiver ces situations grâce à :
l’analyse d’impact
la traçabilité
la formalisation des hypothèses
Accepter toutes les demandes sous pression émotionnelle ou politique affaiblit la rationalité du projet.
Le sujet est approfondi ici.
Dire non, c’est parfois protéger la cohérence décisionnelle.
5. Formaliser pour renforcer la qualité décisionnelle
Si la décision n’est jamais 100 % rationnelle, elle peut être mieux éclairée.
Les référentiels de l’IIBA rappellent l’importance de distinguer :
besoin métier
exigences
solution
Plus la formalisation est claire, moins l’ambiguïté influence l’arbitrage.
Les pratiques de structuration comme Given/When/Then illustrent cette rigueur.
Le Business Analyst transforme ainsi : une décision implicite → en décision argumentée.
Conclusion
Les décisions en projet ne sont jamais parfaitement rationnelles.
Elles sont influencées par :
les biais cognitifs
le cadrage
les dynamiques collectives
les engagements passés
Le rôle du Business Analyst n’est pas d’éliminer ces facteurs.
Il est de :
rendre explicites les critères
structurer l’information
documenter les hypothèses
clarifier les arbitrages
C’est précisément ce qui fait de lui un acteur stratégique.
