Les 5 métriques de rétention que tout fondateur d'app B2C doit suivre dès J+1

La plupart des fondateurs que je rencontre, après leur lancement d'app, sont dans la même situation : un dashboard rempli de chiffres, et aucune idée de ce qui marche ou pas. Ils regardent les téléchargements monter, ils sont contents trois jours, et puis silence. Pas de signal clair. Pas d'action évidente à prendre. Pas de cap.

Le problème n'est pas le manque de données. C'est l'inverse : trop de données qui ne disent rien, et pas assez de celles qui décident. Sur des dizaines d'événements possibles à logger, seuls 5 vous diront vraiment si votre app est en train de réussir ou de mourir lentement. Ce sont ces 5-là qu'il faut mettre en place dès le J+1 du lancement, pas plus tard.

Voici les 5 métriques qui comptent vraiment, comment les calculer, comment les mesurer concrètement, et les benchmarks pour savoir où vous vous situez.

Pourquoi les téléchargements ne disent rien (et ce qu'il faut vraiment regarder)

Le compteur de téléchargements est la métrique la plus visible et la plus trompeuse de toute l'industrie mobile. Elle est visible parce que les stores la mettent en avant. Elle est trompeuse parce qu'elle ne mesure que la première impression, pas l'usage réel.

Un téléchargement vous dit qu'une fiche store a fait son travail. Il ne vous dit pas si l'utilisateur a ouvert l'app, s'il a fini l'onboarding, s'il est revenu, ou s'il l'a désinstallée 30 secondes plus tard. Or 25% des apps installées sont ouvertes une seule fois. Si vous avez 5 000 téléchargements et un D1 à 20%, vous avez en réalité 1 000 utilisateurs réels. Et si votre D7 est à 8%, vous en avez 400 une semaine plus tard.

Les vraies métriques à monitorer sont des métriques d'usage, pas d'acquisition. Elles répondent à des questions comme : combien d'utilisateurs reviennent ? À quelle vitesse perçoivent-ils la valeur ? À quelle fréquence reviennent-ils dans une semaine donnée ? Quelle est la marche d'escalier qui les fait décrocher ? Voilà ce qui pilote un produit. Le reste, c'est de la décoration.

Les 3 cohortes de rétention : D1, D7, D30

C'est la base. Sans ces trois mesures, tout le reste est inutile. La rétention par cohorte mesure le pourcentage d'utilisateurs qui reviennent ouvrir votre app à 1 jour, 7 jours et 30 jours après leur premier usage. Cohorte veut simplement dire : on regarde ensemble tous les utilisateurs qui ont installé l'app le même jour, et on suit leur comportement dans le temps.

D1 : le hook (taux de retour à 24h)

Calcul : sur 100 utilisateurs qui ont ouvert l'app pour la première fois lundi, combien l'ont rouverte mardi ?

Ce que ça mesure : la qualité de votre première impression. Si l'utilisateur ne revient pas le lendemain, c'est que rien dans la première session ne lui a donné envie de revenir. Mauvais onboarding, valeur perçue trop tard, frustration au mauvais moment.

Benchmark : moyenne mondiale toutes catégories ~25-30%. Cible minimum à viser : 30%. Bon : 40%. Excellent : 50% et plus. En dessous de 20%, vous avez un problème de produit aigu.

D7 : le test (taux de retour à 7 jours)

Calcul : sur 100 utilisateurs qui ont installé l'app il y a 7 jours, combien ont rouvert l'app entre J+6 et J+7 ?

Ce que ça mesure : la présence d'une boucle de retour. Si votre app n'a aucune raison structurelle de faire revenir l'utilisateur (du contenu nouveau, une notification utile, un état qui évolue), votre D7 s'effondre. C'est la métrique la plus révélatrice de la qualité produit.

Benchmark : moyenne mondiale ~10-15%. Cible minimum : 15%. Bon : 20%. Excellent : 30%+.

D30 : le moment de vérité (taux de retour à 30 jours)

Calcul : sur 100 utilisateurs installés il y a 30 jours, combien sont revenus au moins une fois entre J+29 et J+30 ?

Ce que ça mesure : votre capacité à intégrer durablement l'utilisateur dans son quotidien. Le D30 est l'indicateur le plus prédictif de la viabilité d'un business mobile : un utilisateur encore là à J+30 a 80% de chances d'être encore là à J+90.

Benchmark : moyenne mondiale ~5-7%. Cible minimum : 7%. Bon : 12%. Excellent : 20%+. Pour référence, les apps bancaires tournent autour de 11%, le gaming s'effondre à 3%, le shopping à 5%.

Comment lire les 3 ensemble

Ce qui compte n'est pas le chiffre absolu, c'est la chute entre les trois. Si votre D1 est à 35% et votre D7 à 20%, vous avez perdu 43% de vos utilisateurs en une semaine, ce qui est normal. Si votre D1 est à 35% et votre D7 à 5%, vous avez perdu 86% en une semaine : votre problème n'est pas le hook (D1 est bon), c'est l'absence de boucle de retour. À l'inverse, un D1 à 15% et un D7 à 12% indique que ceux qui restent sont engagés mais que le hook initial est cassé. Chaque profil de courbe pointe un problème produit différent.

Le stickiness ratio (DAU/MAU)

Le stickiness, c'est le ratio entre vos utilisateurs actifs quotidiens (DAU) et vos utilisateurs actifs mensuels (MAU). Concrètement : sur tous les utilisateurs qui ont ouvert l'app au moins une fois dans le mois, quelle proportion l'ouvre un jour donné ? Si votre stickiness est de 30%, ça veut dire qu'un utilisateur actif vient en moyenne 9 jours sur 30 dans votre app.

Pourquoi c'est plus utile que le DAU brut

Un DAU isolé ne dit rien. 10 000 DAU peut être impressionnant ou ridicule selon la base d'utilisateurs. Le stickiness rapporte l'engagement à votre audience réelle. Une app avec 50 000 MAU et 25 000 DAU (50% stickiness) est dramatiquement plus engageante qu'une app avec 200 000 MAU et 25 000 DAU (12,5% stickiness), même si le DAU est identique.

Benchmarks par catégorie

• Réseaux sociaux et messageries : 50%+ (Instagram, WhatsApp tournent autour de 60%)
• Apps bancaires et fintech : 30 à 40%
• Apps de fitness et habitudes : 25 à 35%
• Apps de productivité : 20 à 30%
• Apps utilitaires (météo, transport) : 15 à 25%
• Apps shopping : 10 à 15%
• Apps occasionnelles (admin, voyage) : 5 à 10%

Si vous démarrez et que vous voulez une cible universelle : 20% est le seuil de validation qu'un usage régulier émerge. En dessous de 10%, votre app est utilisée trop occasionnellement pour construire un business mobile pérenne, sauf si votre modèle économique le justifie (apps utilitaires monétisées par abonnement annuel).

Le time to first value (TTFV)

C'est la métrique la plus négligée alors qu'elle est la plus actionnable. Le time to first value mesure le temps écoulé entre l'ouverture de l'app et le premier moment où l'utilisateur perçoit de la valeur. Pas le temps jusqu'à la fin de l'onboarding. Le temps jusqu'au premier « ah, c'est ça que je suis venu chercher ».

Comment le mesurer concrètement

Définissez d'abord votre first value moment : c'est l'action qui prouve à l'utilisateur que l'app fait ce qu'il attendait. Pour Spotify, c'est « j'écoute ma première musique ». Pour BeReal, c'est « je vois la photo d'un ami ». Pour une app de comptabilité, c'est « je vois mon premier chiffre calculé automatiquement ». Loggez cet événement précis (ex : first_value_reached), et calculez le temps écoulé entre app_first_open et lui.

Cibles à viser

• Excellent : moins de 20 secondes (apps de contenu : Instagram, BeReal, TikTok)
• Bon : 20 à 60 secondes (apps de productivité simples, fitness)
• Acceptable : 60 secondes à 2 minutes (apps complexes nécessitant configuration)
• Problématique : au-delà de 2 minutes (vous perdez 80% en chemin)

Comment le réduire

Trois leviers principaux : (1) couper l'onboarding au strict nécessaire (chaque écran de tutoriel ajoute du TTFV), (2) repousser les permissions et l'inscription après le first value moment (on ne demande pas avant d'avoir donné), (3) pré-remplir, pré-configurer, deviner. Chaque clic non nécessaire est du TTFV. C'est exactement le travail que je fais lors du cadrage produit : on chronomètre le parcours de la première session avant la première ligne de code.

Le funnel d'activation

Les 4 métriques précédentes vous disent quoi va bien ou mal. Le funnel d'activation vous dit où. C'est l'étape par étape de la première session, avec le pourcentage qui passe à l'étape suivante.

À quoi ça ressemble concrètement

Pour une app type, le funnel ressemble à ça :

1. App ouverte pour la première fois : 100%
2. Onboarding démarré : 95%
3. Onboarding complété : 70%
4. Permissions accordées (notifications, localisation si pertinent) : 55%
5. First value moment atteint : 40%
6. 2e session lancée le lendemain : 28%

Chaque chute de pourcentage est un endroit précis où votre produit perd des utilisateurs. Les drops les plus brutaux sont des signaux : si vous perdez 30% entre l'onboarding démarré et complété, votre onboarding est trop long ou demande trop. Si vous perdez 25% sur la demande de permissions, vous la demandez trop tôt ou sans contexte. Pour creuser comment concevoir un onboarding qui ne perd personne, voir l'article sur les 60 premières secondes.

Les 5 à 7 événements à logger

Pour pouvoir construire ce funnel, instrumentez ces événements dès la V1 de votre app, sans exception :

• app_first_open : première ouverture, c'est votre référence 100%
• onboarding_step_X : chaque étape clé de l'onboarding (4 max)
• onboarding_completed : sortie de l'onboarding
• permission_requested + permission_granted : pour chaque permission, demande et résultat
• first_value_reached : le moment de bascule
• core_action_completed : l'action métier principale (achat, message, contenu publié, etc.)
• session_returned : ouverture de la 2e session

Avec ces 7 événements, vous avez 90% de la visibilité produit dont vous avez besoin pour les 6 premiers mois. Plus tard, vous en ajouterez. Au début, c'est suffisant et c'est surtout fait.

Mettre tout ça en place sans data engineer

Bonne nouvelle : vous n'avez besoin ni d'une équipe data, ni d'un budget de cinq chiffres pour mesurer ces 5 métriques. Le stack qui suit fait tourner 95% des MVP B2C que je vois, gratuitement jusqu'à plusieurs dizaines de milliers d'utilisateurs.

Le stack recommandé pour un MVP early-stage

Firebase Analytics en base. Gratuit, intégré nativement à Flutter, événements illimités, dashboards corrects sur Google Analytics 4. C'est ce que j'instrumente par défaut sur tous les projets que je livre. Il vous donne D1/D7/D30 et le funnel out-of-the-box.

Mixpanel ou Amplitude en complément, dès que vous voulez creuser les cohortes ou faire des analyses ad-hoc. Mixpanel est plus simple, Amplitude est plus puissant pour l'analyse rétention. Tier gratuit généreux sur les deux (jusqu'à 100 000 events/mois sur Mixpanel, 10 millions sur Amplitude). Pas la peine de payer avant 50 000 utilisateurs actifs.

Vous n'avez besoin ni d'un ni de l'autre au lancement. Firebase suffit pour les 3 premiers mois. Ajoutez Mixpanel ou Amplitude quand vous commencez à vouloir poser des questions auxquelles Firebase répond mal.

La routine hebdomadaire à tenir

Une fois le stack en place, voici la routine qui change tout : 30 minutes le lundi matin, sur les 5 métriques. Pas plus. Pas moins. Vous regardez :

1. D1, D7, D30 : tendance sur les 4 dernières semaines (monte / stable / descend)
2. Stickiness : valeur de la semaine, comparée à la semaine précédente
3. TTFV : médiane sur les nouveaux utilisateurs de la semaine
4. Funnel : où sont les drops les plus violents cette semaine
5. Une chose qui a bougé que vous ne comprenez pas : c'est votre point de départ pour creuser

30 minutes, chaque lundi. Au bout de 8 semaines, vous voyez clairement si votre produit s'améliore ou pas, et où concentrer les itérations. Sans cette routine, vous décidez à l'aveugle. Et un produit décidé à l'aveugle perd toujours contre un produit piloté à la donnée.

Ce que ça change pour votre projet

Mesurer les 5 bonnes métriques dès J+1, ce n'est pas un luxe technique. C'est ce qui sépare les apps qui s'améliorent par itération de celles qui mourront sans qu'on sache pourquoi. Sans D1, D7, D30, sans stickiness, sans TTFV, sans funnel, vous pilotez un produit en regardant le rétroviseur : vous voyez ce qui s'est passé, jamais où vous allez.

L'investissement n'est pas dans les outils, qui sont gratuits. Il est dans la discipline d'instrumentation au moment du dev. Sept événements à logger correctement, une convention de nommage stable, et des dashboards préparés. C'est 2 à 3 jours de travail pour un dev mobile compétent. C'est aussi la différence entre un MVP qu'on saura faire évoluer et un MVP qu'on regardera mourir.

Si vous démarrez un projet ou si vous avez une app qui fonctionne mais sans visibilité claire sur ces métriques, on peut regarder ensemble ce qu'il faut instrumenter et comment. C'est exactement le type de chantier que je mène en début de cadrage chez ZUHD.