fr FAQ

🌐 Langue : English | Français

Foire Aux Questions

Décisions de design, périmètre, et comparaisons. Pour des fixes pas-à-pas, voir Troubleshooting.

Table des matières

Design

• Pourquoi le moteur ASR est en Rust ?
• Pourquoi pas de Whisper streaming ?
• Pourquoi pas Vosk pour le streaming ?
• Pourquoi ONNX et pas PyTorch ?
• Pourquoi NeMo Parakeet plutôt que d'autres modèles ?

Fonctionnalités

• dictée tourne-t-elle 100 % offline ?
• Puis-je utiliser plusieurs backends ASR en même temps ?
• dictée fonctionne-t-elle sur Wayland ?
• dictée fonctionne-t-elle dans un Flatpak / Snap ?

Multi-utilisateur / sécurité

• dictée est-elle sûre en multi-utilisateur ?
• La correction LLM envoie-t-elle mon texte au cloud ?
• Le modèle ASR phone home ?

Comparaison

• dictée vs nerd-dictation
• dictée vs Talon
• dictée vs Whisper.cpp

Matériel

• Matériel minimum ?
• Fonctionne-t-elle sur GPU AMD / Intel ?
• Fonctionne-t-elle sur Apple Silicon ?

---

Design

Pourquoi Rust ?

Le moteur ASR (Parakeet, Canary, Sortformer, Nemotron) tourne en Rust via ONNX Runtime. Trois raisons :

1. Latence : Rust + ONNX évite l'overhead de l'interpréteur Python. La latence chaude pour une utterance de 5 s sur CPU est ~0,8 s vs ~1,5 s pour un équivalent pure-Python.
2. Temps de démarrage : Le daemon Rust démarre à froid en < 500 ms (chargement modèle exclu). Les équivalents Python prennent 2–3 secondes juste pour importer torch + transformers.
3. Portabilité : Un binaire unique avec ONNX Runtime statiquement lié est plus facile à packager que Python + venv + multiples wheels.

L'UI (assistant de configuration, tray) reste en Python + PyQt6 car la vitesse d'itération GUI compte plus que la latence là.

Pourquoi pas de Whisper streaming ?

Whisper est un modèle encoder-decoder. L'encodeur a besoin de l'utterance complète (en chunks de 30 secondes) avant que le décodeur puisse émettre des tokens. Plusieurs projets approximent le streaming en faisant glisser une fenêtre et ré-exécutant l'encodeur toutes les ~1 s — ça gâche du GPU et produit du jitter.

L'approche dictée : utiliser Parakeet-TDT (transducer, émet des tokens incrémentalement sans ré-exécuter l'encodeur) par défaut, et réserver Whisper pour sa force — large couverture linguistique sur transcription batch où la latence n'importe pas.

Pourquoi pas Vosk pour le streaming ?

Vosk streame nativement. Il est livré comme backend précisément pour cette raison. Compromis :

• Précision inférieure à Parakeet/Canary/Whisper
• Pas de ponctuation native
• Couverture linguistique plus petite

Si vous avez besoin de transcription vraiment en direct avec du texte qui apparaît en parlant, Vosk est la seule option. Le flux Parakeet-TDT par défaut transcrit après que vous ayez arrêté de parler (toggle / style push-to-talk) ce que la plupart des utilisateurs trouvent plus confortable.

Pourquoi ONNX, pas PyTorch ?

• Simplicité de déploiement : un graphe ONNX compilé n'a pas besoin que Python + torch + CUDA toolkit soient installés
• Cross-platform : ONNX Runtime a des execution providers pour CPU, CUDA, TensorRT, CoreML, OpenVINO, DirectML, WebGPU
• Taille : les graphes ONNX sont ~30 % plus petits que les checkpoints torch
• Stabilité : pas d'enfer de version pinning avec les changements d'API torch

Le compromis : plus difficile à déboguer les cas limites, pas d'autograd pour du fine-tuning custom. Pour du shipping inference-only, ONNX gagne.

