70% des premières versions meurent. Pas par manque de fonctions. Par manque de question.

Le constat

Vous avez l'idée. Vous avez peut-être quitté votre job, ou vous y pensez. Vous voulez sortir une première version vite pour tester. Vous cherchez un développeur qui livre en six semaines.

C'est exactement à ce moment qu'on prend les décisions qui feront vivre ou mourir le projet. Pas dans le code. Dans la manière dont on cadre ce qu'on va coder.

Pourquoi tant de premières versions échouent

On code l'idée, pas la question qu'elle pose

Vous avez l'intuition que tel problème mérite d'être résolu. Mais sans en parler à 10 personnes qui le vivent vraiment, vous codez votre intuition. Six mois plus tard, vous découvrez que le vrai problème était à côté. Vous recommencez.

Le périmètre gonfle parce qu'on n'a pas tranché

Sans une question précise, tout devient légitime à développer. Et comme on n'arrive pas à choisir, on inclut tout. Le MVP devient un produit, le produit devient une plateforme, et la plateforme n'est jamais lancée.

On confond première version et lancement

Une première version se lance auprès de 5, 10, 50 personnes ciblées. Pas en grand sur les réseaux. L'objectif n'est pas de faire du buzz, c'est d'observer comment les premiers utilisateurs s'en servent vraiment. Le buzz vient si le produit a déjà résisté à cette épreuve.

On n'a pas prévu ce qui se passe après

Beaucoup de MVP sont sortis sans plan pour la suite. Pas de manière de mesurer ce qui marche, pas de boucle de retour avec les utilisateurs, pas de critère pour décider de continuer ou de pivoter. Résultat : trois mois après le lancement, on ne sait pas si ça fonctionne ou pas.

Notre méthode

On cadre, on construit court, on observe. Trois étapes, jamais sautées.

1. Formuler la question avant de coder la réponse

   Avant la première ligne de code, on définit ensemble quelle question précise votre produit cherche à valider. Une question, pas dix. "Est-ce que les indépendants paieraient 20 euros par mois pour ce gain de temps précis", c'est une question testable. "Est-ce que mon produit est utile" n'en est pas une.

2. Construire le strict minimum qui répond à la question

   Tout ce qui ne répond pas à la question est reporté. Pas supprimé, reporté. Pas de tableau de bord avancé, pas de système de droits complexe, pas d'application mobile. Une seule fonction, qui répond à la question, en six à huit semaines.

3. Mesurer la réponse, ajuster vite

   On installe ce qu'il faut pour observer le comportement réel des premiers utilisateurs : qui s'inscrit, qui revient, qui paye, qui décroche. Vous avez des chiffres au bout d'un mois, et vous savez si vous continuez sur cette voie ou si vous pivotez.

À quoi vous attendre

Première version utilisable en 6 à 8 semaines. C'est le début, pas la fin. À partir de là, le produit évolue toutes les deux à quatre semaines selon ce que vous observez sur les premiers utilisateurs.

Pendant les trois premiers mois, le produit change beaucoup, parfois sur des choses qu'on n'avait pas anticipées. C'est normal. C'est même le seul critère qui montre que le projet est vivant.

Le code vous appartient à chaque étape. Vous pouvez basculer vers une équipe interne le jour où vous embauchez votre premier développeur, sans aucune barrière technique.

Ce qu'on ne fait pas

Pour être clair sur ce qui ne nous correspond pas :

• On ne livre pas une première version avec 30 fonctions. Une première version avec 30 fonctions n'est plus une première version. Si vous voulez tout, on cadre un produit complet sur 6 à 12 mois, ce n'est plus le même service.
• On ne s'engage pas sur une levée de fonds. Un MVP est un test, pas un argumentaire d'investissement. Si votre objectif est de lever, on peut vous aider à préparer une démo solide, mais on ne garantit pas le résultat de votre tour de table.
• On ne code pas sans avoir cadré la question. Si vous voulez juste un développeur d'exécution, sans passer par la phase de cadrage, on n'est pas le bon partenaire. La phase de cadrage est précisément ce qui fait que votre produit a des chances de survivre.

Les questions qu'on nous pose

Combien de temps pour avoir un MVP en production ?

6 à 10 semaines pour un MVP avec une valeur testable réelle. Moins si le périmètre est très resserré, on en parle lors du cadrage.

Le code sera-t-il réutilisable après le MVP ?

Oui. C'est un engagement qu'on prend dès le départ. Pas de prototype jetable. Le code du MVP est la fondation de la v1.

Puis-je lever des fonds avec un MVP livré ?

C'est souvent le but. Un MVP fonctionnel en production est plus convaincant pour un investisseur qu'une maquette Figma.

Que se passe-t-il si on doit pivoter après les premiers retours ?

Un pivot partiel est prévu dans l'architecture. On ajuste ce qui ne fonctionne pas sans tout réécrire, c'est l'avantage d'un code bien structuré dès le début.