Pourquoi j'ai créé un gestionnaire de tâches vocal avec IA

TAMSIV est né d'une frustration banale : des listes de courses sur papier collées au frigo, un club de plongée qui gère tout sur WhatsApp, et cette sensation permanente que l'information se perd entre les post-it et les groupes de discussion. Un jour, je me suis dit : pourquoi on ne pourrait pas simplement parler pour organiser sa vie ? Six mois et 700+ commits plus tard, TAMSIV est une app Android complète avec IA conversationnelle, pipeline vocal temps réel et gestion collaborative. Voici comment tout a commencé.

Points clés à retenir :
- Les meilleures idées de produit naissent de frustrations personnelles répétées — pas d'études de marché abstraites.
- React Native avec la New Architecture (Fabric) permet à un dev web solo de livrer une app mobile performante sans natif pur.
- Supabase offre tout ce dont un projet solo a besoin (auth, DB, storage, Realtime) dans un seul service.
- Le premier prototype fonctionnel (voix vers tâche créée) est le meilleur validateur d'idée — mieux que n'importe quel business plan.

D'où vient l'idée d'un gestionnaire de tâches vocal ?

Tout a commencé par une frustration banale. Mon épouse et moi, on gère une famille de quatre personnes. Les listes de courses ? Sur un bout de papier collé au frigo. Les tâches ménagères ? Dans nos têtes. Et quand on oublie quelque chose — ce qui arrive souvent — c'est la petite tension du quotidien. "Tu n'avais pas dit que tu t'en occupais ?" Si, mais je l'ai oublié. Comme à chaque fois.

En parallèle, je suis membre d'un club de plongée. Et là, c'est le chaos organisé : tout passe par WhatsApp. Les sorties, les inscriptions, le matériel, les comptes-rendus. Des dizaines de messages par jour dans un groupe où l'info se noie. Tu cherches la date de la prochaine sortie ? Bonne chance pour la retrouver entre les mèmes et les photos de poissons.

Deux contextes différents, le même problème : l'information se perd parce que les outils qu'on utilise ne sont pas faits pour ça. Le papier ne rappelle pas. WhatsApp n'organise pas. Et les apps de gestion de tâches existantes ? Trop compliquées, trop de champs à remplir, trop de friction.

Pourquoi la voix est-elle la réponse à la surcharge mentale ?

L'insight qui a tout déclenché : on pense et on communique par la parole, pas par des formulaires. Quand tu dis à ton conjoint "n'oublie pas d'acheter du lait demain", c'est une instruction claire. Mais quand tu ouvres une app de tâches, tu dois :

1. Ouvrir l'app
2. Appuyer sur "+"
3. Taper le titre
4. Sélectionner une date
5. Choisir un projet/tag
6. Sauvegarder

Six étapes pour une action qui prend 3 secondes à dire. C'est exactement le problème que décrit le concept de capture friction dans la méthodologie GTD (Getting Things Done) de David Allen : plus la capture d'une idée est facile, plus le système est utilisé.

Je me suis dit : pourquoi on ne pourrait pas simplement dire ce qu'on veut faire ? "Ajoute du lait à la liste de courses." "Rappelle-moi de préparer les bouteilles pour samedi." Sans ouvrir une app, sans taper, sans chercher le bon champ dans un formulaire.

C'est comme ça que TAMSIV est né. Un gestionnaire de tâches et mémos piloté par la voix, avec une IA conversationnelle qui comprend ce que tu veux et agit en conséquence.

Quels choix techniques pour un dev solo qui lance un projet mobile ?

Premier commit en octobre 2025. Chaque choix technique à ce stade est critique — tu es seul, tu n'as pas de marge d'erreur, et revenir en arrière coûte cher.

Pourquoi React Native et pas du natif pur ?

Je suis développeur web de formation. Le natif pur (Kotlin/Swift) m'aurait ralenti de plusieurs mois pour un résultat équivalent. React Native avec la New Architecture (Fabric) offre des performances au rendez-vous — le jank et les problèmes de bridge qui plagaient les versions antérieures sont résolus.

Le choix du monorepo avec trois dossiers était une évidence :

• frontend/ — React Native TypeScript pour l'app mobile
• backend/ — Node.js Express avec WebSocket pour le serveur IA
• website/ — Next.js pour la landing page et le dashboard web

Un seul repo, un seul git log, des types TypeScript partagés entre frontend et backend. La cohérence est maximale.

Pourquoi Supabase plutôt que Firebase ou un backend custom ?

Supabase offre tout ce dont un projet solo a besoin dans un seul service : PostgreSQL managé, authentification intégrée (email, magic links, et plus tard QR code), stockage de fichiers, et Realtime pour la synchronisation temps réel.

Firebase aurait été l'autre option évidente, mais le modèle NoSQL (Firestore) ne convient pas à des données relationnelles comme les tâches, mémos, groupes et événements. PostgreSQL est fait pour ça — et Supabase le rend accessible sans gérer un serveur.

La structuration de la base de données viendrait plus tard, mais le choix de Supabase dès le début a permis d'itérer vite sans se soucier de l'infrastructure.

Comment fonctionne le pipeline vocal au cœur de TAMSIV ?

