Il y a dix ans, j’étais une fervente défenseuse des POCs (Proof of Concept).
Je les recommandais à mes clients et à mes équipes comme une étape incontournable pour démontrer la valeur d’une solution ou lever un risque.
Dans une majorité de cas, je reste attachée à la preuve par le fonctionnement. Mais avec le temps, j’ai aussi vu leurs limites et dérives.
Les atouts du POC
Tout d’abord, ma conviction : Bien utilisé, un POC reste un formidable outil pragmatique formidable !
- Il permet de tester et prouver la faisabilité d’une idée : valider qu’une technologie tient ses promesses et que le concept fonctionne en conditions réelles.
- Il aide à lever des risques techniques, organisationnels ou liés aux compétences, en mettant à l’épreuve la chaîne complète (outils, données, équipes). L’équipe s’engage ensuite dans le projet de mise en place en toute confiance.
- Enfin, il facilite l’alignement des parties prenantes : en donnant à voir quelque chose de concret, le POC crée de la confiance et embarque sponsors et utilisateurs dans la suite du projet.
Lors de mon expérience chez des éditeurs de logiciels (OpenText, Adobe, etc.), le POC s’est avéré un très bon outil pour démontrer la capacité de l’outil en contexte à des prospects. Cela n’était valable que pour des sélections structurantes pour l’entreprise et quand il y avait un doute, souvent l’intégration au SI spécifique ou un cas d’usage très innovant. Consultez mon article sur la sélection de nouvelles solutions.
Quand le POC devient un piège
- Une excuse pour tester encore et encore : au lieu de décider, on repousse.
- Le reflet d’une aversion au risque (très marquée en France).
- Un transfert de responsabilité : si ça échoue, ce n’est pas “ma” faute, c’est “le POC”.
- Une consommation de temps énorme : des semaines, parfois des mois, sans décision claire.
- Trop de cas d’usage : vouloir tout tester d’un coup et perdre l’essentiel de vue.
- Un manque de réflexion en amont : “puisque ce n’est qu’un POC”, on définit mal les cas d’usage… et donc on tire peu d’enseignements.
Ces travers se sont particulièrement révélés avec l’IA, où beaucoup d’entreprises se sont enlisées dans des POCs successifs, sans jamais passer à l’échelle.
Vous vous interrogez sur la meilleure approche pour vos projets digitaux (POC, pilote ou MVP) ? 📅 Je propose un diagnostic gratuit de 30 minutes pour clarifier vos cas d’usage et identifier la stratégie la plus efficace.
Cas particulier des POC IA
Sur les deux dernières années, la conduite des POCs a été très affectée par la déferlante Gen AI dans les entreprises. La prudence est probablement de rigueur au moment de faire des conclusions. En effet, plusieurs études rappellent que les POCs IA échouent souvent à franchir le cap de la production :
- Selon IDC et Lenovo, 88 % des pilotes IA ne passent pas en production
- S&P Global note qu’en moyenne, 46 % des POCs sont abandonnés avant même d’arriver à l’étape de mise en œuvre.
Le succès d’un POC comme d’un déploiement IA tient beaucoup à la disponibilité et la qualité de la donnée. Ce pré-requis potentiellement coûteux à tendance à être sous-estimé voire contourné, participant à des résultats déceptifs. Il ne faut cependant jamais oublier qu’un échec est une source d’apprentissage.
Alors, POC ou pas POC ?
Ces taux d’échec élevés ne signifient pas que les POCs soient inutiles.
D’une part, ils tiennent à l’emballement que nous avons pu constater suite à la généralisation de la Gen AI. Le POC a ainsi rendu le service attendu qui était de confirmer ou infirmer la généralisation du concept.
D’autre part, ils signalent l’importance d’un cadrage rigoureux : cas d’usage précis, critères de succès clairs, sponsors impliqués et données adaptées. Sans cela, le POC devient un refuge à l’inertie plus qu’un levier de décision.
POC ≠ Prototype
Une confusion fréquente entretient l’inefficacité des POCs : on les traite comme des prototypes.
- Le POC (Proof of Concept) doit rester léger : il démontre qu’un concept est techniquement faisable et qu’il répond à une hypothèse précise. C’est une preuve rapide, limitée dans son périmètre.
- Le prototype, lui, est une pré-version de la solution finale : il intègre déjà une partie de l’expérience utilisateur, de la conception et du parcours fonctionnel.
👉 Quand un POC se transforme en prototype, il devient trop lourd, consomme trop de temps et brouille la prise de décision.
👉 L’enjeu est donc de garder le POC rapide, ciblé et minimaliste, pour que la décision (go / no go) arrive vite.
👉 POC ≠ Prototype ≠ MVP ≠ Pilote – Chacun de ces concepts est un très bon outil mais à utiliser à bon escient.
Mon rôle est souvent d’aider les dirigeants à clarifier ces choix stratégiques pour sécuriser leur ROI – découvrir mon accompagnement.
Cas particulier du POC d’un nouveau logiciel lors d’une sélection. Attention au travers de demander un POC gratuit à un fournisseur. Mon constat est que ces demandes qui peuvent paraître faciles et gratuites n’apportent généralement pas le résultat attendu. Le POC étant gratuit, les équipes n’y accordent pas assez d’attention, manquent de réactivité, ne creusent pas les cas d’usage… Y accorder un budget permet d’officialiser la démarche et lui accorder sa juste valeur.
Les bonnes pratiques pour en tirer de la valeur
Bien mener
- Utiliser le POC à bon escient.
- Définir des cas d’usage concrets et mesurables.
- Identifier dès le départ les critères de succès et d’échec.
- Aligner les sponsors métier et IT.
Bien préparer
- Identifier les « showstoppers » comme valider qu’il n’y aura pas de contre indication du département juridique, cybersécurité ou data privacy.
- Limiter la durée (quelques semaines maximum).
- Documenter les résultats, positifs comme négatifs.
- Impliquer les utilisateurs finaux dès le départ.
Bien suivre
- Clôturer systématiquement par une décision claire.
- Tirer des enseignements (même en cas d’échec).
- Préparer l’étape suivante (passage à l’échelle, itération, ou abandon assumé).
Conclusion
Un POC en entreprise peut être un formidable levier d’apprentissage. Mal utilisé, il devient un piège coûteux et frustrant.
Les chiffres le rappellent : une grande majorité des POCs IA n’atteignent jamais la production. Ce n’est pas le POC en soi qui est en cause — c’est la façon dont il est cadré, mené et suivi.👉 La clé n’est pas “POC ou pas POC”, mais POC bien cadré, ou pas du tout.
💡 Vous réfléchissez à lancer un POC ?
👉 Contactez-moi pour transformer vos idées en solutions concrètes et passer plus vite à l’échelle.