Le POC IA marchait : pourquoi il ne passe pas en production
Un POC IA validé qui stagne depuis six mois n'est pas un problème de modèle. Voici les six murs que le prototype n'a jamais mesurés, le diagnostic à mener en cinq jours et les trois issues possibles.
title: "Le POC IA marchait : pourquoi il ne passe pas en production" seoTitle: "Faire passer un POC IA en production" description: "Un POC IA validé qui stagne depuis six mois n'est pas un problème de modèle. Voici les six murs que le prototype n'a jamais mesurés, le diagnostic à mener en cinq jours et les trois issues possibles." seoDescription: "Un POC IA validé qui stagne depuis six mois : les six murs que le prototype n'a pas mesurés et les trois issues possibles." date: "2026-09-10" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "développement"] category: "IA & Automatisation" keywords: ["POC IA production", "industrialiser un POC LLM", "prototype IA bloqué", "passage en production IA", "dette technique LLM", "audit projet IA", "coût production LLM", "MVP IA", "reprise projet IA"]
Le POC a été validé en mars. Le comité de direction a vu la démo, applaudi, débloqué une ligne budgétaire. Nous sommes en septembre, la fonctionnalité n'est toujours pas devant un client, et personne dans l'équipe ne sait dire s'il reste trois semaines ou six mois de travail. Chaque point d'avancement produit la même phrase : « techniquement ça marche, il reste juste à… ». Le « juste à » change de contenu toutes les deux semaines.
Ce scénario n'a rien d'exceptionnel. C'est même la situation la plus courante parmi les projets IA qu'on nous demande de reprendre, devant la facture qui explose et devant l'agent qui hallucine. Et l'erreur de diagnostic la plus fréquente consiste à croire qu'il s'agit d'un problème de modèle, de prompt ou de fournisseur. Ce n'en est presque jamais un. Le POC n'a pas échoué : il a parfaitement répondu à la question qu'on lui posait, qui n'était pas celle de la production.
Le POC a répondu à une autre question
Un prototype démontre la faisabilité : le modèle est-il capable, sur un exemple représentatif, de produire le type de sortie qu'on attend ? La réponse est aujourd'hui presque toujours oui, et c'est précisément ce qui rend l'exercice trompeur. Depuis que les modèles généralistes atteignent un niveau correct sur la plupart des tâches textuelles, la phase de faisabilité ne filtre plus rien. Elle ne coûte que quelques jours et elle réussit dans neuf cas sur dix.
La production pose une question entièrement différente : ce système peut-il traiter le volume réel, sur des données réelles, à un coût connu, avec une qualité mesurée, un comportement défini en cas d'échec, et une équipe capable de le maintenir dans dix-huit mois ? Aucune de ces six dimensions n'est évaluée par un POC. Le prototype ne les a pas ratées, il ne les a pas regardées.
D'où l'asymétrie de calendrier qui surprend tout le monde : trois semaines pour le POC, six à neuf mois pour la mise en production. Ce n'est pas un échec de l'équipe, c'est la répartition normale de l'effort. Le problème, c'est qu'elle n'a été annoncée à personne, et qu'on a promis une date à partir du seul chiffre connu — celui du POC.
Les six murs que le prototype n'a pas mesurés
La donnée de démo n'est pas la donnée réelle
Le POC tournait sur vingt documents choisis, propres, en français, au même format. La production apporte 40 000 documents dont un tiers sont des PDF scannés, un dixième contiennent des tableaux que l'extraction transforme en bouillie, quelques centaines sont en anglais ou en néerlandais, et un nombre non négligeable sont des doublons ou des versions obsolètes que personne n'a jamais purgées.
C'est le mur le plus coûteux et le plus systématiquement sous-estimé. Sur une reprise de projet type, la préparation des données représente entre 30 et 50 % de l'effort total de mise en production, et elle ne ressemble en rien à de l'IA : c'est du nettoyage, de la déduplication, du typage, des règles métier écrites à la main. Aucune démo ne l'exhibe, parce qu'aucune démo n'en a besoin.
Le coût unitaire n'a jamais été calculé
Le POC a consommé pour 40 euros d'API sur trois semaines. Personne n'en a déduit un coût par requête, parce que personne n'a compté les requêtes. En production, la même fonctionnalité passe par une phase de reformulation, une recherche, un appel principal, parfois une vérification : quatre à six appels pour une réponse utilisateur, sur un contexte dix fois plus long que celui de la démo.
Le calcul à faire tient en une ligne et se fait avant d'écrire du code : coût moyen par interaction multiplié par le volume mensuel attendu, divisé par la marge de la fonctionnalité. S'il n'est pas soutenable, aucune optimisation ultérieure ne le rendra soutenable — les leviers de réduction existent, ils font gagner un facteur 3 à 10, pas un facteur 100. Nous avons détaillé ces leviers dans d'où vient la facture d'API LLM et comment la récupérer ; l'important ici est que le chiffre doit exister avant l'industrialisation, pas après le premier relevé.
Rien ne dit ce qu'est une bonne réponse
Demandez à l'équipe le taux de réussite actuel. Si la réponse est « ça marche bien » ou « à peu près 8 fois sur 10 », il n'y a pas d'instrument de mesure, donc pas de moyen de savoir si un changement améliore ou dégrade le système. Toute modification devient un pari, et l'équipe finit par ne plus rien toucher — ce qui explique une bonne partie des projets figés depuis quatre mois.
Un jeu d'évaluation, même modeste — 80 à 150 cas issus de vos données réelles, avec la sortie attendue — transforme la situation en quelques jours. C'est le sujet de construire l'évaluation qui manque à votre agent, et c'est la première chose que nous mettons en place sur une reprise, avant toute optimisation, parce que sans elle on ne sait même pas dire si le projet est proche ou loin du but.
La latence n'entre pas dans le parcours utilisateur
Une chaîne de cinq appels séquentiels met entre huit et vingt secondes à produire une réponse. En démo, on attend et on commente. Dans un formulaire de support, un conseiller au téléphone ou une page produit, huit secondes est un abandon.
Deux conséquences en découlent, et toutes deux sont architecturales : soit on réduit la chaîne, soit on rend le traitement asynchrone — file d'attente, notification, réponse différée. La seconde option change l'interface, le modèle de données et parfois le processus métier. Elle ne se rajoute pas en fin de projet, ce qui est pourtant le moment où on la découvre.
Les cas d'échec n'ont pas de traitement défini
Que se passe-t-il quand le modèle répond à côté ? Quand l'API renvoie une erreur ou dépasse le délai ? Quand le document d'entrée est illisible ? Quand la réponse est plausible mais fausse ?
Dans un POC : rien, on relance. En production, chacun de ces cas exige une décision produit, pas technique. Faut-il afficher une réponse dégradée, basculer vers un humain, ne rien afficher ? Qui voit passer les cas rejetés ? Combien de temps garde-t-on les échanges, et pour quelle finalité — question qui devient une obligation dès que des données personnelles entrent dans le contexte du modèle.
Ces décisions représentent souvent la moitié des tickets d'industrialisation, et aucune ne se prend dans un sprint technique : il faut le métier dans la pièce.
Personne ne possède vraiment le code
Le POC a été écrit vite, souvent par une personne, parfois par un prestataire, parfois dans un notebook. Il n'a ni tests, ni journalisation, ni gestion de configuration, ni versionnement des prompts. Les clés d'API sont dans le code. Le comportement dépend d'un fichier local que personne n'a commité.
Ce n'est pas un reproche : un prototype doit être écrit vite, c'est sa raison d'être. Le problème apparaît quand on décide de le promouvoir tel quel, parce que « ça marche déjà ». Cette décision-là est celle qui coûte le plus cher sur douze mois, et elle rejoint un travers plus général du développement produit que nous avons documenté dans les erreurs qui coûtent cher en développement SaaS.
Un diagnostic tient en cinq jours
Avant de décider quoi que ce soit, il faut remplacer les impressions par des chiffres. Cet audit ne demande pas plus d'une semaine, y compris sur un projet dont personne ne maîtrise plus l'historique.
Jour 1 — la question métier. Quelle décision ou quelle action cette fonctionnalité remplace-t-elle, et que coûte aujourd'hui cette action sans IA ? Si personne ne sait répondre, le projet n'a pas de critère de succès et le reste de l'audit est inutile.
Jour 2 — le volume et le coût. Volume mensuel réel attendu, nombre d'appels par interaction, taille moyenne du contexte, coût unitaire, coût mensuel projeté à six mois. Un tableur suffit.
Jour 3 — la qualité. Constituer 80 cas réels, faire tourner le système existant dessus, noter les sorties. On obtient un taux de réussite mesuré, presque toujours dix à vingt points sous l'estimation de l'équipe, et surtout la typologie des échecs.
Jour 4 — l'existant technique. Ce qui est réutilisable, ce qui est jetable. Le critère est simple : le code a-t-il des frontières claires — un point d'entrée, une fonction d'appel au modèle, un endroit unique où vivent les prompts ? Si oui, on garde le cœur. Sinon, on garde les prompts et l'apprentissage, on jette le reste.
Jour 5 — les décisions produit en attente. Lister les cas d'échec sans réponse, la latence acceptable, la politique de conservation des données. Les mettre sur la table du métier, pas de la technique.
À la fin de la semaine, on dispose de quatre chiffres — coût unitaire, coût mensuel, taux de réussite mesuré, part du code réutilisable — et d'une liste de décisions à prendre. C'est suffisant pour arbitrer.
Trois issues honnêtes
Réduire le périmètre. C'est l'issue la plus fréquente et la plus efficace. Le POC visait « l'assistant qui traite toutes les demandes clients ». Les données montrent que trois types de demandes représentent 60 % du volume et que le système les traite déjà à 92 %. On livre ces trois-là, avec un basculement vers l'humain pour tout le reste, en six à huit semaines. La valeur arrive, le système apprend en conditions réelles, et le périmètre s'élargit sur des chiffres plutôt que sur des intentions.
Reconstruire le socle en gardant l'acquis. Quand le coût unitaire est tenable et la qualité mesurée correcte, mais que le code est un prototype, on reconstruit l'ossature autour de ce qui a été appris : prompts versionnés, jeu d'évaluation en intégration continue, journalisation de chaque appel avec son coût, gestion des erreurs, tests. Compter six à dix semaines. Ce n'est pas repartir de zéro : les prompts, le découpage et la connaissance des cas limites sont l'essentiel de la valeur du POC, et ils sont conservés.
Arrêter. Si le coût unitaire dépasse la valeur produite d'un facteur supérieur à trois, si le taux de réussite mesuré plafonne à 60 % sur un usage qui en exige 95, si la donnée d'entrée n'existe pas dans un état exploitable, mieux vaut arrêter maintenant. Un projet IA arrêté au bout de six mois avec un rapport clair coûte infiniment moins cher qu'un projet maintenu en vie deux ans par obligation politique. Cette issue est rare mais elle doit rester sur la table, faute de quoi l'audit n'est pas un audit.
Le socle minimum d'une fonctionnalité LLM en production
Quelle que soit l'issue retenue, la liste suivante définit le seuil en dessous duquel on n'expose rien à un utilisateur final. Elle est courte volontairement.
Un jeu d'évaluation d'au moins 80 cas réels, exécuté automatiquement à chaque modification de prompt ou de modèle. Un journal de chaque appel : entrée, sortie, modèle, jetons consommés, latence, coût — sans quoi aucun diagnostic n'est possible après coup. Les prompts hors du code applicatif, versionnés, modifiables sans déploiement. Un plafond de dépense par jour et par utilisateur, avec alerte. Un comportement défini pour l'échec, l'erreur d'API et le dépassement de délai. Enfin, une porte de sortie : la capacité de changer de fournisseur de modèle sans réécrire l'application, ce qui suppose simplement que les appels passent par une couche à vous.
Rien là-dedans ne relève de la recherche. C'est de l'ingénierie logicielle ordinaire appliquée à un composant non déterministe, et c'est exactement ce qui manque à un prototype — non par négligence, mais parce que ce n'était pas son travail.
Par où commencer
Cette semaine, produisez les quatre chiffres du diagnostic : coût par interaction, coût mensuel projeté, taux de réussite mesuré sur 80 cas réels, part du code réutilisable. Ils prennent cinq jours à obtenir et ils changent la nature de la conversation, parce qu'ils remplacent « il reste juste à » par un arbitrage documenté.
Puis choisissez explicitement une des trois issues, avec une date. L'état le plus coûteux n'est aucun des trois : c'est celui où le projet reste ouvert sans décision, consomme un peu d'attention chaque semaine et n'arrive jamais devant un utilisateur. Six mois de ce régime coûtent plus cher qu'une reconstruction assumée, et laissent l'équipe convaincue que l'IA ne marche pas — alors que c'est le passage à l'échelle qui n'avait jamais été financé.
Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.
Prêt à lancer votre projet ?
Transformez vos idées en réalité avec un développeur passionné par la performance et le SEO. Discutons de votre projet dès aujourd'hui.
Articles similaires
Votre agent IA marche 8 fois sur 10 : construire l'évaluation qui manque
Votre facture d'API LLM a triplé : d'où vient l'argent et comment le récupérer
