Comment les développeurs utilisent Verity : des commentaires de code à la documentation technique

Pourquoi les développeurs dictent

L’essentiel du travail d’un développeur ne consiste plus à taper du code caractère par caractère. Il s’agit de décrire ce que vous voulez à des agents d’IA, de rédiger du contexte pour les réviseurs, d’expliquer l’architecture à vos collègues et de documenter des décisions. Tout ça, c’est de la rédaction — et dicter est plus rapide que taper du texte.

Le virage vers le développement assisté par IA a renforcé cette réalité. Si vous passez vos journées à parler à Claude Code, Cursor ou Copilot — décrire des bogues, demander des refactorisations, expliquer des exigences — c’est un volume élevé de saisie en langage naturel. Dicter ces instructions multiplie réellement votre vitesse (consultez notre guide sur la vitesse pour la technique), surtout quand la couche de polissage par IA transforme vos pensées dites à voix haute en requêtes claires et bien structurées.

Il y a aussi un argument ergonomique. Les troubles musculosquelettiques liés au travail répétitif sont courants en génie logiciel, et la dictée vocale soulage vos poignets et vos mains de l’effort mécanique pour les parties du travail axées sur la rédaction.

Comment Verity gère le vocabulaire technique

Les personas Minimal et Formel de Verity préservent déjà bien les identifiants techniques — une mention de useState ou de tokio::spawn reste telle que prononcée, sans devenir « use state » ou « Tokyo spawn ». La fonction de vocabulaire personnalisé vous permet d’enregistrer d’avance des termes propres à votre base de code — noms de fonctions internes, abréviations propres au projet, conventions de nommage de l’équipe. Vous les ajoutez dans Paramètres → Vocabulaire.

Le persona Minimal convient bien à la dictée technique : il applique un nettoyage léger sans reformuler vos phrases, ce qui préserve la précision technique.

Dicter aux agents de programmation IA

C’est le flux de travail le plus payant. Des outils comme Claude Code, Cursor, Copilot et Windsurf sont de plus en plus la façon dont le code s’écrit — vous décrivez ce que vous voulez en langage naturel, l’agent l’écrit. La saisie, c’est de la prose : « refactorise le middleware d’authentification pour utiliser la rotation des JWT », « ajoute la gestion d’erreurs pour la reconnexion WebSocket », « explique pourquoi ce test est instable ». Dicter ces instructions est nettement plus rapide que les taper. La couche de polissage par IA transforme vos pensées parlées en requêtes claires et bien structurées, ce qui améliore directement la qualité de ce que produit l’agent.

Il y a un effet cumulatif. Meilleure est votre requête, moins vous avez besoin d’allers-retours de correction avec l’agent. Une instruction dictée qui passe par le polissage ressort plus précise que ce que la plupart des gens tapent sous pression — phrases complètes, pas d’abréviations, termes techniques préservés. Cette précision évite à l’agent de deviner, ce qui vous évite de réviser du code à côté de la plaque.

Quelques exemples concrets de ce que ça donne en pratique :

• Rapports de bogues aux agents : « Le flux de connexion plante quand le fournisseur OAuth renvoie un 302 sans en-tête location. L’erreur apparaît dans auth/callback/route.ts à l’étape d’analyse de la redirection. Ajoute une garde qui redirige vers la page de connexion avec un paramètre d’erreur au lieu de lever une exception. » Dit en dix secondes, poli en une instruction précise sur laquelle un agent peut agir sans poser de questions.
• Changements d’architecture : « Déplace le limiteur de débit de la passerelle d’API vers la couche de services pour que chaque point de terminaison puisse fixer son propre seuil. L’implémentation actuelle utilise une seule fenêtre glissante pour toutes les routes, ce qui veut dire qu’une rafale de rappels webhook peut affamer les requêtes interactives. » Ce niveau de contexte — le pourquoi, pas seulement le quoi — est naturel à dire et fastidieux à taper.
• Commentaires de revue de code : « Ce diff fait passer la logique de nouvelle tentative d’un délai exponentiel à un intervalle fixe. Ça convient pour la vérification de santé, mais le gestionnaire du webhook de paiement a besoin du délai exponentiel pour éviter de marteler Stripe pendant une panne. Sépare la stratégie de nouvelle tentative selon l’appelant. » Vous pouvez dicter vos commentaires en lisant le diff, puis coller la version polie comme commentaire de revue.

Le flux de travail « penser à voix haute »

La dictée permet une façon de développer que le clavier ne permet pas : penser à voix haute comme étape de conception. Avant de toucher au code, vous exposez oralement l’approche — quels composants sont en jeu, à quoi ressemble le flux de données, où se trouvent les parties délicates. Le texte poli devient une ébauche de conception que vous pouvez remettre directement à un agent d’IA ou coller dans un document de planification.

Ça fonctionne parce que la parole et la pensée vont à la même vitesse. Quand vous tapez un plan, la lenteur mécanique du clavier filtre vos pensées — vous sautez des détails, vous abrégez, vous perdez le fil. Quand vous le dites, tout le raisonnement passe : les cas limites que vous oublieriez normalement de mentionner, les contraintes que vous laisseriez implicites, les solutions de rechange que vous écarteriez sans les noter.

