J'ai vu trop de roadmaps product remplies de fonctionnalités brillantes, bien conçues et parfaitement inutiles. Les équipes ont dépensé des mois à peaufiner l'expérience, les marketeurs ont préparé des lancements, et à la fin : personne n'utilise ce qui a été développé. C'est coûteux en argent, en temps et — pire — en confiance. Après avoir accompagné des équipes produit et des dirigeants sur ces sujets, j'ai systématisé un protocole simple : 7 tests avant développement. L'idée est de rater vite sur papier plutôt que lentement en production.
Pourquoi un protocole avant développement ?
Parce que le développement est la phase la plus chère et la plus engageante d'un projet. Toutes les hypothèses doivent avoir été challengées au préalable : besoin réel, valeur pour l'utilisateur, viabilité commerciale, simplicité de mise en œuvre, risque technique et impact sur l'usage existant. Ces tests n'éliminent pas le risque, mais ils le réduisent fortement et alignent l'équipe.
Le principe général
Chaque fonctionnalité doit passer par au moins un des 7 tests, idéalement plusieurs. Les tests vont du plus rapide et peu coûteux (conversation, landing page) au plus structuré (prototype cliquable, test A/B). L'objectif est de collecter des données réelles ou des signaux fiables qui justifient l'investissement en développement.
Les 7 tests avant développement
- Test de demande explicite (interviews qualitatives) : Parlez directement aux utilisateurs cibles. Formulez l'hypothèse en une phrase et demandez : « Est-ce que vous feriez ceci ? » Cherchez les comportements passés, pas seulement les opinions. Une phrase typique : « Racontez-moi la dernière fois où vous avez rencontré ce problème. » Si les témoignages sont rares, la fonctionnalité est probablement une solution à la recherche d'un problème.
- Test d'engagement passif (landing page) : Créez une page qui décrit la fonctionnalité, ajoutez un call-to-action (pré-inscription, "Je veux", "M'en parler") et mesurez le taux de conversion. Testez avec du trafic ciblé via publicités payantes (Google Ads, Facebook, LinkedIn selon audience). Si vous obtenez un CTR et une conversion conformes aux benchmarks de votre acquisition, vous avez un signal fort.
- Test de monétisation (pré-vente ou pricing test) : Proposez la fonctionnalité en pré-commande ou simulez une page de pricing. Le fait que des utilisateurs paient (ou s'engagent à payer) avant le développement est le signal le plus fort. Même un petit test de 10 transactions validées vaut souvent mieux que des mois d'enquêtes.
- Test d'usage rapide (concierge / smoke test) : Offrez la fonctionnalité manuellement sans la construire (concierge). Cela permet de valider l'usage réel et d'itérer sur le process. Ex : pour un algorithme de recommandation, envoyez des recommandations manuellement pendant quelques semaines et mesurez l'engagement.
- Test d'UX minimal (prototype cliquable) : Créez un prototype interactif (Figma, InVision) et faites des tests utilisateurs pour évaluer la compréhension du flux et l'effort requis. Un bon prototype révèle rapidement les frictions et permet d'estimer la complexité technique réelle.
- Test d'impact produit (expérimentation A/B à petite échelle) : Si possible, implémentez une version très légère côté backend (feature flag) ou simulez le comportement pour une petite portion d'utilisateurs. Mesurez les KPIs clés (rétention, conversion, NPS). Une amélioration significative sur un échantillon pilote valide l'impact.
- Test de risque technique et opérationnel : Faites une revue rapide avec engineering, sécurité et support pour lister les risques (scalabilité, données, conformité). Estimez le coût en heures et identifiez les dépendances. Si les risques sont majeurs, explorez des alternatives plus simples.
Comment exécuter ces tests en pratique
Voici une séquence pragmatique que j'utilise :
- Commencez par interviews qualitatives et une landing page en parallèle — vous combinez sentiment et intérêt réel.
- Si la landing page convertit, proposez une pré-vente ou un essai payant pour valider la monétisation.
- Simultanément, préparez un prototype cliquable pour réduire l'incertitude UX.
- Avant d'investir en dev, faites un test concierge pour tester le process opérationnel.
- Si les signaux sont positifs, lancez un pilote technique avec feature flag et expérimentation A/B.
- Toujours finir par une revue des risques techniques et planifier des milestones courts (sprints de 2–4 semaines).
Exemples concrets
J'ai accompagné une fintech qui voulait ajouter un "assistant d'épargne intelligent". Au départ, idée séduisante mais vague. On a fait :
- 5 interviews d'utilisateurs intensifs pour identifier les frictions d'épargne.
- Une landing page qui expliquait l'assistant et proposait une liste d'attente — 7% de conversion depuis un trafic ciblé LinkedIn, ce qui était encourageant.
- Un test concierge pendant 4 semaines : envoi manuel de conseils d'épargne personnalisés. Mesure : 23% des inscrits ont modifié leurs transferts bancaires.
- Prototype cliquable pour valider le parcours dans l'app : on a réduit l'effort utilisateur de 40% après itération.
- Pilote technique avec 2% des utilisateurs : augmentation nette de la rétention sur 30 jours.
Résultat : la fonctionnalité a été développée progressivement, avec MVP en 3 sprints, et a dépassé ses objectifs de valeur client.
Indicateurs à suivre pour décider
Chaque test produit des métriques actionnables. Voici une table de correspondance simplifiée :
| Test | Signal positif | Seuil pratique |
|---|---|---|
| Interviews | Témoignages récurrents du problème | ≥ 50% des interviews décrivent le problème comme prioritaire |
| Landing page | Taux de conversion sur CTA | Varie selon canal (ex. 3–7% pour trafic qualifié) |
| Pré-vente | Transactions réelles | Au moins 10 transactions validées |
| Concierge | Action réelle de l'utilisateur | Usage répété ou changement de comportement |
| Prototype | Compréhension du flux & time-to-task | Tâche complétée sans aide par >80% des testeurs |
| A/B pilot | Impact sur KPI clé | Amélioration statistiquement significative sur échantillon |
| Revue technique | Risques identifiés & atténués | Plan de mitigation et estimation claire |
Pièges courants et comment les éviter
Quelques erreurs que je vois souvent :
- Se satisfaire d'opinions plutôt que de comportements. Les gens disent souvent ce qu'ils pensent devoir faire, pas ce qu'ils font réellement.
- Tester avec une audience non qualifiée. Un test payé par trafic générique ne vaut pas un test sur votre cible métier.
- Confondre intérêt et volonté de payer. Le clic ne vaut pas la carte de crédit.
- Ignorer la dette technique et les impacts sur l'existant. Les features qui complexifient votre produit tuent la vitesse à long terme.
Processus décisionnel simple
Après les tests, demandez-vous : 1) avons-nous un signal utilisateur solide ? 2) y a-t-il une justification économique ? 3) les risques techniques sont-ils maîtrisés ? Si la réponse est oui à ces trois questions, planifiez le développement avec des jalons clairs et des indicateurs de sortie pour arrêter si les résultats dévient.
Rappellez-vous : l'objectif n'est pas de supprimer l'innovation, mais d'éviter le gaspillage. Un bon produit est la somme d'hypothèses testées et validées, pas d'idées non vérifiées. En appliquant ces 7 tests, vous aurez beaucoup plus de chances de lancer des fonctionnalités que les utilisateurs adopteront réellement.