Du POC à la production : sortir un projet IA du purgatoire

Le purgatoire des POC

Le purgatoire, c'est cet entre-deux où un prototype fonctionne mais n'a jamais le droit de passer en vrai. Il tourne sur un jeu de données propre, sur trois cas choisis, devant un public conquis. Puis vient la question qui coince : « on le met en prod quand ? » Et là, souvent, plus personne ne sait qui possède le projet, où tournent les données, ce que ça coûtera par mois, ni comment on saura qu'il déraille. Le POC n'a pas échoué techniquement. Il a été pensé comme une démo, pas comme un système.

La cause n'est pas la techno

Quand un projet reste coincé, on accuse le modèle, la donnée « pas assez mûre », le fournisseur. C'est rarement ça. La techno du POC est le plus souvent suffisante. Ce qui manque, ce sont quatre choses invisibles en démo mais décisives pour la mise en prod.

• Les données : le POC tournait sur un extrait nettoyé à la main. En vrai, vos données sont dispersées, incomplètes, mal étiquetées, et personne n'a prévu qui les tient à jour. C'est le point que je vérifie en premier (vos données sont-elles prêtes pour l'IA).
• L'adoption : on n'a pas demandé aux gens qui utiliseront l'outil ce dont ils avaient besoin. Le résultat est correct, mais pas dans leur flux de travail.
• La propriété : le POC était le bébé d'une personne motivée. Sans propriétaire métier clair en production, il n'a personne pour le porter, le corriger, l'améliorer.
• Le coût de run : personne n'a estimé la facture mensuelle à l'échelle réelle. On découvre le prix quand il est trop tard pour reculer.

Cadrer un POC industrialisable dès le départ

Un POC industrialisable n'est pas un POC plus gros. C'est un POC plus honnête. Je le cadre sur un cas d'usage réel, avec de vraies données (même en petit), le vrai utilisateur dans la boucle, et une définition chiffrée de « ça marche ». L'objectif n'est pas de prouver que l'IA sait faire quelque chose d'impressionnant, c'est de prouver, sur un périmètre minuscule, que la chaîne complète tient : donnée, modèle, action, utilisateur, coût. C'est le point de départ de ma méthode : mieux vaut un cas traité de bout en bout, y compris les cas moches, qu'une démo qui gère dix cas mais seulement quand tout est propre.

Les critères de succès à fixer avant de coder

Avant d'écrire une ligne, je fais mettre par écrit ce qui déclenchera un « oui, on industrialise ». Pas un ressenti en réunion : un seuil. Sans ça, le POC réussit ou échoue selon l'humeur du jour, et c'est exactement comme ça qu'on reste au purgatoire.

• La qualité minimale acceptable, mesurée sur des exemples réels : quel taux de bonnes réponses, quelle marge d'erreur tolérée, sur quels cas.
• Le gain visé, chiffré : temps gagné, tickets évités, délai réduit. Un ordre de grandeur suffit, mais il doit exister.
• Le coût de run maximal par mois, pour que le gain reste un gain.
• Le propriétaire métier : qui décide, qui utilise, qui maintient une fois en prod.
• La condition d'arrêt : à partir de quand on décide que ça n'en vaut pas la peine, sans que ce soit vécu comme un drame.

Ce qui sépare une démo d'un système de prod

Une démo montre le meilleur cas une fois. La production tient les pires cas mille fois, la nuit, sans vous.

• Les évaluations : un jeu de tests sur vos vrais cas, qui dit si une nouvelle version est meilleure ou pire, chiffres à l'appui. Sans elles, chaque changement est un pari (mesurer un agent IA en production).
• Les garde-fous : ce qui empêche le système de faire une bêtise irréversible, valide les actions sensibles et échoue proprement. C'est le cœur de la fiabilité en production.
• L'observabilité : savoir en continu ce que le système répond, ce qu'il coûte, où il se trompe. Un système que vous ne pouvez pas observer, vous ne pouvez pas lui faire confiance.

Le coût de run à estimer avant de valider

Le coût de run, c'est ce que le système coûte chaque mois une fois en marche : appels au modèle, hébergement, stockage, maintenance. En démo il est invisible, parce que le volume est ridicule. À l'échelle réelle, il peut transformer un projet rentable en gouffre. Je l'estime toujours avant de valider un POC : volume attendu multiplié par le coût unitaire observé, avec de la marge. La bonne nouvelle, c'est qu'il y a presque toujours du gras à couper : sur une facture LLM auditée, je vise 30 à 70% d'économies à qualité égale, en choisissant le bon modèle par tâche, en supprimant les appels inutiles et en mettant du cache. Mais ça se pense au cadrage, pas en catastrophe six mois plus tard.

L'adoption : le projet qui marche mais que personne n'utilise

C'est l'échec le plus frustrant : le système fonctionne, les chiffres sont bons, l'usage reste à zéro. Presque toujours, c'est qu'on a livré un outil de plus au lieu de s'insérer dans le geste métier existant. Personne n'ouvre un nouvel onglet pour gagner trente secondes. L'IA doit venir aux gens, dans l'outil qu'ils utilisent déjà, au moment où ils en ont besoin. Ça se prépare dès le POC : impliquer les futurs utilisateurs, livrer là où ils travaillent, viser un gain ressenti tout de suite. Une réponse sourcée en 2 secondes, avec 70% de recherche en moins, un utilisateur l'adopte sans qu'on ait à le convaincre. C'est ce type de gain concret que je cherche à rendre visible dans mes réalisations.

Une trajectoire en étapes

• Cadrage : un cas d'usage, des critères de succès chiffrés, un propriétaire métier, un coût de run estimé. Rien de codé encore.
• POC honnête : la chaîne complète sur un périmètre minuscule, vraies données, vrai utilisateur, avec des évaluations dès le premier jour.
• Décision : on compare aux critères écrits au départ. Oui, non, ou on ajuste. Pas de zone grise.
• Pilote : mise en prod sur un périmètre réduit, avec garde-fous et observabilité, sur de vrais utilisateurs.
• Industrialisation : on étend une fois que le pilote tient, en gardant l'œil sur le coût et sur l'usage.

C'est la trajectoire que je propose en format court avec un POC IA cadré pour la production : quelques semaines pour savoir si un cas mérite d'être industrialisé, au lieu d'engager six mois à l'aveugle. Un POC réussi n'est pas celui qui impressionne en réunion. C'est celui dont on sait déjà, à la fin, comment il passera en prod.