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

Points clés à retenir : Le Dictaphone de TAMSIV repose sur trois décisions de design : push-to-talk (pas d'écoute continue) pour la batterie et la vie privée, le pattern PendingCreation (preview avant sauvegarde) pour garder l'utilisateur en contrôle, 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 : créer une tâche en parlant, plus vite qu'en tapant. Pas un gadget vocal greffé sur une app de todo classique. La voix est l'interface principale — le clavier est le fallback. Toute l'UX du Dictaphone découle de cette promesse.

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

Pourquoi choisir le push-to-talk plutôt que l'écoute continue ?

C'est la première décision de design, et la plus importante. J'avais deux options : l'écoute 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'écoute continue maintient le microphone actif en permanence. Sur un smartphone, c'est un gouffre énergétique. Le STT (Speech-to-Text) en continu consomme 10 à 15% de batterie par heure, selon les benchmarks Android. Inacceptable pour une app de productivité qui doit rester ouverte en arrière-plan.
• La vie privée : un micro toujours ouvert, ça fait peur. Les utilisateurs n'ont pas confiance — et ils ont raison. Le push-to-talk est explicite. Tu appuies, tu parles, tu relâches. Pas d'ambiguïté sur ce qui est enregistré.
• Le bruit ambiant : dans un café, dans la rue, dans les transports — l'écoute continue capte tout. Le Voice Activity Detection (VAD) n'est pas parfait. Le push-to-talk élimine le problème : l'app n'écoute que quand l'utilisateur le décide.

Le VAD de Deepgram gère automatiquement la fin de phrase en mode cloud. En mode natif, c'est le STT du device qui détecte le silence. Dans les deux cas, l'utilisateur n'a pas besoin de chronométrer son relâchement — le système sait quand la phrase est terminée.

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 travaillé sur une app vocale.

Le problème : la reconnaissance vocale n'est pas parfaite. L'IA peut mal interpréter. "Acheter du pain" pourrait devenir "A cheter du pin". Si on sauvegarde directement en base, l'utilisateur se retrouve avec des données corrompues sans s'en rendre compte.

La solution : le PendingCreation.

1. L'utilisateur dicte : "Ajoute une tâche pour demain : rappeler le dentiste, priorité haute"
2. Le STT transcrit l'audio en texte
3. Le texte est envoyé au LLM via WebSocket
4. Le LLM analyse et appelle la function create_task avec les paramètres extraits (titre, date, priorité)
5. Le backend renvoie un function_result avec une preview
6. L'utilisateur voit la proposition à l'écran : titre, date, priorité
7. Il peut modifier, valider ou annuler
8. Seulement après validation, la tâche est sauvegardée en base (Supabase)

Le principe : la voix accélère la saisie, mais l'humain décide. Rien n'est sauvegardé sans validation explicite. Ça semble ajouter une étape, mais en pratique, la validation prend une demi-seconde (un tap) et donne un sentiment de contrôle que les utilisateurs apprécient énormément.

Ce pattern est particulièrement important pour les événements agenda, où une erreur de date peut avoir des conséquences réelles (rater un rendez-vous).

Quelle est la différence entre STT natif et STT cloud ?

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

Mode natif (par défaut)

• Gratuit : utilise le moteur STT intégré au device (Google Speech-to-Text sur Android, Apple Speech sur iOS)
• Local : aucune donnée audio n'est envoyée à un serveur externe (avec les modèles offline)
• Variable en qualité : dépend du device, de la langue, et du modèle téléchargé
• Utilisé pour : le plan Free

Mode cloud (Deepgram)

• Payant : facturation au nombre de secondes d'audio traitées
• Consistant : qualité uniforme quel que soit le device
• Précis : meilleure gestion des accents, du bruit ambiant, et du vocabulaire technique
• Utilisé pour : les plans Pro et Team

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

En coulisses, le switch entre les deux modes est transparent. Le comparatif STT natif vs Deepgram détaille les différences 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 tâches. Pas les mémos. Pas l'agenda. Le micro.

C'est un choix délibéré. Dans la plupart des apps de productivité, la voix est une feature secondaire — un petit bouton micro caché dans un coin. Dans TAMSIV, c'est le contraire : la voix est LE produit. L'écran tactile est le complément.

L'ordre des onglets (personnalisable par l'utilisateur, sauvegardé en base) suit cette hiérarchie par défaut :

1. Dictaphone — l'action principale (créer par la voix)
2. Feed — voir son activité récente
3. Agenda — organiser son temps
4. Groups — collaborer
5. Social — découvrir
6. Profile — paramètres

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

Comment le feedback haptique améliore-t-il l'expérience vocale ?

Le retour haptique est un détail subtil mais crucial. À chaque changement d'état du Dictaphone, le téléphone vibre légèrement :

• Début d'enregistrement : vibration courte (50ms) — "je t'écoute"
• Fin d'enregistrement : vibration double — "j'ai compris, je traite"
• Preview reçue : vibration longue (100ms) — "voilà ma proposition"
• Validation réussie : vibration de confirmation — "c'est sauvegardé"

