Comment vendre quand l’utilisateur n’est pas l’acheteur

• Lorsque l’utilisateur se sert du produit sans être la personne habilitée à payer, l’essentiel est d’identifier qui détient réellement l’autorité et l’influence
• Le décideur qui possède l’autorité réelle n’est pas forcément l’acheteur ni le premier utilisateur
• Dans les petites organisations, le gain de temps est crucial, donc il est probable qu’un développeur adopte directement l’outil puis obtienne son achat en convainquant sa hiérarchie
• Dans les grandes organisations, les contraintes de sécurité et de procédure sont fortes, donc le pouvoir de décision d’achat appartient au CTO ou à la direction, avec un cycle de vente long
• La personne habilitée à acheter ne coïncide pas forcément avec le détenteur du budget, et la cible clé est celle qui perçoit le plus fortement la valeur du produit et peut faire avancer son adoption
• La stratégie la plus efficace consiste à fournir à l’utilisateur des données concrètes et des supports de persuasion afin qu’il puisse convaincre la direction, et à l’accompagner dans ce processus
• Le succès final repose sur la conception d’un processus qui soutient l’utilisateur dans son rôle de vendeur en interne

---

Introduction – point de départ de la question

• Comment s’y prendre lorsque l’utilisateur réel du produit et le client qui prend la décision d’achat ne sont pas la même personne ?
• Le contexte est celui, classique, de la vente de logiciels B2B, où un développeur teste d’abord le produit, puis le CTO ou le Director of Engineering prend la décision finale

La question fondamentale de l’autorité

• La question la plus essentielle est : « Qui détient le vrai pouvoir ? »
• Plus que la simple capacité à payer par carte ou la priorité donnée à l’essai du produit, ce sont l’influence réelle et la motivation qui déterminent le processus d’achat

Scénarios selon la structure de l’organisation

Dans les petites organisations : structure plate et décisions rapides

• Il arrive souvent qu’un développeur découvre le produit et pilote lui-même son adoption
• Comme la principale motivation du CTO est d’accélérer la mise sur le marché et l’itération, la proposition d’outil d’un développeur peut avoir une influence majeure sur la décision
• On observe souvent une diffusion de type Trojan-horse, où le développeur teste rapidement l’outil gratuitement avant qu’il ne soit ensuite converti en offre payante

Dans les grandes organisations : la sécurité et la conformité comme contraintes majeures

• Il existe des contraintes autres que le temps, notamment la sécurité, et les décisions de la direction jouent un rôle central à toutes les étapes
• L’installation ou l’achat autonome par l’utilisateur (le développeur) n’est pas autorisé, et le cycle de vente est long et complexe
• Les critères de perception de la valeur et du risque se concentrent moins sur l’UI/UX ou la DX que sur la sécurité et le résultat final

Le véritable angle de l’influence et de la valeur

• Le détenteur du budget n’est pas toujours celui qui exerce l’autorité réelle
• L’important est de savoir qui a le levier et dont les incitations pèsent le plus dans l’avancement du processus
• Il faut identifier de manière réaliste quel acteur est effectivement capable d’échanger de la valeur à hauteur du prix demandé

Exemple concret de parcours d’adoption du produit

1. L’utilisateur / le développeur crée un compte sur le produit
2. Il utilise l’essai gratuit dans son environnement local
3. Il expérimente directement la valeur fonctionnelle réelle (par ex. comparaison avant/après Pull Request, mise en évidence des problèmes)
4. Il perçoit la valeur → attente de gains d’efficacité et d’automatisation
5. L’utilisateur convainc la direction de la nécessité du produit
6. La direction approuve ou refuse après test interne et examen budgétaire
7. La direction donne l’approbation finale pour l’achat
8. L’achat du produit est finalisé, puis son usage s’étend davantage dans l’organisation

La question des incitations des deux côtés

• Identifier la motivation fondamentale du développeur à recommander l’outil (confort de travail, mise en valeur de ses compétences, atteinte des objectifs de l’entreprise, etc.)
• Identifier la motivation d’achat de la direction (amélioration de la productivité de développement, atteinte plus rapide des objectifs de l’entreprise, etc.)
• Si ces motivations clés existent, on peut proposer les stratégies suivantes

