38 commits, zéro feature : le sprint qui compte

38 commits en 10 jours. Zéro nouvelle fonctionnalité. Et pourtant, c'est probablement la semaine la plus importante depuis le début du projet.

C'est le paradoxe du développement produit : les semaines qui comptent le plus sont celles où il ne se passe "rien" de visible. Pas de nouvelle feature à annoncer, pas de screenshot spectaculaire. Juste du code qui rend l'existant meilleur, plus solide, plus professionnel. Dans le monde du build in public, ces sprints silencieux ne font pas de likes. Mais ils font la différence entre une app qui "marche chez moi" et une app prête pour de vrais utilisateurs.

Points clés

• 38 commits concentrés sur la stabilité, pas sur les features, avec un agenda web passé de 1 à 4 vues pour une parité complète mobile/desktop.
• Crashlytics (frontend) + Sentry (backend) déployés avant la production, conformément aux recommandations Firebase de monitoring pré-lancement.
• L'IA vocale détecte tes patterns de nommage existants et les reproduit automatiquement pour les nouveaux dossiers.
• Tracking UTM sur tous les liens partagés pour une attribution marketing fiable dès le jour 1.

Pourquoi un sprint sans feature est-il le plus important ?

Selon une étude de Stripe (2018), les développeurs passent en moyenne 42% de leur temps à gérer la dette technique et la maintenance. Ce n'est pas du temps perdu : c'est du temps investi. Un sprint "zéro feature" consiste à s'arrêter volontairement d'ajouter du neuf pour consolider ce qui existe déjà.

Concrètement, qu'est-ce que ça veut dire pour TAMSIV ? 10 jours à corriger des micro-bugs, lisser des transitions, aligner le web sur le mobile, ajouter du monitoring. Rien de flashy. Mais au bout de ces 10 jours, la qualité perçue de l'app a changé de dimension.

J'en avais parlé dans l'article sur le sprint final zéro feature : le réflexe naturel d'un dev, c'est d'ajouter. Toujours ajouter. Il faut une vraie discipline pour se dire "non, cette semaine on consolide". C'est la philosophie que je continue d'appliquer. Est-ce que ça paie ? Les 12 testeurs alpha n'ont remonté aucun crash sur cette période. Zéro. La première fois depuis le début du projet.

Comment l'agenda web est-il passé de 1 à 4 vues ?

L'agenda du dashboard web n'avait qu'une seule vue : la semaine. Suffisant pour une démo, insuffisant pour un usage quotidien. J'ai ajouté trois vues supplémentaires (jour, mois, année) pour atteindre la parité avec l'agenda mobile, que j'avais détaillé ici.

L'objectif technique est clair : que la transition entre le téléphone et l'ordinateur soit invisible. Tu crées une tâche vocalement sur ton téléphone le matin, tu la retrouves sur ton écran d'ordinateur à midi avec exactement la même présentation. Cliquer sur un événement ouvre ses détails. Cliquer sur une tâche, pareil.

Les pages de détail des tâches et mémos ont été entièrement redessinées pour matcher l'expérience mobile. Thumbnails d'images, navigation fluide, même structure visuelle. C'est un travail ingrat mais essentiel : chaque incohérence entre mobile et web crée de la friction cognitive chez l'utilisateur. Et la friction, c'est l'ennemi numéro 1 de la rétention.

Pourquoi ajouter Crashlytics et Sentry avant la production ?

Quand ton app est utilisée par toi et 12 testeurs, tu peux te permettre de debugger via les logs Supabase et le "ça marche chez moi". Quand tu t'apprêtes à passer en production publique, ce n'est plus une option. D'après la documentation Firebase Crashlytics, les apps qui configurent le monitoring avant le lancement détectent les crashs critiques 10x plus vite que celles qui réagissent après les premières plaintes utilisateurs.

J'ai mis en place deux systèmes complémentaires :

Firebase Crashlytics sur le frontend React Native

Crashlytics capture trois types de problèmes sur le mobile. D'abord les crashes (l'app qui se ferme brutalement), ensuite les ANR, Application Not Responding, ces moments où l'app freeze pendant plus de 5 secondes, et enfin les erreurs JavaScript non catchées. Pour chaque incident, on obtient la stack trace complète, le modèle de téléphone, la version d'Android, et ce que l'utilisateur faisait juste avant. J'avais déjà décrit le pipeline audio dans l'article STT natif vs Deepgram, c'est exactement le type de chaîne complexe où un crash silencieux peut passer inaperçu sans monitoring dédié.

Sentry sur le backend Node.js/Express

Côté serveur, Sentry capture les erreurs API, les timeouts WebSocket, les exceptions non gérées. Ce qui fait la différence, ce sont les breadcrumbs : Sentry enregistre une chronologie des événements qui ont mené à l'erreur. Si un appel OpenRouter timeout après un appel Supabase lent, tu vois toute la chaîne. Plus le performance monitoring qui mesure les temps de réponse de chaque endpoint.

L'idée est simple : quand un bug se produit en production, on le sait avant que l'utilisateur ne s'en plaigne. C'est la différence entre "on a un problème" et "on a résolu le problème avant que tu le remarques".

Comment l'IA détecte-t-elle tes patterns de nommage ?

Un seul commit, mais le genre qui change l'expérience au quotidien. L'assistant vocal de TAMSIV analyse désormais les noms de tes dossiers existants pour détecter des patterns de nommage récurrents, et les reproduire automatiquement.

