Preuve de concept (POC)
Une preuve de concept (proof of concept, POC) est un exercice à petite échelle qui teste la faisabilité technique d'une idée, avant tout investissement dans un produit complet ou un MVP. Elle répond à une seule question, est-ce que cela peut être construit, et s'arrête là : elle n'a pas vocation à paraître finie, à tenir à l'échelle, ni à être montrée à de vrais clients.
Qu'est-ce qu'une preuve de concept ?
Une preuve de concept sert à lever un doute technique ou conceptuel précis avant qu'une équipe n'engage un vrai budget sur un projet. Elle est interne par nature : son public est l'équipe et ses parties prenantes, pas les utilisateurs finaux, et le code qui la porte est souvent jeté une fois la question tranchée. Une POC qui répond « oui, cette intégration fonctionne » ou « non, cette approche ne tient pas à l'échelle » a rempli son rôle, quelle que soit son apparence.
Ce que contient généralement une preuve de concept
- Une seule hypothèse à tester, formulée clairement avant de commencer.
- Du code minimal, souvent jetable, sans gestion d'erreurs, sans style ni cas limites traités.
- Un public strictement interne, jamais des utilisateurs finaux ou des clients payants.
- Un délai serré, de quelques jours à deux semaines.
- Une conclusion claire, go ou no-go, une fois le test réalisé.
Preuve de concept vs prototype vs MVP
| Aspect | Preuve de concept | Prototype | MVP |
|---|---|---|---|
| Objectif | Prouver la faisabilité technique | Tester l'apparence et le parcours | Tester la demande réelle du marché |
| Public | Équipe interne uniquement | Équipe interne ou utilisateurs test choisis | Clients réels, souvent payants |
| Niveau de finition | Jetable, aucune finition requise | Maquette cliquable ou visuelle, pas du code de production | Utilisable, à un niveau production sur son périmètre |
| Résultat type | Une décision go/no-go | Une direction de design validée | Des premiers utilisateurs et des données d'usage réelles |
Comment mener une preuve de concept
Commencez par écrire la seule question à laquelle la POC doit répondre, ainsi que les critères qui compteront comme un succès ou un échec ; sauter cette étape est ce qui transforme la plupart des POC en expérimentations sans fin. Construisez la chose la plus simple capable de répondre à cette question, en réutilisant les outils ou services existants les plus rapides à mettre en œuvre. Gardez un délai serré : une POC qui s'étire sur des mois n'en est plus une. Une fois le test réalisé, documentez honnêtement le résultat, y compris ce qui n'a pas fonctionné, et tranchez le go/no-go avant de passer au cadrage du vrai projet.
Pièges courants
L'erreur la plus fréquente est de sauter le cadrage complet du projet parce qu'« on a déjà fait une POC », alors que la POC a seulement prouvé une faisabilité, pas que la solution complète est bien spécifiée. Une autre est de sur-travailler la POC elle-même, en ajoutant de la finition ou une gestion de cas limites qui n'était jamais l'objectif. Une troisième, plus coûteuse, consiste à laisser une preuve de concept partir directement en production : n'ayant jamais été construite pour être maintenue ou sécurisée, elle devient de la dette technique dès que de vrais utilisateurs la touchent. Une POC n'est pas non plus l'endroit pour recueillir l'avis des parties prenantes sur l'apparence : cette question relève du prototype, une fois la faisabilité actée.
La preuve de concept chez BeBranded
Nous menons une preuve de concept dès qu'un projet repose sur une intégration non éprouvée ou un pari technique, avant de cadrer ou de chiffrer le reste du travail, dans le cadre du consulting que nous menons en amont des projets ambitieux. Le client repart avec une réponse claire sur la faisabilité avant qu'une seule journée ne soit facturée sur la construction complète.