Sprint zero feature : 30 commits de polish avant lancement

Le polish est plus rentable que les features. En 48 heures et 30 commits sans aucune fonctionnalité nouvelle, j'ai rendu mon app plus solide qu'en six mois d'ajouts. Voici pourquoi un sprint "zéro feature" avant un lancement est la meilleure décision qu'un dev solo puisse prendre.

Pourquoi faire un sprint sans feature avant le lancement ?

Pendant six mois, chaque journee de developpement ajoutait quelque chose. Une feature, un ecran, un pipeline, une integration. Le compteur de commits montait, les fichiers s'empilaient, et l'app grossissait au fil des 650+ commits.

Et puis un moment arrive ou il faut s'arreter. Pas par fatigue, mais par lucidite. L'app fonctionne pour 12 testeurs alpha qui connaissent ses limites. Mais le grand public ne pardonne pas. Selon une etude d'Apptentive, 77% des utilisateurs lisent au moins un avis avant de telecharger une app. Et un seul bug visible au mauvais moment, c'est un avis 1 etoile.

Cette semaine, j'ai donc fait l'inverse de tout ce que j'avais fait jusque-la : 30 commits en 48 heures. Zero feature. Que du polish, des corrections et de la preparation pour le moment ou l'app sort de l'alpha et entre dans le monde reel.

Comment corriger 15 bugs sur un seul ecran de personnalisation IA ?

L'IA de TAMSIV permet aux utilisateurs de se presenter par la voix. Tu appuies, tu racontes ta vie en 30 secondes, et l'assistant s'adapte a ta personnalite. Le probleme : l'ecran de configuration avait 15 bugs subtils que les tests automatiques ne detectaient pas.

Un bouton cache par un overlay. Un texte tronque sur petits ecrans. Une boucle infinie quand l'utilisateur interrompait l'IA en pleine reponse. Le prompt qui se reinitialisait apres chaque modification. Les boutons d'action empiles les uns sur les autres au lieu de se placer verticalement.

Aucun de ces bugs n'aurait ete trouve dans un test rapide. Il fallait utiliser l'app comme un vrai utilisateur — appuyer partout, interrompre au mauvais moment, revenir en arriere, reessayer. C'est ce que le Nielsen Norman Group appelle le test d'utilisabilite exploratoire : pas de script, juste un humain qui essaie de casser l'interface.

15 commits pour rendre un seul ecran fiable. Ca semble excessif. Mais quand c'est l'ecran qui definit comment l'IA te comprend, chaque micro-bug degrade l'experience entiere.

Quelle est la difference entre "ca marche en alpha" et "c'est pret pour la production" ?

Le systeme d'abonnements Free/Pro/Team existait depuis fevrier. Il marchait en alpha. Mais "marcher en alpha" et "etre pret pour la production" sont deux choses tres differentes.

En alpha, 12 testeurs savent que c'est un travail en cours. Ils acceptent un wording approximatif, un design pas tout a fait cale, des limites floues entre les plans. En production, chaque ambiguite coute un utilisateur. Selon ProfitWell, une page de pricing confuse peut reduire les conversions de 20 a 40%.

La refonte a touche trois axes :

• Le wording : chaque texte a ete relu pour clarifier ce qui est gratuit versus payant. Plus de formulations ambigues.
• Le design de la modale alpha : elle n'a plus de raison d'exister en production. Supprimee et remplacee par un flow naturel vers les plans RevenueCat.
• Les limites du plan gratuit : chaque ecran verifie sur 3 tailles d'ecran differentes, chaque texte responsive.

Le genre de travail qui ne se voit pas dans un changelog, mais qui fait la difference entre un utilisateur qui comprend ce qu'il paie et un utilisateur qui desinstalle par confusion.

Quels "petits details" ont le plus d'impact sur la retention ?

Trois ajustements mineurs ont transforme l'experience quotidienne de l'app.

Le bouton stop TTS. Quand l'IA te repond a voix haute et que tu veux l'arreter, avant il fallait couper le son du telephone. Maintenant un toggle suffit. Ca parait anodin, mais c'est exactement le type de friction qui pousse un utilisateur a desinstaller. Le dictaphone est le coeur de TAMSIV — il doit etre irreprochable.

