Prototype, MVP ou preuve de concept

Partir de la décision plutôt que du nom de l’artefact

Demandez quelle incertitude bloque la prochaine décision responsable. Si l’équipe ne s’accorde pas sur le parcours, elle peut avoir besoin d’un prototype. Si le produit dépend d’une API, d’un calcul ou d’une interaction matérielle incertaine, une preuve de concept peut convenir. Si problème, parcours et responsabilité opérationnelle sont assez compris et qu’une preuve d’usage réel devient nécessaire, le MVP est plus adapté. La question choisit l’artefact, pas son prestige apparent.

Écrivez la décision en une phrase. Nommez qui utilisera ou inspectera l’artefact, où il fonctionnera, quelles données il pourra toucher et quel résultat modifierait le plan. Ajoutez ce que le résultat ne pourra pas démontrer. Cette discipline empêche une démonstration de devenir un engagement de production involontaire et évite de présenter une réussite technique étroite comme validation d’un modèle économique complet.

Employer le prototype pour comprendre l’expérience

Un prototype peut être un croquis ou un parcours interactif réaliste. Il rend une idée inspectable, facilite la discussion et teste la manière dont des personnes comprennent une expérience proposée. La fidélité doit correspondre à la question. Un support sommaire peut mieux convenir pour comparer une structure d’information, tandis qu’une interaction réaliste peut être nécessaire pour observer une tâche complexe. Il faut accepter de le modifier ou de le jeter.

Protégez sa frontière. Étiquetez clairement le prototype, limitez son accès lorsqu’une confusion ou un contexte sensible est possible et n’utilisez ni identifiants actifs ni données de production. Le code peut omettre sécurité, performance, récupération et maintenabilité nécessaires à un service public. Le GOV.UK distingue explicitement ses outils de prototypage des services réels. Réutiliser ce code constitue une nouvelle décision d’ingénierie et demande une revue.

Employer la preuve de concept pour isoler la faisabilité

Une preuve de concept teste une affirmation technique étroite: une intégration échange-t-elle les données nécessaires, un calcul respecte-t-il une contrainte, ou une architecture supporte-t-elle un échec important ? Définissez entrée, environnement, condition de réussite et exclusions. La portée doit permettre de comprendre clairement une réussite et de tirer un apprentissage d’un échec. Elle ne doit pas devenir silencieusement une base produit entière.

Une preuve de concept n’établit ni désirabilité, ni utilisabilité du parcours complet, ni sécurité d’exploitation. Elle peut employer des données synthétiques, une infrastructure temporaire ou des permissions simplifiées. Enregistrez ces différences. Si du code continue, réévaluez dépendances, secrets, données, erreurs, licences, performance et propriété comme pour un nouvel apport. La faisabilité technique est une couche de preuve, pas une autorisation de mise en production.

Employer le MVP pour un parcours réel complet et borné

Un MVP doit préserver un résultat significatif de bout en bout pour l’utilisateur visé. Il peut contenir peu de fonctions, mais le parcours choisi doit être assez cohérent pour produire une preuve interprétable. Définissez qui y accède, quel support existe, ce qui est mesuré et quelle décision utilisera ces observations. Réduire jusqu’à obtenir des écrans incapables de terminer la tâche rend le MVP moins utile, même si le code est plus petit.

Parce qu’il est publié plutôt que simplement démontré, le MVP peut exiger authentification, autorisation, confidentialité, accessibilité, gestion des erreurs, supervision et récupération. Minimal ne signifie pas exempt de contrôles importants. Un déploiement réussi prouve une livraison dans un environnement à un moment donné. Il ne prouve pas à lui seul utilisation régulière, satisfaction, revenus ou marché durable.

Enchaîner seulement les artefacts qui réduisent une incertitude

Il n’existe aucune obligation de construire les trois dans un ordre fixe. Une équipe peut passer d’un prototype papier au MVP lorsque la faisabilité est connue, ou tester une dépendance avant de détailler l’interface si elle peut invalider l’idée. Elle peut aussi arrêter lorsqu’une preuve montre que le problème est faible ou que l’exploitation n’est pas justifiée. Sauter un artefact inutile est discipliné si la décision est documentée.

À chaque transition, notez apprentissages, hypothèses restantes, code ou données réutilisables et personne autorisant le niveau d’exposition suivant. La méthodologie IVRYN sépare implémentation, livraison publique et résultats externes. Appliquez cette séparation. Prototype, preuve de concept et MVP sont utiles lorsqu’ils portent une affirmation bornée et une décision nommée, pas lorsqu’ils forment une échelle de succès implicite.

Critères de décision

Posez les mêmes questions à chaque option avant de choisir.