Idée principale

En B2B, celui qui utilise le logiciel et celui qui l'achète sont rarement la même personne. L'acheteur paie, arbitre entre des projets concurrents, porte celui-ci devant sa hiérarchie, assume le risque s'il échoue et s'interroge sur la tenue du déploiement. Ses critères ne sont donc pas ceux de l'utilisateur : il évalue une décision, pas un outil.

Trois situations en découlent, et elles se constatent couramment. Un produit apprécié sur le terrain qui ne se vend pas. Un produit qui résout un vrai problème et se fait bloquer au moment de l'achat. Un produit bon, mais incompatible avec la manière dont l'organisation décide — procédure, seuils de validation, exigences de réversibilité, capacité de l'équipe interne à porter le déploiement.

Réussir auprès de l'utilisateur et réussir auprès du client sont donc deux épreuves distinctes, et passer la première ne dispense pas de la seconde.

Pourquoi c'est important

Cela sépare deux diagnostics que l'on confond quand une vente échoue. Un produit qui ne se vend pas malgré des utilisateurs satisfaits n'a pas un problème de valeur d'usage ; il a un problème de valeur pour l'acheteur, et améliorer l'expérience utilisateur ne le corrige pas.

Cela dit aussi ce qu'il faut découvrir en plus des usages : ce qui motive et ce qui bloque l'achat, devant qui l'acheteur doit se justifier, et ce que son organisation exige avant de signer.

Nuances et limites

La séparation n'est pas toujours nette : dans une petite structure, l'utilisateur et l'acheteur peuvent être la même personne, et le raisonnement se replie sur un seul jeu de critères.

Et l'adoption par les utilisateurs pèse dans la décision d'achat — elle est un argument pour l'acheteur, pas une garantie.

Questions ouvertes

• À quel moment d'une découverte produit faut-il aller voir l'acheteur, quand l'accès au terrain est plus facile et plus riche ?