Lexique · produit
POC
Aussi appelé : Proof of Concept, preuve de concept, proof-of-concept.
Proof of Concept — démonstration technique limitée qui prouve qu'une idée est réalisable techniquement, sans chercher à délivrer de la valeur utilisateur.
Un POC (Proof of Concept) est un mini-projet dont l'unique but est de lever un doute technique. Avant d'investir dans un produit complet, on veut s'assurer qu'une brique critique fonctionne : tel algorithme peut-il traiter ce volume de données ? telle intégration est-elle réalisable ? telle architecture tient-elle la charge ?
Le POC ne sera pas livré à des utilisateurs. Il vit le temps de l'expérimentation, dans un environnement contrôlé, parfois sur une seule fonctionnalité. Une fois le doute levé ("oui, c'est faisable" ou "non, il faut une autre approche"), il sert souvent à éclairer un GO/NO-GO sur un projet plus large.
Le POC se distingue du MVP (qui, lui, est livré à de vrais utilisateurs pour valider la demande marché) et du prototype (qui valide l'expérience utilisateur via un design cliquable). Confondre les trois est une cause classique de dérapage budgétaire : on commande un "POC" en croyant obtenir un produit utilisable.
Notre prestation
Direction technique : CTPO, CTO temps partagé, cadrage projet
On porte la fonction CTO / CTPO à vos côtés, le temps qu'il faut — cadrage de projet, recrutement, arbitrages d'architecture.
Pour aller plus loin
MVP, POC, prototype : comment lancer votre projet digital sans vous ruiner
Le piège du "on construit tout d'un coup" Vous avez une idée de produit digital. Une application mobile, une plateforme SaaS, un outil innovant pour votre secteur. Excité par le potentiel, vous consultez des prestataires. Et là, douche froide : "Comptez entre 80 000 € et 150 000 € pour la version complète. Délai : 8 à 12 mois." Panique. Vous n'avez pas ce budget. Ou alors, vous l'avez mais l'idée de tout miser sur une idée non validée par le marché vous empêche de dormir. Et si les utilisateur
Questions fréquentes
Quelle est la durée typique d'un POC ?
Entre une et quatre semaines pour la grande majorité des cas. Un POC qui dépasse un mois est généralement mal cadré : soit la question technique posée est trop large (et il faut la découper), soit on a glissé vers un développement de prototype ou de MVP sans s'en rendre compte. Un bon POC tient en quelques jours-homme parce que sa portée est strictement limitée.
Combien coûte un POC ?
Entre 3 000 € et 15 000 € selon la complexité technique. Les variables principales sont : l'accès aux données réelles (un POC sur données synthétiques coûte beaucoup moins cher qu'un POC qui nécessite une connexion à un SI client), le nombre d'intégrations externes, et l'environnement cible (un POC sur du cloud public est moins coûteux qu'un POC à déployer sur une infrastructure on-premise spécifique).
Le code produit pendant un POC est-il réutilisable pour la suite ?
Rarement, et c'est volontaire. Un POC est codé pour aller vite et lever un doute, pas pour être maintenu. Tests minimaux, pas de gestion fine des erreurs, peu de documentation, structure jetable. Vouloir réutiliser ce code en production conduit presque systématiquement à de la dette technique. La règle saine : on garde les apprentissages, pas le code.
POC, prototype et MVP : comment choisir entre les trois ?
POC pour valider la faisabilité technique d'une brique (« est-ce que c'est possible ? »). Prototype pour valider une intention de design ou un parcours utilisateur (« est-ce que ça se manipule bien ? »). MVP pour valider la demande marché en confrontant un produit minimal à de vrais utilisateurs (« est-ce que des gens en veulent ? »). Les trois peuvent s'enchaîner ou s'utiliser indépendamment selon le risque principal de votre projet.
Faut-il faire un POC sur tous les projets ?
Non. Sur des stacks éprouvées avec des intégrations standardisées, le POC est du temps perdu : tout le monde sait déjà que c'est faisable. On démarre directement sur un MVP ou un prototype selon la nature du doute. Le POC se justifie quand il y a une vraie incertitude technique — algorithme spécifique, montée en charge à valider, intégration avec un système peu documenté, brique d'intelligence artificielle dont on ne sait pas si elle tiendra ses performances.