Comment choisir la stack technique de son MVP

La question revient à chaque premier appel avec un fondateur : quelle technologie choisir pour un premier produit ? La réponse honnête est qu'à ce stade, le choix compte beaucoup moins que la vitesse à laquelle vous pouvez montrer quelque chose à un utilisateur.

Le seul critère qui compte vraiment

Un MVP a une seule fonction : répondre à une question de marché avant que l'argent s'épuise. Toute décision technique qui rallonge le délai sans réduire l'incertitude est une mauvaise décision, même si elle est techniquement supérieure.

Les trois pièges classiques

1. Construire pour une charge que vous n'avez pas. Optimiser pour un million d'utilisateurs quand vous en cherchez dix coûte des semaines et ne prouve rien.
2. Choisir une technologie parce qu'elle est nouvelle. Sur un MVP, la documentation et les réponses existantes valent mieux que l'élégance.
3. Repousser la mise en ligne jusqu'à ce que ce soit fini. Un produit devant douze utilisateurs réels apprend plus en une semaine que trois mois de développement à huis clos.

Ce qu'on utilise, et pourquoi

Nos MVP partent sur Next.js, une base de données gérée et un service de paiement existant. Ce n'est pas la stack la plus intéressante à discuter, c'est celle qui permet de mettre un produit en ligne en cinq semaines et de le reprendre proprement ensuite si le marché répond oui.

Le coût réel d'un changement de technologie

L'argument « on refera proprement plus tard » suppose qu'il existera un plus tard. Dans les faits, une réécriture complète coûte entre 60 et 100 % du développement initial, et se paie au pire moment : celui où le produit commence à trouver ses utilisateurs et où chaque semaine sans nouvelle fonctionnalité se voit.

La bonne question n'est donc pas « cette stack tiendra-t-elle à l'échelle ? » mais « laquelle me permet de changer d'avis vite ? ». Un socle ordinaire, largement documenté, se modifie par n'importe quel développeur. Une technologie de niche vous rend dépendant de la disponibilité des trois personnes qui la maîtrisent.

Les quatre questions à se poser avant de trancher

• Combien de développeurs savent s'en servir dans un rayon de recrutement réaliste ? Si la réponse est « peu », le risque n'est pas technique, il est humain.
• Existe-t-il une réponse à mes questions sur les forums publics ? Une technologie récente vous fait passer des heures sur des problèmes déjà résolus ailleurs.
• Puis-je héberger et déployer sans construire d'infrastructure ? Le temps passé à monter des serveurs est du temps qui n'apprend rien sur votre marché.
• Que se passe-t-il si j'ai besoin d'une fonctionnalité banale — authentification, paiement, envoi d'e-mails ? Si elle existe déjà et se branche, c'est une semaine gagnée par fonctionnalité.

Quand il faut vraiment réécrire

Il existe deux signaux légitimes. Le premier : les temps de réponse dégradent l'usage et les mesures montrent que le problème vient de l'architecture, pas d'une requête mal écrite. Le second : une contrainte réglementaire ou contractuelle impose un hébergement ou une certification que la stack actuelle ne permet pas.

Tout le reste — l'inconfort du développeur, la sortie d'un framework plus élégant, l'envie de repartir propre — n'est pas un motif de réécriture. C'est un motif de refactorisation progressive, qui se fait sans arrêter la livraison.

Ce que ça donne sur un projet de six semaines

Sur un MVP livré en quatre à six semaines, l'arbitrage technique occupe une demi-journée en semaine de cadrage. Pas davantage. Si le choix de la stack prend une semaine de discussion, c'est le signe que le périmètre fonctionnel n'est pas assez clair : on ne choisit pas un outil sans savoir précisément ce qu'on veut construire avec.