Anatomie d’un POC qui ne passe jamais en production

Un POC d’IA qui ne passe jamais en production peut convaincre en démonstration sans qu’une équipe métier accepte ensuite de l’utiliser, de le financer et de le reprendre.

J’ai été appelé plusieurs fois en 2023 pour reprendre des projets ouverts par la même phrase : « le POC a très bien marché, mais ça n’est jamais allé plus loin ». Le prototype avait levé un doute technique, sans devenir le problème de quelqu’un. Une preuve de concept doit donc préciser ce qu’elle prouve et ce qui reste à construire.

L’absence de propriétaire métier peut conduire à l’abandon d’un POC d’IA : un projet sans bénéficiaire nommé ne trouve personne pour le défendre au moment de l’arbitrage budgétaire. Sur l’ensemble des cas que j’ai repris, c’est la cause qui revient en premier.

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.

Ce propriétaire n’a pas besoin d’être un expert de l’IA. Il doit connaître la tâche, avoir autorité sur la façon dont elle est faite, et accepter de répondre de la qualité du résultat. C’est un rôle que ChatGPT a d’ailleurs commencé à faire entrer en comité de direction, mais qu’on attribue encore trop rarement par écrit.

Personne ne sait dire si un POC d’IA générative est bon quand aucun jeu de tests n’a été constitué avant le développement, parce qu’une réponse fausse ressemble beaucoup à une réponse juste. Le système produit du texte plausible, et c’est précisément ce qui rend son évaluation difficile.

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 exemple générique : un assistant qui répond aux questions sur un catalogue de contrats impressionne sur les dix questions de la démonstration. En pilote, les utilisateurs posent des questions sur des avenants, des contrats résiliés, des clauses ambiguës. Personne n’a défini ce qu’était une bonne réponse sur ces cas, donc personne ne peut dire si le système progresse ou recule. Les raisons pour lesquelles vos premiers essais avec GPT-4 échouent tiennent souvent à cette absence de référence.

Avant de lancer un POC d’IA, il faut nommer son utilisateur, décrire la tâche, définir la qualité attendue et préparer l’exploitation avec une équipe de reprise.

• Nommez la personne qui utilisera le système chaque semaine. Un service ne suffit pas : un nom.
• Décrivez la tâche telle qu’elle se fait aujourd’hui, geste par geste, avec le temps qu’elle prend.
• Définissez une bonne réponse sur trente cas réels, validés par quelqu’un qui fait autorité.
• Situez l’outil dans un logiciel déjà ouvert toute la journée, pas dans un nouvel onglet.
• Chiffrez le coût par requête et par mois, avant d’écrire la première ligne.
• Désignez qui reprend le système quand le prestataire s’en va, et faites-le travailler dessus dès le premier jour.

Un outil d’IA placé dans une interface séparée impose un changement de contexte dont le coût doit être comparé au gain réel pour l’utilisateur dans sa tâche quotidienne.

L’intégration peut favoriser l’usage sans changement de modèle. Je ne retiens pas de taux d’adoption universel : il faut observer les gestes, la fréquence du besoin et les contraintes du logiciel existant.

Je demande quel écran est ouvert quand la question se pose et comment y faire apparaître un résultat contrôlable. Les plugins de ChatGPT, quand un modèle commence à agir, montrent l’intérêt de relier une réponse aux outils de travail.

Un POC justifie une première mise en service s’il réduit un doute identifié sur une tâche réelle et laisse des éléments réutilisables pour construire l’exploitation.

Un POC n’a de valeur que s’il est conçu comme la première itération de la production, pas comme sa maquette. Si l’architecture du POC ne peut pas devenir celle du système final, le POC ne prouve rien d’autre que la capacité du modèle à produire du texte, ce qui n’était pas la question.

Le coût de production peut être découvert trop tard lorsque le prototype mesure seulement les cas choisis, sans prendre en compte les documents longs ni les reprises humaines.

Comparez le coût des cas ordinaires et difficiles : recherche dans plusieurs sources, reformulations, documents longs, vérification du résultat. Aucun multiplicateur général ne décrit cet écart.

Dès le prototype, chiffrez les appels, la revue et l’exploitation, puis fixez une enveloppe avec une règle d’arrêt explicite. La fenêtre de 8 000 jetons de GPT-4 rappelle que le contexte envoyé affecte la facture. Lecture complémentaire : où s’arrêtent les projets en entreprise.

Les prototypes d’IA 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é. Lecture complémentaire sur cette séquence : sortir du prototype, les cinq verrous.

Cadrer un POC d’IA pour la production revient à le concevoir comme une première version restreinte mais complète, branchée aux vraies données, avec ses droits, sa journalisation et son jeu de tests. Depuis, je ne livre plus de prototype isolé.

La démarche tient en cinq étapes :

1. Nommer le propriétaire métier et obtenir son accord écrit sur la tâche visée.
2. Constituer le jeu de tests avant tout développement, à partir de cas réels validés par ce propriétaire.
3. Choisir l’emplacement de la fonction dans l’outil existant, avant de choisir le modèle.
4. Mesurer le coût sur les cas difficiles du jeu, pas sur la moyenne, et fixer une limite de dépense mensuelle.
5. Désigner l’équipe de reprise et la faire travailler sur le système dès la première semaine.

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. Les métiers qu’elle mobilise sont décrits à part. Pour un projet déjà engagé, un audit IA permet de vérifier ces cinq points avant de remettre du budget.

Les erreurs qui condamnent un POC d’IA dès le départ sont de choisir le cas d’usage pour sa démonstration, de laisser la DSI seule, de repousser l’évaluation et de traiter le corpus comme un détail. Elles se décident toutes avant la première ligne de code.

• Choisir le cas le plus impressionnant plutôt que le plus utile. Il fait une belle démonstration et n’a souvent aucun utilisateur régulier.
• Lancer sans les métiers. Le projet devient un sujet technique, et personne ne le réclame quand il s’arrête.
• Repousser la question de la qualité à « après le POC ». Il n’y a alors aucun moyen de prouver que le POC a réussi.
• Sous-estimer les documents. Un POC sur dix fichiers propres ne dit rien d’un corpus de plusieurs milliers de documents hétérogènes : le corpus est le projet.