DEV Community: elboKazQC

Un raccourci clavier global sur Windows, c'est pas juste un if keydown

elboKazQC — Tue, 21 Jul 2026 14:30:19 +0000

La seule personne qui a commenté mes articles ici l'a fait sur exactement ça : « le coup du F6 enfoncé, je parle, je relâche, ça colle direct ». Cinq articles publiés, un seul commentateur, et il tombe pile sur le mécanisme que je pensais le plus trivial du produit. Fa qu'on va le creuser.

Parce que c'est justement le morceau que j'ai le plus sous-estimé au début. Un raccourci global sur Windows, ça sonne comme un if keydown: enregistre suivi d'un if keyup: arrête. Dans les faits, entre le moment où tu tiens une touche et le moment où le texte atterrit au bon endroit, il y a une demi-douzaine de pièges que j'ai découverts un par un, en production, pas dans un tutoriel.

Toutes les touches ne font pas un bon raccourci global

Le premier piège, c'est de choisir la touche. Une lettre seule (« j » par exemple) vole littéralement la frappe à toutes les applications ouvertes, parce que le raccourci est enregistré en mode suppression (suppress=True) pour que la touche ne tape pas un caractère parasite dans ton éditeur : tape « j » n'importe où pendant que l'app tourne, et plus rien ne s'écrit à cet endroit.

Les touches de fonction (F1 à F24) sont le compromis le moins pire : elles n'écrivent aucun caractère, donc elles ne détruisent pas la frappe. Libres pour autant, non : F1 ouvre l'aide, F5 rafraîchit, F11 passe en plein écran, F12 ouvre les outils de développement. Et comme le raccourci est enregistré en mode suppression, la touche choisie est réellement volée aux autres applications tant que l'app tourne. F6 est le défaut parce que c'est une des moins chargées, pas parce qu'elle est libre, et elle se change avec --hotkey. Le code refuse une config bancale au démarrage plutôt que d'échouer en silence trois clics plus tard :

single_function_key = len(hotkey_keys) == 1 and hotkey_keys[0] in FUNCTION_KEYS
if len(hotkey_keys) < 2 and not single_function_key:
    raise ValueError(f"Hotkey must be a combo like ctrl+space or a function key like f6, got: {hotkey!r}")
if len(hotkey_keys) >= 2 and not any(key in MODIFIER_KEYS for key in hotkey_keys):
    raise ValueError(f"Hotkey combo must include a modifier key (ctrl/alt/shift/windows), got: {hotkey!r}")
if cancel in hotkey_keys:
    raise ValueError(f"Cancel key must not overlap the push-to-talk hotkey, got cancel={cancel!r} hotkey={hotkey!r}")

Trois règles, trois catégories de bug évitées avant même que l'app démarre : une touche seule qui n'est pas une touche de fonction, une combinaison sans modificateur (ctrl, alt, shift ou windows), et une touche d'annulation qui chevauche le raccourci lui-même. Ce dernier cas, je l'ai vécu en test : si la touche d'annulation partage une touche avec le hotkey, appuyer pour annuler peut redéclencher l'enregistrement au lieu de le couper. Mieux vaut planter au démarrage avec un message clair que planter en silence pendant que tu dictes.

Le relâchement de touche ment, dans les deux sens

J'ai déjà raconté ici le bug qui m'a pris deux soirs : l'événement de relâchement de Windows qui ne se déclenche carrément jamais, à cause d'un changement de focus ou d'un autre hook clavier actif en même temps. Le fix, c'était de ne jamais faire confiance à l'événement et de revérifier l'état physique du clavier avec un timer.

Ce que je n'avais pas encore raconté, c'est le problème inverse : il arrive qu'un relâchement parasite passe alors que la touche est encore enfoncée, typiquement pendant un changement de focus qui dure une fraction de seconde, ou quand un autre hook clavier réinjecte des événements. Sans anti-rebond, ce faux signal coupe l'enregistrement en plein milieu d'un mot, et la phrase ressort en deux clips séparés. Le même mécanisme règle les deux sens du problème : un timer qui attend un court délai, puis qui re-questionne le clavier avant de vraiment couper.

Le timer, je l'ai déjà montré dans l'article sur ce bug. Ce qui compte ici, c'est ce qu'il va vérifier avant de couper :

def _stop_if_hotkey_inactive(self):
    if any(keyboard.is_pressed(key) for key in self.hotkey_keys):
        return
    self.stop_recording()

Concrètement : le relâchement ne déclenche pas l'arrêt, il déclenche une question posée un peu plus tard. Si la touche est encore enfoncée, on continue. Sinon, on coupe. L'événement Windows n'est pas la vérité, juste une invitation à aller la vérifier.

L'indicateur visuel peut voler ta fenêtre active

