Il y a deux ans, rédiger une spécification fonctionnelle prenait une demi-journée. Aujourd'hui, un prompt bien tourné en produit une en trente secondes : structurée, exhaustive, avec ses cas limites et ses critères d'acceptation. Sur le papier, c'est un gain de temps considérable. Dans les équipes que nous accompagnons, c'est souvent devenu l'inverse : les développeurs ralentissent, posent plus de questions, et la confiance dans les documents produit s'effrite. Voici pourquoi, et comment reprendre la main.
Le piège : du volume qui masque l'absence de décision
Une spécification n'est pas un texte. C'est la trace écrite d'une décision : ce qu'on construit, pour qui, pourquoi, et surtout ce qu'on a choisi de ne pas faire. Or l'IA ne décide rien. Elle produit ce qui est plausible. Demandez-lui de spécifier un module de facturation, elle vous livrera vingt exigences cohérentes… dont personne n'a validé la moitié, et dont plusieurs n'ont aucun rapport avec votre besoin réel.
Le document a l'air complet. Il ne l'est pas : il est rempli. Et cette différence, ce sont vos développeurs qui la paient.
Ce que ça produit côté développeurs
Nous observons trois effets, systématiquement. Le premier : le développeur doit deviner ce qui compte. Face à vingt exigences d'égale importance apparente, il ne sait pas laquelle est le cœur du besoin et laquelle est un remplissage généré. Il construit tout, ou il demande — et dans les deux cas il perd du temps qu'une spec courte et tranchée lui aurait épargné.
Le deuxième : les cas limites plausibles mais jamais validés. L'IA adore les cas limites ; elle en invente d'excellents. Sauf que « que se passe-t-il si l'utilisateur annule pendant le paiement fractionné multi-devises ? » n'a jamais été une question que votre produit se posait. Le développeur l'implémente consciencieusement, ou il débat une heure pour savoir si c'est sérieux. Travail inutile, ou bug sur un chemin que personne n'a pensé.
Le troisième, le plus insidieux : la fausse complétude décourage les questions. Un document long et bien formaté envoie le signal « tout a été pensé ». Le développeur qui doute se dit que l'info est sûrement quelque part dans les huit pages. Il ne demande pas. Il interprète. Et l'écart entre ce qui était voulu et ce qui est livré se découvre en recette — au moment le plus cher.
Ce que l'IA fait vraiment bien
Ne jetons pas l'outil : bien employé, il est précieux. L'IA excelle à structurer une idée déjà décidée — vous savez ce que vous voulez, elle le met en forme proprement. À reformuler pour un public différent, à résumer des retours utilisateurs en tendances, à générer des scénarios de test que vous validerez ensuite un par un, à produire une première trame qu'on amende plutôt qu'une page blanche qu'on affronte.
Le point commun de ces usages : l'IA accélère un travail dont le sens est déjà fixé. Elle formalise. Elle ne tranche pas.
La règle simple : l'IA rédige, le PM décide et relit tout
Concrètement, voici comment nous l'intégrons sans dégrader le delivery. D'abord, décider avant de générer : la priorité, le périmètre, ce qu'on exclut — tout ça se fixe avant d'ouvrir l'outil, pas après. Ensuite, relire intégralement et assumer chaque ligne : une exigence que personne n'a lue n'est pas une exigence, c'est une hypothèse déguisée. Si vous n'avez pas le temps de relire, vous n'avez pas le temps de spécifier. Enfin, préférer court et tranché à long et exhaustif : une spec de dix lignes assumées vaut mieux qu'une de dix pages générées. Vos développeurs vous en remercieront — et livreront plus vite.
Ce que ça change pour le métier de PM
L'IA ne remplace pas le product manager. Elle déplace sa valeur. Ce qui devient bon marché, c'est la production de documents. Ce qui devient précieux, c'est ce qu'elle ne sait pas faire : comprendre les utilisateurs, prioriser sous contrainte, dire non, maintenir une vision cohérente dans le temps. Autrement dit, le cadrage et l'arbitrage n'ont jamais été aussi décisifs — parce que plus on construit vite, plus une mauvaise décision coûte cher.
C'est d'ailleurs ce que nous voyons chez les équipes tech les plus efficaces : leur facteur limitant n'est plus le développement, dopé par les outils. C'est la qualité de la décision produit en amont. Une direction produit senior, capable de trancher et d'assumer, vaut aujourd'hui plus qu'une équipe qui génère des spécifications à la chaîne.