La discovery est la première victime des contraintes de temps : quand la roadmap presse, on saute les entretiens et on décide sur des intuitions. L’IA arrive donc dans un contexte où la tentation est forte — non pas d’accélérer la recherche, mais de s’en passer. La distinction entre les deux est le sujet de cet article : ce qu’elle accélère réellement, ce qu’elle simule, et comment reconnaître la différence avant d’avoir construit six mois de fonctionnalités sur une connaissance fabriquée.
L’IA peut-elle remplacer la recherche utilisateur ?
Réponse courte
Non. Un modèle de langage peut produire ce qu’un utilisateur pourrait dire, en s’appuyant sur les textes de son corpus ; il ne peut pas produire ce que vos utilisateurs pensent, font et contournent réellement. Le test le plus cité sur le sujet, mené par le Nielsen Norman Group, a comparé des réponses d’« utilisateurs synthétiques » à celles de participants réels dans plusieurs de leurs propres études : les réponses générées se sont révélées trop superficielles pour être exploitables et systématiquement complaisantes, validant des concepts que de vrais utilisateurs remettaient en cause.
Ce biais de complaisance est le point le plus important à retenir. Un modèle entraîné à produire des réponses utiles et agréables ne dira pas spontanément qu’une idée est inutile, qu’un utilisateur ne l’essaierait jamais, ou qu’il continuerait à utiliser son tableur. Or c’est exactement l’information qui a de la valeur en discovery.
Ce qui reste, une fois cette limite posée, est loin d’être négligeable : l’IA agit puissamment sur tout ce qui entoure la recherche — la préparation, l’analyse, la formulation, la restitution. C’est là qu’il faut l’investir.
Ce que l’IA accélère réellement
Cinq usages tiennent parfaitement, parce qu’ils travaillent une matière que vous fournissez ou qu’ils portent sur votre propre raisonnement plutôt que sur les utilisateurs.
- Préparer un guide d’entretien : produire une trame à partir de vos hypothèses, puis faire repérer les questions orientées, fermées ou suggestives
- Analyser des entretiens : classer les verbatims par thème avec citation exacte et rattachement à la source
- Regrouper du feedback : traiter des centaines de tickets ou d’avis par problème sous-jacent plutôt que par mot-clé
- Formuler des hypothèses testables : transformer une intuition en énoncé falsifiable, avec le critère qui l’invaliderait
- Faire de la recherche secondaire : structurer des documents publics, réglementaires ou sectoriels que vous fournissez
Une boucle de discovery outillée — la recherche reste au centre
- Hypothèse formulée avec son critère d’invalidation
- Guide d’entretien préparé, puis critiqué pour les questions orientées
- Entretiens menés avec de vrais utilisateurs — étape non remplaçable
- Analyse assistée : verbatims classés, citations tracées
- Contrôle humain : relecture d’un entretien complet, vérification des cas rares
- Décision produit, avec la matière source citable
Faux personas et fausse discovery : le piège de l’IA
Le mécanisme est toujours le même, et il est confortable. Vous n’avez pas le temps de faire des entretiens. Vous demandez à un assistant de « jouer le rôle » d’un directeur financier de PME, ou de générer trois personas pour votre marché. Le résultat est cohérent, détaillé, immédiatement présentable. Il entre dans un atelier, il est repris dans une présentation, il devient une référence partagée — et plus personne ne se souvient de son origine.
Le problème n’est pas que ces personas soient faux à coup sûr. C’est qu’ils sont invérifiables et qu’ils portent trois biais documentés. La complaisance : les utilisateurs générés apprécient à peu près tout ce qu’on leur présente. L’idéalisation : ils décrivent des comportements rationnels et conformes à ce qu’on lit dans la littérature, pas les contournements réels, les habitudes tenaces et les usages détournés qui font l’essentiel de la vie d’un produit. Et l’absence de surprise : ils ne produisent jamais l’information que vous n’attendiez pas, qui est précisément ce que la recherche est censée trouver.
Le coût n’apparaît pas tout de suite. Il apparaît au lancement, quand la fonctionnalité construite sur cette connaissance n’est pas utilisée, et que personne ne sait dire pourquoi — parce qu’il n’existe aucune matière source à laquelle revenir.
Reconnaître une discovery fabriquée
Quelques questions suffisent à faire la différence, en atelier comme en revue de roadmap. Elles ne sont pas agressives : elles rendent simplement traçable ce qui doit l’être.
| Question à poser | Discovery réelle | Discovery fabriquée |
|---|---|---|
| D’où vient cette information ? | Entretien daté, ticket, enquête, observation | « C’est ressorti de l’analyse » sans source identifiable |
| Peut-on citer un verbatim ? | Citation exacte, rattachée à une personne ou un segment | Reformulation générique, aucun mot d’utilisateur |
| Qu’est-ce qui nous a surpris ? | Au moins un constat contraire à l’hypothèse de départ | Tout confirme ce que l’équipe pensait déjà |
| Qui a dit non ? | Des utilisateurs ont rejeté ou ignoré des idées | Toutes les propositions sont bien accueillies |
| Combien de personnes derrière ce constat ? | Un nombre connu, avec les segments concernés | Impossible à dire |
La règle de traçabilité
Une règle unique règle la plupart des dérives : toute affirmation sur les utilisateurs, dans un document produit, doit pouvoir être rattachée à une source identifiable — entretien, ticket, réponse d’enquête, mesure d’usage.
Concrètement, imposez la citation dans vos demandes d’analyse : chaque constat accompagné d’au moins un verbatim et de sa provenance. Refusez en revue tout constat non traçable. Et distinguez explicitement, dans vos documents, ce qui est constaté de ce qui est supposé — deux sections séparées suffisent.
Cette discipline a un effet secondaire utile : elle rend visible le moment où vous n’avez pas assez de matière. C’est une information précieuse, et c’est exactement ce que la génération automatique masque.
Un usage défendable des profils générés
Il existe un cas où faire jouer un rôle à un modèle a du sens : la préparation. Entraîner une équipe à conduire un entretien, tester si un guide tient la route, anticiper les objections d’un profil difficile avant un rendez-vous client, ou répéter une présentation face à un contradicteur.
La différence est nette : dans ces cas, la sortie n’est jamais utilisée comme une donnée. Elle sert d’exercice, et elle est jetée après usage. Personne ne la cite dans une décision produit.
La règle pratique tient en une phrase : un profil généré peut servir à s’entraîner, jamais à conclure. Si une production issue d’un modèle se retrouve citée dans un document de décision, la frontière a été franchie.
Ce que l’IA change quand la recherche existe déjà
Dans les équipes qui font réellement de la discovery, le gain est important et rarement mis en avant : c’est l’exploitation de la matière accumulée. La plupart des organisations disposent de dizaines d’entretiens, de milliers de tickets et d’années d’avis, dont l’essentiel n’a jamais été relu.
L’analyse transversale de ce corpus — regroupement par problème, détection des signaux récurrents, comparaison entre segments, évolution dans le temps — est devenue accessible. C’est probablement le meilleur investissement d’une équipe produit qui a déjà de la matière.
Second gain : la restitution. Transformer une analyse en synthèse lisible pour la direction, décliner le même constat pour l’équipe technique et pour le comité de direction, préparer les objections. Ce travail de communication consomme un temps considérable et se prête très bien à l’assistance, sans aucun risque de fabrication puisque la matière existe.
Le cadre à poser dans une équipe produit
Trois décisions suffisent, et elles se prennent en une réunion. Premièrement : aucune affirmation sur les utilisateurs sans source citable dans les documents de décision. Deuxièmement : les profils générés sont autorisés pour l’entraînement et interdits comme donnée. Troisièmement : les constats et les hypothèses sont visuellement séparés dans tous les livrables de discovery.
Ajoutez-y la question des données : les verbatims contiennent souvent des informations personnelles, et leur traitement relève de règles précises. La pseudonymisation avant analyse règle la plupart des cas sans dégrader le résultat — le cadre pratique des données sensibles détaille les catégories.
Le reste des usages produit — priorisation, PRD, critères d’acceptation, synthèse de feedback — est traité dans IA pour Product Owner : dix usages concrets.
Questions fréquentes
Combien d’entretiens réels faut-il malgré l’IA ?
+
L’IA ne change pas le nombre d’entretiens nécessaires pour voir apparaître les mêmes constats : elle change le temps d’exploitation. Concrètement, elle permet de traiter davantage de matière avec les mêmes ressources, pas de réduire le nombre de personnes à qui vous parlez.
Les utilisateurs synthétiques sont-ils totalement inutiles ?
+
Ils ont un usage défendable en préparation — s’entraîner à mener un entretien, tester un guide, anticiper des objections. Le test du Nielsen Norman Group montre en revanche qu’ils prédisent mal le comportement réel et qu’ils sont complaisants, ce qui les disqualifie comme source de décision.
Comment convaincre une direction qui veut aller plus vite ?
+
En déplaçant la comparaison : le coût d’une discovery courte mais réelle est presque toujours inférieur au coût d’un trimestre de développement sur une fonctionnalité inutilisée. Et en montrant que l’IA permet d’exploiter la matière déjà disponible, ce qui donne des résultats en quelques jours sans attendre une nouvelle campagne d’entretiens.
Peut-on utiliser l’IA pour analyser des enregistrements d’entretiens ?
+
Oui, c’est l’un des meilleurs usages, sous trois conditions : l’accord des participants, la pseudonymisation avant analyse, et l’exigence de citations tracées dans la synthèse. Relire un entretien complet pour vérifier que rien d’important n’a été écrasé reste indispensable.
À faire maintenant
- 1Poser la règle : aucune affirmation sur les utilisateurs sans source citable
- 2Séparer visuellement constats et hypothèses dans vos documents de discovery
- 3Lancer une analyse transversale de la matière déjà accumulée depuis six mois
- 4Vérifier qu’au moins un constat récent contredit ce que l’équipe pensait