Dictaphone voice-first : push-to-talk et PendingCreation

Points cles a retenir : Le Dictaphone de TAMSIV repose sur trois decisions de design : push-to-talk (pas d'ecoute continue) pour la batterie et la vie privee, le pattern PendingCreation (preview avant sauvegarde) pour garder l'utilisateur en controle, et deux modes STT (natif gratuit vs cloud Deepgram) pour s'adapter au plan tarifaire. La voix n'est pas une feature — c'est le produit.

La promesse de TAMSIV tient en une phrase : creer une tache en parlant, plus vite qu'en tapant. Pas un gadget vocal greffe sur une app de todo classique. La voix est l'interface principale — le clavier est le fallback. Toute l'UX du Dictaphone decoule de cette promesse.

Voici les decisions de design, les compromis techniques et les patterns qui font fonctionner le Dictaphone de TAMSIV au quotidien.

Pourquoi choisir le push-to-talk plutot que l'ecoute continue ?

C'est la premiere decision de design, et la plus importante. J'avais deux options : l'ecoute continue (comme Alexa ou Google Home) ou le push-to-talk (appuyer pour parler).

J'ai choisi le push-to-talk pour trois raisons :

• La batterie : l'ecoute continue maintient le microphone actif en permanence. Sur un smartphone, c'est un gouffre energetique. Le STT (Speech-to-Text) en continu consomme 10 a 15% de batterie par heure, selon les benchmarks Android. Inacceptable pour une app de productivite qui doit rester ouverte en arriere-plan.
• La vie privee : un micro toujours ouvert, ca fait peur. Les utilisateurs n'ont pas confiance — et ils ont raison. Le push-to-talk est explicite. Tu appuies, tu parles, tu relaches. Pas d'ambiguite sur ce qui est enregistre.
• Le bruit ambiant : dans un cafe, dans la rue, dans les transports — l'ecoute continue capte tout. Le Voice Activity Detection (VAD) n'est pas parfait. Le push-to-talk elimine le probleme : l'app n'ecoute que quand l'utilisateur le decide.

Le VAD de Deepgram gere automatiquement la fin de phrase en mode cloud. En mode natif, c'est le STT du device qui detecte le silence. Dans les deux cas, l'utilisateur n'a pas besoin de chronometrer son relachement — le systeme sait quand la phrase est terminee.

Comment fonctionne le pattern PendingCreation ?

C'est le pattern le plus important de TAMSIV. Et probablement le moins intuitif pour quelqu'un qui n'a pas travaille sur une app vocale.

Le probleme : la reconnaissance vocale n'est pas parfaite. L'IA peut mal interpreter. "Acheter du pain" pourrait devenir "A cheter du pin". Si on sauvegarde directement en base, l'utilisateur se retrouve avec des donnees corrompues sans s'en rendre compte.

La solution : le PendingCreation.

1. L'utilisateur dicte : "Ajoute une tache pour demain : rappeler le dentiste, priorite haute"
2. Le STT transcrit l'audio en texte
3. Le texte est envoye au LLM via WebSocket
4. Le LLM analyse et appelle la function create_task avec les parametres extraits (titre, date, priorite)
5. Le backend renvoie un function_result avec une preview
6. L'utilisateur voit la proposition a l'ecran : titre, date, priorite
7. Il peut modifier, valider ou annuler
8. Seulement apres validation, la tache est sauvegardee en base (Supabase)

Le principe : la voix accelere la saisie, mais l'humain decide. Rien n'est sauvegarde sans validation explicite. Ca semble ajouter une etape, mais en pratique, la validation prend une demi-seconde (un tap) et donne un sentiment de controle que les utilisateurs apprecient enormement.

Ce pattern est particulierement important pour les evenements agenda, ou une erreur de date peut avoir des consequences reelles (rater un rendez-vous).

Quelle est la difference entre STT natif et STT cloud ?

TAMSIV offre deux modes de reconnaissance vocale, configurables par l'administrateur :

Mode natif (par defaut)

• Gratuit : utilise le moteur STT integre au device (Google Speech-to-Text sur Android, Apple Speech sur iOS)
• Local : aucune donnee audio n'est envoyee a un serveur externe (avec les modeles offline)
• Variable en qualite : depend du device, de la langue, et du modele telecharge
• Utilise pour : le plan Free

Mode cloud (Deepgram)

• Payant : facturation au nombre de secondes d'audio traitees
• Consistant : qualite uniforme quel que soit le device
• Precis : meilleure gestion des accents, du bruit ambiant, et du vocabulaire technique
• Utilise pour : les plans Pro et Team

Le choix entre natif et cloud est une decision de segmentation produit, pas juste une decision technique. Le plan Free offre une experience vocale fonctionnelle. Le plan Pro offre une experience vocale fiable. C'est un argument de vente clair pour l'upgrade, detaille dans les plans d'abonnement RevenueCat.

En coulisses, le switch entre les deux modes est transparent. Le comparatif STT natif vs Deepgram detaille les differences techniques en profondeur.

Pourquoi le Dictaphone est-il le premier onglet de l'app ?

Dans la navigation de TAMSIV, le Dictaphone est le premier onglet. Pas les taches. Pas les memos. Pas l'agenda. Le micro.

C'est un choix delibere. Dans la plupart des apps de productivite, la voix est une feature secondaire — un petit bouton micro cache dans un coin. Dans TAMSIV, c'est le contraire : la voix est LE produit. L'ecran tactile est le complement.

L'ordre des onglets (personnalisable par l'utilisateur, sauvegarde en base) suit cette hierarchie par defaut :