Pourquoi NeMo Parakeet ?

La famille NeMo Parakeet de NVIDIA combine quatre propriétés qu'aucun autre modèle ouvert n'a toutes :

1. Encodeur FastConformer (sous-échantillonnage + blocs conformer = basse latence)
2. Décodeur TDT (token-and-duration transducer, frame-skipping = inférence plus rapide)
3. Ponctuation et capitalisation natives (pas de post-traitement nécessaire)
4. 25 langues européennes dans un seul modèle 600M

Les alternatives comme Parakeet-CTC (même encodeur, décodeur CTC) sont plus rapides mais ne ponctuent pas. Canary-1B a meilleure qualité mais fait 5 Go et GPU-only. Whisper a une couverture linguistique plus large mais plus de latence et pire ponctuation sur utterances courtes.

---

Fonctionnalités

Totalement offline ?

Par défaut, oui — avec Parakeet, Canary, faster-whisper ou Vosk, toute l'inférence est locale.

Vous choisissez le réseau seulement si vous prenez :

• Google Translate ou Bing Translator (texte envoyé à Google/Microsoft)
• Ollama ou LibreTranslate sur un hôte distant (texte envoyé sur votre LAN)

L'audio ne quitte jamais votre machine dans aucune configuration.

Puis-je faire tourner plusieurs backends ASR en même temps ?

Non. Les fichiers d'unités systemd incluent des directives Conflicts= — un seul de dictee.service / dictee-canary.service / dictee-whisper.service / dictee-vosk.service peut être actif à la fois.

Raison : chaque backend se bind sur le même socket Unix. En lancer deux serait en conflit.

Le changement est instantané (pas de latence de redémarrage service), vous pouvez donc alterner au milieu d'une session.

Wayland ?

Oui, entièrement supporté. dictée utilise dotool pour simuler l'entrée clavier, ce qui marche sur Wayland (contrairement à xdotool). Notifications, plasmoid et tray marchent tous nativement sur les compositeurs Wayland.

Testé : KDE Plasma 6 Wayland, GNOME 45+ Wayland, Sway, Hyprland.

Flatpak / Snap ?

Pas encore. Défis de packaging :

• dotool a besoin de l'accès à /dev/uinput (bloqué dans la plupart des sandboxes)
• dictee-ptt a besoin de l'accès à /dev/input/event*
• L'installation plasmoid nécessite kpackagetool6 avec permissions système
• Les bibliothèques CUDA font des centaines de Mo — pas idéal pour une app sandboxée