L'utilisateur sent physiquement quand l'app écoute, quand elle traite, et quand c'est fait. C'est particulièrement important quand on dicte sans regarder l'écran — 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 réel.

Comment l'IA interprète-t-elle la dictée ?

Le texte transcrit par le STT est envoyé au LLM (via OpenRouter) avec un system prompt spécifique. L'IA a accès à 7 function tools :

• create_task — créer une tâche avec titre, date, priorité, récurrence
• update_task — modifier une tâche existante
• create_memo — créer un mémo vocal structuré
• update_memo — modifier un mémo
• create_calendar_event — créer un événement agenda
• ask_clarification — demander une précision si la requête est ambiguë
• 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 configuré pour le lendemain 9h. "Note pour plus tard : idée de feature pour le feed" devient un create_memo avec le tag "idée".

L'historique de conversation permet d'enchaîner : "Ajoute une tâche" → "En fait, mets-la pour vendredi" → "Et ajoute un mémo dessus". L'IA comprend le fil.

Quelles sont les limites du voice-first ?

Être honnête sur les limites est essentiel. Le voice-first ne convient pas à tout :

• Environnements bruyants : même avec un bon STT, dicter dans un bar est pénible. Le clavier reste disponible en fallback.
• Contenu complexe : dicter un mémo de 3 paragraphes avec des puces et du formatage, c'est fastidieux. L'éditeur rich text prend le relais.
• Vie privée en public : dicter "Rendez-vous oncologue mercredi" dans le métro, personne n'a envie de ça.
• Précision des dates : "La semaine prochaine" est ambigu. Le pattern PendingCreation permet de corriger, mais le clavier reste plus précis pour les dates complexes.

TAMSIV n'oblige personne à utiliser la voix. Chaque écran 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 perçue est le facteur numéro un de l'expérience 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 → Réponse → TTS → Audio

Chaque étape a sa propre latence :

• STT natif : ~200-500ms (local, rapide)
• STT Deepgram : ~300-800ms (réseau, plus précis)
• LLM via OpenRouter : ~1-3 secondes (le goulot d'étranglement)
• TTS OpenAI : ~500ms-1s (streaming audio)

Total : 2 à 5 secondes du moment où l'utilisateur finit de parler au moment où il entend la réponse. C'est acceptable pour une interaction conversationnelle (comparable à un humain qui réfléchit), mais ça nécessite un feedback visuel continu — le bouton animé Nebula affiche une animation pendant que l'IA traite.

Comment construire une expérience voice-first dans ton app ?

Si tu veux intégrer la voix comme interface principale dans ton application, voici les leçons tirées de TAMSIV :

1. Push-to-talk, pas écoute continue : économie de batterie, respect de la vie privée, fiabilité.
2. Preview avant sauvegarde : le pattern PendingCreation est non-négociable. L'utilisateur doit toujours pouvoir corriger.
3. Feedback multimodal : visuel + haptique + sonore. L'utilisateur doit savoir à chaque instant ce que fait l'app.
4. Fallback clavier : la voix ne remplace pas le clavier — elle le complète. Offre toujours une alternative manuelle.
5. Segmente le STT : natif pour le gratuit, cloud pour le premium. C'est un levier de monétisation naturel.

Le parcours de 650+ commits de TAMSIV montre qu'une expérience vocale solide demande des dizaines d'itérations. Le premier prototype fonctionnait — mais la version actuelle est 10x plus fluide grâce aux feedbacks utilisateurs et à l'intégration IA continue.

FAQ

Le Dictaphone fonctionne-t-il hors connexion ?

Partiellement. Le STT natif fonctionne offline (si le modèle de langue est téléchargé sur le device). Mais le LLM et le TTS nécessitent une connexion internet. En mode offline, l'utilisateur peut dicter du texte brut, mais l'IA ne peut pas interpréter ni structurer la tâche.

Quelles langues sont supportées par le Dictaphone ?

Le STT natif supporte toutes les langues installées sur le device (généralement 50+). Le STT Deepgram supporte les principales langues européennes. L'IA comprend les 6 langues de TAMSIV (FR, EN, DE, ES, IT, PT) grâce à l'internationalisation complète.

Comment le Dictaphone gère-t-il les accents et les dialectes ?

Le STT natif dépend du modèle de langue du device — les accents régionaux sont généralement bien gérés pour les langues principales. Deepgram excelle sur les accents grâce à des modèles entraînés sur des corpus diversifiés. L'IA (LLM) comprend les formulations régionales sans problème.

Peut-on dicter des tâches en conduisant ?

Oui, c'est un cas d'usage conçu. Le push-to-talk nécessite un geste initial, mais le feedback haptique et la réponse TTS permettent de dicter et confirmer sans regarder l'écran. 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 dictée (quelques secondes). La connexion WebSocket est légère et persistante. La consommation principale vient du LLM et du TTS, qui sont des appels réseau ponctuels. En utilisation normale (5-10 dictées par jour), l'impact sur la batterie est négligeable.