Faire développer un MVP : pourquoi un prototype est souvent un meilleur point de départ qu'un cahier des charges

Une phrase revient tôt dans de nombreuses discussions de projet : « Mettons d'abord tout par écrit, ensuite vous pourrez nous faire une offre. » Elle semble raisonnable. Après tout, quand on construit une maison, on veut voir les plans avant l'arrivée de la pelleteuse. Pour un logiciel, la comparaison ne vaut que jusqu'à un certain point : on ajoute difficilement un étage à une maison une fois emménagé, alors qu'un formulaire de saisie se modifie bien plus aisément.

Imaginons une entreprise de vingt salariés qui souhaite remplacer sa gestion des commandes. La direction et deux chefs d'équipe rédigent pendant six semaines un cahier des charges. Il compte quatre-vingts pages, des modèles de rôles, des diagrammes d'états et une liste de plus de cent critères obligatoires. Tout le monde en est fier, et personne n'a parlé entre-temps aux collègues du comptoir et du téléphone qui travailleront réellement avec l'outil.

Un document peut décrire ce que l'on imagine, mais pas montrer si cette idée tient dans le quotidien. Cet écart coûte cher par la suite, et il a des causes récurrentes.

Des mécanismes reviennent régulièrement. Le premier : les gens décrivent l'état idéal de leur travail, pas l'état réel. Le papier collé sur l'écran, la liste Excel personnelle, l'appel à la collègue qui « sait toujours » n'apparaissent pas dans le cahier des charges parce qu'on les considère comme des détours. Or ce sont souvent précisément ces détours qui font tourner l'entreprise.

Le deuxième mécanisme est la pression de l'exhaustivité. Un document de cette taille est censé tout régler, si bien que chaque cas particulier qui vient à l'esprit de quelqu'un y est consigné. Les cas rares reçoivent le même poids que le cas normal de tous les jours. À la fin, on ne sait plus ce qui compte vraiment, et un devis doit tout traiter de la même façon. Le troisième mécanisme est plus discret : celui qui décrit un champ ne voit pas ce que cela fait de le remplir vingt fois par jour.

S'y ajoute le langage. Une phrase comme « Le système doit gérer les commandes de manière flexible » peut se réaliser de dix façons, toutes formellement correctes. Le litige naît à la recette, lorsque chaque partie estime que sa lecture est la bonne. Le document a alors un effet juridique, mais aucun pouvoir de clarification.

Les schémas d'échec typiques qui en résultent ressemblent à ceci :

Avant toute décision sur la démarche et le contrat, il vaut la peine de dresser un état des lieux sobre de ce qui est incertain dans le projet. La faisabilité technique l'est rarement pour la plupart des applications métier. Formulaires, listes, rôles, notifications et interfaces avec les systèmes courants sont des problèmes résolus. Ce qui est presque toujours incertain, ce sont les hypothèses sur les personnes et les processus : l'équipe utilisera-t-elle le logiciel, et l'image que l'on se fait du processus est-elle juste ?

Cette question peut être formulée comme une hypothèse centrale, en une phrase qui peut se révéler fausse. Par exemple : « Si les commandes peuvent être saisies sur smartphone en moins d'une minute, les collègues du service extérieur cesseront de tenir des petits papiers. » C'est vérifiable, et cela dit aussi ce qu'il n'est pas nécessaire de construire pour mener le test. La facturation, le reporting et la gestion des droits ne font pas partie du test.

Le périmètre minimal utile découle de l'hypothèse. « Utile » est ici le mot décisif. Un minimum que personne ne peut utiliser au quotidien n'apporte aucun enseignement, et les utilisateurs ne lui accordent que l'attention qu'ils réserveraient à un rendez-vous de démonstration. Le noyau doit pouvoir porter un vrai travail, ne serait-ce que sur un fragment : une équipe, un type de commande, un site.

Il est utile de pondérer explicitement les risques avant de fixer le périmètre. Le graphique suivant montre une telle pondération pour un projet fictif de ce type.

