La voix pour penser avec l'IA : pourquoi ton clavier n'est pas le bon outil

Je pensais autrefois que la voix était une interface d'accessibilité ou une commodité. J'ai changé d'avis après avoir utilisé des outils d'IA tous les jours. Le clavier est excellent pour la précision, mais c'est un mauvais instrument pour penser avec l'IA car il force l'idée à passer par un canal trop étroit, trop tôt.

Le goulot d'étranglement du clavier

Un typiste rapide peut culminer autour de 70 mots par minute. La parole conversationnelle est souvent plus proche de 150 mots par minute, et la pensée interne peut aller plus vite que les deux. Les chiffres exacts comptent moins que la forme : le clavier te force à sérialiser ta pensée en fragments polis avant que l'idée ne soit prête.

C'est ça, le goulot d'étranglement du clavier. Ce n'est pas que taper soit lent dans l'absolu. C'est que taper te pousse à éditer pendant que tu formes la pensée. Avec l'IA, cette compression précoce supprime souvent l'ambiguïté utile : la nuance, l'alternative, la chose dont tu n'es pas sûr mais que tu veux que le modèle prenne en compte.

Je le remarque surtout quand je suis fatigué. En fin de journée, mes prompts tapés deviennent plus courts et le modèle devient d'autant moins utile. Le même soir, dicter la même intention dans le même outil produit une meilleure réponse car la version parlée transporte encore le contexte que j'aurais édité à la main. Le clavier ne me ralentit pas seulement ; il fait de moi un moins bon collaborateur avec le modèle après une certaine heure.

L'IA change la forme du prompt

Travailler avec un LLM ressemble plus à briefer un collaborateur qu'à émettre une commande. Les meilleurs prompts incluent souvent du contexte, des motifs, des contraintes, des exemples et de l'incertitude. Les prompts vocaux fonctionnent mieux avec les outils d'IA quand le problème est encore flou car tu peux parler du contexte environnant sans t'arrêter pour le rendre élégant.

C'est pour ça que la voix pour penser compte. Tu peux dire : « Je pense que le bug est dans la clé de cache, mais je ne suis pas sûr que la locale utilisateur en fasse partie, inspecte d'abord ce chemin et dis-moi si je me trompe. » Tapé, ça devient souvent « check cache bug ». Le prompt plus court perd la pensée.

La forme d'un prompt fait désormais partie du travail, pas un préambule. Traite le prompt comme l'artefact que tu produis, et la voix devient l'outil naturel de rédaction : elle préserve la structure de la façon dont tu comprends réellement le problème, y compris les parties dont tu n'es pas sûr. Un modèle qui reçoit la forme à moitié formée renvoie souvent une meilleure réponse qu'un modèle qui reçoit une commande confiante mais partielle.

Trois moments qui m'ont fait changer d'avis

Le premier était une session de débogage. J'ai tapé un court prompt à un agent en lui demandant d'inspecter une régression. Il a pris le mauvais chemin. Puis j'ai dicté la version brouillonne : ce qui avait changé, ce que je soupçonnais, ce dont je doutais et ce qui réfuterait ma théorie. L'agent a trouvé le problème plus vite car je lui avais enfin donné la forme de mon incertitude.

Le deuxième était de la rédaction. J'ai tapé un paragraphe net sur notre stack de modèles et il sonnait juste mais mort. J'ai dit la même idée en marchant, y compris la frustration qui nous a menés à l'architecture. La version dictée avait l'argument réel. Je l'ai quand même éditée, mais j'éditais à partir d'un brouillon vivant plutôt que d'un plan stérile.

Le troisième était une longue réponse client maladroite. Le client avait posé une question sans réponse simple ; la réponse honnête impliquait des compromis et une petite excuse. Tapée, ma réponse est passée par six éditions et restait raide. Dictée, la première prise était plus chaleureuse, plus directe, et n'a eu besoin que d'une correction d'un seul mot. J'ai envoyé cette version et la conversation a avancé. Je ne fais plus confiance aux réponses tapées pour les messages qui demandent du ton.

Comment j'utilise la voix maintenant

J'utilise la voix pour la pensée en premier jet, pas pour la précision finale. Je dicte le brief brouillon dans Claude Code, Cursor, Obsidian ou un simple fichier Markdown. Puis je passe au clavier pour les éditions exactes. Cette division garde chaque outil dans son couloir : la voix pour le contexte, le clavier pour la chirurgie.

• Avant de coder : je dicte le changement, le risque et le chemin de test. La version dictée fait généralement émerger un risque que j'aurais sauté en tapant.
• Avant d'écrire : je dis l'argument à voix haute avant de faire le plan. Si je ne peux pas dire l'argument en deux minutes, je ne sais pas encore ce que je pense.
• Avant les réunions : je dicte la décision dont j'ai besoin de l'appel. Entrer dans une réunion avec une décision nommée change la conversation.
• Après les échecs : je dicte ce qui m'a surpris avant que la mémoire ne s'efface. Le lendemain matin, la leçon a disparu si elle n'a pas été capturée.

Pour du contexte externe sur la vitesse de parole et les schémas de dictée, l'écrit du Nielsen Norman Group sur la reconnaissance vocale et les références sur les mots par minute sont de bons points de départ.

Les objections que j'entends sans cesse

« Je travaille dans des espaces partagés. » Juste, et c'est une vraie contrainte. Ma réponse, c'est que même dix minutes calmes par jour passées à dicter les prompts difficiles est plus utile qu'une journée entière de prompts tapés. La voix n'a pas besoin de dominer le workflow pour le changer.

« Je peux penser en tapant. » Certaines personnes le peuvent vraiment. Le test n'est pas si tu peux produire du texte en tapant ; c'est si le texte que tu produis en tapant a la même forme que la pensée que tu aurais parlée. Pour la plupart d'entre nous, moi y compris, la version tapée est systématiquement moins complète.

« Je suis décousu quand je dicte. » La première semaine est difficile. La deuxième est bien meilleure. La compétence apprise n'est pas de parler ; c'est de façonner une pensée parlée en quelque chose qu'un lecteur (ou un modèle) peut utiliser. Elle revient plus vite que prévu car tout le monde l'a déjà utilisée auparavant, juste en conversation.

Où Loqua trouve sa place

Nous avons écrit Loqua parce que je voulais la voix pour penser sans accepter le nettoyage de transcription brute. Il supprime les faux départs, garde les noms techniques et formate la sortie pour l'application dans laquelle je suis. La proposition douce, c'est : utilise Loqua quand l'idée est trop grande ou trop fragile pour passer d'abord par le clavier.

Pour la version pratique de cet argument, voir notre journée voice-first. Cet article montre quand la voix fonctionne, quand elle échoue et quand je reprends le clavier. Le sujet de cet article est le pourquoi ; celui-là est le comment.