Sortir du prototype : les cinq verrous

On décrit souvent le passage en production comme un saut : il y aurait le prototype d'un côté, la production de l'autre, et un effort à fournir entre les deux.

Cette image est fausse et elle est coûteuse, parce qu'elle laisse croire qu'on peut y aller d'un coup, avec un budget et trois mois. En réalité il y a cinq verrous distincts, chacun avec sa propre nature, deux techniques, trois organisationnels, et ils se lèvent dans un ordre qui n'est pas négociable.

Tant que le système tourne sur un corpus choisi, tout ce qu'on observe est une illusion de performance.

Le passage aux données réelles est brutal et il doit arriver tôt. Sur un projet documentaire, il révèle en général en quelques jours : des documents scannés que personne n'avait signalés, des doublons contradictoires, des fichiers dont les droits d'accès n'avaient jamais été formalisés, et une proportion de contenu périmé qui dépasse toujours l'estimation initiale.

Ce verrou se lève en premier parce que tous les autres dépendent de ce qu'on y découvre.

Un jeu de tests métier n'est pas un test unitaire. C'est un ensemble de cas réels, avec pour chacun une réponse jugée acceptable par quelqu'un qui fait autorité dans le métier.

Trente cas suffisent pour commencer. Ce qui compte n'est pas le volume mais le fait que le jugement soit extérieur à l'équipe technique : c'est ce qui rend la mesure opposable, et c'est ce qui permet, six mois plus tard, de dire si un changement de modèle a amélioré ou dégradé le service.

Chaque verrou consomme le résultat du précédent. On ne peut pas définir une mesure pertinente sans avoir vu les données réelles. On ne peut pas décider du point d'intégration sans savoir ce que le système sait vraiment faire. On ne peut pas outiller l'exploitation sans usage réel à observer.

Les équipes qui inversent l'ordre, typiquement, qui commencent par l'interface, refont deux fois le travail. Je l'ai vu suffisamment pour en faire une règle de cadrage plutôt qu'un conseil.

Le propriétaire métier nommé, celui qui accepte de répondre du système, est le verrou dont l'absence arrête le plus de projets, et il se lève au cadrage ou jamais. Trois ans d'observation le confirment.

Le schéma d'échec est constant : l'équipe technique construit, présente, et découvre au déploiement qu'un responsable refuse. Il refuse à juste titre, n'ayant pas participé à la définition du périmètre.

La parade tient en une demi-journée d'atelier : lister les actions, les classer par réversibilité, faire valider le classement. Le constat détaillé figure dans agents en entreprise : où s'arrêtent les projets.

Un prototype mesuré sur des cas choisis sous-estime le coût de production d'un facteur trois à cinq. Ce sixième verrou apparaît une fois les cinq autres levés.

La raison tient à la composition des cas : le prototype porte sur des dossiers représentatifs, la production apporte les cas difficiles qui consomment dix fois la moyenne.

La parade se pose dès le prototype, plafond de dépense appliqué par le système, mesure au quantile élevé, et la méthode de mesure est décrite dans mesurer le coût par fonctionnalité.

Un jeu de tests, une fiche d'une page et la liste datée des décisions prises : sans ces trois pièces, le système ne survit pas au départ de celui qui l'a construit. Elles coûtent une journée.

Le jeu de tests permet à la personne suivante de modifier sans casser. La fiche décrit finalité, données, décision servie et supervision. La liste des décisions consigne quel palier pour quelle tâche, quel seuil, à quelle date.

Ces trois livrables sont ceux que je rends systématiquement en fin de mission, et leur contenu est détaillé dans les trois gestes qui font tenir un système.