Trente millions de visiteurs uniques par mois. Quatre-vingt-dix millions d'annonces en ligne. Six cents personnes en product et tech, une soixantaine de feature teams. À cette échelle, mesurer l'impact d'une feature n'est pas une question de méthodologie pure. C'est une question d'écosystème, de culture et de décision. Romaïssa Cherbal a construit cette méthode sur plusieurs années chez Leboncoin. Elle la dit pragmatique, imparfaite, et actionnable.
1. Confondre signal local et impact global
La vision naïve de la mesure d'impact est simple : on pose un KPI, on lance un A/B test, on prend une décision. C'est rassurant. C'est faux.
Romaïssa l'apprend en arrivant chez Leboncoin après une expérience chez Meetic centré sur le revenu. Une feature n'impacte jamais juste un seul KPI isolé. Elle va perturber tout un écosystème. Mesurer son impact réel, ce n'est pas juste faire un test. C'est comprendre où elle agit, ce qu'elle peut déplacer, et surtout, qu'est-ce que je casse en lançant cette feature.
Trois exemples de lectures naïves
Lancement d'un nouveau moyen de paiement : on voit de l'usage, on conclut que c'est un succès. La vraie question : est-ce que ça génère des transactions incrémentales ou est-ce qu'on cannibalise un moyen de paiement existant moins coûteux ?
Lancement d'un outil anti-fraude : on voit la fraude baisser. Mais pas de vente, pas de fraude. Ce qu'il faut regarder : l'équilibre entre réduction de fraude et taux d'acceptation, les faux positifs, les transactions perdues.
Lancement d'une feature de négociation : fort usage. Mais l'usage ne dit pas si les offres sont acceptées, ni ce que ça crée comme friction pour les vendeurs qui ne veulent pas négocier.
"On ne modifie pas juste un chiffre en lançant une nouvelle feature, on ne modifie pas juste un KPI, on va venir toucher à l'équilibre de l'intégralité de l'écosystème."
2. Le end-to-end avant le KPI
Première étape de la méthode : cartographier l'écosystème. Pas seulement le scope sur lequel on travaille. C'est comprendre le end-to-end. À quoi sert ce produit ? Qui sont ses utilisateurs ? Quelle est la consumer journey classique ?
L'exemple de la protection panne
Une assurance sur les produits de seconde main achetés sur Leboncoin. Le besoin utilisateur est clair. Mais lancer cette feature, c'est aussi ajouter une étape dans le funnel de conversion. Est-ce qu'on cannibalise d'autres produits ? Quel impact sur le support client ? Quel impact sur la fraude ? Ce n'est pas juste j'ai lancé une feature, cool, j'ai fait plus de revenus.
3. Deux lectures obligatoires
La deuxième étape est le choix des KPIs. Romaïssa utilise un modèle en deux axes, qu'elle appelle le glaive et le bouclier.
Le glaive : KPI offensif
Qu'est-ce que je cherche à impacter directement avec cette feature ? Ne me dites pas le revenu ou la conversion. On impacte le revenu uniquement quand on travaille sur les pricing. C'est vraiment le KPI le plus proche de la feature.
Le bouclier : KPI défensif
Qu'est-ce que je ne veux pas casser ? C'est du damage control. Exemple : lancement de la protection panne, KPI offensif = taux de prise. KPI défensif = taux de conversion du funnel et satisfaction utilisateur.
Seuils et baselines
Ce n'est pas du doigt mouillé. On récupère tous les A/B tests qu'on a faits. On travaille avec la data et après, on a une idée de l'écosystème. L'arbitrage reste une décision produit : accepte-t-on de perdre un pour cent de revenu si on gagne deux points de NPS ?
Coordination entre équipes
Chez Leboncoin, plusieurs feature teams peuvent intervenir sur le même tunnel. Il faut communiquer en avance de phase avec les autres. Le guardian métrique, tu peux mettre un seuil sous lequel tu ne descends pas et surtout, tu lances progressivement.
4. Quatre niveaux de tests selon le risque
Une fois qu'on sait quoi mesurer, il faut choisir comment tester. Romaïssa décrit quatre niveaux, utilisés selon le contexte et le niveau de risque.
La fake door
Un bouton ou une promotion qui mène vers feature en cours de construction. Peu d'investissement, signal rapide. Souvent, il y a une levée de bouclier parce que derrière, il n'y a rien. Mais c'est le bon outil pour valider un concept avant un investissement massif.
Le roll-out progressif
Pas parfait parce qu'il y a plein d'autres choses qui se passent dans l'écosystème. Mais si vous lancez un truc à cinq pour cent et que vos tickets service clients font plus dix pour cent, vous savez qu'il y a un problème.
Le proof of concept
Un apprentissage à petite échelle, rapide, pas scalable. Je sais que je ne pourrai jamais scale, mais ça me donnera le signal de savoir si je dois investir ou pas.
L'A/B test complet
Chez Leboncoin, ils utilisent Confidence, l'outil de Spotify. High investment. Mais par contre, je sais que quand je lance, mes KPIs vont être qualitatifs. Ce n'est pas toujours accessible : certains tests nécessiteraient des années de collecte pour être significatifs.
5. Trois fake doors en un mois pour sécuriser un demi-million d'euros de dev
L'exemple le plus détaillé du live : le lancement de la protection panne, une garantie sur les produits de seconde main.
La feature allait prendre entre trois et six mois de développement. Avant d'investir, l'équipe a voulu valider le concept. Trois fake doors enchaînées sur un mois, entre dix jours et deux semaines chacune.
Les trois tests
Premier test : tester le positionnement marketing. Comment expliquer à l'utilisateur que son achat est garanti ?
Deuxième test : tester le parcours. Comment trouver le meilleur parcours pour faire en sorte que ça ne crée pas trop de friction ?
Troisième test : tester la meilleure combinaison de parcours pour atteindre les objectifs utilisateur et de revenu.
Le résultat
Lancement sans stress, fois deux par rapport au budget annoncé. Parce qu'on avait trouvé le bon positionnement, on avait testé différents parcours, et on s'était planté en fake door. On avait su ce qui fonctionnait.
L'arbre décisionnel
L'équipe avait préparé des hypothèses de backup. Ce n'est pas juste j'y vais avec une solution imparfaite. On avait trois hypothèses à lancer. La Head of Product avait un arbre de décision : si cette hypothèse ne marche pas, on teste ça, on teste ça.
6. Si tu fais un truc imparfait, c'est toujours mieux que de ne rien faire
Romaïssa est directe sur le perfectionnisme : c'est un piège. Elle illustre avec un test de prix. L'A/B test dans les règles de l'art aurait nécessité trois mille six cents configurations en prod, peut-être deux ans de collecte pour des résultats significatifs. Décision : tout simplifier. Une seule catégorie, un test cinquante-cinquante. Lancé en moins d'un mois, premiers résultats en prod.
La culture du fail fast
Ce n'est pas adopté par toutes les équipes. Certaines ont une culture un peu plus itérative, c'est souvent porté par les PM en place ou par un ou deux devs. La culture du Boncoin, c'est plus une culture de on va vite. Et parce qu'on a trente millions d'utilisateurs, on est en concurrence avec à peu près la Terre entière.
Sur Spotify : sur mille A/B tests, si on arrive à en faire passer dix pour cent, on est déjà très heureux.
"Si tu fais un truc imparfait, c'est toujours mieux que de ne rien faire. C'est le fameux fail fast, learn fast."
7. La culture ne se décrète pas, elle se vit au quotidien
Le troisième chapitre est le plus important selon Romaïssa. La méthode ne vaut rien si la culture ne permet pas de l'appliquer.
Les démos de tribe
Les PM, engineering managers et devs viennent présenter de la data. Ça peut être de la data technique. J'ai fait un refacto de code, ça me permet de gagner vingt pour cent de temps. Objectif : dédramatiser la data.
Le monthly data
Les équipes viennent, elles racontent ce qu'elles ont appris via la data, quels A/B tests elles ont lancés, qu'est-ce qu'elles ont appris. Au début, c'était mais qu'est-ce qu'on va raconter dans ce meeting ? Et à la fin, c'est trop cool, j'ai appris plein de choses.
Les points d'expertise ad hoc
Une fois par an, on a notre spécialiste de la fraude monétique qui nous raconte ce qui s'est passé sur la fraude au paiement.
Le binômage produit-tech
Chez Leboncoin, du CPO-CTO jusqu'aux équipes, on a un binômage. On assume la décision ensemble. Il n'y a pas d'égo de périmètre. C'est notre produit, notre feature, on l'a fait évoluer ensemble.
Les décisions sans regret
C'est comme le rabbit hole d'Internet. Vous pouvez y passer des heures et avoir cinq hypothèses avec cinq datas différentes. À un moment, il faut être capable de prendre une décision. C'est ce qu'on nous demande en tant que product manager.
8. Mesurer, ce n'est pas prouver qu'on a réussi
"Mesurer, ce n'est pas juste prouver qu'on a réussi, c'est vraiment ça vous permet de décider. Et il n'y a rien, tous les KPIs du monde, tous les A/B tests du monde ne vont pas vous empêcher de prendre une décision. Donc, c'est notre taf en tant que product de prendre des décisions et de les assumer après."
Sur l'A/B test trop cher : une feature team, c'est un million d'euros. Six mois de dev, c'est minimum cinq cents mille euros que j'ai mis sur la table. Si je me plante à cinq cents mille euros, est-ce que c'est acceptable ? La réponse va d'elle-même.
Sur les développeurs qu'on a l'impression de faire travailler pour rien : c'est de savoir embarquer ses équipes. Est-ce qu'on va sur six mois de dev ? Et surtout, qu'est-ce qu'on aura appris ? Il faut saisir l'opportunité technique pour lancer quelque chose.