22 juin 2026
Pourquoi j'ai arrêté de faire des POCs et ce que je fais à la place
Les POCs IA donnent souvent une illusion de vitesse. Ce qui transforme une idée en produit utile, c'est une expérimentation plus petite, branchée au réel, et pensée production dès le premier jour.
Le piège du POC qui rassure tout le monde
J'ai longtemps accepté les POCs comme une étape presque obligatoire des projets IA. Un sponsor veut voir si la technologie marche. Une équipe veut se faire la main. La direction veut limiter le risque avant d'investir. Sur le papier, c'est raisonnable. Dans la pratique, j'ai vu trop de POCs devenir des objets étranges : assez impressionnants pour alimenter une présentation, mais trop déconnectés du système réel pour devenir un produit.
Le piège est là. Un POC optimise pour la démonstration, pas pour l'usage. On choisit un jeu de données propre, un parcours heureux, une interface minimale, une intégration temporaire, parfois même un modèle plus cher ou plus lent que ce qui serait acceptable en production. Tout le monde sait que ce n'est pas encore industrialisé, mais personne ne sait exactement ce qu'il manque. Le projet a l'air d'avoir avancé, alors qu'il a surtout reporté les vraies questions : qui l'utilise, dans quel workflow, avec quelle donnée, quelle responsabilité, quel coût et quel niveau d'erreur acceptable ?
Pourquoi les POCs meurent avant le produit
La plupart des POCs ne meurent pas parce que le modèle est mauvais. Ils meurent parce que la preuve qu'ils apportent n'est pas celle dont l'organisation a besoin pour passer en production. Une démo prouve que quelque chose peut fonctionner dans un environnement contrôlé. Elle ne prouve pas que l'équipe saura l'opérer, que les utilisateurs lui feront confiance, que les exceptions sont traitées, que les données arrivent au bon format, que la latence est acceptable, ou que le budget d'inférence tient à l'échelle.
Un autre problème est politique. Le POC donne à chacun une raison de différer les décisions difficiles. On peut ne pas trancher sur le propriétaire métier, ne pas décider du niveau de validation humaine, ne pas connecter les systèmes internes, ne pas écrire d'evals sérieuses, ne pas parler de sécurité, parce que ce n'est encore qu'un test. Puis, le jour où le POC doit devenir un produit, toutes ces dettes arrivent en même temps. Le passage en production ressemble alors à un deuxième projet, plus long, plus cher, et moins excitant que la démo initiale.
Les signaux d'un vrai réflexe production
Aujourd'hui, je cherche des signaux très concrets avant de dire qu'un projet IA est prêt à avancer. Quelqu'un peut-il nommer le workflow exact que l'on améliore ? Peut-on décrire l'utilisateur réel, son moment d'usage, et ce qu'il fait si l'IA se trompe ? Existe-t-il une baseline, même imparfaite, sur le temps gagné, les erreurs, le volume ou la qualité ? A-t-on défini ce qui doit être loggé, revu, corrigé, mesuré ? Ces questions paraissent moins séduisantes qu'une démo, mais elles font la différence entre un jouet et un système.
Le meilleur signal, pour moi, est la présence d'une contrainte réelle dès le début. Une vraie donnée, un vrai compte utilisateur, un vrai processus de validation, un vrai coût cible, un vrai owner opérationnel. Pas tout le système final, évidemment. Mais au moins une partie du réel. Si l'expérimentation ne touche jamais la rugosité du terrain, elle apprend surtout à l'équipe à réussir dans un monde qui n'existe pas.
Ce que je fais à la place : production-first, mais plus petit
Je ne remplace pas le POC par un grand projet plus lourd. Je le remplace par une expérience plus petite, mais orientée production. Le périmètre est volontairement étroit : un workflow, un groupe d'utilisateurs, une source de données, un résultat mesurable. En revanche, les composants critiques sont réels dès le début : authentification si elle compte, logs si l'on devra investiguer, validation humaine si l'erreur est sensible, evals si la qualité doit tenir, déploiement réel si l'adoption dépend de l'accès quotidien.
Cette approche change la conversation. On ne demande plus seulement : est-ce que le modèle peut répondre ? On demande : est-ce que le système peut rendre service lundi matin sans créer plus de travail qu'il n'en retire ? C'est beaucoup plus modeste, mais beaucoup plus honnête. Une petite version en production, utilisée par cinq personnes sur un vrai cas, apprend davantage qu'une démonstration brillante devant cinquante personnes. Elle révèle les frictions, les non-dits, les exceptions et les moments où l'utilisateur a besoin de reprendre la main.
Deux exemples qui changent la trajectoire
Premier exemple : un assistant interne qui résume et classe des documents métier. Le réflexe POC serait de prendre vingt fichiers propres, d'afficher une réponse agréable, puis de conclure que le modèle comprend le sujet. Le réflexe production-first consiste plutôt à brancher une vraie source documentaire limitée, ajouter un écran de revue, conserver les sources citées, tracer les corrections humaines et mesurer le taux de reprise. Le résultat est moins spectaculaire en réunion, mais il répond tout de suite aux questions qui décideront de l'avenir du projet : confiance, contrôle, traçabilité et charge opérationnelle.
Deuxième exemple : un agent qui aide une équipe support à préparer des réponses. Une démo peut générer une réponse parfaite sur trois tickets simples. Une expérience utile doit intégrer les catégories réelles, les cas incomplets, les règles de ton, les escalades, les temps de réponse, et surtout le droit de dire je ne sais pas. Quand on construit cela dès la première itération, le projet devient moins magique et beaucoup plus solide. Si vous avez un POC IA qui tourne en rond, le bon prochain pas n'est peut-être pas une meilleure démo. C'est peut-être une version plus petite, plus réelle, et assez robuste pour être utilisée. C'est exactement le genre de cadrage que j'aime transformer en plan d'exécution concret.