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. Nous sommes pourtant convaincus que, dans beaucoup d'équipes produit, c'est 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 en retenons trois, qui reviennent à chaque fois que la question se pose. 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.
Un exemple : la même spécification en vingt exigences ou en dix lignes
Prenons une demande banale : « permettre aux clients d'exporter leurs factures ». Soumise telle quelle à un assistant, elle revient en une page structurée dont voici un extrait représentatif — nous l'avons raccourci, l'original en comptait une vingtaine.
Avant — généré, non relu
- Le système doit permettre l'export des factures aux formats PDF, CSV, XLSX et JSON.
- L'utilisateur doit pouvoir filtrer par période, statut, montant, devise et client associé.
- L'export doit être disponible en téléchargement immédiat ou envoyé par e-mail de façon asynchrone.
- Le système doit gérer les exports de plus de 10 000 factures par traitement différé avec notification.
- Les factures en devises étrangères doivent être converties au taux du jour, avec option de taux historique.
- Un journal d'audit doit tracer chaque export avec l'identité, l'horodatage et l'adresse IP.
- L'export doit respecter les permissions multi-rôles et le cloisonnement multi-entités.
- … et treize autres exigences du même ordre.
Après — décidé, relu, assumé
- Un bouton « Exporter » sur la liste des factures, visible par le titulaire du compte uniquement.
- Format : PDF des factures sélectionnées, dans une archive. CSV plus tard si des clients le demandent.
- Filtre : la période, déjà présente sur la liste. Rien d'autre pour cette version.
- Au-delà de 200 factures, l'export est envoyé par e-mail ; en dessous, téléchargement direct.
- Hors périmètre : devises, multi-entités, journal d'audit — aucun client ne l'a demandé.
- Critère d'acceptation : un client exporte six mois de factures en moins d'une minute, sans appeler le support.
Les deux textes parlent de la même fonctionnalité. Le premier contient sept décisions que personne n'a prises — multi-format, multi-devise, multi-entité, audit — et qu'un développeur consciencieux implémentera, ou passera une heure à contester. Le second contient trois décisions assumées, un périmètre explicitement exclu et un critère de réussite. Il a demandé vingt minutes de réflexion de plus et il fera gagner des semaines. C'est un exemple construit, pas un cas client — mais toute équipe qui a déjà généré une spécification y reconnaîtra la sienne.
Ce que mesurent les études : plus vite, oui ; plus solide, non
Nous ne sommes pas les seuls à constater que le volume produit par l'IA ne se traduit pas mécaniquement en efficacité. Le rapport DORA 2025 de Google Cloud, qui a interrogé près de 5 000 professionnels, observe que l'adoption de l'IA est désormais quasi générale et qu'elle va de pair avec un débit de livraison plus élevé — mais que l'instabilité des livraisons continue d'augmenter, et que l'idée selon laquelle la vitesse compenserait cette instabilité par des corrections plus rapides ne se vérifie pas dans les données. Sa conclusion tient en un mot : l'IA est un amplificateur, qui renforce les forces des organisations solides et les dysfonctionnements des autres. Appliqué à la spécification, c'est exactement notre thèse : on produit plus vite, et ce qui casse, c'est ce qui n'avait pas été décidé.
L'autre enseignement vient de l'organisme de recherche METR, qui mesure le temps réel passé par des développeurs expérimentés sur des tâches tirées au sort avec ou sans IA. En juillet 2025, les développeurs se croyaient 20 % plus rapides avec l'IA alors que le chronomètre disait l'inverse ; avec les outils de la fin 2025, le ralentissement a disparu, sans qu'une accélération nette soit établie. Ce que METR maintient d'une étude à l'autre, c'est l'écart entre la vitesse ressentie et la vitesse mesurée : les estimations spontanées de gain sont, selon ses mots, « très peu fiables ». Une spécification générée en trente secondes donne précisément cette impression de vitesse. Ce qu'elle coûte se paie plus tard, chez les développeurs, en questions, en cas limites inutiles et en recette.
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 la règle que nous nous imposons pour l'intégrer 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.
Ce n'est pas qu'un point de vue de praticien. Andrew Ng, cofondateur de Coursera et ancien responsable de l'IA chez Baidu, l'a formulé sans détour à la Startup School de Y Combinator en 2025 : il ne voit pas le travail de product management — décider quoi construire — s'accélérer au même rythme que l'ingénierie, et il observe le ratio basculer. Pour la première fois de sa carrière, une de ses équipes lui a proposé de planifier un projet non plus avec un PM pour quatre ingénieurs, mais avec un PM pour un demi-ingénieur. Que l'on juge ce ratio raisonnable ou non, le signal est clair : le 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. C'est le métier que nous défendons : moins de pages, plus de décisions.
Questions fréquentes
L'IA va-t-elle remplacer le Product Manager ?
Non — elle déplace sa valeur. Ce qui devient bon marché, c'est la production de documents. Ce qui devient précieux, c'est la capacité à décider juste, à comprendre les utilisateurs, à arbitrer entre des contraintes et à maintenir une vision cohérente dans le temps. L'IA rend le cadrage encore plus décisif : plus on produit vite, plus une mauvaise décision coûte cher.
Les spécifications générées par l'IA posent-elles un problème de confidentialité ?
Potentiellement, oui. Spécifier, c'est décrire vos processus, vos règles métier, parfois des données clients. Avant d'utiliser un assistant grand public, vérifiez ce que l'éditeur fait des contenus saisis (conservation, entraînement des modèles), privilégiez une offre professionnelle avec un engagement contractuel sur les données, et n'y collez jamais de données personnelles réelles : des exemples anonymisés suffisent pour spécifier. C'est une règle d'équipe à écrire noir sur blanc, pas une consigne orale.