Résultat : l’agent produit un meilleur travail du premier coup, parce qu’il a reçu un portrait complet plutôt qu’une ébauche compressée. Ça crée aussi un artefact naturel — la transcription polie — qui sert de documentation de la décision de conception. Deux résultats pour une seule action.

Un exemple concret : vous êtes sur le point de refactoriser le système de notifications. Au lieu de rédiger un document de conception à partir de zéro, vous ouvrez Verity, appuyez sur le raccourci et parlez pendant quatre-vingt-dix secondes : « En ce moment, les notifications passent par un seul canal — le courriel. On doit ajouter le push et l’in-app. Le défi, c’est que chaque canal a sa propre sémantique de nouvelle tentative et ses propres limites de débit. Je pense qu’on devrait extraire une interface NotificationDispatcher avec une implémentation par canal, faire passer le tout par une file de priorité et laisser chaque canal gérer sa propre politique de nouvelle tentative. Le chemin de migration : ajouter l’interface, placer le courriel derrière, puis ajouter le push et l’in-app comme nouvelles implémentations sans toucher aux appelants existants. » Ça ressort de la couche de polissage en un paragraphe propre et lisible — prêt à coller dans un ticket GitHub, à remettre à un agent ou à déposer dans un ADR.

Passer du code à la communication

Une séance de développement typique alterne entre écrire du code et écrire à propos du code. Vous implémentez une fonctionnalité, puis vous rédigez le message de commit. Vous corrigez un bogue, puis vous mettez à jour le gestionnaire de tickets. Vous révisez une PR, puis vous laissez des commentaires. Les parties code exigent un clavier. Les parties communication exigent de la prose — et c’est là que la dictée prend le relais.

Le raccourci global rend cette transition fluide. Vous ne changez pas d’application, n’ouvrez pas de fenêtre de dictée séparée et ne brisez pas votre concentration. Appuyez sur le raccourci dans votre terminal pour dicter un message de commit. Dans votre navigateur pour dicter un commentaire de revue de PR. Dans Slack pour dicter une mise à jour d’état. Le texte poli apparaît là où se trouve votre curseur, dans l’application que vous utilisiez déjà.

C’est particulièrement utile pendant les longues séances de débogage, où vous devez documenter ce que vous avez essayé, ce que vous avez observé et ce que vous en avez conclu. Taper ces notes tout en réfléchissant au problème impose un coût de changement de contexte. Les dicter, non — vous ne faites que narrer ce que vous pensez déjà.

Autres flux de travail qui fonctionnent bien

• Commentaires dans le code : une documentation en ligne qui explique le pourquoi, pas le quoi. Ils font généralement de 1 à 3 phrases et n’exigent pas la même précision que le code lui-même.
• Descriptions de PR : le contexte pour les réviseurs — ce qui a changé, pourquoi, quoi surveiller. C’est souvent la partie la plus fastidieuse du processus de PR, et c’est naturellement de la prose.
• Messages de commit : lignes d’objet et descriptions détaillées pour git commit. Dicter le message est souvent plus rapide que le taper, surtout avec le format Conventional Commits.
• Documentation technique : sections de README, pages de wiki, registres de décisions d’architecture (ADR), guides d’exploitation. Beaucoup de prose, exigences de précision modérées.
• Courriels techniques et messages Slack : des messages plus longs pour mettre en contexte vos collègues ou les parties prenantes, qui gagnent à être composés oralement.

Linux, macOS et Windows

Verity fonctionne sous Linux, macOS et Windows — les trois plateformes sont des cibles à part entière, pas des ajouts de dernière minute. Ça compte davantage pour les flux de travail des développeurs que pour la plupart des usages, parce qu’une part importante des développeurs travaille sous Linux, comme système principal ou comme environnement de développement.

La plupart des outils de dictée ne prennent pas du tout Linux en charge. La dictée intégrée de chaque plateforme se limite à son propre écosystème, et la plupart des solutions de rechange sont monoplateformes. Linux a historiquement été complètement ignoré.

L’insertion de texte à l’échelle du système fonctionne sur les trois plateformes — la dictée va directement dans n’importe quel champ de texte, peu importe l’application active. Pas besoin d’extension de navigateur, de module d’éditeur spécial ni de zone de saisie dédiée.

Confidentialité pour le code propriétaire

Si vous dictez des commentaires de code ou de la documentation technique, vous dictez probablement de l’information propriétaire : noms d’API internes, décisions d’architecture, détails de logique d’affaires. L’architecture à conservation nulle compte ici d’une façon bien précise.

L’audio est traité sur l’infrastructure de Verity — aucun fournisseur d’IA tiers n’intervient. Aucun audio de votre séance de dictée n’est stocké, journalisé ou utilisé pour entraîner des modèles. Les détails de votre code propriétaire ne persistent dans aucun système une fois la requête de transcription terminée.

Consultez notre billet sur l’architecture de confidentialité pour l’analyse technique complète, ou la page des fonctions de confidentialité pour un résumé de la liste des sous-traitants et des modalités de l’entente de traitement des données (DPA). Le stockage des transcriptions chiffré par utilisateur en AES-256-GCM signifie que même le texte de vos transcriptions est inaccessible à Verity sans votre clé.