La Minute Builder #12 — Voici les 5 erreurs qui empêchent un MVP de devenir un vrai produit

Pourquoi certains MVP évoluent pendant dix ans… tandis que d'autres doivent être entièrement réécrits quelques mois après leur lancement ?

Créer un MVP rapidement est devenu plus simple que jamais.

Avec l'IA, les outils de no-code et le vibe coding, il est aujourd'hui possible de mettre en ligne un produit en quelques jours.

Mais construire vite ne garantit pas de pouvoir évoluer vite.

Ce n'est pas la vitesse de développement qui pose problème.

C'est l'architecture choisie au départ.

Cette phrase paraît logique.

Pourtant, c'est souvent à ce moment-là que naît la plus grosse dette d'un produit.

Non pas la dette technique.

La dette d'architecture.

Contrairement à quelques bugs ou à du code imparfait, une mauvaise architecture ralentit progressivement toute l'équipe.

Chaque nouvelle fonctionnalité devient plus coûteuse.

Chaque évolution devient plus risquée.

Chaque nouveau développeur met plus de temps à comprendre le projet.

Voici les cinq erreurs que je rencontre le plus souvent.

1. Tout coder directement dans les écrans

Lorsqu'on développe rapidement un MVP, il est tentant de construire directement les interfaces — boutons, icônes, formulaires — écran par écran.

Le piège : on ne réutilise pas vraiment une classe CSS. On recopie tout le markup, y compris les icônes, dans chaque vue.

Par exemple :

<!-- Login.vue — tout est codé dans l'écran -->

<button class="btn-primary flex items-center gap-2">
  <svg width="16" height="16"><!-- icône cadenas copiée --></svg>
  Se connecter
</button>

Puis quelques jours plus tard :

<!-- Checkout.vue — même pattern, recopié à la main -->

<button class="btn-primary flex items-center gap-2 px-5">
  <svg width="16" height="16"><!-- icône carte copiée --></svg>
  Payer
</button>

Puis :

<!-- Profile.vue — encore une variante légèrement différente -->

<button class="btn-primary flex gap-2">
  <svg width="14" height="14"><!-- même icône, autre taille --></svg>
  Modifier
</button>

Au début, cela fonctionne parfaitement.

Puis un designer modifie la couleur du bouton, l'espacement, ou remplace une icône.

Il faut alors modifier chaque écran individuellement — bouton par bouton, icône par icône.

Même une icône devrait être un composant, pas un SVG recollé dans douze fichiers.

Quelques semaines plus tard, certains boutons n'ont déjà plus le même comportement.

Le produit devient incohérent.

Une meilleure approche : le Design System

Un Design System consiste à extraire ces patterns en composants génériques — boutons, icônes, champs — réutilisés partout.

Par exemple :

<Button variant="primary" icon="lock">
  Se connecter
</Button>

Puis :

<Button variant="primary" icon="credit-card">
  Payer
</Button>

Sous le capot, `<Icon />` centralise taille, couleur et style. `<Button />` gère les variantes et les états.

Le composant reste unique.

Le design reste cohérent.

Et lorsqu'il évolue, toute l'application évolue avec lui.

2. Copier les composants au lieu de penser Atomic Design

Une erreur très fréquente consiste à dupliquer un composant existant.

On finit rapidement avec :

Button.vue

ButtonPrimary.vue

ButtonFinal.vue

ButtonNew.vue

ButtonFinalV2.vue

Chaque composant contient ensuite ses propres corrections.

Ses propres bugs.

Ses propres styles.

La maintenance devient rapidement impossible.

L'approche Atomic Design

L'Atomic Design, imaginé par Brad Frost, propose de construire une interface comme des briques Lego.

Atoms

Les plus petits composants.

• Button
• Input
• Avatar
• Label
• Icon

Molecules

Assemblage de plusieurs Atoms.

• SearchBar
• LoginForm
• CardHeader

Organisms

Des blocs complets de l'interface.

• Navbar
• Sidebar
• CheckoutForm

Templates

Organisation générale d'une page.

Pages

Les pages finales de l'application.

Cette approche présente un énorme avantage.

Chaque composant est créé une seule fois.

Puis réutilisé des dizaines, voire des centaines de fois.

Le développement devient plus rapide.

La maintenance aussi.

3. Concevoir un modèle de données uniquement pour aujourd'hui

Lorsqu'on développe un MVP, on pense souvent au besoin immédiat.

Imaginons un produit destiné à organiser des événements.

On pourrait créer simplement :

User

Event

Tout fonctionne.

Puis arrivent de nouveaux besoins :

