La dictée vocale dans GitHub : comment ça marche vraiment

GitHub n'a pas de dictée vocale. C'est votre raccourci qui fait le travail.

Laissez-moi répondre à la question que les gens tapent vraiment dans Google. Non, GitHub n'a pas de dictée vocale intégrée. Il n'y a pas de dictée native dans l'éditeur d'issues, le formulaire de PR, le panneau de revue, les Discussions ni le wiki. Ce sont des zones de texte web standard. Pour y dicter, la voix doit venir d'ailleurs : votre système d'exploitation, votre navigateur ou une application tierce.

GitHub ne bloque jamais la dictée. Il n'en fournit simplement aucune lui-même. Vos choix se résument donc à peu près à trois. Votre système d'exploitation a une dictée intégrée — la Saisie vocale de Windows avec Win+H, ou la Dictée de macOS. Une extension de navigateur comme Voice In peut écrire dans un onglet Chrome ou Edge. Ou bien une application de bureau à raccourci global comme Whisper dicte dans n'importe quel champ de n'importe quelle application, navigateur ou non.

La différence entre ces trois options, c'est la portée. La dictée de l'OS est gratuite et fonctionne sur une plateforme à la fois, avec une qualité variable. Une extension de navigateur ne vit qu'à l'intérieur de l'onglet — elle ne peut pas vous suivre dans votre IDE ou dans le GitHub CLI, et elle s'exécute dans le cloud. Une application de bureau comme Whisper n'est pas liée à un onglet ; comme elle fonctionne au niveau de l'OS, elle dicte dans GitHub que vous soyez sur Chrome, Firefox, Safari ou Edge, et aussi dans un message de commit dans GitHub Desktop.

Ce que vous pouvez vraiment dicter (et la seule chose que vous ne pouvez pas)

Voici la limite que je ne vous laisserai pas franchir par accident. Whisper dicte ce que vous écrivez autour de votre code. Il n'écrira pas le code lui-même.

Et ça couvre l'essentiel de la journée de saisie d'un développeur, honnêtement. Les rapports d'issue. Les descriptions de pull request. Les notes de revue de code. Les réponses dans les Discussions. Les README et la doc en markdown. La prose qui explique le changement, pas le changement. Quand vous dictez un paragraphe expliquant pourquoi une migration est risquée, Whisper s'en sort très bien. Quand vous essayez de dicter la migration, vous allez passer un mauvais après-midi.

La raison est simple. Le code parlé ne survit pas au voyage. Les noms de fonctions, le JSON, snake_case contre camelCase, un drapeau kubectl, un chemin d'API — tout ça ressort en anglais approximatif et demande une correction manuelle. Un modèle vocal entend « user underscore I D » et écrit « user ID », et vous voilà en train de corriger. Alors dictez la phrase qui dit « cette PR corrige le contrôle de nullité dans le middleware d'authentification », puis tapez l'identifiant réel. De toute façon, la plupart des corps d'issue et de PR sont à 80 % d'explication et à 20 % d'extrait de code. Dictez les 80, tapez les 20.

Appuyez sur un raccourci, parlez, obtenez du texte dans le champ qui a le focus

Le mécanisme est exactement celui que vous utiliseriez dans n'importe quelle autre application, et c'est tout l'intérêt. Cliquez dans le champ GitHub à remplir. Maintenez le raccourci. Parlez. Relâchez. La transcription apparaît à l'endroit du curseur.

Le raccourci par défaut est Ctrl+Space sur Windows et Command+Option sur macOS. Les deux fonctionnent en push-to-talk : maintenez pendant que vous parlez, relâchez pour arrêter. Vous pouvez les changer dans les paramètres s'ils entrent en conflit avec autre chose — et si vous avez déjà bataillé avec un conflit de raccourci, vous savez pourquoi ce réglage a gagné sa place (j'y reviens plus bas).

Un détail honnête sur la portée. Whisper colle dans le seul champ qui a le focus, un à la fois. Il ne remplit pas tout un formulaire d'issue GitHub d'un seul souffle. Le déroulé pour une nouvelle issue est donc : cliquez sur le titre, dictez-le, cliquez sur le corps, dictez-le. Deux champs, deux pressions. Ça ressemble moins à de la magie qu'à un dactylo rapide qui ne touche jamais le clavier. C'est le bon modèle mental.

L'appli complète, en direct

