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

Points cles : Construire un gestionnaire de taches vocal avec IA en solo, c'est 650+ commits, un pipeline audio temps reel (Deepgram + OpenRouter + OpenAI TTS), une architecture React Native New Architecture, et surtout 6 mois de lecons sur ce qu'il ne faut pas faire. Cet article couvre la stack complete, les erreurs couteuses, et les decisions qui ont fait la difference.

Il y a 6 mois, j'avais un probleme tout bete. A la maison, on etait 4 avec des bouts de papier colles sur le frigo pour les courses. Au club de plongee, tout passait par WhatsApp — impossible de retrouver une info vieille de trois jours. Les apps existantes ? Trop compliquees, trop de clics, pas adaptees a la vraie vie.

Aujourd'hui, TAMSIV est une app Android complete avec un assistant vocal IA, des groupes collaboratifs hierarchiques, un agenda avec recurrence, de la gamification, et elle parle 6 langues. Plus de 650 commits. Dev solo. Et je vais te raconter exactement comment j'en suis arrive la.

Pourquoi creer un gestionnaire de taches vocal en 2025 ?

La reponse courte : parce que les apps de productivite classiques partent du principe que tu es assis devant un ecran 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 teste 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-etre un bouton micro planque quelque part, mais l'interaction principale restait le clavier.

Mon pari : la voix comme interface principale. Tu appuies, tu parles, l'IA comprend et cree la tache. Pas de formulaire, pas de menus deroulants, pas de friction. Si tu veux en savoir plus sur pourquoi les apps de productivite classiques echouent, j'en parle dans cet article sur la fatigue des apps de productivite.

Quelle stack technique pour une app vocale IA ?

Choisir la bonne stack, c'est la decision la plus importante. Voici ce que j'ai retenu apres 6 mois :

• Frontend : React Native 0.81 (TypeScript) avec la New Architecture (Fabric). Performances natives, un seul codebase. Le choix s'est impose 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 reel — HTTP ne suffit pas.
• Base de donnees : Supabase PostgreSQL avec 3 schemas separes (privat, collaborative, gamification). J'explique cette architecture en detail dans mon article sur la structuration de la base de donnees.
• Website : Next.js 16 + Tailwind CSS 4, deploye sur Vercel. J'ai raconte la construction en 3 jours dans cet article dedie.

Comment fonctionne le pipeline vocal de l'app ?

C'est le coeur technique du projet. L'utilisateur appuie sur le bouton, parle, et recoit une reponse vocale structuree en 1.5 a 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 telephone envoie des chunks audio bruts en PCM 16 bits, 16kHz, mono via WebSocket.
2. Speech-to-Text : Deepgram transcrit en streaming avec detection automatique de fin de parole (VAD).
3. LLM : OpenRouter route vers 400+ modeles avec fallback automatique. Le modele comprend l'intention et utilise le function calling pour creer taches, memos ou evenements.
4. Text-to-Speech : OpenAI TTS (voix "nova") genere la reponse audio, streamee en retour via le meme WebSocket.

Chaque etape peut echouer independamment. J'ai mis en place des retries intelligents, des circuit breakers, et des fallbacks a chaque niveau. Pour le detail technique complet du pipeline, lis l'article dedie au pipeline vocal.

Quelles features ont demande le plus de travail ?

En 650+ commits, certaines features ont avale des semaines entieres. Voici le top 3.

Les groupes collaboratifs hierarchiques

Sur le papier : "ajoute des groupes". En realite : un systeme hierarchique a 6 niveaux de profondeur avec 4 roles (Admin, Manager, Member, Viewer), des requetes recursives PostgreSQL (CTE), et 31 politiques RLS a ecrire et tester individuellement.

Mon club de plongee a ete le cas d'usage parfait : Club → Commission Technique → Niveau 1 → Groupe du mardi. L'heritage des permissions entre niveaux a ete le vrai casse-tete. J'en parle en profondeur dans l'article sur les groupes hierarchiques.

L'agenda avec recurrence

Les LLMs ne sont pas bons avec les dates. Quand tu dis "tous les mardis a 14h", le modele doit comprendre la recurrence, la timezone, et generer les bonnes occurrences. J'ai du construire une table de correspondance et un systeme de validation robuste. Le detail technique est dans l'article sur l'agenda et les filtres.

La gamification

12 niveaux, 10 badges, des streaks jusqu'a 365 jours, des defis quotidiens, et un leaderboard. Un schema dedie avec 5 tables et des triggers automatiques. La gamification n'est pas un gadget — elle change fondamentalement l'engagement des utilisateurs. J'ai detaille l'architecture dans l'article sur le schema de gamification.

