L'IA peut-elle nettoyer votre dictée sans l'envoyer dans le cloud ?

Oui — nettoyer une dictée (retirer les mots de remplissage, corriger la ponctuation, découper un paragraphe décousu en phrases lisibles) peut tourner entièrement sur votre propre machine. Pas besoin d'un modèle de pointe. Un grand modèle de langage quantisé, de quelques milliards de paramètres, tournant sur la même pile d'inférence locale que votre moteur de reconnaissance vocale, suffit à transformer une sortie vocale brute en une prose propre.

Un développeur indépendant en a démontré la forme concrète : une app de dictée macOS associant un modèle de transcription Parakeet à 0,6 milliard de paramètres à un modèle Llama à 3 milliards de paramètres pour le nettoyage, les deux tournant en local via le framework MLX d'Apple, les deux étapes combinées se terminant en bien moins d'une seconde sur un Mac M-series standard (Hacker News, « Show HN: local speech-to-text is shockingly fast on Apple Silicon »). La réécriture locale est un problème d'ingénierie résolu, à petite échelle. Alors pourquoi la quasi-totalité des apps de dictée qui vendent le « AI formatting » envoient-elles encore vos mots vers un serveur pour l'obtenir ?

Pourquoi la dictée « locale » envoie-t-elle encore votre texte vers le cloud ?

Transcription et nettoyage sont deux métiers différents, et la plupart des apps ne localisent que le premier. Wispr Flow est l'exemple le plus net de ce qui ne localise ni l'un ni l'autre : selon sa propre description de fonctionnement, votre audio est capté, envoyé vers les serveurs cloud de Wispr, traité par des modèles d'IA — dont des fournisseurs tiers comme OpenAI et Meta — puis le résultat est renvoyé (wisprflow.ai ; confirmé indépendamment par un avis tiers qui note que « voice processing happens in the cloud... including providers like OpenAI and Meta »). Ce n'est pas un effet de bord : c'est justement ce traitement cloud qui rend possible son formatage IA sensible au contexte.

Le cas le plus intéressant, ce sont les apps qui se présentent comme « local-first » mais qui repassent par le cloud à l'étape du nettoyage. Spokenly et OpenWhispr font tourner la transcription en local par défaut, puis confient l'étape de réécriture à une API cloud via le « bring your own key » (BYOK) : la documentation d'OpenWhispr liste elle-même « GPT for AI agent » sous son option BYOK OpenAI, et sa page de comparaison précise explicitement que « the AI cleanup step can optionally use a cloud LLM API if you configure it, while the underlying speech-to-text always runs locally » (docs.openwhispr.com ; openwhispr.com/compare/wisprflow). Un avis comparatif sur Spokenly le formule tout aussi clairement : « Local by default, but the AI text cleanup features route through OpenAI/Anthropic APIs. If you use BYOK, your audio stays local but your text leaves your Mac for processing » — et note que le « fully-local mode » de Spokenly « has no AI cleanup » du tout (getseam.app).

Ce qui pointe vers l'écart réel : les apps qui restent aujourd'hui entièrement locales le sont le plus souvent parce qu'elles sautent le nettoyage, pas parce qu'elles l'ont résolu en local. VoiceInk est décrite dans cette même comparaison comme « 100% local, always... No cloud features at all » — mais aussi comme n'offrant « no post-processing beyond basic filler word removal ». Un avis complémentaire opposant Seam à Spokenly résume l'arbitrage dans un seul tableau : Seam est 100% local sans nettoyage de texte par IA ; Spokenly a un nettoyage de texte par IA (GPT-4, Claude) qui envoie le texte — pas l'audio — vers les serveurs d'OpenAI ou d'Anthropic pour l'obtenir (getseam.app/blog/seam-vs-spokenly). Dictée locale et nettoyage par IA ont été vendus comme un arbitrage où il faudrait choisir un camp. Ce n'est pas le cas, techniquement — c'est juste rarement construit ensemble.

Que peut réellement faire un LLM local avec du texte dicté ?