Ceci est la vraie application, qui tourne ici même — pas une capture d'écran. Fouinez. Les paramètres, le sélecteur de raccourci, le choix des modèles, tout est bien réel.

Deux ou trois choses bonnes à savoir pendant que vous cliquez. Il n'y a pas d'onglet propre à GitHub ni de « mode GitHub », parce qu'il n'y en a pas besoin. Pour Whisper, une description de PR GitHub est un champ de texte comme un autre. La même configuration qui dicte dans l'éditeur d'issues dicte dans votre e-mail et dans votre IDE. Vous le configurez une seule fois. La portée, c'est ça, la fonctionnalité.

Là où ça paie : issues, descriptions de PR, revues, discussions

Le vrai bénéfice, c'est l'écriture ennuyeuse et répétitive — celle que vous remettez à plus tard parce que la taper est une corvée.

Issues. Un bon rapport de bug, c'est surtout du récit : ce que vous avez fait, ce que vous attendiez, ce qui s'est passé à la place. C'est le terrain de prédilection de la dictée. Décrivez les étapes de reproduction comme vous les expliqueriez à un collègue à côté de vous, puis collez la trace de la pile à la main.

Descriptions de pull request. Le corps de PR que tout le monde évite d'écrire parce que le diff « parle de lui-même » (ce n'est pas le cas). Dictez le pourquoi — le contexte dont le relecteur a besoin — et laissez le diff dire le quoi.

Revues de code. Les commentaires de revue, c'est là que le ton compte et là où les gens en disent trop peu. Dire une note de revue à voix haute donne souvent quelque chose de plus humain et de plus complet que de la taper entre deux réunions. Vous écrirez « ça marche, mais ça va casser quand la liste sera vide » au lieu d'un simple « cas limite ? ».

Discussions et docs. De la prose au long cours, c'est exactement ce pour quoi la voix est douée et exactement ce que personne n'a envie de taper. Une intro de README, une réponse dans les Discussions, un guide de migration — dictez le brouillon, nettoyez le markdown après. La même logique vaut pour dicter dans des tickets Jira et d'autres outils de suivi ; GitHub n'est qu'un champ de plus dans la pile.

Nettoyez la dictée automatiquement

La dictée brute a ses scories. Les « euh », les « tu vois », la phrase commencée deux fois. Whisper propose une passe de nettoyage par IA facultative qui corrige les mots de remplissage, la ponctuation et la casse, pour que l'issue ou la PR se lise comme si vous l'aviez écrite avec soin.

Il y en a deux variantes. Dans la formule locale gratuite, le nettoyage tourne sur votre machine via Ollama. En Pro, vous apportez votre propre clé OpenAI et le nettoyage tourne dans le cloud, avec des réponses web disponibles en prime. Dans les deux cas, c'est facultatif — désactivez-le et vous obtenez la transcription brute. Je le laisse activé pour les descriptions de PR et désactivé pour les commentaires rapides, parce qu'un commentaire rapide n'a pas besoin d'édition et qu'une description de PR, si.

La seule chose que le nettoyage ne fera pas, c'est sauver du code parlé. Il peaufine l'anglais. Il ne sait pas que vous vouliez dire getUserById quand vous avez dit « get user by I D ». Continuez à dicter la prose ; continuez à taper les identifiants.

Hors ligne et privé : rien ne quitte votre machine en mode local

Si vous dictez des issues et des PR à propos d'un code qui n'est pas public, l'endroit où va l'audio compte. Dans le mode local de Whisper, la transcription se fait entièrement sur votre machine. Rien de ce que vous dites n'est envoyé à un service cloud. Aucune connexion internet n'est nécessaire pendant la transcription — le seul moment où vous passez en ligne, c'est pour le téléchargement unique du modèle, qui va d'environ 140 Mo à 3 Go selon le modèle que vous choisissez.

C'est le seul endroit où je vais vous donner un vrai avis. La dictée tout-cloud est un désastre de confidentialité qui n'attend qu'une transcription. J'ai un jour vu une équipe interne accumuler une facture cloud à cinq chiffres en un seul trimestre parce qu'un prototype de dictée maison envoyait chaque énoncé à une API — et le pire n'était pas la facture, c'était que les notes vocales de tout le monde sur un produit non sorti vivaient désormais dans les journaux d'un fournisseur. Le tableur des salaires de votre patron, le problème de sécurité que vous signalez en privé, l'architecture propriétaire que vous décrivez dans une PR — rien de tout ça ne devrait quitter votre ordinateur portable juste parce que vous vouliez taper un paragraphe avec votre voix. Votre machine a déjà un micro et un processeur. Pour un paragraphe, elle n'a pas besoin d'un serveur dans la boucle. Si votre outil ne tourne que dans le cloud, c'est la première chose que je corrigerais.

