La plupart des premières versions échouent.Pas par manque de fonctions. Par manque de question.
Une première version qui marche n'est pas une version avec moins de fonctions. C'est une version qui répond à la bonne question, posée à la bonne cible. Voici comment je m'y prends pour qu'elle passe le cap des six premiers mois.
Le constat
Vous avez l'idée. Vous avez peut-être quitté votre emploi, 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 façon dont on cadre ce qu'on va construire.
Pourquoi tant de premières versions échouent
On construit l'idée, pas la question qu'elle pose
Vous avez l'intuition qu'un problème mérite d'être résolu. Mais sans en parler à 10 personnes qui le vivent vraiment, vous construisez 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 question précise, tout devient légitime à développer. Et comme on n'arrive pas à choisir, on inclut tout. La première version 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 choisies. Pas en grand sur les réseaux. Le but n'est pas de faire parler de soi : c'est d'observer comment les premiers utilisateurs s'en servent vraiment. L'attention vient ensuite, si le produit a résisté à cette épreuve.
On n'a pas prévu la suite
Beaucoup de premières versions sortent sans plan pour la suite. Rien pour mesurer ce qui marche, aucun échange suivi avec les utilisateurs, aucun critère pour décider de continuer ou de changer de cap. Résultat : trois mois après le lancement, on ne sait pas si ça fonctionne.
Ma méthode
Je cadre, je construis court, j'observe. Trois étapes, jamais sautées.
Formuler la question avant de construire la réponse
Avant la première ligne de code, on définit ensemble la question précise que votre produit doit trancher. Une question, pas dix. « Est-ce que des indépendants paieraient 20 euros par mois pour ce gain de temps précis ? » se teste. « Est-ce que mon produit est utile ? » ne se teste pas.
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.
Mesurer la réponse, ajuster vite
Je mets en place de quoi observer le comportement réel des premiers utilisateurs : qui s'inscrit, qui revient, qui paie, qui décroche. Au bout d'un mois, vous avez des chiffres, et vous savez si vous continuez sur cette voie ou si vous changez de cap.
Une première version sortie en 8 semaines
Hypothèse de départ : les indépendants perdent trop de temps sur leur facturation, et un outil qui la simplifie pourrait être payant. Première version cadrée autour d'une seule fonction : créer et envoyer un devis, encaisser le paiement, en deux clics.
Elle a été proposée à un petit cercle d'indépendants. Le retour était clair : ce n'était pas la création du devis qui posait problème, c'était la relance. La version suivante s'est concentrée là-dessus, et la suite a suivi.
À quoi vous attendre
Première version utilisable en 6 à 8 semaines. C'est le début, pas la fin. Ensuite, le produit évolue toutes les deux à quatre semaines selon ce que vous observez chez les premiers utilisateurs.
Pendant les trois premiers mois, le produit change beaucoup, parfois sur des points qu'on n'avait pas prévus. C'est normal. C'est même le meilleur signe que le projet est vivant.
Le code vous appartient à chaque étape. Vous pouvez passer à une équipe interne le jour où vous embauchez votre premier développeur, sans aucune barrière technique.
Ce que je ne fais pas
Pour être clair sur ce qui ne me correspond pas.
Je ne livre pas une première version avec 30 fonctions.
Avec 30 fonctions, ce n'est plus une première version. Si vous voulez tout, je vous propose de cadrer un produit complet sur 6 à 12 mois : ce n'est plus le même service.
Je ne m'engage pas sur une levée de fonds.
Une première version est un test, pas un argumentaire pour investisseurs. Si votre objectif est de lever des fonds, je peux vous aider à préparer une démonstration solide, mais je ne garantis pas le résultat de votre tour de table.
Je ne construis pas sans avoir cadré la question.
Si vous cherchez seulement un développeur qui exécute, sans passer par le cadrage, je ne suis pas le bon partenaire. Le cadrage est précisément ce qui donne à votre produit une chance de durer.
Les questions qu'on me pose
- Combien de temps pour avoir un MVP en ligne ?
- 6 à 10 semaines pour une première version qui apporte une vraie valeur à tester. 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 cette première version ?
- Oui. C'est un engagement que je prends dès le départ : aucun prototype jetable. Le code de la première version sert de fondation à la suivante.
- Puis-je lever des fonds avec une première version en ligne ?
- C'est souvent le but. Une première version qui fonctionne en ligne convainc bien plus un investisseur qu'une maquette.
- Que se passe-t-il si on doit changer de cap après les premiers retours ?
- Un changement de cap partiel est prévu dès la conception. J'ajuste ce qui ne fonctionne pas sans tout réécrire : c'est l'avantage d'un code bien organisé dès le début.
Si vous voulezen parler.
Un appel de 30 minutes en visio. Vous me racontez l'idée, on regarde ensemble la question qu'elle pose vraiment. Si je pense que vous n'êtes pas prêt à construire, je vous le dis franchement.