POC
Définition
Proof of Concept. Démonstration technique courte qui valide qu'une approche fonctionne avant d'investir dans un produit complet. Souvent isolé, sans interface ni mise en production.
À quoi sert un POC
Un POC (Proof Of Concept) valide qu'une approche technique est faisable avant de s'engager sur un produit complet. C'est un script isolé, parfois sans interface, qui prouve qu'on peut faire ce qu'on imagine : extraire des données d'un PDF complexe, intégrer une API peu documentée, faire répondre un LLM correctement sur un cas métier précis, atteindre une performance donnée sur un volume donné. Le livrable est rarement présentable à un client, mais il répond à une question technique précise par oui ou par non, avec des données à l'appui.
POC versus MVP
La confusion entre POC et MVP plombe beaucoup de projets. Un POC répond à la question "est-ce que ça marche techniquement ?". Un MVP répond à "est-ce que ça intéresse le marché ?". Les deux servent souvent sur un même projet, dans cet ordre : d'abord on valide la faisabilité technique du point bloquant, ensuite on construit la version commercialisable. Confondre les deux mène à présenter un POC à des clients qui s'attendent à un produit, ou à investir dans un MVP qui se heurte ensuite à un obstacle technique non anticipé.
Comment cadrer un POC
Un POC réussi commence par une question écrite et un critère de succès chiffré. Mauvaise question : "voir si l'IA peut faire ça". Bonne question : "sur ce jeu de 50 factures variées, l'extraction structurée a-t-elle plus de 90% de champs corrects sans intervention ?". On définit le jeu de test, on définit la métrique, on chronomètre le résultat. Sans critère de succès, le POC se prolonge indéfiniment et ne tranche jamais. Avec, on sait quand s'arrêter et quel chemin prendre pour la suite.
La durée et le coût
Un POC dure typiquement quelques jours à trois semaines, rarement plus. Au-delà, il dérive en projet à part entière sans en avoir les fondations. Le coût se justifie quand le risque technique est élevé et qu'un échec en production coûterait beaucoup plus cher : intégration d'un fournisseur exotique, traitement d'un volume massif, performance temps réel sur stack inhabituelle. Pour les cas standards (CRUD classique, page vitrine, e-commerce sur Shopify), un POC est superflu et on attaque directement la production.
Pourquoi on jette le code
Le code d'un POC privilégie la vitesse à la qualité : pas de tests, pas de gestion d'erreur, pas de logs, configuration en dur, dépendances bricolées. C'est volontaire, c'est efficace pour répondre à la question posée. Le piège : transformer ce code en V1 sous prétexte qu'il fonctionne déjà. La dette technique s'accumule, et les premières évolutions coûtent trois fois plus cher qu'elles ne devraient. On accepte de réécrire le POC proprement après validation, en s'appuyant sur les apprentissages pour bâtir des fondations saines.
Quand un POC n'est pas nécessaire
Tout projet ne mérite pas un POC. Si la stack est connue, les briques éprouvées, le métier classique, on saute cette étape. Lancer un POC "par sécurité" sur un site Next.js + Supabase + Stripe est une perte de temps et un signal d'incompétence. À l'inverse, on insiste sur un POC quand on intègre un LLM sur un cas métier sensible (extraction, classification), quand on attaque un fournisseur tiers peu documenté, ou quand on doit tenir une contrainte de performance qui sort du standard. Le POC n'est pas un rite, c'est un outil ponctuel.