Prototype d'application ou MVP : que faut-il créer en premier ?

Quatre livrables, quatre questions

Un projet ne passe pas obligatoirement par toutes les cases. Un formulaire interne simple peut évoluer rapidement vers une première version sans code complexe. Une application dépendante d'un dispositif médical aura au contraire besoin d'une preuve technique avant un design complet.

Choisir le prototype pour une question de parcours

Le prototype est adapté lorsque les incertitudes concernent navigation, vocabulaire, ordre des tâches ou compréhension de l'offre. Il représente inscription, recherche, réservation ou paiement sans connecter tous les services. Figma permet de relier des écrans à partir de points de départ ; son guide des flux de prototype montre cette construction.

Faites tester une tâche sans guider la personne. Un responsable de centre de formation peut créer un cours et ajouter un participant. Un client peut trouver un praticien, choisir un créneau puis déplacer le rendez-vous. Regardez les hésitations et les interprétations, pas seulement les commentaires positifs.

Le prototype mesure surtout la compréhension. Il prouve moins bien l'intention de payer, car chacun sait que le service est simulé. Le livrable doit contenir tâches, profils testés, observations, décisions et questions non résolues, en plus de la maquette.

Isoler la faisabilité dans une preuve technique

Une preuve de concept technique se concentre sur un risque : reconnaissance vocale dans un lieu bruyant, synchronisation hors ligne, connexion à un objet, latence vidéo ou coût d'un modèle d'IA. Ajouter tous les rôles et tout le design empêcherait de mesurer clairement cette hypothèse.

Écrivez le critère de réussite avant le développement. « Essayer l'IA » ne mène à aucune décision. Il vaut mieux demander la transcription de deux minutes sur trois appareils ciblés avec un délai maximal, sans transfert de données sensibles vers un service non approuvé. Notez appareils, données de test, vitesse, coût et échecs.

Une partie du code pourra éventuellement être reprise. Ce n'est pas la priorité. Un code d'exploration ignore souvent les tests, la sécurité et les erreurs rares. Il reste une preuve tant qu'une revue n'a pas établi ce qui convient à la production.

Utiliser un pilote manuel pour tester le service

Dans un pilote dit « concierge », de vrais clients obtiennent le résultat tandis que l'équipe réalise manuellement certaines opérations. Un service de livraison peut recevoir des commandes dans un formulaire, affecter les coursiers dans un tableau puis envoyer les statuts par message. Une plateforme de soins peut organiser les rendez-vous avant de développer un moteur d'attribution.

Cette approche révèle demande, prix, qualité et exceptions. Les participants doivent savoir ce qui est manuel, et leurs données restent à protéger. Mesurez chaque tâche cachée et le temps nécessaire : ce relevé devient le premier plan d'automatisation.

Le test est trompeur si les clients apprécient uniquement l'attention personnelle du fondateur ou si personne ne calcule le coût des opérations. Le service provisoire doit être assez proche de la promesse future pour fournir des résultats utiles.

Le MVP est déjà un vrai produit

Le MVP livre un résultat essentiel de bout en bout, plusieurs fois, à de vrais utilisateurs. Il peut se limiter à une ville, un moyen de paiement ou quelques rôles. Il lui faut néanmoins authentification de production, traitement adapté des données, erreurs, suivi, assistance, comptes maîtrisés et processus de publication reproductible.

Le guide de spécification d'un MVP de Y Combinator conseille de sélectionner les parcours indispensables et de repousser le secondaire. « Minimum » qualifie le périmètre, pas le sérieux. Une application médicale peut avoir peu de fonctions, mais pas négliger la confidentialité. Un commerce peut proposer peu d'articles, mais pas perdre une commande payée. Notre guide de préparation d'un MVP mobile aide à préserver le résultat principal.

Le MVP produit des preuves impossibles à obtenir dans une maquette : activation, retour, résiliation, incidents, assistance et transactions. Ces preuves nécessitent toute l'infrastructure qui entoure les écrans.

Ce qu'un prototype IA de deux semaines peut montrer

Avec l'IA générative, un périmètre étroit et une supervision expérimentée, deux semaines peuvent suffire pour une démonstration convaincante. Les intégrations simples ou simulées permettent de tester un parcours et de révéler les oublis du cahier des charges. Notre article sur le développement d'applications avec l'IA en présente les compromis.

Cette vitesse ne crée pas la fiabilité. Le code produit peut mélanger les approches, exposer des secrets, dépendre de bibliothèques mal évaluées ou ne fonctionner que dans le cas préparé. Avant de recevoir des clients, contrôlez connexion, droits, flux de données, erreurs, licences, journalisation, déploiement et propriété.

Une application installable sur un téléphone reste un prototype si personne ne sait encore la surveiller, la corriger et en assumer les données.

Faut-il réutiliser le code du prototype ?

Un prototype de design transmet surtout parcours, textes et éléments visuels. Une preuve technique peut fournir un algorithme ou une intégration confirmés. Un pilote construit avec du low-code ou l'IA peut fournir davantage si la plateforme garantit export, droits, performances, intégrations et propriété durable.

Décidez après les tests. Examinez architecture, licences, schéma de données, automatisation, sécurité et publication. Réécrire est raisonnable si la structure provisoire rend chaque ajout dangereux. Conserver l'est si le code respecte déjà les contraintes et si l'équipe sait l'exploiter.

Promettre que tout sera réutilisé déforme l'objectif. Le prototype doit produire du savoir. Jeter un code fragile tout en gardant le bon parcours reste une réussite.

La séquence de décision

1. Nommez l'hypothèse qui pourrait arrêter le projet.
2. Si le parcours est mal compris, testez un prototype cliquable.
3. Si une technologie peut échouer, mesurez une preuve technique limitée.
4. Si demande, prix ou organisation sont inconnus, rendez le service manuellement à un petit groupe.
5. Lorsque parcours, technique et service sont compris, définissez le plus petit MVP exploitable.
6. Fixez avant le test les critères pour continuer, modifier ou arrêter.

Pour une idée encore jeune, utilisez les méthodes de notre guide de validation d'une idée d'application. Lorsque la direction est claire, le modèle de spécification technique formalise rôles, états, intégrations et critères d'acceptation.

Préparer une demande d'estimation claire

Une agence estime mieux si elle connaît la question ouverte. Décrivez utilisateur principal, résultat, parcours critique, risque technique, intégrations, sensibilité des données et éléments déjà produits. Précisez si vous cherchez un outil jetable pour apprendre ou une version à maintenir.

Appfyl recommande un prototype lorsque le parcours évolue encore, une preuve technique quand une intégration conditionne le produit, et un MVP lorsque le noyau est compris. Notre guide sur le délai de développement d'une application mobile distingue prototype rapide avec IA, première version low-code et réalisation personnalisée plus large.

Le brief d'estimation Appfyl vous permet de décrire type de produit, état du design, rôles, paiements, administration et intégrations. L'incertitude à résoudre est plus informative qu'une liste de toutes les fonctions imaginables.

Questions fréquentes