J'ai compris ça à mes dépens en construisant MachinesFluent et en m'en servant tous les jours : dès qu'un logiciel de dictée laisse planer le doute pendant quelques secondes, la confiance commence à s'effriter.
Pas la précision. La confiance.
On aime bien parler de word error rate, de latence, de qualité de modèle. Très bien. Tout ça compte. Mais il y a un autre problème, plus discret et souvent bien plus pénible en usage réel. Si l'utilisateur ne sait plus très bien si le système écoute, s'il écoute encore, s'il a fini, s'il traite la demande ou s'il s'est juste figé quelque part, toute l'expérience devient rapidement suspecte.
Et à ce moment-là, les gens reviennent au clavier.
En vocal, la moindre ambiguïté coûte cher
Avec un clavier, l'état du système se voit. Le curseur est là. Le champ est là. Les lettres apparaissent. La chaîne cause-effet reste lisible. Avec la voix, c'est différent : une bonne partie de l'état utile reste invisible. Résultat, l'utilisateur se pose en permanence les mêmes questions, sans forcément les formuler.
Est-ce que ça a commencé à écouter ? Est-ce que le premier mot est bien passé ? Est-ce que ça enregistre encore ? Est-ce que je peux m'arrêter ? Est-ce que c'est en train de traiter ou est-ce que ça a planté ?
Si le logiciel répond clairement à ces questions, l'outil paraît sérieux. Sinon, l'utilisateur se tend. Il articule trop. Il hésite. Il se répète. Il ne parle plus naturellement ; il parle comme quelqu'un qui essaie de ne pas faire buguer une borne.
C'est là que la dictée vocale commence à paraître plus pénible que le clavier, même quand la transcription est techniquement correcte.
Un bon retour d'état devrait être net, presque tangible
Quand je dis qu'un bon retour vocal devrait avoir quelque chose de physique, je ne parle pas d'une interface rétro avec des faux boutons en métal. Je parle d'une sensation de netteté. Comme avec un bon outil : on sent tout de suite quand ça démarre, quand ça a bien pris l'action, et quand c'est terminé.
Un logiciel vocal demande à l'utilisateur de faire confiance, en temps réel, à quelque chose qu'il ne voit pas. Si cette mécanique paraît molle, floue ou incertaine, la confiance s'évapore bien avant que l'utilisateur soit capable d'expliquer précisément ce qui l'agace.
Le démarrage et l'arrêt sont souvent le vrai point faible
C'est là que beaucoup d'outils perdent leurs utilisateurs, sans gros crash ni bug spectaculaire. Juste parce que toute l'interaction manque de netteté. Si le lancement de la dictée n'est pas assez clair, on parle trop tôt. Si l'arrêt laisse un doute, on continue trop longtemps. Si le feedback pendant le traitement est trop discret, on se demande si le système a vraiment compris quelque chose.
Pris isolément, aucun de ces défauts n'a l'air dramatique. Mais mis bout à bout, ils donnent une impression de flou, de fragilité, parfois même de gêne. Et pour un outil vocal, c'est rédhibitoire. Toute la promesse de la voix, c'est de simplifier l'action. Si l'utilisateur doit surveiller l'interface en permanence, la promesse est déjà foutue.
Sur Windows, c'est encore plus important
Le travail sur Windows est rarement propre ou linéaire. On passe d'un mail à un navigateur, puis à un IDE, à des docs, à des tickets, à un chat, à une interface d'admin, puis à un outil interne un peu bancal. On change sans arrêt de contexte. La couche vocale doit donc rester compréhensible partout, pas seulement dans une démo bien rangée.
MachinesFluent est pensé dès le départ pour un usage system-wide, et ça rend cette question encore plus importante. L'utilisateur doit sentir que l'outil reste fiable, quelle que soit l'application au premier plan.
En clair
Oui, la qualité de reconnaissance compte. Évidemment. Mais une fois qu'un produit vocal atteint un niveau correct sur ce point, la vraie question devient beaucoup plus simple : est-ce qu'il paraît clair, stable et fiable ? Si la réponse est non, le reste de la stack ne sauvera pas grand-chose.
Continuer
Ce problème de feedback rejoint le sujet plus large de la vraie latence du clavier et celui de la dictée qui doit produire un texte exploitable.
MachinesFluent est construit autour de cette exigence : une voix lisible, fiable, utilisable dans le vrai travail Windows. Vous pouvez l'essayer ici.