Audit de conversion
Votre mission n'est pas de rapporter des chiffres. C'est de terminer chaque audit par une décision : la fuite qui coûte le plus, le changement que vous déploieriez, et le nombre que ce changement doit battre. Un graphique qui ne change rien à ce que personne fait ensuite est une perte de temps pour tout le monde.
La règle unique qui régit tout
Corrigez la plus grosse fuite, pas la plus facile. La conversion est multiplicative — un entonnoir qui passe de 100 → 40 → 36 → 34 a une étape catastrophique et trois bonnes. Doubler l'étape 36 → 34 (une étape à 94 %) ne vaut presque rien ; passer l'étape 100 → 40 à 55 élève l'ensemble de l'entonnoir d'environ 38 %. Classez toujours les étapes par nombre absolu d'utilisateurs perdus, pas par pourcentage ni par l'aspect agaçant de l'étape. La page la plus laide est rarement la plus coûteuse.
Étape 1 : dessinez l'entonnoir avant de regarder les données
Écrivez les étapes réelles qu'un utilisateur traverse, dans l'ordre, sous forme d'événements — pas de pages. « arrivé → vu les prix → commencé l'inscription → vérifié l'email → terminé la configuration → effectué l'action principale → revenu au jour 7. » Si vous ne pouvez pas nommer l'étape, vous ne pouvez pas la mesurer, et si deux parcours différents sont regroupés en une seule étape, tous les chiffres en aval sont des mensonges.
Deux choses qui cassent silencieusement tout audit d'entonnoir :
- Populations mélangées. Le trafic payant, organique et les flux d'invitation convertissent à des taux radicalement différents. Les moyenner cache à la fois le bon et le mauvais. Segmentez par source avant de conclure quoi que ce soit.
- Le dénominateur a bougé. Une baisse de taux de conversion est généralement un changement de mix de trafic, pas une régression produit. Vérifiez si le nombre à l'étape supérieure a changé de forme avant de chercher un bug produit.
Étape 2 : mesurez étape par étape, puis classez par utilisateurs perdus
Pour chaque étape : entrés, complétés, %, et perte absolue. Triez par perte absolue. Cette liste triée est l'audit — tout le reste est commentaire.
Ensuite, sur la pire étape uniquement, posez les trois questions de diagnostic :
- Est-ce un problème de motivation ? Les utilisateurs ne comprennent pas ou ne veulent pas l'étape suivante. Symptôme : ils partent sans interagir. La solution se trouve dans le copy, la preuve sociale, la clarté tarifaire.
- Est-ce un problème de friction ? Les utilisateurs le veulent et le flux les combat. Symptôme : ils commencent l'étape et abandonnent en cours de route (formulaires commencés sans soumissions, tentatives, erreurs). La solution se trouve dans moins de champs, moins de décisions, de meilleures valeurs par défaut, une meilleure gestion des erreurs.
- Est-ce un problème d'adéquation ? Les utilisateurs qui arrivent n'allaient jamais convertir. Symptôme : l'étape convertit bien pour une source et très mal pour une autre. La solution se trouve en amont, dans le ciblage, pas sur la page.
Se tromper dans cette classification est la manière la plus courante de produire des mois de travail inutile — on ne peut pas sortir d'un problème d'adéquation par un test A/B.
Étape 3 : nommez les métriques de vanité à voix haute
Une métrique est de la vanité si elle peut augmenter pendant que l'entreprise stagne. Pages vues, inscriptions sans activation, « engagement », nombre brut d'abonnés, totaux cumulés (qui ne peuvent qu'augmenter). Remplacez chaque métrique par sa version avec un dénominateur et un intervalle de temps : pas « 10 000 inscriptions » mais « inscription → activation sous 7 jours, par cohorte ».
Choisissez exactement une étoile polaire : la métrique qui ne bouge que lorsqu'un utilisateur obtient une vraie valeur, que l'équipe peut réellement influencer, et qui mène le revenu plutôt que de le suivre. Tout le reste est une métrique de soutien ou une barrière de sécurité. Consultez la référence pour connaître les fourchettes de benchmarks permettant de valider une étape avant de la déclarer défaillante.
Étape 4 : concevez le test qui le prouve
Chaque recommandation est accompagnée d'une expérience et d'un chiffre pré-engagé :
- Un changement par test. Regrouper trois changements, et une victoire ne vous apprend rien sur lequel a fonctionné, et une défaite vous apprend encore moins.
- Fixez l'objectif et la durée avant de commencer. « L'étape 2 passe de 40 % à 48 %, mesuré sur deux semaines complètes. » Décider du seuil après avoir vu les données, c'est ainsi que les équipes déploient des perdants.
- Utilisez des semaines complètes. Le trafic de semaine et de week-end diffère ; un test de 4 jours n'est pas fiable.
- Un test sous-dimensionné est pire que pas de test du tout. Si l'étape ne reçoit que quelques centaines d'utilisateurs par semaine, une petite amélioration est impossible à mesurer — soit testez quelque chose d'assez grand pour se voir, soit déployez simplement la version manifestement meilleure et passez à autre chose. Ne blanchissez pas une supposition avec des statistiques bidon.
- Déclarez-le mort à l'heure prévue. Un test qui n'a pas atteint son objectif à sa date de fin a perdu. Le prolonger jusqu'à ce qu'il gagne n'est pas un test, c'est une recherche de bruit.
Le livrable
Quatre lignes, dans cet ordre, à chaque fois :
- La fuite — quelle étape, nombre absolu d'utilisateurs perdus, % de la perte totale.
- Le diagnostic — motivation / friction / adéquation, avec les preuves qui le confirment.
- Le changement — une chose à déployer.
- Le nombre — ce qu'il doit battre, avant quelle date, sinon c'est annulé.
Si vous ne pouvez pas remplir la ligne 4, vous n'avez pas encore de recommandation — vous avez une opinion.
Voir references/funnel-benchmarks-and-test-design.md pour les fourchettes de benchmarks étape par étape, les règles empiriques sur la taille des échantillons, le tableau de conversion vanité → réel, et les modèles d'audit et d'expérience.