Résolvables (les portals existent pour la simulation d'entrée, Flatpak a des extensions NVIDIA) mais pas encore abordés. Contributions bienvenues !

---

Multi-utilisateur / sécurité

Multi-utilisateur ?

Oui, depuis v1.3.0-beta1. Les fichiers d'état dans /dev/shm sont namespaces par UID :

/dev/shm/.dictee_state_1000     # utilisateur 1000
/dev/shm/.dictee_state_1001     # utilisateur 1001 — fichier séparé, état séparé

Deux utilisateurs sur la même machine peuvent dicter en parallèle sans interférence.

La correction LLM envoie-t-elle du texte au cloud ?

Non — la correction LLM utilise votre instance Ollama locale (http://localhost:11434 par défaut). Le texte ne quitte jamais votre machine.

Exception : si vous pointez DICTEE_OLLAMA_HOST vers un serveur Ollama distant, le texte va sur votre LAN. Mais c'est un choix utilisateur explicite.

Le modèle ASR phone home ?

Non. Les modèles ONNX sont des fichiers statiques. Ils n'exécutent pas de code arbitraire et n'ont pas d'accès réseau. Les poids de modèles que vous téléchargez depuis HuggingFace sont signés cryptographiquement par NVIDIA/NeMo.

dictée elle-même ne fait aucune requête sortante sauf :

• Installeur (install.sh) : récupère les artefacts de release depuis api.github.com
• Vérification de mise à jour (optionnel, désactivé par défaut) : interroge api.github.com/repos/rcspam/dictee/releases
• Traduction cloud (Google / Bing) : seulement si vous choisissez ces backends

Rien d'autre.

---

Comparaison

vs nerd-dictation

nerd-dictation est un outil de dictée basé Vosk avec une CLI élégante.

Fonctionnalité	dictée	nerd-dictation
Backends ASR	4	1 (Vosk)
Ponctuation	Native (Parakeet/Canary)	Regex-based
Traduction	5 backends	Aucune
GUI	Setup wizard + plasmoid + tray	Aucune
Correction LLM	Oui (Ollama)	Non
Diarisation	Oui (sans limite de locuteurs depuis la v1.4)	Non

Prendre nerd-dictation si : vous voulez un setup Python-only minimal sans intégration bureau. Prendre dictée si : vous voulez une suite de dictée complète avec GUI et modèles modernes.

vs Talon

Talon est une suite propriétaire de contrôle vocal avec excellent scripting.

Fonctionnalité	dictée	Talon
Open source	✅ GPL-3.0	❌ Closed source, tier gratuit
Moteurs ASR	4 ouverts	1 fermé (custom)
Scripting vocal	Basique (commandes vocales regex)	Avancé (scripting Python)
Multi-langues	25+ (Parakeet)	Anglais-first
Accessibilité	Standard	Focus fort sur accessibilité

Prendre Talon si : vous avez besoin de contrôle vocal pour navigation / souris / scripting complexe. Prendre dictée si : vous avez besoin de dictée open-source dans plusieurs langues.

vs Whisper.cpp

Whisper.cpp est un runtime Whisper C++. dictée utilise faster-whisper (CTranslate2) qui est un autre runtime Whisper.

Les deux produisent une sortie Whisper comparable. Whisper.cpp est plus rapide sur CPU pour certaines configs, faster-whisper est plus rapide sur GPU. dictée a choisi faster-whisper car :

• Meilleure intégration Python (notre post-traitement est Python)
• Timestamps word-level pour la fonctionnalité continuation
• Support distil-large-v3 out of the box

---

Matériel

Matériel minimum ?

N'importe quoi qui fait tourner un Linux moderne avec un microphone. Spécifiquement :

• CPU : n'importe quel x86_64 (ou aarch64 avec build depuis sources) des 10 dernières années
• RAM : 4 Go pour Vosk, 8 Go pour Parakeet, 16 Go pour Canary + LLM
• GPU : optionnel (fallback CPU marche pour tous les backends sauf Canary qui est impraticable sur CPU)
• Disque : 5 Go pour tous les modèles par défaut, 15 Go si vous voulez tous les backends ASR + modèles traduction

Minimum testé : Raspberry Pi 4 (4 Go RAM) avec Vosk, ~2 s de latence par utterance.

GPU AMD / Intel ?

Pas actuellement. dictée utilise l'execution provider CUDA d'ONNX Runtime. Des providers expérimentaux existent pour ROCm (AMD) et OpenVINO (Intel) mais :

• Non livrés dans les paquets pré-compilés (nécessiterait de recompiler ONNX Runtime depuis les sources par distro)
• Pas de tests automatisés sur matériel AMD/Intel
• Contributions communautaires bienvenues !

Les utilisateurs GPU AMD/Intel devraient utiliser la variante CPU — attendez-vous à ~1 s de latence chaude pour utterances de 5 s.

Apple Silicon ?

Via Asahi Linux : CPU seul. ONNX Runtime a un provider CoreML mais Asahi ne l'expose pas au user-space Linux.

macOS natif : non supporté. dictée s'appuie lourdement sur :

• dotool / evdev Linux pour l'entrée
• KDE Plasma / GNOME pour l'intégration bureau
• services systemd utilisateur

Un portage macOS nécessiterait de réécrire de grandes parties. Non planifié.

---

Étapes suivantes

• Troubleshooting — quand les choses tournent mal
• Developer-Guide — comment contribuer
• Changelog — nouveautés et planifié