Pourquoi le trafic ne prouve pas qu’un produit répond à une demande
Dans mon article de 2017, je présentais des pourcentages que je ne pouvais pas démontrer et je promettais une niche plus rentable que les autres. Je retire ces affirmations.
La leçon utile vient de mon expérience avec pH7CMS. Le projet attirait du trafic et de la curiosité, mais cet intérêt ne produisait pas la demande commerciale que j’espérais. J’avais pris l’audience pour une validation du produit.
Ce sont deux signaux différents.
Une visite mesure l’attention
Une personne peut ouvrir une page pour apprendre, comparer, télécharger un projet open source ou satisfaire sa curiosité. Elle peut apprécier le travail sans avoir le problème que le produit veut résoudre. Elle peut aussi avoir ce problème sans vouloir payer pour cette solution.
Je ne demande donc plus seulement combien de personnes arrivent. Je cherche à comprendre pourquoi elles viennent et ce qu’elles essaient de faire.
Une requête de recherche, une étoile GitHub ou un téléchargement reste utile. Aucun de ces événements ne démontre seul qu’une personne utilisera le produit dans son activité.
Je sépare les niveaux de preuve
Je classe les signaux dans un ordre simple :
- Audience : une personne voit la page ou découvre le projet.
- Intérêt : elle lit la documentation, regarde une démonstration ou pose une question précise.
- Activation : elle termine l’action principale du produit.
- Engagement : elle investit du temps, importe des données ou invite un collègue.
- Paiement : elle accepte un prix réel pour une offre définie.
- Rétention : elle revient parce que le produit reste utile.
Chaque niveau répond à une question différente. Beaucoup de visites avec peu d’activations indiquent peut-être un mauvais public, une promesse imprécise ou un démarrage trop difficile. Des activations sans rétention signalent plutôt que la valeur ne dure pas.
Je cherche le coût du problème
Une idée devient plus crédible quand je peux décrire le problème sans parler de ma solution.
Je demande aux personnes concernées ce qu’elles font aujourd’hui, à quelle fréquence le problème revient, ce qu’il leur coûte et pourquoi les solutions existantes ne conviennent pas. Je préfère les exemples récents aux opinions générales.
« Ce serait pratique » reste un signal faible. « Je recopie ce rapport chaque vendredi et une erreur bloque la facturation » décrit un travail, une fréquence et une conséquence.
Je vérifie aussi qui décide. L’utilisateur, l’acheteur et la personne qui approuve l’installation peuvent être différents. Un produit apprécié par l’utilisateur peut rester impossible à vendre si personne ne possède le budget ou le droit de l’adopter.
Tester une offre avant une construction longue
Je peux réduire le risque avec une version très limitée :
- une page qui décrit un problème précis et une offre réelle ;
- une démonstration manuelle du résultat attendu ;
- un pilote avec un périmètre et une durée définis ;
- un prix présenté avant que tout soit construit ;
- une liste d’attente qui demande le contexte d’usage, pas seulement une adresse e-mail.
Le but n’est pas de faire croire que le produit existe déjà. Je précise ce qui fonctionne, ce qui est manuel et ce qui reste à construire.
Une réponse négative aide aussi. Si les personnes comprennent l’offre mais refusent d’y consacrer du temps ou de l’argent, je dois revoir le problème, le public ou la solution avant d’ajouter du code.
Mesurer la progression qui compte
Je choisis une mesure liée à chaque étape. Pour l’activation, je mesure l’action qui produit la première valeur. Pour la rétention, je regarde si cette action revient au rythme naturel du problème. Pour le paiement, je sépare les demandes de devis, les essais et les transactions réelles.
Je garde le trafic comme mesure de distribution. Je ne lui demande plus de prouver la valeur du produit.
Cette distinction m’aurait évité de consacrer autant de temps à certains projets. Elle guide maintenant mes décisions : l’attention ouvre une conversation, mais seuls l’usage, l’engagement et le paiement montrent qu’une demande commence à exister.
Pierre-Henry Soria