Tester une landing page en A/B est un problème résolu. On change le titre, on attend quelques jours, on compte les inscriptions. La métrique arrive en quelques secondes, le trafic est important, et le résultat de chaque visiteur est indépendant de celui des autres.
L'onboarding casse ces trois hypothèses. Le résultat qui vous intéresse arrive plusieurs jours après que le changement a été vu. Votre volume d'inscriptions ne représente qu'une fraction de votre volume de visiteurs. Et chaque utilisateur vit le parcours une seule fois : impossible de rejouer le moment qui a compté.
Rien de tout cela ne rend l'expérimentation sur l'onboarding impossible. Cela en fait une autre discipline, où la valeur vient du fait de tester des changements moins nombreux et plus importants face à des métriques plus lentes et plus justes. Ce guide explique quoi tester, quoi mesurer, de combien de trafic vous avez réellement besoin, et que faire à la place quand vous ne l'avez pas.
À retenir
- Mesurez l'activation, pas les clics. Une variante peut augmenter la complétion de la visite produit tout en réduisant le nombre d'utilisateurs qui tirent quoi que ce soit du produit. C'est exactement ce qui arrive quand on optimise un indicateur intermédiaire.
- Testez de gros changements. Les petits changements exigent un trafic que la plupart des produits SaaS n'ont pas. Une checklist contre pas de checklist se teste ; un changement de couleur de bouton, non.
- La métrique de résultat est différée. Si l'activation prend en général une semaine, les utilisateurs inscrits hier ne peuvent pas encore être activés. Les inclure fausse le résultat.
- Fixez la taille d'échantillon avant le lancement. Les métriques d'onboarding oscillent fortement au début, et il y a presque toujours un moment où votre variante préférée est en tête.
- Une seule variable par test. Changez trois choses, et un résultat positif ne vous dit rien sur celle qu'il faut garder.
- Manquer de trafic n'autorise pas à deviner. Cinq sessions de test utilisateur, une comparaison de cohortes avant/après ou un test de la fausse porte valent mieux qu'une expérience sous-dimensionnée.
Qu'est-ce que le test A/B de l'onboarding ?
Définition : tester l'onboarding en A/B consiste à répartir aléatoirement les nouveaux utilisateurs entre deux versions de l'expérience d'onboarding et à les comparer sur un résultat en aval, généralement le taux d'activation. Un groupe reçoit le parcours actuel (le contrôle), l'autre reçoit un seul changement délibéré (la variante). Chaque utilisateur est affecté une fois et reste dans cette variante pendant toute la durée du test.
La mécanique est classique. Ce qui ne l'est pas, c'est l'écart entre la cause et l'effet. Sur une landing page, ce que vous avez changé et ce que vous mesurez sont séparés de quelques secondes. Dans l'onboarding, vous changez quelque chose que l'utilisateur voit à la deuxième minute et vous mesurez s'il a obtenu de la valeur au septième jour, avec toute une expérience produit entre les deux.
C'est dans cet écart que la plupart des expériences d'onboarding déraillent, et c'est pourquoi la suite de ce guide consacre plus de temps à la mesure qu'à la mécanique.
Pourquoi les tests A/B d'onboarding sont plus difficiles
-
La métrique est différée
L'activation peut prendre une heure ou quinze jours. Tant que chaque utilisateur de votre échantillon n'a pas eu toute la fenêtre pour s'activer, les deux variantes sont sous-estimées, et pas forcément dans la même proportion : c'est ainsi qu'une métrique différée peut carrément inverser un résultat.
-
La population est petite
Vous testez sur des inscrits, pas sur des visiteurs. Un site avec 50 000 visiteurs mensuels et un taux d'inscription de 3 % dispose de 1 500 utilisateurs par mois à répartir, soit à peu près un test correctement dimensionné par trimestre, si vous testez quelque chose de significatif.
-
Chaque utilisateur ne le voit qu'une fois
Il n'y a pas de seconde impression. Une variante déroutante ne se contente pas de perdre le test : elle vous coûte définitivement les utilisateurs qui l'ont reçue. C'est un vrai argument pour mener d'abord une recherche qualitative et ne tester que les idées qui y survivent.
-
Les segments se comportent différemment
Un changement qui aide les utilisateurs techniques peut pénaliser les non-techniques, et le tout se solde par « aucun effet ». Les résultats agrégés d'onboarding masquent davantage que ceux d'une landing page : prévoyez donc vos ventilations par segment avant le lancement.
La conséquence pratique : vous disposez d'une poignée de vraies expériences d'onboarding par an, pas de dizaines. Consacrez-les à des changements structurels reposant sur un mécanisme plausible (des idées issues d'enregistrements de sessions, de données d'abandon ou de tests utilisateurs) plutôt qu'à un backlog de variations cosmétiques.
Quoi mesurer : l'activation, pas les clics
La façon la plus courante d'obtenir une mauvaise réponse d'un test bien mené, c'est de mesurer la mauvaise chose.
| Métrique | À utiliser comme | Pourquoi |
|---|---|---|
| Taux d'activation | Métrique de succès principale | Le seul chiffre qui signifie qu'un utilisateur a obtenu ce pour quoi il est venu |
| Time to first value | Métrique de succès secondaire | Repère les variantes qui activent la même part d'utilisateurs, mais plus vite |
| Rétention à J30 | Juge final, si vous pouvez attendre | La seule métrique qu'une première session persuasive ne peut pas fausser |
| Taux de complétion des étapes | Diagnostic uniquement | Explique pourquoi une variante a gagné ou perdu ; un très mauvais critère de succès |
| Complétion de la visite / de la checklist | Diagnostic uniquement | Facile à gonfler en raccourcissant la visite, ce qui n'aide peut-être personne |
| Temps passé dans l'onboarding | Garde-fou | Ambigu à lui seul : engagement ou confusion |
| Tickets de support | Garde-fou | Une variante qui gagne sur l'activation et double les tickets n'a pas gagné |
Le piège de l'indicateur intermédiaire mérite d'être détaillé, tant il est facile d'y tomber. Supposons que la variante B raccourcisse la visite produit de huit étapes à trois. La complétion de la visite passe de 34 % à 71 % et le test est déclaré gagnant. Mais si les cinq étapes supprimées étaient justement celles qui montraient aux utilisateurs comment faire ce pour quoi ils étaient venus, l'activation a peut-être baissé pendant que votre métrique phare doublait.
Choisissez l'événement d'activation avant le test, définissez-le comme un événement de valeur concret, et ne le modifiez pas en cours de route. Nos guides sur l'aha moment et les métriques d'onboarding expliquent comment le choisir.
8 tests A/B d'onboarding qui valent la peine
Classés à peu près par taille d'effet attendue, ce qui, vu les contraintes de trafic ci-dessus, est le seul ordre qui compte.
1. Checklist contre pas de checklist
Montrez une checklist d'onboarding à la moitié des nouveaux utilisateurs et le produit seul à l'autre moitié. C'est généralement le plus gros levier disponible, car une checklist transforme un « débrouillez-vous » sans limite en une liste courte, finie, avec une fin visible.
Hypothèse : rendre le chemin explicite et fini augmente l'activation. Mesure : taux d'activation et time to value.
2. Moins de champs à l'inscription
Réduisez le formulaire à l'e-mail et au mot de passe, et collectez le reste plus tard. Surveillez les deux moitiés du funnel : le taux d'inscription et le taux d'activation. Ce test sert à détecter un échec précis : une modification du formulaire qui augmente les inscriptions tout en réduisant l'activation, parce que les champs supprimés faisaient un vrai travail d'orientation. C'est la tension que traitent nos guides sur les parcours d'inscription et le profilage progressif.
3. Données d'exemple contre état vide
Pré-remplissez les nouveaux comptes avec un projet d'exemple réaliste au lieu d'un écran vide. C'est structurel, peu coûteux à construire, et souvent l'un des changements les plus efficaces : un compte vide demande à l'utilisateur de faire la partie la plus difficile du travail avec le moins de contexte. Voir notre guide sur les états vides.
Garde-fou : surveillez les utilisateurs qui confondent les données de démo avec les leurs, ce qui apparaît dans les tickets de support plutôt que dans une métrique.
4. Visite d'entrée contre guidage contextuel
Contrôle : une visite de bienvenue à la première connexion. Variante : pas de visite d'entrée, mais de courtes infobulles déclenchées quand l'utilisateur atteint pour la première fois chaque zone concernée.
C'est le test le plus instructif de la liste, car les deux philosophies produisent des produits réellement différents. Le guidage contextuel l'emporte généralement sur l'activation ; les visites d'entrée l'emportent parfois sur la découverte des fonctionnalités. Savoir ce qui s'applique à vous vaut bien un trimestre de trafic. Notre guide pour créer une visite produit qui convertit couvre les deux approches.
5. Parcours personnalisé contre parcours unique
Posez une question à choix multiples, « qu'est-ce qui vous amène ? », et faites bifurquer la première session selon la réponse. Le contrôle reçoit le même parcours pour tout le monde.
Notez que ce test mesure deux choses à la fois : le coût de la question et le bénéfice de la bifurcation. C'est acceptable ici, car vous ne livreriez jamais la question sans la bifurcation, mais reconnaissez honnêtement qu'un résultat négatif ne vous dit pas laquelle des deux moitiés a échoué. À lire aussi : l'onboarding personnalisé.
6. Indicateur de progression contre rien
Ajoutez une barre de progression à une configuration en plusieurs étapes. C'est peu coûteux à mettre en place, et cela exploite un effet comportemental fiable : on a plus tendance à terminer quelque chose qui est visiblement presque fini.
Attention : une barre de progression peut rendre une longue configuration plus longue encore en apparence. Afficher « étape 2 sur 9 » peut être pire que de ne rien afficher.
7. Exigence de valeur différée contre immédiate
Le contrôle demande à l'utilisateur d'importer ses vraies données avant de voir quoi que ce soit. La variante le laisse explorer d'abord et importer plus tard. Ce test vérifie si vous faites payer le coût de configuration avant que l'utilisateur n'ait la moindre raison de le payer.
8. Microcopie de l'étape où l'abandon est le plus fort
Réécrivez le libellé, le texte d'aide et le bouton de l'étape où votre funnel perd le plus. Le périmètre est réduit, mais concentré à l'endroit exact où la perte se produit. Voir notre guide de la microcopie UX.
Réserve : les changements de texte produisent généralement de petits effets ; ce test demande donc plus de trafic que sa simplicité ne le laisse penser.
Taille d'échantillon et durée : la version honnête
C'est la partie que la plupart des conseils sur les tests d'onboarding passent sous silence, et c'est pour cela que tant d'équipes lancent des tests qui n'auraient jamais pu aboutir à une conclusion.
C'est la relation qui compte : diviser par deux l'effet que vous voulez détecter multiplie environ par quatre le trafic nécessaire. Ce seul fait détermine toute votre stratégie d'expérimentation.
Trois règles pour arrêter un test
- Atteignez la taille d'échantillon calculée à l'avance. Décidée avant le lancement, écrite noir sur blanc, et pas revue parce que la courbe a l'air prometteuse au quatrième jour.
- Tenez au moins deux semaines complètes. Les inscriptions de semaine et de week-end ne se comportent pas de la même façon, et une semaine n'est qu'un seul échantillon d'un cycle hebdomadaire.
- Laissez la métrique mûrir. Si l'activation prend jusqu'à sept jours, les inscrits des sept derniers jours n'ont pas encore pu s'activer. Excluez-les ou attendez.
Regarder les résultats en cours de route (le « peeking ») n'est pas un péché véniel. Vérifier la significativité à répétition et s'arrêter dès qu'elle apparaît fait exploser votre taux de faux positifs : vous lancez en réalité de nombreux tests et ne rapportez que le plus flatteur. Avec les données de début de test, très bruitées en onboarding, une variante qui « gagne clairement » au troisième jour est la norme, pas le signal. Fixez la condition d'arrêt avant le lancement et respectez-la.
Comment mener un test A/B d'onboarding en 6 étapes
Trouver la fuite dans votre funnel
La diagnostiquer de façon qualitative avant de concevoir une variante
Écrire une hypothèse réfutable avec une seule variable
Calculer la taille d'échantillon et la date de fin
Construire les deux variantes et vérifier la répartition
Analyser par segment, puis livrer ou abandonner
1. Trouver la fuite
Construisez le funnel d'onboarding de l'inscription à l'activation et repérez l'étape qui convertit le moins bien : c'est le diagnostic au cœur du framework des pirate metrics. Testez là où se trouve la perte, pas là où se trouve l'idée.
2. Diagnostiquer avant de concevoir
Les analytics vous disent où. Jamais pourquoi. Avant de construire une variante, regardez cinq enregistrements de sessions d'utilisateurs qui ont abandonné à cette étape, ou menez un court test utilisateur sur le parcours.
C'est cette étape qui distingue un test ayant une vraie chance de gagner d'un pile ou face. Une variante conçue à partir d'une cause observée repose sur un mécanisme ; une variante issue d'un brainstorming repose sur un espoir.
3. Écrire une hypothèse réfutable
Le format qui garde les équipes honnêtes :
Parce que [ce que nous avons observé], nous pensons que [le changement] va [effet attendu sur la métrique principale]. Nous saurons que nous avons raison quand [seuil précis].
Exemple rempli : Parce que quatre participants sur cinq ont abandonné à l'étape d'import des données en expliquant qu'ils n'avaient pas de fichier prêt, nous pensons que proposer un jeu de données d'exemple va augmenter l'activation à 7 jours. Nous saurons que nous avons raison quand le taux d'activation de la variante dépassera celui du contrôle d'au moins 20 % en relatif, avec 1 300 utilisateurs par bras.
Changez exactement une variable. Pas le texte et la mise en page et le déclencheur : une victoire obtenue avec un lot de changements ne peut pas être attribuée, et vous finirez par garder les trois pour toujours.
4. Calculer d'abord la taille d'échantillon et la date de fin
Partez de votre taux d'activation de référence, décidez de la plus petite amélioration qui justifierait une mise en production, et calculez le nombre d'utilisateurs nécessaires par bras. Divisez ensuite par votre volume d'inscriptions hebdomadaire pour obtenir une durée. Si cette durée dépasse huit semaines, le test n'est pas viable : testez quelque chose de plus gros ou utilisez l'une des alternatives ci-dessous.
5. Construire les deux variantes et vérifier la répartition
Affectez chaque utilisateur une seule fois, sur un identifiant stable, et gardez-le dans cette variante pendant tout le test. Puis vérifiez : contrôlez la répartition après les cinquante premiers utilisateurs, confirmez qu'elle est proche de 50/50 et que les deux variantes s'affichent correctement pour un vrai compte.
Des variantes cassées ou mal affectées sont la première cause de tests d'onboarding gâchés, et les dégâts restent invisibles jusqu'à l'analyse. Comme les visites produit, les checklists et les infobulles de Kompassify sont ciblées par segment et configurées plutôt que codées, vous pouvez monter les deux bras sans nouvelle release, ce qui signifie aussi qu'une variante perdante peut être désactivée en quelques minutes.
6. Analyser par segment, puis décider
Regardez d'abord le résultat agrégé, puis ventilez-le par canal d'acquisition, par offre et par tout attribut de première session que vous collectez. Un « aucun effet » agrégé cache souvent un fort effet positif dans un segment et un effet négatif dans un autre, ce qui appelle une décision de déploiement (sur un seul segment) plutôt qu'un abandon.
Puis décidez pour de bon. Un test qui se termine par « intéressant, laissons-le tourner » vous a coûté du trafic et ne vous a rien apporté.
Que faire quand vous n'avez pas le trafic
La plupart des produits SaaS ne peuvent pas mener de tests A/B valides sur leur onboarding, et faire comme si de rien n'était produit des tests sous-dimensionnés dont les faux négatifs bloquent des changements réellement bons. Les alternatives ne sont pas des lots de consolation ; pour les petites équipes, ce sont généralement les meilleurs outils.
| Méthode | Ce qu'il vous faut | Ce que vous obtenez | Idéal pour |
|---|---|---|---|
| Test utilisateur | 5 participants | La cause de l'abandon, observée directement | Tout abandon que vous ne savez pas expliquer |
| Cohortes avant / après | Deux mois comparables | Une tendance, faussée par la saisonnalité | Les grands changements structurels uniquement |
| Test de la fausse porte | Un lien et un message | Une preuve de demande avant de construire | Décider si quelque chose mérite même d'être construit |
| Sondage in-app au point d'abandon | Une question | Les raisons déclarées, dans les mots de l'utilisateur | Générer des hypothèses à moindre coût |
| Enregistrements de sessions | 10–20 sessions | Hésitations et clics de rage observés | Trouver des frictions dont vous ignoriez l'existence |
La politique pragmatique pour une petite équipe : utilisez des méthodes qualitatives pour décider quoi changer, livrez le changement à tout le monde, et servez-vous d'une comparaison de cohortes avant/après pour vérifier que rien ne s'est dégradé. Réservez les vrais tests A/B aux deux ou trois décisions par an qui sont coûteuses, réversibles et réellement incertaines. Une cause clairement observée en cinq sessions vaut mieux qu'un test sous-dimensionné qui ne conclut rien.
Les erreurs fréquentes dans les tests A/B d'onboarding
✅ À faire
- Définir l'événement d'activation avant le lancement
- Changer exactement une variable
- Fixer à l'avance la taille d'échantillon et la date de fin
- Tenir au moins deux semaines complètes
- Laisser la métrique de résultat mûrir avant d'analyser
- Ventiler les résultats par segment
- Garder des métriques garde-fous sur les tickets de support et la rétention
- Livrer ou abandonner ; ne jamais laisser un test tourner indéfiniment
❌ À éviter
- Faire de la complétion de la visite ou de la checklist l'objectif
- S'arrêter dès que la significativité apparaît
- Regrouper plusieurs changements dans une seule variante
- Inclure des utilisateurs qui n'ont pas eu le temps de s'activer
- Tester des changements cosmétiques avec peu de trafic
- Laisser les utilisateurs changer de variante d'une session à l'autre
- Lancer des tests qui se chevauchent sur le même parcours
- Prendre un résultat nul pour la preuve que l'idée était mauvaise
L'erreur la plus coûteuse : tester soigneusement la mauvaise chose. Un test rigoureux de la couleur d'un bouton, sur un parcours dont le vrai problème est que les nouveaux utilisateurs arrivent sur un écran vide sans savoir quoi faire, produira un résultat propre, fiable et parfaitement inutile, tout en consommant un trimestre de trafic que vous auriez pu consacrer à la question qui comptait.
Menez vos expériences d'onboarding sans livrer de nouvelle release
Kompassify vous permet de créer des visites produit, des checklists d'onboarding, des infobulles et des barres de progression, de les cibler sur des segments d'utilisateurs précis et de mesurer l'activation grâce à l'analytics produit intégrée, le tout sans code. Gratuit jusqu'à 100 utilisateurs actifs mensuels, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →Questions fréquentes
Qu'est-ce que le test A/B de l'onboarding utilisateur ?
Tester l'onboarding en A/B consiste à répartir aléatoirement les nouveaux utilisateurs entre deux versions d'une expérience d'onboarding et à les comparer sur un résultat en aval, généralement le taux d'activation. Un groupe reçoit le parcours actuel, l'autre reçoit un seul changement délibéré, et chaque utilisateur est affecté une fois et reste dans cette variante pendant tout le test. La principale différence avec un test de landing page tient à ce que l'on mesure : le résultat qui compte arrive plusieurs jours après que le changement a été vu, pas quelques secondes.
Que faut-il mesurer dans un test A/B d'onboarding ?
Le taux d'activation, défini comme le pourcentage d'utilisateurs de chaque variante qui atteignent un événement de valeur concret, comme l'envoi d'une première facture ou la publication d'une première page. Les taux de complétion des étapes et de clic sont utiles comme diagnostics mais dangereux comme critères de succès, car une variante peut facilement augmenter la complétion de la visite produit tout en réduisant le nombre d'utilisateurs qui tirent vraiment quelque chose du produit. Si vous pouvez vous permettre d'attendre, la rétention à J30 est un meilleur juge final que l'activation.
De combien de trafic a-t-on besoin pour tester l'onboarding en A/B ?
À titre indicatif, détecter une amélioration relative de 20 % sur un taux d'activation de référence d'environ 25 % demande à peu près 1 000 à 1 500 utilisateurs par variante. Les effets plus petits en demandent beaucoup plus : diviser par deux la taille d'effet à détecter multiplie environ par quatre l'échantillon nécessaire. La plupart des produits SaaS sous quelques milliers d'inscriptions par mois ne peuvent pas mener de tests A/B d'onboarding valides sur de petits changements, ce qui plaide pour tester de plus gros changements, pas pour ne rien tester.
Combien de temps doit durer un test A/B d'onboarding ?
Assez longtemps pour atteindre la taille d'échantillon requise, au moins deux semaines complètes pour couvrir la saisonnalité hebdomadaire, et assez longtemps pour que la métrique de résultat ait mûri pour chaque utilisateur de l'échantillon. C'est ce dernier point que les équipes oublient : si l'activation prend en général sept jours, les utilisateurs inscrits hier n'ont pas encore eu la possibilité de s'activer, et les inclure sous-estime les deux variantes et peut inverser le résultat. Arrêtez-vous sur une taille d'échantillon fixée à l'avance, pas quand la courbe vous plaît.
Quels tests A/B d'onboarding lancer en premier ?
Commencez par les expériences structurelles plutôt que cosmétiques, car les petits changements demandent un trafic que vous n'avez probablement pas. Les premiers tests les plus rentables consistent généralement à ajouter une checklist d'onboarding face à l'absence de checklist, à repousser des champs d'inscription plus tard dans le parcours, à pré-remplir un nouveau compte avec des données d'exemple au lieu d'un état vide, et à remplacer une visite produit d'entrée par un guidage contextuel déclenché là où les utilisateurs bloquent.
Peut-on tester l'onboarding en A/B sans assez de trafic ?
Oui, et vous devriez. Avec un faible volume, les options honnêtes sont le test utilisateur qualitatif avec cinq participants pour trouver la cause d'un abandon, la comparaison de cohortes avant/après pour les grands changements structurels, et les tests de la fausse porte qui mesurent la demande avant que quoi que ce soit ne soit construit. Ces méthodes offrent moins de certitude statistique qu'un split test, mais une cause clairement observée en cinq sessions vaut mieux qu'une expérience sous-dimensionnée qui produit un faux négatif et bloque un bon changement.
Quelle est l'erreur la plus fréquente dans les tests A/B d'onboarding ?
Conclure trop tôt. Les métriques d'onboarding fluctuent énormément pendant les premiers jours d'un test, et il est presque toujours possible de trouver un moment où la variante préférée est en tête. Combiné à une métrique de résultat différée, cela produit des conclusions assurées tirées du bruit. Fixez la taille d'échantillon et la date de fin avant le lancement, et ne regardez pas la significativité avant que les deux soient atteintes. L'erreur qui suit de près consiste à changer plusieurs choses à la fois, ce qui garantit que vous ne pourrez pas attribuer le résultat.