i

Description

Des bouteilles de Coca-Cola

Source

Rowanswiki · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

La confirmation du besoin

On croit recueillir un besoin, alors qu'on vient chercher l'approbation de la solution que l'on a déjà en tête.

En bref

• Quoi : un recueil de besoins qui sert en réalité à valider une solution déjà choisie.
• Pourquoi : c'est une forme du biais de confirmation ; la formulation des questions et l'écoute font le tri avant toute analyse.
• Détecter : questions fermées (« vous aimeriez ce bouton ? »), solution citée avant le problème, tous les retours sont favorables.
• Éviter : décrire le problème avant la solution, poser des questions ouvertes, observer le travail réel, chercher ce qui réfute l'hypothèse.

Sur cette page

1. Définition
2. Le mécanisme
3. Où on le rencontre
   1. En conduite de projet
   2. En management
4. Cas célèbres
   1. New Coke : on a testé le goût, pas le besoin 1985
   2. La tâche des « 2-4-6 » 1960
5. Signaux de détection
6. Réflexes d'évitement
7. Avec l'IA : détecter, remédier, atténuer
   1. Détecter
   2. Remédier
   3. Atténuer
   4. Prompts à intégrer à vos usages
   5. Comment les intégrer
   6. Précautions
8. Limites
9. Sources et vérification
10. Voir aussi
    1. Se combine avec, ou renforce
    2. Biais voisins
    3. Contrepoids et réflexes associés

Définition#

Illustration fictive

La confirmation du besoin désigne la manière dont un biais de confirmation s'installe dans un recueil de besoins : on interroge des utilisateurs, des clients ou des sponsors en ayant déjà une solution en tête, on pose des questions qui la favorisent, et l'on retient dans les réponses ce qui la conforte. Le résultat est un cahier des charges qui paraît validé par le terrain, alors qu'il n'a été ni mis à l'épreuve ni réfuté.

Ce n'est pas un biais distinct sur le plan de la psychologie : c'est le biais de confirmation décrit par Peter Wason (1960) et passé en revue par Raymond Nickerson (1998), appliqué à une situation précise de la conduite de projet. On le traite à part parce que ses parades sont propres au métier : méthode d'entretien, observation, formulation des questions.

Le mécanisme#

• Chercher ce qui confirme. Dans la tâche des « 2-4-6 » de Wason, les participants testent des suites qui respectent leur hypothèse plutôt que des suites qui pourraient la réfuter ; ils sont donc confortés dans une règle fausse. Un entretien qui teste « voulez-vous un tableau de bord ? » procède de la même façon.
• Des questions qui orientent. Une question fermée ou suggestive (« ce serait plus pratique avec une application mobile, non ? ») obtient presque toujours un « oui » poli. L'interlocuteur répond à la question, pas au besoin.
• Une écoute sélective. Les remarques favorables sont notées, les réserves sont lues comme des cas particuliers ou des « résistances au changement ».
• L'attachement à l'idée. Plus on a investi dans une solution (maquettes, estimation, promesse à la direction), plus il est coûteux de la voir contredite (voir l'effet IKEA).
• La politesse de l'interlocuteur. Un client ou un utilisateur approuve par courtoisie, ou parce qu'il ne se représente pas l'usage réel avant de l'avoir sous les mains.

Où on le rencontre#

En conduite de projet#

• Recueil de besoins : l'analyste arrive avec un schéma d'architecture ou une maquette et demande « est-ce que ça couvre votre besoin ? ». L'utilisateur, qui n'a pas de point de comparaison, approuve.
• Ateliers : l'animateur présente la solution cible en ouverture ; les participants discutent de ses détails au lieu de poser le problème.
• Expression de besoin déjà formulée en solution : « il nous faut un export Excel » est une solution, pas un besoin. L'équipe la réalise sans demander ce que l'export doit permettre de faire.
• Preuve de concept et démonstration : on montre ce qui marche à ceux qui sont favorables ; on évite les utilisateurs critiques, ou on les voit en dernier.
• Spécification : on conserve les besoins qui concordent avec l'architecture retenue et l'on classe les autres en « hors périmètre ».

En management#

• Enquête interne ou baromètre : les questions sont rédigées pour obtenir l'adhésion à une réorganisation déjà décidée.
• Retours de l'équipe sur un changement d'outil ou de processus : on interroge ceux dont on sait qu'ils sont d'accord, ou l'on demande « avez-vous des objections ? » devant tout le monde.
• Entretiens annuels : le manager qui a déjà une opinion sur un collaborateur recueille les faits qui la confirment.
• Consultation du terrain par un siège : le siège présente le dispositif cible et recueille des avis sur ses modalités ; la question de savoir s'il répond à un besoin réel n'est jamais posée.

Cas célèbres#

Signaux de détection#

• La solution est nommée avant le problème (« on va faire un portail, qu'est-ce qu'on y met ? »).
• Des questions qui se terminent par « non ? », « n'est-ce pas ? », ou qui n'admettent que « oui » ou « non ».
• Les retours sont unanimement favorables, sans réserve, sans cas d'usage imprévu.
• Les besoins exprimés sont des fonctions techniques (« un export », « un filtre »), pas des tâches à accomplir.
• Les utilisateurs interrogés sont ceux que l'on connaît déjà ou qui sont favorables.
• Les remarques critiques sont classées « résistance au changement » ou « hors périmètre » avant d'avoir été examinées.
• Aucun des entretiens n'a eu lieu là où le travail se fait : on a seulement entendu parler du travail.

Réflexes d'évitement#

1. Le problème avant la solution. Ouvrez l'atelier par la situation actuelle : ce que l'utilisateur fait aujourd'hui, ce qui lui coûte du temps, ce qui échoue. La solution n'est présentée qu'ensuite, comme une hypothèse.
2. Des questions ouvertes sur le passé. « Racontez-moi la dernière fois que… » plutôt que « est-ce que vous voudriez… ». Les faits passés sont moins sujets à la politesse que les intentions futures (voir The Mom Test de Rob Fitzpatrick).
3. Observer le travail réel. Passer une demi-journée à côté de l'utilisateur apprend ce qu'il ne dit pas, parce qu'il l'a oublié ou le trouve trop évident.
4. Chercher ce qui réfute. Écrivez avant l'entretien ce qui vous ferait abandonner ou modifier l'idée, puis cherchez-le : « qu'est-ce qui rendrait cette solution inutile pour vous ? »
5. Interroger aussi ceux qui ne sont pas d'accord. Faites une liste des interlocuteurs « difficiles » (utilisateurs critiques, support, exploitation, métier concurrent) et voyez-les en premier.
6. Traduire une solution demandée en besoin. Devant « il faut un export Excel », demandez « qu'en faites-vous ensuite ? » jusqu'à atteindre la tâche réelle.
7. Nommer un avocat du diable dans l'équipe : il prépare, à chaque restitution, les trois raisons pour lesquelles le besoin retenu pourrait être faux.
8. Faire un test avec un comportement, pas un avis. Un prototype grossier utilisé en situation, ou un engagement (temps, donnée, pré-commande), apprend plus qu'une approbation verbale.

Avec l'IA : détecter, remédier, atténuer#

Prompts à intégrer à vos usages#

1. Relecture d'un guide d'entretien. Avant des entretiens de recueil de besoins.

Voici le guide d'entretien que je compte utiliser pour comprendre le travail de [type d'utilisateurs]. Ne t'occupe pas de la solution envisagée.
1. Repère chaque question fermée, suggestive (elle contient la réponse attendue), double ou orientée vers une solution.
2. Reformule-les en questions ouvertes portant sur des faits passés (« racontez-moi la dernière fois que… »).
3. Ajoute cinq questions qui chercheraient à montrer que le besoin n'existe pas, ou qu'il se règle autrement.
4. Dis, en une phrase, ce que ce guide permettrait de ne pas entendre.