Prenons un exemple concret. Tu as trois dossiers : "Courses Carrefour", "Courses Leclerc", "Courses Aldi". Tu dis à l'IA "crée un dossier courses pour Lidl". Avant, elle aurait créé "Lidl" ou "Courses" tout court. Maintenant, elle détecte le pattern [Catégorie] + [Nom du magasin] et crée automatiquement "Courses Lidl".

Un autre exemple : tes dossiers projets sont nommés "Projet Alpha - Q1", "Projet Beta - Q2". L'IA repère le format [Projet] + [Nom] + [Trimestre]. Quand tu crées un nouveau dossier projet, elle applique la même convention sans que tu aies à le préciser.

C'est le genre de détail qu'aucun utilisateur ne demandera jamais, mais que tout le monde remarque quand c'est là. J'en avais parlé dans l'article sur la personnalisation vocale : l'IA ne fait pas juste ce que tu lui dis. Elle comprend comment tu t'organises.

Quelles optimisations CRO pour la landing page ?

Selon Google Web Vitals, un LCP (Largest Contentful Paint) supérieur à 2.5 secondes impacte directement le taux de rebond. La landing page tamsiv.com a reçu plusieurs optimisations ciblées pour rester sous ce seuil.

Le hero glow animé utilisait un Canvas JavaScript qui consommait trop de CPU, surtout sur mobile. Je l'ai remplacé par du CSS pur : même effet visuel, zéro impact sur la batterie. C'est typiquement le genre de dette technique invisible qu'on ne corrige que pendant un sprint zéro feature.

Le sous-titre du hero a été réécrit pour expliquer clairement ce que fait TAMSIV en une phrase. En CRO, la clarté du message au-dessus de la ligne de flottaison est le facteur numéro 1 de conversion. Si le visiteur ne comprend pas ce que tu fais en 3 secondes, il part.

J'ai aussi amélioré le layout pricing : le label annuel est maintenant sur sa propre ligne pour plus de lisibilité. Et le scroll spy du header a été corrigé : l'état actif ne se nettoyait pas correctement en scrollant vers le haut, un bug subtil mais agaçant.

Comment le tracking UTM améliore-t-il la stratégie marketing ?

Savoir d'où viennent tes visiteurs, c'est la base de toute stratégie marketing. Sans tracking, tu postes du contenu à l'aveugle. Avec, tu sais exactement quel post LinkedIn, quel message Discord, quelle campagne génère du trafic réel. D'après la documentation Google Analytics, les paramètres UTM sont le standard pour l'attribution de campagne.

J'ai implémenté trois choses. D'abord, des paramètres UTM sur chaque lien partagé : source, medium, campaign, content. Ensuite, une capture d'IP côté serveur pour des analytics plus fiables que le JavaScript client-side, qui est bloqué par les adblockers. Et enfin, un admin dashboard enrichi avec sélecteur de période (7 jours, 30 jours, 90 jours, tout) et une configuration synchronisée entre mobile et web. J'avais posé les bases de ce dashboard dans l'article sur l'admin dashboard, c'est maintenant un outil complet.

Le résultat concret ? Sur la dernière session marketing, j'ai pu voir que l'i18n en 6 langues générait 60% du trafic entrant. Sans UTM, je n'aurais jamais eu cette donnée.

versionCode 32 : quelle est la prochaine étape ?

La build Android en est à sa 32ème version. Plus de 740 commits au total. L'app est soumise au Play Store pour la revue de production. En attendant la validation de Google, on continue de polir chaque détail.

38 commits, zéro feature, et une app qui est passée de "ça marche" à "c'est prêt". C'est exactement le type de sprint qui ne fait pas de bruit, mais qui fait la différence le jour où les vrais utilisateurs débarquent.

Questions fréquentes

Qu'est-ce qu'un sprint "zéro feature" ?

C'est une période de développement volontairement consacrée à la stabilité, la performance et la dette technique, sans ajouter de nouvelles fonctionnalités. L'objectif est de consolider l'existant avant un jalon important, comme un lancement en production.

Pourquoi utiliser Crashlytics ET Sentry ensemble ?

Crashlytics est spécialisé dans le monitoring mobile (crashes, ANR, erreurs JS dans React Native). Sentry couvre le backend Node.js (erreurs API, WebSocket, performance). Les deux combinés donnent une visibilité complète sur toute la chaîne, du téléphone au serveur.

Comment fonctionne la détection de patterns de nommage par l'IA ?

L'assistant vocal analyse les noms de dossiers existants pour identifier des conventions récurrentes (préfixe commun, format structuré). Quand tu crées un nouveau dossier, l'IA applique automatiquement le même pattern sans que tu aies besoin de le préciser.

Qu'est-ce que le tracking UTM et pourquoi c'est important ?

Les paramètres UTM (source, medium, campaign) sont ajoutés aux URLs partagées pour identifier précisément d'où vient chaque visiteur. Sans ce tracking, il est impossible de savoir quel canal marketing fonctionne vraiment, selon la documentation Google Analytics.

TAMSIV est-il disponible sur le Play Store ?

L'app est actuellement en phase de test alpha fermé avec 12 testeurs. La soumission pour la production publique est en cours de validation par Google. En attendant, tu peux découvrir le projet sur tamsiv.com.