Premiere video de demo et sprint qualite : 7 corrections critiques

Après 6 mois de développement et plus de 700 commits, TAMSIV avait tout : un pipeline vocal fonctionnel, un système de gamification, des groupes collaboratifs, 6 langues supportées. Mais il manquait quelque chose d'essentiel — une vidéo. Parce qu'une app vocale, ça ne se décrit pas. Ça se montre. Cette semaine, j'ai tourné la première vidéo de démo de TAMSIV, et en parallèle, j'ai bouclé un sprint qualité qui a corrigé 7 problèmes critiques.

Points clés à retenir :
- Une vidéo de démo est indispensable pour une app vocale — "parlez et l'IA comprend" ne suffit pas, il faut voir le micro qui s'active et la tâche qui se crée.
- Un sprint qualité (0 feature, 7 corrections) a autant d'impact qu'un mois de développement quand il cible les frictions quotidiennes.
- Le bouton stop d'un dictaphone doit fonctionner à 100% — même 1% d'échec détruit la confiance.
- Toujours vider le cache singleton au logout sur appareil partagé — une fuite de données entre sessions est un bug de sécurité critique.

Pourquoi une vidéo de démo est-elle indispensable pour une app vocale ?

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

Tu peux écrire "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 réel, la tâche qui se crée 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 vidéo explicative avant d'acheter un produit ou de télécharger une app. Pour une app vocale, ce chiffre est probablement encore plus élevé — le concept même nécessite une démonstration visuelle.

La vidéo est maintenant visible sur YouTube et directement intégrée dans le hero du site tamsiv.com. Le visiteur voit immédiatement comment fonctionne TAMSIV, sans avoir besoin de télécharger l'app ni de lire une documentation.

Comment intégrer une vidéo dans le hero d'un site Next.js ?

L'intégration dans le site Next.js était une évidence — mais avec quelques contraintes techniques :

• Performance : pas d'autoplay, pas de preload du fichier vidéo complet. Un embed YouTube avec façade (image placeholder + bouton play) pour éviter de charger l'iframe au premier rendu.
• Mobile responsive : le ratio 16:9 doit s'adapter sans bande noire ni débordement sur tous les écrans.
• SEO : balise VideoObject en JSON-LD pour que Google indexe la vidéo et l'affiche dans les résultats enrichis.

Le résultat : le hero du site montre maintenant une preview de la vidéo 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 impacté.

Pourquoi un sprint 0 feature change tout pour la rétention ?

En parallèle de la vidéo, j'ai consacré une semaine à un sprint 100% qualité. Pas de nouvelle fonctionnalité — uniquement du polish, de la fiabilité, et des corrections silencieuses qui font la différence au quotidien. 7 commits. 0 nouvelle feature.

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

Ce sprint fait suite au sprint qualité précédent qui avait déjà corrigé les rappels et les emails. Cette fois, les corrections touchent le cœur de l'app.

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

Le bug le plus frustrant de l'app : parfois, le bouton "stop" ne répondait pas. Le micro continuait d'enregistrer, l'utilisateur devait forcer l'arrêt. Cauchemar UX absolu.

La cause ? Un problème de timing entre l'initialisation du STT natif (reconnaissance vocale du téléphone) et le state React. Quand l'utilisateur appuyait sur stop pendant une fenêtre de quelques millisecondes où le STT était en transition entre deux états, le callback de stop était simplement ignoré.

La solution technique en 3 points

• Mode "standby" pour le STT natif : au lieu d'initialiser complètement le STT à chaque pression sur le bouton micro, il reste en état de veille active. Résultat : démarrage 2x plus rapide, pas d'attente de callback.
• Bouton stop absolu : quel que soit l'état interne du STT (initialisation, écoute, traitement), le bouton stop déclenche un arrêt forcé. Pas de condition, pas de "attends que le callback revienne".
• Cleanup de sécurité : un timeout de 30 secondes nettoie automatiquement tout état résiduel — inspiré du pattern utilisé dans l'AudioPlayerService.

Ce fix est peut-être le plus important de tout le sprint. Le pipeline vocal est le cœur de TAMSIV. Si le bouton d'enregistrement n'est pas fiable à 100%, rien d'autre n'a d'importance.

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

Avant, demander "qu'est-ce que j'ai cette semaine ?" à l'IA ne fonctionnait que pour un jour. Le system prompt limitait les requêtes à une date unique. Un problème typique de la conception de prompts pour l'IA conversationnelle.

La solution a nécessité 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 paramètre end_date optionnel pour les requêtes 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 à HiDream pour la génération d'images IA ?