Ce pour quoi il n'est pas fait (écrire du code)

Vous êtes peut-être venu chercher un moyen d'écrire du code à la voix, ou vous vous souvenez de « Hey, GitHub! » et vous vous demandez où c'est passé. Deux réponses honnêtes.

« Hey, GitHub! » et GitHub Copilot Voice étaient une préversion technique de GitHub Next. GitHub a abandonné la préversion en 2024. Ce n'est jamais devenu un produit ; les enseignements ont été intégrés à l'extension VS Code Speech. Donc si un article de blog vous dit aujourd'hui d'activer « Hey GitHub », il a deux ans de retard.

La voie de la voix pour le code existe toujours — elle vit simplement dans votre éditeur et votre terminal, pas sur github.com. L'extension VS Code Speech (parfois appelée « Hey Code ») vous laisse parler à l'éditeur et à Copilot Chat pour le code et les commandes. Et GitHub Copilot CLI a récemment ajouté une entrée vocale locale qui pilote l'agent Copilot dans le terminal. Ces deux outils servent à piloter du code et un agent IA. Aucun ne dicte de la prose dans une issue GitHub dans votre navigateur. C'est une voie différente, et c'est celle que Whisper occupe : l'écriture autour du code.

Quand laisser tomber Whisper pour votre flux de travail GitHub

Je préfère que vous utilisiez le bon outil plutôt que celui que je fabrique. Voici donc quand laisser tomber Whisper.

Si ce que vous voulez vraiment, c'est piloter Copilot ou votre éditeur à la voix — « corrige cette fonction », « lance les tests », « explique ce bloc » — c'est la voie code/agent, pas la prose. Utilisez plutôt l'extension VS Code Speech ou l'entrée vocale de GitHub Copilot CLI. Elles parlent à la machine ; Whisper écrit les mots qu'un humain lit.

Si vous ne dictez jamais que l'occasionnel commentaire d'une ligne, votre système d'exploitation le fait déjà gratuitement. Appuyez sur Win+H sous Windows ou activez la Dictée sur macOS, et vous pouvez déposer une phrase rapide dans un champ GitHub sans rien installer. Whisper commence à mériter sa place quand vous écrivez de vrais paragraphes à travers de nombreuses applications, que vous voulez qu'il fonctionne hors ligne, ou que vous voulez un seul raccourci partout plutôt qu'une fonction de l'OS qui ne couvre que certains champs. En dessous de ce seuil, l'option intégrée fait très bien l'affaire, et je ne vais pas prétendre le contraire.

Local gratuit, avec Pro pour le cloud

La chaîne locale — transcription, nettoyage par IA sur l'appareil, raccourci, tout ce qu'il faut pour dicter dans GitHub — est gratuite pour les utilisateurs connectés, et aucune carte n'est requise à l'inscription. Vous l'installez, vous vous connectez et vous commencez à dicter.

Whisper Pro ajoute la surface cloud : transcription cloud OpenAI, nettoyage IA dans le cloud avec votre propre clé, et réponses web, avec un court essai pour cette formule. Pour dicter des issues et des PR, la formule locale gratuite couvre tout le travail. Les chiffres de Pro sont sur la page tarifs ; je ne vais pas vous les balancer en plein paragraphe.

Un dernier mot sur ce raccourci

Un mot sur la raison pour laquelle le raccourci est personnalisable, puisque ça relie le tout. La première version de Whisper déclenchait son arrêt d'enregistrement six fois par appui de touche sur certaines machines Windows — des événements de relâchement fantômes venant du framework de saisie, le genre de chose qui marche sur une installation propre et casse sur une vraie. Il a fallu un anti-rebond de 300 ms et plus de temps que je ne veux l'admettre pour le rendre fiable. J'ai appris sur la gestion des entrées sous Windows bien plus que je ne l'aurais jamais souhaité. La leçon est restée : c'est le raccourci qui doit s'adapter à votre machine, pas l'inverse. Cliquez dans le champ, maintenez la touche, parlez. Le code, vous le tapez toujours vous-même — et c'est, je crois, la version honnête du marché.