Deux objets qui n'ont pas le même but
Un MVP n'est pas une version réduite du produit final, c'est un instrument de mesure. Il existe pour répondre à une question : les utilisateurs font-ils ce que nous supposons qu'ils feront ? Tout ce qui ne sert pas à répondre à cette question est hors périmètre, y compris des choses qui paraissent indispensables.
Un produit industrialisé répond à une autre question : ce logiciel peut-il porter une activité pendant des années, avec des volumes croissants et des exigences de disponibilité ? Il intègre donc les tests, la supervision, les sauvegardes, la sécurité et la capacité d'évoluer sans tout casser.
Ce sont deux commandes différentes. Les deux échecs classiques viennent de leur confusion.
Premier échec : le MVP qui n'en est pas un
Le scénario est archi-connu. On annonce un MVP, puis chaque partie prenante ajoute la fonctionnalité sans laquelle « ça n'a pas de sens ». Neuf mois plus tard, le produit sort avec quarante fonctionnalités, un budget complet consommé, et la question initiale toujours sans réponse.
Le symptôme se détecte tôt : si vous ne pouvez pas énoncer en une phrase l'hypothèse que le MVP doit valider, ce n'est pas un MVP, c'est une version 1 sous-financée.
La discipline consiste à choisir un seul parcours, celui qui porte la valeur, et à traiter tout le reste manuellement. Un processus opéré à la main derrière l'écran est une réponse parfaitement légitime au stade de la validation, et c'est souvent celle qui apprend le plus sur le métier réel.
Second échec : le MVP qu'on ne quitte jamais
L'échec symétrique est plus insidieux. Le prototype fonctionne, les clients arrivent, l'activité décolle. Personne n'ose arrêter pour consolider, puisque tout marche.
Les signaux apparaissent progressivement : les incidents se multiplient, chaque correction en provoque une autre, les délais de livraison s'allongent sans que le contenu grossisse. L'équipe passe plus de temps à réparer qu'à construire.
À ce stade, l'industrialisation n'est plus un projet d'amélioration, c'est un sauvetage, mené sous contrainte d'exploitation, donc au pire moment et au prix fort. La dette technique acceptée pour aller vite est légitime ; ce qui coûte cher, c'est de ne jamais l'avoir inscrite quelque part ni datée.
Ce que contient réellement l'industrialisation
Le terme reste vague pour beaucoup de directions, ce qui explique qu'il soit si facilement reporté. Concrètement, il recouvre cinq chantiers.
Les tests automatisés, qui permettent de modifier sans casser et sans tout re-vérifier à la main. La supervision et les alertes, pour découvrir un incident avant que le client n'appelle. Les sauvegardes et le plan de reprise, testés et non seulement configurés. La sécurité, du cloisonnement des données à la gestion des accès. Enfin, la capacité à monter en charge, dimensionnée sur des mesures et non sur des estimations.
Aucun de ces chantiers n'ajoute une fonctionnalité visible. C'est pour cette raison qu'ils sont systématiquement repoussés, et pour cette même raison qu'ils doivent être décidés en amont, pas arbitrés au sprint le sprint.
Le bon moment pour basculer
Trois signaux, et il suffit qu'un seul apparaisse.
Le produit est facturé. À partir du moment où un client paie, il attend une disponibilité. La tolérance à l'incident chute brutalement, et elle ne remonte pas.
La correction devient plus coûteuse que la construction. Quand une modification de trois jours en génère cinq de régressions, la structure du code est devenue le facteur limitant.
Le volume approche la limite de conception. Un prototype tient facilement quelques centaines d'utilisateurs. Le passage à l'échelle supérieure se prépare avant d'y arriver, jamais pendant.
Industrialiser sans tout réécrire
La bonne nouvelle est que l'industrialisation n'implique pas de repartir de zéro, et que le faire est même généralement une erreur.
La démarche efficace commence par un état des lieux : ce qui est utilisé, ce qui ne l'est jamais, ce qui casse le plus souvent. Elle se poursuit par la mise sous tests des parcours critiques, ce qui rend l'application modifiable en sécurité. Elle continue par la mise en place de la supervision et des sauvegardes, qui protègent l'exploitation immédiatement. Elle finit par la reprise des modules les plus fragiles, un par un, à mesure que des évolutions les concernent.
Le MVP a produit une information qu'aucune spécification n'aurait donnée : la liste de ce qui sert réellement. C'est le meilleur cahier des charges possible pour la version industrialisée, et c'est ce qui rend cette séquence plus sûre qu'un développement lancé d'emblée sur un périmètre supposé.
