App vocale IA en 650 commits : retour d'experience dev solo

Points clés : Construire un gestionnaire de tâches vocal avec IA en solo, c'est 650+ commits, un pipeline audio temps réel (Deepgram + OpenRouter + OpenAI TTS), une architecture React Native New Architecture, et surtout 6 mois de leçons sur ce qu'il ne faut pas faire. Cet article couvre la stack complète, les erreurs coûteuses, et les décisions qui ont fait la différence.

Il y a 6 mois, j'avais un problème tout bête. À la maison, on était 4 avec des bouts de papier collés sur le frigo pour les courses. Au club de plongée, tout passait par WhatsApp — impossible de retrouver une info vieille de trois jours. Les apps existantes ? Trop compliquées, trop de clics, pas adaptées à la vraie vie.

Aujourd'hui, TAMSIV est une app Android complète avec un assistant vocal IA, des groupes collaboratifs hiérarchiques, un agenda avec récurrence, de la gamification, et elle parle 6 langues. Plus de 650 commits. Dev solo. Et je vais te raconter exactement comment j'en suis arrivé là.

Pourquoi créer un gestionnaire de tâches vocal en 2025 ?

La réponse courte : parce que les apps de productivité classiques partent du principe que tu es assis devant un écran avec les deux mains libres. Mais dans la vraie vie, tu es en train de conduire, de cuisiner, de marcher le chien, ou de porter des courses.

J'ai testé des dizaines d'apps — Todoist, Any.do, Google Tasks, Microsoft To Do. Toutes excellentes sur papier. Mais aucune ne mettait la voix au centre. Elles avaient peut-être un bouton micro planqué quelque part, mais l'interaction principale restait le clavier.

Mon pari : la voix comme interface principale. Tu appuies, tu parles, l'IA comprend et crée la tâche. Pas de formulaire, pas de menus déroulants, pas de friction. Si tu veux en savoir plus sur pourquoi les apps de productivité classiques échouent, j'en parle dans cet article sur la fatigue des apps de productivité.

Quelle stack technique pour une app vocale IA ?

Choisir la bonne stack, c'est la décision la plus importante. Voici ce que j'ai retenu après 6 mois :

• Frontend : React Native 0.81 (TypeScript) avec la New Architecture (Fabric). Performances natives, un seul codebase. Le choix s'est imposé parce que je connais React et que je voulais livrer vite.
• Backend : Node.js/Express + WebSocket. Le WebSocket est indispensable pour le streaming audio temps réel — HTTP ne suffit pas.
• Base de données : Supabase PostgreSQL avec 3 schémas séparés (privat, collaborative, gamification). J'explique cette architecture en détail dans mon article sur la structuration de la base de données.
• Website : Next.js 16 + Tailwind CSS 4, déployé sur Vercel. J'ai raconté la construction en 3 jours dans cet article dédié.

Comment fonctionne le pipeline vocal de l'app ?

C'est le cœur technique du projet. L'utilisateur appuie sur le bouton, parle, et reçoit une réponse vocale structurée en 1.5 à 3 secondes. Sous le capot :

Audio PCM 16kHz mono → WebSocket (JWT) → Deepgram STT (VAD) → OpenRouter LLM → Function calling → OpenAI TTS → Reponse vocale

1. Capture audio : Le téléphone envoie des chunks audio bruts en PCM 16 bits, 16kHz, mono via WebSocket.
2. Speech-to-Text : Deepgram transcrit en streaming avec détection automatique de fin de parole (VAD).
3. LLM : OpenRouter route vers 400+ modèles avec fallback automatique. Le modèle comprend l'intention et utilise le function calling pour créer tâches, mémos ou événements.
4. Text-to-Speech : OpenAI TTS (voix "nova") génère la réponse audio, streamée en retour via le même WebSocket.

Chaque étape peut échouer indépendamment. J'ai mis en place des retries intelligents, des circuit breakers, et des fallbacks à chaque niveau. Pour le détail technique complet du pipeline, lis l'article dédié au pipeline vocal.

Quelles features ont demandé le plus de travail ?

En 650+ commits, certaines features ont avalé des semaines entières. Voici le top 3.

Les groupes collaboratifs hiérarchiques

Sur le papier : "ajoute des groupes". En réalité : un système hiérarchique à 6 niveaux de profondeur avec 4 rôles (Admin, Manager, Member, Viewer), des requêtes récursives PostgreSQL (CTE), et 31 politiques RLS à écrire et tester individuellement.

Mon club de plongée a été le cas d'usage parfait : Club → Commission Technique → Niveau 1 → Groupe du mardi. L'héritage des permissions entre niveaux a été le vrai casse-tête. J'en parle en profondeur dans l'article sur les groupes hiérarchiques.

L'agenda avec récurrence

Les LLMs ne sont pas bons avec les dates. Quand tu dis "tous les mardis à 14h", le modèle doit comprendre la récurrence, la timezone, et générer les bonnes occurrences. J'ai dû construire une table de correspondance et un système de validation robuste. Le détail technique est dans l'article sur l'agenda et les filtres.

La gamification

12 niveaux, 10 badges, des streaks jusqu'à 365 jours, des défis quotidiens, et un leaderboard. Un schéma dédié avec 5 tables et des triggers automatiques. La gamification n'est pas un gadget — elle change fondamentalement l'engagement des utilisateurs. J'ai détaillé l'architecture dans l'article sur le schéma de gamification.