1. Dictaphone — l'action principale (creer par la voix)
2. Feed — voir son activite recente
3. Agenda — organiser son temps
4. Groups — collaborer
5. Social — decouvrir
6. Profile — parametres

Si tu ouvres TAMSIV, tu tombes sur le micro. Un seul geste pour commencer a dicter. C'est la philosophie "voice-first" poussee a son maximum.

Comment le feedback haptique ameliore-t-il l'experience vocale ?

Le retour haptique est un detail subtil mais crucial. A chaque changement d'etat du Dictaphone, le telephone vibre legerement :

• Debut d'enregistrement : vibration courte (50ms) — "je t'ecoute"
• Fin d'enregistrement : vibration double — "j'ai compris, je traite"
• Preview recue : vibration longue (100ms) — "voila ma proposition"
• Validation reussie : vibration de confirmation — "c'est sauvegarde"

L'utilisateur sent physiquement quand l'app ecoute, quand elle traite, et quand c'est fait. C'est particulierement important quand on dicte sans regarder l'ecran — en conduisant, en cuisinant, en marchant.

Ce principe de feedback multimodal (visuel + haptique + sonore optionnel) est une recommandation classique du Nielsen Norman Group pour les interfaces temps reel.

Comment l'IA interprete-t-elle la dictee ?

Le texte transcrit par le STT est envoye au LLM (via OpenRouter) avec un system prompt specifique. L'IA a acces a 7 function tools :

• create_task — creer une tache avec titre, date, priorite, recurrence
• update_task — modifier une tache existante
• create_memo — creer un memo vocal structure
• update_memo — modifier un memo
• create_calendar_event — creer un evenement agenda
• ask_clarification — demander une precision si la requete est ambigue
• end_conversation — terminer proprement la conversation

L'IA ne se contente pas de transcrire — elle comprend l'intention. "Rappelle-moi d'acheter du pain demain matin" devient un create_task avec un rappel configure pour le lendemain 9h. "Note pour plus tard : idee de feature pour le feed" devient un create_memo avec le tag "idee".

L'historique de conversation permet d'enchainer : "Ajoute une tache" → "En fait, mets-la pour vendredi" → "Et ajoute un memo dessus". L'IA comprend le fil.

Quelles sont les limites du voice-first ?

Etre honnete sur les limites est essentiel. Le voice-first ne convient pas a tout :

• Environnements bruyants : meme avec un bon STT, dicter dans un bar est penible. Le clavier reste disponible en fallback.
• Contenu complexe : dicter un memo de 3 paragraphes avec des puces et du formatage, c'est fastidieux. L'editeur rich text prend le relais.
• Vie privee en public : dicter "Rendez-vous oncologue mercredi" dans le metro, personne n'a envie de ca.
• Precision des dates : "La semaine prochaine" est ambigu. Le pattern PendingCreation permet de corriger, mais le clavier reste plus precis pour les dates complexes.

