FIN DES POC ?

L’effervescence autour des POC est-elle en train de s’atténuer ? Cette question revient comme une petite musique lancinante au sein des organisations.

Est-ce justifié ?

On peut légitimement se poser la question devant le taux de réussite ou d’implémentation des use cases estimé à 20%, soit donc 80% d’entre eux passeraient à la trappe, 80% de l’énergie et de budget passeraient ainsi au rebus. Même si le concept du POC a initialement été créé pour échouer ou prouver, il est évident que le niveau de tolérance ou de bienveillance atteint son seuil asymptotique

En fait la question que l’on doit se poser : pourquoi tant d’échecs, pourquoi si peu de use cases menés à terme, pourquoi autant d’initiatives inopérables dans la vraie vie ?

Je vois trois raisons à cette coûteuse tendance.

La première est la plus évidente. Trop de POC sont lancés de manière trop éloignée des besoins métiers, avec un consensus mou et un effet d’entraînement et d’emballement des équipes projets (« de toute manière, c’est un POC, on ne prend pas de risque »). La bonne alchimie entre les besoins, les experts Data&IA, et, au centre, l’idée est la seule façon d’optimiser la réussite d’un projet. En toute rigueur, un POC bien construit devrait être uniquement soumis à un aléa pendant la phase de modélisation. Une équipe pluridisciplinaire doit avoir la capacité à border les risques et les impondérables.

La seconde raison (sûrement auto-corrélée à la première) est le phénomène de « juniorisation » du processus de décision. On voit trop de jeunes Datascientists très prometteurs s’accaparer une décision d’entreprise sous l’ombrelle de leur statut d’expert. Les use cases doivent avant tout répondre à un besoin stratégique de l’entreprise et doit de ce fait être suffisamment vulgarisés pour passer entre les mains d’un collège de validation senior, ou du moins ayant une connaissance de la culture et des priorités de l’entreprise. Les Datascientists ont un rôle fondamental pour donner un coup d’accélérateur à un projet mais ils doivent s’inscrire dans la chaine de valeur validée par le top management. La mise en place de POC doit absolument remonter dans les instances dirigeantes d’une organisation pour être co-signée et co-validée par les garants de la vision stratégique.

La troisième raison concerne le binôme Vision-Business Model. Tout d’abord, un certain nombre de POC sont lancés sans l’existence de Business Model. Dans ce cas précis, il n’est pas besoin de s’appesantir sur le risque pris par la société. Dans la majorité des cas, c’est la fragilité du Business Model qui est mise en cause. Aveuglés par une idée géniale sortie d’une séance de DesignThinking, la faisabilité, et plus précisément la scalablité, sont peu challengées et peu considérées. Il y a 2 moments cruciaux indissociables lors de la mise en place de ce type de projet : La génération de l’idée et sa modélisation économique. La capacité d’un projet à rentrer dans une structure de coûts, à s’inscrire dans une organisation (RH, IT, SupplyChain, Digital,…), à être un levier de croissance doit être modélisée avant de lancer un sprint avec les experts.

On voit naitre depuis quelques temps autour du POC d’autres concepts apportant une teinte de succès : Les POV (proof of Value), les MVP (Miminum Value Product),…

Je pense, qu’au-delà des nouveaux buzzwords, il est important d’injecter un peu de bon sens et d’échanges sur un use case en gestation : partage avec le plus grand nombre, regard extérieur expert/senior et solide modélisation économique/organisationnelle. Et avoir toujours à l’esprit que ce qui nait petit doit s’exprimer grandement. En clair, les POC qui n’ont pas de viabilité sur une phase de déploiement ne servent à rien.

Pour conclure, loin de moi l’idée de tuer dans l’œuf un projet prometteur mais plutôt de démultiplier ses chances de passer le stade expérimental pour éviter la lassitude de l’échec … et d’entériner définitivement la puissance de frappe du métier de la Datascience, … mais une Datascience infusée et intégrée comme tout projet d’entreprise qui se respecte.