MVP : commencer petit sans tout refaire ensuite

« Commençons petit » est un bon réflexe, à une condition : que le petit puisse grandir. Beaucoup d’entreprises paient deux fois la même application, parce que la première version a été construite comme une maquette jetable. Voici comment je cadre un MVP d’application métier : ce qu’on coupe, ce qu’on garde et combien ça coûte.

Ce qu’est vraiment un MVP pour une entreprise

Dans une start-up, le MVP sert à vérifier qu’un marché existe. Dans une PME ou une ETI, la question est différente : le besoin est connu (une équipe ressaisit, un tableur déborde, un logiciel ne suit plus) et il s’agit de mettre en production vite la partie qui rapporte le plus, sans bloquer la suite.

Un bon MVP d’application métier coche trois cases :

• il remplace un vrai processus de bout en bout, même étroit (par exemple la prise de commande, pas « un peu de tout ») ;
• il est utilisé tous les jours par un groupe réel, pas seulement montré en réunion ;
• il repose sur des fondations qui accueilleront les lots suivants sans réécriture.

Prototype, MVP, version complète : les ordres de grandeur

Ces montants sont hors taxes, tirés de mon barème public. Le devis devient ferme après le cadrage.

Exemple d’illustration, à partir des briques de l’estimateur : un MVP de suivi d’interventions avec comptes et rôles (1 500€), back-office (2 000€) et tableau de bord (1 500€) s’ajoute au socle de l’application ; la connexion à votre logiciel comptable (2 000€) peut attendre le lot 2. Pour votre propre cas, l’estimateur donne une fourchette en une minute.

Ce qu’on peut couper sans risque

Pour tenir le budget d’un MVP, je coupe dans le périmètre, jamais dans la construction. Peuvent attendre :

• les profils secondaires : si les commerciaux sont le cœur du besoin, l’espace direction viendra au lot 2 ;
• les automatisations de confort : relances automatiques, exports sur mesure, notifications fines ;
• les connexions non vitales : un export CSV propre peut remplacer une synchronisation pendant quelques semaines ;
• le design premium : une interface sobre, rapide et cohérente suffit pour démarrer ;
• les cas rares : le processus qui concerne 2 % des dossiers peut rester manuel au début.

Ce qu’il ne faut jamais sacrifier

Ce sont ces points qui font la différence entre un MVP qui grandit et un MVP qu’on jette.

1. Le modèle de données. Clients, commandes, produits, interventions : la structure de la base doit refléter votre métier réel, y compris ce qui viendra plus tard. Changer un modèle de données en production coûte bien plus cher que de le penser au cadrage.
2. Les comptes et les droits. Même avec deux profils au départ, le système de rôles doit être prévu pour en accueillir d’autres.
3. La sécurité de base : authentification solide, accès limités, sauvegardes, données hébergées dans un cadre conforme au RGPD.
4. Un code lisible, versionné, qui vous appartient. Chez moi, le code source et les droits sont cédés au client après paiement complet. C’est ce qui vous permet de continuer avec moi ou avec un autre prestataire.
5. Une stack standard. J’utilise des technologies répandues (React, TypeScript, Node.js, PostgreSQL via Supabase) pour que n’importe quel développeur compétent puisse reprendre le projet.

C’est exactement ce qui manque souvent aux prototypes générés trop vite. Si vous en êtes là, la page mettre en production un prototype interne détaille comment faire le tri.

Quand le MVP n’est pas la bonne approche

Je le dis franchement : un MVP sur-mesure n’a pas de sens dans tous les cas.

• Un logiciel du marché couvre déjà 80 % du besoin et le reste peut s’adapter : prenez-le et gardez le sur-mesure pour plus tard si nécessaire.
• Le besoin n’est pas encore clair dans l’entreprise : quelques ateliers de cadrage et des maquettes valent mieux qu’un développement prématuré.
• Le processus ne se découpe pas : une obligation réglementaire ou une bascule complète d’un ancien logiciel impose parfois de livrer un périmètre minimal plus large.
• Personne n’a le temps de tester : un MVP sans groupe pilote disponible ne produit aucun apprentissage.

Comment se déroule un projet en mode MVP

1. Appel de 30 minutes pour identifier le processus qui rapporte le plus.
2. Cadrage (1 à 2 semaines) : périmètre du MVP, liste de ce qui est repoussé, devis ferme et planning. Le cahier des charges distingue clairement le lot 1 des suivants.
3. Maquettes cliquables (1 à 3 semaines) testées par le futur groupe pilote.
4. Développement par lots, chacun testé par vos équipes.
5. Mise en ligne pour le groupe pilote, reprise des données utiles, formation, puis 3 mois de support inclus.
6. Bilan d’usage avant de chiffrer le lot suivant, à partir de ce que l’équipe utilise vraiment.

Le paiement suit ce rythme : 50 % d’acompte au démarrage, prix forfaitaire par lot. Le détail de l’offre est sur la page applications métier.