Pourquoi faire un prototype avant de développer un logiciel ?

Un cahier des charges ne se teste pas.

Un projet de logiciel commence presque toujours par des mots. On décrit ce que l'outil doit faire, on le relit, on le valide. Le problème, c'est qu'une phrase claire pour celui qui l'écrit ne l'est pas forcément pour celui qui la lit.

La direction pense au contrôle, l'équipe pense à son quotidien, le développeur pense à ce qui est écrit. Chacun lit la même phrase avec sa propre image en tête, et personne ne s'en rend compte, puisque la phrase ne change pas.

Il y a une deuxième difficulté, plus profonde : beaucoup de besoins ne se découvrent qu'en voyant l'outil. Personne ne pense à écrire qu'il faut traiter les avoirs, jusqu'au moment où quelqu'un cherche où les mettre. Ces oublis ne viennent pas d'un manque de sérieux. Ils viennent du fait qu'on décrit son travail de mémoire, et que la mémoire garde les cas habituels, pas les exceptions.

Maquette, prototype, POC : de quoi parle-t-on ?

Ces mots sont souvent utilisés l'un pour l'autre. Ils désignent pourtant des étapes différentes, qui répondent chacune à une question précise.

Un prototype et un POC peuvent se combiner : un parcours cliquable pour l'usage, avec la partie risquée réellement construite pour la technique. Ce qui compte, c'est de savoir lequel des deux doutes on cherche à lever.

Ce qu'un prototype révèle, et qu'un document cache.

Devant un écran qui contient ses propres dossiers, un collaborateur réagit en quelques minutes. Il ne commente plus un texte, il essaie de faire son travail, et il bute là où l'outil ne suit pas. Voici le genre de retours qu'on entend pendant un test.

Aucun de ces retours n'est spectaculaire. C'est justement ce qui les rend précieux : ce sont des détails du quotidien, invisibles sur le papier, qui décident si un outil sera adopté ou contourné. Un prototype les fait remonter pendant qu'il est encore simple d'en tenir compte.

Plus une erreur est découverte tard, plus elle coûte.

Une erreur de compréhension finit toujours par apparaître. La seule question est de savoir quand. Selon le moment, la même découverte ne demande pas du tout le même travail pour être corrigée.

Pendant un prototype, rien n'est encore construit pour durer : changer un écran ou une règle ne casse rien. Pendant le développement, chaque changement touche du code déjà écrit, déjà testé, parfois déjà relié au reste. Après la livraison, c'est souvent pire : personne ne demande de correction, les équipes ouvrent un tableur à côté, et l'outil perd peu à peu son intérêt.

C'est pour cela que nous disons qu'un prototype vaut aussi quand il échoue. Il coûte quelques jours, là où la même découverte faite en cours de développement coûterait plusieurs mois.

Le bon moment pour un prototype : après l'audit, avant le développement.

Un prototype construit trop tôt teste une idée floue. Avant de prototyper, il faut savoir quel problème on cherche à résoudre, et pour qui. C'est le rôle de l'audit de processus : observer comment le travail se fait vraiment, et désigner le cas d'usage qui compte le plus.

Nous conseillons aussi de garder le prototype petit. Un seul cas d'usage, traité de bout en bout, en apprend plus que dix fonctionnalités esquissées. Le but n'est pas de montrer tout le futur logiciel, mais de lever le doute qui bloque la décision.

Vous ne savez pas encore par où commencer ? Notre article Comment savoir quels processus automatiser dans une PME ? aide à choisir le premier cas d'usage.

Comment préparer un prototype utile.

Un prototype vaut ce que valent les éléments sur lesquels il est construit. Avec des exemples inventés, il convainc tout le monde et ne prouve rien. Avec vos vraies pièces, il dit la vérité.

Vos documents sont souvent confidentiels. C'est une raison de poser les règles avant le moindre envoi : accord de confidentialité, lieu d'hébergement, et ce qu'il advient des pièces une fois le test terminé.

Après le prototype : trois issues possibles.

Un prototype se termine par une décision. Elle se prend sur ce que tout le monde a vu fonctionner, et non plus sur une hypothèse.

Quand le développement est lancé, il se fait par étapes courtes, chacune testable par vos équipes. Le prototype n'y disparaît pas : il sert de référence commune tout au long du projet. Pour savoir ce que représente ensuite le budget d'un logiciel, lisez Combien coûte un logiciel sur-mesure pour une PME en Suisse ?