Du PRD au MVP testable : l'ordre à suivre quand vous n'êtes pas développeur

Pour passer d'un PRD à un MVP testable, vous n'avez besoin ni de TestFlight, ni d'un cofondateur technique. Vous avez besoin d'une web app mobile-first avec un lien partageable, d'une stack aussi banale que possible, et de trois chiffres à mesurer. Le PRD est devenu la partie facile. C'est le câblage qui bloque les fondateurs non techniques, et le câblage s'apprend.

Vous avez des user stories, des écrans, peut-être une maquette Figma. Et rien qui tourne. Voici l'ordre dans lequel on fait avancer les fondateurs qu'on accompagne.

1. TestFlight, pas maintenant

TestFlight sert à distribuer une application native en bêta. Le natif ajoute des semaines. Il faut un compte développeur Apple, un build Xcode, une review avant chaque distribution. Surtout, chaque correction se compte en jours au lieu de minutes.

Une web app mobile-first avec un lien partageable suffit pour répondre à la seule question qui compte à ce stade : est-ce qu'ils reviennent demain. Vous envoyez une URL, la personne ouvre, elle utilise. Vous corrigez et vous redéployez en dix minutes. Le natif viendra quand vous saurez quoi construire en natif.

2. Séparez vos deux tests

Un MVP mélange presque toujours deux questions distinctes, et ce mélange est la première raison pour laquelle les tests ne concluent rien.

Est-ce qu'ils comprennent se teste avec un prototype cliquable généré à l'IA (Claude, Lovable, Emergent, peu importe) et cinq personnes à qui vous demandez de raconter à voix haute ce qu'elles croient voir. Pas de base de données, pas d'authentification. Vous cherchez le moment où quelqu'un hésite sur un bouton.

Est-ce qu'ils reviennent se teste avec la plus petite chose réelle que vous puissiez mettre en ligne : une action par jour, une raison de revenir. Là il faut du vrai code, parce qu'il faut de la persistance. C'est un autre chantier, et le lancer avant d'avoir passé le premier test revient à construire sur une réponse que vous n'avez pas.

3. Prenez la stack la plus banale possible

React, Next, une base Mongo ou Postgres, un hébergeur qui déploie tout seul depuis votre dépôt Git. Pas parce que c'est élégant. Parce que c'est ce que Claude Code connaît le mieux.

Le raisonnement est mécanique. Un modèle génère du code d'autant plus fiable que le pattern est représenté dans ce qu'il a vu. Sur une stack ultra courante, Claude produit du code idiomatique. Les messages d'erreur que vous rencontrez ont déjà été résolus mille fois par d'autres. Sur une stack rare, vous passez vos soirées sur des erreurs que personne n'a jamais eues avant vous, avec un assistant qui invente des API plausibles qui n'existent pas.

Le choix de stack est la première décision d'architecture d'un projet, et c'est aussi la plus chère à défaire. C'est typiquement le genre de décision qui entre dans le registre du noyau extensible : une poignée de fichiers et de contrats dont tout le reste dépend, et qui ne se modifient pas sans qu'un ingénieur senior regarde.

4. Pas de capteurs, pas d'intégrations en v1

Les capteurs, les connexions bancaires, les webhooks d'un outil tiers : tout ça arrive dans le PRD parce que c'est la version aboutie du produit dans votre tête. En v1 ils font autre chose. Ils ajoutent des modes de panne que vous ne savez pas encore diagnostiquer, et ils vous empêchent de savoir si l'échec vient de votre idée ou de l'API d'en face.

La règle est courte : si votre boucle marche en saisie manuelle, elle marche. Si elle ne marche pas en saisie manuelle, les capteurs ne l'auraient pas sauvée. L'automatisation rend une boucle qui fonctionne plus confortable. Elle ne crée jamais la boucle.

5. Mesurez trois choses, pas trente

Inscrit. A fait l'action. Revenu le lendemain sans relance.

La troisième est tout le test. Les deux premières se truquent facilement, souvent sans le vouloir : vous avez partagé le lien à des gens qui vous aiment bien, ils ont signé, ils ont cliqué une fois pour vous faire plaisir. Un retour le lendemain sans notification ni message de votre part, c'est le seul signal qui ne vient pas de votre réseau.

Trois compteurs suffisent, et ils tiennent dans une requête. Installer un outil d'analytics complet à ce stade vous donnera trente courbes et aucune décision.

Ce qui bloque vraiment

Les fondateurs non techniques bloquent rarement sur l'idée. Ils bloquent sur le câblage : quelle stack, quoi déployer en premier, quoi ignorer, comment savoir si le résultat compte. Ce sont des décisions de séquence, pas de génie technique, et elles s'apprennent en les prenant une fois avec quelqu'un qui les a déjà prises.

C'est la logique de notre façon de travailler. Vous restez au clavier avec Claude Code. Un ingénieur senior relit chaque PR sous vingt-quatre heures ouvrées, et celles qui touchent au noyau passent en plus sous les yeux d'un architecte. Vous planifiez trois à cinq items en début de semaine, on en parle une heure en milieu de semaine, le reste tourne en async. Vous shippez vite sans éroder la fondation pendant que vous apprenez.

---

Vous construisez déjà votre produit avec l'IA ? Le Bunker Test est notre audit gratuit : vous nous donnez un accès en lecture, nous revenons sous cinq jours ouvrés avec un score de solidité et de structure sur 100. Vous repartez avec vos trois risques principaux et un correctif à shipper le jour même. Sans engagement, et le rapport vous reste.

Demander votre Bunker Test gratuit →