Construire le MVP : la boucle fonctionne de bout en bout

La technique de construction vient du cours de vibe coding (Lovable/Replit, iterations, rollbacks). Ici, nous abordons ce qui sépare un produit d'un projet amateur : l'ordre de construction et deux couches que les débutants oublient toujours.

Le squelette avant la beauté

Premier objectif : la boucle entière fonctionne de bout en bout, même maladroitement – inscription → faire l'action → obtenir le résultat. Ce n'est qu'alors que vous peaufinez les étapes individuelles. Pourquoi cet ordre : les problèmes les plus effrayants sont les jonctions (« l'étape 3 est impossible sans les données de l'étape 5 »), et ils n'apparaissent que lorsque la boucle fonctionne entièrement. Mieux vaut les détecter dès le premier jour que de découvrir, après une semaine à peaufiner la landing page, que le produit ne peut pas être complété du tout.

Cette règle est plus ancienne que le développement web. Lors de la création du premier Toy Story, Pixar a réalisé une version brute du film entier à partir de croquis – les « reels » – et ce n'est qu'une fois qu'ils ont été sûrs que l'histoire tenait de bout en bout qu'ils ont passé des mois à rendre les images. L'ensemble brut d'abord, les détails beaux ensuite. Les logiciels fonctionnent de la même manière.

Une pause socratique

Vous avez ouvert le produit pour la première fois. Que voyez-vous sur ce premier écran ? Pas une liste de tâches complète, pas un fil d'actualité rempli – le vide. Et c'est là que se décide si vous restez ou si vous fermez l'onglet. Réfléchissez : que doit contenir cet écran vide pour que vous sachiez quoi faire ?

Couche 1 : les états vides

Un nouvel utilisateur n'a aucune donnée : liste vide, historique vide. Un projet amateur montre un vide absolu ; un produit guide : « Rien ici pour l'instant. Téléchargez votre premier élément – voici le bouton. » Ce qu'il faut demander à l'IA : « Pour chaque liste et chaque écran, créez un état vide : ce que c'est, à quoi ça sert, et un bouton pour la première action ». Les premières impressions se jouent précisément ici – sur l'écran que les projets amateurs laissent vide.

Couche 2 : les erreurs compréhensibles

Mauvais fichier, le Wi-Fi a clignoté, le paiement a échoué. Un projet amateur ne dit rien, ou effraie les gens avec « Erreur 0x80070057 ». Un produit explique et offre une solution : « Ce fichier dépasse 100 Mo – compressez-le ou divisez-le. » La formule pour un bon message : ce qui s'est passé + ce qu'il faut faire. La demande : « Chaque erreur en langage clair : ce qui s'est passé et ce qu'il faut faire. Et montrez-moi une liste de tous les messages d'erreur » – cette dernière partie vous permet d'éditer tous les textes en une seule fois, avec une seule voix.

Mythes de débutants

• « Les erreurs sont des cas limites, je les écrirai plus tard. » Une personne sur trois rencontre une erreur lors de sa toute première visite : mauvais format, souris qui glisse, réseau instable. Ce n'est pas un cas limite, c'est le cœur de l'expérience.
• « C'est clair pour moi, donc c'est clair pour tout le monde. » Vous connaissez le produit de l'intérieur – vous êtes un testeur aveugle. Il doit être clair pour quelqu'un qui voit l'écran pour la première fois.
• « Je vais le rendre joli, puis vérifier la logique. » C'est l'inverse : la boucle fonctionnelle d'abord, la beauté ensuite. Un produit magnifique mais cassé est une image coûteuse.

Le test « entre les mains de quelqu'un d'autre »

Vous connaissez cette astuce des cours précédents – c'est maintenant une étape d'acceptation obligatoire. Quelqu'un de votre public cible parcourt la boucle devant vous, en silence, et vous ne donnez aucun indice, n'expliquez rien – vous observez simplement où il bute. Dans « Don't Make Me Think », Steve Krug a montré que 3 à 5 personnes réelles suffisent à trouver la plupart des problèmes ; vous n'avez pas besoin d'un laboratoire coûteux. Trois trébuchements = trois tâches pour demain. Continuez à peaufiner la boucle jusqu'à ce qu'une nouvelle personne la parcoure sans une seule question – c'est ce que signifie être prêt pour le MVP.

Où cela tourne mal : peaufiner la mauvaise chose

L'échec classique de la construction d'un MVP ressemble à ceci : le fondateur passe une semaine à perfectionner l'animation d'un bouton et le dégradé d'une landing page, et l'utilisateur test trébuche à l'entrée – il ne sait pas où cliquer après s'être inscrit. Peau polie, squelette brisé. La règle de l'ordre existe précisément pour cela : tant qu'une nouvelle personne ne peut pas parcourir la boucle de bout en bout, peaufiner un seul écran est prématuré. D'abord « fonctionne du début à la fin », puis « beau à chaque étape ». L'ordre inverse est la manière la plus coûteuse de passer une semaine.

Comment cela se connecte aux autres cours

Itérer, revenir à une version fonctionnelle et travailler avec un assistant IA sont des techniques du cours de vibe coding. Et les états vides et les erreurs compréhensibles que vous construisez ici augmentent directement la conversion vers la première valeur – une métrique de la leçon d'analyse de ce cours. Tout est lié : ce que vous construisez maintenant est ce que vous mesurerez plus tard.

Faites ceci maintenant (5 minutes)

Ouvrez votre brouillon de produit et trouvez le premier écran d'un nouvel utilisateur. L'état vide les mène-t-il à une première action, ou est-il simplement vide ? S'il est simplement vide, rédigez la demande à l'IA pour les états vides dès maintenant, avant d'oublier.