ServiceDéveloppement logiciel
De l'idée au MVP : construire le plus petit produit qui prouve, puis le faire grandir
Notre service MVP et prototypes transforme une idée d'activité en quelque chose qu'on peut utiliser, en deux temps : d'abord un prototype cliquable pour vérifier que l'idée parle aux personnes visées, puis un produit minimum viable (MVP) — la plus petite version à laquelle de vrais utilisateurs peuvent s'inscrire, payer ou se fier. Il repose sur les mêmes fondations qu'un produit complet (dev, recette et prod, prévisualisations, compilations automatisées) : un MVP qui marche grandit au lieu d'être réécrit.
Ce que nous faisons pour vous
- Une séance de cadrage qui ramène l'idée à une phrase, un utilisateur cible et une question mesurable
- Un prototype cliquable sur une adresse de prévisualisation que vous pouvez montrer à des prospects ou partenaires
- Un MVP avec les quelques fonctions qui répondent à la question — et la liste écrite de ce qui est volontairement laissé de côté
- Le paiement quand la question est « vont-ils payer » (page de paiement hébergée comme Stripe), l'e-mail quand elle est « vont-ils revenir »
- Une mesure des actions qui comptent, pour que la réponse soit mesurée et non devinée
- dev, recette et prod dès le premier jour, pour que le MVP puisse devenir le produit
- Une réunion de décision : continuer, changer ou arrêter, selon ce que les utilisateurs ont réellement fait
Pour qui
- Pour vous si vous êtes fondateur ou dirigeant avec une idée de produit, de plateforme ou d'outil interne
- Pour vous si vous voulez tester une nouvelle offre auprès de vrais clients avant de financer un développement complet
- Pour vous s'il vous faut une démonstration qui fonctionne pour des investisseurs, des partenaires ou un client pilote
- Pas pour vous si chaque fonction est « indispensable » dès le premier jour : c'est un développement complet, voir logiciel sur mesure
- Pas pour vous s'il s'agit d'applications mobiles natives : nos MVP sont des applications web adaptées au mobile et installables
Prototype, MVP, produit : trois choses différentes
Dire à l'avance quel stade on construit évite les deux échecs classiques : un prototype vendu comme un produit, et un produit développé des mois avant que quiconque ne l'essaie.
| Stade | Ce que c'est | Ce qu'il prouve | Ce qu'il n'est pas |
|---|---|---|---|
| Prototype | Des écrans cliquables au contenu réaliste, peu ou pas de serveur | Que l'idée est comprise et désirée par ceux à qui elle s'adresse | Un outil sur lequel on peut compter |
| MVP | La plus petite version qui marche : vrais comptes, vraies données, souvent vrais paiements | Que les gens s'en servent, reviennent ou paient | Complet, peaufiné ou dimensionné pour la masse |
| Produit | Le MVP enrichi de ce que demandent les utilisateurs | Qu'il peut faire vivre une activité | Terminé — il continue d'évoluer |
Notre déroulé
- Une question. « Les organismes de formation paieront-ils pour cet outil ? », « Les clients réserveront-ils en ligne plutôt que d'appeler ? » Le MVP existe pour y répondre.
- Le périmètre sur une page. Fonctions retenues, fonctions écartées, et la mesure du succès.
- Prototype. Des écrans sur une adresse de prévisualisation. Vous les montrez à cinq ou dix vraies personnes, nous ajustons.
- Construction du MVP. Par petites tranches, chacune visible sur sa prévisualisation, avec la recette pour vos tests avant la production.
- Lancement auprès de vrais utilisateurs. Paiement et mesure en place dès le départ, pour que la réponse soit dans les données.
- Décider. Nous regardons l'usage avec vous et convenons de la suite — ou de l'arrêt.
Des produits que nous avons construits et exploitons
Des produits du type de ceux auxquels mène un MVP, que nous avons construits et exploitons aujourd'hui : un logiciel de gestion en SaaS pour organismes de formation en France (Next.js + Postgres, aujourd'hui en production), des générateurs de documents qui produisent courriers et documents réglementaires au nom de l'acheteur et les vendent en ligne, une plateforme d'e-learning vendant des modules SCORM avec attestations, des annuaires dont un recense plus de 4 900 traducteurs assermentés, et un assistant de devis pour une entreprise de safari en Afrique australe, construit dès le départ avec des environnements dev, recette et prod séparés. Nous ne publions pas leur chiffre d'affaires ; nous pouvons vous montrer comment ils ont été cadrés.
Petit, mais pas bâclé
Un MVP peut faire l'impasse sur des fonctions, pas sur les fondations. Les nôtres ont la même chaîne que les gros projets : compilation sur GitHub Actions, chaque exécution tournant dans une machine virtuelle neuve ; branches protégées qui exigent une relecture et des contrôles réussis avant fusion ; Docker Compose pour que le MVP tourne de la même façon dans chaque environnement. Pour le paiement, nous utilisons des pages hébergées — Stripe décrit Checkout comme une page de paiement intégrée à votre site ou accessible par redirection vers une page hébergée par Stripe — plutôt que de coder nous-mêmes des formulaires de carte. C'est ce qui permet à un MVP réussi de grandir sans réécriture.
Ce qui vous appartient, et ce dont nous avons besoin
- Le code (dans un dépôt que vous contrôlez), le nom de domaine, le compte de paiement et les données utilisateurs sont à vous
- Il nous faut un décideur, disponible chaque semaine
- L'accès à cinq à dix vraies personnes de votre cible pour tester le prototype
- Votre réponse franche, à la fin : les données disent-elles de continuer ?
Les questions qu'on nous pose
Quelle différence entre un prototype et un MVP ?
Un prototype, ce sont des écrans cliquables pour vérifier que l'idée est comprise et désirée. Un MVP est la plus petite version qui fonctionne, à laquelle de vrais utilisateurs peuvent s'inscrire, qu'ils peuvent utiliser ou payer.
Faudra-t-il réécrire le MVP plus tard ?
Pas s'il repose sur de bonnes fondations. Les nôtres utilisent les mêmes environnements, compilations et hébergement qu'un produit complet : il peut grandir.
Le MVP peut-il encaisser des paiements ?
Oui. Quand la question est de savoir si les gens paieront, nous ajoutons une page de paiement hébergée comme Stripe pour obtenir une vraie réponse.
Comment décider de continuer ?
Avec la mesure convenue au départ (inscriptions, réservations, paiements, retours) et une réunion où l'on regarde ce que les utilisateurs ont réellement fait.
Pouvez-vous en faire une application mobile ?
Nous construisons des applications web adaptées au téléphone et installables. Nous n'avons pas encore livré d'application native iOS ou Android.
Sources
- GitHub Docs — Comprendre GitHub Actions (consulté le 2026-10-06)
- GitHub Docs — À propos des branches protégées (consulté le 2026-10-06)
- Docker Docs — Modèle d'application Compose (consulté le 2026-10-06)
- Stripe Docs — Créer une page de paiement (Checkout) (consulté le 2026-10-06)