Voir son logiciel avant de le payer : à quoi sert un prototype

Commander un logiciel métier, c'est presque toujours acheter un document. Une proposition, un cahier des charges, une liste de fonctionnalités, parfois des maquettes statiques. Vous signez, le développement commence, et la première chose que vous verrez fonctionner arrivera des semaines plus tard. Entre les deux, vous aurez financé une interprétation de votre besoin sans jamais pouvoir la vérifier.

Le prototype visuel inverse cet ordre. Il met l'application devant vos yeux avant le premier euro engagé.

Ce qu'un document ne peut pas prouver

Un cahier des charges est un texte. Il décrit des intentions, et deux lecteurs également compétents en tirent deux logiciels différents. « L'utilisateur valide la commande » peut désigner un simple bouton, un circuit d'approbation à deux niveaux, ou un contrôle automatique sur le stock disponible. Tant que personne ne voit l'écran, personne ne sait laquelle des trois lectures a été chiffrée.

Cet écart se paie toujours, et il se paie tard. Il apparaît à la recette, quand le logiciel fait exactement ce qui était écrit et pas ce qui était attendu. À ce stade, corriger ne veut plus dire changer une phrase : il faut rouvrir des développements déjà payés, et souvent renégocier le périmètre.

Les maquettes graphiques réduisent le risque sans le supprimer. Elles montrent une apparence, rarement un enchaînement. On y voit une page, pas ce qui se passe quand une donnée manque, quand deux personnes travaillent sur le même dossier, ou quand il faut revenir en arrière.

Ce qu'est un prototype, concrètement

Ce qu'il contient

Un prototype visuel présente les écrans réels de l'application, reliés entre eux, remplis de données qui ressemblent aux vôtres. On y parcourt un cas d'usage de bout en bout : créer un dossier, le faire avancer, le consulter la semaine suivante, l'exporter. Les libellés sont ceux de votre métier, pas des mots génériques.

C'est cette continuité qui fait la valeur du prototype. Elle oblige à trancher les questions que le document laissait ouvertes, et elle les rend visibles en quelques minutes de démonstration plutôt qu'en plusieurs réunions.

Ce qu'il n'est pas

Un prototype n'est pas une version bêta. Il n'a ni base de données de production, ni gestion fine des droits, ni sauvegarde, ni performance garantie. Il ne traite aucune donnée réelle et ne doit jamais être mis entre les mains des utilisateurs finaux comme un outil de travail.

Confondre les deux est l'erreur la plus coûteuse du genre : on croit tenir un logiciel presque fini, on l'utilise, et on découvre en production que l'essentiel du travail restait à faire. Un prototype sert à décider. Il ne sert pas à produire.

Pourquoi il est gratuit, et pourquoi il n'est pas livré

Chez LPR Studio, le prototype est offert et présenté en visio sous 5 jours ouvrés. Ce n'est pas une opération commerciale : c'est la façon la plus rapide de savoir si un projet tient debout. Cinq jours de travail valent mieux qu'une avant-vente de trois mois passée à s'accorder sur des phrases.

En contrepartie, le prototype de démonstration reste notre propriété. Il est présenté, pas livré. Ce qui se vend ensuite, c'est l'application finie, déployée et maintenue. Cette règle écarte une situation que personne ne souhaite : un prototype récupéré, confié à un tiers, et un projet qui démarre sur un objet conçu pour convaincre, pas pour durer.

Si le prototype ne vous convainc pas, il ne se passe rien. Pas de facture, pas d'engagement de part et d'autre. C'est le seul moment d'un projet logiciel où dire non ne coûte rien.

Ce que le prototype change pour le budget

Un chiffrage est fiable quand le périmètre est fermé. Or un périmètre décrit en texte reste ouvert : chaque relecture y ajoute une précision, et chaque précision déplace le prix. C'est ce qui produit les devis prudents, gonflés d'une marge de sécurité que vous payez pour couvrir l'incertitude du prestataire.

Le prototype validé ferme le périmètre parce qu'il le montre. Il devient la référence commune : ce qui est à l'écran est dans le forfait, ce qui n'y est pas fera l'objet d'une décision explicite. C'est ce qui permet d'annoncer un prix fixe avant la première ligne de code, et de s'y tenir. Le détail de ce qui pèse sur ce prix est dans notre article sur ce qui fait vraiment le prix d'une application métier.

Il change aussi la nature de la discussion interne. Une direction générale tranche difficilement sur un document de trente pages ; elle tranche sans mal devant un écran qui montre le futur quotidien de ses équipes. Le prototype est autant un outil de décision interne qu'un outil de cadrage.

Comment s'y préparer

Trois éléments suffisent pour lancer un prototype utile.

• Le problème à résoudre, formulé en langage métier et non en solution. « Nos plannings vivent dans quatre tableurs et personne ne sait lequel fait foi » vaut mieux que « il nous faut un module de planification ».
• Les utilisateurs concernés et ce qu'ils font réellement dans la journée. Un outil pensé pour un responsable et utilisé par vingt opérateurs échoue pour cette seule raison.
• Les outils déjà en place : ERP, comptabilité, CRM, fichiers partagés. Une application qui ignore le reste du système d'information ne sert personne.

Vous n'avez besoin ni de spécifications, ni de budget arrêté, ni de validation préalable. C'est justement ce que le prototype sert à construire. La suite du parcours, du prototype à la mise en production, est décrite sur notre page d'approche, et le choix entre forfait et régie est traité dans cet article.