L'alternative au cahier des charges n'est pas de renoncer à planifier, mais de changer l'ordre. On lève d'abord la plus grande incertitude avec l'effort le plus faible possible, puis on décide de ce qui sera construit. Cela ne fait pas économiser de l'argent automatiquement. Cela déplace les dépenses de l'hypothèse vers la connaissance, et c'est là le véritable gain.

Un prototype cliquable est le niveau le plus léger. Il se compose d'écrans conçus que l'on peut relier entre eux, sans logique ni données derrière. Il convient pour vérifier des processus, des termes et des enchaînements, et se réalise en quelques jours plutôt qu'en quelques semaines. Il ne convient pas pour juger de la charge, de la qualité des données ou de l'aptitude à l'usage quotidien, car personne ne travaille avec une maquette comme il le ferait avec un vrai système.

Un MVP fonctionnel va un cran plus loin. Il enregistre de vraies données, dispose d'une connexion et tourne au quotidien, même avec peu de fonctions. Qui souhaite faire développer un MVP devrait donc clarifier dès le départ si un prototype cliquable suffit ou si l'hypothèse ne peut être vérifiée qu'en exploitation réelle. Une combinaison aide le plus souvent : d'abord le prototype pour le processus, puis le MVP pour le test de longue durée.

L'autre côté compte aussi. Une démarche MVP n'est pas le bon choix partout. Pour des processus fortement réglementés, des normes imposées ou le remplacement d'un logiciel existant au périmètre fonctionnel précisément défini, un cahier des charges fonctionnel détaillé peut être pertinent. Même alors, un petit prototype des écrans les plus risqués vaut la peine.

Le découpage commence par l'observation plutôt que par une liste d'exigences. Nous passerions une demi-journée dans l'entreprise, accompagnerions deux ou trois personnes dans leur travail et noterions le déroulement tel qu'il se passe réellement : avec les interruptions, les questions, les notes autocollantes. Il n'en résulte pas un document, mais une courte liste de moments où la solution actuelle échoue.

Le noyau se déduit de ces moments. Comme règle empirique, on se demande si un fragment apporte une utilité à lui seul. Saisir une commande et l'attribuer à un collaborateur peut être un tel fragment. Saisir une commande sans encore la facturer l'est probablement aussi. Facturer sans saisir ne l'est pas. On obtient ainsi une coupe à travers le processus qui contient un morceau de travail de bout en bout, plutôt qu'un peu de chaque couche.

La décision de ce qui ne sera pas construit en fait pleinement partie. Nous tenons donc une courte « liste du pas encore », où figurent les fonctions volontairement mises de côté, chacune avec sa raison. On voit ainsi qu'une chose n'a pas été oubliée mais reportée, et la liste devient plus tard la base de la planification de l'extension.

Plusieurs étapes d'extension peuvent se représenter comme des couches qui s'appuient les unes sur les autres, chacune avec son propre objectif d'apprentissage.

Une objection courante veut qu'un MVP soit un produit jetable qu'il faudra ensuite réécrire entièrement. C'est vrai si on le construit ainsi. Ce n'est pas forcément vrai. L'essentiel est de savoir où l'on économise. On économise sur le périmètre, l'apparence et les cas particuliers, pas sur le modèle de données, la protection des accès et la traçabilité. Un modèle de données propre peut être étendu, un modèle chaotique ne peut qu'être remplacé.

En pratique, nous misons sur des briques éprouvées et répandues : une base de données relationnelle, une interface web qui fonctionne sur smartphone comme sur ordinateur, une connexion via des méthodes établies, des sauvegardes régulières. Nous renonçons aux développements maison pour les problèmes standard comme la gestion des mots de passe ou l'envoi d'e-mails. Cela réduit non seulement l'effort, mais facilite aussi le passage à l'extension ultérieure, car d'autres développeurs connaissent ces briques.

Le travail se déroule en cycles courts. Une démonstration est suivie d'une utilisation par de vrais utilisateurs, puis d'une évaluation et de la décision sur la prochaine coupe. Une version entre en exploitation quotidienne après quelques semaines, et non une fois toutes les fonctions terminées. La traçabilité implique que chaque modification soit documentée dans un système de gestion de versions et que l'équipe puisse essayer dans un environnement de test avant toute mise en ligne.

