Calculateur ROI programme d'expérimentation : projection chiffrée de vos tests A/B
La plupart des projections CRO surestiment les gains. Ce calculateur corrige ce biais de sélection avec le Winner’s Curse selon l’approche d’Airbnb ou Microsoft, et transforme vos tests A/B en projection ROI défendable en CODIR : gains corrigés, pertes évitées et incertitude comprises.
- Projection corrigée du biais de sélection sur 12 à 36 mois
- 2 modes assumés, 2 corrections statistiques : Airbnb (valeur espérée) et celle de Microsoft (comptage strict)
- Valorisez les pertes évitées, pas seulement les gains déployés
- 100 % dans votre navigateur, aucune donnée envoyée ni stockée
Le probleme
La plupart des projections des tests A/B sont soit trop optimistes,
soit impossibles à défendre.
Quand on présente « tests gagnants = gains cumulés », on gonfle deux fois : on garde la part de chance des gagnants, et on oublie tout ce que le programme a évité de déployer. Un CFO le sent, et il divise votre chiffre par deux dans sa tête.
Les gains gagnants sont biaisés
Un test qu’on retient parce qu’il a gagné garde une part de chance. La projection naïve la compte comme acquise, c’est le Winner’s Curse.
Les tests utiles restent invisibles
Un test A/B bloqué faute de trafic, une variante abandonnée à raison : rien dans un reporting classique. Pourtant, éviter une mauvaise décision a une valeur.
Le CODIR veut un chiffre, pas une promesse
Pas une liste de tests. Une projection de valeur, une fourchette, et des hypothèses qu’on peut défendre ligne par ligne devant la finance.
La méthode
4 principes pour une projection défendable.
Comment le calculateur juge un test, ce qu’il écarte, comment il corrige ce qui reste, et comment tout s’assemble en une projection tenable.
Vérifier la fiabilité réelle du test A/B
Un test répond à deux questions différentes : y a-t-il un effet, et peut-on croire son ampleur ? On peut être sûr qu’un effet existe (95 % de confiance) tout en étant incapable d’en estimer la taille de façon fiable si la puissance est trop faible.
Le calculateur vérifie les deux et écarte de la projection les tests trop fragiles pour compter.
Corriger les gains selon la force de preuve
2 logiques éprouvées, offertes comme 2 modes:
- L’approche Airbnb rabote chaque effet selon sa fiabilité, c’est la valeur espérée.
- L’approche Microsoft ne compte que ce qui est prouvé à 95 %, c’est le comptage strict.
L’outil vous propose de choisir votre philosophie, pas un curseur.
Valoriser les pertes évitées
Décider de ne pas déployer une variante perdante, c’est éviter une perte et ça a de la valeur. Le calculateur la chiffre, corrigée exactement comme les gains (même correction), pour ne jamais la surestimer non plus. C’est la moitié invisible de la valeur d’un programme.
Projection défendable
Une fois les gains corrigés, on ajoute les pertes évitées, on retire le coût du programme, et on obtient la valeur nette. Ce qu’on présente au CODIR n’est pas le maximum théorique, mais ce chiffre-là — et la règle qui y mène, ligne par ligne.
Cas d’usage
Quand la discussion passe du test A/B au pilotage du programme d'expérimentation.
Défendre un budget CRO
Transformer une demande de ressources en projection de valeur nette et de scénarios.
Prioriser une roadmap
Distinguer les tests qui valent l’effort de ceux qui ne seront jamais fiables.
Aligner produit & finance
Rendre visibles les hypothèses, le risque et les limites du modèle.
Structurer un pitch CODIR
Passer d’un reporting d’activité à un business case défendable ligne par ligne.
0 €
générés par le programme · correction bayésienne (shrinkage) appliquée aux gains et aux pertes évitées
Outil de décision, pas une prédiction. Les chiffres s'appuient sur des corrections statistiques rigoureuses ; pilotage continu requis.
Formats, statuts et aperçu ✓/✗ dans la fenêtre d'import.
Évolution de la valeur
Projection mois par mois · avec et sans programme
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.
Valeur espérée : valeur attendue compte tenu de la preuve — shrinkage bayésien symétrique appliqué aux gains ET aux pertes évitées. Chaque test contribue au prorata de sa fiabilité ; l'incertitude se lit dans la bande IC 80 %.
Comptage strict : ne compte que les résultats significatifs à 95 % (|z| ≥ 1,96), sinon 0. Borne conservatrice — ne peut que durcir le chiffre, jamais le gonfler.
Espérée = logique empirique-Bayes (Airbnb) ; strict = comptage significatif (Kohavi / Microsoft).
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 par shrinkage bayésien — 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 évitées. Le solde net peut être fortement négatif.
Plan de test
Positionnez vos tests A/B sur l'horizon. Cliquez sur une ligne pour éditer ses paramètres.
M1 = date de démarrage d'analyse (paramètre). Positions calculées par le moteur à partir des dates réelles des tests. Survol d'une barre : nom complet.
Commencez votre projection
Importez l'historique de vos tests A/B pour projeter la valeur nette de votre programme. Vos données restent dans votre navigateur — aucun fichier n'est envoyé sur un serveur.
- 1 Importez ou saisissez vos tests A/B (trafic + conversions bruts).
- 2 Ajustez les hypothèses : type de business, coût du programme, horizon.
- 3 Présentez la valeur nette corrigée à votre CODIR.
Paramètres globaux
Correction du biais de sélection — shrinkage bayésien
Un test A/B qui franchit le seuil de significativité a tendance à surestimer son vrai uplift (Winner's Curse). Plutôt que de tronquer, on régresse chaque effet vers le prior : plus le résultat est incertain, plus sa contribution est réduite. La correction est appliquée symétriquement aux gains ET aux pertes évitées.
effet_corrigé = shrink × effet · shrink = τ² / (τ² + σ²)
σ est l'erreur d'estimation de l'effet (dépend du trafic et du taux) ; τ est l'écart-type a priori des vrais uplifts du programme. Quand σ est grand (preuve faible), shrink tend vers 0 ; quand σ est petit (preuve forte), shrink tend vers 1. Continu, sans falaise.
Comptage strict (bascule) — borne conservatrice : seuls les résultats significatifs à 95 % (|z| ≥ 1,96) comptent, gains comme pertes évitées ; les autres passent à 0.
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 de la variation (Trafic A ou Trafic B saisi). Plus de division par le nombre de tests simultanés.
Facteur de projection : le résultat mesuré sous opt-in est remonté à 100 % du déploiement via le taux d'acceptation des cookies (× 2 / taux d'opt-in).
Caveat — biais de sélection opt-in : les visiteurs acceptant les cookies peuvent ne pas être représentatifs de l'ensemble ; la projection à 100 % suppose un comportement homogène (hypothèse à assumer).
Caveat — gains saisis manuellement (Panier moyen) : un gain saisi à la main n'est ni corrigé (shrinkage) ni ajusté par l'opt-in — il est pris tel quel.
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 évité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 évité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 une correction bayésienne (shrinkage) qui régresse chaque uplift vers le prior selon sa fiabilité — les résultats incertains sont réduits, ce qui reflète 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 évitées » — leur valeur est la perte évitée en ne déployant pas.
Comment justifier la valeur des décisions évitées au CFO ?
Documentez chaque décision évité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 périmètre de chaque test provient désormais des trafics A/B saisis (Trafic A + Trafic B), remontés à 100 % du déploiement via le taux d'acceptation des cookies. Il n'y a plus de division automatique du trafic global par le nombre de tests simultanés.
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.
Où sont stockées mes données ?
Aucune donnée n'est envoyée à nos serveurs — tout reste sur votre appareil. Les calculs sont 100 % côté navigateur ; votre tableau de bord est enregistré localement (localStorage) et exportable en fichier .json que vous gardez. Pas de compte, 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 une correction bayésienne (shrinkage) des uplifts — l'état de l'art contre le biais de sélection
• Modélise la persistance des gains avec plateau résiduel par type
• Intègre la valeur des décisions évité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 évité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 corrige le Winner’s Curse (le biais de sélection) : un test déclaré gagnant surestime mécaniquement son vrai uplift, du seul fait d’avoir franchi le seuil de significativité. Plus il est sous-puissant, plus la surestimation est forte.
Le calculateur retire cette part de chance. En mode Valeur espérée, un shrinkage bayésien (approche Airbnb) rabote chaque effet au prorata de sa fiabilité ; en mode Comptage strict, seuls les résultats prouvés à 95 % comptent (approche Microsoft).
Concrètement, si vos projections internes annoncent +5 % et que le calculateur affiche +3,5 %, ce dernier chiffre est statistiquement plus défendable face à un CFO.
Comment expliquer la correction à un CFO non statisticien ?
Utilisez cette formulation en 30 secondes : « Quand un test est déclaré gagnant, son uplift mesuré est mécaniquement biaisé vers le haut, simplement parce qu’il a franchi le seuil de significativité, c’est le Winner’s Curse. Le calculateur estime cette part de chance et la retire : soit en la rabotant au prorata de la preuve (approche Airbnb), soit en ne comptant que le prouvé à 95 % (approche Microsoft). C’est ce qui transforme une projection optimiste en projection défendable. »
Cette explication s’appuie sur les pratiques des grandes plateformes d’expérimentation (Airbnb, Microsoft) et ferme la porte aux objections du type « vous avez inventé ces chiffres ».
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 calculateur ne divise pas le trafic global entre tests simultanés. Chaque test utilise son propre trafic, les Trafic A et Trafic B que vous saisissez (le cumul réel du test), remontés à 100 % du déploiement via le taux d’acceptation des cookies. La puissance et la significativité (z) sont donc calculées sur les vrais volumes de chaque test, pas sur une répartition théorique du trafic mensuel. Deux tests lancés le même mois sur des pages différentes ne se partagent pas le même trafic.
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 faible trafic, beaucoup de tests sont sous-puissants, et la correction rabote fortement leur contribution : en mode Valeur espérée un test peu fiable pèse peu ; en mode Comptage strict, sa contribution tombe à zéro tant qu’il n’atteint pas 95 %.
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.