Dictée vocale pour développeurs : la voix pour la prose, le clavier pour le code

Mis à jour: 6 novembre 2026

Personne de sensé ne dicte une boucle for. En revanche, un développeur écrit chaque jour une quantité étonnante de français ordinaire : corps de commit, description de pull request, commentaires de revue, notes de conception, tickets Jira et longs prompts pour un assistant de code. C'est cette prose qui gagne à être dictée. Ce guide trie ce qu'il vaut mieux dire et ce qu'il faut continuer à taper, donne des phrases d'exemple pour chaque cas et dit franchement où la reconnaissance vocale déraille sur du texte technique.

Dire ou taper : une règle de tri simple

Le critère : si un collègue pouvait le lire à voix haute sans rien épeler, dictez-le. Si le texte contient des identifiants, une syntaxe bourrée de ponctuation ou des chaînes exactes, tapez-le. La plupart des tâches réelles mélangent les deux : vous dictez les phrases et vous tapez les quelques mots techniques qu'elles contiennent.

Tâche	Dicter ?	Pourquoi
Corps d'un message de commit	Oui	Deux ou trois phrases d'explication, surtout des mots courants
Ligne de titre du commit	Souvent	Courte ; ajoutez le nom du fichier ou de la fonction au clavier
Commentaire de revue de code	Oui	Expliquer un souci va plus vite à l'oral qu'au clavier
README et documentation	Oui, pour le texte	Blocs de code, commandes et chemins à taper à la main
Prompt pour un assistant de code	Oui	C'est sur le contexte long que la voix fait gagner le plus
Noms de variables, appels de fonction	Non	camelCase, tirets bas et parenthèses sortent de travers
Commandes shell, options, regex	Non	Un seul caractère faux change le sens
Chemins de fichiers et URL	Non	Barres obliques et points sont pénibles à dire et faciles à mal placer

Des messages de commit dictés

Lancez git commit sans l'option -m pour que votre éditeur s'ouvre. Tapez la ligne de titre, ou dictez-la puis corrigez les noms, laissez une ligne vide et dictez le corps. C'est justement la partie qu'on saute au clavier parce qu'elle paraît fastidieuse, et c'est celle qui expliquera la modification à la personne qui lancera git blame dans un an.

Un corps qui se dit en une quinzaine de secondes : « La boucle de nouvelle tentative abandonnait après le premier timeout parce que le compteur était remis à zéro dans le bloc catch point. J'ai déplacé la réinitialisation avant la boucle et ajouté un test qui simule deux timeouts d'affilée point. » Tapez ensuite le nom du fichier de test si vous voulez qu'il apparaisse.

Les conventions de commit varient d'une équipe à l'autre : beaucoup gardent un titre court à l'impératif, souvent en anglais même dans une équipe francophone, et coupent le corps à une largeur fixe. La dictée se moque de la largeur des lignes ; reformatez dans l'éditeur avant d'enregistrer. Si votre dépôt impose l'anglais, dictez en anglais : la plupart des outils gèrent les deux langues, à condition de choisir la bonne ou d'utiliser un outil qui reconnaît la langue tout seul.

Des commentaires de revue qui passent bien

Tapés, les commentaires de revue deviennent vite secs, et un commentaire sec se lit comme un reproche. Dictés, ils ressemblent davantage à ce que vous diriez au bureau d'à côté. Une structure qui marche : ce que vous avez remarqué, pourquoi c'est important, ce que vous proposez.

Exemple à dicter : « Cette requête part une fois par élément de la liste virgule donc une page avec deux cents commandes fait deux cents allers-retours vers la base point. On pourrait tout charger en un seul appel et regrouper en mémoire point d'interrogation. Je peux regarder ça avec toi si tu veux point. » Revenez ensuite dans le commentaire pour entourer le nom de la fonction de backticks au clavier.

Relisez chaque commentaire avant de le publier. Une erreur de reconnaissance coûte plus cher dans une revue que dans une note perso, parce que l'auteur du code doit deviner ce que vous vouliez dire.

Documentation, notes de conception et tickets

La documentation, c'est là que les développeurs ont le plus à dire et le moins de patience pour le taper. Essayez ce partage : dictez l'explication section par section (« à quoi sert ce service », « comment le lancer en local », « ce qui casse le plus souvent »), puis tapez chaque commande, variable d'environnement et bloc de code après coup. Un premier jet dicté en dix minutes puis relu vaut mieux qu'un README vide qui attend un après-midi libre.

Pour les tickets et rapports de bug, énoncez les étapes de reproduction comme des phrases numérotées : « Étape un virgule ouvrir la page des paramètres point. Étape deux virgule changer le fuseau horaire et enregistrer point. Attendu le tableau de bord mis à jour virgule il affiche toujours l'ancien fuseau point. » La numérotation se nettoie en quelques secondes, et les détails que vous auriez sautés au clavier sont bien là.

Les prompts pour assistants de code