Quelques contrôles choisis avec soin assurent la sécurité. Les processus centraux bénéficient de tests automatisés pour que des modifications ultérieures ne les endommagent pas à l'insu de tous. Pour les données, la règle est la même que pour les systèmes plus grands : les sauvegardes ne doivent pas seulement s'exécuter, elles doivent avoir été restaurées au moins une fois à titre d'essai. Tout le reste, comme un concept de droits sophistiqué, suit lorsque le noyau tient.

Peu de questions sont débattues avec autant de passion. Le prix fixe promet la sécurité, la régie promet la flexibilité, et ces deux promesses ne sont qu'à moitié vraies. Un prix fixe est fiable lorsque la prestation est décrite avec précision. Plus l'exigence est floue, plus le prestataire intègre de marge, ou plus le litige est grand par la suite sur ce qui était « inclus ». Le prix fixe déplace le risque, il ne le supprime pas.

La régie est plus honnête lorsque l'objectif n'est pas encore arrêté. Vous payez le travail réellement fourni et gardez le pilotage. Le prix à payer est la discipline de votre côté : sans plafond, sans points d'étape réguliers et sans priorisation claire, un projet peut s'étendre en silence. Qui y recourt devrait fixer un cadre, par exemple un budget par cycle suivi d'une décision sur le suivant.

Un modèle par étapes a fait ses preuves comme voie médiane. Le test, c'est-à-dire l'observation, le prototype et le premier MVP, est convenu comme un lot raisonnable au périmètre et au prix fixes, car il peut être décrit à l'avance. L'extension qui suit se déroule en cycles, chacun avec un plafond et une validation claire. Il y a ainsi une sortie à chaque étape, et la décision sur le gros budget se prend en connaissance de cause plutôt que par espoir.

Être honnête, c'est aussi reconnaître que ce modèle a des inconvénients. Le coût total n'est pas fixé au départ. Si vous avez besoin en interne d'une somme ferme pour libérer le budget, elle peut être donnée sous forme de fourchette qui se resserre après le test. Et une démarche par étapes suppose que vous ayez du temps pour les retours. Sans cela, même le meilleur contrat n'y fait rien.

Dans un projet itératif, les modifications sont la règle, pas une perturbation. Cela ne rend pas la gestion des changements superflue, mais nécessaire, car sans règles la souplesse devient arbitraire. Une courte liste a fait ses preuves, où chaque modification figure avec sa raison, l'effort estimé et son impact sur le calendrier ou le budget, ainsi qu'une personne de votre côté qui tranche les priorités. Plusieurs décideurs aux souhaits différents sont le risque le plus fréquent dans ce type de projet.

La recette aussi appelle une autre forme. Au lieu d'un rendez-vous unique à la fin, il y a des critères de recette par cycle, formulés de façon à pouvoir être observés. « Le logiciel est convivial » n'en est pas un. « Un nouveau collaborateur saisit une commande sans aide après dix minutes d'initiation » en est un. De tels critères peuvent être vérifiés au quotidien et évitent les querelles d'interprétation.

Un autre cas particulier est le fonds de données existant. Lorsque des données anciennes doivent être reprises, on ne voit souvent qu'au test à quel point elles sont hétérogènes : clients en double, texte libre au lieu d'une sélection, informations obligatoires manquantes. Nous recommandons d'importer les données tôt avec un petit extrait, car le nettoyage est sinon sous-estimé. Il en va de même pour les interfaces avec des systèmes tiers, dont le comportement n'est vraiment connu qu'en pratique.

Il y a enfin le cas où l'hypothèse se révèle fausse. C'est un bon résultat, même si on ne le ressent pas ainsi. Avec un investissement limité, on a appris que la voie prévue ne tient pas, et l'on peut changer de cap ou renoncer au projet. Il faut pour cela définir à l'avance à quoi on le reconnaîtra, faute de quoi chaque retour est lu comme une confirmation.

