Premier produit · web, mobile ou IA
Un MVP n'est pas une version au rabais de votre produit. C'est la plus petite chose que vous puissiez mettre entre les mains de vrais utilisateurs pour savoir si votre idée tient. Tout le travail consiste à choisir quoi ne pas construire.
Depuis deux ans, l'IA écrit une large part de notre code sous contrôle senior — et c'est ici que ça change le plus de choses : ce qui n'entrait pas dans un premier budget entre désormais souvent dans la première version.
C'est la seule question qui définit correctement un périmètre. Pas « quelles fonctionnalités mettre » — la liste est toujours trop longue — mais « quelle incertitude me fait le plus peur ».
Nous avons vu beaucoup de premiers produits.
Y compris ceux qui n'auraient pas dû être construits.
Choisir le périmètre
C'est la partie du travail où l'on vous fait économiser le plus d'argent — en écartant ce qu'il ne fallait pas construire tout de suite.
Un utilisateur trop large donne un produit sans arêtes. Nous cherchons la personne qui a le plus mal, dans la situation la plus précise. C'est elle qui vous dira la vérité.
Ce qui en sort · Un utilisateur cible et un cas d'usage uniqueIl existe toujours une solution actuelle — un tableur, un carnet, un appel, un concurrent. Si elle suffit, votre produit n'a pas de place. Si elle est douloureuse, vous avez votre point d'entrée.
Ce qui en sort · La preuve que le besoin existe déjàLa question la plus utile et la plus rarement posée. Elle révèle l'hypothèse la plus fragile de votre projet — c'est exactement celle que le MVP doit tester en premier.
Ce qui en sort · L'hypothèse à valider avant tout le resteTrajectoire type
Une trajectoire réelle, pas un idéal commercial. Le délai dépend surtout de votre capacité à décider vite — rarement du développement.
Nous écoutons, puis nous challengeons : usage, marché, risques, budget. Nous écartons ensemble ce qui peut attendre. C'est l'étape où vous économisez le plus.
Périmètre écrit · budget · trajectoireVous cliquez dans votre produit avant qu'une ligne de code n'existe. Écrans, parcours, textes. On le fait tester à cinq utilisateurs réels — c'est la meilleure dépense du projet.
Maquettes · prototype · premiers retoursConstruction par incréments avec une démo toutes les deux semaines. L'IA accélère l'écriture, un senior relit tout, les tests tournent à chaque modification.
Démos · code testé · documentationVérification complète, correction, mise en place de la mesure d'usage et préparation de la publication ou du déploiement.
Produit vérifié · analytics posésMise en production, publication sur les Stores le cas échéant, et surveillance rapprochée les premiers jours. Puis on regarde les chiffres ensemble.
En ligne · mesuré · surveilléVous ne restez jamais plus de deux semaines sans voir votre produit avancer. C'est autant une règle de méthode qu'un garde-fou : un client qui ne voit rien pendant deux mois est un client qui découvre trop tard qu'on s'est mal comprises.
Erreurs fréquentes
Nous les avons toutes vues, et parfois accompagnées avant d'apprendre à les signaler à temps. Aucune n'est une question de budget.
Un produit complet dont on a retiré la moitié des fonctions n'est pas un MVP : c'est un produit décevant. Le MVP fait une seule chose, et il la fait bien.
À la place · Un parcours complet et soigné, plutôt que cinq parcours à moitié.
Il y a toujours une fonction supplémentaire qui semble indispensable avant de montrer le produit. Ce réflexe repousse indéfiniment le seul moment utile : la confrontation au réel.
À la place · Fixer la date de mise entre les mains d'utilisateurs dès le cadrage.
Sans mesure d'usage, vous aurez des opinions au lieu de données. Et les opinions les plus fortes viennent souvent des gens qui n'utilisent pas le produit.
À la place · Définir deux ou trois indicateurs avant le lancement, pas après.
« Il faut du natif », « il faut de l'IA », « il faut de la blockchain » : ces décisions prises en amont coûtent cher et ferment des portes pour rien.
À la place · Laisser le besoin dicter la technologie, et demander qu'on le justifie.
Un chiffre donné sans avoir compris le projet est confortable pour tout le monde sauf pour vous : il finit toujours par exploser ou par amputer le produit.
À la place · Investir deux semaines de cadrage payé pour obtenir un chiffre solide.
Un MVP qui n'a pas prévu comment il évoluera devient une impasse technique dès que ça marche — c'est-à-dire au pire moment.
À la place · Des choix d’architecture sobres, réversibles et documentés dès le départ.
Budget
Trois formats selon ce que vous devez prouver. Le chiffre exact vient après le cadrage — jamais avant.
Pas de code : des écrans cliquables, testés auprès de vrais utilisateurs. Le moyen le moins cher de découvrir qu'on se trompait.
Un produit réel, en ligne, entre les mains d'utilisateurs, avec la mesure qui permet de décider de la suite.
Quand l'IA est le moteur du produit, il faut en plus des données propres et une mesure de la qualité des réponses.
Fourchettes indicatives, août 2026. Obtenir une estimation sur votre périmètre →
Après le MVP
La question n'est pas « est-ce que les utilisateurs aiment ». C'est « est-ce qu'ils reviennent, et est-ce que quelqu'un est prêt à payer ». Ces deux réponses décident de la suite bien mieux qu'un avis enthousiaste.
Nous posons les instruments de mesure avant le lancement, pas après. Et nous acceptons qu'une des issues possibles soit d'arrêter — c'est aussi un bon retour sur investissement.
Le sujet devient technique : ce qui tenait pour cent utilisateurs ne tient pas pour dix mille. On renforce l'architecture, la base de données et l'hébergement, on industrialise le déploiement, et on priorise la roadmap avec les données réelles plutôt qu'avec le plan initial.
C'est le cas le plus fréquent, et le plus utile. Une partie du produit trouve son public, une autre non. Le MVP a fait exactement son travail.
Avoir dépensé 40 k€ pour découvrir qu'un marché n'existe pas est un excellent investissement. L'alternative est de le découvrir à 400 k€.
Questions fréquentes
Pour aller plus loin, notre exemple de cahier des charges vous aide à structurer votre besoin avant même de nous parler.
Non, c'est une grande partie de notre travail. Nous expliquons chaque décision en français plutôt qu'en jargon, et nous vous disons quand une demande va coûter cher pour peu de valeur. Vous n'avez pas besoin d'un CTO pour démarrer — vous avez besoin de savoir ce que vous voulez prouver.
Souvent oui, et c'est une bonne contrainte. La question à se poser : vos utilisateurs sont-ils devant un écran ou en mouvement ? Une application mobile impose la publication sur les Stores et leurs délais ; le web se met à jour en une heure. Pour valider une idée, le web gagne presque toujours.
En le décidant avant de le lancer. Nous fixons ensemble deux ou trois critères chiffrés — un taux de retour à sept jours, un nombre d'utilisateurs qui vont au bout du parcours, une intention d'achat exprimée — et les instruments sont posés avant la mise en ligne. Sans ce travail préalable, vous aurez des opinions au lieu d'une décision.
Oui, avec le format prototype testé : entre 8 et 15 k€, sans développement. C'est souvent le meilleur premier pas, et il arrive qu'il vous fasse renoncer au projet — auquel cas il vous a fait économiser dix fois son prix.
Pour une part significative, oui. Elle génère, transforme, documente et teste, avec nos standards chargés à chaque intervention. Mais l'architecture, les arbitrages, la revue et la validation avant production restent sous la responsabilité de développeurs seniors. Sur un premier produit, c'est cette garantie qui compte le plus.
C'est la trajectoire normale d'une startup qui réussit, et nous la préparons dès le départ : des choix technologiques courants plutôt qu'exotiques, une documentation tenue à jour et une architecture sobre. Nous organisons ensuite un transfert accompagné vers votre premier développeur ou votre CTO. Un MVP qui ne peut pas être repris est un MVP raté.
Dites-le franchement, cela change la conversation. Un prototype testé est souvent exactement ce qui débloque un financement, parce qu'il transforme une idée en quelque chose que des investisseurs peuvent manipuler. Nous en avons accompagné plusieurs dans ce sens.
Votre premier produit
Trente minutes pour clarifier ce que vous devez prouver, écarter ce qui peut attendre et estimer une première trajectoire. Vous repartez avec un avis, pas avec un devis — et si votre projet ne nous semble pas mûr, nous vous le dirons.