La démonstration a convaincu tout le monde. Six mois plus tard, elle n'est toujours pas en service.

Ce qu'un prototype démontre, et ce qu'il ne démontre pas

Un prototype répond à une question : est-ce faisable, et à quoi cela ressemblerait-il ? C'est une question utile, et y répondre vite est un progrès réel.

Un outil de production répond à une autre question, beaucoup plus large : que se passe-t-il quand les données sont sales, quand la source change de format sans prévenir, quand deux personnes agissent en même temps, quand quelqu'un se trompe, quand un service tiers ne répond plus, quand la personne qui l'a conçu est partie ?

Le prototype traite le chemin qui fonctionne. L'outil doit traiter tous les autres, et les autres sont beaucoup plus nombreux. C'est pour cela que l'écart de travail entre les deux surprend systématiquement : il n'est pas visible, parce que ce qui manque ne s'affiche jamais à l'écran.

Pourquoi l'illusion est plus forte aujourd'hui

Il y a quelques années, un prototype ressemblait à un prototype. Les écrans étaient bruts, la navigation approximative, et personne ne confondait.

Aujourd'hui, un assistant ou une plateforme sans code produit en quelques jours quelque chose de soigné, cliquable et convaincant, avec de vrais boutons et de vraies transitions. Il ressemble à un produit fini, parce que la partie qui coûtait le plus cher à l'apparence est devenue presque gratuite.

Le déséquilibre s'est donc creusé : la façade s'est rapprochée du produit fini, et tout ce qui n'est pas la façade est resté exactement aussi long à construire. Un dirigeant qui juge sur ce qu'il voit conclut logiquement qu'on est près du but. Il se trompe de plus en plus, et de bonne foi.

Cela ne condamne ni ces outils ni cette manière de travailler. Un prototype obtenu en trois jours est une excellente affaire, tant qu'on sait ce qu'on a acheté.

Ce qui manque, précisément

Sept éléments, dont aucun ne se voit sur une démonstration, et qui représentent l'essentiel du travail restant.

1. 01Les droits : qui voit quoi, qui modifie quoi, qui valide, et ce que devient l'accès de quelqu'un qui part.
2. 02Les données réelles, qui sont incomplètes, contradictoires et pleines d'historique, là où le prototype tournait sur un jeu propre.
3. 03La reprise de l'existant : ce qui est déjà dans l'ancien système et qu'il faut faire entrer sans le déformer.
4. 04Le comportement en cas d'erreur : ce que le système fait, ce qu'il affiche, ce qu'il enregistre, et comment on rattrape.
5. 05La traçabilité : pouvoir expliquer un chiffre affiché en remontant jusqu'à sa source, plusieurs mois après.
6. 06L'exploitation : les sauvegardes, la restauration, la surveillance, et quelqu'un que l'on appelle quand ça s'arrête un lundi matin.
7. 07La propriété : qui détient le code, les accès et les données, et avec quoi on continue si la relation s'arrête.

Le point sur les données réelles est celui qui coûte le plus, et il est le plus systématiquement sous-estimé. Un prototype confronté à une donnée absente ou aberrante ne s'arrête pas : il produit un résultat quand même, comme le ferait un tableur. Ce résultat a l'apparence d'un chiffre, il est utilisé pour décider, et l'erreur ne se découvre que par sa conséquence.

Les cinq questions qui tranchent

Elles se posent devant le prototype, en quinze minutes, sans compétence technique. Les réponses vous disent s'il est à un mois ou à un an de la production.

1. 01Que fait-il quand une donnée manque ? La seule bonne réponse est qu'il s'arrête et affiche ce qui manque. S'il calcule quand même, tout le reste est sans objet.
2. 02Qui a le droit de faire quoi ? Si la réponse est « tout le monde peut tout », il n'y a pas de droits, il y a une absence de droits.
3. 03D'où viennent les données, et que se passe-t-il le jour où la source change ? Une source change toujours, et rarement en prévenant.
4. 04Qui pourra le modifier dans six mois, avec quoi, et en s'appuyant sur quelle documentation ?
5. 05Peut-on expliquer un résultat affiché en remontant jusqu'aux éléments qui l'ont produit ? Si personne ne sait le faire aujourd'hui, personne ne saura le faire pendant un litige.

Le bon usage d'un prototype

Il existe, il est précieux, et il consiste à décider.

Un prototype sert à trancher une question ouverte : cette façon de présenter l'information convient-elle aux utilisateurs, cette règle produit-elle le résultat attendu sur des cas réels, ce parcours est-il praticable en situation ? Il répond en quelques jours à des questions qui prendraient des semaines de réunions.

Un prototype réussi est un prototype qu'on jette après avoir appris ce qu'on voulait savoir. Ce qu'il faut garder n'est pas le code : c'est la décision qu'il a permis de prendre, écrite quelque part.

L'erreur consiste à le promouvoir en production parce qu'il fonctionne, et parce que le jeter semble du gâchis. C'est là qu'on hérite d'un système que personne ne sait maintenir, dont les règles ne sont écrites nulle part, et qui produit des chiffres que personne ne peut justifier.

Quand on peut le garder quand même

Soyons honnêtes : il existe des cas où promouvoir un prototype est raisonnable. Quatre conditions, et il faut les quatre.

1. 01L'usage est interne et concerne une ou deux personnes, qui savent exactement ce que l'outil fait.
2. 02Rien n'en sort vers l'extérieur : ni facture, ni message client, ni commande fournisseur.
3. 03Aucune décision engageante ne repose sur ses résultats sans vérification humaine.
4. 04Sa disparition du jour au lendemain serait un désagrément, pas un arrêt d'activité.

Ces quatre conditions décrivent un outil personnel utile, et beaucoup d'entreprises en ont de très bons. Le danger n'apparaît pas le jour de sa création : il apparaît le jour où quinze personnes en dépendent sans que personne n'ait décidé ce changement de statut.

C'est exactement le mécanisme par lequel un tableur devient critique, et il mérite la même vigilance.