Ce même projet de dictée présenté sur Show HN détaille une liste de tâches concrète, déjà en service, pour son modèle de nettoyage on-device : retirer les mots de remplissage (« euh », « hum ») et les bégaiements/répétitions, convertir les nombres énoncés à l'oral, convertir les caractères spéciaux, développer les acronymes (« A P I » → « API »), mettre en forme les adresses e-mail dictées (« hi at example dot com » → « hi@example.com »), et convertir les montants et horaires énoncés à l'oral en chiffres (« two ninety nine » → « $2.99 » ; « three oh two » → « 3:02 ») (Hacker News, getonit.ai). C'est un ensemble de fonctionnalités réel, déjà livré — pas hypothétique — qui tourne entièrement via un modèle local.

Rien de tout cela n'exige un modèle géant. C'est la catégorie de tâche — appliquer une transformation connue et bornée à un texte d'entrée — pour laquelle les petits modèles ouverts de 3 à 4 milliards de paramètres, quantisés en formats 4 bits comme GGUF (pour llama.cpp) ou MLX, sont couramment utilisés sur du matériel grand public ; un benchmark académique récent sur les LLM on-device a évalué spécifiquement des modèles Qwen 2.5/3 et Llama 3 à ces tailles, pour exactement ce type de déploiement contraint et à ressources limitées (arXiv:2505.15030). Réécrire un paragraphe de parole dictée en une prose propre entre pleinement dans cette enveloppe — c'est une transformation de motif sur un texte déjà présent devant le modèle, sans besoin de connaissances générales du monde.

Où la réécriture locale reste en retrait des modèles de la classe GPT-4

Les limites, il vaut la peine de les dire franchement, d'autant que c'est l'équipe même qui a livré ce nettoyage local qui les a signalées : « small LLMs (3B, 1B) still make mistakes. They can hallucinate long, unrelated responses and occasionally repeat back a few-shot example. » Leur parade a été défensive plutôt que corrective — revenir à la transcription brute et non modifiée dès que la sortie du petit modèle semblait peu fiable, ce qui veut dire que « some 'ums' and 'ahs' still make it through » (Hacker News, getonit.ai).

Cet arbitrage revient à chaque fois que des ingénieurs remplacent un modèle de pointe par un petit modèle local sur une tâche de langage : un retour d'expérience détaillé sur le remplacement de GPT-4 par un petit modèle de langage local dans un pipeline de traitement de documents rapporte que le petit modèle gère de façon fiable la majorité des cas bien définis, tout en reconnaissant que « GPT-4 is genuinely better on ambiguous documents... anything requiring real inference » — et en renvoyant ces cas plus difficiles vers un circuit de relecture séparé plutôt que de prétendre que le petit modèle pourrait aussi les couvrir (Towards Data Science). Appliqué à la dictée : un modèle local est bien adapté aux mots de remplissage, à la ponctuation, à la mise en forme des nombres et à la structure des paragraphes — des tâches étroites et répétables. Les réécritures profondes de ton, les formulations ambiguës, ou un contenu qui demande un vrai jugement, sont les cas où un petit modèle on-device a le plus de chances d'avoir besoin d'un second regard humain, comme dans n'importe quel autre domaine.

Comment fonctionne concrètement une passe de réécriture locale ?

Mécaniquement, c'est une étape supplémentaire greffée sur le même pipeline qui fait déjà tourner la reconnaissance vocale en local — voir notre article sur le GPU dont une app de dictée locale a réellement besoin pour la partie transcription. L'étape de réécriture se place immédiatement après la transcription et avant que le texte n'atterrisse : un modèle de langage quantisé, chargé une fois et gardé au chaud, lit la transcription brute et renvoie une version nettoyée, en partageant le même GPU qui vient de faire la passe de reconnaissance vocale, au lieu d'ouvrir une connexion réseau. Dans le projet basé sur MLX cité plus haut, le pipeline combiné — transcription Parakeet plus nettoyage Llama 3B — atteint environ 800 ms de latence p50 pour une phrase complète, contre moins de 500 ms quand l'étape LLM est entièrement sautée (Hacker News, getonit.ai). Cette latence ajoutée est le coût de la seconde passe de modèle ; la priorité de ce qu'il faut corriger en premier — le désordre que cette passe est justement conçue pour retirer — est la même liste que nous avions détaillée dans notre article sur pourquoi les mots de remplissage survivent à la dictée.

