J’ai trop refait,
pas assez mesuré.

01 LE CARNET / 1 MIN

Depuis le dernier épisode, Sam s’est bien remplie

Le coach IA, l’historique des matchs et l’analyse vidéo sont toujours au cœur de l’app. J’ai aussi ajouté un simulateur de classement qui reprend la manière de calculer de la FFT, ainsi qu’un module pour noter ses séances d’entraînement.

Le simulateur permet de se projeter dans sa progression. Le module d’entraînement donne une place aux séances entre les matchs. Petit à petit, Sam accompagne davantage de moments de la vie d’un joueur.

Quand j’ai dévoilé le projet en janvier, l’enjeu était de faire exister le produit. L’app est maintenant beaucoup plus complète, et j’en suis content. J’ai encore plein d’idées, mais ma priorité évolue : je veux comprendre ce qui aide les joueurs à profiter de ce qui existe déjà.

Quelqu’un qui télécharge Sam n’a pas suivi mes mois de développement. Il doit trouver rapidement quelque chose qui lui sert, puis avoir une raison de revenir. C’est sur ces premiers moments que je veux concentrer une partie des prochains développements.

02 LE CARNET / 1 MIN

L’onboarding : beaucoup de refontes, trop peu de traces

J’ai souvent abordé un problème de l’onboarding en reprenant l’ensemble. Le vibe coding rend ça possible très vite. Il rend aussi facile le fait d’ajouter une autre modification pendant qu’on travaille sur la première.

À la fin, j’avais un nouveau parcours, mais plusieurs choses avaient changé en même temps. Difficile de savoir ce qu’il fallait garder ou remettre en question.

J’ai bien sûr appris en construisant l’app. Mais je documentais trop peu mes essais : ce que je cherchais à vérifier, les données avant et après, et la raison de conserver une version. Ces apprentissages restaient difficiles à retrouver pour le développement suivant.

C’est le piège dans lequel je suis tombé : le code avançait plus vite que ma compréhension de ses effets.

Je ne veux plus qu’un problème sur un écran déclenche automatiquement une nouvelle refonte générale. Pour tester quelque chose dans l’onboarding, je veux choisir un élément précis et garder le reste du parcours stable pendant le test.

Déplacer un écran est déjà un changement à mesurer. Si j’en profite pour réécrire tous les textes et modifier l’offre, je me remets dans la même situation.

Je veux qu’un changement livré laisse aussi une trace de ce qu’il m’a appris.

03 LE CARNET / 3 MIN

Ce que je mets en place avec PostHog et Claude

Ces derniers jours, j’ai passé du temps à analyser le parcours dans PostHog : l’arrivée dans l’app, la fin de l’onboarding, la présentation des offres, le démarrage d’un essai et le retour quelques jours plus tard. J’ai aussi regardé le passage de l’essai à l’abonnement et la façon dont Sam se situe par rapport au marché.

Je croise les usages observés dans PostHog avec les données d’abonnement remontées par RevenueCat. Un essai démarré et un joueur devenu payant sont deux étapes différentes. De la même manière, une première ouverture de l’app n’est pas exactement un téléchargement comptabilisé par le store.

Avec Claude, j’ai travaillé à partir de ces données pour formuler des hypothèses et préparer des tests. Je garde la décision sur ce qu’on implémente : une explication convaincante reste une hypothèse à vérifier.

Un carnet avant de modifier le code

La version 3.2.9 a maintenant son registre de tests, avec une base relevée le 2 octobre sur la 3.2.8. Chaque fiche garde le constat, l’explication envisagée, le changement prévu, la mesure à suivre et ce qui ne doit pas se dégrader ailleurs. Elle prévoit aussi un minimum de joueurs à observer et une date limite pour décider.

Je veux pouvoir rouvrir une fiche dans un mois et retrouver pourquoi j’ai fait ce changement, ce qu’il a donné et ce que j’ai décidé. C’est cette mémoire qui me manquait entre les refontes.

J’ai réparti les tests par étape : arrivée dans l’app, présentation de l’offre, expérience pendant l’essai et passage du gratuit au Pro. Les relances pour faire revenir les joueurs ont aussi leur place. Ma règle est un seul test à la fois par étape, jamais deux sur le même écran.

Certains changements seront suivis en comparant les versions de l’app. D’autres passent par un test A/B, avec deux parcours proposés en parallèle. Je garde cette distinction dans le carnet : entre deux versions, les campagnes et les profils des nouveaux joueurs peuvent aussi avoir changé.

Cette première série concerne l’iPhone. Le calendrier part de la sortie de la 3.2.9 sur l’App Store, puis il faut laisser les joueurs concernés utiliser les parcours. Activer une expérience dans PostHog ne suffit pas à avoir des résultats.

Le cas des notifications

