ADR-0020 — L'onboarding se termine sur le scan, jamais sur le paiement
Le wizard de premiere inscription (src/app/(minimal)/onboarding/_components/onboarding-client.tsx) enchaine quatre etapes : Account → Organization (+Plan) → Store → Visibility. Son etape 2 porte trois decisions dans un…
Statut
Accepté · 2026-09-17
Piliers : app-shell, billing, ai-platform, integrations
Contexte
Le wizard de premiere inscription
(src/app/(minimal)/onboarding/_components/onboarding-client.tsx)
enchaine quatre etapes : Account → Organization (+Plan) → Store → Visibility. Son etape 2 porte trois decisions dans un seul ecran —
l'identite de l'entreprise, le choix d'un plan, et le checkout Stripe
qu'elle ouvre (rememberCheckoutIntent, retour sur
~/billing/activate).
Deux faits rendent cet ordre intenable :
| Un plan se choisit avant toute preuve | a l'etape 2, le marchand n'a pas encore connecte sa boutique. Le produit ne lui a rien montre. Le prix n'a aucun denominateur |
Le plan Free porte 0 credit | src/types/billing-plans.ts PLAN_PRICING. Un compte qui refuse le checkout arrive donc sur un dashboard ou la garde pre-stream refuse tout en 402 : l'onboarding se termine sur un mur, pas sur une valeur |
L'etape store, elle, est deja au bon endroit :
src/app/(minimal)/onboarding/_components/store-step.tsx
n'a pas de formulaire propre et ouvre GenerateStoreDialog, la meme
machine que le chat et le dashboard — donc le launch playbook, le
provisioning de dev store, le transfert d'ownership, le connecteur
Shopify et le warm-up Intelligence. C'est la seule etape du tunnel qui
produise quelque chose que le marchand n'avait pas avant.
Le probleme n'est donc pas le nombre d'etapes, c'est leur ordre : le seul moment ou le produit a prouve quelque chose arrive APRES le seul moment ou on demande de l'argent.
Décision
L'onboarding se termine sur le scan et son plan @Atlas ; le paiement est demande a la premiere action d'ecriture, jamais avant.
Concretement, quatre regles :
- Le scan de decouverte est finance par la plateforme, pas par le solde de l'organisation — une fois par store, sous un plafond mensuel plateforme sur le meme modele que le scanner public.
- Le resultat du scan est rendu en entier. Aucun flou, aucun masque, aucun compteur cache derriere un plan.
- Le plan @Atlas est chiffre action par action, et le bouton qui ouvre le checkout porte le nom de l'action, pas celui d'un plan.
- La frontiere du gratuit est l'ecriture : lire le scan, lire l'Intelligence de son propre store et interroger @Atlas restent ouverts en Free ; executer une action, generer, ou installer un System passent par les credits.
L'etape organisation ne porte plus que l'identite de l'entreprise. Le choix de plan et l'invitation de membres sortent du tunnel.
Alternatives écartées
| Option | Pourquoi non |
|---|---|
| Garder le plan picker a l'etape 2 | c'est l'etat actuel, et c'est la cause : on demande un arbitrage de prix a quelqu'un a qui le produit n'a encore rien montre |
| Trial Pro 14 jours | decale le mur au lieu de le supprimer, ajoute une machine a etats de fin de trial et une relance a ecrire, et laisse sans reponse la question structurelle « on paye quand ». Ici la reponse est une phrase : quand @Atlas agit |
| Crediter le compte au signup | les credits sont l'unite que l'on vend ; en offrir brouille le message et ouvre le siphonnage par comptes jetables. Le bonus quotidien existe deja pour les plans payants, per-org et idempotent (DailyBonus) |
| Facturer le scan de decouverte au solde | avec Free = 0 credit, le scan ne tournerait jamais pour un nouvel inscrit : cela revient a supprimer la seule etape qui prouve quelque chose |
| Flouter le resultat et vendre le devoilement | montre qu'on detient l'information et qu'on la retient. Sur un audit — dont l'objet est la confiance — c'est le pattern qui coute le plus cher en credibilite |
| Bloquer le tunnel sur l'extension, le bridge MCP, l'app ou le theme Shopify | quatre etapes de plus avant la premiere preuve. Le bridge suppose de quitter l'app ; le theme modifie une boutique en production a la minute trois ; l'extension depend d'un package encore en review (growth-web/0620). Ces surfaces se vendent par l'output d'@Atlas, depuis une checklist d'activation post-onboarding |
Conséquences
Ce que ca coute. Le scan de decouverte devient une ligne de cout d'acquisition, a plafonner et a surveiller comme telle — c'est une depense reelle, engagee avant toute recette, sur un compte qui peut ne jamais convertir. Le cout marginal reste borne par la mutualisation du Store Graph (un domaine indexe sert tous ses observateurs) et par la regle « un scan de decouverte par store ».
Ce que ca rend difficile. La conversion n'est plus mesurable a la fin du tunnel : elle se mesure a la premiere action executee, donc plus tard et sur une autre surface. Le tunnel et la conversion cessent d'etre le meme entonnoir, et le plan @Atlas doit porter une estimation de cout credible — une action sous-estimee, c'est un 402 en pleine execution apres un achat.
Le signal qui indiquerait de revisiter. Un taux d'inscrits qui atteignent le scan sans jamais executer une action, ou un cout de scan par compte converti qui depasse la premiere facture : dans les deux cas le scan aurait cesse d'etre un argument de vente pour devenir un service gratuit.