Comment construire un MVP qui fonctionne encore au neuvième mois

Pour construire un MVP qui fonctionne encore au neuvième mois, tranchez cinq points avant le premier écran : le modèle de données, les comptes et les rôles, les paiements, la région d’hébergement et le pipeline de livraison. Réduisez ensuite la première livraison à un utilisateur, une tâche et un parcours, mettez-la en production via un pipeline automatisé et consignez chaque décision importante au moment où vous la prenez. Tout le reste, des tableaux de bord d’administration aux microservices, peut attendre.

La raison, c’est le neuvième mois. À ce stade, vous avez de vrais utilisateurs, un deuxième ingénieur et une feuille de route, et chaque raccourci pris au premier mois dicte le rythme du dixième. Ce guide couvre les décisions coûteuses à défaire, le choix de qui développe, les bases du RGPD, un plan sur quatre semaines, le cadrage et la passation.

#Un MVP n’est pas un prototype

Eric Ries a défini le produit minimum viable comme la version d’un nouveau produit qui permet à une équipe de recueillir le maximum d’apprentissages validés sur ses clients avec le moins d’effort possible. Apprendre de vrais clients suppose de vrais comptes, de vraies données et, tôt ou tard, de l’argent réel.

Un prototype répond à la question « est-ce que cela pourrait marcher ? » et il est fait pour être jeté : une maquette cliquable, une démo pour un pitch, un script sur un ordinateur portable. Un MVP répond à la question « les gens vont-ils l’utiliser et payer pour cela ? », et ceux qui répondent y laissent leurs données. Cela, vous ne pouvez pas le jeter.

Les ennuis commencent quand un prototype passe en production sans que personne n’ait décidé de l’y faire passer. Écrans, règles métier et requêtes de base de données finissent dans les mêmes fichiers, la connexion et les paiements sont greffés tardivement, et les déploiements partent de la machine d’une seule personne. Rien ne semble anormal au deuxième mois. Au neuvième, chaque fonctionnalité coûte plus cher qu’elle ne le devrait.

Martin Fowler décrit ce surcoût comme les intérêts de la dette technique : l’effort supplémentaire nécessaire pour ajouter de nouvelles fonctionnalités à cause des défauts de qualité interne. Une part de dette est un échange équitable contre la vitesse. Le but d’une première version est de s’endetter délibérément, là où la dette est peu coûteuse à rembourser, et jamais dans les fondations.

#Cinq décisions à prendre la première semaine

La première semaine sert à décider sur le papier, pas à produire des écrans. Chacune de ces cinq décisions est peu coûteuse à bien prendre avant la première ligne de code produit, et coûteuse à changer une fois que des utilisateurs en dépendent.

1. Le modèle de données

Notez les entités centrales, leurs relations et à qui appartient chaque enregistrement. Pour la plupart des produits B2B, la question décisive est la multi-location : chaque organisation cliente dispose-t-elle de son propre espace, et chaque table concernée porte-t-elle une référence à l’organisation dès le premier jour ? Ajouter la multi-location après coup à un schéma mono-locataire touche chaque requête déjà écrite. Gérez le schéma par des migrations versionnées, jamais par des modifications manuelles de la base de production.

2. Comptes, rôles et permissions

Décidez comment les utilisateurs se connectent, comment ils sont rattachés aux organisations et quels rôles existent. Deux ou trois rôles suffisent pour commencer, mais ils doivent être vérifiés à un seul endroit, côté serveur, et non dispersés dans les écrans sous forme de conditions « if ». Utilisez un fournisseur ou une bibliothèque d’authentification éprouvés plutôt que de gérer vous-même les mots de passe, et laissez de la place pour l’authentification unique (SSO), car votre premier client grand compte la demandera.

3. Les paiements

Même si vous ne facturez rien au lancement, décidez qui paie (une personne ou une organisation), pour quoi (des licences par utilisateur, l’usage ou un forfait) et où vit l’état des abonnements. Utilisez le paiement hébergé ou intégré d’un prestataire de paiement afin que les données de carte ne touchent jamais vos serveurs. Stripe, par exemple, explique que ses intégrations à faible risque envoient les données de paiement directement à Stripe et réduisent vos obligations PCI DSS.

4. La région d’hébergement

Choisissez la région de votre base de données, de vos sauvegardes, de vos journaux et de votre stockage de fichiers, et vérifiez la région de chaque fournisseur qui traite des données personnelles. Pour un produit vendu en Allemagne, en Autriche et en Suisse, une région de l’UE est le choix par défaut raisonnable. Cela ne supprime pas vos obligations au titre du RGPD, mais cela retire la question des transferts internationaux de la plupart des questionnaires de sécurité que vos clients vous enverront.

