Blog
Build in Public
30 mars 20265 min

Le sprint final — 30 commits en 48h, zéro feature

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.

Cette semaine, j'ai fait l'inverse. 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.

La personnalisation IA — 15 commits pour dire "stop"

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. Le problème : l'écran de configuration avait 15 bugs subtils.

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. 15 commits pour rendre un seul écran fiable.

Les abonnements passent en mode 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.

La refonte a touché le wording (clarifier ce qui est gratuit vs payant), le design de la modale alpha (qui n'a plus de raison d'exister en production), et surtout les limites du plan gratuit. Chaque texte a été relu, chaque écran vérifié sur 3 tailles d'écran différentes.

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.

Les petits détails qui changent tout

Un bouton "stop" pour le 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.

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.

Le toggle d'images générées. Chaque conversation peut générer une image de couverture via IA. 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.

versionCode 30 — le chiffre qui compte

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 beta-testeurs. Où chaque bug est un avis 1 étoile potentiel.

Pourquoi un sprint sans feature

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.

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. Et la différence se joue dans ces 30 commits invisibles.