Une preuve de concept, ou POC (de l'anglais proof of concept), est une petite expérience qui répond à une seule question : est-ce que ça peut marcher ? Elle se construit vite, souvent en quelques jours, et finit en général à la poubelle. Son seul résultat est un oui, un non, ou un « oui, mais » assorti de conditions.

Elle concerne toute personne sur le point de dépenser une vraie somme pour quelque chose d'incertain. Une marque qui demande à un développeur de relier sa boutique en ligne au logiciel de son entrepôt, une créatrice qui se demande si un outil peut envoyer automatiquement des fichiers à ses acheteurs, un fondateur dont l'application repose sur une technologie que personne dans l'équipe ne maîtrise. Avant la grosse facture, la POC vous dit si la partie risquée est tout simplement possible.

Qu'est-ce qu'une preuve de concept (POC) ?

Une preuve de concept est un test limité qui démontre la faisabilité d'une idée, d'une méthode ou d'une technologie précise. Elle se concentre sur la partie la plus difficile ou la plus incertaine d'un projet et laisse tout le reste de côté : design, sécurité, montée en charge, cas particuliers, expérience utilisateur. Si le mécanisme central fonctionne dans un cadre rudimentaire, le concept est prouvé. Sinon, vous avez économisé tout ce qui aurait été construit autour.

Trois traits distinguent une POC :

  • Elle répond à une question technique ou pratique, pas commerciale. « Peut-on synchroniser le stock entre ces deux systèmes chaque minute ? » est une question de POC. « Les clients vont-ils payer ? » n'en est pas une.
  • Elle est surtout interne. Les clients la voient rarement. Son public, c'est vous, votre équipe, votre développeur ou un investisseur.
  • Elle est jetable. Le code ou le montage n'est pas destiné à la mise en ligne. Sa valeur, c'est ce qu'elle vous apprend.

Ce qu'une POC n'est pas :

  • Pas un prototype. Le prototype montre à quoi ressemblera le produit et comment on s'y déplacera. La POC prouve que le moteur tourne, même sans carrosserie.
  • Pas un produit minimum viable. Le MVP est confié à de vrais utilisateurs pour tester la demande. La POC arrive plus tôt et teste la faisabilité.
  • Pas un pilote. Le pilote fait tourner une solution finie ou presque chez un vrai client, en conditions réelles.

Pour retenir l'ordre : la POC demande « est-ce que ça peut marcher ? », le prototype « comment ça marchera pour les gens ? », et le MVP « est-ce que les gens en veulent ? ».

Pourquoi c'est important

Les gros projets échouent souvent sur une seule hypothèse cachée. La POC la débusque tôt et lui donne un prix.

Imaginez une marque de bijoux qui traite 800 commandes par mois. Elle veut que sa boutique récupère en direct le stock de son fournisseur, pour que les articles épuisés disparaissent tout seuls. Une agence chiffre le projet à 6 000 euros et six semaines. Tout repose sur un point : le logiciel du fournisseur donne-t-il accès à ses stocks via une API, et ces données sont-elles fiables ?

La marque demande d'abord une POC : 3 jours, 850 euros. Le développeur écrit un petit script qui lit le stock de 20 produits toutes les 10 minutes et enregistre les résultats. Au bout de deux jours, la réponse tombe. Les données du fournisseur ne sont mises à jour qu'une fois par nuit, donc le stock « en direct » est impossible. Vendre des articles déjà partis aurait entraîné environ 30 commandes annulées par mois.

Sans POC, la marque aurait payé 6 000 euros pour une fonctionnalité incapable de tenir sa promesse. Avec, elle a dépensé 850 euros, opté pour une mise à jour nocturne complétée d'un petit stock de sécurité, et ramené le budget à 2 400 euros.

Comment ça marche

Une bonne POC est étroite, bornée dans le temps et jugée sur des critères fixés d'avance.

  • Formulez une seule question. Écrivez-la. « Un acheteur reçoit-il son lien de téléchargement moins d'une minute après avoir payé via ce prestataire ? » Une question par POC.
  • Définissez les critères de réussite et d'échec. Mesurables : « fonctionne sur 50 commandes test d'affilée », « réponse en moins de 2 secondes », « moins de 1 % d'erreurs ».
  • Fixez une durée et un budget. En général de 2 à 10 jours ouvrés. Si la réponse n'est pas claire à l'échéance, c'est déjà une réponse.
  • Construisez seulement la partie risquée. Pas de design, pas de comptes, pas d'écrans d'administration. Données de test, comptes bac à sable et faux produits suffisent.
  • Lancez le test et consignez les résultats. Des journaux, des captures et des chiffres, pas des impressions.
  • Rédigez une conclusion d'une page. Ce qui a marché, ce qui a échoué, dans quelles conditions, ce que coûterait une version propre, et quel est le risque suivant.
  • Jetez ou archivez le montage. Démarrez le vrai projet sur une base saine, en réutilisant les leçons, pas les raccourcis.

En développement logiciel, la POC est courante avant d'adopter un nouveau framework, de se connecter à un service externe ou de compter sur une fonction qu'un éditeur dit proposer. En e-commerce, elle est utile avant toute intégration ou automatisation sur mesure dont le reste du projet dépend.

Repères et exemples

  • Durée. La plupart des POC prennent de 2 à 10 jours ouvrés. Au-delà de trois semaines, c'est souvent devenu un projet déguisé.
  • Coût. Pour une petite entreprise qui travaille avec un freelance, de 500 à 3 000 euros est courant. Règle pratique : une POC coûte de 5 à 15 % du projet complet dont elle réduit le risque.
  • Résultat. Une POC qui échoue est une réussite si elle a coûté peu. Attendez-vous à ce qu'une bonne partie se termine par « non » ou « oui, avec des limites ».

Situations typiques :

  • Une créatrice veut que ses vidéos de formation se débloquent automatiquement après l'achat dans un outil précis. Une POC de deux jours avec un produit test vérifie toute la chaîne avant de le promettre à 500 élèves en attente.
  • Une marque envisage un configurateur qui affiche un aperçu de gravure. Une POC vérifie que l'aperçu s'affiche correctement sur mobile avant tout travail de design.
  • Un fondateur qui bâtit une application autour d'un service de reconnaissance vocale y passe 200 vrais enregistrements pour mesurer la précision dans un environnement bruyant.

Erreurs fréquentes

  • Tester la partie facile. Une POC qui prouve que la page de connexion fonctionne ne prouve rien. Visez l'hypothèse la plus risquée.
  • Pas de critères écrits. Sans eux, tout résultat partiel passe pour « prometteur » et le projet démarre quand même.
  • La laisser devenir la version en ligne. Le code d'une POC est écrit sans sécurité ni gestion d'erreurs. Le mettre en production crée un système fragile et de la dette technique.
  • Confondre faisabilité et demande. Prouver qu'on peut construire une chose ne dit rien sur l'envie de l'acheter.
  • Sauter le compte rendu. Ce qui reste dans la tête d'un seul développeur disparaît dès que le projet change de mains.

Bonnes pratiques

  • Demandez une POC avant tout gros devis sur mesure. Quand un freelance ou une agence propose une intégration, demandez quelle partie est incertaine et payez pour tester celle-là d'abord.
  • Limitez le périmètre à une question. Deux questions, c'est deux POC, ou une réponse confuse.
  • Utilisez des conditions réelles là où elles comptent. Vrais volumes de données, vrais téléphones, vrai compte bac à sable, pas des cas idéaux.
  • Clarifiez la propriété des résultats. Les notes, journaux et conclusions doivent vous appartenir, même si le code est jeté.
  • Décidez d'avance de la suite. « Si ça passe, on lance la phase un. Sinon, on bascule sur l'option B. » Cela garde la POC honnête.
  • Reportez le résultat dans votre feuille de route produit. Un concept prouvé devient un élément planifié avec une estimation réaliste.

Dans Roctify

Beaucoup de POC payées par les petits vendeurs servent à vérifier que plusieurs outils fonctionnent ensemble : une vitrine, un checkout, un prestataire de paiement, un outil d'envoi de fichiers. Roctify supprime une grande partie de cette incertitude, car ces briques sont livrées ensemble. La boutique, la page lien en bio, le checkout sur une seule page, Stripe, PayPal et le paiement à la livraison, ainsi que la livraison automatique des produits digitaux après paiement, sont intégrés et partagent un seul catalogue. Il n'y a pas de connexion entre outils séparés à prouver.

Vous pouvez tout de même mener un test de faisabilité rapide avec l'offre gratuite : créez un produit test, passez des commandes et vérifiez que le stock, les taxes, la livraison et l'envoi se comportent comme votre projet l'exige. Si votre projet suppose de relier Roctify à un autre système, comme un ERP ou un entrepôt, il s'agit d'une intégration sur mesure qui se discute dans l'offre Enterprise, et c'est précisément là qu'une petite POC écrite vaut la peine d'être faite en premier.

FAQ

Qui paie la preuve de concept ?

En général le client, puisque la POC protège son budget. Certaines agences proposent une POC courte à tarif réduit pour décrocher le projet complet. Dans tous les cas, fixez le prix, la durée et le livrable (une conclusion écrite) avant de commencer.

Une POC peut-elle devenir le produit final ?

Elle ne devrait pas. Une POC est construite vite, sans sécurité, sans tests ni gestion d'erreurs, pour répondre à une question. Une fois le concept prouvé, la vraie version se construit proprement, en réutilisant les leçons et non les raccourcis.

Faut-il une POC pour chaque projet ?

Non. Si tout le projet a déjà été réalisé maintes fois avec les mêmes outils, une POC ajoute un coût sans réduire le risque. Lancez-en une seulement quand une partie clé est nouvelle, incertaine ou dépend d'un système extérieur que vous ne maîtrisez pas.