Prototype dessiné ou prototype codé : lequel d'abord ?

Commencez par un prototype dessiné si vous voulez savoir si l'idée et le parcours sont compris. Passez à un prototype codé quand la question porte sur ce qui doit vraiment fonctionner : des données réelles, des calculs, des connexions à d'autres services. Les deux ne testent pas la même chose, et le plus utile est souvent de les enchaîner.

Un avertissement d'abord. Les outils de dessin d'écrans comme ceux qui génèrent du code évoluent vite, et la frontière entre les deux se brouille : certains outils transforment un dessin en application. Cet article parle de démarches, pas d'outils précis ; vérifiez l'état actuel de ce que vous comptez utiliser.

L'analogie : le plan de l'architecte et la maison témoin

Avant de bâtir, un architecte montre des plans et des images. On y juge l'agencement, les volumes, ce qu'on ressentira en y vivant. Cela coûte peu et on change facilement d'avis. Une maison témoin, elle, est construite en vrai : on y vérifie que les portes ferment, que l'eau coule, que l'escalier est praticable. C'est plus long et plus cher, mais on y apprend ce qu'un plan ne dit pas.

Le prototype dessiné

Ce sont des écrans (parfois cliquables) qui montrent à quoi le produit ressemblera et comment on circule d'un écran à l'autre. Rien ne fonctionne vraiment derrière : les chiffres affichés sont fictifs.

Il apprend :

• si les gens comprennent le produit et le parcours ;
• où ils hésitent ou se perdent ;
• si l'idée mérite d'être poursuivie, avant d'investir.

Il n'apprend pas :

• si le produit tient avec de vraies données ou beaucoup d'utilisateurs ;
• si la technique est faisable, rapide, sûre ;
• si les connexions à des services extérieurs se passent bien.

Le prototype codé

C'est une version réduite qui fonctionne réellement : elle enregistre, calcule, se connecte. Elle peut être jetable ou servir de base à la suite.

Il apprend :

• si l'idée est réalisable, et ce que cela coûte à tenir ;
• comment le produit se comporte avec de vraies données ;
• ce qui est plus difficile que prévu.

Il demande : plus de temps, et le risque de s'attacher à des choix techniques faits trop tôt. Si un prototype codé vite devient le produit sans relecture, on retrouve les questions de Lovable, Bolt, Cursor : ce qui change quand l'IA écrit le code.

Pour décider : les questions à vous poser

• Ma plus grande incertitude porte-t-elle sur la compréhension ou sur la faisabilité ? Compréhension : dessinez. Faisabilité : codez.
• Combien de personnes dois-je convaincre, et avec quoi ? Pour présenter une idée à un partenaire ou un premier utilisateur, des écrans suffisent souvent.
• Mon produit repose-t-il sur un calcul, une donnée ou une connexion particulière ? Si oui, cela vaut le coup de la tester tôt, en code.
• Puis-je me permettre de jeter ce que je construis ? Un prototype dessiné se jette sans regret ; un prototype codé demande de décider à l'avance s'il sert de base ou non.
• Ai-je vérifié ce que les outils actuels permettent ? Ils changent vite, et ce qui demandait des jours peut en demander moins aujourd'hui.

Un enchaînement fréquent

1. Dessiner le parcours principal et le montrer à quelques personnes concernées.
2. Corriger, jusqu'à ce que le parcours soit compris.
3. Coder la partie dont la faisabilité est incertaine.
4. Décider du premier périmètre à livrer : voir Qu'est-ce qu'un MVP et Cadrer un produit avant de le développer.

À retenir

Le prototype dessiné teste si l'on comprend le produit, le prototype codé teste s'il fonctionne. Commencez par ce qui correspond à votre plus grande incertitude, sans oublier que l'un n'exclut pas l'autre.

Et pour votre produit ?

Si vous avez une idée et hésitez sur la façon de la tester, on peut regarder ensemble ce qu'il vous faut apprendre en premier, puis choisir la forme de prototype adaptée. C'est une étape habituelle d'une création de produit. Nous pouvons en discuter lors d'un échange de 30 minutes.