Tenir une roadmap produit quand tout le monde réclame de l'intelligence artificielle

Les trois sources qui remplissent une roadmap produit : les clients, les commerciaux, les concurrents

Trois sources remplissent une roadmap produit, et elles se ressemblent d'un éditeur de logiciel à l'autre, quel que soit le secteur concerné ou la taille de l'entreprise. Les clients demandent ce qui leur manque aujourd'hui, dans leur usage quotidien du produit, avec toute la légitimité de qui paie chaque mois et fait vivre l'entreprise par son abonnement renouvelé sans discuter. Leur voix mérite d'être entendue en premier, pas nécessairement suivie sans recul.

Les commerciaux relaient ce qui bloque une vente en cours, une fonction absente qui fait perdre un client potentiel face à un concurrent mieux équipé sur ce point précis, au moment précis où ça compte le plus pour conclure le contrat. Leur voix porte fort parce qu'elle se traduit immédiatement en chiffre d'affaires visible, contrat par contrat, mois par mois, dans les chiffres présentés en comité.

Les concurrents, enfin, sortent une fonction et l'équipe se sent obligée de répondre, par crainte de paraître en retard aux yeux du marché et des clients qui comparent les offres avant de renouveler. Cette source pousse souvent le plus vite vers une décision hâtive, et c'est justement ce qui la rend risquée quand elle décide seule, sans être confrontée aux deux autres sources avant de trancher. Prendre le temps de vérifier change souvent la réponse apportée.

Pourquoi aucune des trois voix ne doit décider seule de votre roadmap produit

Aucune des trois voix ne connaît l'ensemble du produit et de sa trajectoire à moyen terme, chacune voit midi à sa porte et défend sa vision limitée. Le client qui demande une fonction connaît son propre usage, pas celui des mille autres clients qui n'utilisent pas le produit de la même façon que lui, avec d'autres contraintes, d'autres habitudes et d'autres priorités du moment. Sa demande reste légitime, elle ne suffit simplement pas à elle seule pour décider.

Le commercial qui pousse pour débloquer une vente pense à ce contrat précis, rarement à ce que la fonction coûtera à maintenir pendant les cinq années suivantes, une fois le contrat signé et son attention tournée vers la prochaine vente à conclure, sur un autre dossier qui presse déjà autant que le précédent. Sa priorité du jour n'est pas forcément celle du produit dans son ensemble, et les deux se confondent rarement.

Le concurrent qui a sorti une fonction l'a fait pour ses propres clients, avec ses propres contraintes techniques et son propre historique de produit, pas les vôtres. Copier sans vérifier si elle sert votre base installée revient à construire pour un produit qui n'est pas le vôtre, avec un public qui n'est pas le sien non plus, et des attentes différentes. Vérifier avant de copier évite bien des chantiers inutiles menés dans la précipitation.

Une roadmap produit solide écoute les trois voix sans en laisser aucune trancher seule à sa place. Elle croise chaque demande avec ce qu'elle sait déjà du produit : combien de clients seraient réellement concernés, ce que la fonction coûtera à maintenir sur la durée, et si elle s'inscrit dans la direction choisie ou la contredit ouvertement, quitte à déplaire à celui qui a le plus insisté. C'est ce travail de recoupement qui distingue une roadmap pilotée d'une roadmap subie.

Une fonction demandée fort n'est pas forcément une fonction utile : comment arbitrer

Une fonction demandée fort et une fonction utile ne se recouvrent pas toujours, loin de là, et la confusion entre les deux remplit beaucoup de roadmaps de fonctions bruyantes plutôt qu'utiles à la majorité des clients réels. La demande forte vient d'une voix qui insiste, parfois un seul client très présent en réunion, parfois un commercial pressé de conclure un dossier chaud avant la fin du trimestre.

L'utilité se mesure autrement : combien de clients en profiteraient réellement une fois la fonction disponible, pas seulement ceux qui l'ont demandée à voix haute lors d'un appel ou d'une réunion, et ce que la fonction rapporterait comparé à ce qu'elle coûtera à construire puis à faire vivre dans le produit pendant des années, sans jamais être remise en question ensuite. Ce sont deux chiffres différents, et confondre l'un avec l'autre coûte cher sur la durée.

Une méthode simple aide à trancher : demandez, pour chaque fonction proposée, combien de clients l'utiliseraient vraiment si elle existait demain, pas combien l'ont réclamée en réunion ou par mail au cours des derniers mois. L'écart entre les deux chiffres révèle souvent qu'une demande bruyante ne représente qu'une poignée de cas isolés, quand une fonction plus silencieuse répondrait à un besoin partagé par toute la base installée, sans que personne ne l'ait réclamé haut et fort.

