Anatomie d'un POC qui ne passe jamais en production

J'ai été appelé plusieurs fois en 2023 pour reprendre des projets dont la phrase d'ouverture était toujours la même : « le POC a très bien marché, mais ça n'est jamais allé plus loin ».

C'est une phrase importante, parce qu'elle contient déjà le diagnostic. Un POC qui marche très bien et qui ne va pas plus loin n'a pas échoué techniquement. Il a échoué à devenir le problème de quelqu'un.

Sur l'ensemble des cas que j'ai repris, la première cause d'abandon est l'absence de propriétaire métier.

Un projet porté par la seule direction des systèmes d'information a un commanditaire mais pas de bénéficiaire. Quand arrive l'arbitrage budgétaire, personne dans les métiers ne se lève pour le défendre, parce que personne n'a rien à perdre à son abandon. Le projet ne meurt pas d'un rejet : il meurt d'indifférence.

Je demande donc, avant tout engagement : qui, nommément, aura une moins bonne année si ce système n'existe pas. Si la question n'a pas de réponse, je le dis.

Un système d'IA générative produit du texte plausible. C'est précisément ce qui rend son évaluation difficile : une réponse fausse ressemble beaucoup à une réponse juste.

Sans jeu de tests constitué avant le développement, l'équipe en est réduite à l'impression. Or l'impression est excellente les deux premières semaines, puis se dégrade au fur et à mesure que les cas tordus arrivent. Comme rien n'est mesuré, la dégradation n'est pas objectivée : elle est simplement ressentie, et elle se traduit par un désengagement silencieux.

Un système excellent, accessible dans une interface séparée, perd contre un système médiocre intégré là où le travail se fait déjà.

Ce n'est pas de la paresse. C'est que le coût d'un changement de contexte, répété quarante fois par jour, dépasse le gain apporté par l'outil. J'ai vu des taux d'usage passer de trois à soixante pour cent sans toucher au modèle, uniquement en déplaçant la fonction dans l'outil de gestion déjà utilisé.

C'est aussi pourquoi je refuse désormais les projets qui commencent par « on va faire un portail ».

Depuis, je ne livre plus de prototype isolé. La première livraison est un système restreint mais complet : peu de cas couverts, mais branché aux vraies données, avec ses droits d'accès, sa journalisation et son jeu de tests.

C'est moins spectaculaire à montrer. Mais quand la direction décide de continuer, il n'y a rien à jeter, on élargit le périmètre, on ne recommence pas.

Cette exigence a un nom, et c'est celui du métier que j'exerce : Forward Deployed Engineer.

Un prototype mesuré sur des cas choisis sous-estime le coût de production d'un facteur trois à cinq, et cette découverte arrive après l'engagement. C'est la cause d'arrêt la moins commentée.

La raison tient à la composition des cas. Un prototype porte sur des dossiers représentatifs, souvent sélectionnés. La production apporte les cas difficiles : ceux qui font boucler le système, tenter plusieurs approches, consommer dix fois la moyenne.

La parade se pose dès le prototype : un plafond de dépense appliqué par le système, et une mesure au quantile élevé plutôt qu'en moyenne. Le mécanisme est détaillé dans agents en entreprise : où s'arrêtent les projets.

Les prototypes qui atteignent la production partagent trois traits : un périmètre étroit, un résultat vérifiable, et un propriétaire métier nommé dès le cadrage. Aucun de ces traits n'est technique.

Le périmètre étroit signifie une tâche, pas une plateforme. Le résultat vérifiable signifie qu'on sait dire, à la fin, si c'est juste, par une citation, un test, une comparaison avec une référence.

Le propriétaire nommé est le plus déterminant : c'est la personne qui accepte de répondre du système et qui décidera de sa mise en service. Sans elle, le refus arrive au moment du déploiement, budget déjà consommé, la séquence décrite dans sortir du prototype, les cinq verrous.