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 journée de développement ajoutait quelque chose. Une feature, un écran, un pipeline, une intégration. Le compteur de commits montait, les fichiers s'empilaient, et l'app grossissait au fil des 650+ commits.

Et puis un moment arrive où il faut s'arrêter. Pas par fatigue, mais par lucidité. L'app fonctionne pour 12 testeurs alpha qui connaissent ses limites. Mais le grand public ne pardonne pas. Selon une étude d'Apptentive, 77% des utilisateurs lisent au moins un avis avant de télécharger une app. Et un seul bug visible au mauvais moment, c'est un avis 1 étoile.

Cette semaine, j'ai donc fait l'inverse de tout ce que j'avais fait jusque-là : 30 commits en 48 heures. Zéro feature. Que du polish, des corrections et de la préparation pour le moment où l'app sort de l'alpha et entre dans le monde réel.

Comment corriger 15 bugs sur un seul écran de personnalisation IA ?

L'IA de TAMSIV permet aux utilisateurs de se présenter par la voix. Tu appuies, tu racontes ta vie en 30 secondes, et l'assistant s'adapte à ta personnalité. Le problème : l'écran de configuration avait 15 bugs subtils que les tests automatiques ne détectaient pas.

Un bouton caché par un overlay. Un texte tronqué sur petits écrans. Une boucle infinie quand l'utilisateur interrompait l'IA en pleine réponse. Le prompt qui se réinitialisait après chaque modification. Les boutons d'action empilés les uns sur les autres au lieu de se placer verticalement.

Aucun de ces bugs n'aurait été trouvé dans un test rapide. Il fallait utiliser l'app comme un vrai utilisateur — appuyer partout, interrompre au mauvais moment, revenir en arrière, réessayer. C'est ce que le Nielsen Norman Group appelle le test d'utilisabilité exploratoire : pas de script, juste un humain qui essaie de casser l'interface.

15 commits pour rendre un seul écran fiable. Ça semble excessif. Mais quand c'est l'écran qui définit comment l'IA te comprend, chaque micro-bug dégrade l'expérience entière.

Quelle est la différence entre "ça marche en alpha" et "c'est prêt pour la production" ?

Le système d'abonnements Free/Pro/Team existait depuis février. Il marchait en alpha. Mais "marcher en alpha" et "être prêt pour la production" sont deux choses très différentes.

En alpha, 12 testeurs savent que c'est un travail en cours. Ils acceptent un wording approximatif, un design pas tout à fait calé, des limites floues entre les plans. En production, chaque ambiguïté coûte un utilisateur. Selon ProfitWell, une page de pricing confuse peut réduire les conversions de 20 à 40%.

La refonte a touché trois axes :

• Le wording : chaque texte a été relu pour clarifier ce qui est gratuit versus payant. Plus de formulations ambiguës.
• Le design de la modale alpha : elle n'a plus de raison d'exister en production. Supprimée et remplacée par un flow naturel vers les plans RevenueCat.
• Les limites du plan gratuit : chaque écran vérifié sur 3 tailles d'écran différentes, chaque texte responsive.

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

Quels "petits détails" ont le plus d'impact sur la rétention ?

Trois ajustements mineurs ont transformé l'expérience quotidienne de l'app.

Le bouton stop TTS. Quand l'IA te répond à voix haute et que tu veux l'arrêter, avant il fallait couper le son du téléphone. Maintenant un toggle suffit. Ça paraît anodin, mais c'est exactement le type de friction qui pousse un utilisateur à désinstaller. Le dictaphone est le cœur de TAMSIV — il doit être irréprochable.

Le scope strict du LLM. L'IA avait tendance à répondre à des questions hors sujet — météo, culture générale, philosophie. En production, elle doit rester concentrée : tâches, mémos, événements. Point. Un garde-fou backend qui refuse poliment tout le reste. Comme l'explique le guide de prompt engineering d'OpenAI, définir des limites claires au LLM est essentiel pour une expérience utilisateur cohérente.

Le toggle d'images générées. Chaque conversation peut générer une image de couverture via IA, grâce à l'intégration Runware dans le dictaphone. Mais ça coûte des crédits. Un switch dans le header du dictaphone permet maintenant de désactiver la génération d'images à la volée. Transparence et contrôle.

Que représente le versionCode 30 pour un dev solo ?

Chaque build Android a un numéro. On en est au 30ème. Les 29 précédents étaient de l'alpha — des builds pour 12 testeurs qui acceptaient les bugs en échange de la primeur. Le build 30 est le dernier avant que n'importe qui puisse télécharger TAMSIV sur le Play Store.

C'est un chiffre banal. Mais il représente le moment où "mon app" devient "une app". Où le code n'est plus protégé par le filtre bienveillant des bêta-testeurs. Où chaque bug est un avis 1 étoile potentiel.

Pour mettre ça en perspective : le sprint qualité précédent avait déjà corrigé des dizaines de problèmes. 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 décider quand arrêter d'ajouter des features ?

La tentation du développeur 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 crée des interactions imprévues avec le reste.

J'ai appliqué une règle simple : si un bug peut être rencontré dans les 5 premières 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 référence 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 écran 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 ?

Concrètement, voici comment j'ai organisé ces 48 heures :

1. Audit par écran : j'ai ouvert chaque écran de l'app sur 3 appareils différents (petit, moyen, grand) et noté chaque anomalie visuelle ou fonctionnelle.
2. Priorisation par impact : les bugs visibles dans les 5 premières minutes en haut, les edge cases en bas.
3. Commits atomiques : un commit = un fix. Pas de commits fourre-tout. Ça permet de rollback chirurgicalement si un fix casse autre chose.
4. Test de régression : après chaque fix, revérification des écrans adjacents. Quand tu touches l'architecture d'un composant partagé, l'effet domino est réel.

Ce workflow n'est pas spectaculaire. Il n'y a pas de nouvelle techno, pas de refacto héroïque. Juste de la discipline et du temps passé à 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 inférieure à 4 étoiles perdent jusqu'à 50% de leurs téléchargements potentiels. Et les premiers avis sont décisifs : ils définissent la trajectoire de l'app pour les mois suivants.

Ajouter une feature qui impressionne 10% des utilisateurs mais qui crée 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 à rendement garanti.

Ce sprint de polish a touché l'ensemble du parcours utilisateur : de l'onboarding à la gestion des abonnements, en passant par le cœur de l'app — le dictaphone vocal. Et la différence se joue dans ces 30 commits invisibles.

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