Premiere video de demo et sprint qualite : 7 corrections critiques

Apres 6 mois de developpement et plus de 700 commits, TAMSIV avait tout : un pipeline vocal fonctionnel, un systeme de gamification, des groupes collaboratifs, 6 langues supportees. Mais il manquait quelque chose d'essentiel — une video. Parce qu'une app vocale, ca ne se decrit pas. Ca se montre. Cette semaine, j'ai tourne la premiere video de demo de TAMSIV, et en parallele, j'ai boucle un sprint qualite qui a corrige 7 problemes critiques.

Points cles a retenir :
- Une video de demo est indispensable pour une app vocale — "parlez et l'IA comprend" ne suffit pas, il faut voir le micro qui s'active et la tache qui se cree.
- Un sprint qualite (0 feature, 7 corrections) a autant d'impact qu'un mois de developpement quand il cible les frictions quotidiennes.
- Le bouton stop d'un dictaphone doit fonctionner a 100% — meme 1% d'echec detruit la confiance.
- Toujours vider le cache singleton au logout sur appareil partage — une fuite de donnees entre sessions est un bug de securite critique.

Pourquoi une video de demo est-elle indispensable pour une app vocale ?

Depuis 6 mois, TAMSIV existait en texte et en captures d'ecran. Sur le site web, dans les articles de blog, sur les fiches Play Store. Mais une app vocale a un probleme fondamental de communication : l'interaction principale est invisible.

Tu peux ecrire "parlez, l'IA comprend et organise" autant de fois que tu veux. Tant que le visiteur n'a pas vu le micro qui s'active, la transcription en temps reel, la tache qui se cree toute seule dans le bon dossier — il ne comprend pas vraiment ce que fait l'app.

Comme l'explique Wyzowl dans son rapport 2026 sur le video marketing, 96% des consommateurs regardent une video explicative avant d'acheter un produit ou de telecharger une app. Pour une app vocale, ce chiffre est probablement encore plus eleve — le concept meme necessite une demonstration visuelle.

La video est maintenant visible sur YouTube et directement integree dans le hero du site tamsiv.com. Le visiteur voit immediatement comment fonctionne TAMSIV, sans avoir besoin de telecharger l'app ni de lire une documentation.

Comment integrer une video dans le hero d'un site Next.js ?

L'integration dans le site Next.js etait une evidence — mais avec quelques contraintes techniques :

• Performance : pas d'autoplay, pas de preload du fichier video complet. Un embed YouTube avec facade (image placeholder + bouton play) pour eviter de charger l'iframe au premier rendu.
• Mobile responsive : le ratio 16:9 doit s'adapter sans bande noire ni debordement sur tous les ecrans.
• SEO : balise VideoObject en JSON-LD pour que Google indexe la video et l'affiche dans les resultats enrichis.

Le resultat : le hero du site montre maintenant une preview de la video avec un bouton play. Un clic charge l'embed YouTube. C'est le meilleur compromis entre impact visuel et performance — le Largest Contentful Paint n'est pas impacte.

Pourquoi un sprint 0 feature change tout pour la retention ?

En parallele de la video, j'ai consacre une semaine a un sprint 100% qualite. Pas de nouvelle fonctionnalite — uniquement du polish, de la fiabilite, et des corrections silencieuses qui font la difference au quotidien. 7 commits. 0 nouvelle feature.

C'est contre-intuitif quand tu es dev solo. Tu as une liste de features a ajouter longue comme le bras. Chaque jour sans nouvelle feature te semble perdu. Mais c'est exactement l'inverse : chaque micro-friction supprimee, chaque bug silencieux corrige, c'est un utilisateur de plus qui ne desinstalle pas au bout de 3 jours.

Ce sprint fait suite au sprint qualite precedent qui avait deja corrige les rappels et les emails. Cette fois, les corrections touchent le coeur de l'app.

Comment rendre un bouton stop fiable a 100% sur un dictaphone vocal ?

Le bug le plus frustrant de l'app : parfois, le bouton "stop" ne repondait pas. Le micro continuait d'enregistrer, l'utilisateur devait forcer l'arret. Cauchemar UX absolu.

La cause ? Un probleme de timing entre l'initialisation du STT natif (reconnaissance vocale du telephone) et le state React. Quand l'utilisateur appuyait sur stop pendant une fenetre de quelques millisecondes ou le STT etait en transition entre deux etats, le callback de stop etait simplement ignore.

La solution technique en 3 points

• Mode "standby" pour le STT natif : au lieu d'initialiser completement le STT a chaque pression sur le bouton micro, il reste en etat de veille active. Resultat : demarrage 2x plus rapide, pas d'attente de callback.
• Bouton stop absolu : quel que soit l'etat interne du STT (initialisation, ecoute, traitement), le bouton stop declenche un arret force. Pas de condition, pas de "attends que le callback revienne".
• Cleanup de securite : un timeout de 30 secondes nettoie automatiquement tout etat residuel — inspire du pattern utilise dans l'AudioPlayerService.

Ce fix est peut-etre le plus important de tout le sprint. Le pipeline vocal est le coeur de TAMSIV. Si le bouton d'enregistrement n'est pas fiable a 100%, rien d'autre n'a d'importance.

Comment faire comprendre les plages de dates a une IA vocale ?

Avant, demander "qu'est-ce que j'ai cette semaine ?" a l'IA ne fonctionnait que pour un jour. Le system prompt limitait les requetes a une date unique. Un probleme typique de la conception de prompts pour l'IA conversationnelle.

