Du POC à la production : pourquoi les prototypes IA restent au tiroir

La démo s'est bien passée. Le modèle a répondu aux cinq questions que tout le monde avait préparées, la salle a hoché la tête, et quelqu'un a dit « on le déploie ». Six mois plus tard, le prototype tourne toujours sur un ordinateur portable, et la personne qui l'a construit est passée à autre chose.

Pendant ce temps, le dirigeant qui l'a vu marcher demande pourquoi ce n'est toujours pas en ligne. Nous entendons souvent cette histoire lors des premiers appels sur l'IA. Le problème vient rarement du modèle. Il vient de tout ce que la démo n'avait pas à faire.

Un POC IA répond à une seule question : est-ce que ça peut marcher. Il a le droit de tricher. Il tourne sur vingt documents propres, avec un seul utilisateur, sans connexion, et une clé d'API collée dans un fichier de configuration.

Les ennuis commencent quand on prend la démo pour l'essentiel du produit. La démo représente peut-être un dixième du travail. Le reste, ce sont les flux de données, les tests, les droits d'accès, les logs et les alertes de facturation.

Rien de tout cela ne se voit en démo, et c'est pourtant ce qui décide si le produit part en production.

Des données réelles, pas un dossier trié à la main

La démo utilisait un dossier que quelqu'un avait trié à la main. En production, le modèle reçoit ce que vos systèmes contiennent vraiment : des PDF scannés, des doublons, trois versions du même contrat, un CRM dont la moitié des champs sont vides.

Le modèle qui semblait précis sur des données propres se met à deviner. Les réponses dérivent, les sources disparaissent, et les utilisateurs cessent de lui faire confiance après la deuxième erreur. Ils vous le disent rarement : ils reviennent simplement à l'ancienne méthode.

Le premier chantier de production n'a donc rien de spectaculaire. Trouver où vivent les données, qui en est responsable, à quelle fréquence elles changent et comment elles arrivent jusqu'au modèle. Sur beaucoup de projets, cela prend plus de temps que la partie IA, et il faut le prévoir ainsi dès le premier jour.

Évaluation : personne ne sait dire si c'est bon

Demandez à l'équipe d'un prototype à l'arrêt quel est son taux de réponses justes. La réponse honnête est souvent « ça avait l'air bien pendant les tests ». Personne ne peut valider un projet là-dessus.

Un produit a besoin d'un jeu d'évaluation : quelques centaines de cas réels, avec la réponse que donnerait une personne compétente. Partez des questions posées par les vrais utilisateurs pendant le pilote, pas de celles que l'équipe avait préparées pour la démo : c'est sur celles-là que la démo a été ajustée.

Chaque changement de prompt, de modèle ou de données passe par ce jeu d'évaluation. Sans lui, chaque correction casse quelque chose, et vous l'apprenez par un client.

Il oblige aussi à une discussion que la démo a évitée : quel taux d'erreur est acceptable pour cette tâche. Un brouillon d'e-mail faux une fois sur dix reste utile. Une décision de remboursement fausse une fois sur dix devient un risque.

Ce que la démo n'a jamais eu à gérer

Personne ne la surveille

Un prototype n'a pas de suivi, parce que personne n'en dépend. En production, quelqu'un en dépendra, et la première mauvaise réponse vous arrivera sous forme de capture d'écran dans un ticket de support, sans aucun log pour l'expliquer. Il vous faut des logs de ce que le modèle a reçu et renvoyé, des alertes quand la latence ou le taux d'erreur bougent, et un moyen de rejouer une mauvaise réponse pour la comprendre.

Le modèle que vous avez testé va aussi changer sous vos pieds : les fournisseurs retirent et mettent à jour leurs versions, et sans jeu d'évaluation vous ne verrez pas ce qui a cassé.

La facture absente de la démo

Une démo traite quelques dizaines de requêtes par jour. Mettez-la entre les mains de tous les salariés, ou sur chaque demande client, et vous multipliez ce volume par mille, avec des contextes plus longs que tout ce que la démo a vu. Le cache, des modèles plus petits pour les étapes simples et des limites par utilisateur sont des choix de conception, et ils coûtent moins cher avant le lancement qu'après la première facture.

Avant le lancement, estimez le coût mensuel au volume de production, à partir de la taille réelle des requêtes, pas de la facture de la démo.

Le juridique posera des questions auxquelles la démo ne sait pas répondre

Avant le lancement, quelqu'un doit répondre à trois questions :

• Qui peut voir quels documents à travers l'assistant, et l'assistant respecte-t-il les droits d'accès de chaque source.
• Où sont stockés les prompts et les réponses, combien de temps, et dans quel pays.
• Un utilisateur peut-il faire révéler au modèle ce qu'il ne devrait pas, par injection de prompt ou par une recherche mal bornée.

Vos équipes juridique et sécurité poseront ces questions. Le prototype n'a pas de réponse, parce qu'il n'en a jamais eu besoin. Décidez d'abord de l'hébergement (en Europe, sur votre cloud ou sur site), car il limite les modèles que vous pouvez utiliser.

Le responsable : quelqu'un doit le faire tourner en production

C'est la raison la moins technique, et celle qui enterre le plus de prototypes qui fonctionnent. Le prototype a été construit par une équipe innovation, un stagiaire ou une agence au forfait. Quand il marche, personne n'est désigné pour le faire tourner.

Un produit en production a besoin d'un responsable : quelqu'un qui lit les logs, met à jour le jeu d'évaluation, gère la prochaine hausse de prix du fournisseur de modèle et décide quoi améliorer. Sans cette personne, le système se dégrade peu à peu, et les équipes cessent de l'utiliser sans rien dire.

C'est aussi là qu'échouent la plupart des passations. Ceux qui ont construit la démo partent, ceux qui en héritent n'ont pas fait les choix, et le premier incident prend des semaines à comprendre. Nous travaillons dans l'autre sens : les personnes présentes au premier appel construisent le produit et le mettent en production, puis le font tourner après le lancement ou le transmettent proprement à votre équipe, avec la documentation et le jeu d'évaluation qui le rendent maintenable.

Que faire d'un POC IA que vous avez déjà

Avant d'écrire une ligne de code de plus, transmettez ces six questions à l'équipe qui l'a construit :

La plupart des prototypes à l'arrêt n'ont pas besoin d'être reconstruits. Il leur faut un cadrage écrit qui nomme ce qui manque entre la démo et le produit, et une réponse honnête sur l'intérêt du cas d'usage. Parfois il n'y en a pas : le volume est trop faible, les données n'existent pas encore, ou un outil plus simple fait l'affaire.

C'est aussi une réponse utile, et elle coûte moins cher avant le deuxième budget qu'après. Quand le cas d'usage en vaut la peine, le chemin est court : un cadrage qui dit ce que nous construisons et ce que nous ne construisons pas, une démo chaque semaine, et une première version en production 3 à 6 semaines après le lancement du projet.

Si vous avez un prototype au tiroir, apportez-le à un audit gratuit : un enregistrement de la démo suffit, le dépôt de code et un échantillon de données si vous pouvez les partager. Une heure sur votre activité, puis un document court qui dit ce qu'il faut pour le mettre en production, ou pourquoi il doit rester où il est.