Réponse courte : en quatorze jours, vous ne pouvez pas prouver qu'un business numérique réussira. Vous pouvez en revanche tester cinq incertitudes avant de développer : le problème existe-t-il, pouvez-vous atteindre les personnes concernées, votre promesse déclenche-t-elle un comportement, l'économie peut-elle fonctionner et savez-vous livrer une première valeur ?
Le protocole ci-dessous ne demande ni application complète ni automatisation. Il utilise des entretiens, une offre précise, un prototype léger et une livraison manuelle. Son résultat n'est pas une présentation rassurante, mais une décision documentée : poursuivre, reformuler ou arrêter.
Principe Forge Labs : ne pas demander aux gens s'ils aiment une idée. Observer ce qu'ils font face à une proposition concrète, puis augmenter progressivement le niveau d'engagement demandé.
Les cinq incertitudes à tester
- Le problème : une situation précise produit-elle une perte, un risque, une attente ou un effort assez important pour être traité ?
- L'accès : existe-t-il un canal réaliste pour rencontrer ou acquérir les premiers utilisateurs ?
- La valeur : une promesse ciblée provoque-t-elle un essai, un rendez-vous, une recommandation ou un paiement ?
- L'économie : la valeur et la fréquence peuvent-elles supporter les coûts d'acquisition, de livraison, de support et d'exploitation ?
- La faisabilité : pouvez-vous livrer le résultat avec les données, compétences, partenaires et contraintes disponibles ?
Cette logique part du problème plutôt que de la solution. L'approche d'investigation de beta.gouv.fr, conçue pour les services publics numériques, suit le même principe : rencontrer les utilisateurs, qualifier le problème puis tester la valeur d'une solution avec un prototype, une maquette ou un site minimal. Le contexte entrepreneurial est différent, mais la réduction de l'incertitude avant construction reste directement utile.
Une échelle de preuve pour ne pas confondre intérêt et demande
| Niveau | Signal | Ce qu'il démontre | Ce qu'il ne démontre pas |
|---|---|---|---|
| 1 | Opinion positive | La proposition est compréhensible ou sympathique | Un usage futur |
| 2 | Problème raconté avec un exemple récent | La situation existe pour cette personne | Sa priorité ou sa fréquence dans le marché |
| 3 | Temps consacré à un essai ou un rendez-vous | La personne accepte un premier coût d'attention | Une volonté de payer |
| 4 | Donnée, accès ou mise en relation fournis | La personne veut avancer dans des conditions réelles | Une adoption durable |
| 5 | Pilote payé, précommande ou engagement contractuel | La valeur perçue supporte un coût | Une économie à grande échelle |
| 6 | Usage répété ou renouvellement | Le résultat mérite d'être obtenu à nouveau | Une croissance rentable |
Le but des quatorze jours est de monter aussi haut que possible sur cette échelle sans fabriquer le produit. Tous les projets ne peuvent pas demander un paiement immédiat ; dans ce cas, définissez l'engagement le plus coûteux et pertinent que le contexte autorise.
Jours 1 et 2 — Formuler le problème sans votre solution
Jour 1 : écrivez une phrase falsifiable : « [type de personne] rencontre [situation observable] lorsqu'elle veut [objectif], ce qui entraîne [conséquence mesurable]. » Bannissez le nom du produit et sa technologie. Une formulation comme « les PME ont besoin d'IA » ne décrit ni une personne, ni un moment, ni une conséquence.
Jour 2 : dessinez la chaîne actuelle. Qui déclenche l'action ? Quelles étapes, décisions, attentes et contournements suivent ? Où l'argent, le temps, le risque ou l'information se perdent-ils ? Recherchez aussi les solutions déjà utilisées : concurrent, tableur, prestataire, procédure interne ou abandon.
Le référentiel public d'écoconception recommande de définir les cibles, leurs usages et leurs besoins réels, mais aussi de vérifier si un service existant répond déjà au besoin. Cette discipline protège contre le produit redondant et les fonctionnalités sans utilisateur.
Jours 3 à 5 — Obtenir des faits lors d'entretiens
Jour 3 : recrutez des personnes ayant vécu récemment la situation. Un premier ensemble de cinq à dix entretiens peut faire apparaître des mécanismes et des différences ; il ne constitue pas un échantillon statistique. Variez les profils qui pourraient modifier la décision : fréquence, taille, maturité, rôle ou outil actuel.
Jour 4 : menez les entretiens sur le passé, pas sur l'intention. Demandez : « Racontez la dernière fois », « Qu'avez-vous fait ? », « Combien de temps cela a-t-il pris ? », « Qui a été impliqué ? », « Qu'avez-vous essayé ? » Évitez « Utiliseriez-vous… ? », qui invite à être poli et à imaginer un futur sans contrainte.
Jour 5 : consignez séparément les faits, les interprétations et les citations de travail. Ne retenez pas seulement les témoignages qui confirment l'idée. Classez les personnes pour lesquelles le problème est fréquent, coûteux et déjà traité avec un budget ou un effort significatif.
Jour 6 — Choisir une cible étroite et un résultat
Sélectionnez le segment où les preuves sont les plus fortes, même s'il est plus petit que le marché imaginé. Définissez un résultat observable : réduire un délai, produire une décision, éviter une erreur, trouver une information ou accomplir une transaction.
Votre promesse doit relier la situation au résultat : « Pour [cible] qui rencontre [problème], nous obtenons [résultat] sans [coût ou risque du contournement actuel]. » Si elle contient trois cibles, quatre problèmes et une liste de fonctions, elle n'est pas encore testable.
Jours 7 et 8 — Construire le test, pas le produit
Jour 7 : choisissez le plus petit dispositif capable de livrer le résultat. Cela peut être une analyse manuelle, un tableur interne, une maquette cliquable, un formulaire suivi d'un traitement humain ou une page présentant une offre. L'utilisateur ne doit pas être trompé : si le service est manuel ou expérimental, dites-le.
Jour 8 : préparez le parcours complet : message d'entrée, explication, action demandée, livraison, suivi et mesure. Collectez uniquement les informations nécessaires au test. La CNIL rappelle le principe de minimisation des données : les données doivent être adéquates, pertinentes et nécessaires au regard de la finalité définie.
Jour 9 — Tester un canal d'accès réel
Choisissez un canal que vous pourriez encore utiliser après le test : contacts directs, communauté, partenariat, audience éditoriale, recherche, événement ou prospection ciblée conforme. Envoyez une proposition précise à un groupe identifié et mesurez chaque étape : personnes jointes, réponses, conversations et essais.
Un excellent entretien obtenu par relation personnelle valide le problème, pas le canal d'acquisition. Notez donc l'origine de chaque participant. Si aucune personne concernée n'est accessible sans effort disproportionné, le risque de distribution devient un résultat du test, pas un détail à reporter.
Jours 10 et 11 — Livrer la valeur manuellement
Jour 10 : exécutez le service pour quelques utilisateurs. Chronométrez les opérations, listez les données manquantes et observez où vous devez improviser. La livraison manuelle révèle les règles que l'interface aurait masquées.
Jour 11 : recommencez avec les corrections indispensables seulement. Vérifiez que le résultat est effectivement utilisé : une recommandation appliquée, un dossier traité, une décision prise ou un temps évité. Une livraison appréciée mais inutilisée indique souvent une faible priorité.
Jour 12 — Demander un engagement proportionné
Demandez une action qui a un coût réel : payer un pilote, signer une lettre d'intention précise, réserver une date, fournir les données nécessaires, présenter un décideur ou recommencer le service. Présentez les conditions honnêtement, y compris les limites de la version testée.
Un refus n'invalide pas automatiquement le problème. Demandez ce qui bloque : prix, confiance, timing, intégration, priorité, résultat ou autorité de décision. Classez la cause ; ne réduisez pas immédiatement le prix, car vous perdriez l'information recherchée.
Jour 13 — Tester l'économie avec trois scénarios
Construisez un modèle prudent, central et ambitieux :
marge unitaire = prix net − coût de livraison − support variable − coûts techniques variables
Pour une offre à revenus récurrents, utilisez :
délai de récupération en mois = coût d'acquisition / marge mensuelle récurrente par client
Pour un achat ponctuel, ne transformez pas artificiellement la marge en revenu mensuel : suivez le nombre de ventes — ou la durée — nécessaire pour que la marge cumulée couvre le coût d'acquisition. Pour chiffrer aussi le produit, l'intégration, l'exploitation et les risques, consultez le guide Combien coûte réellement un logiciel métier en 2026 ?.
Incluez le temps humain de la livraison manuelle, même s'il est réalisé par le fondateur. Identifiez ce que le produit pourrait réellement automatiser et ce qui restera du jugement, de la relation ou du contrôle. Un modèle qui devient rentable seulement avec un volume non testé doit être marqué comme hypothèse, pas comme prévision.
Jour 14 — Décider avec des critères écrits avant
| Décision | Signaux | Action suivante |
|---|---|---|
| Poursuivre | Problème répété, engagement significatif, livraison utile, économie plausible | Construire la plus petite capacité qui réduit le coût manuel dominant |
| Reformuler | Problème réel mais cible, promesse, canal ou prix mal aligné | Modifier une hypothèse à la fois et lancer un second test |
| Arrêter | Problème faible, déjà bien résolu, accès impossible ou économie incohérente | Conserver les enseignements et libérer les ressources |
Fixez avant le test les seuils qui comptent pour vous : nombre de problèmes récents documentés, engagements obtenus, coût de livraison, marge possible et contraintes bloquantes. Les seuils varient selon un SaaS à faible prix, une place de marché ou un service à forte valeur ; l'important est de ne pas les réécrire après avoir vu les résultats.
Quatre faux positifs fréquents
- Les compliments : une idée compréhensible n'est pas une priorité financée.
- La liste d'attente : une adresse email coûte peu ; mesurez la présence au rendez-vous ou l'essai accompli.
- Le prototype spectaculaire : il peut tester l'interface tout en masquant la difficulté des données, de la distribution ou de la livraison.
- Le pilote sur mesure : un client satisfait d'un travail artisanal ne prouve pas encore qu'un produit commun peut servir d'autres clients avec une économie saine.
Que construire après un test positif ?
Automatisez d'abord la partie répétitive qui limite la livraison ou la qualité. Conservez manuellement les décisions encore incertaines. Une première version peut être une interface interne, un portail minimal, une API ou un workflow ; elle n'a pas besoin de reproduire toute l'expérience finale.
Reliez chaque fonction à une preuve du test : « cette étape empêche trois abandons observés », « ce contrôle réduit le temps dominant », « cet export est requis pour l'engagement obtenu ». Une fonction sans preuve reste une hypothèse et doit concourir pour sa place.
La phase de construction de beta.gouv.fr illustre également cette logique : confronter rapidement une première version à des utilisateurs et l'améliorer par itérations. Là encore, il ne s'agit pas de copier un programme public, mais de conserver son mécanisme utile : financer l'apprentissage avant l'expansion.
Le livrable des quatorze jours est une décision
Tester une idée sans développer le produit ne consiste pas à éviter tout travail. Il faut rencontrer les personnes, livrer un résultat, demander un engagement et construire un modèle économique. Ce travail est précisément ce qui empêche de confondre vitesse de développement et progrès entrepreneurial.
Après quatorze jours, vous devez pouvoir nommer les preuves, les objections et les inconnues restantes. Si le signal est fort, construisez la plus petite capacité qui améliore la livraison. S'il est ambigu, modifiez une hypothèse. S'il est faible, arrêter est un résultat utile : vous venez d'économiser le produit le plus coûteux, celui que personne n'attend.
Sources consultées
- beta.gouv.fr — Identifier le problème à résoudre : l'investigation, consulté en juillet 2026.
- beta.gouv.fr — Réaliser un service public numérique : la construction, consulté en juillet 2026.
- Mission interministérielle Numérique écoresponsable — Définir les cibles et besoins réels, version 2, mise à jour le 24 septembre 2024.
- CNIL — Minimiser les données collectées, consulté en juillet 2026.