Une démarche MVP améliore la base de décision, pas automatiquement le résultat. Ce que vous pouvez attendre, c'est que les plus grosses hypothèses erronées soient repérées plus tôt que dans un projet entièrement planifié à l'avance. Que cela fasse in fine économiser de l'argent ou du temps dépend du projet, de l'équipe et de la qualité de la collaboration. Nous ne pouvons pas annoncer sérieusement de pourcentages d'économie.

Le bénéfice se mesure à l'aide d'indicateurs proches du quotidien. Il s'agit notamment du temps nécessaire au processus central par rapport à l'ancienne méthode, du nombre de questions et de corrections par opération, de la part des opérations qui naissent réellement dans le système plutôt que sur des bouts de papier ou dans des tableurs, ainsi que de l'utilisation volontaire après la phase de mise en place. L'état actuel devrait être relevé grossièrement avant le début, sinon la comparaison fait défaut.

Comptez plusieurs semaines d'observation avant que des tendances apparaissent. Les premiers jours sont marqués par la curiosité et les difficultés de démarrage ; l'utilisation ne devient significative que lorsque l'attrait de la nouveauté est passé. C'est une raison de plus de ne pas fixer le test trop court. Il est en outre utile, après la phase d'observation, de parler aux utilisateurs qui évitent le système : leurs raisons montrent souvent mieux que n'importe quelle statistique quelle hypothèse n'a pas tenu et si l'on peut y remédier par un ajustement ou seulement en y renonçant.

On ne peut pas garantir que le MVP deviendra plus tard la solution complète sans remaniement, que tous les intéressés accepteront le logiciel ni que le prix total restera sous un certain seuil. Ce qui peut être promis, c'est une démarche compréhensible, des points d'étape honnêtes et la possibilité de sortir à des étapes définies.

L'idée la plus importante est que la clarté naît de l'usage, pas de la description. Cela ne signifie pas que les descriptions soient sans valeur. Un document concis avec l'image de l'objectif, l'hypothèse centrale, la liste du pas encore et les critères de recette s'est souvent révélé une meilleure base de travail qu'un cahier des charges exhaustif, car il consigne des décisions sans présenter des hypothèses comme des faits.

Le deuxième enseignement concerne l'implication. Impliquer tôt les utilisateurs ne signifie pas les installer en atelier, mais leur donner quelque chose de tangible et observer leur réaction. Même un prototype cliquable qu'une collègue manipule pendant cinq minutes apporte souvent plus qu'une journée d'entretiens sur les exigences. Il est tout aussi important de ne pas interroger uniquement les enthousiastes, mais aussi les sceptiques, car leurs objections sont généralement plus concrètes et portent précisément sur les endroits où le quotidien mettra plus tard le système à l'épreuve.

Troisièmement, toute décision sur le périmètre devrait comporter un refus motivé. Un MVP qui sait tout faire un peu n'est pas un MVP. Qui ne fait qu'ajouter des fonctions sans jamais en retirer construit un cahier des charges en code. Une règle fixe aide : pour chaque nouvelle fonction, on précise quelle hypothèse elle vérifie et à quoi on le reconnaîtra.

Un cahier des charges n'est pas une erreur, mais c'est souvent la mauvaise première étape. Si vous n'êtes pas sûr que l'équipe adoptera un nouveau logiciel et que l'image du processus est juste, un petit noyau utilisable est la manière la plus économique de le découvrir. Qui souhaite faire développer un MVP achète avant tout une réponse fiable à la question de ce qu'il faut vraiment construire.

L'étape suivante est raisonnable. Formulez en une phrase ce qui doit changer au quotidien et notez à quoi vous le reconnaîtriez. Ajoutez trois choses dont vous n'avez expressément pas encore besoin. Avec cette demi-page, on peut mener un échange qui apporte plus qu'un long document. Nous l'examinons volontiers avec vous et vous dirons clairement si une démarche MVP convient à votre projet ou si un cahier des charges fonctionnel classique est le meilleur choix.