Quelles erreurs eviter quand on developpe en solo ?

Je vais etre honnete : j'ai fait des erreurs couteuses. Si tu developpes un projet solo, apprends de mes plantages.

Erreur n°1 : Zero marketing pendant 6 mois

650 commits et pas un seul post pour en parler. Aucun. J'etais tellement absorbe par le code que j'ai completement ignore la partie visibilite. Le jour ou j'ai voulu communiquer, je partais de zero — zero audience, zero contenu, zero historique.

La lecon : commence le marketing des le premier commit. Meme un simple tweet "je demarre un nouveau projet" vaut mieux que le silence.

Erreur n°2 : Sous-estimer l'internationalisation

Passer de 100% francais a 6 langues (FR, EN, DE, ES, IT, PT) a touche 35 fichiers et 1993 cles de traduction. C'est un chantier enorme quand tu le fais apres coup. Aujourd'hui, chaque nouvelle feature est traduite des le depart. 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 donnees des le depart

J'ai eu la chance de bien faire ce choix-la, mais j'ai vu tellement de projets ou tout est dans le schema public que je le mentionne. Trois schemas separes des le jour 1, ca change tout pour la maintenabilite. Le detail est dans l'article sur la restructuration de la base de donnees.

Comment gerer un projet solo de cette envergure ?

650 commits en 6 mois, ca fait une moyenne de 3-4 commits par jour. Certains jours j'en faisais 10, d'autres zero. Voici ce qui m'a aide :

• Des commits atomiques : chaque commit fait une seule chose. Ca rend le debug et le revert beaucoup plus simples.
• Un monorepo : frontend, backend et website dans le meme repo. Un seul git log pour voir l'historique complet du projet.
• Des singletons services : ConversationService, CalendarService, GamificationService... chaque domaine a son service dedie, facile a tester et a maintenir.
• Le pattern PendingCreation : la voix cree une preview, l'utilisateur valide, edite ou annule avant la sauvegarde en base. Zero surprise.

Quel est le cout de fonctionnement d'une app vocale IA ?

Question que tout le monde pose. Voici la decomposition par interaction vocale :

• STT natif (device) : gratuit. Deepgram cloud en fallback : ~$0.0059/min.
• LLM via OpenRouter : variable selon le modele, typiquement $0.001-0.01 par requete.
• TTS OpenAI : ~$0.015 pour 1000 caracteres.
• Supabase : plan gratuit genereux, puis ~$25/mois en Pro.
• Backend Railway : ~$5-10/mois selon l'usage.

Au total, une interaction vocale complete coute entre $0.01 et $0.03. C'est viable avec un modele freemium — j'ai detaille les tiers d'abonnement dans l'article sur RevenueCat et les abonnements.

Ou 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 metriques qui comptent :

• 650+ commits sur le monorepo
• 6 langues supportees (FR, EN, DE, ES, IT, PT)
• 3 modes WebSocket (Live, Realtime, Batch)
• 31 politiques RLS pour la securite des donnees
• 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 a temps plein. Le pipeline vocal seul (STT + LLM + TTS) a pris environ 3 semaines. Les groupes collaboratifs et la gamification ont ajoute 2 mois chacun. Si tu te concentres sur le MVP vocal uniquement, compte 2-3 mois.

Pourquoi React Native plutot que Flutter ou natif ?

Je connaissais deja React. La New Architecture (Fabric) de React Native 0.81 offre des performances quasi-natives. Flutter etait une option valable, mais l'ecosysteme npm et la communaute React ont fait pencher la balance. Le natif pur aurait double 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 majorite des cas, le STT natif du device est suffisant et gratuit. Deepgram excelle dans les environnements bruyants et pour les langues non-europeennes. TAMSIV utilise le natif par defaut et bascule sur Deepgram en fallback. J'ai compare les deux en detail dans l'article STT natif vs Deepgram.

Comment monetiser une app vocale IA sans exploser les couts ?

Le modele freemium avec des limites quotidiennes sur le plan gratuit. Les features couteuses (STT cloud, generation d'images IA) sont reservees aux plans Pro et Team. RevenueCat gere les abonnements in-app. Le secret, c'est d'optimiser le cout 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 cote serveur). Le STT peut tourner en local. Le WebSocket est indispensable pour le streaming temps reel — les appels HTTP classiques ajoutent trop de latence.