Développement de MVP pour startups et PME

Qu'est-ce qu'un MVP, et qu'est-ce que ce n'est pas ?

Un MVP (Minimum Viable Product, produit minimum viable) est la plus petite version d'un produit qui permet de vérifier une hypothèse de marché avec de vrais utilisateurs. « Minimum » concerne les fonctionnalités, pas la qualité : peu de choses, faites pour fonctionner à chaque fois. Un MVP n'est pas un prototype cliquable, qui sert à montrer une idée mais pas à l'utiliser, et ce n'est pas la version 1.0 avec tout ce que vous voudriez offrir un jour. C'est un vrai produit, avec des utilisateurs, des données, une authentification et, si nécessaire, des paiements, réduit au parcours qui démontre sa valeur. Pour une place de marché, il peut suffire de faire se rencontrer l'offre et la demande dans une seule catégorie ; pour un logiciel par abonnement, d'automatiser un seul flux de travail pour un seul type de client. Tout le reste est reporté explicitement, jusqu'à ce que les données montrent qu'il vaut la peine de le construire.

Quand faut-il développer un MVP, et quand ne faut-il pas ?

C'est utile quand vous avez une hypothèse précise à vérifier et un groupe d'utilisateurs que vous pouvez vraiment atteindre : un secteur que vous connaissez, une liste d'attente, les clients actuels de votre entreprise. C'est utile quand vous devez montrer de la traction à des investisseurs ou à des partenaires avec des chiffres réels plutôt qu'avec des slides. C'est utile aussi pour une PME qui veut lancer un nouveau service numérique sans arrêter le travail quotidien, ou transformer en produit un processus qu'elle gère aujourd'hui à la main.

Ce n'est pas utile quand l'hypothèse peut être vérifiée sans écrire de code. Souvent, une page de présentation avec un formulaire de réservation, ou un service rendu à la main aux dix premiers clients, vous apprend en deux semaines ce qu'un MVP vous apprendrait en deux mois. Nous vous le disons dès le premier échange : un projet lancé sans raison vous coûte de l'argent et ne nous sert à rien.

Comment développe-t-on un MVP, phase par phase ?

Les phases sont toujours les mêmes ; c'est leur durée qui change. Le tableau présente notre parcours type pour un MVP web de complexité moyenne, d'environ six semaines. C'est un modèle de référence, pas un engagement contractuel : les délais réels sont fixés dans la proposition, après la discovery, et dépendent du périmètre, des intégrations et de la rapidité des décisions.

1. Discovery : décider ce qu'on ne construit pas