Le cœur du projet, c'est le pipeline vocal. Dès le premier prototype, j'ai câblé la chaîne complète :

1. Audio PCM 16kHz — capture depuis le micro du téléphone
2. WebSocket temps réel — envoi du flux audio au backend
3. STT (Speech-to-Text) — transcription par le moteur natif du device (avec fallback Deepgram)
4. LLM (Large Language Model) — analyse du texte et décision d'action via OpenRouter
5. Function calling — le LLM appelle une fonction (create_task, create_memo, etc.)
6. TTS (Text-to-Speech) — réponse vocale via OpenAI TTS

L'utilisateur parle, le backend transcrit, envoie le texte à un LLM qui décide quoi faire, et renvoie une réponse vocale. Tout ça en quelques secondes.

Les premiers tests étaient magiques. Dire "crée une tâche acheter du pain pour demain" et voir la tâche apparaître avec la bonne date... c'est le genre de moment qui te confirme que tu es sur la bonne voie. Pas besoin d'un business plan de 50 pages — quand le prototype marche et que tu te dis "je veux utiliser ça tous les jours", l'idée est validée.

Quels sont les défis d'un développeur solo sur un projet aussi ambitieux ?

Être développeur solo, c'est une liberté totale sur les choix techniques. Pas de réunion, pas de compromis, pas de "on en discute lundi". Tu vois un problème, tu le corriges. Tu as une idée, tu la codes.

Mais c'est aussi la solitude face aux bugs à 23h. Personne pour relire ton code, personne pour challenger tes choix, personne pour te dire "tu es sur la bonne voie" quand tu doutes. C'est un sentiment que connaissent beaucoup de fondateurs techniques solos.

Le build in public — raconter l'aventure via ce blog et les réseaux — est devenu ma façon de compenser cette solitude. Chaque article est un checkpoint, une preuve que le projet avance, un moyen de recevoir du feedback même sans équipe.

Comment est-on passé du premier commit à 700+ commits en 6 mois ?

Le parcours depuis ce premier commit a suivi une trajectoire que je n'aurais pas pu planifier :

• Octobre-Novembre 2025 : fondations — clean architecture, pipeline vocal, éditeur rich text
• Décembre 2025 : gamification, renommage en TAMSIV, notifications récurrentes
• Janvier 2026 : UX polish, feed et gamification UI
• Février 2026 : abonnements RevenueCat, internationalisation 6 langues, optimisation performance
• Mars 2026 : système de parrainage, personnalisation vocale, lancement public

L'article détaillé sur les 650+ commits retrace chaque étape en profondeur.

Quelles leçons retenir pour lancer un projet solo ?

1. Pars de ta propre frustration. Les meilleurs produits résolvent un problème que le créateur vit au quotidien. Tu seras ton premier utilisateur et ton meilleur testeur.
2. Choisis des outils qui multiplient ta productivité. React Native, Supabase, OpenRouter — chaque choix doit te faire gagner des semaines, pas des heures.
3. Prototype vite, valide vite. Le premier pipeline vocal fonctionnel m'a pris 3 jours. Ce prototype a validé l'idée mieux que n'importe quelle étude.
4. Documente l'aventure. Le build in public n'est pas du marketing — c'est un journal de bord qui te force à prendre du recul et qui crée une communauté autour du projet.

Questions fréquentes

Faut-il savoir coder en natif pour créer une app mobile avec IA ?

Non. React Native avec TypeScript permet à un développeur web de créer une app mobile performante. Pour l'IA, des services comme OpenRouter et OpenAI fournissent des API qui ne nécessitent pas de compétences en machine learning. Le plus important est de comprendre l'architecture client-serveur et les WebSockets.

Combien coûte le développement d'une app comme TAMSIV en dev solo ?

En coûts directs : Supabase (plan gratuit au début, puis ~25 EUR/mois), OpenRouter (~0.001 EUR/message LLM), OpenAI TTS (~0.015 EUR/1000 caractères), Runware pour les images (~0.003 EUR/image). Le coût principal est le temps : 6 mois à temps partiel, soit environ 500-600 heures de travail.

Pourquoi un monorepo plutôt que des repos séparés ?

Pour un dev solo, la cohérence prime. Un seul repo signifie un seul historique git, des types TypeScript partagés, et pas de synchronisation de versions entre packages. Le monorepo devient plus complexe à gérer à partir de 3-4 développeurs, mais pour un projet solo, c'est idéal.

Le pipeline vocal fonctionne-t-il hors connexion ?

Partiellement. Le STT natif du device fonctionne sans internet (reconnaissance vocale locale). Mais le LLM et le TTS nécessitent une connexion au backend. Un mode offline avec mise en file d'attente est sur la roadmap — les commandes vocales seraient stockées localement et traitées à la reconnexion.

WhatsApp n'est-il pas suffisant pour gérer des tâches en groupe ?

Non, et c'est exactement le problème qui a inspiré TAMSIV. WhatsApp est un outil de communication, pas d'organisation. Les informations se noient dans le flux de messages, rien n'est structurel, il n'y a pas de rappels, pas de dates d'échéance, pas d'assignation. C'est le chaos organisé — et les groupes collaboratifs de TAMSIV résolvent précisément ce problème.