Le coût caché d'une fonction que vous gardez dans le produit pour toujours

Une fonction ajoutée au produit n'y entre jamais seule, elle traîne toujours autre chose derrière elle, invisible au moment du lancement. Elle apporte avec elle du code à maintenir, des tests à faire passer à chaque mise à jour du produit, une ligne de documentation à tenir à jour, et une case de plus à cocher chaque fois qu'un client demande une nouvelle intégration à construire autour du produit.

Ce coût ne se voit pas le jour du lancement, il s'accumule ensuite, année après année, exactement comme la dette technique décrite dans notre guide du logiciel sur mesure. Une fonction utilisée par trois clients sur mille continue de coûter à l'équipe autant qu'une fonction utilisée par tous, sans rapporter à la même échelle ni justifier cette charge d'entretien permanente qui pèse sur l'équipe technique.

Avant d'inscrire une fonction dans la roadmap produit, poser la question du retrait, et pas seulement celle de l'ajout, change souvent la décision prise en réunion ce jour-là. Si personne n'imagine pouvoir un jour retirer cette fonction sans froisser un client fidèle, mieux vaut être certain qu'elle mérite vraiment d'entrer dans le produit pour de bon, sans retour en arrière possible dans deux ou trois ans.

Comment tester une idée avant de l'inscrire dans la roadmap produit

Inscrire une idée dans la roadmap produit avant de l'avoir testée revient à s'engager sur un pari, parfois coûteux, sans savoir à l'avance s'il sera gagnant. Une conversation avec cinq clients qui ont exprimé le besoin, avant d'écrire la moindre ligne de code, révèle souvent que le problème réel diffère légèrement de ce que la première demande laissait penser au départ, une fois qu'on gratte un peu.

Une version réduite, construite pour vérifier l'usage réel plutôt que pour couvrir tous les cas imaginables dès le premier jour, permet de savoir vite si l'idée tient la route ou pas. Notre chapitre sur le produit minimum détaille comment construire cette première version sans y engager plus que ce que le test exige réellement, ni un jour de plus. Le but tient en une réponse à une seule question précise, la perfection viendra après si l'usage se confirme.

Si personne ne l'utilise une fois disponible, même auprès des clients qui l'avaient demandée le plus fort au départ, la roadmap produit vient d'éviter un chantier qui aurait coûté bien plus cher à construire en entier avant de découvrir la même chose, mais trop tard pour reculer facilement et sans dommage pour l'image du produit auprès des clients déçus. Un test raté coûte toujours moins cher qu'un lancement raté.

Où placer une fonction d'intelligence artificielle sans arrêter le reste de la roadmap

Une fonction d'intelligence artificielle pose une difficulté que les autres fonctions ne posent pas de la même façon : elle attire l'attention du comité de direction plus que n'importe quel autre sujet du moment, elle peut vite prendre toute la place dans les discussions internes, et elle risque de faire passer le reste de la roadmap produit au second plan pendant des mois entiers, sans que personne ne l'ait vraiment décidé.

La bonne place pour ce sujet n'est pas en tête de liste par défaut, ni écartée par prudence excessive face à la nouveauté. Elle se juge comme n'importe quelle autre fonction : combien de clients en profiteraient réellement, ce qu'elle coûterait à construire et à maintenir sur la durée, et si elle sert la direction choisie pour le produit ou la détourne de sa trajectoire initiale. Rien ne justifie de lui appliquer une règle différente du reste de la roadmap.

Sur ce sujet précis, deux voies existent selon le temps et les compétences disponibles en interne : faire développer directement dans le dépôt du produit avec vos propres développeurs, via un développement mené dans votre dépôt de code, ou faire construire un composant autonome branché ensuite à votre produit, sans mobiliser toute l'équipe sur un sujet nouveau pour elle. Les deux permettent de traiter le sujet sans arrêter le reste de la roadmap pendant que l'équipe apprend en parallèle, à son rythme.

Ce qu'on dit à un client qui réclame une date

Un client qui réclame une date précise pour une fonction pas encore construite mérite une réponse honnête, pas une date inventée sur le moment pour le rassurer et clore rapidement la conversation. Une date donnée sans certitude réelle devient, tôt ou tard, une promesse non tenue, et une promesse non tenue coûte plus cher en confiance qu'un délai franchement annoncé comme incertain dès le départ, sans faux espoir donné à personne.

Dites plutôt où se situe la fonction dans vos priorités actuelles, et ce qui ferait qu'elle avance plus vite ou plus lentement selon les mois qui viennent et les autres chantiers en cours. Un client comprend souvent mieux une explication honnête sur l'arbitrage en cours qu'une date qui s'avérera fausse dans trois mois, une fois les priorités révisées en interne sans qu'il en soit informé à temps. La transparence coûte moins cher que le silence, même si elle demande plus de courage sur le moment.