5. Le pipeline de livraison

Dès le premier commit, chaque modification passe par le contrôle de version, des tests automatisés et un déploiement automatisé, d’abord en préproduction puis en production. Personne ne déploie depuis un ordinateur portable. Mettre en place un pipeline est fastidieux la première semaine et très difficile au neuvième mois, quand l’équipe a pris l’habitude de livrer à la main et que chaque livraison se fait en retenant son souffle.

Ce qu’il faut laisser de côté, volontairement

• Les microservices. Une seule application bien structurée, avec des couches internes claires (interface, règles métier, données), est plus facile à faire évoluer et à exploiter pour une petite équipe.
• Un back-office sur mesure. Utilisez un client de base de données ou un outil interne simple jusqu’à ce que le support montre ce dont les administrateurs ont réellement besoin.
• Des applications natives sur les deux plateformes, sauf si le produit a besoin des fonctions de l’appareil. Une application web responsive suffit souvent pour apprendre.
• Plus de langues que n’en demande votre premier marché, même s’il faut stocker textes, dates et devises de façon à pouvoir les ajouter plus tard.
• Une infrastructure maison, comme votre propre pile d’analytics, votre service de feature flags ou votre design system.
• Les cas limites de clients que vous n’avez pas encore.

#Quelles décisions sont coûteuses à défaire

Dans sa lettre aux actionnaires de 2015, Jeff Bezos distinguait les portes à sens unique et les portes à double sens : les décisions lourdes de conséquences, presque irréversibles, qui méritent du soin, et les décisions réversibles, qu’un petit groupe doit prendre rapidement. La plupart des décisions d’une start-up sont des portes à double sens. Tout l’art consiste à repérer les rares qui ne le sont pas, et à ne pas laisser les décisions réversibles engloutir la première semaine.

Regardez ce qui se trouve du côté coûteux : les données, l’identité, l’argent et l’endroit où ils résident. Ce sont les décisions à valider par écrit la première semaine. Le reste peut être tranché le jour même par la personne qui développe, puis changé quand vous en saurez davantage.

#No-code, agence, freelances ou équipe interne

La bonne façon de développer dépend moins du budget que de deux questions : qui possédera et comprendra le code au neuvième mois, et quelle part de votre produit est le logiciel lui-même. Si vous êtes fondateur et cherchez « App entwickeln lassen », posez ces deux questions à chaque prestataire avant de comparer les offres.

Quel que soit votre choix, le contrat doit préciser que le code, les dépôts, les comptes cloud et les noms de domaine appartiennent à votre entreprise dès le départ, et que la documentation est un livrable, pas une faveur.

#Les bases du RGPD à respecter dès le premier jour

Le RGPD exige la protection des données dès la conception et par défaut (article 25). Pour une première version, cela se résume à quatre points pratiques. Il s’agit d’informations générales : si vous traitez des données de santé, des données financières ou des données d’enfants, ou quoi que ce soit d’inhabituel, consultez un avocat spécialisé en protection des données avant le lancement.

Région d’hébergement et transferts internationaux

Le RGPD n’impose pas que les données restent dans l’UE. Il exige une base juridique au titre du chapitre V pour tout transfert hors de l’EEE, comme une décision d’adéquation ou des clauses contractuelles types. Pour les fournisseurs américains, le cadre de protection des données UE-États-Unis (Data Privacy Framework) couvre les transferts vers les entreprises certifiées dans ce cadre. Le Tribunal de l’Union européenne a confirmé ce cadre en septembre 2025, mais un pourvoi (affaire C-703/25 P) est pendant devant la Cour de justice. Conserver les données principales dans une région de l’UE et connaître la base de transfert de chaque fournisseur limite votre exposition, quelle que soit l’issue.

Un DPA avec chaque sous-traitant

Chaque fournisseur qui traite des données personnelles pour votre compte, de l’hébergement à l’envoi d’e-mails en passant par le suivi des erreurs, nécessite un contrat de traitement des données au titre de l’article 28. En Allemagne, on parle d’Auftragsverarbeitungsvertrag (AVV), et vos clients B2B vous en demanderont un aussi. Tenez une liste des fournisseurs avec les données que chacun reçoit, leur lieu de stockage et la date de signature du DPA. Cette liste est aussi le point de départ de votre registre des activités de traitement au titre de l’article 30, dont l’exemption pour les organisations de moins de 250 personnes ne s’applique plus dès que le traitement n’est pas occasionnel.

