Written by:
Last Published:
5 novembre 2026
•
Le processus de découverte produit est une phase courte et structurée précédant le développement, durant laquelle vous et votre agence décidez de ce qu'il faut construire, dans quel ordre et à quel coût. Est-ce une manière polie de facturer avant de construire ? Non. Lorsqu'il est bien mené, il s'agit d'un investissement initial modeste qui permet d'éviter le coût bien plus élevé de construire le mauvais produit.
Considérez cela comme une étude de sol avant de couler les fondations. Personne n'aime payer pour une étude. Mais tout le monde préfère cela à la découverte d'une source sous le plancher de la cuisine. La découverte produit remplit le même rôle pour le logiciel : elle fait remonter les problèmes cachés alors qu'ils ne coûtent qu'une discussion, et non une reconstruction.
Ce guide est destiné à la personne qui commande le travail : le fondateur, le product owner ou le cadre qui valide le périmètre et le budget, plutôt qu'aux personnes chargées de la réalisation. Il explique le processus dans la pratique, et non en théorie. La version que nous décrivons est la « Scoping Session » d'Imaginary Cloud ; vous découvrez donc un processus réel, et non une méthode générique.
La découverte produit transforme une idée en décisions concrètes avant d'investir dans le code. Lors d'une session de cadrage (Scoping Session), chefs de projet, développeurs et designers travaillent avec votre équipe à travers trois phases (le business case, l'utilisateur et le plan technique). Vous repartez avec un périmètre défini, des fonctionnalités priorisées, des personas, une architecture de haut niveau, des dépendances identifiées, un planning de projet et une estimation budgétaire. Sa valeur réside dans ce qu'elle prévient : la dérive du périmètre, les estimations peu fiables et les mauvaises surprises en fin de projet. Le meilleur test pour une bonne découverte est de savoir si une autre équipe pourrait réaliser le projet en se basant sur ses livrables.
La phase de découverte produit consiste à déterminer ce qu'il faut construire, et s'il est pertinent de le faire, avant même le début du développement. Avec une agence, il s'agit d'une collaboration courte et structurée qui transforme une idée en un périmètre défini, une liste de fonctionnalités priorisées, une approche technique et une estimation budgétaire.
Alors, qu'est-ce que la découverte produit en termes simples ? C'est le volet décisionnel du développement produit. Teresa Torres, de Product Talk, la décrit comme un processus de prise de décision, distinct de la phase de livraison, qui concerne la construction, le déploiement et la maintenance. Marty Cagan, dans ses écrits pour le SVPG, définit ses objectifs comme le fait de vérifier si les utilisateurs ont réellement besoin du produit et si vous êtes en mesure de concevoir quelque chose d'utilisable, d'utile et de réalisable.
Et surtout, ce qu'elle n'est pas. Ce n'est pas du design (bien que le design y contribue). Ce n'est pas un devis (bien qu'une estimation de coût en découle). Et ce n'est pas une garantie que l'idée est la bonne.
Parfois, le résultat le plus précieux est un "pas encore" clair. C'est un résultat, pas un échec.
Vous n'avez pas besoin d'un cahier des charges parfait. Vous avez besoin de réponses honnêtes à quelques questions : quel problème résolvez-vous, pour qui, sous quelles contraintes, et qui prend les décisions. Plus vous pourrez aborder ces points lors de la première session, moins vous aurez d'hypothèses non vérifiées dans votre périmètre.
Rien de tout cela n'est une condition d'entrée formelle. C'est simplement la matière première de notre échange. Apportez ce que vous avez, et dites clairement ce que vous ignorez.
Une dernière chose à préparer, et ce n'est pas un document : préparez-vous à être remis en question. Une bonne session de découverte interroge l'idée, et une organisation ouverte à cela en tire un bien meilleur profit.
La session de cadrage d'Imaginary Cloud se décline en trois phases : Analyse, Découverte et Planification. Elle réunit chefs de projet, développeurs et designers, et progresse du business case vers l'utilisateur, puis vers le plan technique.
La session repose sur une approche centrée sur l'utilisateur, combinant planification de projet et expertise technique et créative. Voici ce qu'implique chaque phase, ce que vous faites et ce que vous en retirez.
L'équipe commence par l'idée elle-même. Ensemble, vous clarifiez les besoins métier, fixez le calendrier du projet, listez les principaux concurrents, esquissez des personas (profils fictifs mais basés sur des données réelles de vos utilisateurs types) et définissez les objectifs principaux. C'est ici que les questions de votre liste de préparation sont utilisées.
Ce que vous faites : expliquer l'idée, les objectifs et les contraintes, et répondre aux questions délicates sur le business case.
Ce que cela permet d'établir : le business case et les objectifs qui encadrent les deux phases suivantes.
L'attention se déplace maintenant du business vers les personnes qui utiliseront le produit. Votre équipe et la nôtre construisent ensemble des personas pour comprendre comment ces utilisateurs interagiront avec le produit. Nous listons et hiérarchisons ensuite les user stories, qui sont de brèves descriptions de ce qu'un utilisateur doit faire et pourquoi. Le classement est basé sur le stade de cycle de vie du produit ainsi que sur les objectifs des utilisateurs et du produit ; le résultat devient la base du plan de développement.
Ce que vous faites : apportez ce que vous savez sur vos utilisateurs et participez à la priorisation. C'est ici que vous décidez ce qui compte le plus et ce qui peut attendre.
Ce que cela produit : des personas, ainsi que des user stories et des fonctionnalités hiérarchisées.
Cette dernière phase transforme les priorités en une approche technique. L'équipe identifie et hiérarchise les fonctionnalités principales, conçoit une solution technique équilibrant complexité et portée, et cartographie les dépendances externes liées aux fournisseurs tiers, tels que les services de paiement, de connexion sociale et de cloud.
Ce que vous faites : confirmer les priorités, signaler les contraintes liées aux outils et à l'infrastructure, et réagir à l'approche proposée.
Ce que cela produit : une architecture de haut niveau, une liste des dépendances tierces et un plan de projet incluant un calendrier et une estimation des coûts.
Imaginary Cloud ne publie pas de durée fixe pour la session de cadrage (Scoping Session), ce qui est logique, car cela dépend de la clarté de votre idée et de la complexité du produit. À titre indicatif, le manuel de service du gouvernement britannique indique qu'une phase de découverte dure généralement entre quatre et huit semaines, moins pour des problèmes familiers et davantage pour des projets inédits. Ces recommandations sont destinées aux services publics ; considérez-les donc comme un point de référence et non comme une promesse. Demandez à votre agence un calendrier spécifique à votre projet.
Un bon processus de découverte produit aboutit à des documents sur lesquels vous pouvez vous appuyer pour construire le produit ou que vous pouvez confier à une autre équipe. Vous devriez recevoir un périmètre et une feuille de route du projet, des fonctionnalités et des user stories hiérarchisées, des personas, une architecture de haut niveau, une liste des dépendances, un plan de projet et une estimation des coûts.
Cette liste correspond à ce que fournit la session de cadrage d'Imaginary Cloud. Pour en juger la qualité, utilisez ce que nous appelons le « test de transfert » : une autre équipe compétente pourrait-elle lire ces documents, chiffrer et construire le produit sans avoir besoin d'un seul appel de clarification ? Si la réponse est non, c'est qu'il manque quelque chose ou que le contenu est trop vague. Effectuez ces quatre vérifications avant de considérer le travail comme terminé :
Une bonne phase de découverte permet également d'aligner toutes les parties prenantes de votre côté. Recherchez des livrables que les parties prenantes peuvent valider, comme un ordre de priorité convenu et une définition partagée de la première version. Si les personnes qui financent le projet et celles qui utilisent le produit ne sont pas d'accord sur la définition de « terminé », la phase de découverte est le moment le plus économique pour s'en rendre compte.
La phase de découverte a alors rempli son rôle. Une découverte qui conclut à un résultat « non conforme aux attentes » ou « pas encore prêt » vous évite les coûts liés à la découverte de ces obstacles lors du développement. Vous avez alors le choix de modifier le périmètre, de tester une version plus restreinte ou d'arrêter le projet.
Les recommandations du gouvernement britannique vont dans le même sens : la phase de découverte doit aboutir à une décision sur la poursuite ou non du projet, et décider d'arrêter à ce stade est une issue tout à fait légitime. Ce que vous conservez est également précieux. Les recherches, les personas, les priorités et les conclusions techniques vous restent acquis et permettent généralement de gagner du temps lors de la tentative suivante.
Mettez-vous d'accord sur ce point à l'avance. Demandez à votre agence ce qu'il advient si la phase de découverte modifie l'orientation du projet, et comment l'étape suivante est définie et chiffrée.
La phase de découverte protège votre budget en transformant les inconnues en décisions avant que les dépenses de développement ne commencent. Le périmètre, les priorités et les dépendances techniques sont définis sur papier, où il est peu coûteux de changer d'avis, plutôt que dans le code, où cela ne l'est pas.
Voici le mécanisme, en trois étapes.
Tout d'abord, le périmètre ne dérive plus. Lorsque les fonctionnalités sont listées et hiérarchisées en fonction des objectifs des utilisateurs et du produit, les ajouts « tant qu'on y est » doivent se justifier. Les efforts sont concentrés là où ils comptent le plus.
Ensuite, l'estimation repose sur des bases concrètes. Une estimation budgétaire construite à partir de fonctionnalités priorisées et d'une architecture définie constitue une prévision commerciale bien plus fiable qu'une estimation basée sur un brief d'un paragraphe. La page dédiée d'Imaginary Cloud décrit la planification initiale comme un moyen d'identifier les domaines prioritaires et d'éviter les coûts et délais supplémentaires.
Enfin, les risques sont identifiés très tôt. Un prestataire de paiement qui ne prend pas en charge votre marché, une méthode de connexion que vos utilisateurs n'utilisent pas, ou une fonctionnalité bien plus complexe à développer qu'il n'y paraît : il est toujours moins coûteux de découvrir ces obstacles lors de la phase de planification que lors du neuvième sprint.
Nous ne pouvons pas vous donner de pourcentage d'économie, et nous nous méfierions de quiconque le ferait. Les économies dépendent du nombre de fausses pistes évitées grâce à la phase de découverte, ce que l'on ne peut constater qu'avec le recul.
Ce que nous pouvons affirmer, c'est que cette logique est éprouvée depuis longtemps. Le Double Diamant du Design Council, un cadre de conception en quatre étapes (découvrir, définir, développer et livrer), place les deux premières étapes avant les deux dernières, dans cet ordre. Les recherches de Jakob Nielsen sur l'utilisabilité préconisent plusieurs petits cycles de tests avec des refontes intermédiaires, plutôt qu'une seule étude de grande envergure.
Deux études de cas publiques d'Imaginary Cloud illustrent cette méthode en action, sans avancer de chiffres qui ne figurent pas sur leurs pages. Pour Aurora Analytica, une plateforme d'analyse d'essais cliniques, les propriétaires de produit, les développeurs et les designers ont convenu des fonctionnalités et des priorités dans le cadre d'une approche MVP (produit minimum viable, la version la plus simple permettant de tester une idée auprès d'utilisateurs réels), et les choix de conception ont été vérifiés au regard de la faisabilité technique. Pour VestaConnect, une plateforme de coordination des soins, un MVP a été testé auprès d'utilisateurs bêta, leurs retours ont alimenté la feuille de route, et le produit est passé par la suite d'un modèle bêta à un modèle payant. Vous pouvez en découvrir davantage dans nos études de cas, et en savoir plus sur notre approche MVP.
Pour un cadre dirigeant, la découverte est un moyen d'engager des capitaux par étapes. Vous investissez une somme modeste pour obtenir de meilleures informations, puis vous décidez s'il convient de financer le développement complet. Cela réduit les risques, améliore la fiabilité des prévisions et peut accélérer la création de valeur initiale.
Voici comment cela répond aux préoccupations d'un conseil d'administration ou d'un responsable financier.
Pour défendre votre dossier au sein de votre organisation, utilisez vos propres chiffres. Combien a coûté le dernier projet qui a dû changer de direction en cours de route ? Quel est le coût d'un sprint manqué en termes de temps d'équipe et de revenus différés ? La phase de découverte ne supprimera pas ces risques, mais elle permet de traiter les questions les plus critiques au moment où y répondre coûte le moins cher.
Jugez-la sur ce que vous aurez concrètement entre les mains et sur la manière dont l'agence collabore avec vous, et non sur la présentation commerciale. Demandez les livrables par écrit, identifiez les personnes qui seront présentes et vérifiez ce qui se passe si la phase de découverte modifie le plan initial.
Quelle que soit l'agence que vous présélectionnez, ces questions permettent de distinguer une véritable phase de découverte d'un long argumentaire de vente :
La session de cadrage d'Imaginary Cloud est assurée par des chefs de projet et des développeurs, avec l'intervention de designers pour le travail d'UX et d'interface. Elle comprend une estimation des coûts et un plan de projet. Imaginary Cloud propose ensuite deux modèles de collaboration : l'extension d'équipe et les projets gérés.
Tous les projets ne nécessitent pas un processus complet de découverte produit. Une modification mineure et bien définie sur un produit existant peut simplement nécessiter une discussion plutôt que trois phases distinctes. Le risque se situe à l'opposé : une idée floue qui fait l'impasse sur la découverte et dont les lacunes ne sont révélées qu'au moment du développement.
Une approche plus légère est pertinente lorsque le problème est bien compris, les utilisateurs identifiés, la technologie maîtrisée et le périmètre du changement limité. En cas de doute, demandez à l'agence quelles phases peuvent être raccourcies et quels risques cela implique.
Les erreurs les plus courantes consistent à faire l'impasse sur la découverte parce que l'idée semble claire, à considérer l'estimation initiale comme un prix fixe, à exclure les décideurs ou à omettre certaines contraintes. Ces quatre erreurs peuvent être évitées avec un peu de préparation.
La discovery produit consiste à décider ce qu'il faut construire, et s'il faut le construire, avant le début du développement. Avec une agence, cela combine l'analyse commerciale, la recherche utilisateur et la planification technique pour aboutir à un périmètre, une liste de fonctionnalités priorisées et une estimation des coûts exploitables.
Il s'agit de l'étape au début d'un projet, avant le développement, durant laquelle vous testez vos hypothèses sur le problème, les utilisateurs et l'approche technique. Elle se termine par une décision de poursuivre, d'ajuster ou d'arrêter, et par la production des documents nécessaires à la planification de la réalisation.
Une session de cadrage couvre trois phases : l'analyse de l'opportunité commerciale, la découverte des utilisateurs et des priorités, et la planification de l'architecture et du projet. Elle produit un périmètre et une feuille de route, des fonctionnalités et des user stories priorisées, des personas, une architecture de haut niveau, une liste de dépendances, un plan de projet et une estimation des coûts.
Les agences utilisent des noms différents pour la même idée : sprint de discovery, atelier, phase ou session de cadrage. Ce qui compte, c'est le résultat. Demandez les livrables par écrit et vérifiez-les par rapport à la liste ci-dessus : périmètre, priorités, personas, architecture, dépendances, plan et estimation.
Cela dépend de la complexité de votre produit et de la clarté de votre idée. Imaginary Cloud ne publie pas de durée fixe. Les directives du gouvernement britannique pour les services publics suggèrent une fourchette typique de quatre à huit semaines. Demandez à votre agence un calendrier pour votre projet.
Imaginary Cloud ne publie pas de prix. La session comprend un calendrier et une estimation des coûts pour votre projet, et vous pouvez demander un devis auprès de l'équipe de développement commercial. Les coûts varient en fonction du périmètre du produit, le devis est donc la réponse la plus fiable.
Appliquez le test de passation : une autre équipe compétente pourrait-elle construire le produit à partir des documents sans poser de questions ? Vérifiez que les fonctionnalités sont priorisées, que les dépendances sont identifiées, que l'estimation précise ses hypothèses et que la session se termine par une décision claire de poursuivre, d'ajuster ou de suspendre le projet.
Demandez ce que vous recevrez et sous quel format, qui sera présent, comment la session est organisée, sur quoi repose l'estimation, qui est propriétaire des livrables et ce qui se passe si le plan change. Demandez également à échanger avec un client ayant déjà suivi ce processus.
Souvent, oui. Les designs montrent à quoi ressemble le produit, mais ne garantissent pas que le périmètre est priorisé, que l'architecture est solide ou que les dépendances tierces sont identifiées. La phase de planification couvre ces aspects. Si vos designs sont aboutis, la phase de découverte peut être allégée, mais pas ignorée.
Vous décidez si vous souhaitez poursuivre. Si c'est le cas, le périmètre, la feuille de route et le plan de projet deviennent la base du développement. Imaginary Cloud propose deux modèles : l'extension d'équipe, où des développeurs rejoignent votre équipe, et les projets gérés, où nous développons le produit en interne selon nos propres processus.
Le processus de découverte produit est un moyen à faible risque de déterminer ce dont votre idée a réellement besoin et ce qu'elle implique. Si vous avez un produit en tête et que vous souhaitez voir à quoi ressemblerait une session de cadrage pour celui-ci, vous pouvez en savoir plus sur la session de cadrage ou discuter avec notre équipe. Apportez votre idée, vos contraintes et vos questions délicates. Nous apporterons le plan.
Alexandra Mendes est Senior Growth Specialist chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction sur le développement logiciel, l'IA et la transformation numérique. Après avoir suivi une formation en développement frontend, Alexandra a acquis des compétences pratiques en programmation et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la manière dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
People who read this post, also found these interesting:
.webp)