Si la fonction concerne un sujet où le client a un poids réel dans votre chiffre d'affaires, dites-le à votre équipe produit ouvertement, comme un critère parmi d'autres à considérer dans l'arbitrage, plutôt que de le laisser peser en silence sur une roadmap produit qui prétend rester neutre alors qu'elle ne l'est jamais tout à fait dans les faits. Mieux vaut le dire ouvertement que de le laisser influencer les choix sans que personne ne l'assume.

Les signes qu'une roadmap produit est devenue une liste de courses

Une roadmap produit devenue une liste de courses présente des signes reconnaissables, une fois qu'on sait où regarder et qu'on ose regarder honnêtement. Le premier : chaque ligne vient d'une demande extérieure, plus aucune fonction n'y figure parce que l'équipe produit l'a jugée utile de sa propre initiative, après avoir observé l'usage réel des clients sur le terrain, sans qu'on la lui ait réclamée.

Le deuxième signe : personne ne sait plus dire pourquoi une fonction précède une autre dans l'ordre choisi, l'ordre suit simplement la date à laquelle chaque demande est arrivée, ou l'intensité de la personne qui la réclame le plus souvent en réunion, sans autre critère de tri ni méthode d'arbitrage partagée par l'équipe. Chacun défend sa priorité du moment, et la roadmap finit par ressembler à un empilement plutôt qu'à un choix assumé.

Le troisième signe, le plus révélateur : la liste ne raccourcit jamais, elle s'allonge seulement, parce que personne ne retire une fonction ancienne pour en ajouter une nouvelle jugée plus utile aujourd'hui par les clients réels. Une roadmap produit qui grossit sans jamais se resserrer a cessé d'être un choix pour devenir un inventaire de tout ce qu'on vous a un jour demandé, sans jamais rien trier.

Qui tient la roadmap produit, et pourquoi ça ne peut pas être tout le monde à la fois

Une roadmap produit tenue par tout le monde à la fois n'est tenue par personne, en pratique, malgré les bonnes intentions de départ. Chaque service qui pèse dessus, commercial, support, direction, apporte une information utile à sa manière, mais la décision finale sur l'ordre choisi doit revenir à une seule personne ou à un petit groupe stable, qui porte ensuite la responsabilité des choix faits devant le reste de l'entreprise.

Cette personne écoute les trois sources décrites plus haut sans en devenir l'exécutante docile, au service de la voix la plus forte du moment. Son travail consiste à transformer des demandes en priorités argumentées, puis à défendre ces priorités quand la voix la plus forte du moment réclame un passage devant tout le monde, en réunion ou par un mail urgent envoyé un vendredi soir. Tenir cette ligne demande de la constance, surtout face à une voix qui insiste.

Dans une équipe de 10 à 150 personnes, ce rôle revient souvent à celui qui connaît le mieux le produit et sa base installée, pas nécessairement à celui qui porte le titre le plus haut sur l'organigramme officiel de l'entreprise. Ce qui compte, c'est que la responsabilité de trancher soit claire et connue de toute l'équipe, sans ambiguïté possible sur qui décide au bout du compte. Une équipe qui le sait discute moins et avance plus vite.

Ce que nous construisons avec les éditeurs qui tiennent une roadmap produit

Nous aidons des éditeurs de logiciel à faire avancer une fonction d'intelligence artificielle sans que le reste de leur roadmap produit s'arrête pendant des mois, en développant directement dans leur dépôt de code avec leurs propres développeurs, ou en construisant un composant autonome qu'ils branchent ensuite à leur produit existant, sans bousculer le reste de leurs chantiers en cours. Le rythme du reste de la roadmap continue, pendant que ce sujet précis avance en parallèle.

C'est ce que nous avons fait avec Cortex OS : intégrer un moteur d'intelligence artificielle générative dans un produit déjà vendu, pendant que l'équipe continuait à avancer sur le reste de sa roadmap sans interruption ni ralentissement notable. Le détail se trouve sur notre page cas Cortex OS, avec ce qui a été construit précisément et comment le chantier s'est déroulé.

Si l'intelligence artificielle vient de rejoindre votre roadmap produit et que vous cherchez encore où la placer sans tout arrêter autour, notre guide sur l'intelligence artificielle dans un logiciel édité reprend les questions à trancher avant de vous lancer dans le chantier. Nous écrire directement fonctionne tout aussi bien si vous préférez en discuter avec quelqu'un plutôt qu'avec une page.