Workflow voice-first : une journée dans notre journée voice-first

Je suis Shuran, fondateur de Loqua.ai. Voici la version honnête de notre workflow voice-first : où il fait gagner du temps, où il échoue, et ce que je fais à la place. L'objectif n'est pas de mettre en scène la productivité. L'objectif est de réduire la distance entre une pensée et l'artefact qui fait avancer le travail. À la fin d'une journée comme celle-ci, la question taper-versus-parler est largement invisible ; ce que je remarque, c'est le travail lui-même.

Boîte de réception à 8 h

Je commence par Spark Mail et Slack. La voix marche bien ici car les réponses sont surtout de l'intention et du ton. Je dicte la réponse brouillon, Loqua supprime les hésitations, et la couche consciente de l'application garde la sortie plus courte dans Slack que dans l'e-mail.

Le bloc boîte de réception prend généralement quinze à vingt minutes. Environ deux tiers des réponses sont dictées ; le reste est tapé car elles ont besoin d'une formulation exacte, d'une liste de liens ou d'une explication délicate. La répartition n'est pas une règle. C'est ce que devient la matinée une fois que j'arrête de forcer un outil à faire le boulot de l'autre.

Là où la voix échoue : fils confidentiels dans des espaces publics. Si je suis dans un café et que le message contient un contexte sensible, je tape. Voice first ne veut pas dire confidentialité en second.

Standup

Pour le standup, je parle dans trois cases : livré, aujourd'hui, bloqueur. C'est l'un des patterns de workflow de dictée vocale quotidien à plus fort rendement, car la structure se répète et le contenu change.

L'astuce, c'est de ne pas divaguer. Je dis les noms des cases à voix haute. Loqua les utilise comme structure. Le standup lui-même prend peut-être trente secondes à écrire et une minute de plus pour lire ce que le reste de l'équipe a posté. La voix ne fait pas gagner beaucoup de temps sur chaque standup individuel ; elle économise le coût de le repousser, ce qui était la plus grande traînée sur la journée.

Revue de code

La revue de code est mixte. La voix est excellente pour expliquer la préoccupation ; le clavier est meilleur pour la précision au niveau de la ligne. Je dicte les résumés de revue et les commentaires de haut niveau, puis j'utilise la souris et le clavier pour la navigation exacte dans les fichiers.

Un bon commentaire de revue vocal dit pourquoi le problème compte, pas seulement quelle ligne est fausse. Par exemple : « Cette clé de cache ignore la locale, donc les résultats chinois et anglais peuvent entrer en collision. Pouvons-nous inclure la locale dans la clé et ajouter un test de régression ? » Ce commentaire est bien plus facile à dire qu'à taper en lisant du code.

Brouillon de spec

La rédaction de specs est là où le workflow voice-first se rapproche le plus de la pensée. Je dicte l'objectif, les non-objectifs, le flux utilisateur, les cas limites et les critères d'acceptation. Puis j'édite les titres au clavier. Pour une spec plus grande, je démarre dans Obsidian ; pour les tâches d'implémentation, je déplace la version nettoyée dans Claude Code ou Cursor.

Le premier brouillon dicté est rarement la spec qu'on livre. C'est l'échafaudage qui rend évidente l'édition au clavier. L'astuce que je redécouvre sans cesse, c'est que la version dictée fait remonter les sections manquantes plus vite qu'un plan tapé, car dire « acceptance » à voix haute me force à le faire suivre d'au moins un critère.

Fils Slack

Slack est l'endroit où le ton compte. La voix peut sonner trop brusque si le modèle de nettoyage ne fait que transcrire. Le formatage par destination de Loqua garde les réponses courtes mais pas froides. Je relis quand même avant d'envoyer ; la voix devrait accélérer le jugement, pas le remplacer.

Un pattern qui a mis du temps à apprendre : dicte la version chaleureuse, pas la version efficace. Slack se lit mieux quand la première phrase reconnaît la personne et la deuxième phrase va au but. Une réponse tapée tend à sauter la première phrase. Une dictée la garde généralement, et le fil est plus sain pour ça.

Là où la voix échoue : quand un fil nécessite des citations soigneuses ou plusieurs liens. Je tape ceux-là. La règle hybride est simple : utiliser la voix pour l'argument, le clavier pour les références.

Journal de fin de journée

À la fin de la journée, je dicte ce qui m'a surpris. Ce n'est pas une mise à jour de statut. C'est une capture mémoire : ce qui m'a fait changer d'avis, ce qui a été plus dur que prévu, et ce que je ne dois pas oublier demain. Obsidian est la destination car il est cherchable et liable.

Une entrée de journal typique fait trois courts paragraphes et prend environ cinq minutes. Le pattern intéressant, c'est que les entrées les plus précieuses concernent les petites surprises, pas les grandes décisions. Les grandes décisions sont écrites de toute façon, souvent plus d'une fois. La petite surprise — l'API qui a renvoyé une forme différente de ce que les docs laissaient entendre, le commentaire utilisateur qui contredisait mon modèle — c'est celle qui disparaît au matin si elle n'est pas capturée.

Quand la voix n'a pas fonctionné aujourd'hui

Deux exemples de la même journée. Premièrement, un refactor de code dense dans un fichier chargé. J'ai essayé de dicter le plan de renommage dans l'éditeur et le modèle se trompait sur un identifiant car le contexte visible défilait plus vite que le listener ne pouvait suivre. J'ai basculé vers la frappe. La voix était le mauvais outil car le curseur bougeait trop vite pour que le contexte se stabilise.

Deuxièmement, un fil Slack tendu où la bonne réponse était trois phrases et zéro adjectif. J'ai dicté, le nettoyage a ajouté une atténuation polie, et le message s'est retrouvé à se lire plus doux que je le voulais. Je l'ai réécrit à la main. La leçon, c'est que la voix est bonne pour la chaleur et mauvaise pour la froideur délibérée ; quand tu as besoin d'un message plat, tape-le.

Pour plus de détails sur le stack, voir notre voice productivity stack. Pour l'argument derrière l'habitude, voir pourquoi ton clavier n'est pas le bon outil pour penser avec l'IA. Les références externes qui ont façonné notre workflow Mac incluent Apple Dictation et les docs Linear.