MVP : ce qu'on coupe, et

ce qu'on ne coupe jamais

La question à poser sur chaque ligne du périmètre

Pour chaque élément que vous envisagez de retirer, posez une seule question : si on l'ajoute dans six mois, est-ce qu'on touche à ce qui existe déjà ?

Si la réponse est non, c'est une fonctionnalité. Elle vit à côté du reste, elle s'ajoute sans rien déranger, et la reporter ne coûte que le délai de sa mise en service. Coupez sans hésiter.

Si la réponse est oui, c'est une fondation. L'ajouter plus tard voudra dire reprendre le modèle de données, migrer l'existant, réécrire des écrans déjà validés et retester ce qui fonctionnait. Le coût n'est plus celui de la fonctionnalité : c'est celui de la fonctionnalité plus la démolition.

Cette question évacue la plupart des débats de périmètre, parce qu'elle ne porte pas sur l'importance ressentie de l'élément mais sur sa place dans l'édifice. Un export PDF peut paraître essentiel au client et rester une fonctionnalité. Un identifiant d'utilisateur peut paraître technique et rester une fondation.

Ce qui se coupe : presque tout

La bonne nouvelle est que la majorité d'un périmètre initial est faite de fonctionnalités reportables. Les candidats habituels :

• Les exports et les rapports. Ils lisent des données existantes ; les ajouter plus tard ne change rien à la façon dont ces données sont stockées.
• Les réglages et les préférences. Chaque option est une branche à écrire, à tester et à maintenir. Un produit qui décide à la place de l'utilisateur est plus rapide à faire et souvent meilleur.
• Les notifications. Sauf si tout l'intérêt du produit repose dessus, elles s'ajoutent sur un existant sans le remanier.
• Les intégrations tierces. Chacune a son cycle de vie propre et ses pannes ; les différer réduit le nombre de choses qui peuvent casser pendant que vous cherchez vos premiers utilisateurs.
• Les seconds rôles de l'interface : pagination sophistiquée, filtres multiples, recherche avancée. Une liste simple suffit tant que les volumes sont ceux d'un début.
• Les tableaux de bord et la visualisation. Ce sont des vues sur des données ; tant qu'il n'y a rien à voir, elles n'apprennent rien.

Ce qui ne se coupe jamais : le modèle de données

La façon dont vos données sont structurées est la fondation la plus profonde et la plus chère à reprendre. Tout est bâti dessus : les écrans, les requêtes, les exports, les droits d'accès.

Le cas d'école est l'appartenance. Un produit conçu pour un utilisateur seul, auquel on demande six mois plus tard de gérer des équipes, ne s'adapte pas : il faut introduire la notion de compte, rattacher chaque objet existant au bon compte, réécrire toutes les requêtes pour qu'elles filtrent dessus, et vérifier une à une qu'aucune ne laisse fuiter les données d'une équipe vers une autre. Ce n'est pas une évolution, c'est une reconstruction sous anesthésie locale.

Vous n'avez pas à implémenter les équipes dans le MVP. Vous avez à décider, avant la première ligne, si le produit en aura un jour — et si oui, à prévoir la place dans le modèle. Une colonne inutilisée coûte quelques minutes ; son absence coûte des semaines.

Ce qui ne se coupe jamais : l'authentification et les droits

L'authentification paraît coupable parce qu'elle n'apporte aucune valeur visible. C'est justement ce qui la rend dangereuse à reporter : on ne la voit pas, donc on ne la prévoit pas, donc tout le code écrit entre-temps suppose qu'il n'y a qu'un utilisateur.

Le vrai sujet n'est d'ailleurs pas l'écran de connexion — celui-là est rapide à faire. Le sujet est le contrôle d'accès : chaque requête doit vérifier que celui qui la formule a le droit de voir ce qu'il demande. Ajouter cette vérification après coup suppose de reprendre chaque point d'entrée sans en oublier un seul, et un seul oubli suffit à exposer les données d'un client à un autre.

Sur un produit destiné à plusieurs clients, c'est le point où une économie de quelques jours se transforme en incident de sécurité, avec les obligations de notification qui l'accompagnent.

Ce qui ne se coupe jamais : les sauvegardes et la journalisation

Une sauvegarde ne sert à rien tant qu'il ne s'est rien passé, ce qui la fait passer pour un luxe de fin de projet. Elle est en réalité la seule chose qui distingue un incident d'une fin d'activité. Et contrairement au reste, elle ne se rattrape pas : on ne restaure pas des données qu'on n'a jamais copiées.

La journalisation obéit à la même logique. Sans trace, le premier bogue en production se diagnostique en interrogeant l'utilisateur, ce qui prend des jours et ne donne jamais la vraie cause. Quelques lignes de journal écrites dès le départ transforment ces jours en minutes.

Ces deux éléments partagent une propriété : ils coûtent peu à mettre en place au début et ne coûtent rien à porter ensuite. Le seul moment où ils coûtent cher, c'est quand on en a besoin et qu'ils ne sont pas là.

Les fausses économies les plus fréquentes

Trois coupes reviennent régulièrement et se retournent presque toujours contre le projet.

• « On met tout dans une seule table, on rangera plus tard. » Le rangement plus tard implique de migrer les données de production sans les perdre, pendant que le produit tourne. C'est l'opération la plus risquée du cycle de vie d'un produit, et vous vous l'infligez volontairement.
• « On gère les erreurs après. » Un produit qui échoue en silence donne des utilisateurs qui pensent avoir enregistré leur travail et ne l'ont pas fait. La confiance perdue là ne se regagne pas avec un correctif.
• « On ne teste rien, on ira plus vite. » C'est vrai les trois premières semaines. Ensuite chaque modification devient une roulette, parce que plus personne ne sait ce qu'elle casse ailleurs. Le ralentissement arrive exactement au moment où vous avez besoin d'aller vite : quand les premiers utilisateurs demandent des changements.

Le MVP n'est pas un produit au rabais

La confusion la plus coûteuse consiste à entendre « minimum viable » comme « version dégradée ». Un MVP fait peu de choses, mais il les fait complètement : ce qu'il propose fonctionne, se sauvegarde, se répare et supporte un deuxième utilisateur.

Un produit qui fait vingt choses à moitié n'apprend rien à personne. Les utilisateurs ne savent pas s'ils n'aiment pas l'idée ou s'ils n'aiment pas l'exécution, et vous non plus. Un produit qui fait trois choses bien donne une réponse exploitable.

C'est le vrai critère pour arbitrer un périmètre : non pas « qu'est-ce qu'on peut enlever » mais « qu'est-ce qui doit marcher parfaitement pour que la réponse des utilisateurs nous apprenne quelque chose ».