La solution a necessite deux modifications :

1. Extension du system prompt : ajout d'exemples de plages de dates ("du lundi au vendredi", "les 3 prochains jours", "cette semaine") dans les instructions de l'IA.
2. Modification du function calling : le tool create_calendar_event accepte maintenant un parametre end_date optionnel pour les requetes portant sur une plage.

Maintenant, l'assistant comprend les plages : "du lundi au vendredi", "les 3 prochains jours", "cette semaine". C'est un changement subtil mais qui transforme l'utilisation de l'agenda au quotidien.

Pourquoi passer de SDXL a HiDream pour la generation d'images IA ?

Les images de couverture des dossiers dans TAMSIV sont generees par IA. On utilisait SDXL 0.9, qui avait deux problemes majeurs : il comprenait mal les prompts complexes (texte melange, instructions ignorees) et la qualite etait inconsistante.

Le switch vers HiDream-I1-Fast via Runware a tout change. Meilleure comprehension du prompt, resultats plus coherents, et un cout de ~0.003 EUR par image. C'est le meme modele que j'utilise pour les images IA inline dans le dictaphone — la coherence visuelle est maintenue dans toute l'app.

Comment detecter une fuite de donnees entre sessions utilisateur ?

Un bug critique decouvert et corrige pendant ce sprint : sur un appareil partage, les donnees de l'utilisateur precedent pouvaient brievement apparaitre lors d'un changement de compte. Le cache singleton n'etait pas vide au logout.

C'est un bug de securite de classe critique. Meme si l'exposition est breve (quelques centaines de millisecondes), un utilisateur peut voir les taches, les memos ou les evenements d'un autre utilisateur. Dans une app de productivite qui gere des donnees personnelles, c'est inacceptable.

La correction : nettoyage complet au logout

La solution est simple en theorie mais demande de la rigueur : chaque service singleton (ContentCacheService, CalendarService, GamificationService) a recu une methode clearAll() appelee systematiquement a chaque deconnexion. Le systeme de securite de TAMSIV inclut maintenant une verification que tous les caches sont vides avant d'initialiser une nouvelle session.

Quel est l'impact combine de la video et du sprint qualite ?

La video et le sprint qualite sont deux faces de la meme piece :

• La video est la vitrine — elle rend le projet tangible pour quelqu'un qui n'a jamais touche l'app. C'est l'outil d'acquisition.
• Le sprint qualite est les fondations — il fait la difference entre une app qu'on essaie et une app qu'on garde. C'est l'outil de retention.

Les deux se completent parfaitement. Attirer des utilisateurs avec une belle video pour les perdre a cause d'un bouton stop defaillant serait un desastre. A l'inverse, une app parfaitement polie que personne ne connait ne sert a rien.

C'est exactement la logique que je detaille dans l'article sur le parcours des 650+ commits : chaque phase du projet alterne entre features visibles et polish invisible.

Quelles lecons tirer pour un dev solo qui lance son app ?

Apres cette semaine, voici ce que je retiens :

1. Tourne ta video tot. N'attends pas que l'app soit "parfaite". Une video de 2 minutes avec un produit fonctionnel vaut mieux que des mois de descriptions textuelles.
2. Planifie tes sprints qualite. Bloque une semaine sur deux sans aucune feature. Le sprint zero-feature est devenu un rituel pour moi.
3. Le bouton principal doit etre infaillible. Pour TAMSIV, c'est le bouton micro. Pour toi, c'est le bouton qui represente ton core value proposition. S'il echoue une fois, tu perds la confiance.
4. Verifie la securite des singletons au logout. Si tu utilises des caches en memoire dans une app mobile, assure-toi qu'ils sont nettoyes a chaque changement de session.

Questions frequentes

Combien de temps faut-il pour tourner une video de demo d'app mobile ?

Pour TAMSIV, la video de 2 minutes a necessite environ une demi-journee : preparation du scenario, 3 prises, montage basique. Pas besoin d'un studio professionnel — un bon eclairage et un ecran bien cadre suffisent. L'important est de montrer l'interaction reelle, pas un mockup.

Faut-il un sprint qualite avant ou apres le lancement ?

Les deux. Avant le lancement, un sprint qualite cible les frictions les plus visibles (comme le bouton stop). Apres le lancement, les retours utilisateurs guident les priorites. Je recommande un sprint qualite toutes les 2 semaines pendant la phase de beta.

Le mode standby du STT consomme-t-il plus de batterie ?

Non, le mode standby maintient le module STT en memoire mais ne demarre pas l'ecoute active. La consommation batterie est negligeable comparee a l'enregistrement actif. C'est comparable a garder une connexion SpeechRecognizer initialisee sans la demarrer.

Comment eviter les fuites de donnees entre sessions sur appareil partage ?

Trois regles : (1) chaque service singleton doit avoir une methode clearAll(), (2) cette methode est appelee dans le handler de logout, (3) un test automatise verifie que tous les caches sont vides apres logout. C'est basique mais souvent oublie dans les architectures a base de singletons.

HiDream-I1-Fast est-il meilleur que SDXL pour la generation d'images d'app ?

Pour les images de couverture et les illustrations contextuelles, oui. HiDream comprend mieux les prompts complexes et produit des resultats plus coherents. SDXL reste pertinent pour du photoralisme pur, mais pour des images fonctionnelles dans une app mobile, HiDream est un meilleur choix a un cout similaire (~0.003 EUR/image).