La discovery part d'une question : quelle hypothèse ce MVP doit-il démontrer ? À partir de là, nous définissons avec vous l'utilisateur visé, le parcours critique (de la première connexion au moment où l'utilisateur obtient la valeur promise) et les indicateurs qui diront si l'hypothèse tient : combien terminent le parcours, combien reviennent, combien paient. Nous listons aussi les contraintes : données personnelles, paiements, intégrations obligatoires, échéances externes. Le résultat est un document de périmètre court, en trois colonnes : ce qui entre dans le MVP, ce qui reste dehors et ce qui viendra plus tard. C'est la phase où l'on économise le plus, car chaque fonctionnalité retirée ici est du travail que vous ne payez pas.

2. Architecture : simple aujourd'hui, extensible demain

Un MVP n'a pas besoin de microservices, de clusters et de dix environnements. Il a besoin d'une architecture simple qui n'oblige pas à tout réécrire quand arrivent les premiers clients. En général, cela signifie une application web responsive ou une PWA avant une app native, une seule application organisée en modules, une base de données relationnelle et des services externes éprouvés pour l'authentification, les paiements et les e-mails. Le stack de référence comprend PHP et Laravel, Node.js et TypeScript, React et Vue.js, MySQL. Les choix principaux sont consignés dans un court registre des décisions : ceux qui arriveront ensuite sauront pourquoi le système est fait ainsi.

3. Développement incrémental : une livraison par semaine

Le développement avance par livraisons hebdomadaires dans un environnement de test auquel vous avez accès. Chaque semaine, vous voyez le produit grandir, vous le testez et vous décidez avec nous des priorités de la semaine suivante. Le backlog est partagé et priorisé : si un retour change les priorités, on repousse quelque chose plutôt que d'allonger le projet. Pas de tunnel de deux mois avec une surprise à la fin.

4. Quality gate : ce que nous vérifions avant la mise en ligne

Avant le lancement, le produit passe une série de contrôles convenus au départ. Tests automatisés des parcours critiques, comme l'inscription, le paiement et l'action principale. Revue du code. Contrôles de sécurité de base sur l'authentification, les autorisations, les données personnelles et les sauvegardes. Performances sur smartphone. Événements analytiques déjà actifs, pour mesurer dès le premier jour les indicateurs décidés pendant la discovery. Journalisation des erreurs et supervision. Si un contrôle bloquant échoue, le lancement est décalé : c'est une règle que nous fixons ensemble avant d'écrire la première ligne.

5. Passation : le produit reste le vôtre

Un MVP que seul son auteur sait faire fonctionner est un risque pour votre entreprise. C'est pourquoi le code vit dans un dépôt à votre nom, les comptes d'infrastructure et des services externes vous appartiennent et la documentation explique comment démarrer le projet, comment le livrer et comment il est organisé. Nous terminons par une séance de passation avec votre équipe ou avec ceux qui suivront le produit. Ensuite, vous choisissez : continuer à le développer avec nous, intégrer une équipe interne ou poursuivre seul.

Que recevez-vous à la fin du développement du MVP ?

• Le produit en production, avec un domaine et une infrastructure à votre nom.
• Le code source dans votre dépôt, avec l'historique complet des modifications.
• Trois environnements séparés : développement, test et production.
• La documentation technique : démarrage en local, livraison, architecture et décisions prises.
• Le tableau de bord avec les indicateurs convenus pendant la discovery.
• Le compte rendu du quality gate, avec les contrôles réussis et les limites connues.
• Le backlog des fonctionnalités reportées, priorisé selon ce que vous avez appris des utilisateurs.

Un exemple de périmètre

Exemple illustratif, pas un cas client. Une startup veut vérifier si des guides locaux paieraient pour recevoir des réservations d'excursions sans commission. Le MVP comprend la fiche de l'excursion, le calendrier des disponibilités, la réservation avec paiement en ligne, la confirmation par e-mail et un tableau de bord essentiel pour le guide. Restent dehors l'app native, les avis, le chat et le programme de fidélité. Viendront plus tard, si les chiffres le justifient, les offres pour les groupes et l'intégration avec des canaux de vente externes. L'indicateur principal est unique : combien de guides, parmi ceux invités, reçoivent au moins une réservation payée le premier mois.

De quoi avons-nous besoin de votre part pour démarrer ?

Avant tout, d'une personne qui décide. Un MVP ralentit davantage à cause d'une décision repoussée qu'à cause d'un bug : nous demandons que le fondateur ou le responsable produit assiste aux démos hebdomadaires et réponde aux questions en quelques jours. Il nous faut ensuite l'accès à quelques utilisateurs pour les tests, les contenus et les textes du produit, et des comptes au nom de l'entreprise : domaine, services cloud, prestataire de paiement. Si vous avez déjà des maquettes, des études de marché ou une version précédente, apportez-les à la première rencontre : nous les utilisons, nous ne repartons pas de zéro.

Combien coûte le développement d'un MVP ?

Le coût d'un MVP dépend du périmètre convenu, c'est pourquoi nous ne publions pas de grille tarifaire valable pour tous. Pèsent surtout le nombre de types d'utilisateurs et de parcours, les intégrations avec des systèmes externes (paiements, logiciels de gestion, API tierces), la présence de composants d'intelligence artificielle, les exigences de sécurité et de conformité, les plateformes à couvrir et l'état du design, prêt ou à concevoir. S'y ajoutent les coûts récurrents d'hébergement, de services externes et d'éventuels modèles d'IA, qui augmentent avec l'usage et doivent être estimés dès le départ. Après le premier échange, vous recevez une proposition écrite avec phases, livrables et coûts, et vous pouvez commencer par la seule discovery avant de vous engager sur l'ensemble du développement.

Peut-on développer un MVP avec de l'intelligence artificielle ?

Oui, quand l'intelligence artificielle est la valeur du produit et non une étiquette. Un assistant qui répond sur les documents d'un secteur, un système qui extrait des données de factures ou de contrats, une recherche qui comprend le sens des questions : dans ces cas, l'IA doit être vérifiée tout de suite, car c'est l'hypothèse la plus risquée. Pendant la discovery, nous définissons comment mesurer la qualité des réponses et combien coûtera chaque utilisation des modèles. Si, au contraire, l'IA ne change pas l'expérience de l'utilisateur, nous la laissons hors de la première version. Pour les projets dont l'IA est le cœur, nous travaillons avec la même méthode que pour le développement d'intelligence artificielle pour les entreprises ; si le MVP est un outil interne qui doit relier e-mails, CRM et logiciels de gestion, consultez aussi les automatisations IA pour les processus d'entreprise.

Avec quelle expérience travaillons-nous ?

shardana.ai est né en 2026, mais le travail s'appuie sur plus de 25 ans d'expérience de son fondateur, Maurizio Brioschi, en ingénierie logicielle, développement backend, architecture de systèmes et direction d'équipes techniques. Dans les MVP, cette expérience sert surtout à choisir ce qu'il ne faut pas faire : quelle fonctionnalité reporter, quel service externe utiliser plutôt que de le réécrire, quel raccourci deviendra une dette difficile à rembourser. Nous ne publions pas de cas clients que nous ne pouvons pas documenter : lors du premier échange, nous entrons dans le détail des choix techniques pour votre idée.

Où travaillons-nous ?

Nous travaillons avec des startups et des PME dans toute l'Italie, en grande partie à distance : la discovery, les démos hebdomadaires et les livraisons fonctionnent bien en ligne. Le siège est à Cabras, dans la province d'Oristano, et pour les projets en Sardaigne il est possible d'organiser des rencontres en présentiel, à commencer par l'atelier de discovery.

Questions fréquentes

Combien de temps faut-il pour développer un MVP ?

Pour un MVP web de complexité moyenne, notre parcours type dure environ six semaines, de la discovery au lancement. C'est une référence, pas une garantie : des intégrations complexes, des apps natives ou des décisions lentes allongent les délais, tandis qu'un périmètre très resserré les raccourcit. Nous fixons les délais de votre projet dans la proposition, après la discovery.

Outil no-code ou développement sur mesure ?

Cela dépend de ce que vous devez vérifier. Les outils no-code conviennent pour valider une idée rapidement, quand la logique est simple et les volumes faibles. Le développement sur mesure se justifie quand le produit a sa propre logique, doit s'intégrer à d'autres systèmes ou doit grandir sans réécriture. Parfois, la bonne réponse est de commencer en no-code : dans ce cas, nous vous le disons.

Le code source m'appartient-il ?

Oui. Le code vit dans un dépôt au nom de votre entreprise et les droits sont réglés dans le contrat avant de commencer. Les comptes d'infrastructure et des services externes sont eux aussi à votre nom.

Pouvez-vous travailler avec notre équipe technique interne ?

Oui. Nous pouvons développer le MVP et le transmettre à votre équipe, ou travailler ensemble dès le départ, avec des revues de code partagées et des décisions d'architecture prises en commun.

Que se passe-t-il après le lancement ?

Nous analysons avec vous les indicateurs décidés pendant la discovery et priorisons le backlog selon ce que les utilisateurs font réellement. Vous pouvez poursuivre le développement avec nous, le confier à votre équipe ou vous arrêter, si les données montrent que l'hypothèse ne tient pas.

Développez-vous aussi des apps mobiles ?

Oui, mais pour un MVP nous partons presque toujours d'une application web responsive ou d'une PWA, installable depuis le navigateur : elle coûte moins cher et se met à jour sans passer par les stores. Nous passons aux apps natives quand il faut des fonctions du téléphone que le web n'offre pas. Vous trouverez les détails sur la page consacrée aux apps mobiles et PWA.

Services associés

• Développement d'intelligence artificielle pour les entreprises : logiciels d'IA sur mesure, des chatbots aux agents.
• Automatisations IA pour les processus d'entreprise : processus entre CRM, logiciels de gestion, e-mails et documents.
• Développement d'applications web sur mesure : quand il vous faut un logiciel de gestion ou un portail construit sur les processus d'une entreprise déjà en activité.
• Apps mobiles et PWA : quand votre MVP doit tenir dans le téléphone.
• À propos : le studio, la méthode et le fondateur.