Vous avez ouvert ce matin une page Notion intitulée « PRD : [nom de la feature] ». Trois heures plus tard, elle affiche encore « PRD : [nom de la feature] ».
Vous connaissez le problème. Vous connaissez la solution. Vous l'avez expliquée deux fois hier à votre tech lead. Mais dès que vous vous asseyez pour la mettre par écrit, vous bloquez.
Ce n'est pas un problème de réflexion. C'est un problème de saisie au clavier.
Les PM ne sont pas payés pour taper. Vous êtes payé pour trancher sur ce qu'il faut construire et pourquoi. Le PRD n'est que l'artefact qui fige la décision pour que l'engineering, le design et la direction puissent l'exécuter. Et quelque part entre savoir quoi écrire et finir le doc, les heures s'évaporent.
Il existe un chemin plus rapide. Le PRD est l'un des documents les plus « faits pour la voix » qu'un PM écrira jamais. C'est en gros ce que vous diriez devant un tableau blanc pour expliquer la feature. Le jour où vous arrêtez de taper vos PRD pour les dicter, votre temps de rédaction s'effondre.
La taxe d'écriture des PM dont personne ne parle
Chaque PRD que vous écrivez est en compétition avec une réunion, une revue de roadmap, un thread Slack avec un stakeholder. La rédaction elle-même se fait dans des fenêtres volées d'une demi-heure ou après le dîner.
Le calcul est brutal. Une personne moyenne tape autour de 40 mots par minute. Une personne moyenne parle autour de 150. Soit déjà un écart de 3,5x, avant même de compter toutes les frictions qui rendent l'écriture pénible : retours en arrière, reformulations, le doute qui vous fait réécrire trois fois la même phrase avant d'avancer.
Un PRD de 1 500 mots qui prend 90 minutes à taper prend environ 25 minutes à dicter. La réflexion est la même. Le résultat est le même. Seul le mécanisme change.
Pourquoi les PRD sont parfaitement taillés pour la voix
La plupart des documents punissent la dictée parce qu'ils exigent de la précision : code, tableaux, modèles financiers. Les PRD sont l'inverse. Ce sont des documents narratifs.
Repensez au dernier PRD que vous avez écrit. La section « Problème » fait deux paragraphes qui expliquent pourquoi le sujet compte. La « Solution » décrit comment le truc fonctionne. Les « User stories » sont des phrases au format « En tant que X, je veux Y, afin que Z. » La section « Cas limites » est une liste de scénarios du type « que se passe-t-il si… ».
Rien de tout cela ne demande une précision clavier. Tout cela ressemble à ce que vous diriez en réunion. Le format colle déjà à la manière dont un PM communique réellement son travail.
Le workflow de PRD en 30 minutes
Voici la structure qui marche : 1. Ouvrez un doc vierge avec les titres de section déjà posés : problème, solution, user stories, critères d'acceptation, cas limites, hors périmètre, questions ouvertes. 2. Avancez section par section. Dictez chacune comme si vous l'expliquiez à un nouvel ingénieur qui rejoint l'équipe. 3. N'éditez pas pendant que vous parlez. Le bascule mentale entre « locuteur » et « éditeur » est ce qui vous ralentit le plus. 4. Une fois toutes les sections dictées, relisez le draft complet une fois, du début à la fin. Resserrez la langue. Corrigez ce qui est vraiment faux. 5. Envoyez en relecture.
Toute la discipline est dans l'étape trois. Si vous vous arrêtez sans cesse pour reformuler des phrases, vous perdez le bénéfice de vitesse. Vous êtes juste retombé à la vitesse du clavier, déguisé en autre chose.
Section par section : comment dicter chaque partie d'un PRD
Certaines sections se dictent plus facilement que d'autres. Voici comment aborder chacune.
Énoncé du problème
C'est la section la plus simple à dicter. Du pur récit. Vous expliquez ce qui est cassé, pour qui c'est cassé, et pourquoi ça compte maintenant.
Dictez-le comme vous briefiez une nouvelle recrue au stand-up. Mentionnez le segment d'utilisateurs, la friction qu'il rencontre, la métrique impactée. Ne vous souciez pas de l'élégance de la prose. C'est le boulot de l'édition.
Vue d'ensemble de la solution
Déroulez la solution proposée comme si vous la dessiniez au tableau. « L'utilisateur clique ici, voit ça, puis… » La voix gère ça avec fluidité parce que ça correspond à la manière dont vous l'expliqueriez déjà à l'oral.
User stories
Les user stories sonnent mécaniques à cause du schéma « En tant que X, je veux Y, afin que Z », mais elles se dictent très bien dès lors que vous vous engagez dans le format. Dites chaque story en une seule phrase, puis passez à la suivante.
Si vous en avez dix, dictez les dix d'une traite. Ne les numérotez pas à voix haute. Laissez l'éditeur du doc ou votre passe de nettoyage par IA gérer la mise en forme.
Critères d'acceptation
Les listes sont la partie la plus délicate de la dictée vocale, mais ça reste jouable. Deux approches :
La première : dictez les critères sous forme de phrases complètes et laissez la passe IA les convertir en liste. Dites par exemple : « L'utilisateur doit pouvoir filtrer les résultats par date, par utilisateur et par statut. L'état du filtre doit être conservé entre les sessions. L'état vide doit afficher une astuce. »
La seconde : verbalisez explicitement la structure à puces. « Puce un, filtrer par date. Puce deux, filtrer par utilisateur. Puce trois, conserver entre les sessions. » Choisissez celle qui vous semble la moins gauche à prononcer.
Cas limites
C'est là que la voix excelle vraiment. Les cas limites relèvent du genre de réflexion à voix haute qui sort clean à l'oral et maladroite au clavier. Des questions comme « que se passe-t-il si l'utilisateur est hors ligne » ou « et si les données sont périmées » coulent bien plus naturellement à la parole qu'à l'écrit.
Dictez tous les cas limites qui vous viennent, même ceux qui paraissent évidents. Vous élaguerez à l'édition.
Hors périmètre
Trois phrases. Quatre, à tout casser. La voix règle ça en moins d'une minute.
Questions ouvertes
Cette section est sous-estimée. La plupart des PM la sautent parce qu'ils ne veulent pas avoir l'air d'hésiter. Faux calcul. La section « questions ouvertes » est celle où l'engineering, le design et votre N+2 attrapent les angles morts que vous n'avez pas encore creusés.
La voix est l'outil idéal pour ça. Les questions ouvertes sont exactement le genre de pensées à moitié formées qui sortent bien quand vous parlez, et qui semblent étrangement lourdes dès que vous essayez de les taper. Dictez chaque incertitude, même celles dont vous soupçonnez la réponse évidente. La moitié seront tranchées au stand-up suivant. L'autre moitié sauveront votre lancement.
Adapter le ton à la section
Un PRD ne s'écrit pas d'une seule voix. L'exec summary en haut doit être serré et stratégique. Les specs techniques doivent être précises. La section « questions ouvertes » peut se permettre d'être plus relâchée.
Quand vous dictez, vous changez de registre naturellement. Votre voix se formalise quand vous parlez stratégie et se détend quand vous parcourez les cas limites. Le problème, c'est que la plupart des outils de dictée crachent la même transcription plate, indépendamment du contexte.
C'est précisément là que les Smart Rules de Voicr entrent en jeu. Vous pouvez configurer un style « spec pro propre » pour votre éditeur de docs, un style « brainstorming décontracté » pour vos threads Slack, et un style « clarté technique » pour votre wiki engineering. Voicr détecte l'application active et applique le bon style automatiquement : la même pensée prononcée à voix haute atterrit différemment selon où elle débarque.
Pour les PRD en particulier, configurez une règle qui réclame une prose pro propre, retire les mots de remplissage et structure les listes à puces là où vous les signalez. Vous parlez une fois. Le doc se lit comme si vous l'aviez peaufiné.
Là où la voix n'aide pas
Soyons honnêtes : toutes les parties d'un PRD ne profitent pas de la voix.
Les tableaux et matrices restent plus rapides à taper. Si votre PRD inclut une grille de comparaison de features, une matrice de permissions ou un tableau d'estimation chiffré, tapez-le.
Les chaînes techniques exactes sont aussi plus rapides au clavier. Noms d'endpoints d'API, noms de colonnes de base de données, numéros de version — vous pouvez les dicter en contournant (« l'endpoint c'est, slash, users, slash, ID ») mais c'est gauche. Tapez-les.
Les schémas, évidemment, ne se dictent pas. Esquissez-les dans l'outil de votre choix et insérez-les.
Pour tout le reste — narratif, user stories, cas limites, décisions, justifications — la voix gagne en vitesse, et sur le fait que vous ne restez plus bloqué en plein milieu d'une phrase à chercher la formulation parfaite.
Le changement d'état d'esprit : penser à voix haute, éditer ensuite
Le plus gros gain à dicter ses PRD, ce n'est pas le calcul des mots par minute. C'est que vous arrêtez de polir pendant que vous écrivez.
Quand vous tapez, vous reculez. Vous réécrivez deux fois la même phrase. Vous fixez pendant dix minutes un paragraphe « presque bien ». C'est là que les PRD meurent : dans l'interstice entre la rédaction et l'édition, là où ni l'une ni l'autre n'aboutit vraiment.
Quand vous dictez, vous vous engagez. Vous dites une phrase, elle atterrit sur la page, vous passez à la suivante. Le premier jet est plus brouillon que ce que vous auriez tapé. Mais vous finissez le draft. Et un draft brouillon mais fini est radicalement plus utile qu'un draft poli mais inachevé.
Une fois le draft posé, l'édition devient une activité différente, et beaucoup plus rapide. Vous passerez souvent plus de temps à raffiner qu'à dicter, et c'est très bien. Raffiner un doc complet, c'est un boulot connu. Fixer une page blanche, non.
Essayez sur votre prochain PRD
Choisissez un PRD que vous repoussez depuis trop longtemps. Ouvrez le doc, posez les titres de section, et dictez du début à la fin sans éditer. Lancez un minuteur de 25 minutes. Voyez ce qui en ressort.
La première fois, ça paraîtra bizarre. Vous craindrez que le résultat ne soit pas assez bon. Résistez à l'envie de corriger en plein flux. Finissez, simplement.
Si vous voulez que la dictée sorte assez propre pour que vous n'ayez quasiment rien à éditer, Voicr s'occupe du polissage automatiquement. Maintenez FN n'importe où sur votre Mac, parlez le temps d'une section, relâchez, et collez le texte nettoyé dans votre doc. L'outil supprime les mots de remplissage, corrige la grammaire et structure vos idées avant qu'elles n'atteignent votre presse-papiers. Le draft de PRD qui prenait un après-midi tient en une seule séance.
Vos PRD ne vont pas s'écrire tout seuls. Mais ils n'ont pas non plus à être tapés.