Stratégies de réponse concrètes

1. Fournir à l’utilisateur des outils de persuasion, comme des rapports précis de comparaison avant/après, afin qu’il puisse convaincre la direction
   • Dans ce processus, ce ne sont pas des conseils abstraits qui comptent, mais des résultats fondés sur des données quantitatives
   • Des mesures concrètes, comme « combien de temps a été économisé par rapport à la méthode précédente », sont la clé de la persuasion
2. Comprendre comment se déroule réellement la conversation d’achat grâce à des entretiens clients (développeurs), afin de résoudre à l’avance les obstacles du processus de persuasion

• Autrement dit, plutôt que de convaincre directement la personne habilitée à acheter, il faut fournir tout l’environnement de soutien et les documents concrets nécessaires pour que l’utilisateur joue avec succès un rôle de vente en interne
• Dans ce processus, le succès de l’utilisateur se traduit directement par le succès du fournisseur (une structure gagnante pour l’utilisateur, le fournisseur, la direction et l’entreprise)

Conclusion et résumé

• La meilleure stratégie consiste à aider l’utilisateur à réussir son rôle de vente interne autour du produit
• Il faut se concentrer sur la fourniture de preuves quantitatives et d’éléments concrets de valeur nécessaires pour convaincre la direction
• Il est indispensable, en amont, d’analyser finement la structure décisionnelle selon la taille de l’organisation et ses contraintes
• En définitive, si l’utilisateur réussit, le fournisseur et l’entreprise réussissent eux aussi simultanément

[GN⁺]

Commentaires sur Hacker News

• Je supporte de plus en plus mal le fait qu’on me demande mes coordonnées juste pour télécharger quelque chose, puis que des commerciaux m’appellent ou m’écrivent sans arrêt peu après, en ignorant mes refus polis et en revenant sans cesse avec des demandes de rendez-vous. Je n’ai pas le pouvoir d’achat, mais je peux diffuser mon mécontentement dans mon équipe, ce qui finit par dégrader l’image du produit. Quand un ingénieur me demande une recommandation, c’est évidemment le genre de chose que je vais mentionner. Cas rencontrés avec Veeam, AWS et Keyence.

  • En tant qu’IT Manager, je vis ça presque toutes les semaines. Comme ils n’obtiennent pas de réponse de ma part, ils contournent parfois le problème en envoyant des e-mails au hasard à mes collègues ou à d’autres personnes dans l’entreprise ; dans ce cas, je fais rapidement bloquer tout le domaine. Et j’aimerais aussi qu’on arrête de me forcer à regarder une démo juste pour obtenir un devis. J’aurai déjà étudié le produit et, si besoin, testé un essai ; il est donc plus logique de me donner d’abord le prix plutôt que de m’imposer une présentation commerciale ou une démo.

  • Même problème avec Auth0 et Okta. J’avais bien le pouvoir d’achat et même le budget, mais ils m’ont tellement sollicité que j’ai fini par les détester.

  • J’adore vraiment le concept de « pouvoir de nuisance ». Même quand quelque chose est proposé gratuitement, une équipe sales ou marketing trop zélée peut détériorer l’image d’une entreprise. Il faut contacter les clients de la manière qu’ils préfèrent, pas uniquement selon les méthodes voulues par l’entreprise ; sinon, l’effet est contre-productif. Mais c’est difficile du point de vue de la conception des incitations.

  • J’ai déjà vécu des cas extrêmes avec certaines équipes marketing SaaS qui envoient des e-mails toutes les 5 à 15 minutes. Parfois, cela peut venir d’un employé agissant de manière isolée, mais il semble aussi arriver que la direction ou le CEO configure lui-même l’outil d’e-mail marketing au maximum.

  • Il faut aussi ajouter les produits Microsoft à la liste. Pour s’inscrire, il faut créer un « compte professionnel », avec des barrières à l’entrée comme l’interdiction des comptes Gmail. Même pour utiliser un essai de 30 jours et évaluer le produit, on peut se retrouver incapable d’y accéder à cause de problèmes de compte. Si c’est déjà aussi pénible pour un simple trial, je n’ose même pas imaginer le processus réel d’adoption. Ça ne donne vraiment pas envie d’utiliser leur CRM, ERP, Dataverse et autres outils basés sur l’IA.

