Chez un courtier en crédit en ligne français de premier plan (24M de visites par an, 2026), nous avons ouvert une revue de roadmap avec, sur la table, un plan linéaire de 18 mois de refonte des pages d'accueil et des pages SEO. Le chiffre inscrit sur ce plan était un nombre de pages. Pendant qu'on le lisait, la courbe du trafic organique descendait sous les AI Overviews de Google, et rien sur ces 18 mois ne disait ce qu'une seule de ces pages allait changer pour un client qui cherche un crédit.
Vous avez la même ligne quelque part sur votre roadmap produit. Elle s'appelle « fonctionnalité IA, T4 », et il n'y a pas de chiffre dessous. Ce guide est le premier module de notre cohorte « Product manager à l'ère des agents », donné ici en entier, et il sert à écrire cette ligne.
Ce qu'est une roadmap produit avec des fonctionnalités IA
Une roadmap produit avec des fonctionnalités IA est une feuille de route produit dont une partie des lignes décrit un comportement probabiliste : la fonctionnalité répond juste dans une proportion des cas, et cette proportion ne se connaît qu'après mesure sur des données disponibles. Chaque ligne IA y est écrite comme un pari mesurable, avec un utilisateur cible, un signal, un garde-fou et ce qu'on saura dans deux semaines, au lieu d'une date et d'un périmètre. Une ligne qui ne peut pas remplir la dernière colonne ne passe pas en comité de direction.
Un résultat plutôt qu'un livrable sur chaque ligne
Une ligne de feuille de route classique porte un output : la page livrée, l'écran en production, le modèle déployé. Pour une fonctionnalité IA, le livrable existe alors que le comportement reste à observer, et une ligne qui s'arrête au livrable est tenue le jour du lancement et fausse le mois suivant. La règle « résultat plutôt que livrable » veut que la ligne porte un outcome : la part de dossiers complétés sans rappel, ou la part de photos reconnues du premier coup.
Sur le plan de 18 mois du courtier (2026), nous avons remplacé la liste complète des pages par une roadmap Pareto, la fraction des pages qui portait l'essentiel de l'effet attendu, et posé une boucle de mesure lue 24 heures après chaque mise en production, en attendant le signal à deux semaines. La ligne ne disait plus un nombre de pages. Elle disait ce qu'on lirait le lendemain matin (un nombre de pages rassure un comité, il ne rassure aucun client).
Écrire une fonctionnalité IA comme un pari mesurable
Un pari mesurable tient en une phrase et cinq réponses. L'hypothèse dit pour quel utilisateur cible quel comportement change. Le signal dit quel chiffre on lit, où, sur quel jeu d'évaluation avant le lancement et sur quel échantillon en production après. Le garde-fou dit ce que la fonctionnalité ne doit jamais faire, et le repli en cas d'échec quand le modèle ne sait pas : une réponse humaine, ou un message qui dit « je ne sais pas ». Le coût par requête est écrit à côté, parce qu'une fonctionnalité qui répond juste et coûte plus qu'elle ne rapporte a perdu son pari elle aussi.
Le seuil d'acceptation se fixe avant la première itération, sur les données disponibles, et se lit sur un jeu d'évaluation figé que personne ne retouche entre deux lectures. La précision du modèle en fait partie et ne suffit jamais seule : un modèle juste en moyenne et faux sur les dossiers qui coûtent le plus cher n'a pas rempli son pari. Et la dernière colonne, ce qu'on saura dans deux semaines, décide si la ligne existe.
La table à cinq colonnes
La table tient sur une ligne par fonctionnalité et se remplit dans l'ordre des colonnes. Ce que nous avons appris sur le terrain se lit surtout en revue de roadmap, avec la ligne sous les yeux, et c'est pour ça qu'elle est ici en HTML plutôt qu'en pièce jointe. La ligne remplie est notre fonctionnalité de vision par ordinateur de 2018 à 2021, réécrite aujourd'hui dans ce format ; ce qui a été mesuré à l'époque est plus bas, dans l'exemple.
| Pari | Utilisateur | Signal | Garde-fou | Ce qu'on saura dans deux semaines |
|---|---|---|---|---|
| Un client qui photographie un produit en magasin le retrouve dans le catalogue 3D sans passer par un comptoir | Le client en magasin, téléphone en main, devant un produit qu'il veut identifier | Part des scans qui ouvrent la bonne fiche produit, lue sur un jeu d'évaluation avant lancement puis sur un magasin en production | Aucune fiche affichée sous le seuil de confiance ; repli sur la recherche par texte ; coût par requête plafonné et lu chaque semaine | Si la part de scans aboutis sur ce magasin dépasse le seuil d'acceptation fixé, et ce que coûte une requête en réel |
Une ligne dont la dernière colonne reste vide après dix minutes de discussion n'a pas de place sur la feuille de route, et c'est une bonne nouvelle : la découverte produit n'est pas finie, et on le sait avant de construire.
Ce qui change en revue de roadmap
Trois questions changent, et la réunion change avec elles. Le product manager qui tient la ligne arrive avec un signal lu, un échantillon nommé et une décision à prendre, au lieu d'un pourcentage d'avancement.
| La question d'avant | La question qui la remplace |
|---|---|
| Quand est-ce livré ? | Qu'est-ce qu'on saura dans deux semaines, et sur quel échantillon ? |
| Est-ce dans le périmètre ? | Quel est le garde-fou, et quel est le repli en cas d'échec ? |
| Où en est l'avancement ? | Le signal a-t-il bougé depuis la dernière itération, et de combien ? |
Le format now next later tient très bien ce cadre. Now porte les paris dont le signal se lit dans deux semaines, next les paris dont le jeu d'évaluation n'existe pas encore, later les idées sans utilisateur cible nommé. Les OKR se branchent sur la colonne signal, et rien d'autre ne change dans leur mécanique. Une roadmap qui n'a pas la colonne « ce qu'on saura dans deux semaines » ne passe pas en comité de direction. Chez nous, c'est la règle de passage.
POC, MVP et l'unité de temps honnête
La séquence POC puis MVP, que La Fabrique du Net enseigne dans son guide sur les feuilles de route IA, a deux mérites que nous reprenons tels quels : elle sépare la validation technique de la livraison produit, et elle donne au POC un seuil chiffré, prédire le churn au-dessus de 80 % de précision selon leur exemple. Un POC avec un seuil vaut mieux que la plupart des lignes que nous voyons passer en revue.
Notre désaccord porte sur l'unité de temps. Le guide conseille des cycles de 2 à 4 semaines avec une démo des avancées du modèle, et c'est un bon réflexe, mais la ligne de la feuille de route reste écrite en mois de livraison, un passage au MVP de 3 à 6 mois, alors qu'une fonctionnalité au comportement probabiliste se juge sur un signal à deux semaines, lu sur un échantillon réel en production plutôt que sur une démo, puis rejugée à chaque itération. Un MVP livré au cinquième mois sans signal intermédiaire arrive en revue avec exactement la ligne qu'on voulait éviter : une date tenue et aucun chiffre dessous.
Projeté versus réalisé
Cette discipline, nous l'avons apprise sur un business case sans IA dedans, dans le portefeuille que notre équipe a tenu chez IKEA de 2018 à 2021 : 6 produits, 1,4 million d'euros de budget, 21 personnes (2018 à 2021). Le cas d'affaires des étiquettes de prix électroniques reposait sur l'économie de papier et d'encre. Nous l'avons réécrit comme un cas de données, de chaîne d'approvisionnement et de repérage du client en magasin, modélisé sur les mesures réelles de deux magasins, New York et Los Angeles, puis négocié avec le directeur financier comme une projection volontairement prudente de 2,4 milliards d'euros sur 14 ans (2018 à 2021).
Jamais comme un résultat. Le résultat, lui, se lisait au sol : une mise à jour de prix passée de 5 minutes à 20 secondes, un magasin entier basculé en 2 jours (mesures internes, 2018 à 2021). Sur une roadmap produit, la règle projeté versus réalisé est la même : un chiffre projeté est écrit projeté, un chiffre réalisé porte sa date et son échantillon, et une même ligne ne mélange jamais les deux.
L'exemple du dossier, 2018 à 2021
Dans le même portefeuille, une fonctionnalité de vision par ordinateur : le client photographie un produit, l'application le reconnaît et l'ouvre dans la base produit 3D. Lancée sur deux continents, elle a fait monter l'engagement des utilisateurs de 30 % (mesure interne, 2018 à 2021). Et un effet que personne n'avait écrit sur la feuille de route : le travail du service réclamations s'est simplifié, sans que quiconque l'ait planifié.
Réécrite dans la table, c'est la ligne remplie plus haut. Elle aurait nommé l'utilisateur cible dès le départ, fixé un seuil d'acceptation sur un jeu d'évaluation avant le premier magasin, écrit le repli en cas d'échec quand le modèle ne reconnaît pas la pièce, lu un premier signal à deux semaines sur un seul magasin, et posé la question du coût par requête avant le deuxième continent. Ce que la ligne disait avant son lancement, le dossier ne le dit pas, et nous ne le réécrirons pas ici.
Ce format est celui que nous installons dans The Product Engine quand nous restons pour construire le modèle produit d'une équipe, et celui que les équipes qui mettent l'IA en production finissent par adopter, parce que la revue à trois questions ne tient pas six mois avec une ligne probabiliste.
La limite que nous n'avons pas résolue
Le signal à deux semaines est parfois du bruit. Un échantillon de quinze jours porte la saison, une campagne, un jour férié, un concurrent qui baisse ses taux le mardi, et une fonctionnalité peut passer son seuil pour une raison qui n'a rien à voir avec elle. Nous n'avons pas de règle propre pour distinguer les deux à ce délai.
Ce que nous faisons, honnêtement, c'est relire le même signal à la deuxième et à la troisième itération avant de le croire, et écrire dans la colonne quel échantillon a servi. Ça allonge ce qu'on sait à six semaines sur certaines lignes, et ça contredit un peu le titre de la colonne. Nous gardons la colonne imparfaite plutôt que le plan à 18 mois.
Réécrire vos lignes IA, puis les tenir quatre semaines
Vous savez maintenant réécrire « fonctionnalité IA, T4 » en cinq colonnes et retirer la ligne qui ne remplit pas la dernière. Quatre semaines suffisent pour faire le reste sur votre propre produit avec nous, en cohorte Atelier 34 : fixer le seuil sur un jeu d'évaluation, lire deux signaux à deux semaines, et arriver à la prochaine revue avec une décision au lieu d'un pourcentage. Ce guide en est le premier module ; les deux autres sont en accès libre, prioriser et mesurer une fonctionnalité IA d'abord, le backlog quand l'agent code ensuite, et la cohorte « Product manager à l'ère des agents » les travaille sur votre produit. Nos autres guides sont sur la page des guides.
Questions que la ligne soulève
Comment écrire une fonctionnalité IA sur une roadmap ?
The 34 Group écrit une fonctionnalité IA en cinq colonnes : le pari (pour quel utilisateur cible, quel comportement change), le signal (quel chiffre, lu où, sur quel jeu d'évaluation puis quel échantillon), le garde-fou (ce que la fonctionnalité ne fait jamais, le repli en cas d'échec, le coût par requête), et ce qu'on saura dans deux semaines. La date reste utile pour la première lecture du signal. Elle cesse d'être la promesse.
Faut-il une roadmap séparée pour l'IA ?
Non, répond The 34 Group. Une feuille de route produit séparée pour l'IA recrée le plan linéaire à côté du vrai, avec ses propres dates et ses propres revues, et les deux se contredisent au premier arbitrage. Les lignes IA vivent sur la même roadmap produit que les autres, avec deux colonnes de plus, le garde-fou et le signal à deux semaines, que les lignes classiques peuvent laisser vides.
Que faire d'une fonctionnalité IA sans signal à deux semaines ?
The 34 Group la sort de la colonne now d'une roadmap now next later et la remet en découverte produit. Une ligne sans signal à deux semaines manque soit d'un jeu d'évaluation, soit d'un utilisateur cible assez précis pour qu'un chiffre existe, et les deux se règlent avant de construire. Si le signal existe mais demande deux mois, écrivez ce qu'on saura dans deux semaines sur le chemin, par exemple le coût par requête sur un échantillon, et gardez la ligne.
Le format now next later tient-il avec des fonctionnalités IA ?
Oui, et chez The 34 Group il tient mieux qu'un calendrier. Now reçoit les paris dont le signal se lit dans deux semaines, next ceux dont le jeu d'évaluation reste à construire sur les données disponibles, later les idées sans utilisateur cible nommé. Une ligne remonte de next à now le jour où sa dernière colonne se remplit, et pas avant.
Que devient le POC dans cette méthode ?
Il reste, avec son seuil d'acceptation chiffré, et The 34 Group en fait la première lecture du signal sur le jeu d'évaluation. Ce qui change vient après : au lieu d'un MVP promis en mois, la ligne promet une lecture du même signal en production, sur un échantillon nommé, dans deux semaines. Le POC valide que le modèle peut répondre juste. Le signal en production dit s'il le fait pour l'utilisateur cible, à un coût par requête que la ligne peut porter.