Quelles erreurs éviter quand on développe en solo ?

Je vais être honnête : j'ai fait des erreurs coûteuses. Si tu développes un projet solo, apprends de mes plantages.

Erreur n°1 : Zéro marketing pendant 6 mois

650 commits et pas un seul post pour en parler. Aucun. J'étais tellement absorbé par le code que j'ai complètement ignoré la partie visibilité. Le jour où j'ai voulu communiquer, je partais de zéro — zéro audience, zéro contenu, zéro historique.

La leçon : commence le marketing dès le premier commit. Même un simple tweet "je démarre un nouveau projet" vaut mieux que le silence.

Erreur n°2 : Sous-estimer l'internationalisation

Passer de 100% français à 6 langues (FR, EN, DE, ES, IT, PT) a touché 35 fichiers et 1993 clés de traduction. C'est un chantier énorme quand tu le fais après coup. Aujourd'hui, chaque nouvelle feature est traduite dès le départ. L'i18n est devenue un vrai canal d'acquisition — j'en parle dans cet article sur l'i18n comme levier de croissance.

Erreur n°3 : Ne pas structurer la base de données dès le départ

J'ai eu la chance de bien faire ce choix-là, mais j'ai vu tellement de projets où tout est dans le schéma public que je le mentionne. Trois schémas séparés dès le jour 1, ça change tout pour la maintenabilité. Le détail est dans l'article sur la restructuration de la base de données.

Comment gérer un projet solo de cette envergure ?

650 commits en 6 mois, ça fait une moyenne de 3-4 commits par jour. Certains jours j'en faisais 10, d'autres zéro. Voici ce qui m'a aidé :

• Des commits atomiques : chaque commit fait une seule chose. Ça rend le debug et le revert beaucoup plus simples.
• Un monorepo : frontend, backend et website dans le même repo. Un seul git log pour voir l'historique complet du projet.
• Des singletons services : ConversationService, CalendarService, GamificationService... chaque domaine a son service dédié, facile à tester et à maintenir.
• Le pattern PendingCreation : la voix crée une preview, l'utilisateur valide, édite ou annule avant la sauvegarde en base. Zéro surprise.

Quel est le coût de fonctionnement d'une app vocale IA ?

Question que tout le monde pose. Voici la décomposition par interaction vocale :

• STT natif (device) : gratuit. Deepgram cloud en fallback : ~$0.0059/min.
• LLM via OpenRouter : variable selon le modèle, typiquement $0.001-0.01 par requête.
• TTS OpenAI : ~$0.015 pour 1000 caractères.
• Supabase : plan gratuit généreux, puis ~$25/mois en Pro.
• Backend Railway : ~$5-10/mois selon l'usage.

Au total, une interaction vocale complète coûte entre $0.01 et $0.03. C'est viable avec un modèle freemium — j'ai détaillé les tiers d'abonnement dans l'article sur RevenueCat et les abonnements.

Où en est le projet aujourd'hui ?

TAMSIV est en alpha sur le Google Play Store. 12 testeurs actifs. Le lancement en production publique est imminent.

Les métriques qui comptent :

• 650+ commits sur le monorepo
• 6 langues supportées (FR, EN, DE, ES, IT, PT)
• 3 modes WebSocket (Live, Realtime, Batch)
• 31 politiques RLS pour la sécurité des données
• 12 niveaux de gamification avec badges et streaks
• 6 onglets : Dictaphone, Feed, Agenda, Groups, Social, Profile

FAQ

Combien de temps faut-il pour construire une app vocale IA en solo ?

Pour TAMSIV, il a fallu 6 mois à temps plein. Le pipeline vocal seul (STT + LLM + TTS) a pris environ 3 semaines. Les groupes collaboratifs et la gamification ont ajouté 2 mois chacun. Si tu te concentres sur le MVP vocal uniquement, compte 2-3 mois.

Pourquoi React Native plutôt que Flutter ou natif ?

Je connaissais déjà React. La New Architecture (Fabric) de React Native 0.81 offre des performances quasi-natives. Flutter était une option valable, mais l'écosystème npm et la communauté React ont fait pencher la balance. Le natif pur aurait doublé le temps de dev sans avantage significatif pour ce type d'app.

Est-ce que le Speech-to-Text natif est aussi bon que Deepgram ?

Pour la majorité des cas, le STT natif du device est suffisant et gratuit. Deepgram excelle dans les environnements bruyants et pour les langues non-européennes. TAMSIV utilise le natif par défaut et bascule sur Deepgram en fallback. J'ai comparé les deux en détail dans l'article STT natif vs Deepgram.

Comment monétiser une app vocale IA sans exploser les coûts ?

Le modèle freemium avec des limites quotidiennes sur le plan gratuit. Les features coûteuses (STT cloud, génération d'images IA) sont réservées aux plans Pro et Team. RevenueCat gère les abonnements in-app. Le secret, c'est d'optimiser le coût par interaction — le STT natif gratuit couvre 90% des usages.

Faut-il un backend pour une app vocale ou tout peut tourner en local ?

Tu as besoin d'un backend pour le LLM (function calling, orchestration) et le TTS (les API sont côté serveur). Le STT peut tourner en local. Le WebSocket est indispensable pour le streaming temps réel — les appels HTTP classiques ajoutent trop de latence.