• Ce phénomène vient du problème principal-agent : dans l’entreprise, la direction détient le budget, mais ce sont les développeurs et les équipes terrain qui utilisent réellement les produits et les outils. Du point de vue d’un fondateur, on conseille souvent de mettre les utilisateurs de son côté afin qu’ils convainquent eux-mêmes la direction. L’idée centrale est que, puisqu’on ne peut pas parler directement à la personne qui a la carte bancaire, il faut aider au maximum l’utilisateur à persuader le management. Autrement dit, faire en sorte que l’utilisateur ou le développeur joue en pratique un rôle commercial. Cette approche peut fonctionner pour les modèles premium, par exemple, mais dans des secteurs où la décision d’achat est entièrement descendante — comme les systèmes hospitaliers et les EHR (dossiers médicaux électroniques) — les utilisateurs n’ont même pas réellement la possibilité d’essayer le produit, donc je me demande comment dépasser cela.

  • Sur le terrain, on voit aussi souvent la situation inverse : un commercial bien rodé vise le détenteur du budget, coupe la communication avec les vrais utilisateurs, et fait signer le contrat d’abord. Quand les utilisateurs se plaignent et signalent les problèmes, l’argent a déjà été dépensé.

  • Pour mettre en pratique le conseil consistant à « offrir aux utilisateurs la meilleure occasion de convaincre la direction, et les valoriser simplement en leur donnant les moyens de faire connaître cette option à la direction », nous avons nous aussi créé une « CEO Page » séparée : https://www.rsync.net/products/ceopage.html

• Pour compléter sur la manière de faire de l’enterprise sales : même le décideur lui-même ne comprend pas toujours correctement les véritables dynamiques de pouvoir dans son entreprise. Il faut aussi déterminer si cette personne relève d’un centre de coûts ou d’une activité génératrice de revenus, si elle pousse l’adoption d’une nouvelle technologie ou s’il s’agit d’un produit standardisé, et qui verra ce produit comme un risque ou une menace pour son pouvoir. Toutes ces informations doivent être intégrées à la stratégie : à qui vendre, qui éviter, et à quel moment approcher le sujet de façon légère ou à grande échelle.

• La méthode souvent utilisée par Slack et Postman, c’est : « 96 % de votre équipe utilisent déjà notre produit. Dans ces conditions, n’est-il pas logique de l’acheter maintenant ? »

  • On leur répond alors : « Si tout le monde l’utilise déjà, pourquoi faudrait-il l’acheter ? » Cette question révèle justement le niveau de décalage entre l’acheteur et l’utilisateur, surtout dans les PME.

  • C’est aussi pour cette raison qu’on offre gratuitement des logiciels aux étudiants.

  • Cela arrive très souvent aussi dans les petites équipes au sein de grandes entreprises. S’il y a une équipe sécurité, elle peut considérer comme problématique le fait que l’usage soit dispersé sur plusieurs workspaces Slack ; dans ce cas, un argument du type « Au lieu que 400 personnes utilisent 12 workspaces différents, gérez plutôt cela avec un seul compte officiel » peut fonctionner.

  • L’un des avantages cachés de l’open source commercial ou de modèles similaires, c’est que plus l’adoption individuelle augmente, plus l’adoption au niveau de l’entreprise progresse aussi.