TAMSIV n'oblige personne a utiliser la voix. Chaque ecran a un formulaire classique en alternative. La voix est plus rapide dans 80% des cas — les 20% restants ont le clavier.

Comment optimiser la latence du pipeline vocal ?

La latence percue est le facteur numero un de l'experience vocale. Si l'utilisateur parle et attend 5 secondes avant de voir la preview, il retourne au clavier. Le pipeline complet :

Audio → STT → Texte → WebSocket → LLM → Function calling → Reponse → TTS → Audio

Chaque etape a sa propre latence :

• STT natif : ~200-500ms (local, rapide)
• STT Deepgram : ~300-800ms (reseau, plus precis)
• LLM via OpenRouter : ~1-3 secondes (le goulot d'etranglement)
• TTS OpenAI : ~500ms-1s (streaming audio)

Total : 2 a 5 secondes du moment ou l'utilisateur finit de parler au moment ou il entend la reponse. C'est acceptable pour une interaction conversationnelle (comparable a un humain qui reflechit), mais ca necessite un feedback visuel continu — le bouton anime Nebula affiche une animation pendant que l'IA traite.

Comment construire une experience voice-first dans ton app ?

Si tu veux integrer la voix comme interface principale dans ton application, voici les lecons tirees de TAMSIV :

1. Push-to-talk, pas ecoute continue : economie de batterie, respect de la vie privee, fiabilite.
2. Preview avant sauvegarde : le pattern PendingCreation est non-negociable. L'utilisateur doit toujours pouvoir corriger.
3. Feedback multimodal : visuel + haptique + sonore. L'utilisateur doit savoir a chaque instant ce que fait l'app.
4. Fallback clavier : la voix ne remplace pas le clavier — elle le complete. Offre toujours une alternative manuelle.
5. Segmente le STT : natif pour le gratuit, cloud pour le premium. C'est un levier de monetisation naturel.

Le parcours de 650+ commits de TAMSIV montre qu'une experience vocale solide demande des dizaines d'iterations. Le premier prototype fonctionnait — mais la version actuelle est 10x plus fluide grace aux feedbacks utilisateurs et a l'integration IA continue.

FAQ

Le Dictaphone fonctionne-t-il hors connexion ?

Partiellement. Le STT natif fonctionne offline (si le modele de langue est telecharge sur le device). Mais le LLM et le TTS necessitent une connexion internet. En mode offline, l'utilisateur peut dicter du texte brut, mais l'IA ne peut pas interpreter ni structurer la tache.

Quelles langues sont supportees par le Dictaphone ?

Le STT natif supporte toutes les langues installees sur le device (generalement 50+). Le STT Deepgram supporte les principales langues europeennes. L'IA comprend les 6 langues de TAMSIV (FR, EN, DE, ES, IT, PT) grace a l'internationalisation complete.

Comment le Dictaphone gere-t-il les accents et les dialectes ?

Le STT natif depend du modele de langue du device — les accents regionaux sont generalement bien geres pour les langues principales. Deepgram excelle sur les accents grace a des modeles entraines sur des corpus diversifies. L'IA (LLM) comprend les formulations regionales sans probleme.

Peut-on dicter des taches en conduisant ?

Oui, c'est un cas d'usage concu. Le push-to-talk necessite un geste initial, mais le feedback haptique et la reponse TTS permettent de dicter et confirmer sans regarder l'ecran. Attention : la validation finale (tap sur "Confirmer") requiert un regard — une future version pourrait ajouter la confirmation vocale.

Le Dictaphone consomme-t-il beaucoup de batterie ?

Non. Le push-to-talk n'active le microphone que pendant la dictee (quelques secondes). La connexion WebSocket est legere et persistante. La consommation principale vient du LLM et du TTS, qui sont des appels reseau ponctuels. En utilisation normale (5-10 dictees par jour), l'impact sur la batterie est negligeable.