Les images de couverture des dossiers dans TAMSIV sont générées par IA. On utilisait SDXL 0.9, qui avait deux problèmes majeurs : il comprenait mal les prompts complexes (texte mélangé, instructions ignorées) et la qualité était inconsistante.

Le switch vers HiDream-I1-Fast via Runware a tout changé. Meilleure compréhension du prompt, résultats plus cohérents, et un coût de ~0.003 EUR par image. C'est le même modèle que j'utilise pour les images IA inline dans le dictaphone — la cohérence visuelle est maintenue dans toute l'app.

Comment détecter une fuite de données entre sessions utilisateur ?

Un bug critique découvert et corrigé pendant ce sprint : sur un appareil partagé, les données de l'utilisateur précédent pouvaient brièvement apparaître lors d'un changement de compte. Le cache singleton n'était pas vidé au logout.

C'est un bug de sécurité de classe critique. Même si l'exposition est brève (quelques centaines de millisecondes), un utilisateur peut voir les tâches, les mémos ou les événements d'un autre utilisateur. Dans une app de productivité qui gère des données personnelles, c'est inacceptable.

La correction : nettoyage complet au logout

La solution est simple en théorie mais demande de la rigueur : chaque service singleton (ContentCacheService, CalendarService, GamificationService) a reçu une méthode clearAll() appelée systématiquement à chaque déconnexion. Le système de sécurité de TAMSIV inclut maintenant une vérification que tous les caches sont vidés avant d'initialiser une nouvelle session.

Quel est l'impact combiné de la vidéo et du sprint qualité ?

La vidéo et le sprint qualité sont deux faces de la même pièce :

• La vidéo est la vitrine — elle rend le projet tangible pour quelqu'un qui n'a jamais touché l'app. C'est l'outil d'acquisition.
• Le sprint qualité est les fondations — il fait la différence entre une app qu'on essaie et une app qu'on garde. C'est l'outil de rétention.

Les deux se complètent parfaitement. Attirer des utilisateurs avec une belle vidéo pour les perdre à cause d'un bouton stop défaillant serait un désastre. À l'inverse, une app parfaitement polie que personne ne connaît ne sert à rien.

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

Quelles leçons tirer pour un dev solo qui lance son app ?

Après cette semaine, voici ce que je retiens :

1. Tourne ta vidéo tôt. N'attends pas que l'app soit "parfaite". Une vidéo de 2 minutes avec un produit fonctionnel vaut mieux que des mois de descriptions textuelles.
2. Planifie tes sprints qualité. Bloque une semaine sur deux sans aucune feature. Le sprint zéro-feature est devenu un rituel pour moi.
3. Le bouton principal doit être infaillible. Pour TAMSIV, c'est le bouton micro. Pour toi, c'est le bouton qui représente ton core value proposition. S'il échoue une fois, tu perds la confiance.
4. Vérifie la sécurité des singletons au logout. Si tu utilises des caches en mémoire dans une app mobile, assure-toi qu'ils sont nettoyés à chaque changement de session.

Questions fréquentes

Combien de temps faut-il pour tourner une vidéo de démo d'app mobile ?

Pour TAMSIV, la vidéo de 2 minutes a nécessité environ une demi-journée : préparation du scénario, 3 prises, montage basique. Pas besoin d'un studio professionnel — un bon éclairage et un écran bien cadré suffisent. L'important est de montrer l'interaction réelle, pas un mockup.

Faut-il un sprint qualité avant ou après le lancement ?

Les deux. Avant le lancement, un sprint qualité cible les frictions les plus visibles (comme le bouton stop). Après le lancement, les retours utilisateurs guident les priorités. Je recommande un sprint qualité toutes les 2 semaines pendant la phase de bêta.

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

Non, le mode standby maintient le module STT en mémoire mais ne démarre pas l'écoute active. La consommation batterie est négligeable comparée à l'enregistrement actif. C'est comparable à garder une connexion SpeechRecognizer initialisée sans la démarrer.

Comment éviter les fuites de données entre sessions sur appareil partagé ?

Trois règles : (1) chaque service singleton doit avoir une méthode clearAll(), (2) cette méthode est appelée dans le handler de logout, (3) un test automatisé vérifie que tous les caches sont vides après logout. C'est basique mais souvent oublié dans les architectures à base de singletons.

HiDream-I1-Fast est-il meilleur que SDXL pour la génération d'images d'app ?

Pour les images de couverture et les illustrations contextuelles, oui. HiDream comprend mieux les prompts complexes et produit des résultats plus cohérents. SDXL reste pertinent pour du photoralisme pur, mais pour des images fonctionnelles dans une app mobile, HiDream est un meilleur choix à un coût similaire (~0.003 EUR/image).