Le piège le plus vicieux, c'est celui-là, parce qu'il ne casse rien de façon bruyante : il colle juste le texte au mauvais endroit. Quand Tania enregistre, une petite fenêtre d'état apparaît à l'écran. Si cette fenêtre devient la fenêtre active au moment du collage, le raccourci de collage part vers elle. Et comme elle n'a aucune zone de saisie, le texte ne va nulle part : ton éditeur n'a rien reçu et ta transcription est perdue sans un seul message d'erreur. Sur Windows, ça se règle au niveau du style de la fenêtre, pas dans la logique applicative :

GWL_EXSTYLE = -20
WS_EX_NOACTIVATE = 0x08000000
WS_EX_TOOLWINDOW = 0x00000080
cur = ctypes.windll.user32.GetWindowLongW(hwnd, GWL_EXSTYLE)
ctypes.windll.user32.SetWindowLongW(hwnd, GWL_EXSTYLE, cur | WS_EX_NOACTIVATE | WS_EX_TOOLWINDOW)

WS_EX_NOACTIVATE dit à Windows que cette fenêtre n'a pas le droit de prendre le focus, jamais. WS_EX_TOOLWINDOW la sort en plus de l'Alt+Tab et de la barre des tâches. Sans ces drapeaux, l'indicateur a l'air anodin à l'œil, mais plus rien ne l'empêche de prendre le focus quand il apparaît. Détail qui m'a coûté un moment de doute : le style étendu se pose sur une fenêtre déjà créée, alors je le réapplique à chaque réaffichage plutôt qu'une seule fois à l'initialisation.

Les modificateurs fantômes

