Maquette, prototype ou MVP : de quoi as-tu besoin ?

1. La maquette : décider de ce que l’on voit

Une maquette présente les écrans : contenu, hiérarchie, couleurs et placement des actions. Elle aide à discuter de ce qui doit apparaître et à repérer une information manquante. Une belle suite d’écrans ne démontre pas encore que la navigation sera comprise ou que les fonctions marcheront.

Figma permet de concevoir ces écrans et d’aller ensuite vers le prototypage. La documentation de Figma sur la conception d’une application explique notamment le rôle des parcours et des essais d’interactions. Le point utile pour ton projet : préciser si tu attends seulement des écrans ou aussi des liens qui permettent de les parcourir.

Une maquette est adaptée quand la question principale porte sur le contenu ou l’interface. Elle ne prouve ni l’existence d’un serveur, ni l’enregistrement de données, ni la publication sur un store.

2. Le prototype cliquable : essayer un parcours

Un prototype relie des écrans pour simuler une suite d’actions. Tu peux demander à une personne de trouver une information ou de terminer un parcours, puis observer où elle hésite. L’objectif est de voir si elle comprend ce qu’il faut faire, avant de construire toutes les fonctions.

Prépare une tâche précise et évite de guider la personne pendant l’essai. Note ses hésitations et ce qu’elle pense avoir obtenu. Une scène simulée doit être identifiée : si un paiement ou une réponse d’IA est illustré, cela ne prouve pas qu’il fonctionne réellement.

Un prototype n’a pas besoin d’être publié sur l’App Store pour servir à une discussion. Mais une interaction dans une maquette ne remplace pas les tests d’une application avec ses données, ses accès et ses erreurs.

3. Le MVP : faire fonctionner l’essentiel

Un MVP est une première version utilisable, volontairement limitée à l’essentiel. Il sert à observer un usage réel sur un périmètre défini. Il peut encore manquer de fonctions secondaires ; le parcours retenu doit cependant fonctionner avec les données et les services réellement prévus.

Choisis une action principale, les conditions dans lesquelles elle doit marcher et les observations qui permettront de décider de la suite. Un téléchargement ne prouve pas à lui seul que le produit répond au besoin. Regarde ce que les personnes arrivent à faire et ce qui les empêche de revenir.

Pour une application destinée au public, « première version » ne dispense pas de traiter les droits d’accès, les erreurs, les données et les vérifications nécessaires. Les règles du store s’appliquent aussi à un périmètre réduit.

4. Choisir selon la question encore ouverte

• « Est-ce que le contenu et l’interface sont clairs ? » Commence par des maquettes et des retours sur les écrans.
• « Est-ce que les gens comprennent comment réussir cette tâche ? » Prépare un prototype du parcours et fais-le essayer sans expliquer chaque geste.
• « Est-ce que cette fonction peut marcher avec ce service ou cet appareil ? » Prévois une vérification technique ciblée ; une simulation visuelle ne suffit pas.
• « Est-ce que les gens utilisent réellement cette solution ? » Définis la plus petite version fonctionnelle qui permet d’observer cet usage.

Il n’est pas obligatoire de commander quatre projets séparés. Le bon choix dépend de ce qui est déjà connu. Note ce que chaque livrable doit permettre de décider, ce qu’il ne prouve pas et la condition pour passer à la suite.

5. Regarder le travail derrière les écrans

Dans les réalisations de Yodavio, les visuels et le statut du projet sont présentés séparément. BOOXS montre notamment son univers et une application publiée. Talkana présente le design et la construction d’une application testée sur TestFlight, puis publiée sur l’App Store. Ces exemples ne sont pas des simulations de missions clients : le rôle du studio est précisé dans chaque étude.

Demande toujours ce qui est montré : écran dessiné, parcours simulé, version testable ou application publiée. Un même visuel de téléphone peut illustrer plusieurs états du travail ; il ne suffit pas à prouver une livraison complète.

Chez Yodavio, le parcours présenté part du brief et de la liste d’écrans, passe par Figma, puis la construction et la soumission à Apple. Tu peux consulter notre méthode de développement en 4 étapes et les postes à clarifier pour ton budget.

6. Préparer la prochaine étape

Avant le premier échange, écris la question à vérifier, le public qui doit essayer, le parcours concerné et les éléments déjà disponibles. Ajoute tes contraintes de budget et de date. Tu obtiendras une discussion plus utile qu’avec la seule demande « fais-moi un MVP ».

Notre guide de cahier des charges et son modèle de brief t’aide à rassembler ces informations. Tu peux venir avec une idée encore incomplète : le premier travail consiste à préciser ce qu’il faut construire et pourquoi.