Techniques de terrain : discovery technique, démo sans script et objections de fond
La psychologie du chapitre précédent se traduit en gestes concrets. Ce chapitre couvre les quatre moments de vérité d'un cycle de vente technique : la discovery, la démo, le parcours d'évaluation et le traitement des objections structurantes.
La discovery technique : parler architecture, pas bénéfices
Une discovery classique cherche la douleur business (« combien cela vous coûte-t-il ? »). Face à un interlocuteur technique, commencer par là vous classe immédiatement dans la catégorie « commercial qui déroule son script ». La discovery technique inverse l'ordre : d'abord le système, ensuite la douleur, enfin l'enjeu business.
Questions d'ouverture qui établissent la crédibilité :
- « Comment c'est architecturé aujourd'hui ? Qu'est-ce qui est en amont et en aval ? »
- « Qu'est-ce que vous avez déjà essayé — en interne ou en externe — et pourquoi ça n'a pas tenu ? »
- « Quelles sont vos contraintes non négociables : hébergement, conformité, latence, langages, équipe ? »
- « Si vous le construisiez vous-mêmes, vous le feriez comment ? »
Cette dernière question est doublement puissante : elle vous renseigne sur le scénario build vs buy avant qu'il ne devienne une objection, et elle traite votre interlocuteur en ingénieur — pas en cible.
À retenir : en discovery technique, chaque question doit prouver que vous comprenez son monde. Une seule question générique (« quels sont vos enjeux de transformation digitale ? ») suffit à vous disqualifier. Préparez vos questions au niveau de précision de votre interlocuteur — l'IA vous y aidera, chapitre 6.
Règle d'or complémentaire : notez les termes exacts qu'utilise le prospect (noms de composants, contraintes, volumétries) et réutilisez-les tels quels dans tous vos livrables. Le vocabulaire approximatif est un marqueur d'inattention que les techniques détectent instantanément.
La démo « terminal-first » : montrer le vrai produit, pas le film du produit
La démo scriptée — parcours idéal, données préparées, transitions fluides — est conçue pour rassurer. Sur un public technique, elle produit l'effet inverse : tout le monde sait que les démos sont truquées, donc une démo parfaite ne prouve rien, sinon votre habileté à truquer.
La démo qui convainc un technique suit quatre principes :
- Montrer l'envers du décor — la configuration réelle, le fichier de config, l'appel API brut, les logs. Ce que les autres vendeurs cachent est précisément ce que votre audience veut voir
- Dérouler un cas non préparé — « donnez-moi un de vos cas réels, on le fait maintenant ». Le risque est réel, et c'est exactement pour ça que ça fonctionne : une démo improvisée réussie vaut dix démos parfaites
- Montrer une limite volontairement — « ici, sur ce type de charge, on est moins bons que X ; voici comment on le contourne ». L'effet pratfall joue à plein : l'imperfection avouée crédibilise tout le reste
- Laisser le clavier — dès que possible, c'est le prospect qui manipule. Ce qu'il fait lui-même nourrit son besoin de compétence et devient sa propre expérience (niveau 1 de la hiérarchie de preuve)
La documentation comme commercial silencieux
Pour un acheteur qui préfère lire que parler, votre documentation est votre meilleur vendeur — ou votre pire. Les éléments que les acheteurs techniques inspectent systématiquement avant tout contact :
| Artefact | Ce qu'il signale |
|---|---|
| Documentation publique, sans inscription | Vous n'avez rien à cacher ; l'évaluation autonome est respectée |
| Quickstart en moins de 15 minutes | Le time-to-value est réel, pas marketing |
| Changelog actif et page de statut des incidents | Le produit est vivant et l'éditeur est honnête sur ses pannes |
| Page de limites connues et de comparaison loyale | Rare, donc différenciant : c'est le signal de confiance maximal |
| Exemples de code maintenus, SDK propres | L'équipe produit pense développeur |
Si vous ne contrôlez pas la documentation (c'est le produit qui la fait), vous contrôlez en revanche votre usage : envoyer le lien profond exact vers la section qui répond à la question posée, plutôt qu'une plaquette PDF, est un geste de vente technique à part entière.
Le parcours d'évaluation : POC self-service et critères co-signés
L'erreur classique est de traiter le POC comme une concession (« bon, d'accord, on vous laisse essayer »). Pour un acheteur technique, le POC n'est pas une étape du cycle de vente : c'est le cycle de vente. Tout ce qui précède ne sert qu'à y arriver dans de bonnes conditions.
Le design d'un POC qui convertit :
- Périmètre minimal et réel — un cas d'usage du prospect, pas un scénario de votre catalogue ; des données représentatives, pas un échantillon idéal
- Critères de succès écrits et co-signés avant de commencer — métriques chiffrées, seuils, méthode de mesure. Sans cela, le POC « réussit » techniquement et meurt commercialement, car personne n'avait défini ce que réussir voulait dire
- Durée courte et bornée — deux à quatre semaines. Un POC sans date de fin est un projet gratuit
- Une clause de réciprocité — « si les critères sont atteints, que se passe-t-il ? ». La réponse engage le prospect sur la suite (présentation au comité, phase pilote payante) et révèle les blocages cachés pendant qu'il est encore temps
- Un canal direct avec un humain technique — Slack partagé ou équivalent avec un sales engineer. La qualité du support pendant le POC est lue comme un échantillon de la qualité du support après achat
Traiter les quatre objections techniques structurantes
« Et la sécurité ? Où vont nos données ? »
Ne jamais répondre en généralités (« nous prenons la sécurité très au sérieux » — phrase qui signale exactement l'inverse). Répondre en artefacts : architecture de données, certifications, options d'hébergement, DPA. Et surtout : impliquer l'équipe sécurité du prospect tôt, volontairement. Le véto sécurité tardif est l'un des cinq tueurs silencieux ; sa prévention vaut tous les arguments.
« Ça tiendra notre charge ? »
L'objection scalabilité ne se traite pas par affirmation mais par proposition de protocole : « quelle est votre volumétrie de pointe ? Définissons un test de charge dans le POC avec vos chiffres ». Offrir la mesure plutôt que la promesse, c'est parler la langue de l'ingénieur.
« On va être verrouillés chez vous » (lock-in)
Objection rationnelle : le coût de sortie fait partie du coût total. Réponse crédible en trois temps : montrer les mécanismes de réversibilité (export, API ouvertes, formats standards), chiffrer honnêtement l'effort de migration sortante, et reconnaître ce qui, en revanche, serait coûteux à quitter. L'aveu partiel rend le reste audible.
« On peut le développer nous-mêmes »
Le NIH, vu au chapitre 2. Tactique de terrain : ne jamais contester la capacité, toujours questionner l'opportunité. Script : « Vous en êtes parfaitement capables — la vraie question, c'est : est-ce que ce composant est différenciant pour votre métier ? S'il ne l'est pas, chaque mois d'ingénieur que vous y mettez est un mois pris sur ce qui l'est. Faisons le calcul ensemble, honnêtement — et si le build gagne, je vous le dirai. » Le chiffrage complet est au chapitre suivant.
La règle absolue : zéro bluff
Toutes les techniques de ce chapitre reposent sur un socle unique : ne jamais improviser une réponse technique. Le script à mémoriser pour les questions qui vous dépassent :
« Bonne question — je préfère ne pas vous répondre approximativement. Je note, je vérifie avec l'équipe produit, et vous avez la réponse exacte demain avant midi. »
Puis, évidemment, tenir le délai. Trois effets : vous nourrissez votre crédibilité au lieu de la risquer, vous créez un point de contact légitime (la réponse), et vous démontrez le comportement que le prospect peut attendre de votre entreprise après signature.
À retenir : face à un acheteur technique, une réponse exacte demain vaut infiniment plus qu'une réponse approximative maintenant. Le bluff détecté ne coûte pas un point — il coûte le deal.
Le chapitre suivant change d'altitude : comment ces dynamiques s'inscrivent dans un modèle business — motion bottom-up, PQL, et la traduction de la valeur technique en langage CFO.