Première version d'un logiciel, le MVP d'une PME

Une première version, souvent appelée MVP (pour minimum viable product, produit minimum viable), est la plus petite version d'un logiciel qui rend déjà un service réel à ses utilisateurs. Pour une PME, c'est un outil limité à un processus, utilisé pour de bon dès sa mise en service, puis complété étape par étape selon ce que l'usage montre.

L'idée vient du monde des startups. Elle s'applique bien aux outils métier, à condition de l'adapter : une PME ne teste pas un marché, elle teste un outil sur son propre travail. Voici comment délimiter cette première version, ce qu'elle ne doit pas sacrifier et ce qu'elle coûte selon les prix affichés.

D'où vient le terme, et ce qu'il devient dans une PME

Le produit minimum viable désigne la version d'un produit qui permet d'obtenir un maximum de retours des clients avec un minimum d'effort. Le terme a été popularisé par Eric Ries et Steve Blank dans le mouvement dit lean startup. Pour une startup, il sert à vérifier que des clients paieront pour un produit avant d'y investir davantage.

Source : Wikipédia, Produit minimum viable, consulté le 22 octobre 2026.

Dans une PME, la question change. Vous savez déjà que le besoin existe, puisque vos salariés le vivent chaque jour. La première version sert à vérifier que l'outil s'insère dans le travail réel, que les règles de gestion ont été bien comprises et que les utilisateurs l'adoptent. Les retours viennent des salariés, et de vos clients s'il s'agit d'un portail qui leur est ouvert.

Conséquence pratique : une première version de PME doit être fiable. On peut lui retirer des fonctions. Sa solidité, elle, doit être celle d'un outil définitif, puisque des données réelles y passent dès le premier jour.

Une première version se distingue aussi d'une maquette et d'un prototype. La maquette montre les écrans sans fonctionner. Le prototype fonctionne en partie, souvent avec de fausses données, pour tester une idée. La première version sert en production : de vraies données, de vrais utilisateurs, un usage quotidien.

Délimiter le périmètre de la première version

Le bon périmètre tient souvent en une phrase : un processus, de bout en bout, pour un groupe d'utilisateurs. Quelques critères pour le choisir :

• Le processus qui coûte le plus aujourd'hui, en temps, en erreurs ou en clients mécontents.
• Un processus qu'on peut traiter entièrement, du début à la fin, sans en laisser la moitié dans l'ancien outil.
• Un groupe d'utilisateurs volontaires, prêts à signaler ce qui ne va pas.
• Des données simples à reprendre, ou un démarrage à zéro possible sans perte.
• Un résultat mesurable : temps gagné, erreurs évitées, délai réduit.

Exemple inventé pour l'illustration : une entreprise de maintenance de 25 salariés rêve d'un outil complet, avec planning, interventions, devis, facturation et portail client. Sa première version se limite aux bons d'intervention, remplis sur téléphone par les techniciens et transmis au bureau. Le planning reste dans l'outil actuel pendant ce temps, et la facturation continue comme avant. Les étapes suivantes s'ajouteront une fois les bons d'intervention adoptés.

Méfiez-vous du périmètre qui grossit pendant la discussion. Chaque fonction ajoutée « parce qu'elle est petite » retarde la mise en service, qui est le seul moment où l'on apprend vraiment comment l'outil sera utilisé.

Le travail d'expression des besoins, avec son tri entre indispensable, utile et plus tard, donne directement ce périmètre.

Ce qu'une première version ne doit pas sacrifier

• La sécurité. Comptes individuels, droits par profil, connexions chiffrées. Une faille dans une version réduite reste une faille.
• Les sauvegardes. Dès que des données réelles entrent dans l'outil, elles doivent pouvoir être restaurées.
• Les données personnelles. La CNIL recommande de restreindre la collecte au strict nécessaire et de prévoir dès la conception la durée de conservation des données. C'est plus simple à faire dans une version réduite qu'à rattraper ensuite.
• Un code qu'on peut reprendre. Une première version bâclée oblige à tout réécrire pour l'étape suivante, ce qui annule l'économie. Le code source et les accès doivent vous être remis.
• Les règles de gestion du processus choisi. Toutes, exceptions comprises : un outil qui gère mal un cas sur dix finit contourné.
• Une documentation minimale. Comment installer, sauvegarder et restaurer l'outil, écrit quelque part et remis avec le code.

Source : CNIL, Guide RGPD du développeur, consulté le 22 octobre 2026.

Reste la question de la technique. Certaines premières versions se font en no-code, avec des outils qui assemblent une application sans programmer. Le guide no-code ou développement sur mesure compare les deux voies, y compris pour la suite du projet.

Prix et délais affichés

Les studios spécialisés dans les premières versions publient souvent leurs prix, ce que font rarement les agences classiques. Ils visent surtout les startups, mais leurs chiffres donnent un ordre de grandeur.

Sources : Ary Studio, Zetos, développement MVP à Paris et La Fabrique du Net, tarifs des agences de développement web, consultés le 22 octobre 2026.

Ces montants sont des prix publics, pour des périmètres que chaque studio définit à sa façon. Un outil métier de PME, avec ses règles de gestion, sa liaison avec la comptabilité et sa reprise de données, peut demander davantage de travail qu'une première version de startup au même nombre d'écrans. Demandez toujours ce que le prix couvre : hébergement, corrections après livraison, remise du code source. Les repères complets sont sur la page prix d'une application web sur mesure, et le guide sur le délai de développement d'une application explique ce qui allonge ou raccourcit le calendrier.

Après la première version : décider de la suite

La première version n'a d'intérêt que si elle aide à décider. Fixez avant le lancement ce que vous regarderez après quelques semaines d'usage :

• Les utilisateurs se servent-ils de l'outil sans qu'on les y pousse ?
• La mesure de départ (temps, erreurs, délais) a-t-elle bougé ?
• Quelles demandes reviennent le plus souvent ?
• Quels contournements sont apparus ?

Prévoyez aussi un moment fixe pour recueillir les retours, par exemple un point court chaque semaine avec les utilisateurs pilotes, et une liste unique où chaque demande est notée avec son auteur et sa date.

Plusieurs décisions sont alors possibles : poursuivre avec l'étape prévue, changer l'ordre des étapes suivantes, ou arrêter si l'outil ne rapporte pas ce qu'il coûte. Cette dernière option n'existe que si le contrat la permet. C'est pour cela que je travaille avec un prix fixe découpé en étapes, chacune payée une fois livrée et validée, avec la possibilité d'arrêter après n'importe laquelle. Le guide sur l'échéancier de paiement par étapes explique comment le construire.

Quand une première version n'est pas la bonne approche

Le découpage a ses limites, et il fonctionne mal dans quelques situations.

• Le remplacement d'un logiciel qui s'arrête. Si l'ancien logiciel cesse de fonctionner à une date donnée (fin de contrat, fin de support), le nouvel outil doit couvrir dès le départ tout ce qu'il faisait.
• Une obligation réglementaire à respecter en entier. Un outil qui émet des factures doit suivre les règles de facturation dès la première facture : on ne peut pas en livrer la moitié.
• Un processus indivisible. Certains circuits n'ont de valeur que complets. Un portail où vos clients ne peuvent pas suivre leurs commandes ne leur apporte rien.

Dans ces cas, le découpage en étapes reste utile pour le paiement et le suivi, mais la mise en service se fait en une fois. Le budget du projet doit alors être prévu en entier dès le départ.