Commander ses agents de code à la voix, sur Mac

La voix pour écrire du code : sans intérêt, vous tapez plus précisément que vous ne parlez. La voix pour diriger cinq agents qui codent : c'est autre chose. La différence tient en un mot — viser. Voici ce qui marche, dans quel ordre l'installer, et où est la limite.

Le vrai gain n'est pas la vitesse de frappe

Quand cinq sessions sont ouvertes, la moitié de vos gestes ne servent qu'à désigner : trouver la bonne fenêtre, cliquer dedans, vérifier qu'elle a bien le focus, puis seulement taper. Une phrase supprime toute cette phase : « envoie à Merlin l'objectif 1 » contient la cible et le contenu. C'est la même raison qui rend une palette de commandes agréable — sauf que la voix marche aussi quand vos mains tiennent un café ou que vos yeux sont sur un autre écran.

1. La dictée doit être locale, et rapide

Deux critères, dans cet ordre :

• La latence. Au-delà d'une demi-seconde entre la fin de votre phrase et l'action, vous arrêtez d'utiliser la voix : vous doutez, vous répétez, vous cliquez. Les modèles de transcription légers qui tournent sur puce Apple Silicon descendent aujourd'hui à quelques dizaines de millisecondes.
• Le lieu. Un micro de développeur capte des noms de dépôts privés, des chemins internes, des noms de clients. La transcription doit se faire sur la machine. C'est aussi ce qui garantit que ça marche sans réseau.

Ajoutez le vocabulaire : les noms de vos agents, worktree, tmux, le nom de vos dépôts. Un moteur à qui l'on donne la liste des mots attendus se trompe beaucoup moins qu'un moteur générique.

2. Un nom par agent, pas un identifiant

« Envoie à la session 3 » ne se dit pas. « Envoie à Merlin » se dit. Nommer les agents n'est pas un gadget : c'est ce qui rend l'adressage vocal praticable, et c'est aussi ce qui vous permet de vous en souvenir une heure plus tard. Un détail à surveiller si vous comparez des outils : le nom que vous avez donné doit être la seule source. Un outil qui renomme vos agents d'après le CLI qui les fait tourner casse la commande vocale au premier doublon.

3. Plusieurs ordres dans une phrase

Personne ne parle en commandes atomiques. On dit « ouvre un agent claude sur le site et un codex sur l'API », ou « coupe la musique, puis finis le résumé ». Deux exigences :

• l'ordre est respecté — les ordres s'exécutent dans la séquence dite, pas en parallèle ni à l'envers ;
• l'auto-correction est comprise — « en fait, commence plutôt par… » réordonne au lieu d'empiler.

C'est la partie la plus difficile à faire correctement, et celle qui se teste le mieux : un découpage de phrase est une fonction pure, on peut lui passer des centaines de phrases réelles et vérifier la sortie. Si un éditeur ne peut pas vous dire comment il mesure ça, c'est probablement qu'il ne le mesure pas.

4. Le retour parlé, sinon la boucle est ouverte

Parler pour lancer, mais lire pour savoir : la moitié du gain disparaît. « Résume-moi ce que Chase a trouvé » doit produire une réponse audible. Deux façons de la produire :

En local — le modèle embarqué de macOS résume ce que la session vient d'afficher. Zéro token, zéro réseau, et ça marche même quand vos quotas sont épuisés.
Par un modèle distant — plus fin sur les textes longs, mais vous payez et vous attendez.

Pour « où en est-il ? », le local suffit et gagne. Gardez le distant pour ce qui demande vraiment du raisonnement.

5. Ce qui doit rester au clavier

Soyons honnêtes sur les limites. La voix est mauvaise pour : dicter un extrait de code, saisir un chemin exact, choisir dans une liste longue, travailler en open space, travailler la nuit à côté de quelqu'un qui dort. Un outil vocal sérieux propose donc le même vocabulaire au clavier — palette de commandes, champ texte, et de préférence un exécutable en ligne de commande pour ce que vous voudrez scripter. Et le micro reste éteint tant que vous ne le demandez pas : l'écoute permanente doit être un réglage que l'on arme, jamais un défaut.