Le scope strict du LLM. L'IA avait tendance a repondre a des questions hors sujet — meteo, culture generale, philosophie. En production, elle doit rester concentree : taches, memos, evenements. Point. Un garde-fou backend qui refuse poliment tout le reste. Comme l'explique le guide de prompt engineering d'OpenAI, definir des limites claires au LLM est essentiel pour une experience utilisateur coherente.

Le toggle d'images generees. Chaque conversation peut generer une image de couverture via IA, grace a l'integration Runware dans le dictaphone. Mais ca coute des credits. Un switch dans le header du dictaphone permet maintenant de desactiver la generation d'images a la volee. Transparence et controle.

Que represente le versionCode 30 pour un dev solo ?

Chaque build Android a un numero. On en est au 30eme. Les 29 precedents etaient de l'alpha — des builds pour 12 testeurs qui acceptaient les bugs en echange de la primeur. Le build 30 est le dernier avant que n'importe qui puisse telecharger TAMSIV sur le Play Store.

C'est un chiffre banal. Mais il represente le moment ou "mon app" devient "une app". Ou le code n'est plus protege par le filtre bienveillant des beta-testeurs. Ou chaque bug est un avis 1 etoile potentiel.

Pour mettre ca en perspective : le sprint qualite precedent avait deja corrige des dizaines de problemes. Le build 30 est l'aboutissement de deux semaines de polish intensif, pas juste de 48 heures. C'est la couche finale avant la mise en production.

Comment decider quand arreter d'ajouter des features ?

La tentation du developpeur solo, c'est d'ajouter toujours plus. Une feature en appelle une autre. Le backlog ne se vide jamais. Et plus l'app grandit, plus chaque ajout cree des interactions imprevues avec le reste.

J'ai applique une regle simple : si un bug peut etre rencontre dans les 5 premieres minutes d'utilisation, il est prioritaire sur n'importe quelle feature du backlog. C'est ce que Marty Cagan appelle le "reference customer test" — si ton utilisateur de reference ne peut pas terminer le parcours de base sans friction, rien d'autre ne compte.

Ce sprint m'a appris quelque chose : le polish n'est pas l'ennemi de la progression. C'est le contraire. Corriger 15 bugs sur un seul ecran a rendu l'app plus solide que n'importe quelle nouvelle feature. Les utilisateurs ne voient pas les commits. Ils voient une app qui marche — ou qui ne marche pas.

Quel est le workflow d'un sprint de polish en pratique ?

Concretement, voici comment j'ai organise ces 48 heures :

1. Audit par ecran : j'ai ouvert chaque ecran de l'app sur 3 appareils differents (petit, moyen, grand) et note chaque anomalie visuelle ou fonctionnelle.
2. Priorisation par impact : les bugs visibles dans les 5 premieres minutes en haut, les edge cases en bas.
3. Commits atomiques : un commit = un fix. Pas de commits fourre-tout. Ca permet de rollback chirurgicalement si un fix casse autre chose.
4. Test de regression : apres chaque fix, reverification des ecrans adjacents. Quand tu touches l'architecture d'un composant partage, l'effet domino est reel.

Ce workflow n'est pas spectaculaire. Il n'y a pas de nouvelle techno, pas de refacto heroique. Juste de la discipline et du temps passe a utiliser sa propre app comme un utilisateur lambda.

Pourquoi le polish est-il plus rentable que les features pour un lancement ?

Les chiffres sont clairs. Sur le Play Store, les apps avec une note inferieure a 4 etoiles perdent jusqu'a 50% de leurs telechargements potentiels. Et les premiers avis sont decisifs : ils definissent la trajectoire de l'app pour les mois suivants.

Ajouter une feature qui impressionne 10% des utilisateurs mais qui cree un bug pour 5% d'entre eux, c'est un mauvais trade-off. En revanche, corriger 30 micro-bugs qui touchent potentiellement tout le monde, c'est de l'investissement a rendement garanti.

Ce sprint de polish a touche l'ensemble du parcours utilisateur : de l'onboarding a la gestion des abonnements, en passant par le coeur de l'app — le dictaphone vocal. Et la difference se joue dans ces 30 commits invisibles.

Le build 30 est pret. L'app est plus propre, plus stable, plus claire qu'elle ne l'a jamais ete. La suite, c'est le grand public.