Programmer à la voix : code, revue, commits

« Programmer à la voix » sonne d'habitude comme une farce. La vidéo de 2017 où un développeur crie « open paren if foo equals equals null close paren », c'est un mème, pas un workflow. Moi aussi, j'ai longtemps pensé que cette idée était morte.

Commander Flow a fait évoluer mon point de vue. Pas parce qu'il a ajouté un mode magique de « dictée de code ». Mais parce que le code n'est pas que du code. Le code, ce sont des commits, des tickets, du code review, de la documentation, des commentaires, des noms, des chats avec les collègues. Et tout ça autour du code — chez moi, c'est désormais à la voix.

Là où la voix change vraiment la vie d'un développeur

Mon opération vocale la plus fréquente, ce sont les messages de commit. Je place le curseur dans git commit -m "...", je maintiens la touche, je dis quelque chose comme « répare la race condition à l'annulation de pipeline, on annule correctement le token au second appui sur le raccourci », et un message conventional commits prêt arrive dans le terminal, parce que j'ai dicté les règles une fois — et elles ont été retenues.

Les descriptions de PR sont presque pareilles, juste plus longues. J'ouvre le template GitHub-PR, je dicte comme si j'expliquais à un junior : ce qui change, pourquoi, ce qu'on ne touche pas, comment vérifier. Quelques secondes plus tard, j'obtiens un markdown propre avec les en-têtes ## Context, ## Changes, ## Test plan. Avant ça prenait cinq minutes, maintenant — quelques secondes.

Le bouleversement principal pour moi, ce sont les commentaires de code-review. Avant, j'avais la flemme d'écrire des revues détaillées : trop de frappe pour quelque chose qu'on lit et qu'on oublie. Maintenant, je sélectionne une ligne, je dicte ma pensée et j'obtiens un commentaire poli et précis en deux secondes. Mes revues sont devenues sensiblement plus longues et nettement plus utiles, et l'équipe le voit.

Mention spéciale à la documentation. La partie la plus douloureuse du métier. Je dicte un docstring comme je l'expliquerais à un collègue, et Commander Flow le met au format XML-doc, TSDoc ou markdown — selon le langage du projet. La documentation a cessé d'être une taxe que je paie en plus du code.

« Je n'écris pas du code à la voix. J'écris tout ce qui est autour du code à la voix. Et j'ai compris que c'est la moitié de mon boulot. »

Le mode code-comments : un truc à part que j'adore

Du coup, je dis simplement « garde ça comme un commentaire de code » à voix haute — et Commander Flow :

• Ne touche pas aux identifiants en latin (variable names, class names)
• Préserve les termes (kubectl, async/await, useEffect, OAuth) dans leur orthographe d'origine
• N'ajoute pas de tournures « polies superflues » (de toute façon, personne n'écrit « cher lecteur » dans des commentaires de code)
• Gère correctement les deux alphabets dans un même commentaire : // on vérifie que Subscription.IsActive avant l'appel à BillingService.Refresh

Ça paraît anodin. Mais sans cet indice vocal, les premières builds alpha « anoblissaient » parfois mon commentaire technique au point de devenir « vérifions si notre objet métier d'abonnement est correct ».

Le dictionnaire de termes : une fonctionnalité sous-estimée

Dans PolishOptions.Dictionary, je verse mes propres termes et acronymes. J'ai par exemple :

• kubectl, helm, argocd, flux
• IDictionary, IAsyncEnumerable, Span<T>
• ConfigureAwait(false) (en bloc, comme une expression — pour que le LLM ne réécrive pas)
• Acronymes de l'entreprise, noms de services internes

Après ça, le LLM cesse d'« améliorer » les termes spécifiques et les laisse exactement tels que je les ai dictés.

Le scénario qui me convainc chaque jour

10h30, je suis dans l'IDE, à côté il y a Telegram d'équipe, à côté Linear avec un ticket. Je maintiens le raccourci et je dis :

« J'ai sorti la logique de retry dans une classe RetryPolicy avec backoff exponentiel, ajouté les tests, vérifie en plus le sequence diagram dans le ticket avant de merger »

Ça part dans Linear comme commentaire au ticket. Ensuite — Alt+Tab vers Slack, même raccourci :

« équipe, j'ai poussé une PR pour revue, non bloquante mais idéalement aujourd'hui »

Style Slack, en minuscules, sans « chers collègues ». Puis retour à l'IDE.

Trois actions dans trois applications, tout à la voix, sans toucher au clavier.

Là où j'ai trébuché

La ponctuation dans le code intercalée à la dictée. Si je dicte un bloc « cette fonction renvoie Task<bool> », parfois le LLM « pense » que Task<bool> est du HTML et tente de l'échapper. Réglé en ajoutant le terme au dictionnaire, mais ça surprend la première fois.

Conflits de raccourcis avec l'IDE. Mon IDE a ses propres raccourcis. Le raccourci Commander Flow, j'ai dû le réassigner deux fois pour éviter les conflits. Aujourd'hui il est sur Caps Lock — la touche la plus pratique et la moins utilisée. Petit inconfort, réglé en un clic.

Les modes les plus lourds peuvent « réfléchir » un peu plus lentement dans l'IDE. Pour un e-mail, quelques millisecondes en plus passent inaperçues. Pour un commentaire de code « ici et maintenant » — perceptibles. Je suis passé au mode intermédiaire pour le portable et j'ai gardé le mode le plus puissant pour le desktop avec GPU dédié. La latence a disparu.

Ce que j'ai compris du son comme interface de programmation

La voix ne remplace pas le clavier dans l'IDE. Elle le complète là où le clavier était le pire outil. Taper if (x != null && y != null) — clavier. Expliquer pourquoi cette vérification est nécessaire — voix.

Entre ces deux tâches, il y a un gouffre de charge cognitive, et elles ne « se résolvent » pas pareillement à la frappe. J'ai cessé de me forcer à taper la deuxième catégorie. C'est devenu plus léger.

Ce que j'ai retenu de cette proportion

Programmer à la voix, ce n'est pas « dicter du code ». C'est un déplacement de ce que tu fais à la voix. La logique au clavier, tout l'humain autour de la logique à la voix.

En dix ans de métier, je n'avais pas trouvé de proportion plus confortable.