Un assistant de code répond mieux quand il a du contexte : ce que vous cherchez à faire, ce que vous avez déjà essayé, ce qui ne doit pas changer. Taper tout cela prend du temps, alors on écrit une ligne et on reçoit une réponse générique. À l'oral, c'est moins d'une minute.

Dictez le contexte en mots simples, puis collez le code ou le message d'erreur à la main : une stack trace ou un extrait de code se copie à l'identique, il ne se prononce jamais. La méthode complète pour structurer un prompt à la voix, y compris le piège du « nouvelle ligne » qui envoie le message trop tôt, se trouve dans notre guide pour dicter ses prompts à ChatGPT et Claude.

Ce que la dictée fait mal (et les rares parades)

Les identifiants. « get user by id » arrive en quatre mots. Sur Mac, les commandes de Dictée d'Apple en français comprennent « activer pas d'espace » et « annuler pas d'espace » pour coller l'expression suivante, ainsi que « activer maj » pour une majuscule initiale, mais fabriquer du camelCase à la voix reste plus lent que de le taper.
Les symboles en série. Apple comme Microsoft permettent de dire « parenthèse ouvrante », « trait de soulignement » ou « barre oblique inverse ». Pratique pour un symbole isolé, pénible pour une ligne de code entière.
Le jargon et les noms de produits. Noms de bibliothèques, de services internes et sigles sont les mots les plus souvent mal compris. Tapez-les, ou dictez autour et comblez le trou ensuite.
L'exactitude. Un mot mal compris dans un commentaire est une coquille. Un caractère mal compris dans une valeur de configuration est un bug. Ne dictez jamais une valeur qui sera exécutée ou analysée par une machine.
L'open space. Parler à son ordinateur toute la journée à côté de collègues en visio gêne tout le monde. Un casque-micro et le maintien d'une touche pendant qu'on parle aident ; une pièce calme aide davantage.

Les noms exacts des commandes de ponctuation en français, sur Mac et sur Windows, sont réunis dans comment dicter la ponctuation.

Un réglage qui ne gêne pas le travail

Un développeur change sans cesse d'application : éditeur, terminal, navigateur, messagerie. Quel que soit l'outil, il doit écrire là où se trouve le curseur, dans chacune d'elles, avec un seul geste. La Dictée intégrée du Mac et la saisie vocale de Windows écrivent toutes deux au curseur, mais la saisie vocale de Windows exige une connexion Internet et la Dictée du Mac s'arrête après 30 secondes sans parole.

Voice Monkeys, notre application, est construite autour de ce geste : maintenez la touche Option droite sur Mac (Alt droite sous Windows et Linux), parlez, relâchez, et le texte arrive au curseur, y compris dans un terminal ou un IDE. Un appui bref garde l'écoute active jusqu'au prochain appui, Échap annule. Sur un Mac Apple Silicon, le modèle vocal tourne sur la machine et l'audio n'en sort pas ; si votre employeur encadre l'endroit où peuvent aller les enregistrements liés au travail, comparez ce fait avec ses règles plutôt que de vous en dispenser. Sous Linux, il faut une session X11, pas Wayland. Vous pouvez le télécharger et l'essayer 7 jours. Si vous écrivez surtout de la prose dans un seul éditeur, les outils intégrés suffiront peut-être. Pour comparer les options, voyez le panorama des applications de dictée.

Questions et réponses

Peut-on écrire du code avec la dictée vocale ?

Les outils de dictée généralistes sont mauvais pour le code : identifiants, crochets et syntaxe exacte sortent de travers. Ils sont efficaces pour la prose autour du code, comme les corps de commit, les commentaires de revue, la documentation et les prompts.

Comment dicter un message de commit ?

Lancez git commit sans -m pour ouvrir l'éditeur, tapez ou dictez un titre court, laissez une ligne vide, puis dictez le corps. Corrigez les noms de fichiers et de fonctions au clavier avant d'enregistrer.

La dictée fonctionne-t-elle dans un terminal ?

Les outils qui écrivent au curseur, dont la Dictée du Mac, la saisie vocale de Windows et des applications dédiées comme Voice Monkeys, écrivent dans le terminal comme le ferait un clavier. Ne dictez pas une commande que vous allez exécuter ; tapez-la.

Comment dicter un tiret bas ou des crochets ?

Dites le nom du symbole, par exemple « trait de soulignement » ou « crochet ouvrant ». Apple et Microsoft publient ces listes en français ; les mots diffèrent légèrement d'un système à l'autre.

Puis-je dicter des descriptions de code professionnel ?

Cela dépend de l'endroit où la voix est traitée et des règles de votre employeur. Vérifiez si votre outil traite l'audio sur l'appareil ou sur un serveur, puis consultez la politique de votre entreprise. Notre article sur la confidentialité de la dictée vocale aide à poser les bonnes questions.

Sources

Apple : Commandes de dictée de texte sur Mac (vérifié 6 novembre 2026)
Apple : Dicter des messages et des documents sur Mac (vérifié 6 novembre 2026)
Microsoft : Utilisez la saisie vocale pour parler au lieu de taper sur votre PC (vérifié 6 novembre 2026)