Product Discovery : Commencer un peu plus lentement, livrer beaucoup plus vite
Nous aimons tous les lancements rapides. Le danger n'est pas la rapidité, mais le fait de commencer sans avoir une vision commune de ce que le produit pourrait devenir. C'est à ce moment-là que l'expression "nous l'ajouterons plus tard" cesse d'être un plan et devient une rénovation.
Là où les plateformes cassent sans product discovery
Le product discovery est l’étape que la plupart des équipes sautent—et regrettent ensuite. Une première version allégée d’une plateforme ou d’une application web personnalisée fonctionne bien. Puis la vie réelle se présente.
Un client demande des abonnements au lieu de paiements uniques.
Un programme de partenariat exige des autorisations différentes pour les vendeurs et les gestionnaires.
Une étape d’approbation se glisse dans un flux de travail qui se résumait auparavant à « créer → publier ».
La sécurité exige un SSO (Google/Microsoft) et une authentification multifactorielle.
Le marketing veut des analyses fiables, et pas seulement une exportation rapide.
Aucune de ces demandes n’est exotique—elles constituent l’évolution naturelle de la plupart des produits SaaS et des plateformes numériques. Le problème est que chacune d’entre elles touche aux fondations : commandes, permissions, flux de travail, suivi des données, authentification.
Si ces éléments n’ont pas été pris en compte dès le départ, il ne s’agit pas d’ajouter une fonctionnalité, mais d’abattre les murs.
Le coût de sauter le discovery
Tous les raccourcis du début finissent par coûter cher. Pour les agences web et les équipes produit, ce coût se traduit par des délais non respectés, des factures de développement plus élevées et des parties prenantes frustrées. Barry Boehm a chiffré ce phénomène en 1981 : un changement attrapé au stade des exigences coûte environ 1 unité ; le même changement attrapé en production en coûte 100. Quarante ans de projets logiciels n’ont cessé de confirmer la courbe.
C’est aussi pourquoi un périmètre de mission clair est rentable bien avant la première ligne de code — le moment le moins cher pour changer d’avis est celui où rien n’a encore été construit.
Poser les jalons dès le départ
Avant de plonger dans la conception et la réalisation, nous faisons une pause—non pas pour rédiger un cahier des charges de 200 pages, mais pour définir les rails sur lesquels le produit fonctionnera. Voici à quoi ressemble une phase de product discovery en pratique :
À qui le produit s’adresse-t-il vraiment, et qu’est-ce qui doit être fait sans effort ?
Quels sont les enregistrements qui seront conservés pendant des années ?
Quels sont les événements et les mesures qui auront de l’importance plus tard ?
Quelles sont les évolutions probables (abonnements, rôles des partenaires, approbations, intégrations) qui ont besoin d’un espace dans les fondations ?
Quelle méthode standard utiliserons-nous pour connecter des systèmes tiers afin que la prochaine intégration se fasse en douceur ?
Cette étape—discovery rapide et planification de l’architecture logicielle—prend généralement une à deux semaines. Elle porte ses fruits pour chaque fonctionnalité qui suit. Lorsqu’une équipe vient nous voir pour un développement MVP, la phase de discovery est la première étape du plan, pas une option.
Ce que livre une phase de discovery
Le discovery n’est pas une série de réunions ; c’est une courte mission qui produit des artefacts concrets. Au bout d’une à deux semaines, vous recevez :
Description d’architecture — la forme technique de la plateforme en 4–6 pages : esquisse du modèle de données, frontières d’intégration, décisions que nous recommandons de reporter.
Projet de modèle de données — entités, relations et champs qui doivent rester stables à travers les futures fonctionnalités.
Liste de risques — 5 à 10 risques non évidents propres à votre domaine, chacun avec une mitigation.
Plan de construction — une feuille de route par phases, pour que la première release ne bloque pas la deuxième.
Estimation honnête — fourchettes de temps et de coût pour la première release, ancrées dans l’architecture ci-dessus.
Tout est rédigé pour qu’une partie prenante non technique puisse le lire — pas de schémas pour les schémas.
À quoi ressemble un discovery de deux semaines
Le discovery a un rythme. Deux semaines suffisent pour répondre aux questions structurelles sans bloquer la réalisation.
| Jours | Objectif | Livrable |
|---|---|---|
| 1–3 | Utilisateurs, flux de revenus, non-négociables | Rôles utilisateurs, jobs-to-be-done, contraintes business |
| 4–6 | Modèle de données et modèle d’événements | Schéma projet, catalogue d’événements, règles de rétention |
| 7–9 | Intégrations et décisions d’architecture | Carte d’intégration, choix techniques, liste de décisions reportées |
| 10 | Plan, estimation, revue des risques | Plan de construction par phases, fourchette de coût, principaux risques avec mitigations |
Ce qui se passe quand l'architecture tient
Les idées futures cessent d’être des déraillements.
Une demande d’abonnement devient un nouveau wagon sur le train, et non une nouvelle voie.
Un rôle de partenaire n’est qu’une configuration, pas une réécriture.
Une étape d’approbation est un état dans un flux, pas une solution de contournement désordonnée.
Même lorsque les plans changent (et ils changeront), l’architecture de base de la plateforme est maintenue. L’équipe peut se concentrer sur la livraison plus rapide des fonctionnalités, au lieu d’effectuer des opérations chirurgicales.
Avec discovery vs sans : côte à côte
Deux équipes livrent le même MVP — l’une avec un discovery de deux semaines, l’autre sans — et divergent vite dès que les demandes réelles arrivent.
| Moment du projet | Sans discovery | Avec discovery |
|---|---|---|
| Le client demande des abonnements | Réécrire la facturation, l’auth, les droits | Activer un flag — le schéma le supporte déjà |
| Le programme partenaires exige des rôles | Raccrocher les permissions sur chaque écran | Ajouter un rôle — les permissions sont pilotées par policy |
| SSO/MFA imposé | Remplacer l’authentification, migrer tous les utilisateurs | Changer de fournisseur d’identité — le modèle de session est déjà abstrait |
| Première demande d’analytics | Remplir les événements depuis les logs, perdre en précision | Événements capturés dès le jour un — pas de backfill |
Pourquoi un discovery court fait gagner du temps
L’objectif n’est pas de prédire l’avenir à la perfection. Il s’agit de concevoir l’architecture logicielle pour la flexibilité dès le premier jour. En ralentissant d’une semaine ou deux au départ, vous évitez des mois de retravail par la suite—et vous lancez un produit qui peut réellement évoluer avec votre entreprise.
Quand nous reprenons un projet qui n’a jamais eu de phase de discovery, la première étape est généralement un audit externe du projet — confronter l’architecture actuelle à la direction que le produit doit réellement prendre. L’audit seul finance souvent l’année de développement suivante en évitant la mauvaise reconstruction.
FAQ sur le product discovery
Questions fréquentes que nous recevons lorsque nous proposons une phase de discovery — les réponses dans la FAQ ci-dessous.
Combien de temps dure réellement une phase de product discovery ?
Une à deux semaines pour la plupart des projets SaaS et web sur mesure. Pas un cahier de 200 pages — un ensemble ciblé de réponses sur les utilisateurs, le modèle de données, les évolutions probables et les frontières d'intégration. Si elle dure plus, c'est généralement le périmètre du projet qu'il faut réduire, pas la discovery qu'il faut étendre.
Le discovery en vaut-il la peine pour un petit MVP ?
Oui — et plus l'équipe est petite, plus c'est important. Un petit MVP sera étendu par quelqu'un qui n'était pas au premier entretien ; le discovery transforme le modèle mental du fondateur en quelque chose que le prochain développeur peut lire. La phase peut être plus courte (3 à 5 jours pour un MVP serré), mais la sauter entièrement est le point de départ de la plupart des reconstructions.
Que produit une phase de product discovery ?
Une vision partagée du produit : pour qui il est, quels enregistrements et événements comptent à long terme, quelles évolutions futures (abonnements, rôles, approbations, intégrations) ont besoin d'espace dans les fondations, et une méthode standard pour connecter les systèmes tiers. Concrètement : une courte description écrite de l'architecture, une esquisse du modèle de données et une courte liste de risques non évidents — assez pour commencer à construire sans remettre en question chaque décision.
Peut-on faire du discovery sans s'engager sur la réalisation complète ?
Oui. Nous proposons le discovery comme mission autonome — vous recevez la description de l'architecture, le modèle de données et la liste des risques, et vous êtes libre de construire avec nous, avec une autre équipe, ou de mettre le projet en pause. Un contrat de discovery séparé protège les deux parties : vous ne payez pas pour une réalisation que nous n'avons pas cadrée, et nous ne nous engageons pas sur une réalisation que nous ne pouvons pas estimer honnêtement.
Commencez par le discovery
Pensez-vous à unproduit
conçu pour durer ?
Dites-nous ce que vous construisez. Nous répondons sous un jour ouvré en vous indiquant si une phase de discovery de 1 à 2 semaines est la prochaine étape qu'il vous faut — ou si vous avez déjà de quoi commencer la construction.