Décider quoi construire, et pour qui, avant de dépenser un euro de build. La méthode, les cinq étapes, les livrables, et ce que les agents IA changent en 2026.
La phase de discovery, c'est le temps où l'on décide quoi construire, et pour qui, avant de dépenser un euro de build. On part d'un problème supposé, on va vérifier qu'il existe chez de vraies personnes, on mesure ce qu'il coûte, et on ressort avec un périmètre à construire, ou avec la décision de ne rien construire. C'est la partie du travail produit qui évite de livrer vite la mauvaise chose.
Le mot vient du Double Diamond du Design Council britannique : un premier losange pour explorer et cadrer le problème, un second pour concevoir et livrer la solution. La discovery est le premier. La delivery est le second.
Ce qui a changé depuis que j'ai écrit la première version de cet article. J'ai mené des discoveries pendant quinze ans, pour Chanel, Dior, Accor, Carrefour, Forvis Mazars. La méthode n'a pas bougé. Le temps, si. Ce qui prenait trois semaines à une équipe de trois en prend une à une personne qui pilote des agents. Cet article est la version 2026 : la méthode, et ce que les agents changent à chaque étape.
À trois choses, dans cet ordre.
Éviter de construire ce dont personne n'a besoin. C'est la première cause d'échec des produits, loin devant la technique. Une discovery coûte une à trois semaines. Un produit construit sur une hypothèse fausse coûte six mois et une équipe.
Choisir le bon problème parmi les dix qu'on voit. Toute équipe a une liste. La discovery classe cette liste par ce que chaque problème coûte réellement aux utilisateurs et au business, pas par ce que le dirigeant a vu chez un concurrent.
Donner à la delivery un périmètre qu'on peut tenir. Une discovery qui se termine sans périmètre minimal et sans critères de réussite n'a pas terminé. Elle a juste arrêté.
Une discovery commence par une phrase : « Nous pensons que [ces utilisateurs] ont [ce problème] parce que [cette raison], et que ça leur coûte [ceci]. » Si la phrase ne s'écrit pas, on n'est pas prêt à découvrir, on est prêt à errer. Cette étape reste entièrement humaine. Un agent peut reformuler, il ne peut pas savoir ce que l'entreprise est prête à ne pas faire.
Entretiens, observation sur le terrain, données d'usage existantes, tickets support, verbatims commerciaux. Huit à douze entretiens bien choisis suffisent pour un périmètre : au-delà, les réponses se répètent. Le choix des personnes compte plus que leur nombre. Ce que les agents changent : la transcription et la première synthèse d'un entretien d'une heure prennent dix minutes au lieu d'une demi-journée. Je conduis l'entretien, l'agent le traite le soir même, je relis le lendemain matin avec les vraies questions déjà posées.
Regrouper les verbatims par thème, compter, croiser avec les données quantitatives. C'est l'étape la plus longue en discovery classique et la plus mécanique. Un agent regroupe 200 verbatims par thème en une heure, avec les citations sources, et se trompe sur les nuances. Je garde les nuances. Le tri passe de quatre jours à un.
Chaque problème observé devient une hypothèse de solution, classée sur deux axes : ce qu'elle rapporte si elle est vraie, et ce qu'on risque si elle est fausse. On teste d'abord celles qui sont risquées et importantes. Un prototype cliquable, un faux bouton, un email envoyé à la main à vingt clients : le test le moins cher qui tranche. Ici les agents accélèrent la production des prototypes, pas le choix de ce qu'on teste.
Une page. Le problème, les preuves, le périmètre minimal, les critères de succès mesurables, ce qu'on ne fait pas. Cette page est le contrat entre la discovery et la delivery. Si elle n'existe pas, la delivery redécouvre tout en construisant, et c'est là que les mois partent.
| Livrable | Forme | Ce qu'il permet |
|---|---|---|
| Énoncé du problème | Une phrase, avec les preuves derrière | Que tout le monde construise la même chose |
| Carte des utilisateurs | Deux à quatre segments, leurs situations, leurs coûts | Prioriser par valeur, pas par bruit |
| Hypothèses classées | Tableau valeur / risque, résultats des tests | Savoir ce qu'on a vérifié et ce qu'on suppose |
| Périmètre minimal | Ce qui entre, ce qui n'entre pas | Une delivery qui tient en semaines |
| Critères de réussite | Trois mesures, avec leur valeur actuelle | Savoir, dans trois mois, si ça a marché |
La discovery alibi. La décision est prise, les entretiens servent à la justifier. Ça se reconnaît aux questions fermées et aux personnes interrogées choisies parmi les convaincus.
La discovery infinie. Trois mois de recherche, un rapport, aucune décision. Une discovery a une date de fin fixée avant de commencer.
La discovery sans données. Dix entretiens, zéro chiffre. Les entretiens disent pourquoi. Les données disent combien. Il faut les deux.
La discovery sans faisabilité. On découvre un besoin magnifique et on apprend en delivery qu'il faut deux ans de développement. La technique s'assoit à la table dès le premier jour. Sur un produit IA, ça veut dire vérifier que les données existent avant de promettre l'agent.
En 2026, la moitié des discoveries que je mène portent sur une question nouvelle : quelle tâche confier à des agents, et laquelle surtout pas. La méthode est la même, les questions changent.
Quelle tâche coûte le plus de temps répétitif ? Est-elle assez formalisable pour qu'un agent la tienne ? Les données qu'il lui faut existent-elles, et qui y a accès ? Que se passe-t-il quand l'agent se trompe, et qui s'en aperçoit ? Combien vaut une heure gagnée sur cette tâche, multipliée par le nombre de fois où elle revient ?
Une semaine de discovery sur ces cinq questions, c'est ce que je vends comme audit d'automatisation. Elle se termine par une liste de tâches classées par gain, avec pour chacune le verdict : à automatiser maintenant, à automatiser plus tard, ou à laisser aux humains. Le troisième verdict est le plus utile. C'est celui qu'une agence qui vend des agents ne vous donnera pas.
Un exemple concret. Pour tondroit.fr, la discovery a duré six jours. Douze entretiens avec des particuliers qui avaient cherché une réponse juridique en ligne, l'analyse de 400 questions posées sur des forums, et un test : une page qui promettait une réponse sourcée, sans le produit derrière. Verdict : le besoin existait, la confiance était le vrai problème, donc l'agent devrait citer la loi ou se taire. Toute l'architecture RAG vient de cette phrase.
Une à trois semaines pour un produit ou un périmètre précis. Au-delà d'un mois, ce n'est plus une discovery, c'est une étude qui évite de décider. Avec des agents pour la synthèse des entretiens et de la recherche, je tiens une discovery complète en une semaine sur un périmètre cadré.
La discovery répond à la question « faut-il construire ceci, et pour qui ». La delivery répond à « construisons-le bien ». La première produit une décision et un périmètre, la seconde produit un système qui tourne. Les deux se recouvrent en continu sur un produit vivant, mais on ne les confond pas : une équipe qui livre pendant qu'elle découvre livre la mauvaise chose plus vite.
Un problème formulé en une phrase, les preuves qui le soutiennent, les segments d'utilisateurs concernés, les hypothèses classées par risque, le périmètre minimal à construire et les critères qui diront si ça marche. Pas un rapport de 60 pages. Une page de décision et les données derrière.
En partie. La transcription et la synthèse des entretiens, le regroupement des verbatims, la revue de la concurrence et la première passe d'analyse des données se confient à des agents et passent de plusieurs jours à quelques heures. Le choix des personnes à interroger, la formulation du problème, l'arbitrage entre hypothèses et la décision de ne pas construire restent humains. C'est précisément là que se joue la valeur.
L'UX research est un des outils de la discovery, pas la discovery elle-même. Une discovery mobilise aussi les données d'usage, le business, la faisabilité technique et les contraintes réglementaires. Un designer qui ne fait que des entretiens fait de la recherche. Un product builder qui en tire une décision et un périmètre fait de la discovery.
Plus que jamais. La majorité des projets d'agents IA qui n'arrivent pas en production échouent sur le cadrage, pas sur le modèle : périmètre flou, données non préparées, tâche mal choisie. Une discovery d'une semaine qui identifie la tâche à automatiser, mesure son coût actuel et vérifie que les données existent, c'est ce qui sépare un agent qui tourne d'un POC oublié.
45 minutes pour poser la question de départ et voir si une semaine suffit. Si la réponse est « ne construisez pas », je vous le dis aussi.
Réserver un appel de 45 minutes →
Ou par email : e.loui@uxdesignparis.fr · Téléphone : +33 6 35 31 50 35