Dernier piège, plus discret : si tu tiens ctrl ou shift en parlant (un réflexe si t'étais en train de sélectionner du texte juste avant), ce modificateur peut encore être considéré comme enfoncé au moment où le code envoie ctrl+v pour coller. Résultat : le collage se transforme en autre chose selon l'application active. Le fix, c'est de relâcher explicitement les trois modificateurs avant d'envoyer le collage :

keyboard.release("ctrl")
keyboard.release("shift")
keyboard.release("alt")
keyboard.send("ctrl+v")

Trois lignes qui coûtent rien, dans le chemin de collage par presse-papier. Ça ne défait pas la physique, si tu tiens vraiment la touche elle peut se ré-annoncer aussitôt, mais ça règle le cas courant du modificateur resté collé dans l'état du clavier.

Ce que le push-to-talk règle vraiment, et ce qu'il règle pas

Il y a un gain qui n'est dans aucune des lignes ci-dessus, mais dans la forme même du geste. Un clip borné par un humain qui tient une touche n'a pas de longue traîne de silence au début ni à la fin. C'est un des terrains où les modèles de transcription hallucinent le plus, largement documenté sur Whisper, ces bouts de phrase (« merci », « sous-titres réalisés par... ») qui sortent de nulle part sur du silence pur. Un mode toggle ou une écoute continue avale forcément du silence et du bruit ambiant, donc ça a besoin d'un détecteur d'activité vocale pour compenser. Le push-to-talk transfère cette décision à l'utilisateur, qui la prend mieux qu'un seuil automatique.

Ça reste un arbitrage, pas une victoire absolue. Tenir une touche pendant dix minutes de dictée continue, personne fait ça, fa que ce mode ne convient juste pas à la dictée longue. Et je vais le dire clairement parce que ça fait plusieurs articles que je le repousse : j'ai un protocole de banc d'essai pour mesurer un vrai taux d'erreur de transcription, et il n'a toujours pas tourné. Zéro chiffre de précision à montrer aujourd'hui, ici comme ailleurs dans la série. Le jour où ça tourne, ce sera un article à part, pas une ligne glissée dans celui-ci.

Le code des pièges ci-dessus est dans app.py, ouvert en MIT sur GitHub. Si vous avez déjà câblé un raccourci global sur Windows ou ailleurs, qu'est-ce qui a fini par piétiner un raccourci existant chez vous ? Je cherche encore les cas que j'ai pas prévus.

faster-whisper en local sur Windows, en français : les réglages qui ont vraiment changé ma sortie

elboKazQC — Tue, 14 Jul 2026 14:31:58 +0000

F6 enfoncé, je parle, je relâche, ça transcrit, ça colle où j'étais en train d'écrire. C'est tout ce que fait Tania Dictée, mon appli Windows de dictée vocale 100 % locale (aucun serveur, faster-whisper qui tourne sur ta machine, rien qui sort chez toi). Sauf qu'au début, ma sortie en français québécois plein d'anglicismes de dev sortait mal. Pas à cause du modèle. À cause de tout ce qu'il y a autour du modèle.

Je fais pas de benchmark ici, j'ai pas mesuré de taux d'erreur ni de latence, ça serait inventer des chiffres que j'ai pas. Ce que j'ai, c'est cinq réglages concrets qui ont changé ma sortie, dans l'ordre où je les ai découverts.

Le modèle, c'est un choix de matériel, pas un chiffre

Tania Dictée détecte le hardware au démarrage et choisit tout seul :

def auto_detect_device() -> str:
    return "cuda" if HAS_CUDA else "cpu"

def auto_detect_compute_type(device: str) -> str:
    return "float16" if device == "cuda" else "int8"

def auto_detect_model(device: str) -> str:
    return "large-v3" if device == "cuda" else "medium"

GPU CUDA disponible : large-v3 en float16. Sinon, CPU : medium en int8. Le int8, c'est de la quantification (CTranslate2 sous le capot de faster-whisper compresse les poids du modèle), et c'est ça qui rend un modèle sérieux tenable sur un CPU ordinaire, là où le même modèle en pleine précision devient trop lent pour de la dictée au fil de la frappe.

La tentation, quand ça roule sur CPU, c'est de descendre à tiny pour que ça aille plus vite. Je le déconseille sur du français. C'est exactement là que tu perds les accents, les mots rares, les noms propres. medium est le compromis que j'ai gardé : assez de matière pour du français québécois avec du jargon, encore raisonnable sur un CPU.

Les paramètres de transcribe() qui comptent

L'appel, avec les valeurs par défaut de l'app (language et beam_size sortent en réalité de la config) :

segments, info = model.transcribe(
    wav_path,
    language="fr",
    beam_size=5,
    vad_filter=True,
    condition_on_previous_text=True,
    word_timestamps=False,
    temperature=0.0,
    initial_prompt=self.initial_prompt,
    hotwords=self.hotwords,
)

language="fr" est forcé, pas laissé en auto-détection. Un clip push-to-talk, c'est souvent court, une phrase ou deux. Laisser Whisper deviner la langue sur un clip aussi court, c'est ouvrir la porte à ce qu'il bascule vers l'anglais en plein milieu. Forcer la langue élimine ce drift.

temperature=0.0 : je veux une transcription reproductible, pas de la créativité. Une température plus haute laisse le modèle halluciner du texte plausible mais faux, surtout sur du silence ou du bruit de fond. À 0, t'as le chemin le plus probable, stable d'un essai à l'autre. Le prix à payer, par contre : par défaut faster-whisper accepte une liste de températures et remonte l'échelle quand le décodage échoue à ses seuils. Passer un scalaire 0.0 désactive ce filet. Reproductible, mais plus de deuxième chance sur un clip pourri. C'est un arbitrage, pas un réglage gratuit.

word_timestamps=False : inutile pour de la dictée, et ça évite le passage d'alignement.

condition_on_previous_text=True : celui-là, je vais me le faire reprocher, fa que autant le sortir moi-même. Réinjecter le texte déjà décodé dans le contexte, c'est le classique amplificateur de boucles de répétition de Whisper. Ce qui le rend tenable ici, c'est le format : un clip push-to-talk, c'est un appel transcribe() isolé de quelques secondes, et rien n'est reporté d'un clip au suivant. Le contexte reste à l'intérieur d'une même dictée, où il aide plus qu'il nuit. Sur des fichiers longs, je le laisserais pas à True.

vad_filter=True : le VAD (détecteur d'activité vocale) coupe les segments de silence avant de les envoyer au modèle. Le silence, c'est justement là-dessus que Whisper hallucine le plus, des bouts de phrase qui sortent de nulle part. Filtrer le silence en amont règle le problème à la source plutôt que de patcher le résultat après coup.

hotwords, le réglage que tout le monde sous-estime

Tania Dictée embarque une liste de termes par défaut, en dur dans le code (DEFAULT_GLOSSARY_TERMS) : Tania Dictée, VS Code, Cursor, Claude Code, ChatGPT, GitHub, Whisper, Stripe, Notion, Python, Node.js, React, Tailwind, Docker, push-to-talk, Québec. Un fichier glossary.txt optionnel (une ligne par terme) vient s'ajouter à cette liste sans la remplacer : c'est là que tu mets tes noms de projets, de collègues, de produits maison.

Ce glossaire est passé DEUX fois au modèle :

glossary_terms = load_glossary_terms(cfg.glossary_path)
prompt = build_initial_prompt(glossary_terms)
hotwords_str = " ".join(glossary_terms) if glossary_terms else None

Une fois fondu dans l'initial_prompt, une fois tel quel dans hotwords. La différence est plus subtile que ce que je croyais au départ. Dans faster-whisper, hotwords ne biaise pas le décodeur à chaque token : la chaîne est encodée et posée en tête du contexte de conditionnement (le slot sot_prev, celui du texte précédent), avant les tokens de l'initial_prompt. C'est get_prompt() dans transcribe.py. Même canal que le prompt, mais tes termes se retrouvent en position privilégiée au lieu d'être noyés au milieu d'une longue consigne. Deux conséquences pratiques : ce slot est borné (autour de 224 tokens), donc un glossaire kilométrique se fait tronquer sans prévenir, et hotwords est ignoré si tu passes un prefix. Sur les noms propres rares, c'est le réglage qui m'a donné l'impression du plus gros gain. Impression, pas mesure : j'ai pas de banc d'essai à te montrer.

Attention à la version : hotwords n'existe pas dans les vieilles faster-whisper. Sur une version trop ancienne, tu vas manger un TypeError: transcribe() got an unexpected keyword argument 'hotwords'.

Le prompt qui dit au modèle de ne pas traduire

L'initial_prompt est en français, et une bonne partie de son contenu sert à une seule chose : empêcher Whisper de franciser poliment le jargon dev. Extrait réel :

Si un mot est dit en anglais, le GARDER EN ANGLAIS, ne jamais le traduire en français :
'build' reste 'build' (pas 'construire'), 'ship' reste 'ship' (pas 'expédier'),
'run' reste 'run', 'commit' reste 'commit', 'push' reste 'push', 'merge' reste 'merge'.

Laissé à lui-même, Whisper a tendance à "corriger" le franglais vers du français propre. Sauf que si tu dis "je vais ship-le", tu veux "ship", pas "expédier". Le prompt lui interdit aussi d'adoucir ou de reformuler, parce que ça, aussi, Whisper le fait naturellement.

Le filet regex, sale mais honnête

Même avec tout ça, il reste des ratés récurrents et prévisibles. Donc après la transcription, il y a une couche de remplacements regex, SOFT_REPLACEMENTS dans le code (une trentaine d'entrées, en voici six) :

SOFT_REPLACEMENTS = [
    (r"\bpaillette\s*on\b", "Python"),
    (r"\bno\s*jeasse\b", "Node.js"),
    (r"\bdock\s*heure\b", "Docker"),
    (r"\bouisp(er|eur)?\b", "Whisper"),
    (r"\bvs codes?\b", "VS Code"),
    (r"\bia\b", "IA"),
]

def apply_soft_replacements(text: str) -> str:
    cleaned = (text or "").strip()
    for pattern, replacement in SOFT_REPLACEMENTS:
        cleaned = re.sub(pattern, replacement, cleaned, flags=re.IGNORECASE)
    return re.sub(r"\s+", " ", cleaned).strip()

Le flags=re.IGNORECASE est pas décoratif : Whisper te ressort le même raté en majuscule ou en minuscule selon la ponctuation autour.

"paillette on" pour Python, "no jeasse" pour Node.js, "dock heure" pour Docker. C'est pas élégant, c'est du sparadrap. Mais quand un modèle se plante toujours de la même façon sur les mêmes mots, une regex déterministe bat un plus gros modèle, pour zéro coût de calcul. Je l'assume tel quel.

Le vrai risque de cette couche, c'est le faux positif : une regex trop large qui réécrit un mot légitime. J'en ai une qui transforme "équiper" en "ship", parce que Whisper me traduisait systématiquement "ship" par "équiper". Le jour où je vais dicter pour vrai le verbe équiper, elle va me mordre. C'est pour ça que chaque motif est ancré sur un raté que j'ai réellement observé, jamais sur un raté hypothétique, et que la couche entière se coupe d'un flag (--cleanup-mode raw rend la sortie brute de Whisper).

Si t'as une meilleure façon de gérer des ratés récurrents et prévisibles sans repartir sur un modèle plus lourd, dis-le en commentaire, je prends.

Un détail Windows qui fait perdre une soirée

Sur Windows, la console encode par défaut d'une façon qui transforme "Tania Dictée" en mojibake dans les logs et dans l'exe packagé. Le fix tient en quelques lignes, tout en haut du script :

if sys.platform == "win32":
    try:
        sys.stdout.reconfigure(encoding="utf-8", errors="replace")
    except Exception:
        pass
    try:
        sys.stderr.reconfigure(encoding="utf-8", errors="replace")
    except Exception:
        pass

Les try sont pas de la paranoïa décorative : une fois l'app packagée en exe sans console (PyInstaller --noconsole), sys.stdout vaut None et le .reconfigure() nu te sort un AttributeError au démarrage.

Petit, bête, et ça sent le vécu d'avoir fixé des accents cassés à 23h un mardi.

C'est du build-in-public honnête : Tania Dictée est à 0 vente pour l'instant, et le code est ouvert en MIT sur GitHub si tu veux fouiller ou reprendre des bouts. T'as un pipeline speech-to-text local qui tourne, c'est quoi ton filet à toi pour les ratés récurrents ?

3 semaines de build-in-public plus tard : 4 abonnés, 0 vente, et le bug de hotkey qui m'a pris 2 soirs

elboKazQC — Mon, 06 Jul 2026 16:20:40 +0000

Ça fait trois semaines que je publie ici en mode transparent sur Tania Dictée, mon outil de dictée vocale FR-Québec. Le premier article avait un titre franc : 0 inscrit, 3 jours pour valider l'idée. Il a eu une réaction. Les deux suivants, sur le code-switching et la vie privée, zéro.

Alors on continue avec les vrais chiffres, plus un bug qui m'a fait perdre deux soirées et qui vaut la peine d'être raconté.

Les chiffres, sans les habiller

Sur dev.to : 3 articles publiés, 4 abonnés au blog. Les 4 sont arrivés en silence, aucun commentaire, aucune réaction associée. Moins de 25 vues par article. Une seule réaction au total, sur le tout premier post.

Sur X (@TaniaDictee) : 1 abonné. Sur Hacker News, mon karma est à 1. Le repo GitHub a 0 star.

Zéro vente. Le produit est à 9$ CAD sur Gumroad depuis des semaines, personne n'a encore acheté.

Je pourrais dramatiser ou je pourrais dire que c'est normal pour un projet solo à budget zéro. La vérité est entre les deux : c'est petit, mais dev.to est le seul endroit où quelque chose bouge, même faiblement. Alors j'y mets plus d'énergie plutôt que de disperser sur cinq canaux qui ne répondent pas.

Le bug qui m'a pris deux soirs

Tania Dictée fonctionne en push-to-talk : tu tiens F6, tu parles, tu relâches, ça transcrit et ça colle le texte où t'as le curseur. Simple sur papier. Sauf que la détection du relâchement de touche sur Windows n'est pas aussi fiable qu'on pense.

Le module keyboard en Python expose deux événements : add_hotkey pour la pression, on_release_key pour le relâchement. Mon premier réflexe a été de démarrer l'enregistrement sur la pression et de l'arrêter sur le relâchement. Ça marchait... la plupart du temps.

Le problème : si tu relâches F6 pendant qu'une autre fenêtre a le focus, ou si Windows avale l'événement à cause d'un conflit avec un autre hook clavier actif (j'en avais un autre qui tournait pour une raison complètement différente), l'événement de relâchement ne se déclenche jamais. Résultat : Tania reste convaincue que tu parles encore. Elle enregistre en boucle jusqu'à ce que tu réappuies sur F6, ce qui bascule l'état dans le mauvais sens et fige l'app dans un état bizarre.

La vraie source du bug, ce n'était pas mon code d'enregistrement, c'était une hypothèse fausse : je pensais qu'un événement clavier Windows me serait toujours livré. Dans mon cas il ne l'était pas, surtout avec plusieurs hooks actifs en parallèle.

La solution qui a fini par tenir : au lieu de dépendre uniquement de l'événement on_release_key, j'ai ajouté un threading.Timer qui revérifie activement l'état des touches à intervalle court avec keyboard.is_pressed(). Si aucune des touches du hotkey n'est physiquement pressée, on arrête l'enregistrement, peu importe si l'événement de relâchement est arrivé ou pas.

def _schedule_stop_if_hotkey_released(self):
    # debounce configurable, pas un chiffre magique code en dur
    delay = max(0.0, float(self.cfg.release_debounce_ms) / 1000.0)
    timer = threading.Timer(delay, self._stop_if_hotkey_inactive)
    timer.daemon = True
    timer.start()

def _stop_if_hotkey_inactive(self):
    # on ne fait pas confiance a l'evenement de relachement :
    # on verifie l'etat physique reel des touches
    if any(keyboard.is_pressed(key) for key in self.hotkey_keys):
        return
    self.stop_recording()

En gros : ne fais pas confiance à l'événement, vérifie l'état réel. Ça semble évident écrit comme ça, mais sur le coup j'ai passé deux soirées à ajouter des logs, suspecter le driver du micro, suspecter faster-whisper, avant de réaliser que le vrai coupable était une hypothèse sur le comportement du clavier que je n'avais jamais vérifiée.

Il y a un deuxième détail qui a mordu en même temps : add_hotkey avec suppress=True empêche la touche d'atteindre les autres apps (utile pour que F6 ne tape pas un caractère parasite dans ton éditeur), mais ça change aussi comment Windows route certains événements de relâchement selon le contexte de focus. Ce n'est documenté nulle part de façon limpide, il a fallu tester à la main pour comprendre.

Ce que ça change concrètement

Depuis ce fix, Tania tourne chez moi tous les jours sans ce comportement fantôme. C'est le genre de bug qu'un utilisateur externe aurait rencontré dans sa première semaine et qui aurait tué la confiance direct. Bonne nouvelle : c'est réglé avant que qui que ce soit d'autre que moi ne l'ait vécu, parce que pour l'instant je suis mon seul utilisateur.

C'est aussi une leçon plus large sur le solo dev : quand t'es le seul testeur, les bugs les plus vicieux sont ceux qui dépendent du contexte système (autres apps ouvertes, autres hooks actifs, focus de fenêtre) et que tu ne reproduis pas facilement en isolation. Le fix a fini par être plus robuste que l'approche initiale précisément parce qu'il ne fait plus confiance à un seul signal.

Au fond, c'est pour ça que je bâtis ce truc : si tu dictes en français québécois une bonne partie de ta journée et que l'idée d'envoyer ta voix dans le cloud te dérange, c'est exactement l'outil que j'aurais voulu trouver au lieu de le coder.

Où on en est

Le code reste ouvert sous licence MIT sur github.com/elboKazQC/tania-dictee si le bug ou le hotkey handling vous intéresse en détail. Toujours 0 star, ça ne me dérange pas de le dire.

La suite : je continue de nourrir dev.to en priorité puisque c'est le seul canal où il se passe quelque chose, même petit. Prochain post, probablement le premier vrai benchmark de précision (WER) que j'ai promis dans les articles précédents et que je n'ai toujours pas publié. Il est temps.

Si vous avez déjà chassé un bug qui se cachait derrière une hypothèse fausse sur un événement système (clavier, réseau, fichier), ça m'intéresse de l'entendre en commentaire.

Dicter du code confidentiel : pourquoi j'ai arrêté d'envoyer ma voix dans le cloud

elboKazQC — Tue, 30 Jun 2026 14:22:35 +0000

Je suis consultant IA. La moitié de mes journées, je pilote des modèles de langage pour des clients. Je dicte beaucoup : des prompts à Claude Code, des notes de conception, des noms de variables, des bouts de logique métier qui ne sont pas encore publics.

Pendant un bon moment, j'ai utilisé une solution de dictée cloud. Commode. Ça marche bien. Et puis un jour j'ai réalisé ce qui part réellement sur leurs serveurs quand j'appuie sur le bouton d'enregistrement.

Ce que ta voix contient vraiment

Quand tu dictes un prompt à un outil de code ou à un agent IA, t'as pas l'impression de transmettre quelque chose de sensible. T'es dans ta bulle, t'es chez toi, c'est juste toi qui parles à un micro.

Mais dans ce flux audio, il y a le nom du produit client qui n'est pas encore annoncé. Il y a la logique d'un flux de données propriétaire. Il y a les noms des tables, des endpoints, des règles d'affaires. Il y a les acronymes internes qui permettent à n'importe qui de chercher sur Google et de comprendre dans quelle industrie tu travailles.

Pour les outils de dictée cloud comme Wispr Flow, Otter ou les fonctions vocales intégrées à divers services, cet audio transite par des serveurs distants. Ce qui arrive ensuite, c'est leur affaire : rétention du contenu pour amélioration du modèle, accès interne potentiel, politiques qui changent silencieusement d'une mise à jour des CGU à l'autre.

Sous NDA, t'es responsable de ça. Pas eux.

Ce que "100 % local" veut dire en pratique

La promesse d'une solution locale, c'est que l'audio ne quitte jamais ton disque. Point. Pas de requête réseau, pas de token envoyé quelque part, pas de métadonnée. Le modèle Whisper tourne directement sur ta machine.

Il y a un test simple pour le vérifier : tu coupes ta connexion Wi-Fi, tu dictes, tu lâches le bouton. Si la transcription arrive, c'est 100 % local. Sinon, quelque chose part quelque part.

Tu peux aussi ouvrir un moniteur réseau (Little Snitch, Glasswire, ou simplement Wireshark si t'as le goût de souffrir un peu) pendant une session de dictée, et regarder si des connexions sortantes s'ouvrent. Avec une solution vraiment locale, t'as rien. C'est le silence réseau qui prouve la confidentialité, pas la politique de vie privée du vendor.

Le comment technique, sans faire semblant que c'est compliqué

Le moteur sous le capot, c'est faster-whisper, une implémentation optimisée de Whisper par Systran. Plus rapide que l'originale d'OpenAI sur CPU, et elle tourne proprement sur Windows sans configuration ésotérique.

La première fois que tu l'actives, le modèle (quelques centaines de mégaoctets selon la taille choisie) se télécharge une fois. Après ça, plus besoin de connexion. Si tu veux voir à quoi ressemble un appel de base :

from faster_whisper import WhisperModel

modele = WhisperModel("small", device="cpu", compute_type="int8")
segments, info = modele.transcribe(
    "audio.wav",
    language="fr",
    initial_prompt="useState, Stripe, fa que, pis, API REST, webhook"
)
for segment in segments:
    print(segment.text)

Le paramètre initial_prompt est la pièce souvent oubliée. Il force le modèle à s'attendre à certains mots, ce qui améliore la transcription des termes techniques et des expressions québécoises. Tu peux y mettre des noms de variables, des mots de ton domaine, des expressions typiques de ton projet. La limite est d'environ 224 tokens, pis ça se remplit vite, fa que sois sélectif.

Le compromis honnête

Je vais pas te vendre ça comme une solution parfaite, parce que c'est pas le cas.

L'accent québécois demeure plus difficile pour Whisper que le français de France standard. Sur un texte technique avec du vocabulaire précis, le glossaire dans initial_prompt aide vraiment. Sur une phrase purement conversationnelle avec des expressions régionales denses, attends-toi à plus de corrections manuelles qu'en FR standard. C'est la réalité. Je publie pas de chiffres de taux d'erreur parce que j'ai pas encore fait le benchmark formel, pis je vais pas inventer un nombre.

C'est aussi Windows uniquement pour l'instant. Mac et Linux, c'est pas là. Et l'interface reste en phase alpha : fonctionnelle, mais elle a pas encore le polish d'un produit mature.

Le setup de base demande quelques étapes techniques si tu pars de zéro. C'est précisément pourquoi j'ai fini par empaqueter tout ça.

Pourquoi j'ai packagé ça

J'avais déjà monté ce pipeline pour moi-même. Faster-whisper installé, un petit script Python, push-to-talk sur F6 (maintiens pour parler, relâche pour transcrire), intégration au presse-papier pour coller dans n'importe quelle app. Ça marchait.

J'ai montré ça à quelques personnes. La réaction habituelle : "c'est cool, mais je vais pas m'asseoir pour installer tout ça."

Fa que j'ai fait l'installeur. 63 MB. Tu lance, t'installes, t'appuies sur F6. Le code est ouvert sous licence MIT sur github.com/elboKazQC/tania-dictee si tu veux voir exactement ce qui tourne sur ta machine (pis c'est là que la transparence privacy commence vraiment : open source, pas juste une promesse dans une FAQ).

La version packagée est disponible à 9 $ CAD, achat unique, sur Gumroad. Pas d'abonnement.

Zéro utilisateur externe à date. Je suis en mode build-in-public, pis je te parle depuis le début du tunnel, pas depuis l'autre bout.

Si le sujet t'intéresse, la waitlist est ici : elbokazqc.github.io/tania-dictee

La dictée vocale en français québécois, c'est pas un gadget : c'est un problème de code-switching

elboKazQC — Fri, 26 Jun 2026 18:17:19 +0000

J'utilise la dictée vocale tous les jours depuis six mois. Pas pour taper moins vite. Pour penser plus vite quand je vibe-code avec Claude Code et Cursor.

Pis j'ai fini par construire mon propre outil parce que les outils existants me tapaient sur les nerfs d'une façon très précise.

Le problème réel

Quand tu travailles en tech au Québec, tes phrases ressemblent à ça :

"OK fa que je fais un useState pour le component pis je passe le handler en props"

Ça, c'est une phrase normale. Personne en tech QC ne parle autrement. Pas parce qu'on est négligents avec la langue. Parce que le vocabulaire technique vient de l'anglais et qu'on le soude naturellement au français au fil de la pensée.

Ça s'appelle le code-switching. Et c'est là que la plupart des outils de dictée craquent.

Ce que les outils mainstream font mal

Dragon NaturallySpeaking

Dragon, c'est le vieux standard. Médical, juridique, corporate. Ça coûte environ 500$ en une shot. C'est lourd à installer et à entraîner. Et sa gestion du français québécois avec des termes tech intercalés... c'est en gros zéro.

"useState" devient "usé état". "Fa que" devient "faque" parfois, "fake" d'autres fois. C'est aléatoire. T'as intérêt à corriger après chaque phrase.

Wispr Flow

Wispr Flow est plus moderne. UX propre, cross-platform, et leur gestion du français s'est améliorée. Leur plan Pro coûte 15$/mois, soit environ 144$/an.

Mais il y a un problème structurel que leur propre doc admet : la détection de langue se fait par session, pas par mot.

Autrement dit : Wispr détecte la langue une fois au début de la session. Si tu commences en français, il reste en mode français jusqu'à la fin. Les mots anglais qui arrivent dans la phrase, il tente de les translittérer en français. "Handler" peut devenir "andler" ou "ender", "props" survit parfois, parfois pas. C'est variable.

Pour une phrase de temps en temps avec un mot anglais, ça passe. Pour un vibe-coder québécois qui switch constamment dans la même phrase, ça ne passe pas.

Pourquoi c'est un vrai problème, pas un détail

La dictée vocale utile, c'est quand tu peux parler aussi vite que tu penses et que la transcription suit. Le moment où tu dois ralentir pour articuler différemment, ou corriger constamment après, tu perds exactement l'avantage pour lequel t'as adopté l'outil.

J'ai fini par faire le calcul : le temps de correction de franglais = le temps que je sauvais à dicter. Retour à la case départ.

Fa que j'ai décidé de régler ça directement.

Ce que j'ai construit

Tania Dictée est un outil de dictée vocale Windows, 100% local. Tu maintiens F6, tu parles, tu relâches. Le texte se colle dans n'importe quelle app active : VS Code, Cursor, Claude Code, Gmail, peu importe.

La différence principale par rapport aux outils existants :

Traitement par phrase, pas par session. Chaque phrase passe à travers Whisper (via faster-whisper) avec un glossaire FR-QC intégré d'office. "useState", "handler", "fa que", "pis", "Supabase", "Cursor", tout ça est dans le glossaire. Le modèle sait que c'est du franglais québécois. Il n'essaie pas de choisir une langue et de tout forcer dedans.

100% local, zéro cloud. Ce que tu dictes reste sur ton PC. Pas de compte à créer. Pas de tokens qui partent sur un serveur externe. Pour un consultant sous NDA ou un dev avec du code proprio, ça compte.

Windows-first, sans friction. Installeur d'environ 63 MB. Pas de Python à installer, pas de droits admin. Tu dézippe, tu lances, ça marche.

Prix : 9$ CAD une seule fois. Pas d'abonnement. Un achat, c'est fini.

Le code est open source MIT sur GitHub (github.com/elboKazQC/tania-dictee).

Ce que je ne prétends pas (build-in-public oblige)

Je construis en transparent, alors voici ce qui est vrai à date :

Zéro utilisateur externe. C'est moi qui l'utilise tous les jours. La première vraie validation externe, c'est ce que je cherche en ce moment.

Pas de version Mac ou Linux. Windows only, point.

L'UX est en alpha. Il n'y a pas encore de paramètres graphiques élaborés, pas d'onboarding fancy.

Le benchmark de précision (protocole WER contre Whisper vanilla et Dragon) n'est pas encore publié. Le protocole est prêt et les mesures arrivent. Je ne vais pas inventer des chiffres d'ici là.

Pourquoi ça peut quand même marcher

La niche est petite mais réelle : développeurs et consultants qui travaillent en franglais québécois, qui vibe-codent, qui ont du code proprio à protéger. Les outils qui existent ne sont pas conçus pour eux.

La preuve du concept existe : moi. Six mois d'usage quotidien, ça m'a économisé du temps réel. Si ça marche pour moi, il y a probablement d'autres personnes avec le même problème.

Si t'as déjà pesté contre Dragon ou Wispr Flow quand tu dictes du franglais tech, j'aimerais t'entendre. Qu'est-ce qui t'a le plus agacé ? Est-ce que c'était le code-switching, la précision globale, ou autre chose ?

La waitlist est à https://elbokazqc.github.io/tania-dictee. 9$ CAD, achat unique, si jamais tu veux soutenir le projet et être parmi les premiers testeurs externes.

-- Vincent

Build-in-public : 0 inscrit, 3 jours pour valider mon outil de dictée vocale FR/QC

elboKazQC — Wed, 17 Jun 2026 17:12:50 +0000

Je lance un compte à rebours public.

Point de contrôle : 20 juin 2026.
Cible : 25 inscrits à la waitlist.
En-dessous, je repense le plan.

Voilà où on en est.

C'est quoi Tania Dictée

Un outil de dictée vocale Windows, 100 % local (Whisper via faster-whisper : modèle small sur CPU, large-v3 sur GPU), optimisé pour le français québécois et le franglais. Tu maintiens F6, tu parles, tu relâches, ton texte apparaît dans n'importe quelle app active.

Pourquoi j'ai bâti ça : j'ai essayé Dragon NaturallySpeaking et Wispr Flow. Aucun des deux ne gère le code-switching FR/EN dans la même phrase. Et Wispr Flow à 144 $/an pour transcrire mon code à moitié de travers, c'est non.

Résultat : j'ai bâti le mien. Ça fait 6 mois que je l'utilise tous les jours pour vibe coder avec Claude Code et Cursor.

L'état du produit (honnête)

Installeur Windows (63 Mo, pas de Python, pas de droits admin requis)
Zéro cloud, zéro compte, zéro abonnement
Glossaire FR-QC inclus (Cursor, Supabase, useState, "pis", "fa que"...)
Prix : 9 $ CAD sur Gumroad

Ce qui manque encore : version Mac, UX plus polie, benchmark WER public.

Pourquoi je publie ça maintenant

Le produit marche pour moi, mais j'ai 0 donnée sur s'il aide quelqu'un d'autre.

Le seul moyen de le savoir : aller chercher des early adopters, leur faire tester, voir si ça colle.

Le plan des 3 prochains jours

Posts X @TaniaDictee quotidiens (build-in-public transparent)
Découvrabilité GitHub (annuaires d'outils Whisper)
Point de contrôle public le 20 juin

Si tu es dev québécois, consultant qui dicte beaucoup, ou juste curieux d'un outil Whisper local sur Windows : waitlist ici ou achat direct 9 $ CAD.

Pas de spam. Juste les updates concrètes.

-- Vincent