Calculateur ROI programme d'expérimentation : projection chiffrée de vos tests A/B
Le seul calculateur qui permet d’estimer le gain de son programme d’expérimentation qui applique la correction Winner’s Curse pour déterminer l’impact de vos tests A/B.
- Projection corrigée du biais de sélection sur 12 à 36 mois
- Prend en compte les pertes évitées par les décisions bloquées
- Préparation du pitch au CODIR pour présenter avec assurance
- 100 % côté navigateur — aucune donnée stockée
0 €
générés par le programme · Correction WC appliquée (Lee & Shen, KDD 2018)
Outil de décision, pas une prédiction. Les chiffres s'appuient sur des corrections statistiques rigoureuses ; pilotage continu requis.
Évolution de la valeur
Performance projetée du programme · zoom sur les gains
Mensuel : valeur produite chaque mois, après application de la décroissance par type. Pratique pour visualiser la dynamique du programme.
Cumulatif : somme progressive de la valeur mois après mois. Pratique pour communiquer un total à un CFO ou un CODIR.
Les deux vues affichent la même valeur totale au dernier mois — c'est juste une question d'angle de présentation.
Linéaire : décroissance régulière sur la durée de vie configurée (mois 1 → 100%, dernier mois → 0%). Mode prudent.
Équilibré : décroissance avec plateau résiduel par type (15% tweaks UI, 50% flows structurels, 85% ops). Plus défendable scientifiquement.
Réf. : Amazon Science, "Measuring long-term effects of experimentation", 2023.
Votre programme génère de la valeur réelle corrigée du Winner's Curse — c'est l'honnêteté statistique qui protège votre business case contre la surestimation classique.
Sans votre démarche, l'organisation aurait sorti les gains naïfs mais aurait aussi déployé les décisions coûteuses bloquées. Le solde net peut être fortement négatif.
Paramètres globaux
Plan de test
Positionnez vos tests A/B sur l'horizon. Cliquez sur une ligne pour éditer ses paramètres dans le panneau à droite.
Sélectionnez un test ou une décision dans la frise pour modifier ses paramètres.
Correction du biais de sélection (Winner's Curse)
Un test A/B qui franchit le seuil de significativité a tendance à surestimer son vrai uplift — c'est le Winner's Curse. Plus le test est sous-puissant, plus la surestimation est forte.
WC = max(0, uplift − σ · φ(b − z))
Où φ est la densité normale standard, b = 1.645 (seuil unilatéral 95%), z = uplift/σ (signal-to-noise ratio).
Source : Lee & Shen, "Winners Curse — Bias Estimation for Total Effects of Features in Online Controlled Experiments", ACM SIGKDD, 2018.
Erreur d'estimation σ par type de métrique
| Type | Formule σ | Modèle |
|---|---|---|
| Conversion | √(2(1−CR) / (n_arm · CR)) |
Binomial |
| AOV | CV / √(n_arm · CR) |
Normal (CV) |
| Retour | √(2·RR·(1−RR) / n_orders) / RR |
Binomial |
| Support | CV / √(n_arm · tpM/traffic) |
Normal (CV) |
| Ops | CV / √(trM · dur / 2) |
Normal (CV) |
n_arm = trafic effectif / 2. Le trafic effectif est divisé par le nombre de tests simultanés, mois par mois.
Décroissance avec plateau résiduel
gain(t) = gain₀ × (plateau + (1 − plateau) × max(0, 1 − (t−1)/(ls−1)))
| Type de test | Durée de vie | Plateau défaut |
|---|---|---|
| Tweak UI | 3–6 mois | 15% |
| Copy / messaging | 6–12 mois | 20% |
| Flow / UX structurel | 12–24 mois | 50% |
| Personnalisation | 24–36 mois | 60% |
| Support / ops | permanent | 85% |
Référence : Amazon Science, "Measuring the long-term effects of experimentation", 2023.
Calibrage du prior τ (shrinkage)
shrinkage = τ² / (τ² + σ²)
τ est l'écart-type a priori des vrais uplifts dans votre programme. Plus τ est bas, plus le shrinkage est agressif. La calibration empirique consiste à calculer l'écart-type des uplifts observés sur vos 20 derniers tests déployés.
| Situation | τ recommandé |
|---|---|
| Programme démarrant | 3–5% |
| Tests structurels (checkout) | 6–8% |
| Tweaks UI mineurs | 2–3% |
| Grands groupes matures | 4–6% |
| Programme mature (50+ tests) | calculer |
Référence : Kohavi, Tang, Xu. "Trustworthy Online Controlled Experiments", Cambridge University Press, 2020, chapitre 18.
Pourquoi projeter les gains d'un programme A/B ?
Une projection chiffrée de votre programme d'expérimentation n'est jamais totalement juste. Les uplifts des tests futurs sont incertains par construction. Le contexte business évolue. Un programme mature change radicalement en 18 mois. Alors pourquoi cet outil ?
Cet outil sert à éclairer une décision stratégique plutôt qu'à prédire un futur exact. Il répond à 4 questions concrètes :
2. Les petites victoires accumulées valent-elles le coup ? Un programme mature accumule 50 tests à +1-3%. Cette accumulation crée une valeur cumulée importante sur 12-36 mois.
3. La culture d'expérimentation protège-t-elle l'entreprise ? La moitié de la valeur vient des mauvaises décisions évitées grâce au testing.
4. Comment recalibrer le programme ? Comparez projection et mesure réelle trimestriellement. Recalibrez τ et les plateaux.
Qu'est-ce que ce calculateur ?
Ce calculateur produit une projection chiffrée et défendable de la valeur générée par votre programme d'expérimentation A/B sur 12 à 36 mois. Il s'adresse aux Heads of CRO, Product Managers, Heads of Growth et Directeurs Marketing qui doivent justifier un investissement CRO devant un CODIR ou un CFO.
• Un montant en € de gains projetés sur l'horizon
• Un ROI annualisé du programme
• La valeur des décisions bloquées par l'expérimentation
• Un graphique de projection mois par mois
Comment l'utiliser en 5 minutes
| 1 | Sélectionnez votre contexte dans le select en haut des paramètres (Startup / E-com mid / Grand groupe / B2B SaaS) |
|---|---|
| 2 | Ajustez les 3 champs essentiels : trafic mensuel, AOV (ou LTV pour SaaS), horizon |
| 3 | Ajoutez vos tests A/B planifiés dans la frise calendaire avec leurs hypothèses d'uplift |
| 4 | Ajoutez les décisions bloquées par l'expérimentation |
| 5 | Lisez les 4 KPI cards en haut pour le résumé exécutif |
| 6 | Présentez le rapport en mode CODIR |
Comment calibrer vos paramètres
| Paramètre | Comment le trouver |
|---|---|
| Trafic mensuel | GA4 : Rapports > Acquisition > Trafic total sur 30 jours |
| AOV / LTV | E-commerce = CA/commandes, SaaS = LTV client sur cohortes matures |
| Coût programme / an | Salaires équipe CRO + outils (plateforme de test, analytics) + agence |
| Prior τ | Écart-type des uplifts observés de vos 20 derniers tests déployés |
| Durée de vie | Par type de test — voir le preset affiché dans l'éditeur |
| Plateau résiduel | Conventions sectorielles (15% tweaks UI, 85% ops) |
Questions fréquentes
Pourquoi mon ROI affiché est-il plus bas que mes projections internes ?
Parce que cet outil applique la correction Winner's Curse, qui réduit les uplifts déclarés de 15-30% pour refléter le biais de sélection des tests significatifs.
Pourquoi ne pas inclure les gains des tests négatifs ?
Les tests négatifs sont comptés dans les « décisions bloquées » — leur valeur est la perte évitée en ne déployant pas.
Comment justifier la valeur des décisions bloquées au CFO ?
Documentez chaque décision bloquée avec : date, hypothèse testée, résultat du test, projection du CA perdu si déployée. Cf. méthodologie Lukas Vermeer (Booking.com).
Pourquoi 80% d'IC et pas 95% ?
80% est plus pertinent pour la prise de décision business. 95% est trop conservateur pour des projections stratégiques.
Pourquoi le plateau résiduel ne tombe-t-il jamais à zéro ?
Empiriquement, les gains structurels persistent (effet d'habitude, réduction durable de friction). Référence : Amazon Science 2023.
Que faire si je n'ai pas encore de tests passés pour calibrer τ ?
Utilisez la valeur par défaut du preset (3-10% selon le contexte). Recalibrez après vos 20 premiers tests.
Comment l'outil gère-t-il le partage de trafic entre tests simultanés ?
Le trafic effectif par test = trafic mensuel ÷ nombre de tests simultanés ce mois-ci.
Puis-je utiliser cet outil pour un programme de personnalisation ?
Oui, mais avec prudence. La personnalisation a une dynamique de gain différente (plus de variance entre segments).
L'outil est-il adapté pour les sites à faible trafic (< 10K/mois) ?
Partiellement. La correction WC mord très fort sur les tests sous-puissants. Regardez la bannière de statut de puissance dans l'éditeur.
Mes données sont-elles stockées ?
Non. Tous les calculs sont 100% côté navigateur. Aucune donnée ne sort de votre machine. Pas de cookies, pas de tracking.
Méthodologie détaillée
Pour le détail technique complet des formules, des corrections statistiques et des sources académiques, consultez l'onglet Méthodologie.
Limites et précautions méthodologiques
Cet outil produit une projection — pas une prévision certifiée. Les résultats dépendent de plusieurs hypothèses dont la précision varie entre ±15% et ±40% selon votre contexte.
• Applique la correction Winner's Curse (Lee & Shen 2018), état de l'art
• Modélise la persistance des gains avec plateau résiduel par type
• Intègre la valeur des décisions bloquées
• Différencie 7 types de métriques avec des formules σ adaptées
1. Le prior τ est une estimation. Le shrinkage peut sur-corriger ou sous-corriger de 15-30% selon le τ choisi.
2. Les plateaux résiduels sont des conventions. Ajustez selon votre contexte (maturité, fréquence des refontes).
3. Les décisions bloquées sont déclaratives. Documentez chaque décision avec preuves pour la traçabilité.
4. L'horizon 36 mois est long. Préférez des recalibrages fréquents (tous les 6 mois).
5. La correction WC est optimale pour un test isolé. Sur un portefeuille, c'est néanmoins meilleur qu'une projection naïve.
6. Pas de stress test intégré. Recalculez avec τ ±2pts, plateaux ±10pts pour la fourchette.
• Business case défendable au CODIR
• Comparer des scénarios (budget haut vs bas)
• Justifier un investissement CRO
• Garantir un ROI précis à ±5%
• Fixer des OKR individuels
• Remplacer la mesure post-déploiement
La vraie valeur se mesure a posteriori (HoldOut tests, Universal Holdouts, Causal Impact). Ce calculateur est un outil de projection ex-ante pour justifier l'investissement. À chaque trimestre, comparez projections et gains mesurés. Recalibrez τ et les plateaux.
Vérifier la fiabilité statistique d'un test
L'outil calcule automatiquement le MDE détectable (Minimum Detectable Effect) pour chaque test, en fonction du trafic, de la baseline, de la durée et des tests concurrents.
MDE = (zα/2 + zβ) × √(2 × p × (1−p) / n) / pAvec α=5% bilatéral, puissance 80%. Si l'uplift attendu est inférieur au MDE, le test est signalé comme sous-puissant.
Questions communes
FAQ
Pourquoi mon ROI affiché est-il plus bas que mes projections internes ?
Parce que ce calculateur applique la correction Winner’s Curse, qui réduit les uplifts déclarés de 15 à 30 % pour refléter le biais de sélection statistique des tests significatifs.
Un test qui franchit le seuil de p < 0,05 a tendance à surestimer son vrai uplift — c’est une propriété mathématique du processus de filtrage. La correction Winner’s Curse (Lee & Shen, KDD 2018) ajuste cette surestimation.
Concrètement, si vos projections internes annoncent +5 % de gain et que ce calculateur affiche +3,5 %, ce dernier chiffre est statistiquement plus défendable face à un CFO.
Comment expliquer la correction Winner's Curse à un CFO non statisticien ?
Utilisez cette formulation en 30 secondes : « Quand un test A/B est déclaré gagnant, son uplift mesuré est mécaniquement biaisé vers le haut, simplement parce qu’il a franchi le seuil de significativité. La correction Winner’s Curse, méthodologie de référence depuis 2018 (Lee & Shen, ACM SIGKDD), réduit cet uplift à sa vraie valeur estimée. C’est ce qui transforme une projection optimiste en projection défendable. »
Cette explication ferme la porte aux objections du type « vous avez inventé ces chiffres » en s’appuyant sur une référence académique reconnue.
Pourquoi ne pas inclure les gains des tests négatifs ?
Les tests négatifs ne sont pas ignorés — ils sont comptés comme « décisions bloquées » dans la projection. Leur valeur est la perte évitée en ne déployant pas la variante perdante.
Cette approche, popularisée par Lukas Vermeer (Booking.com), permet de quantifier la valeur défensive de l’expérimentation : un programme CRO mature génère typiquement 50 % de sa valeur via les gains des tests positifs et 50 % via les pertes évitées par les décisions négatives bloquées.
Comment justifier la valeur des décisions bloquées au CFO ?
Documentez chaque décision bloquée avec quatre éléments : la date du test, l’hypothèse testée, le résultat statistique du test (perte mesurée et significativité), la projection du chiffre d’affaires perdu si la variante perdante avait été déployée.
Cette traçabilité documentaire transforme une « perte évitée » abstraite en valeur quantifiée et auditable. Un CFO acceptera plus facilement un chiffre adossé à une refonte checkout testée et abandonnée qu’un calcul théorique sans preuve.
Pourquoi 80 % d'intervalle de confiance et pas 95 % ?
Un intervalle de confiance à 80 % est plus pertinent pour la prise de décision business qu’un IC à 95 %.
Le 95 % est trop conservateur pour des projections stratégiques sur 12-36 mois : il produit des fourchettes si larges qu’elles deviennent inutilisables pour piloter un budget. Le 80 % offre un compromis entre rigueur statistique et utilité décisionnelle, en cohérence avec la pratique des grandes plateformes d’expérimentation (Microsoft, Airbnb).
Pourquoi le plateau résiduel ne tombe-t-il jamais à zéro ?
Empiriquement, les gains structurels d’un test A/B persistent dans le temps grâce à un effet d’habitude utilisateur et à une réduction durable de friction.
Une optimisation de checkout déployée en mois 1 ne perd pas 100 % de son uplift en mois 36 ; elle conserve typiquement 15 à 85 % de sa valeur initiale selon le type de modification.
Référence : Amazon Science, « Measuring the long-term effects of experimentation », 2023.
Les plateaux résiduels appliqués par défaut sont : 15 % pour les tweaks UI, 50 % pour les flows structurels, 85 % pour les changements ops.
Que faire si je n'ai pas encore de tests passés pour calibrer le prior tau (τ) ?
Utilisez la valeur par défaut du preset correspondant à votre contexte :
- 3 % pour une startup démarrant son programme
- 5 % pour un e-commerce mid-market
- 6 à 8 % pour des tests structurels (checkout, refonte)
- 4 à 6 % pour un grand groupe mature
Recalibrez ensuite ce paramètre après vos 20 premiers tests déployés en calculant l’écart-type empirique de leurs uplifts mesurés. Cette calibration améliore significativement la précision de la projection sur les programmes matures.
Comment ce calculateur gère-t-il le partage de trafic entre tests simultanés ?
Le trafic effectif par test est calculé comme : trafic mensuel divisé par le nombre de tests simultanés ce mois-là.
Cette répartition est appliquée mois par mois sur la frise calendaire de votre plan de tests. Un test isolé sur un mois bénéficie de 100 % du trafic ; trois tests simultanés se partagent le trafic à 33 % chacun.
Cette modélisation permet d’évaluer correctement la puissance statistique réelle de chaque test (MDE détectable) en fonction de la pression concurrentielle de votre roadmap.
Puis-je utiliser ce calculateur pour un programme de personnalisation ?
Oui, mais avec prudence. La personnalisation a une dynamique de gain différente d’un test A/B classique : la variance entre segments est plus forte, et les uplifts moyens cachent une distribution hétérogène.
Utilisez les paramètres « Tweak UI » ou « Personnalisation » du calculateur et appliquez un facteur de prudence ×0,7 sur les uplifts pour compenser la variance segmentaire.
Pour des programmes de personnalisation matures (50+ campagnes actives), recalibrez le prior τ avec les données empiriques de votre programme.
Le calculateur est-il adapté pour les sites à faible trafic (moins de 10 000 visiteurs par mois) ?
Partiellement. Sur les sites à faible trafic, la correction Winner’s Curse mord très fort sur les tests sous-puissants : les tests qui ne disposent pas d’un sample size suffisant pour atteindre la puissance statistique de 80 % voient leur contribution réduite à zéro dans la projection.
Surveillez la bannière de statut de puissance dans l’éditeur du calculateur. Pour les programmes à faible trafic, il est souvent plus pertinent de privilégier les tests sur des changements structurels (gros uplifts attendus) plutôt que les tweaks UI fins.
Mes données sont-elles stockées sur les serveurs de FWOptimisation ?
Non. Tous les calculs du calculateur sont effectués 100 % côté navigateur, en JavaScript local.
Aucune donnée ne sort de votre machine, aucune information n’est envoyée à un serveur, aucun cookie de tracking n’est posé sur la page du calculateur.
Cette architecture garantit la confidentialité totale de vos données business sensibles (chiffre d’affaires, panier moyen, hypothèses de tests). Vous pouvez utiliser le calculateur sereinement sur des données réelles d’entreprise.
Combien de temps faut-il pour préparer un business case CRO solide avec ce calculateur ?
Comptez 30 à 60 minutes pour saisir vos tests passés et vos décisions bloquées dans le calculateur.
La rédaction du pitch CODIR demande ensuite 2 à 4 heures de travail supplémentaires : structurer le script, préparer les slides, anticiper les objections probables du comité, calibrer la fourchette prudent/agressif.
Pour un coaching personnalisé en 45 minutes incluant l’analyse de vos chiffres réels et un retour écrit dans les 48h, réservez une session de coaching pitch CODIR à 149 €.
Quelle est la différence entre un calculateur ROI et un calculateur de sample size (MDE) ?
Le calculateur ROI projette la valeur agrégée de votre programme d’expérimentation dans son ensemble sur 12 à 36 mois (gains des tests + pertes évitées − coût programme).
Le calculateur de sample size (Minimum Detectable Effect, MDE) dimensionne un test individuel avant lancement : combien de visiteurs sont nécessaires pour détecter un uplift donné avec une puissance statistique de 80 %.
Les deux outils sont complémentaires : le MDE garantit que vos tests détectent réellement ce qu’ils prétendent détecter ; le ROI agrège l’ensemble du portefeuille de tests en projection business défendable.
Que faire si mon CODIR refuse le budget malgré un business case solide ?
Trois cas typiques expliquent un refus de budget malgré un pitch techniquement solide.
Premièrement, le contexte financier global de l’entreprise ne permet pas l’investissement — dans ce cas, reportez la demande au prochain cycle budgétaire.
Deuxièmement, un membre du comité a un agenda politique opposé — identifiez l’objection structurelle dans une réunion bilatérale avant le prochain CODIR.
Troisièmement, votre pitch était techniquement bon mais émotionnellement plat — un CODIR ne valide pas seulement des chiffres, il valide aussi un porteur de projet incarnant la conviction.
Détails complets dans le guide pitch CODIR.
Comment intégrer ce calculateur dans un slide deck CODIR ?
Trois approches sont possibles.
Première option : capturez votre projection en screenshot et insérez-la dans vos slides avec le commentaire méthodologique adapté.
Deuxième option : activez le Mode CODIR du calculateur (bouton en haut à droite de l’outil) pour obtenir un rendu épuré directement présentable en partage d’écran lors de la réunion.
Troisième option : partagez le lien direct du calculateur — la configuration de votre projection est préservée dans l’URL via le bouton Partager, ce qui permet aux membres du comité de manipuler les paramètres en post-réunion.
Le calculateur fonctionne-t-il pour des tests multi-variants (A/B/C/D) ?
Le modèle actuel est calibré pour des tests A/B classiques à deux variants (contrôle + 1 variation).
Pour des tests multi-variants, deux ajustements sont nécessaires : (1) le trafic effectif par bras est divisé par le nombre de variants (4 variants = 25 % du trafic par bras au lieu de 50 %), ce qui réduit la puissance statistique ; (2) la correction multi-comparaison (Bonferroni ou similaire) augmente le seuil de significativité requis.
En pratique, modélisez chaque variant gagnant comme un test A/B distinct dans la frise du calculateur, et appliquez manuellement un facteur de prudence ×0,8 pour compenser la perte de puissance.