Sachez avant de tout dépenser.
Un MVP n’est pas une version au rabais du vrai produit. C’est la plus petite construction qui réponde honnêtement à une question : les gens vont-ils vraiment l’utiliser, et vont-ils payer ?
Nous construisons le plus petit produit qui permette de vérifier que votre idée tient : un vrai logiciel, avec de vrais utilisateurs, pas une maquette. Le cadrage compte plus que le développement, parce que la plupart des MVP échouent en étant trop gros. Périmètre et date sont fixés par écrit avant de commencer.
Mis à jour novembre 2026
Le plus difficile, c’est de décider ce qu’on laisse de côté.
La première liste de chaque fondateur est trop longue, la nôtre comprise. Tout y semble nécessaire parce que vous voyez déjà le produit fini — mais ce n’est pas le produit fini que vous construisez maintenant.
La question à laquelle répond un MVP est étroite : les gens en veulent-ils assez pour l’utiliser, et pour payer ? Tout ce qui n’aide pas à y répondre peut attendre, y compris ce dont vous aurez forcément besoin plus tard.
Nous passons donc un vrai temps sur le cadrage avant de chiffrer. C’est la partie la moins facturable du travail et de loin la plus précieuse : un lancement plus petit vous apprend plus tôt, et il vous reste du budget pour agir sur ce que vous avez appris.
Ce que vous recevez.
Un vrai logiciel, pas un prototype
Déployé, fonctionnel, avec de vrais utilisateurs. Une maquette cliquable ne peut pas vous dire si les gens reviennent.
La seule chose qu’il doit faire
Construite proprement. Tout le reste construit simplement, ou pas du tout.
Le paiement, si c’est la question
Le seul test fiable de la disposition à payer, c’est de demander aux gens de payer.
Des statistiques dès le premier jour
Où les gens s’arrêtent, ce qu’ils ne touchent jamais. Sans cela, vous lancez et vous n’apprenez rien.
Un moyen de parler à vos utilisateurs
Les cinquante premiers valent plus en conversations qu’en chiffres.
Des fondations qui ne vous enferment pas
Des technologies standard, une structure saine. Rapide, sans décider de votre architecture pour les cinq prochaines années.
Un cadrage honnête d’abord
Y compris vous dire quand quelque chose n’a pas encore besoin d’être construit.
Un code qui vous appartient
À vous dès le premier commit. Continuez avec nous, avec votre équipe ou avec qui vous voulez.
Ce qu’on coupe, et ce qu’on ne coupe jamais.
Les décisions qui font qu’un MVP sort à la date prévue, ou avec des mois de retard.
| Première version | Plus tard | Pourquoi | |
|---|---|---|---|
| L’action centrale pour laquelle le produit existe | Oui | — | Sans elle, il n’y a rien à tester |
| Le paiement, si vous testez la disposition à payer | Oui | — | Une intention n’est pas une preuve |
| Inscription et comptes | Le plus simple possible | SSO, équipes, rôles | Nécessaire, mais ce n’est pas la question |
| Console d’administration | Un accès à la base suffit | De vrais outils | Seule votre équipe la voit |
| Réglages et préférences | Aucun | Oui | Personne ne part faute de réglages |
| Parcours d’accueil | Minimal | Conçu proprement | Vous ne savez pas encore où les gens calent |
| Application mobile | Rarement | Si l’usage le justifie | Une application web responsive teste la même idée |
Notre façon de cadrer.
Si votre liste ne rentre pas, nous la coupons avec vous plutôt que de repousser discrètement l’échéance.
Lancer sans mesurer est la façon la plus courante pour un MVP de n’apprendre rien.
Si des clients vous paient déjà pour ce service fait à la main, vous n’avez pas besoin d’un MVP.
Quand un MVP est le bon choix.
Vous avez une idée et aucune preuve
Le cas classique. Construisez la plus petite chose qui produise une preuve.
Vous levez des fonds et il vous faut de la traction
Des chiffres d’usage réels convainquent des investisseurs. Une présentation qui décrit un produit, non.
Vous le faites à la main aujourd’hui
Le meilleur point de départ qui soit : vous savez déjà que le processus fonctionne.
Ce n’est pas pour vous si… vous avez déjà la preuve
Si des clients vous paient déjà pour ce service fait à la main, construisez le vrai produit. Nous vous le dirons.
Comment nous travaillons.
Nous formulons la question
Qu’est-ce qui doit être vrai pour que cela marche ? Tout le reste sert à y répondre.
Nous coupons la liste, ensemble
La conversation la plus difficile et la plus utile. Attendez-vous à retirer plus de la moitié.
Nous fixons le périmètre et la date
Fixés, par écrit. Un MVP au périmètre mouvant n’est pas un MVP.
Nous concevons le parcours central
Cliquable, pour que vous le sentiez avant qu’il soit construit. Des jours, pas des semaines.
Nous développons par blocs de deux semaines
Un logiciel utilisable toutes les deux semaines. Pas de surprise à la fin.
Nous lançons et mesurons
Des statistiques en place dès le premier jour, parce que lancer sans mesurer gâche tout l’exercice.
Nous regardons ce qui s’est passé
Ce que les gens ont fait, pas ce qu’ils ont dit. Puis nous décidons ensemble de la version deux — ou s’il doit y en avoir une.
Développement de MVP
7 questions, avec leurs réponses. Vous en avez une autre ? Écrivez-nous.
Moins que ce que vous dépenseriez pour apprendre la même chose à la dure. Nous ne publions pas de chiffres parce que la fourchette est réellement large et dépend presque entièrement du périmètre. Ce que nous pouvons dire, c’est que la conversation de cadrage fait bouger le montant bien plus que n’importe quel choix technique, et que nous l’avons avant de chiffrer, pas après.
Sept catégories. Quarante-cinq services.
Décrivez-nous votre projet. Franchement.
Ce que vous voulez construire, ce qui vous bloque, et le budget si vous l’avez. Nous répondons sous un jour ouvré, et nous vous dirons honnêtement si nous ne sommes pas les bonnes personnes.