Demandez à un développeur quelle part de sa semaine il passe à écrire du code, et la réponse honnête est souvent : « moins qu’on ne croit ». Le reste, c’est de la prose. Descriptions de pull requests, commentaires de revue, tickets, messages de commit, documents de conception, points d’incident, fils Slack. Et depuis 2025, une part croissante de ce texte, ce sont des instructions pour des outils de code IA, dont le résultat dépend presque entièrement de la quantité de contexte qu’on a eu le courage de taper.
C’est dans cette prose que la dictée vocale a sa place dans l’environnement d’un développeur. Pas dans le code lui-même, et nous préférons l’écrire dès le premier paragraphe plutôt que de vous laisser le découvrir après une semaine à vous battre avec votre éditeur.
Dikto n’est pas un outil de programmation vocale. Il n’écrira pas de manière fiable une boucle for, une expression régulière ou une commande shell, et son nettoyage par IA est conçu pour rendre une langue agréable à lire, ce qui est exactement ce qu’il ne faut pas faire à une syntaxe. Ce qu’il fait bien, c’est transformer deux minutes de parole en description de pull request, en commentaire de revue ou en prompt d’agent que vous auriez autrement raccourci, parce que le taper vous paraissait une corvée.
L’essentiel
- Dictez la prose, tapez le code. Descriptions de PR, commentaires de revue, tickets, documentation, corps de commit et prompts pour les agents de code IA sont du langage naturel. La syntaxe, non.
- Le prompt aux outils de code IA est le gain le plus net. Un prompt parlé sort plus long et plus précis qu’un prompt tapé, et c’est la précision qui rend exploitable la première tentative d’un agent.
- Apprenez votre vocabulaire à l’outil. Noms de frameworks, de services, termes internes : c’est là que la transcription généraliste trébuche, et un dictionnaire personnalisé règle l’essentiel du problème.
- Vérifiez ce qui quitte votre machine. Dikto fonctionne uniquement dans le cloud. Tout ce que vous dictez ou sélectionnez pour une action IA est envoyé pour traitement : la politique de votre entreprise sur le code source et les données clients s’applique. Ne dictez jamais un secret.
- Si vous voulez coder sans les mains, prenez un outil de programmation vocale. Talon, Cursorless et le Contrôle vocal de macOS sont faits pour ce travail. Une application de dictée les complète, elle ne les remplace pas.
Où partent réellement les mots d’un développeur
Avant de décider si la dictée en vaut la peine, il faut faire un inventaire honnête. Sur une semaine type, l’écriture en langage naturel ressemble à ceci :
- Descriptions de pull requests : ce qui a changé, pourquoi, ce que vous avez envisagé puis écarté, comment tester, quoi surveiller après la mise en production.
- Commentaires de revue : toute la différence entre « nit : renommer » et un commentaire qui explique le mode de défaillance qui vous inquiète.
- Tickets et rapports de bug : étapes de reproduction, comportement attendu contre comportement observé, ce que vous avez déjà éliminé.
- Messages de commit : la ligne de titre est courte, mais le corps — le pourquoi — est précisément la partie qu’on saute.
- Documents de conception et ADR : contexte, options, compromis, décision.
- Points d’incident et de statut : rédigés sous pression, lus par des gens qui n’étaient pas dans la salle.
- Messagerie : la longue explication Slack que vous redonnez de la même façon trois fois par mois.
- Prompts pour les outils de code IA : Claude Code, Cursor, GitHub Copilot Chat, Codex et les autres.
Presque tout ce texte souffre du même défaut : il est écrit par quelqu’un qui veut retourner au code, donc il finit plus court que ce dont le lecteur a besoin. La parole conversationnelle tourne autour de 130 à 150 mots par minute ; même un dactylographe rapide reste nettement en dessous, et la plupart des gens tapent encore plus lentement quand ils composent un texte que quand ils le recopient. L’effet concret n’est pas « vous gagnez X minutes ». C’est que la version complète de la description de PR cesse de coûter plus cher que la version bâclée.
Piloter les agents de code IA à la voix
C’est l’usage qui a le plus changé, et celui où la dictée est rentable le plus vite.
Un agent de code IA ne vaut que ce que vaut la consigne qu’il reçoit. Les prompts qui donnent une première tentative exploitable contiennent en général les mêmes éléments : l’objectif, les contraintes, où chercher dans le code, ce qu’il ne faut pas toucher, et comment savoir que le travail est terminé. Les prompts que l’on tape vraiment tiennent souvent en une ligne, parce que rédiger la consigne complète donne l’impression d’écrire un ticket pour un collègue assis juste à côté.
À l’oral, la consigne complète prend à peu près le temps de l’expliquer à ce collègue — ce qu’elle est, au fond. Un prompt dicté brut peut ressembler à ceci :
« alors euh la logique de retry dans le handler du webhook de paiement avale l’erreur à la troisième tentative je veux qu’elle logue l’erreur avec l’ID de l’événement et qu’ensuite elle la relance pour que la file marque le job en échec ne change pas les délais de backoff et ne touche pas aux autres handlers il y a un fichier de test à côté ajoute un test pour le troisième échec et lance les tests existants avant de terminer »
Après nettoyage, l’agent reçoit :
La logique de retry du handler du webhook de paiement avale l’erreur à la troisième tentative. Je veux qu’elle journalise l’erreur avec l’identifiant de l’événement, puis qu’elle la relance, pour que la file marque le job en échec. Ne modifie pas les délais de backoff et ne touche pas aux autres handlers. Il y a un fichier de test à côté : ajoute un test pour le troisième échec, et lance les tests existants avant de terminer.
Rien dans ce prompt n’est du code. C’est une consigne claire, et elle a pris vingt secondes à dire.
Quelques habitudes améliorent nettement les prompts dictés :
- Dites les contraintes à voix haute. « Ne change pas l’API publique », « garde le diff petit », « demande-moi avant d’ajouter une dépendance ». Ce sont les choses qu’on omet en tapant et qu’on regrette à la relecture.
- Nommez l’étape de vérification. « Lance les tests », « montre-moi le diff avant de committer », « explique le changement en deux phrases ». Les agents respectent bien mieux une ligne d’arrivée explicite qu’une ligne implicite.
- Tapez les identifiants ensuite s’ils comptent. Si le prompt repose sur un nom de fonction ou de fichier exact, dictez la phrase puis corrigez le nom à la main, ou collez-le. Les agents pardonnent une prose approximative, pas un chemin mal orthographié.
- Parlez dans la langue que vous voulez. Beaucoup d’agents comprennent très bien le français. Si votre équipe travaille en anglais, vous pouvez aussi dicter en français et insérer directement l’anglais (voir plus bas).
Un avertissement pratique pour les agents en terminal. Dikto insère le texte là où se trouve votre curseur, et une invite de terminal est un champ texte comme un autre. Mais les terminaux ne gèrent pas tous les saisies multilignes de la même façon : dans certains, un saut de ligne dans le texte inséré équivaut à appuyer sur Entrée. Avant de vous y fier, dictez un prompt de test de deux paragraphes dans votre propre terminal et vérifiez s’il arrive en un seul message ou s’il part à moitié. Quand c’est nécessaire, la solution tient généralement à un réglage de l’agent ou du terminal, ou simplement à dicter le prompt en un seul paragraphe.
Ce qu’il ne faut pas dicter
La liste est courte, et elle mérite d’être prise au sérieux.
La syntaxe du code. Crochets, opérateurs, indentation et casse exacte ne sont pas du langage naturel. Un moteur de dictée transcrit ce qu’il entend sous forme de mots, puis un nettoyage par IA essaie de faire de ces mots une bonne prose — majuscules, ponctuation, « corrections ». C’est utile dans un e-mail et destructeur dans un bloc de code. Pour écrire du code à la voix, il faut un outil qui traite la parole comme des commandes plutôt que comme du texte ; nous y revenons plus bas.
Les commandes que vous allez exécuter. Une commande shell légèrement mal transcrite est pire qu’une commande tapée lentement. Dictez l’explication ; tapez ou collez la commande.
Les secrets. Clés d’API, jetons, mots de passe, chaînes de connexion, données clients. Ni dans une dictée, ni dans un prompt, ni dans un dictionnaire personnalisé. C’est vrai de tout outil cloud, mais cela vaut d’être répété pour la dictée : prononcer quelque chose à voix haute donne moins l’impression de « l’envoyer » que de le coller.
Tout ce que la politique de votre employeur garde en interne. Beaucoup d’entreprises encadrent les services tiers autorisés à recevoir du code source, des détails d’architecture interne ou des informations clients. Dicter une phrase sur un système, ou sélectionner un bloc de texte et lancer une action IA dessus, envoie ce contenu à un service cloud pour traitement. Si vous ne savez pas ce que votre politique autorise, posez la question avant de prendre l’habitude.
Configurer l’outil pour le développement
Choisissez un raccourci qui n’entre pas en conflit avec votre éditeur. Les IDE réservent énormément de combinaisons de touches. Prenez un raccourci que ni votre éditeur, ni votre terminal, ni votre gestionnaire de fenêtres n’utilisent, ou associez la dictée à un bouton libre de votre souris pour que vos mains ne quittent jamais leur position.
Construisez votre dictionnaire dès le premier jour. Les mots qu’un moteur généraliste rate sont prévisibles : noms de frameworks et de bibliothèques, services cloud, noms internes de votre produit, prénoms de vos collègues, acronymes qui ressemblent à des mots. Ajoutez les vingt ou trente que vous employez le plus — votre base de données, votre file de messages, votre framework front, votre outil de supervision, les noms des services de votre architecture. Dans Dikto, les termes du dictionnaire et le contexte enregistré sont stockés sur nos serveurs et envoyés pour traitement afin d’améliorer la reconnaissance : c’est exactement pour cela qu’ils ne doivent jamais contenir de secret. Pour les noms de code internes, suivez la politique de votre entreprise.
Utilisez les actions de sélection sur vos propres brouillons. Le double appui de Dikto ouvre des actions IA sur le texte sélectionné : reformuler, traduire, résumer, corriger l’orthographe. Pour un développeur, les plus utiles sont les moins spectaculaires : resserrer un commentaire de revue trop bavard, corriger l’orthographe d’une section de README, ou transformer une note d’incident écrite au fil de l’eau en texte lisible par un interlocuteur métier. Soyez sélectif sur ce que vous sélectionnez : une action IA sur un bloc de code propriétaire envoie ce code pour traitement, exactement comme une dictée.
Quatre usages rentables tout de suite
La description de PR en quatre-vingt-dix secondes. Quand le diff est prêt, avant d’ouvrir la revue, dictez quatre choses dans l’ordre : ce qui a changé, pourquoi, ce que vous avez envisagé puis écarté, comment tester. La partie « alternatives écartées » est celle que les relecteurs apprécient le plus et que les auteurs écrivent le moins ; à l’oral, elle ne coûte presque rien.
Des commentaires de revue qui s’expliquent. Au lieu de « ça peut créer une race condition », dites ce qui vous inquiète : quels deux chemins, sous quelle charge, et ce que l’utilisateur verrait. Un commentaire qui explique son raisonnement obtient une meilleure réponse, et moins de réactions défensives.
Le corps des commits. Tapez la ligne de titre dans la convention de votre équipe. Dictez le corps — le pourquoi — en dessous. Dans six mois, git blame vous remerciera.
Les points d’incident. Sous pression, on tape de façon télégraphique. Dicter « ce que nous savons, ce que nous ne savons pas encore, ce que nous faisons ensuite, à quelle heure arrive le prochain point » produit un message sur lequel les gens peuvent réellement agir.
Pour les développeurs qui travaillent en anglais
Une grande partie des développeurs francophones écrivent en anglais toute la journée : le code, les PR, la documentation, les échanges avec l’équipe basée à l’étranger. Le code ne pose pas de problème ; la description de PR, le document de conception et la réponse au fil d’un collègue américain prennent plus de temps qu’ils ne le devraient.
Dikto permet de dicter en français et d’obtenir le texte dans une autre langue — vous parlez français, l’anglais s’insère. Pour expliquer une décision de conception ou rédiger un rapport de bug détaillé, penser en français et livrer en anglais n’a rien à voir avec composer dans sa deuxième langue à mi-vitesse. Nous ne sommes pas le seul outil à le proposer — Typeless, Spokenly et TypeWhisper offrent tous une forme de « parler une langue, écrire dans une autre » —, alors essayez-en plusieurs. Notre article détaillé sur le sujet : traduire par la voix.
Si ce que vous cherchez, c’est coder sans les mains
Certains développeurs arrivent à la dictée parce que taper leur fait mal : douleurs au poignet, tendinites, troubles musculosquelettiques. Si vous devez écrire du code sans clavier, une application de dictée n’est pas le bon outil principal, et il faut regarder la catégorie conçue pour cela :
- Talon est le système de contrôle vocal historique des développeurs qui codent entièrement à la voix, avec des jeux de commandes communautaires et une prise en charge du suivi oculaire. Sa courbe d’apprentissage se compte en semaines, pas en minutes.
- Cursorless est une extension VS Code, construite sur Talon, qui permet d’éditer le code de façon structurelle à la voix — « prends la fonction suivante », « change cet argument » — plutôt que de dicter des caractères.
- Le Contrôle vocal de macOS, intégré au système, donne des commandes, des clics et de la navigation sans rien installer.
Vérifiez l’état actuel de chaque projet et les plateformes prises en charge avant de vous engager. Ces outils cohabitent bien avec une application de dictée : l’outil de programmation vocale gère la syntaxe et la navigation, la dictée gère les paragraphes. Et si la douleur est la raison pour laquelle vous lisez ceci, parlez-en aussi à un médecin : l’outillage aide, il ne soigne pas.
Choisir un outil de dictée quand on est développeur
Les applications de dictée IA généralistes sur Mac — Dikto, Wispr Flow, Superwhisper, Typeless, MacWhisper et d’autres — couvrent toutes le versant « prose » du développement. Elles diffèrent sur des points qui comptent particulièrement pour un développeur :
- Le lieu du traitement. Certaines font tourner de petits modèles en local, d’autres sont hybrides, d’autres uniquement cloud. Dikto est uniquement cloud : il n’y a pas de mode hors ligne, et l’audio quitte votre Mac. Le réglage « Fournisseur d’IA » de l’application utilise « Mistral (UE) » par défaut, avec OpenAI en option ; notre politique de confidentialité décrit les traitements et ce qui est conservé ou non. Si votre employeur interdit d’envoyer quoi que ce soit à un service cloud, un outil entièrement local est la bonne réponse, et c’est celui-là qu’il faut choisir.
- Les intégrations propres au développement. Wispr Flow, par exemple, met en avant des fonctions pensées pour les éditeurs de code IA, comme la reconnaissance des noms de fichiers et de variables. Si c’est votre besoin principal, testez-le sur votre propre base de code.
- Le prix et les limites. L’offre gratuite de Dikto donne des limites quotidiennes plus élevées pendant les sept premiers jours, puis 15 minutes de dictée (environ 2 000 mots) et 10 actions IA par semaine, sans carte bancaire. Pro coûte 9 € par mois ou 89 € par an pour une dictée illimitée. La comparaison avec le reste du marché se trouve dans notre comparatif des meilleurs logiciels de dictée vocale pour Mac.
Questions fréquentes
Peut-on écrire du code avec Dikto ? Pas de manière fiable, et nous ne le recommandons pas. Dikto est conçu pour produire un langage naturel propre, et son nettoyage va à l’encontre de la syntaxe. Utilisez-le pour tout ce qui entoure le code, et un outil de programmation vocale si vous devez coder à la voix.
Est-ce que ça fonctionne dans mon IDE et mon terminal ? Le raccourci global insère le texte dans l’application active, y compris les éditeurs, les panneaux de chat et les terminaux. Testez la saisie multiligne dans votre terminal avant d’en dépendre, comme décrit plus haut.
Est-ce qu’il comprend les termes techniques ? Les termes courants, en général. La longue traîne — noms de vos services, bibliothèques de niche, acronymes — est la raison d’être du dictionnaire personnalisé. Comptez en ajouter pendant la première semaine.
Peut-on dicter à propos de code propriétaire ? C’est à votre employeur d’en décider, pas à nous. Les faits dont vous avez besoin sont les suivants : Dikto est uniquement cloud, l’audio dicté et tout texte sur lequel vous lancez une action IA sont envoyés pour traitement, et les termes du dictionnaire et le contexte enregistrés restent sur nos serveurs jusqu’à ce que vous les modifiiez ou supprimiez votre compte. Quelle que soit la politique, ne dictez jamais de secrets.
La dictée est-elle vraiment plus rapide que la frappe pour un développeur qui tape vite ? Pour un texte court et précis, souvent non. Pour les explications longues — descriptions de PR, raisonnement de conception, prompts détaillés —, le gain vient moins de la vitesse brute que du fait qu’on arrête d’abréger.
En résumé
Le code est la partie du métier de développeur que la voix gère le moins bien, et la prose qui l’entoure est celle qu’elle gère le mieux. Dictez la pull request, la revue, le ticket, la documentation, et surtout la consigne que vous donnez à votre agent de code IA ; continuez à taper la syntaxe, les commandes et tout ce qui est secret.
Si ce partage correspond à votre façon de travailler, vous pouvez essayer Dikto gratuitement sans carte bancaire, construire votre dictionnaire la première semaine, et voir si vos descriptions de PR s’allongent avant que vos journées ne le fassent.