Le sujet du Proof of Concept fait l’objet de discussions intarissables sur ce qui est devenu la pierre angulaire de beaucoup de stratégies digitales. Les PoC (Proof of Concept) sont également devenus la méthode préférée des entreprises industrielles pour interagir avec des startups. Ils sont un sujet de frustration et de coûts perdus pour les uns, parfois de réussite pour les autres. Finalement, peu réussissent au point d’être vraiment déployés opérationnellement dans la vraie chaîne de valeur de l’entreprise. En définitive, que penser du PoC ?
Le PoC : une approche essentielle pour la transformation digitale
Le PoC vient d’une démarche extrêmement positive. Il s’agit de tester une idée, une innovation, ou une collaboration avec des partenaires technologiques dans un cadre restreint permettant de qualifier son utilisation potentielle industrielle. Cette approche est une thématique forte de la transformation digitale. Il faut expérimenter, tester, accepter d’échouer, apprendre de manière à valider des hypothèses, éduquer les équipes, monter en compétence et développer des différenciateurs sur son marché.
De la théorie à la pratique : la nécessité d’un cadre structuré
Dans la théorie, le PoC a plusieurs objectifs : démontrer une faisabilité sans développer une solution complète, réduire les risques associés à une solution innovante, confirmer les estimations de coûts, emporter l’adhésion des équipes, et in fine faciliter la prise de décision entre plusieurs solutions.
Néanmoins, dans la pratique, la notion de PoC est beaucoup plus floue. Les objectifs sont incertains, les conditions de réussite peu claires. Le PoC devient un outil de communication interne et externe, ou alors un prétexte pour aborder de manière très allégée une stratégie affichée de transformation digitale. Il lui manque très souvent des attributs essentiels qui lui donnent vraiment un impact dans l’entreprise.
Le PoC en ToC : trois raisons d’échec
La raison principale d’échec du PoC devrait venir du risque intrinsèque qu’il teste et non de son exécution opérationnelle. C’est ainsi que l’échec du PoC sera positif et porteur de valeur pour l’entreprise. Il aura permis d’écarter une solution trop risquée. Pourtant, les raisons d’échec sont souvent autres :
Trop de PoC tue le PoC : Les proofs of concept sont une méthode de validation rapide, et non un screening systématique de toutes les idées du moment. Le PoC a du sens pour aider à prendre rapidement les bonnes décisions dans un projet comportant des risques d’innovation. Néanmoins, on voit parfois des entreprises lancer des dizaines de PoC simultanément, ce qui dilue les compétences et l’impact de chaque PoC, et risque de retarder le projet.
Confondre PoC et communication : Certains PoC sont lancés pour permettre de faire de la communication interne ou externe. En réalité, il s’agit plus de démonstration que de PoC. C’est un bon vecteur de communication sur l’innovation, mais les objectifs sont différents. Le projet devra donc ne pas se tromper de cible et être orienté vers cet objectif de communication ou de démonstration.
Manque de clarté sur ce qu’on attend : Quels sont les objectifs ? Qu’est ce qui fera du PoC un succès ? Comment les résultats seront-ils utilisés ensuite ? Un PoC chez un logisticien avait ainsi montré la capacité d’un système à géolocaliser assez précisément des palettes dans un entrepôt. Mais sans réflexion sur le besoin métier réel de localiser aussi précisément les flux de palettes, et un gain opérationnel éventuel…
Le PoC au top : trois conditions de succès
Les conditions de réussite d’un Proof of Concept viennent de sa définition. Il est là pour tester un concept ou une idée, dans des conditions proches de la réalité, et de manière économique et rapide. Lancer un PoC suppose aussi d’accepter son échec éventuel et le droit à l’erreur. Le but n’est pas de réussir à transformer l’essai pour tous les PoCs, ce qui serait impossible, mais de tester et d’apprendre.
Le PoC devrait logiquement s’inspirer des démarches "Lean Startup", qui promeuvent entre autres une boucle de mesure et de rétroaction rapide sur la performance (Produire – Mesurer – Apprendre), et un investissement au plus juste pour accomplir chaque tâche (faire plus que le strictement nécessaire coûte de l’argent et surtout du temps).
Ambition et objectifs : Le PoC doit d’abord avoir des objectifs clairs, atteignables dans un délai à court terme, et des indicateurs de succès et d’échec définis en amont. Par exemple, dans l’industrie pharmaceutique, les essais de phase 1 peuvent être considérés comme de bons exemples de PoC. Ils ont des objectifs de succès bien définis sur le plan médical, sont réalisés avec un nombre très limité de sujets, pour valider que le comportement d’une molécule et ses effets thérapeutiques in vivo est similaire à l’hypothèse de recherche. Le succès de la phase 1 permet d’aller plus loin ; en revanche, son échec ferme rapidement une hypothèse et autorise une rapide réallocation des moyens sur d’autres molécules.
Moyens, ressources, périmètre : Les moyens et ressources alloués au PoC doivent être définis et suffisants. Comme tout projet, le PoC nécessite un budget/des moyens humains et financiers, des jalons, en relation avec un périmètre et des objectifs. Il demande aussi la mise à disposition de compétences adaptées. Les PoC adressent en principe des sujets à fort risque technologique, ils doivent donc être soutenus par des compétences spécifiques de bon niveau. Cela inclut également d’impliquer les bonnes compétences métier pour conserver son lien avec les futurs utilisateurs.
Objectif production : Le PoC, si bien sûr il fonctionne, doit pouvoir être industrialisé jusqu’à une application réelle en production ou en service. Les données et conditions doivent donc être proches des conditions réelles. Cela signifie qu’il faut prendre en compte l’environnement spécifique de production. Dans une application de détection d’anomalie de fabrication par caméra, une attention a été portée dès le début aux problèmes potentiels de mauvais calibrage des caméras dans l’usine ; les données de test du PoC prenaient donc assez fidèlement en compte ces erreurs pour tester les modèles avec des conditions proches de la réalité.
Suivre ces quelques idées devrait contribuer à redorer l’image du Proof of Concept, et lui donner tout son potentiel pour avoir un effet à l’échelle de l’entreprise !
Xavier Brucker
