Skip to content

fr How It Works

Jump to bottom
rcspam edited this page May 15, 2026 · 1 revision

🌐 Langue : English | Français

Comment dictée fonctionne — vue d'ensemble

Cette page explique ce qui se passe entre l'appui sur F9 et l'apparition du texte. Pas besoin de connaître la programmation pour la lire — l'objectif est de te donner une image mentale claire du système.

Que se passe-t-il quand tu appuies sur F9 ?

En une phrase : ta voix est enregistrée, envoyée à un programme qui sait comprendre la parole, le texte transcrit est renvoyé, puis tapé dans la fenêtre où était ton curseur. Le tout en moins d'une seconde sur une bonne machine.

Mais derrière cette simplicité apparente, il y a 8 niveaux de logiciels qui se passent le relais. Chacun a un rôle précis. Comprendre ces niveaux aide à diagnostiquer les problèmes et à choisir les bons réglages.

La pile en une image

┌─────────────────────────────────────────────────────┐
│  1.  Tu appuies sur F9                              │  ← Toi
│                                                     │
│  2.  Le script dictée (le chef d'orchestre)         │
│                                                     │
│  3.  Le messager (transcribe-client)                │
│                       ↓ via un tuyau (socket Unix)  │
│  4.  Le serveur de transcription (transcribe-       │
│      daemon) — toujours prêt en arrière-plan        │
│                                                     │
│  5.  La bibliothèque maison (parakeet-rs)           │  ← Le code de dictée
│                                                     │
│  6.  Le pont vers le moteur (ort)                   │
│                                                     │
│  7.  Le moteur d'inférence (libonnxruntime)         │  ← Code Microsoft
│                                                     │
│  8.  Le pilote matériel (CPU ou GPU NVIDIA)         │  ← Le matériel
│                                                     │
│  9.  Le modèle d'intelligence artificielle (.onnx)  │  ← Le "cerveau" entraîné
└─────────────────────────────────────────────────────┘

Les 9 niveaux expliqués

1. Toi qui appuies sur F9

L'utilisateur appuie sur F9 (ou clique sur le widget de la barre des tâches, ou utilise dictee-transcribe pour un fichier audio). C'est le point de départ.

2. Le script « dictée » — le chef d'orchestre

C'est un programme texte (un « script shell ») qui vit dans /usr/bin/dictee. Quand il est lancé, il :

  • enregistre l'audio depuis ton micro pendant que tu parles (avec un outil système qui s'appelle pw-record)
  • lit ta configuration (le fichier ~/.config/dictee.conf) pour savoir quel moteur de reconnaissance utiliser (Parakeet ? Canary ? Whisper ?)
  • transmet le fichier audio enregistré au serveur de transcription (étape 4)
  • une fois qu'il reçoit le texte, l'écrit dans ta fenêtre active (avec un outil qui s'appelle dotool, équivalent à un clavier virtuel)
  • s'occupe aussi du post-traitement : ajouter la ponctuation manquante, corriger des règles de langue, déclencher éventuellement une traduction…

C'est le programme que tu pilotes indirectement. Tous les réglages de l'application passent par lui.

3. Le messager (transcribe-client) — le coursier

C'est un petit programme très léger, installé en /usr/bin/transcribe-client. Son seul travail : transporter ton fichier audio jusqu'au serveur de transcription, et ramener le texte transcrit.

Imagine un coursier à vélo qui amène un paquet à un atelier et revient avec la réponse. Il est volontairement minimaliste : il démarre instantanément, ne consomme presque rien, ne sait pas comment fonctionne la transcription. Il ne fait que transmettre.

Pourquoi un coursier séparé ? Parce que le vrai serveur de transcription (étape 4) est gros et lent à démarrer (il doit charger un modèle d'intelligence artificielle en mémoire). Si on devait démarrer ce serveur à chaque dictée, on attendrait 3 secondes au lieu d'avoir une réponse instantanée.

4. Le serveur de transcription (transcribe-daemon) — le scribe permanent

C'est le vrai cerveau de la transcription. Il vit en arrière-plan en permanence (dès le démarrage de ta session), géré par systemd comme un service système (dictee.service).

Ce serveur :

  • charge le modèle d'IA une seule fois au démarrage (ça prend 2-5 secondes, mais on ne le paie qu'une fois par session)
  • garde le modèle en mémoire (RAM si CPU, VRAM si GPU)
  • attend en écoute sur un canal de communication (un « socket » Unix, qui est juste un fichier spécial servant de tuyau entre programmes)
  • pour chaque fichier audio qu'il reçoit : analyse, transcrit, renvoie le texte
  • s'arrête uniquement quand tu fermes ta session

C'est cette architecture « serveur permanent + petit client » qui explique pourquoi dictée est réactive : le gros travail de chargement est fait une fois, pas à chaque dictée.

5. La bibliothèque maison (parakeet-rs) — la salle de cours

À ce stade, le serveur de transcription a reçu un fichier audio. Il fait appel à une bibliothèque de code (au sens « collection de fonctions réutilisables ») qui sait comment transformer de l'audio en texte. Cette bibliothèque s'appelle parakeet-rs. C'est le code que maintiennent les développeurs de dictée.

Elle s'occupe de :

  • transformer le son brut (les vibrations échantillonnées à 16 000 fois par seconde) en une représentation mathématique que le modèle d'IA comprend (un « mel-spectrogramme » — imagine une photo couleur de la fréquence du son dans le temps)
  • charger le modèle ONNX (le « cerveau », étape 9) depuis le disque
  • alimenter le modèle avec le mel-spectrogramme
  • récupérer les sorties du modèle (des nombres représentant la probabilité de chaque caractère/mot)
  • boucler caractère par caractère pour reconstruire le texte final

C'est la partie « intelligence métier » : tout ce qui est spécifique au format Parakeet ou Canary (les deux modèles que dictée supporte en Rust). Si demain on voulait ajouter le support d'un nouveau modèle, c'est ici qu'on ajouterait du code.

6. Le pont vers le moteur (ort) — le traducteur

Le code de parakeet-rs est écrit en Rust, mais le moteur d'inférence (étape 7) qui exécute réellement le modèle est écrit en C++ (un autre langage). Pour qu'ils puissent se parler, il faut un traducteur : la bibliothèque ort.

Imagine une réunion entre un dirigeant français et un dirigeant chinois : il leur faut un interprète pour se comprendre. ort est cet interprète entre le code Rust de dictée et le moteur C++ Microsoft.

Sans cette couche, le développeur devrait écrire manuellement tous les appels de bas niveau (un travail fastidieux et risqué). Avec ort, on dit simplement en Rust : « charge ce fichier .onnx, donne-lui ces données en entrée, et donne-moi les sorties ».

7. Le moteur d'inférence (libonnxruntime.so) — la salle des machines

C'est une grosse bibliothèque (~50 à 80 Mo) développée par Microsoft, gratuite et open-source, utilisée par énormément de projets dans le monde (pas seulement dictée). Elle est installée chez toi en /usr/lib/dictee/libonnxruntime.so.

Son rôle : exécuter des modèles d'intelligence artificielle au format ONNX (format standard, comme PDF pour les documents).

Quand on lui demande « exécute ce modèle avec ces données » :

  1. Elle lit le fichier .onnx : c'est un dossier de plans (la structure du modèle) et de valeurs (les milliards de paramètres que le modèle a appris pendant son entraînement)
  2. Elle construit le graphe d'opérations : « d'abord cette multiplication de matrices, ensuite cette convolution, puis cette fonction de probabilité, etc. »
  3. Elle optimise le graphe : éliminer les calculs redondants, fusionner les opérations qui peuvent l'être
  4. Elle délègue chaque opération au pilote matériel approprié (étape 8)

Tu n'as jamais à toucher ce code — c'est une dépendance binaire qu'on installe avec dictée. Mais il est utile de savoir qu'il existe : si un jour tu vois un message d'erreur qui parle de « ONNX Runtime » ou « ORT », c'est lui.

8. Le pilote matériel (Execution Provider) — l'ouvrier qualifié

L'étape précédente a transformé le modèle en une liste d'opérations mathématiques à faire. Mais chaque opération doit être traduite dans le langage du matériel sur lequel on tourne :

  • Sur CPU (processeur central, présent dans toutes les machines) : les opérations sont traduites en instructions du processeur. Les processeurs modernes ont des instructions spéciales optimisées pour l'IA (AVX2, AVX-VNNI) qui accélèrent les multiplications de matrices.

  • Sur GPU NVIDIA (carte graphique avec accélération CUDA) : les opérations sont traduites en « kernels CUDA », c'est-à-dire des petits programmes qui tournent en parallèle sur les milliers de cœurs du GPU. Beaucoup plus rapide pour les modèles d'IA.

Le choix entre CPU et GPU est fait au démarrage du serveur de transcription :

  • Si tu as installé dictée-cuda et qu'une carte NVIDIA est détectée → GPU
  • Si tu as installé dictée-cpu, ou pas de carte NVIDIA, ou la variable DICTEE_FORCE_CPU=1 est définie → CPU

C'est ce qui explique les différences de vitesse : sur la même machine, Parakeet prend 0,18 s sur GPU contre 1,17 s sur CPU pour 16 s d'audio.

9. Le modèle ONNX — le cerveau entraîné

Le modèle, c'est le « cerveau » de la reconnaissance vocale. C'est lui qui sait, après des semaines d'entraînement par les chercheurs de NVIDIA, comment associer des sons à du texte.

Concrètement, c'est un fichier sur ton disque (typiquement dans /usr/share/dictee/tdt/) qui contient :

  • La structure du réseau de neurones : combien de couches, comment elles sont connectées, etc.
  • Les poids : des milliards de nombres ajustés pendant l'entraînement. Ce sont eux qui « savent » associer un certain motif sonore à un certain mot.
  • La précision : 32 bits par poids (FP32, plus précis mais lourd) ou 8 bits par poids (INT8, plus léger mais légèrement moins précis).

dictée supporte deux modèles principaux :

  • Parakeet-TDT 0.6B v3 : 25 langues, ~600 millions de paramètres, format .onnx, ~2,4 Go en FP32 ou ~670 Mo en INT8
  • Canary 1B v2 : 7 langues avec traduction intégrée, ~1 milliard de paramètres, ~4 Go en FP32 ou ~1 Go en INT8

Ces modèles sont téléchargés une fois depuis Hugging Face (un dépôt public de modèles d'IA) au moment du setup.

Pourquoi cette architecture en couches ?

Ça peut paraître compliqué, mais chaque couche a une bonne raison d'exister :

Séparation client/serveur (étapes 3 et 4) : le client est instantané, le serveur garde le modèle chargé. Sans cette séparation, chaque dictée prendrait 3-5 secondes de plus (le chargement du modèle).

Bibliothèque parakeet-rs (étape 5) vs moteur ORT (étape 7) : parakeet-rs s'occupe des particularités de Parakeet/Canary (formats spécifiques, pré-traitement audio, post-traitement texte). ORT s'occupe de l'exécution générique du modèle. Cette séparation permet :

  • de mettre à jour ORT sans réécrire dictée
  • d'utiliser ORT pour d'autres modèles (whisper, vision par ordinateur, etc.) sans changer son code
  • de profiter des optimisations Microsoft sans effort

Pilote matériel (étape 8) : le même modèle ONNX peut tourner sur Linux/Windows/Mac, sur Intel/AMD/Apple Silicon, sur CPU ou GPU. C'est ce qui fait la richesse du format ONNX.

Où chaque couche vit sur ton disque

Couche Emplacement
dictee (script) /usr/bin/dictee
transcribe-client /usr/bin/transcribe-client
transcribe-daemon /usr/bin/transcribe-daemon
parakeet-rs (compilé dans transcribe-daemon) inclus dans le binaire ci-dessus
ort (idem) inclus dans le binaire ci-dessus
libonnxruntime.so /usr/lib/dictee/libonnxruntime.so
Driver NVIDIA + libcudnn /usr/lib/x86_64-linux-gnu/ ou /usr/lib/dictee/
Modèle Parakeet TDT /usr/share/dictee/tdt/ (ou ~/.local/share/dictee/tdt/)
Modèle Canary /usr/share/dictee/canary/
Modèle Sortformer (diarisation) /usr/share/dictee/sortformer/
Configuration utilisateur ~/.config/dictee.conf

Métaphore résumée

Imagine que tu commandes un plat dans un restaurant :

Couche Métaphore
Toi qui appuies sur F9 Le client qui passe sa commande
Le script dictée Le serveur en salle, qui écrit la commande
Le messager transcribe-client Le commis qui apporte la commande à la cuisine
Le serveur transcribe-daemon Le chef de cuisine, déjà en place, toujours prêt
La bibliothèque parakeet-rs Le livre de recettes propre au restaurant
Le pont ort Le traducteur entre le livre (en français) et le chef (anglophone)
Le moteur libonnxruntime.so Le savoir-faire général de cuisine (peler, hacher, cuire…)
Le pilote matériel Les ustensiles : feu à gaz (CPU) ou induction (GPU)
Le modèle .onnx La recette détaillée, fruit de longues recherches

Toutes ces couches collaborent. Chacune fait bien une seule chose. C'est ce qui rend le système robuste et évolutif.

Pour aller plus loin

📖 dictee Wiki

🇬🇧 Home · 🇫🇷 Accueil

Getting started / Premiers pas

Speech recognition / ASR

Translation / Traduction

Post-processing / Post-traitement

CLI

Reference / Référence

🏠 Repo · 📦 Releases · 🐛 Issues

Clone this wiki locally