• L’entreprise que j’avais fondée auparavant s’est elle aussi heurtée à ce problème. Il fallait vendre à des équipes de développeurs qui n’avaient pas le vrai pouvoir de décision d’achat. Dans les petites entreprises, ou dans les cas exceptionnels où l’interlocuteur avait l’autorité nécessaire, les contrats étaient faciles à conclure ; mais dans la plupart des cas, il fallait traverser un long cycle de vente et convaincre les décideurs de niveau supérieur grâce aux économies de coûts. Au final, le processus était long, le taux de réussite faible, et cela a été l’une des principales causes de l’échec de l’entreprise. Je suis heureux que ce sujet soit abordé plus ouvertement ; beaucoup de petites sociétés y sont confrontées, mais il existe étonnamment peu de conseils structurés à ce sujet.

• Ce modèle fonctionne bien lorsque l’utilisateur peut utiliser directement le produit et appartient à la même organisation. Mais quand l’utilisateur n’a pas de lien direct avec le décideur, ou qu’il est difficile de prouver l’intérêt économique de l’achat — par exemple un pop d’entrée sans clé pour voiture — je me demande comment il faut s’y prendre. C’est un gros avantage pour le conducteur, mais du point de vue du CTO de Ford, même une demande de rendez-vous peut sembler inutile. Dans ce type de situation, je cherche des conseils sur la manière d’aborder le marché après avoir développé le produit.

  • Dans ce genre de cas, une stratégie bottom-up est séduisante. Au lieu de viser directement le siège de Ford, il peut être efficace de commencer par les concessionnaires de voitures d’occasion, les garages automobiles ou les vendeurs d’accessoires. Si l’on prend l’exemple des dispositifs de démarrage à distance, les utilisateurs en avaient besoin mais les constructeurs automobiles s’y intéressaient peu ; le marché s’est donc d’abord formé via des ventes croisées dans les boutiques d’autoradio, avant que les fabricants ne l’intègrent ensuite comme option. J’ai moi-même connu ce type de parcours avec des dispositifs antivol : commencer petit, construire une base de clients, puis approcher progressivement les grandes entreprises est souvent efficace.

  • On peut aussi mettre en avant le fait que des concurrents ont déjà adopté ce pop, afin de déclencher du FOMO (la peur de passer à côté).

• Dans l’enterprise, il ne suffit pas de vendre seulement au CTO. Si l’entreprise joue un rôle vraiment central, comme AWS ou Azure, convaincre le CTO et quelques ingénieurs clés peut suffire à faire bouger toute l’organisation ; mais pour la plupart des logiciels, la décision revient souvent à un line manager, un directeur ou un responsable de département. Il faut même parfois segmenter très finement la cible, car chaque département peut adopter des logiciels différents.

• Les marketplaces B2B2C sont particulièrement intéressantes. Dans un modèle où l’on ne facture pas les utilisateurs « B2B » mais où l’on prélève une commission sur chaque transaction, on transforme ces utilisateurs en force commerciale distribuée. Il faut aider chacun d’eux à attirer des clients B2C via sa propre instance. Du point de vue de l’équipe fondatrice, cela donne souvent l’impression qu’il y a énormément de choses à construire et que tout devient confus, mais l’avantage est qu’avec une faible barrière à l’entrée initiale, le chiffre d’affaires peut croître naturellement très vite chaque fois qu’un compte transmet bien de la valeur au client final.

• Ce sujet nous parle aussi dans notre entreprise. Nous développons une API de business intelligence liée à l’entity resolution, et comme cela implique à la fois les équipes engineering, produit et data science, la séparation entre acheteurs et utilisateurs devient complexe. Les ingénieurs comprennent intuitivement la difficulté du matching de données complexes d’entreprise, mais les dirigeants ont tendance à voir seulement un projet qui prend du retard. En ce moment, une approche du type « votre équipe passe des mois sur le matching de données » est donc plus convaincante. Une entreprise a tenté de le construire elle-même pendant 10 ans, et cela ne fonctionne toujours pas correctement. Bien sûr, nous constatons aussi que l’approche varie selon l’entreprise et le contexte.

  • Je suis curieux de savoir comment vous communiquez cette valeur technique aux utilisateurs. Est-ce que vous commencez la conversation avec un cold e-mail envoyé à des ingénieurs, puis vous élargissez ensuite ?

• Un autre modèle possible est celui de TikTok : prendre simplement un pourcentage au milieu de chaque transaction.