Pierre-Louis Auger
73 % des consultants Produit WeFiiT interrogés ont construit un prototype avec l'IA cette année, mais 33 % seulement disposaient d'une documentation produit réutilisable pour le faire. On revient ici sur ce que cet écart produit dans les équipes que nous accompagnons, et sur les pratiques qui aident à le réduire.
Chez un grand distributeur de mode et de maison, deux PM préparent chacun, pour leur rayon, le même arbitrage pour le comité produit : refondre le parcours de retour dans l'app, ou corriger l'écran où le client doit imprimer son étiquette, étape à laquelle un client sur deux abandonne. Marie suit les retours du rayon mode depuis quatre ans. Julien a repris ceux du rayon maison il y a deux mois, après une mobilité interne. L'exemple est fictif, mais nous avons rencontré des situations très proches sur plusieurs missions.
Tous deux construisent un prototype cliquable sur Lovable en une après-midi. Face aux directions métiers, Marie obtient une décision : l'étiquette sera remplacée par un QR code à présenter en point relais, et la refonte est reportée. Julien, lui, ne ressort qu'avec des questions auxquelles il ne sait pas répondre :
« Ton parcours respecte bien le délai légal de remboursement qu'on a validé l'an dernier ? », demande le juridique.
« Le retour en magasin sans étiquette, on ne l'avait pas déjà testé et abandonné ? », rappelle la directrice e-commerce.
L'outil et les prompts étaient comparables. Marie a pu nourrir le sien de ce que quatre ans sur le produit lui ont appris : pourquoi le retour sans étiquette avait été abandonné, ce que les clients disent de l'étape d'impression, ce que le juridique avait validé. Julien, lui, n'avait pas tous ces éléments et n'a pas pu les partager à l'IA avant de prototyper.
Sur nos missions, depuis que les PM prototypent avec l'IA, nous voyons ce type d'écart se répéter régulièrement. D'où une de nos convictions phare : quand le Product Building devient une commodité, la gestion du contexte devient le seul vrai avantage durable.
Pour vous restituer une vue d'ensemble de ce que nous voyons chez nos clients, principalement des grands groupes de secteurs variés (luxe, retail, hôtellerie, banque, tech, énergie, mobilité), nous avons posé début octobre trois questions à une cinquantaine de consultants Produit WeFiiT.
Cela confirme bien que dans nos missions, le sujet de qualité du contexte réutilisable qu'on peut donner à l'IA revient plus souvent que celui de savoir si les équipes peuvent, ou non, prototyper avec l'IA.
C'est d'autant plus vrai qu'on constate souvent que l'historique d'un produit et de ses contraintes est concentré dans la tête de quelques personnes. Ces même personnes peuvent parfois être amenés à changer poste : mobilité interne, réorganisation, fin de mission d'un prestataire, départ d'un Lead PM...
C'est typiquement le cas chez nous : un consultant finit toujours par quitter sa mission, et laisse à l'équipe de quoi continuer même après son absence.
Mais vos équipes sont-elles bien équipées face à ça ? Vos nouveaux arrivants souffrent potentiellement déjà du manque de contexte de documentation associé. Maintenant, avec un outil qui sort un prototype crédible en quelques heures il peut aussi fausser toutes vos prises de décisions.
Par contexte, on entend ce qu'un PM, ou un outil d'IA, doit savoir d'un produit pour prendre une décision informée, et qui ne tient pas dans un prompt. Sur nos missions, on le découpe en quatre volets.
Ces éléments existent généralement quelque part : dans des drives, des comptes rendus de réunion, des tickets ou la mémoire des équipes. Le travail consiste à les rendre retrouvables et à les tenir à jour, pour un nouvel arrivant comme pour un outil d'IA.
Pour un acteur du luxe, nous utilisons l'IA pour analyser le code en production et en tirer une description du fonctionnement actuel du produit : les écrans et parcours, les appels entre services, une partie des règles de gestion telles qu'elles sont implémentées. C'est utile pour repérer les écarts avec la documentation existante, ou pour en reconstituer une base quand il n'y en a pas. Le code ne dit rien, en revanche, de l'historique des décisions, des options abandonnées, ni des raisons d'une règle. Ttoutes les règles métier n'y figurent pas, certaines vivant dans des processus manuels ou des outils tiers. Le résultat est un point de départ, que l'équipe doit relire et compléter.
Pour une direction produit, il s'agit de rendre ces pratiques régulières sur 20, 30 ou 50 PM sans ajouter de comité. On a identifié quatre leviers pour le faire.
Cadrer les outils avec la sécurité. Une liste d'outils autorisés, des données fictives par défaut et une règle écrite sur ce qui peut aller en production. Important qu'elle soit facilement accessible des IA comme des humains concernés. Sans ce cadre, on voit les équipes osciller entre usages non déclarés (shadow IT) et interdiction générale de l'usage de l'IA.
Noter les décisions là où elles se prennent. Un journal de décisions (decision log) rempli en fin de comités : la décision, ses raisons, les options écartées. En atelier, on peut aussi faire travailler l'IA directement sur un support partagé (Miro et ses AI Flows, par exemple) : le groupe voit ce qu'elle produit, le corrige, et la décision est écrite avant la fin de la séance.
Confier l'organisation d'ensemble au Product Ops. Sans coordination, chaque PM range son contexte à sa façon, dans ses propres outils, et personne ne retrouve rien d'une équipe à l'autre. Le Product Ops définit donc un cadre commun : où ranger chacun des quatre volets du contexte (décision, utilisateur, métier et réglementaire, fabrication), avec quels outils, et qui y a accès, outils d'IA compris. Le contenu reste à la charge de chaque PM, qui tient à jour le contexte de son produit.
Mesurer le temps de reprise de contexte, c'est-à-dire le temps dont un nouvel arrivant a besoin pour comprendre pourquoi les décisions passées ont été prises. Il suffit d'interroger les arrivants après leur premier mois pour avoir un premier indicateur de la qualité du contexte transmis.
Trois dérives reviennent régulièrement sur nos missions.
Un contexte périmé. Une note sur les règles de remboursement antérieure à la dernière mise à jour des conditions générales de vente produit un prototype faux qu'il est très difficile de repérer. Pire, on risque de faire confiance aveuglement car le résultat est très convaincant... Dater chaque document et nommer la personne qui le maintient limite ce risque, mais ne l'écarte jamais entièrement, donc il convient de réaliser des audits réguliers.
Le shadow IT, c'est-à-dire l'usage d'outils non validés par la DSI. Par exemple, nous avons déjà vu des équipes placer de vraies commandes clients dans un outil de prototypage grand public pour aller plus vite. Dans un groupe régulé, un incident de ce type peut suffire à faire restreindre ces outils pour toute l'équipe (ou bien pire encore), d'où l'intérêt des données fictives par défaut.
La démo prise pour un produit. Comme quand tout se faisait dans Figma, une direction qui voit un prototype fluide peut le croire presque terminé, et la Tech hérite d'une promesse qu'elle n'a pas estimée. Inviter le lead dev aux revues et présenter le prototype comme une option à trancher évite ce malentendu.
À poser avant d'ouvrir l'outil, par écrit dans le ticket ou la page de Discovery.
Si dès première question vous n'avez pas de réponse, mieux vaut ne pas commencer à build tout de suite. Essayez de cadrer avant de vous lancer dans un build empirique qui risque de vous faire prendre beaucoup de mauvaise décisions.
Répondez par oui ou par non, une question par volet du contexte.
Quatre oui : votre contexte est assez structuré pour qu'un nouvel arrivant, ou un outil d'IA, s'en serve.
Deux ou trois oui : la base existe, il reste à identifier qui peut compléter ce qui manque.
Zéro ou un oui : le contexte dépend de quelques personnes, et chaque départ ou arrivée a un coût pour l'équipe et pour le produit : une repasse sur votre socle data est nécessaire avant de mettre en place du product building à l'échelle.
Vous vous reconnaissez dans ces situations ? Échangeons à partir de vos enjeux concrets : évaluer les usages de l’IA au sein de vos équipes produit ou passer à l’action en mettant en place les pratiques présentées dans cet article.
