POC par ici, POC par là… Dans bien des entreprises, il semble que le Proof of Concept soit depuis longtemps devenu un réflexe pavlovien : dès qu’un sujet digital pointe le bout de son nez, hop ! On lance un POC. Et tant pis si personne ne sait vraiment ce qu’on cherche à valider, ni ce que l’on fera ensuite.
Le POC est un outil précieux, à condition qu’on le traite comme tel : il s’agit d’un dispositif d’expérimentation au service d’une décision.
À force d’en faire la panacée de toute approche d’innovation, on a fini par perdre de vue l’essentiel : parfois, il ne faut pas faire de POC. Oui, vous avez bien lu.
Le POC, à quoi ça sert vraiment ?
Le POC — Proof of Concept — est une expérimentation cadrée et frugale visant à lever les incertitudes clés sur une opportunité digitale pour se mettre en capacité de décider de lancer un projet ou pas. Le POC alimente le GO / NOGO. Il s’agit de dépenser un peu pour se convaincre d’y aller en investissant vraiment, ou pas ; il doit répondre à une seule question : est-ce que cela vaut le coup d’y aller ? Concrètement, il s’agit de rassembler les éléments de décision nécessaires et suffisants pour démarrer un vrai projet ou abandonner proprement l’opportunité. Rien de plus, rien de moins.
On peut vouloir s’assurer de : la faisabilité technique (ça marche ?), la faisabilité fonctionnelle et l’acceptabilité (les utilisateurs s’en servent ?), la valeur créée (ça rapporte quelque chose : économies, efficacité, satisfaction…).
Le terme POC est l’acception la plus large : il vise à démontrer la faisabilité technique et fonctionnelle, la viabilité d’une idée, d’un concept ou d’une solution dans des conditions représentatives. Selon le type d’incertitude à lever, des variantes existent :
- Le Proof of Value (PoV) se concentre sur la démonstration de la valeur métier et des bénéfices tangibles de la solution et déroule souvent des scénarios réels pour quantifier les gains, les économies
- Le Proof of Technology (PoT) se concentre sur la solidité des bases technologiques de la solution et de son intégration dans l’environnement technique et vise à démontrer le bon fonctionnement des technologies sous-jacentes ou des composants essentiels d’une solution.
Et la complexité des objets fonctionnels et techniques mis en œuvre sont variables :
- La maquette : simule l’apparence et l’ergonomie de la solution finale sans inclure toutes les fonctionnalités techniques.
- Le prototype : inclut des éléments techniques et permet de recueillir des retours sur les aspects fonctionnels de la solution.
- Le pilote : version incluant toutes les fonctionnalités principales pour être utilisé en conditions réelles, déployée à petite échelle.
- Le MVP : une première version industrialisable des fonctionnalités clés, minimaliste, mais utilisable.
Le POC est donc un outil de design, pas une ligne de production. Il est temporaire, ciblé, frugal. Il sert à décider, pas à durer.
Le POC est utile… sauf quand il ne l’est pas
Le vrai problème n’est pas le POC lui-même, mais l’usage compulsif qu’on en fait.
Le POC “alibi”
Faire un POC pour prouver qu’on “fait de l’innovation”, pour occuper une équipe en attente de budget, pour flatter une startup… Ou pire encore : faire un POC alors qu’on a déjà décidé qu’on voulait (ou qu’on ne voulait pas) la solution.
Le POC “perdu d’avance”
Un POC mal cadré, sans hypothèses claires, sans critères de décision précis, sans sponsor réel, et sans vision de ce qu’on fera en cas de GO ? C’est du gâchis. Et pourtant, combien en voit-on ?
Et si on n’en faisait pas ?
Dans pas mal de cas, faire un POC est une perte de temps.
Voici quelques cas concrets où il est plus intelligent de faire autre chose.
1. Faire un PoV ou une maquette
Quand la question centrale est métier (utilité perçue, adéquation au besoin), on n’a pas forcément besoin de tout brancher. On peut commencer par comparer des solutions, tester un concept, recueillir du feedback.
Exemple : avant de développer un outil interne, on réalise une maquette interactive et on organise des ateliers avec les utilisateurs finaux. L’objectif ? Voir s’ils comprennent, s’ils adhèrent, s’ils voient une valeur. Zéro ligne de code, 100 % insights.
2. Aller directement au pilote
Quand la techno est déjà éprouvée ailleurs, que le coût est raisonnable, et que l’enjeu porte sur l’adoption, pas sur la faisabilité.
Exemples : Déployer un chatbot interne déjà utilisé par d’autres entreprises, Tester la 5G pour des usages métiers simples, Utiliser une solution SaaS courante avec des API standardisées.
Dans ces cas-là, mieux vaut tester en conditions réelles sur un périmètre restreint. Pas besoin d’un POC bricolé : on déploie pour de vrai, mais à petite échelle.
3. Démarrer par un MVP
Quand l’objectif est de créer un nouveau produit / service, que l’on veut apprendre vite en conditions réelles et que trois conditions sont réunies :
- La techno est maîtrisée.
- Le besoin d’itération est élevé.
- L’intégration SI est faible ou évitable.
Exemple : lancer une version simplifiée d’un outil client avec les 2 ou 3 fonctionnalités clés pour observer l’usage réel. Pas besoin de tout valider avant : on construit, on mesure, on ajuste.
Faire ou pas : comment choisir ?
Voici une grille simple pour décider :
| Question | Si oui… | Sinon… |
|---|---|---|
| Y a-t-il une vraie incertitude technique ? | POC / PoT | Maquette, pilote ou MVP |
| Veut-on tester l’adoption / l’usage ? | Pilote ou MVP | POC / POT si techno aussi incertaine |
| Le coût est-il faible et le risque limité ? | Pilote en conditions réelles | Revenir à une approche exploratoire |
| La techno est-elle déjà mature ailleurs ? | Benchmark / retour d’expérience | POC si contexte spécifique à valider |
| A-t-on une vision claire de la suite ? | Go / no-go à l’issue de l’expérimentation | Stop (ou reposer les bases du projet) |
N’oublions pas une règle d’or : un POC, ça coûte peu, ça dure peu (3-6 mois), et ça répond à une question : GO/NO-GO. Sinon, ce n’est pas un POC, c’est un projet déguisé !
Le bon usage du doute et le courage de choisir
Le vrai sujet derrière tout cela, c’est l’attitude vis-à-vis du doute.
- Quand on ne sait pas, on teste.
- Quand on sait déjà, on agit.
- Et quand on croit savoir, on se méfie.
L’expérimentation n’est pas une mode. Elle ne doit pas devenir pas devenir un totem d’agilité ou un outil d’agitation. C’est une méthode qui doit rester au service d’une stratégie de décision,
Le POC n’est ni un passage obligé, ni un mal nécessaire. C’est un instrument parmi d’autres pour sécuriser une décision. Le courage d’une stratégie digitale tient autant dans la capacité à expérimenter que dans celle à ne pas expérimenter inutilement. La prochaine fois qu’on vous propose « on fait un POC ? », posez-vous la vraie question : « Qu’est-ce qu’on cherche à savoir ? » Et si la réponse n’est pas claire… alors, ne faites rien. Un POC n’est jamais une fin en soi.
Vous vous interrogez sur la bonne approche à adopter pour évaluer une opportunité digitale ? Vous voulez maximiser l’impact de vos expérimentations ? Parlons-en (un échange vaut mieux qu’un énième POC !)
