Seuls 11 % des consommateurs laisseraient une IA décider d'un achat à leur place (Gartner, mai 2026). La product discovery est la discipline des product managers : une phase de discovery où l'équipe produit mène la recherche utilisateur pour comprendre les besoins utilisateurs avant de construire. La discovery a un pendant moins connu, celle que vit l'acheteur. Cet article détaille le processus de product discovery, les outils, puis l'agentic discovery de Kleio.
Qu'est-ce que la product discovery ?
Définition de la product discovery
La product discovery (ou découverte produit) est la phase de product management où l'équipe produit identifie le bon problème et la bonne solution avant de développer. Une product discovery efficace repose sur trois piliers : la recherche utilisateur (user research), le feedback utilisateur et la validation des idées. Le product designer explore la solution, le développeur évalue le produit et les responsables produit arbitrent. Cette organisation produit sépare la discovery et la delivery. Le processus de product discovery réduit le risque du projet : l'équipe teste une hypothèse avant de développer la fonctionnalité. Chaque product builder y gagne une vision produit appuyée sur les besoins clients.
Pourquoi la product discovery est-elle cruciale ?
L'importance de la product discovery tient à une statistique que tout responsable produit connaît : la plupart des idées ne produisent pas l'impact attendu. Sans discovery, l'entreprise investit dans une fonctionnalité sur la foi d'une intuition, puis constate l'écart entre l'attente des utilisateurs et le produit livré. La discovery apporte une valeur ajoutée concrète : elle permet de définir le bon problème, de résoudre un besoin réel et de concentrer le budget de développement sur ce qui compte pour le marché. Elle limite aussi la perte de temps liée aux projets lancés sur un point de vue interne. Pour une entreprise, c'est un objectif de gestion du risque autant que de créativité.
Qui fait de la product discovery dans une équipe produit ?
Le product manager pilote la discovery avec un product designer et un développeur, parfois appelés product builders. Le product designer traduit la recherche en maquettes et en parcours testables. Le développeur évalue ce qui est réalisable et ce qui ne l'est pas. Les responsables produit arbitrent ensuite entre les opportunités. Ce trio partage la responsabilité des décisions : personne ne reçoit un cahier des charges déjà figé. Le product design et la gestion de produit agile se rejoignent ici, car la discovery alimente chaque itération du produit. La discovery est une discipline transverse du product management : elle permet de relier les utilisateurs, le design et le développement. Les entreprises qui veulent monter en maturité peuvent utiliser un guide interne qui décrit le rôle de chacun.
Discovery et delivery : deux pistes en parallèle
La discovery décide quoi construire. La delivery construit et livre. Beaucoup d'organisations les séparent en deux pistes qui avancent en parallèle : c'est le principe du dual track. Pendant que les développeurs livrent la fonctionnalité validée le mois dernier, l'équipe produit teste déjà les idées du mois suivant auprès des utilisateurs. Cette organisation évite la perte de temps des projets où l'on code d'abord et où l'on interroge ensuite. La product discovery nourrit la feuille de route en preuves plutôt qu'en opinions. Le cycle de discovery et de delivery se répète à chaque trimestre.
Les quatre risques de Marty Cagan
Marty Cagan, auteur de référence du product management, structure la discovery autour de quatre risques à lever avant le développement. Le risque de valeur : les clients achèteront-ils ou utiliseront-ils le produit ? Le risque d'utilisabilité : les utilisateurs comprendront-ils comment s'en servir ? Le risque de faisabilité : l'équipe peut-elle le construire avec ses compétences et sa technologie ? Le risque de viabilité : la solution fonctionne-t-elle pour l'ensemble de l'entreprise, y compris la vente et le juridique ? Chaque risque a un propriétaire : le product manager porte la valeur et la viabilité, le designer l'utilisabilité, l'ingénieur la faisabilité (SVPG, Marty Cagan).
La continuous discovery de Teresa Torres
Teresa Torres a popularisé la continuous discovery : au minimum un contact hebdomadaire avec des clients, mené par l'équipe qui construit le produit, via de petites activités de recherche tournées vers un résultat produit visé (Continuous Discovery Habits). Son outil central, l'opportunity solution tree, relie un objectif produit à des opportunités issues des interviews, puis à des solutions et à des expériences. L'équipe produit y visualise ses suppositions et choisit quoi tester. Cette approche installe la discovery comme une habitude de l'organisation produit et non comme une phase ponctuelle avant un lancement.
Comment réussir sa product discovery : étapes, techniques et outils ?
Les étapes d'une product discovery efficace
Un processus de product discovery efficace suit des étapes que toutes les équipes adaptent à leur contexte :
- cadrer le problème et le résultat attendu avec les parties prenantes
- mener la recherche utilisateur par des entretiens et des observations
- identifier les besoins utilisateurs, puis formuler des suppositions à valider
- imaginer plusieurs solutions et les prioriser selon la valeur et l'effort
- construire un prototype ou un test minimal pour obtenir un retour rapide
- décider de poursuivre, d'ajuster ou d'abandonner l'idée
Chaque étape de la product discovery produit un livrable : une synthèse de recherche, une liste d'hypothèses classées, un prototype testé. Le processus agile boucle plusieurs fois avant la phase de delivery. La validation des idées reste le but : une idée n'avance que si elle résiste au test auprès d'utilisateurs réels. Ces étapes de la product discovery se retrouvent dans toutes les méthodes : réussir sa product discovery, c'est d'abord accepter de remettre en cause ses idées. Pour structurer la création produit, les organisations peuvent utiliser une feuille de route d'suppositions et un accompagnement externe, un coach ou un référent interne, qui garantit la cadence.
Comment réussir la recherche utilisateur ?
La recherche utilisateur est le cœur de la discovery. Pour réussir, l'équipe produit interroge des personnes qui vivent réellement le problème, pas des collègues. Un entretien dure une demi-heure et explore des situations vécues, pas des opinions sur un produit hypothétique. Poser la question « que feriez-vous si ? » produit des réponses polies mais fausses. Mieux vaut demander « racontez-moi la dernière fois que » : l'utilisateur décrit un comportement observable. La synthèse regroupe ensuite les verbatims en opportunités, que le product manager classe par fréquence et par impact.
Les techniques de product discovery qui fonctionnent
Les techniques de product discovery se répartissent en deux familles. La recherche qualitative regroupe les entretiens utilisateurs, les observations terrain et les tests d'utilisabilité. La recherche quantitative regroupe les questionnaires, les données d'usage et les tests A/B. Le design thinking et le double diamant structurent l'alternance entre divergence (explorer le problème) et convergence (choisir la solution). Le concept de produit minimum viable, un test à coût réduit, permet de confronter une idée à de vrais utilisateurs en quelques jours plutôt qu'en quelques mois. Le choix de la technique dépend du risque à lever et non d'une mode méthodologique.
Quels outils pour la product discovery ?
Les outils de product discovery couvrent quatre usages : centraliser la recherche utilisateur, cartographier les opportunités, prototyper et prioriser la feuille de route. Une équipe produit utilise un outil de prototypage pour tester des maquettes, un outil d'entretien pour enregistrer et analyser la voix du client et un outil de gestion de projet pour suivre les idées, comme Jira Product Discovery. Les organisations qui s'appuient déjà sur Jira pour la gestion de projet flexible y rattachent souvent leur backlog d'idées. Les plateformes low code permettent aussi de prototyper sans écrire une ligne de code. Jira Service Management ou un autre outil de gestion de projet reste utile pour suivre les demandes mais il ne se substitue pas à la recherche. Un site web de test ou une application de démonstration suffisent souvent à valider une supposition. Les outils de product discovery doivent être choisis selon l'étape et le risque à lever. L'outil compte moins que la discipline : une équipe qui ne parle jamais à ses utilisateurs ne gagnera rien avec un meilleur logiciel.
Conseil d'expert
avant d'acheter un outil, fixez la cadence de contact utilisateur de votre équipe produit. Un entretien par semaine avec un outil gratuit vaut mieux qu'un abonnement sans entretien.
Un exemple de product discovery pas à pas
Prenons l'exemple d'une application de réservation de salles de réunion. L'équipe produit formule une hypothèse : les assistantes réservent trop tard car elles ne voient pas les salles libres en temps réel. Elle mène cinq entretiens, découvre que le vrai problème est l'incertitude sur les équipements, puis construit un prototype qui affiche les équipements avant la réservation. Le test auprès de huit utilisateurs valide l'supposition en deux semaines. L'équipe a évité de développer un calendrier en temps réel coûteux. Cet exemple illustre le principe : la discovery transforme une idée de fonctionnalité en question testable.
Atelier de cadrage : définir le problème avant la solution
Un atelier de cadrage d'une demi-journée permet de définir le problem space avant de concevoir une solution. L'équipe liste les attentes des clients, écarte chaque feature qui ne répond à aucune d'elles et aligne les participants sur une même formulation du problème. Cet atelier est aussi un moment de culture produit : il rappelle que la value proposition se construit en partant de l'utilisateur. Un bon cadrage permet de concevoir des solutions plus ciblées, de définir des critères de succès partagés et de rester aligné sur l'objectif attendu. Parmi les clés de réussite : une solution testée tôt, des attentes explicites et une équipe alignée sur la valeur recherchée. Ce qui peut être décisif, c'est la culture d'équipe : le conseil le plus utile reste de documenter chaque décision pour permettre à l'équipe de la revoir. Il faut aussi être capable d'abandonner une solution séduisante qui ne répond pas à l'attente des utilisateurs et savoir définir à l'avance ce qui ferait changer d'avis.
Le vocabulaire anglais de la discovery : product team, tech lead, insights
Les équipes françaises emploient un vocabulaire anglais qu'il faut décoder. La product team regroupe le product manager, le designer et le tech lead. Une feature est une fonctionnalité, un insight est un enseignement tiré de la recherche et le customer discovery désigne la recherche menée auprès des clients. Le framework est le cadre de travail partagé, le build correspond à la construction et le work in progress aux idées en cours de test. Les décisions s'appuient sur la data et sur chaque information remontée du terrain. Comprendre ce vocabulaire est une clé pour lire les ouvrages de référence : il permet de suivre les échanges d'une équipe internationale et de savoir comment le travail est priorisé dans un process de discovery. Une stratégie produit lisible sur tout le cycle repose sur ces mots partagés.
Comment documenter et partager une product discovery ?
Une bonne discovery laisse une trace lisible. Une fiche de synthèse par cycle regroupe le problème, les hypothèses, les résultats des tests et la décision prise. Un template simple suffit : objectif, utilisateurs interrogés, enseignements, prochaine étape. La lecture de ces fiches permet aux nouveaux arrivants de comprendre l'historique des choix produit. Elle aligne aussi les parties prenantes sur la vision et sur la feuille de route, sans repasser par de longues réunions.
Comment se former à la product discovery ?
Se former à la product discovery passe par trois leviers : la lecture des ouvrages de référence, la pratique encadrée par un coach produit et la culture d'équipe. Une formation de deux jours donne un cadre méthodologique mais seule la répétition des entretiens installe le réflexe. La plupart des organisations qui réussissent désignent un binôme chargé de monter la pratique, puis étendent la démarche équipe par équipe. Il est également utile de cadrer les attentes des dirigeants dès le départ : la discovery produit des décisions, pas des livraisons immédiates.
Quelle place pour l'intelligence artificielle dans la discovery ?
L'intelligence artificielle accélère la synthèse des entretiens, le regroupement des verbatims et la rédaction d'suppositions. Elle ne remplace pas le contact avec l'utilisateur. Une équipe produit gagne du temps sur l'analyse mais doit garder la conversation humaine pour comprendre le contexte. Le même constat vaut côté acheteur, comme le montre la suite de cet article.
Réussir sa product discovery : quel accompagnement choisir ?
Réussir sa product discovery demande souvent un accompagnement product discovery extérieur lors des premiers cycles. Un coach aide à structurer la création produit : il explique comment enchaîner les étapes de la product discovery, comment mener un entretien sans biais et comment présenter les conclusions aux dirigeants. Les formations product les plus utiles mêlent théorie et pratique sur un vrai sujet de l'entreprise. Un guide complet ne remplace pas ce travail : l'importance de la product discovery se comprend en la pratiquant sur son propre produit. Les outils de product discovery viennent ensuite, quand la méthode est installée. Dans une organisation, la discovery est une discipline qui s'apprend par répétition et la discovery product management devient alors un réflexe d'équipe. Pour suivre l'avancement, beaucoup d'équipes utilisent un tableau Jira de gestion de projet adapté aux idées et aux suppositions. Mesurer l'impact de ce travail passe par un point mensuel avec les responsables produit : on y mesure l'impact sur le produit des décisions prises grâce à la discovery.
Comment éviter les pièges de la product discovery ?
Quatre pièges reviennent dans la plupart des organisations. Confondre discovery et validation : l'équipe cherche à confirmer son idée au lieu de la tester. Interroger les mauvais utilisateurs : un échantillon d'amis ou de clients historiques fausse les suppositions. Rester sur des opinions : sans feedback utilisateur réel, la feuille de route reflète le plus fort en réunion. Enfin, séparer la discovery de l'équipe de développement : le product manager découvre seul et transmet ses conclusions, ce qui détruit le bénéfice du trio. Éviter les pièges de la product discovery demande une discipline de cadence plus que de méthode.
Comment mesurer l'impact de la product discovery ?
Mesurer l'impact de la discovery revient à mesurer la qualité des décisions produit. Des indicateurs de performance utiles : le nombre d'hypothèses testées par mois, la part de fonctionnalités livrées qui atteignent leur objectif d'usage, la satisfaction utilisateur après lancement et le temps économisé sur les développements abandonnés. Une discovery efficace réduit les projets annulés en cours de route. Son impact sur le produit se juge donc à la baisse du risque avant chaque livraison et non à la quantité de documents produits. Mesurer l'impact exige de fixer les indicateurs avant la discovery et non après : sans objectif chiffré au départ, aucune équipe ne peut conclure. L'importance de la product discovery se démontre alors par un point simple, le coût évité.
La product discovery côté acheteur : l'autre moitié du problème
La plupart des guides de product discovery s'arrêtent à l'équipe produit. Pourtant, l'acheteur vit lui aussi une discovery : celle d'un produit qu'il ne connaît pas encore, parmi un catalogue qu'il ne maîtrise pas. Le tableau ci-dessous compare les deux.
Quand l'acheteur ne sait pas ce qu'il cherche ?
Environ 60 % des acheteurs ne savent pas ce qu'ils veulent au démarrage d'un parcours high-consideration (donnée Kleio). Un voyageur qui cherche « un séjour au soleil en famille » ou un ménage qui cherche « un appartement près d'une école » ne formule pas de requête précise. Leur besoin se précise en découvrant des offres, pas avant. Le parcours d'achat fonctionne donc comme une discovery où l'acheteur apprend ce qu'il aime en voyant ce qui existe, dans l'hospitality, le real estate, le travel ou l'automotive retail.
Pourquoi filtres et moteurs de recherche ne suffisent pas ?
Un filtre à facettes suppose que l'acheteur connaît déjà ses critères : budget, surface, motorisation. Un moteur de recherche textuel suppose qu'il sait nommer ce qu'il veut. Dans un catalogue complexe, aucune de ces deux suppositions ne tient. Une application mobile ou web de réservation pose le même problème qu'un site de concession ou une agence immobilière : le client doit être capable de nommer son besoin pour utiliser le moteur de recherche. L'acheteur abandonne alors ou choisit au hasard ou transfère sa question à un conseiller qui n'a pas le temps de tout traiter. Cette perte est invisible dans les statistiques de conversion, qui comptent les acheteurs sortis et non ceux jamais arrivés à une préférence. Le conseil habituel, ajouter des filtres, ne permet pas de résoudre ce problème : l'application la plus riche en filtres reste muette face à un acheteur qui ne sait pas quoi demander.
Ce que dit Gartner sur l'IA et l'achat
Selon Gartner (enquêtes américaines de novembre-décembre 2025 auprès de 846 personnes et de janvier 2026 auprès de 322 personnes), seuls 11 % des consommateurs laisseraient une IA décider d'un achat. En revanche, 28 % acceptent qu'elle restreigne le choix en électronique personnelle et 31 % en produits ménagers. Parmi les utilisateurs d'IA en shopping, 54 % revérifient tout ce qu'elle produit et 62 % estiment que les informations fournies par ces outils leur ont fait perdre du temps. L'enseignement est net : l'acheteur veut une aide à l'exploration, pas une décision déléguée.
Le saviez-vous ?
Seuls 11 % des consommateurs laisseraient une IA décider d'un achat mais 28 à 31 % acceptent qu'elle restreigne le choix (Gartner, mai 2026).
Agentic discovery : la product discovery externe pilotée par des agents IA
Définition de l'agentic discovery
L'agentic discovery désigne une discovery menée par des agents IA qui aident l'acheteur à construire une préférence en réagissant à de vrais produits. Elle ne consiste pas à exposer un catalogue à des agents externes. L'agent propose quelques produits réels, observe la réaction de l'acheteur puis révise sa proposition suivante. L'acheteur affine ainsi sa préférence sans avoir à la formuler d'emblée. Notre page dédiée détaille ce concept d'agentic discovery. Elle se distingue d'un assistant de FAQ : l'agent raisonne sur des attributs, des prix, des disponibilités et des relations entre produits.
La boucle : proposer, réagir, réviser
Le schéma ci-dessous montre la boucle de l'agentic discovery. Chaque réaction de l'acheteur, un refus compris, devient un signal : un refus pour cause de prix révise le budget estimé, un refus pour cause de distance révise la zone. La boucle converge vers une préférence assez claire pour passer à la réservation, au devis ou au rendez-vous avec un conseiller.
Cette boucle reprend la logique de la discovery produit : une supposition, un test, un apprentissage. Seul change celui qui apprend. Dans la product discovery interne, c'est l'équipe produit qui découvre ce que veulent les utilisateurs. Dans l'agentic discovery, c'est l'acheteur qui découvre ce qu'il veut, aidé par l'agent.
Diagnostic : votre parcours d'achat a-t-il un problème de discovery ?
Votre site laisse-t-il l'acheteur découvrir ce qu'il veut ou lui demande-t-il de le savoir déjà ? Répondez à quatre questions pour situer votre parcours.
Le résultat indique si votre parcours repose sur des filtres, sur une recherche textuelle ou sur une discovery guidée. Il ne remplace pas un audit mais il met des mots sur l'écart entre ce que votre catalogue propose et ce que vos acheteurs savent formuler.
Agentic discovery ou recommandation de produits ?
Un moteur de recommandation classique classe des produits à partir de l'historique de comportement. Il suppose donc un historique, ce qui manque pour un acheteur qui découvre une catégorie rare. L'agentic discovery fonctionne sans historique : elle part de la conversation et des réactions en direct. Pour approfondir la différence, consultez notre guide sur la recommandation de produits et notre analyse de la différence entre agentic discovery et agentic search. Les deux approches se complètent : la recommandation classe, la discovery guide la construction de la préférence. Dans une application de vente, qu'elle soit web ou mobile, la recommandation sert la dernière étape et la discovery sert les premières. Une application bâtie uniquement sur la recommandation laisse l'acheteur sans guide au départ ; une application qui intègre l'agentic discovery l'accompagne depuis son premier besoin.
Les terrains où la discovery se joue : hospitality, real estate, automotive
La discovery côté acheteur pèse le plus sur les achats high-consideration, c'est-à-dire à décision longue, gros catalogue et intention faible au départ. Dans l'hospitality et le travel, le voyageur découvre la destination en même temps que l'offre. Dans le real estate, l'acheteur révise son projet à chaque visite virtuelle. Dans l'automotive retail, il passe d'un budget à un usage puis à un modèle. Travel n'est pas Automotive et Real Estate n'est pas Wholesale : chaque secteur a sa propre logique d'exploration.
Kleio, la plateforme d'agentic discovery pour les achats high-consideration
Le Knowledge Engine : un catalogue vivant
Le Knowledge Engine de Kleio répartit le catalogue de nos clients en trois stores conçus pour leur usage : produits, documents et mémoire. L'agent interroge donc un catalogue vivant, avec prix et disponibilités à jour et non un export figé. Le Knowledge Engine atteint 99 % de précision sur les requêtes avec des réponses en moins de 3 secondes et zéro hallucination : l'agent ne répond qu'à partir de données approuvées. Notre article sur le Knowledge Engine détaille cette architecture.
La Triple Business Ontology
La Triple Business Ontology de Kleio superpose trois couches pré-construites : fonction, industrie et client. Elle existe pour 7 industries : Travel, Automotive, Real Estate, Wholesale, Manufacturing, Insurance, Energy & Utilities. Chaque application métier hérite de cette ontologie. Une application doit être capable de comprendre ce vocabulaire. Chaque industrie a ainsi son vocabulaire d'exploration : l'agent sait ce qu'est un critère déterminant pour un voyageur ou pour un acquéreur immobilier. Nous étendons cette ontologie au modèle de données du client en semaines.
Orpi, Selectour, Havas Voyages, Altarea Cogedim
Orpi a déployé la plateforme Kleio sur Orpi.com et dans ses 1 250 agences au service de 8 000 conseillers, en trois mois (voir le cas Orpi). Selectour équipe ses conseillers voyages et ses clients. Havas Voyages développe sa génération de leads par une expérience conversationnelle personnalisée. Altarea Cogedim absorbe la complexité de ses offres immobilières et de ses schémas de financement tout en libérant ses conseillers pour les moments à forte valeur.
Déployer en 8 à 12 semaines
Nous déployons Kleio en 8 à 12 semaines du lancement du projet à la production, dans un cadre SOC 2 avec isolation par locataire. Pas de plug-in à brancher sur votre catalogue : l'implémentation est accompagnée, avec votre équipe e-commerce et vos conseillers.