Un des sujets que je veux travailler est la demande de notifications. Elles sont trop peu activées, et je soupçonne le moment où je les demande dans l’onboarding de jouer un rôle.

C’est un bon exemple de ce que je veux changer dans ma manière de développer. Pour tester le placement, je garderais le même message et les autres écrans inchangés. Je veux terminer le changement prévu sans transformer l’essai en refonte complète.

Une revue le lundi, une décision quand j’ai assez de recul

J’ai prévu un point chaque lundi avec Claude pour relever les chiffres, compléter les fiches et regarder les tests arrivés à leur date de lecture.

Je veux avancer par petits tests, parfois sur une ou deux semaines. Mais le rendez-vous du lundi ne m’oblige pas à trouver un gagnant. Il faut assez de joueurs, et laisser les essais arriver à leur terme pour savoir s’ils deviennent payants.

Le registre prévoit aussi les règles d’arrêt. Si un changement dégrade nettement un garde-fou après la première semaine, je l’arrête. Si rien n’est net à la date limite, je garde la version la plus simple et je le note.

Avec le volume actuel de Sam, je cherche des changements assez francs pour apprendre quelque chose. Un test localisé peut modifier fortement un écran ; il n’a pas besoin de se limiter à la couleur d’un bouton.

Quand une variante est retenue, je l’intègre, puis je peux passer au test suivant sur cette étape. Le carnet garde aussi les essais sans gagnant. Ce sera toujours plus utile que de me fier, quelques semaines plus tard, au souvenir de la version que je préférais.

04 LE CARNET / 1 MIN

En parallèle, le chantier Belgique

Pendant que je prépare cette façon de travailler, je continue à construire. Et l’adaptation de Sam Tennis à la Belgique est un gros morceau.

L’app était déjà accessible depuis d’autres pays. Mais une partie de sa valeur repose sur l’historique du joueur : ses matchs, ses résultats, son classement. Sans ces données, plusieurs fonctionnalités ont moins de contexte.

Je travaille donc à récupérer les données publiques pertinentes des joueurs belges et je prépare la traduction en néerlandais. L’objectif est de leur apporter une expérience plus complète.

Une même app, adaptée à la fédération du joueur

La Belgique implique plusieurs langues, fédérations et modèles de classement. Les repères français ne se transposent pas tels quels.

Le fonctionnement que je prépare part d’un choix très tôt dans l’onboarding : à quelle fédération le joueur est-il rattaché ? Sa réponse guidera la recherche de son profil, certaines étapes de l’inscription et les fonctionnalités liées au classement. La langue doit aussi être choisie correctement.

Je garde une même application, mais le simulateur devra utiliser les règles adaptées au joueur. Lui montrer un calcul FFT alors qu’il dépend d’une autre fédération n’aurait pas de sens.

Je n’ai clairement pas choisi le produit le plus simple à exporter. Il faut adapter les données, les langues, les classements, puis vérifier que tout fonctionne ensemble. Mais c’est aussi ce qui me plaît : ce travail rend Sam plus utile à des joueurs qui n’avaient pas encore accès à toute sa valeur.

Observer aussi la conversion sur un autre marché

Je suis curieux de comparer ce qui se passera en Belgique et en France. J’entends souvent que les Français paient difficilement pour des applications mobiles. J’ai envie de confronter cette idée aux usages de Sam, sans partir avec la réponse.

Il faudra tenir compte de la provenance des joueurs, de leur plateforme, de l’offre proposée et de la qualité de l’historique retrouvé. Les premiers groupes belges seront petits : leurs résultats donneront des pistes, pas un verdict sur les habitudes de tout un pays.

Si l’adaptation fonctionne, j’aimerais ensuite avancer progressivement dans d’autres pays européens, avec le même travail sur leur contexte tennistique.

05 LE CARNET / 1 MIN

Ce que je veux pouvoir raconter au prochain épisode

J’ai deux chantiers devant moi : mieux comprendre le parcours des joueurs qui arrivent déjà, et préparer Sam pour ceux qui jouent ailleurs.

Pour la prochaine étape, j’aimerais revenir avec un test précis, ses observations et la décision prise. Même si cette décision est de garder la version actuelle. Et je pourrai faire le point sur l’intégration des données belges, le parcours par fédération et la traduction.

C’est ce que je retiens de ces mois de vibe coding : avant de coder, écrire ce qu’on cherche à apprendre et comment on va le mesurer. J’ai envie de garder la vitesse de création que l’IA m’apporte, tout en accumulant des apprentissages que je pourrai retrouver et réutiliser.

Je m’éclate toujours autant sur Sam. Je veux simplement donner plus de mémoire à la façon dont je le construis.

Si tu joues au tennis, tu peux découvrir Sam Tennis. Les autres épisodes sont dans le journal Build in Public.

À très vite,

Guillaume