Ce qu'Inkvox construit pour Pro

La dictée cœur d'Inkvox fonctionne déjà sur ce principe pour la transcription : Whisper large-v3-turbo, quantisé, sur votre propre GPU via Vulkan — NVIDIA, AMD ou Intel, avec un repli CPU si vous n'en avez pas — transcrivant une phrase en environ 0,3 à 0,4 seconde sur du matériel comme une RTX 3070, dans plus de 100 langues. Zéro octet d'audio envoyé, aucun compte requis, fonctionnement entièrement hors ligne après le téléchargement initial du modèle (~800 Mo). Voir comment ça marche.

La couche de réécriture décrite dans cet article — celle qui nettoie les mots de remplissage, reformate et ajuste le ton après la transcription — c'est ce que nous construisons ensuite, pour Inkvox Pro : un LLM local tournant sur ce même GPU, faisant ce même type de travail, toujours 100% local. C'est en développement actif, pas encore livré, et nous n'allons pas prétendre le contraire — quand ça sortira, ce sera comme une passe locale, pas un aller-retour discret par l'API de quelqu'un d'autre. Le support macOS est prévu pour suivre le même modèle local-first une fois la bêta Windows stabilisée.

Questions fréquentes

Le nettoyage IA d'une dictée peut-il tourner en local plutôt que dans le cloud ?

Oui. Un grand modèle de langage quantisé de quelques milliards de paramètres — assez petit pour tourner sur un GPU grand public à côté d'un modèle de reconnaissance vocale — peut retirer les mots de remplissage, corriger la ponctuation et reformater le texte dicté sans qu'aucune donnée ne quitte l'appareil. Des projets de dictée locale indépendants ont déjà livré ce schéma avec de petits modèles locaux comme Llama 3B.

Pourquoi les apps de dictée « locales » envoient-elles encore du texte à OpenAI ou à Anthropic ?

Parce que transcription et nettoyage sont deux étapes séparées, et la plupart des apps ne localisent que la première. La reconnaissance vocale peut tourner on-device, mais la couche de formatage ou de réécriture IA est souvent redirigée vers une API LLM cloud — documenté chez des apps comme Spokenly et OpenWhispr, où la transcription cœur est locale mais le nettoyage IA optionnel utilise votre propre clé API OpenAI ou Anthropic.

Un LLM local réécrit-il la dictée aussi bien que GPT-4 ?

Pas sur toutes les tâches. Un petit modèle quantisé gère de façon fiable le nettoyage étroit et bien défini — mots de remplissage, ponctuation, mise en forme des nombres, retours à la ligne. Il est plus sujet à l'hallucination occasionnelle ou à la répétition qu'un modèle de pointe, et les développeurs qui ont livré ce schéma prévoient un repli vers la transcription brute quand la sortie du petit modèle semble peu fiable.

Quelle est la différence entre une réécriture IA locale et un formatage IA cloud comme Wispr Flow ?

Le formatage IA de Wispr Flow traite votre voix sur ses serveurs cloud, via des fournisseurs d'IA tiers, selon sa propre description du fonctionnement du produit. Une passe de réécriture locale exécute l'étape de nettoyage équivalente sur votre propre GPU, avec un modèle stocké sur votre machine, si bien que le texte dicté n'a jamais besoin de quitter l'appareil pour être formaté.

Le nettoyage que tout le monde attend de la dictée — moins de mots de remplissage, une meilleure ponctuation, un ton adapté à l'app dans laquelle vous tapez — n'exige pas un aller-retour vers le serveur de quelqu'un d'autre. Il exige un petit modèle, posé sur le même GPU qui fait déjà la transcription. Rejoignez la liste d'attente pour essayer Inkvox, et être informé en premier quand la couche de réécriture locale sortira.