La marche entre le pilote et la production
Beaucoup d’organisations accumulent des pilotes réussis et n’exploitent presque rien. Le constat se lit d’ordinaire comme une hésitation, un manque de courage ou un défaut de budget, et il est rarement l’un des trois. Un pilote et un système en production ne répondent pas à la même question, et rien ne fait passer mécaniquement de l’une à l’autre. Le pilote démontre qu’une chose est possible : il tourne sur des cas souvent choisis, dans un environnement monté pour lui, avec une équipe projet présente pour rattraper ce qui déraille. La production exige que la même chose fonctionne sans surveillance, sur tous les cas y compris ceux qu’on avait écartés parce qu’ils étaient sales, à l’intérieur de systèmes qu’il faut respecter, et qu’elle survive au départ de ceux qui l’ont construite. La distance entre ces deux états n’est pas une question de finition : c’est un autre travail, il coûte souvent autant que le pilote, et il n’est presque jamais budgété au moment où le pilote est lancé. C’est cela, et non le manque de conviction, qui laisse tant de démonstrations en suspens.
Ce qui change réellement
Les données cessent d’être choisies. Le pilote tournait sur un extrait propre. La production reçoit tout : les dossiers incomplets, les doublons, les valeurs aberrantes, les cas que l’équipe avait écartés d’un commun accord parce qu’ils étaient trop particuliers. Ces cas représentent souvent la majorité du temps passé.
Personne ne surveille plus. Pendant le pilote, une sortie douteuse était remarquée par quelqu’un de l’équipe. En production, elle part dans un processus. Il faut donc que le système sache reconnaître ce qu’il ne sait pas traiter, ce qui est un travail distinct de celui qui consiste à bien traiter le reste.
Les contraintes de l’organisation s’appliquent. Authentification, habilitations, journalisation, fenêtres de mise en production, revue de sécurité, localisation des données. Rien de cela ne concernait le pilote, tout cela concerne la production, et l’essentiel se compte en délais plutôt qu’en difficulté.
La responsabilité se déplace. Un pilote appartient à une équipe projet. Un système en production appartient à une équipe d’exploitation qui n’a pas participé à sa construction et qui devra le réparer un mardi soir. Cette équipe a des exigences légitimes sur la façon dont le système échoue et sur ce qu’il journalise.
Comment construire un pilote qui puisse passer
La décision qui compte se prend au lancement du pilote, pas à sa fin. Trois choix rendent le passage possible, et ils coûtent peu au départ.
Faire tourner le pilote sur des données réelles non filtrées, même si les résultats sont moins flatteurs. Un chiffre honnête sur des données sales vaut mieux qu’un excellent chiffre sur un extrait, parce que le second sera démenti au moment du passage et discréditera le projet.
Le mettre entre les mains d’un utilisateur réel, dans son environnement, dès qu’il produit quelque chose d’imparfait. Un pilote qui ne touche jamais un utilisateur ne teste que la faisabilité technique, qui est rarement le point douteux.
Et lancer les demandes d’habilitation dès le premier jour, avant même de savoir exactement ce qui sera construit. Les délais courent de toute façon, et les découvrir en fin de pilote ajoute un trimestre à un projet qui avait réussi.
Le coût du passage, et qui le paie
Le passage en production coûte fréquemment autant que le pilote, parfois davantage, et cette dépense n’est presque jamais provisionnée. Elle couvre la gestion des cas écartés, la détection des situations hors domaine, la journalisation, la reprise après incident, la documentation d’exploitation et la période d’accompagnement.
L’effet de cette omission est prévisible. Le pilote réussit, son coût de passage apparaît, il paraît disproportionné par rapport à une démonstration qui fonctionnait déjà, et la décision est reportée. Le projet ne meurt pas, il reste en démonstration prolongée, ce qui est la façon la plus coûteuse de ne pas choisir.
La correction est administrative plutôt que technique : présenter dès le départ le budget des deux phases, et faire valider le passage en même temps que le pilote, sous condition de résultat. Une organisation qui procède ainsi exploite ce qu’elle démontre.
Le propriétaire, condition qu’on oublie
Un pilote porté par une direction de l’innovation, sans propriétaire dans la direction métier qui exploitera le système, n’a personne dont la réussite dépend du passage en production. Il produit une démonstration convaincante et s’arrête là.
La condition à vérifier avant de lancer est simple et rarement posée : existe-t-il une personne dont l’évaluation annuelle sera meilleure si ce système tourne en production dans six mois. Si la réponse est non, le pilote peut avoir une valeur d’apprentissage, et il ne faut pas en attendre autre chose.
Un problème, trente minutes
Décrivez une tâche qui prend trop de temps aujourd’hui, exceptions comprises. Nous vous dirons si elle vaut la peine d’être construite, et nous le dirons franchement quand ce n’est pas le cas.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
