La conversation la plus coûteuse que nous ayons avec des fondateurs est presque toujours la même. Elle commence par : « Nous avons sauté la discovery parce que nous voulions aller vite. » Six mois plus tard, ils reconstruisent quelque chose qui n'a jamais été correctement cadré, payant deux fois pour un travail réalisé une fois dans la mauvaise direction.
Un sprint de discovery n'est pas un retard. C'est la décision qui détermine si tout ce qui suit repose sur des bases solides ou sur des suppositions. Cet article explique ce que produit réellement un sprint de product discovery, pourquoi la phase de discovery d'un projet logiciel est l'investissement à plus fort effet de levier qu'un fondateur puisse faire avant d'écrire la moindre ligne de code, et ce que comprend précisément le nôtre.
Qu'est-ce qu'un sprint de discovery ?
Un sprint de discovery est une phase structurée et limitée dans le temps, au démarrage d'un projet logiciel, durant laquelle une équipe de développement travaille avec le client pour définir ce qui est construit, pourquoi, comment l'architecture doit être conçue, et ce que la livraison coûtera et durera de façon réaliste. Il intervient avant l'écriture de tout code de production.
Le résultat d'une phase de discovery de projet n'est ni un moodboard ni une estimation approximative griffonnée pendant un appel. C'est un ensemble de livrables écrits et concrets qui donnent au client comme à l'équipe une image commune et sans ambiguïté du projet avant que l'argent ne soit engagé dans la réalisation complète.
Cela diffère d'un sprint de design, qui se concentre sur le prototypage et les tests utilisateurs d'une fonctionnalité ou d'un concept précis. La distinction sprint de discovery et sprint de design est importante : la discovery porte sur le cadrage et l'architecture de l'ensemble du produit ; le sprint de design sert à valider une hypothèse UX précise. La plupart des produits en phase initiale ont besoin de la discovery d'abord, des sprints de design ensuite.
Pourquoi faire l'impasse sur la phase de discovery est la décision la plus coûteuse que vous puissiez prendre
Les fondateurs sautent la phase de discovery d'un projet logiciel pour deux raisons : ils veulent aller vite et ne veulent pas payer pour quelque chose qui ne ressemble pas encore au produit. Les deux raisons sont compréhensibles. Les deux sont fausses.
Lorsqu'un projet saute la phase de discovery logicielle, voici ce qui se produit généralement :
Le périmètre est défini de façon informelle lors d'appels et dans des fils Slack – chacun a donc une idée différente de ce qui est construit
Les décisions d'architecture sont prises par défaut plutôt que par choix – ce qui crée une dette technique dont la correction coûte bien plus cher que de bien faire dès le départ
Les estimations budgétaires reposent sur des informations incomplètes – le coût réel n'apparaît qu'en cours de réalisation, au moment où changer de cap coûte le plus cher
L'équipe commence à construire avant que le client ne sache avec certitude ce dont il a besoin – ce qui entraîne reprises, fonctionnalités supprimées et glissements de calendrier qui érodent la confiance des deux côtés
Nous avons observé ce schéma dans tous les secteurs où nous intervenons – du développement de MVP pour startups aux plateformes d'entreprise complexes. Les projets qui se déroulent sans accroc ont presque toujours bénéficié d'une véritable phase de discovery de projet. Ceux qui peinent l'ont presque toujours sautée.
Le coût d'un sprint de discovery ne représente qu'une fraction de ce que coûte la correction d'un projet mal cadré. Pour la plupart des projets que nous livrons, la phase de discovery s'amortit dès les deux premiers sprints de développement.
Ce que comprend notre sprint de discovery
Notre processus de sprint de discovery dure une à deux semaines selon la complexité du projet. Il mobilise des ingénieurs seniors, un responsable produit et, le cas échéant, un responsable UX – pas de profils juniors ni de chargés de compte. À la fin de la phase, le client reçoit quatre livrables écrits.
1. Un périmètre produit écrit
Un document qui définit ce que fait le produit, ce qu'il ne fait pas, à qui il s'adresse et ce que comprend la version minimale viable. Rédigé en langage clair, sans jargon technique. Il devient le point de référence pour chaque décision prise pendant la réalisation. Les désaccords sur le périmètre, qui auraient demandé des semaines à résoudre en plein projet, sont réglés ici, par écrit, avant le début du développement.
2. Proposition d'architecture
Un document d'architecture technique décrivant la stack recommandée, la structure du système, le modèle de données et l'approche d'intégration. Il est rédigé par les ingénieurs seniors qui construiront réellement le produit – pas par une équipe avant-vente. Pour les projets réglementés comme les plateformes de santé conçues pour répondre aux exigences HIPAA, cette phase définit aussi dès le départ l'architecture de conformité et le traitement des données, et non après coup.
3. Une estimation budgétaire réaliste
Une ventilation des coûts de développement par phase, fondée sur le périmètre écrit et l'architecture. Pas une fourchette approximative conçue pour paraître basse, mais une estimation structurée avec des hypothèses claires. S'il faut réduire le périmètre pour respecter le budget, cette discussion a lieu ici, et non au troisième mois, quand la moitié du budget est déjà dépensée.
4. Un calendrier clair
Un plan de livraison par phases, avec des jalons, des dépendances et des facteurs de risque clairement identifiés. C'est le calendrier sur lequel nous travaillons réellement – pas celui qui sonne bien lors d'un rendez-vous commercial. Pour la plupart des projets de développement de MVP, nous livrons en 8 à 12 semaines à compter de la validation de la discovery. Pour les plateformes plus complexes, le délai est plus long, et ce document explique précisément pourquoi.
Ce qui distingue notre phase de discovery
La plupart des agences traitent le service de phase de discovery comme une étape commerciale – une prestation légère destinée à décrocher un contrat plus long. Nous la traitons comme un livrable autonome, que le client peut confier à n'importe quelle équipe de développement et exploiter.
Cela signifie que nous sommes prêts à dire à un fondateur, pendant la discovery, que son idée doit être cadrée autrement, que le calendrier qu'il envisage n'est pas réaliste ou qu'une approche technique à laquelle il tient posera problème à grande échelle. Ces conversations sont plus faciles au stade de la discovery qu'au quatrième mois.
Cela signifie aussi que l'équipe qui mène la discovery est celle qui construit le produit. Il n'y a pas de passation d'une équipe de discovery avant-vente à une équipe de livraison distincte – un point de transition où le contexte se perd régulièrement. Les ingénieurs qui conçoivent l'architecture pendant la phase de discovery sont ceux qui la mettent en œuvre.
Voici comment nous avons livré, de zéro, la plateforme Apos Health, conçue pour répondre aux exigences HIPAA pour un fabricant de dispositifs médicaux autorisés par la FDA – en commençant par une phase de discovery complète qui a défini l'architecture de conformité, la structure des rôles multi-cliniques et le modèle de données d'analyse de la marche avant qu'une seule ligne de code de production ne soit écrite. Le projet s'est déroulé sur douze mois sans aucune refonte d'architecture, car les fondations étaient solides.
Quand lancer un sprint de discovery
Vous avez besoin d'un service de phase de discovery logicielle si l'une des situations suivantes s'applique :
Vous avez une idée de produit mais ni périmètre écrit ni spécification technique
Vous avez un périmètre mais pas d'architecture – vous savez quoi construire, mais pas comment
Vous avez reçu des estimations très différentes de plusieurs agences et vous ne pouvez pas expliquer l'écart
Vous travaillez dans un secteur réglementé et ne savez pas avec certitude ce que la conformité exige de l'architecture
Vous constituez une équipe de développement dédiée et avez besoin d'un socle technique commun avant son démarrage
Une précédente réalisation a échoué ou s'est enlisée et vous repartez de zéro
Vous n'avez probablement pas besoin d'un sprint de discovery complet si vous disposez déjà d'une spécification technique détaillée rédigée par un ingénieur, d'un périmètre clair et stable sans question d'architecture ouverte, et d'une équipe qui a déjà construit ce type de produit. Dans ce cas, un échange de cadrage plus court peut suffire. Nous vous dirons lors du premier appel quelle option correspond à votre situation.
Si vous cadrez un produit et voulez savoir ce que sa réalisation demandera vraiment, c'est précisément à cela que sert notre sprint de discovery.
Planifier un appel de discovery – nous vous dirons en 30 minutes si une phase de discovery complète a du sens pour votre projet, ce qu'elle coûterait et ce que vous en retireriez.
Questions fréquentes
Qu'est-ce qu'un sprint de discovery et combien de temps dure-t-il ?
Un sprint de discovery est une phase structurée de cadrage au démarrage d'un projet logiciel, qui produit un périmètre écrit, une proposition d'architecture, une estimation budgétaire et un calendrier de livraison. Il dure une à deux semaines selon la complexité du projet. Il intervient avant le début de tout développement de production et avant la signature d'un contrat de développement complet.
Quels sont les livrables de la phase de discovery ?
Les livrables de notre phase de discovery sont quatre documents : un périmètre produit écrit qui définit ce qui est construit et ce qui est hors périmètre, une proposition d'architecture technique rédigée par les ingénieurs seniors qui construiront le produit, une estimation budgétaire structurée avec des hypothèses claires, et un calendrier de livraison par phases avec jalons et facteurs de risque. Ce sont des documents écrits, pas des présentations ni des résumés oraux.
Combien coûte un sprint de discovery ?
Le coût d'un sprint de discovery varie selon la complexité du projet. Il dépend de la complexité du périmètre, du nombre d'intégrations et de la présence ou non d'environnements réglementés comme la santé ou la fintech. Ce coût est presque toujours récupéré dès la première phase de développement grâce aux reprises et aux changements de périmètre évités.
Quelle est la différence entre un sprint de discovery et un sprint de design ?
La distinction sprint de discovery et sprint de design : un sprint de discovery cadre et architecture l'ensemble du produit – il répond à « que construisons-nous, comment et à quel coût ? ». Un sprint de design est un exercice UX ciblé qui prototype et teste avec des utilisateurs une fonctionnalité ou un concept précis. La plupart des produits ont besoin de la discovery d'abord, puis de sprints de design pour valider des fonctionnalités spécifiques plus tard dans la réalisation.
Ai-je besoin d'un sprint de discovery si j'ai déjà un cahier des charges ?
Cela dépend du cahier des charges. Une liste de fonctionnalités écrite n'équivaut pas à une phase de discovery logicielle. Si votre cahier des charges comprend une architecture technique, un modèle de données, les exigences d'intégration et les aspects de conformité – et qu'il a été rédigé par un ingénieur –, vous pouvez peut-être passer directement au développement. S'il a été rédigé par un fondateur ou un chef de produit non technique, une phase de discovery fera presque certainement apparaître des lacunes qui auraient causé des problèmes en cours de réalisation.
Quels outils et quelles méthodes utilisez-vous pendant la phase de discovery ?
Notre processus de sprint de discovery s'appuie sur des ateliers structurés avec le client pour définir le périmètre et les priorités, sur des sessions de revue technique avec des ingénieurs seniors pour évaluer les options d'architecture, et sur une documentation écrite comme livrable principal. Pour les missions de discovery de startups de premier plan, nous recourons aussi au prototypage rapide afin de valider les hypothèses UX lorsque le parcours utilisateur est incertain. Tous les livrables sont fournis dans un format dont le client est propriétaire et qu'il peut confier à n'importe quelle équipe de développement.
La phase de discovery peut-elle se faire à distance ?
Oui – et c'est ainsi que nous menons la plupart de nos services de phase de discovery. Nous travaillons entièrement à distance avec des fondateurs et des CTO au Royaume-Uni, en Irlande, en Allemagne et dans les pays nordiques. Les ateliers de discovery se déroulent en visioconférence, la documentation est partagée en temps réel et les livrables écrits sont produits de façon asynchrone entre les sessions. La seule chose qui change avec la discovery à distance, c'est la logistique – pas la qualité du résultat.