• plusieurs organisateurs
• plusieurs équipes
• plusieurs rôles
• plusieurs abonnements
• plusieurs entreprises

Le modèle initial ne suffit plus.

On ajoute alors des colonnes.

Puis des exceptions.

Puis des contournements.

Quelques mois plus tard, personne ne comprend vraiment la base de données.

Une meilleure approche

Avant de créer une table ou une collection, je me pose toujours cette question.

Sans tout développer aujourd'hui, il est possible de prévoir une architecture capable d'évoluer.

Par exemple :

Organization

Membership

User

Role

Subscription

Même si certaines tables restent presque vides au départ.

Le produit pourra évoluer naturellement.

Sans devoir tout reconstruire.

4. Organiser le backend par domaines métier

C'est probablement le point qui change le plus la maintenabilité d'un projet.

Beaucoup de MVP commencent ainsi :

src/

controllers/

services/

models/

utils/

helpers/

middlewares/

Cette architecture paraît simple.

Puis le projet grandit.

Les services commencent à dépendre les uns des autres.

Les imports deviennent difficiles à suivre.

Personne ne sait vraiment où créer une nouvelle fonctionnalité.

Le monolithe modulaire

Aujourd'hui, de nombreuses équipes utilisent un monolithe modulaire.

L'idée est simple.

Le projet reste une seule application.

Mais chaque domaine métier est complètement isolé — avec sa propre structure interne.

src/
  Auth/
  Users/
  Payments/
  Subscriptions/
  Events/
  Notifications/

Chaque domaine contient sa propre logique, du contrôleur au test :

Auth/
  controllers/       → auth.controller.ts
  services/          → auth.service.ts
  repositories/      → auth.repository.ts
  dto/
  entities/
  tests/

Users/, Payments/, Subscriptions/… reprennent la même organisation. On ne cherche plus un `payments.service.ts` perdu dans un dossier global `services/` qui mélange tout.

Cette approche est utilisée dans de nombreux projets NestJS.

Elle permet :

• de mieux répartir les responsabilités
• de limiter les dépendances entre domaines
• de faciliter les tests
• de préparer une éventuelle séparation en microservices si le produit grandit

Le monolithe modulaire offre souvent un excellent compromis entre simplicité et évolutivité pour un MVP.

5. Considérer le MVP comme du code jetable

C'est probablement l'idée la plus dangereuse.

Dans la réalité, cela arrive rarement.

Pourquoi ?

Parce que lorsque le MVP fonctionne… les clients arrivent.

Puis :

• les demandes de nouvelles fonctionnalités
• les corrections de bugs
• le support utilisateur
• les investisseurs
• les recrutements

Personne ne souhaite interrompre plusieurs mois de développement pour repartir de zéro.

Le MVP devient naturellement V1.

Puis V2.

Puis V3.

L'architecture choisie au début accompagnera souvent l'équipe pendant plusieurs années.

Dette technique ou dette d'architecture ?

On confond souvent ces deux notions.

La dette technique concerne principalement la qualité du code.

Elle peut généralement être remboursée progressivement :

• améliorer un composant
• supprimer du code mort
• ajouter des tests
• simplifier une fonction

La dette d'architecture est différente.

Elle concerne les fondations du produit.

Une mauvaise séparation des responsabilités, un modèle de données mal pensé ou une architecture trop couplée deviennent extrêmement coûteux à corriger.

C'est souvent cette dette qui oblige certaines entreprises à réécrire entièrement leur logiciel.

Ce qu'il faut retenir

Un MVP n'a pas besoin d'être parfait.

Il n'a pas besoin d'intégrer tous les Design Patterns existants.

Il n'a pas besoin d'anticiper tous les besoins futurs.

En revanche, il doit être pensé pour évoluer.

Construire vite ne signifie pas construire provisoirement.

Un MVP n'est pas un prototype.

C'est la première version d'un produit qui a vocation à grandir.

La dette technique peut souvent être remboursée.

La dette d'architecture, elle, accompagne parfois un produit pendant des années.

Le plus grand risque d'un MVP n'est donc pas qu'il échoue.

C'est qu'il fonctionne.

Les meilleurs produits ont commencé comme des MVP

Instagram était un MVP.

Airbnb était un MVP.

Spotify était un MVP.

Ils n'étaient pas parfaits.

Mais leurs équipes avaient posé des fondations suffisamment solides pour faire évoluer leur produit au fil des années, sans repartir systématiquement de zéro.

La qualité d'un MVP ne se mesure donc pas uniquement à sa vitesse de développement.

Elle se mesure aussi à sa capacité à accompagner les prochaines versions du produit.