Le consentement, et quand vous n’en avez pas besoin

Beaucoup de premières versions recueillent des consentements inutiles et oublient ceux qui sont nécessaires. Les données dont vous avez besoin pour fournir le service prévu par votre contrat ne requièrent pas de consentement. Les cookies non essentiels et tout accès similaire à l’appareil d’un utilisateur, si : en Allemagne, le § 25 TDDDG exige un consentement, sauf si l’accès est strictement nécessaire à un service demandé par l’utilisateur. Lorsque vous vous appuyez sur le consentement, enregistrez ce qui a été accepté et quand, car l’article 7 vous oblige à le démontrer et impose que le retrait soit aussi simple que l’octroi.

Une suppression qui supprime vraiment

L’article 17 donne aux personnes un droit à l’effacement, et l’article 19 vous oblige à en informer les destinataires avec qui vous avez partagé leurs données. Concevez la suppression dès la première semaine : quels enregistrements sont supprimés, lesquels sont anonymisés ou conservés parce que la loi vous oblige à les garder (les factures, par exemple), comment la suppression atteint les sous-traitants et les sauvegardes, et qui peut la déclencher. Un indicateur de suppression logique dans la table des utilisateurs n’est pas un processus de suppression.

#Un plan semaine par semaine pour les quatre premières semaines

Ce plan suppose un produit au périmètre resserré et une petite équipe senior. Un périmètre plus large prend plus de temps, mais l’ordre reste le même : les décisions, puis le squelette, puis la première livraison.

Ensuite, livrez à un rythme fixe (une fois par semaine est un bon choix par défaut), avec une courte revue qui décide de ce qui part ensuite. Un rythme régulier compte davantage que la taille de chaque livraison.

#Comment cadrer la première livraison

Cadrez la première livraison autour d’un utilisateur, d’une tâche et d’un parcours. Formulez-la en une seule phrase : « Une responsable de clinique peut inviter son équipe et voir les réservations de la semaine au même endroit. » Tout ce qui ne sert pas cette phrase va sur la liste des coupes. Gardez cette liste, car elle devient votre feuille de route.

1. Nommez précisément le premier utilisateur : son rôle, le type d’entreprise et ce qu’il utilise aujourd’hui.
2. Listez les étapes de cette tâche, de la première visite au résultat, et supprimez chaque étape qui n’est pas essentielle.
3. Repérez les étapes qui touchent aux décisions coûteuses (données, rôles, argent). Construisez-les correctement ; le reste peut rester simple.
4. Choisissez un ou deux signaux qui vous diront que cela a fonctionné, comme l’activation ou une action répétée, et n’instrumentez que ceux-là.
5. Fixez une date et réduisez le périmètre pour la tenir, plutôt que de déplacer la date.

Une bonne première livraison paraît petite au fondateur et complète au premier utilisateur. Si votre liste d’indispensables remplit une page, vous décrivez la version trois.

#À quoi ressemble une vraie passation

Le test d’une passation est simple : un ingénieur qui n’était pas dans la pièce peut-il déployer, déboguer et faire évoluer le produit sans appeler la personne qui l’a construit ?

Les fiches de décision sont la partie la plus sous-estimée. Le format de fiche de décision d’architecture (architecture decision record) de Michael Nygard consigne chaque décision importante dans un court fichier, avec son contexte, la décision, son statut et ses conséquences. Au neuvième mois, quand le deuxième ingénieur demande pourquoi la multi-location fonctionne ainsi, la réponse se trouve dans le dépôt plutôt que dans la mémoire de quelqu’un.

Les comptes sont l’autre piège, et certains prennent du temps. Apple exige qu’une organisation s’inscrive en tant qu’entité juridique avec un numéro D-U-N-S, et Google Play ne crée pas de compte développeur d’organisation sans ce numéro ; la demande, gratuite, peut prendre jusqu’à 30 jours. Commencez tôt, au nom de l’entreprise, jamais à celui d’un freelance ou d’une agence.

#Comment nous pouvons vous aider

Bespoke IT développe des premières versions pour des start-up en Allemagne, en Autriche et en Suisse selon le calendrier décrit ici : l’architecture la première semaine, un produit fonctionnel la troisième et une passation que votre premier ingénieur recruté peut reprendre sans nous. Si vous préparez une première version, ou si vous en avez déjà une qui ressemble au neuvième mois, découvrez comment nous travaillons avec les start-up.