Guide : [texte]

2. Séparer besoins, solutions et réserves. Sur des notes d'atelier ou d'entretien, anonymisées.

Voici les notes brutes d'un atelier de recueil de besoins (noms retirés). Sans connaître la solution que nous envisageons :
- classe chaque énoncé en trois colonnes : « tâche ou problème », « solution demandée », « réserve ou objection » ;
- pour chaque solution demandée, propose la tâche réelle qu'elle cache, sous forme de question à poser ;
- liste toutes les réserves et objections, y compris celles que le compte rendu officiel n'a pas retenues ;
- conclus en une phrase : les notes contiennent-elles de quoi remettre en cause l'idée de départ ?

Notes : [texte]

Comment les intégrer#

• Avant : le prompt 1 sert de relecture du guide, avec un collègue qui joue l'avocat du diable.
• Après chaque entretien : déposez les notes brutes dans le prompt 2 avant de rédiger le compte rendu.
• À la restitution : présentez les réserves à côté des besoins confirmés, pas dans une annexe.

Précautions#

• Ne révélez pas la solution à l'outil avant qu'il n'ait classé les notes : il se mettrait à la confirmer.
• L'IA ne remplace pas l'observation du travail réel : elle ne voit que ce qui a été écrit.
• Les notes d'entretien contiennent souvent des informations sur des personnes : anonymisez avant de les coller dans un outil non autorisé.
• Vérifiez les références ou les « bonnes pratiques » qu'elle cite : elles peuvent être inventées.

Limites#

• Avoir une hypothèse n'est pas fautif : on ne mène pas d'entretien sans idée de départ. Le défaut est de la traiter comme acquise et de ne chercher que ce qui la conforte.
• Les questions ouvertes et l'observation coûtent du temps. Pour un besoin simple et bien connu, une validation rapide peut suffire.
• Les utilisateurs ne savent pas toujours dire ce dont ils ont besoin ; observer et prototyper compensent, mais ne suppriment pas l'incertitude.
• L'exemple de New Coke est célèbre mais souvent raconté de façon simplifiée : d'autres facteurs (marque, nostalgie, médias) ont joué, et l'épisode a même, selon certains analystes, relancé les ventes de la marque. La leçon sur la question mal posée reste valable.

Sources et vérification#

• Wason (1960), « On the failure to eliminate hypotheses in a conceptual task », Quarterly Journal of Experimental Psychology, 12(3) — la tâche des « 2-4-6 ».
• Nickerson (1998), « Confirmation bias: A ubiquitous phenomenon in many guises », Review of General Psychology, 2(2) — synthèse.
• Fitzpatrick (2013), The Mom Test: How to talk to customers and learn if your business is a good idea when everyone is lying to you, CreateSpace.
• Torres (2021), Continuous Discovery Habits, Product Talk LLC.
• The Coca-Cola Company, « New Coke: The Most Memorable Marketing Blunder Ever? » — dates, tests de goût, retour du 11 juillet 1985.
• ABC7, « Beverage Backlash: History of New Coke » — repris des dates et du chiffre de près de 200 000 consommateurs.

Voir aussi#