Dans le domaine de l’informatique et de la gestion projets, il existe le Proof of Concept (POC). Il s’agit d’un avant projet, court et simple, qui a pour but de tester la capacité d’une solution à répondre au besoin. Sa traduction exacte serait « preuve de concept » mais on pourrait l’appeler « une mise à l’épreuve » ou « une expérimentation » d’une solution.

Définition d’un POC – Proof of Concept ?

Un Proof of Concept est une démonstration ou une validation rapide d’une idée, d’un concept ou d’une solution technique. Il s’agit d’un prototype minimaliste conçu pour tester et vérifier la viabilité d’une idée ou d’une solution technique avant de passer à une phase de développement ou d’intégration.

Le POC permet de réduire les risques techniques et financiers associés au développement ou à la mise en place d’une nouvelle application ou fonctionnalité.

Il est énormément lié à la notion de MVP – minimum viable product. Qu’on pourrait traduire par les fonctionnalités minimums à avoir et à éprouver sur une solution.

Caractéristiques d’un POC

Un POC présente les caractéristiques suivantes :

  • Périmètre restreint : un POC est conçu pour être aussi simple que possible, en se concentrant uniquement sur les éléments clés
  • Rapide et peu coûteux à mettre en place, ainsi en cas d’échec, pas ou peu de perte (financière ou temps)
  • Axé sur les résultats : il est conçu pour produire des résultats concrets et mesurables pour vérifier la pertinence des solutions

On dit souvent qu’il vaut mieux « un bon croquis plutôt qu’un long discours ». Pour comprendre l’intérêt d’un POC, on pourrait le résumer en disant qu’ « il vaut mieux un bon POC qu’un long argumentaire ».

A quel étape d’un projet intervient il ?

Sur un projet classique, il intervient en amont, c’est à dire au moment de la recherche de solution. Donc après l’expression du besoin.

Ces recherches aboutissent souvent à plusieurs solutions ou prestataires possibles. Mais, les parties prenantes ont parfois du mal à choisir, soit parce qu’il s’agit d’une solution nouvelle dans l’entreprise, soit d’une innovation qui n’a pas encore fait ses preuve sur le marché, soit parce qu’il est nécessaire de comparer les solutions trouvées.

Trois exemples de proof of concept

Pour être plus concret je vais vous donner 3 exemples que j’ai pu rencontré dans ma carrière.

Le choix d’une solution pour calculer le temps dans les files d’attente

J’ai eu l’occasion de travailler dans un parc d’attraction. L’attente est un problème majeur pour les clients. Nous avions donc besoin de mieux mesurer les temps d’attente pour informer les clients et les orienter vers les lieux ou attractions moins occupés.

Le besoin a été exprimé. Simple à dire mais pas facile à mettre en place. Nous avons trouver plusieurs solutions. Sauf qu’aucune n’avait été éprouvé dans des secteurs similaires au nôtre. Pourtant, nous avions les leaders du marché. Mais à mon avis, ce marché n’était pas encore mature et tous ces logiciels devaient encore faire leurs preuves.

Dans ce cas, un proof of concept se justifiait totalement. Car il permettait de tester les solutions grâce à des mesures sur le terrain et de mettre en concurrence les acteurs pour ne retenir que le meilleur. Nous avons réussi à déployer ces solutions pour les tester plusieurs mois.

Nous avons d’ailleurs bien fait car nous n’en avons retenu aucune faute de résultats satisfaisants. Au final, nous nous sommes orienter sur une autre manière de traiter le problème.

Merci le POC !

Le choix d’une solution pour mesurer le taux de transformation dans une boutique

Autre projet, autre société. Notre souhait était de pouvoir calculer les entrées et sorties des clients dans une boutique et en déduire un taux de transformation en fonction du nombre de vente sur la même période.

Les solutions proposées avaient toutes fait leur preuves. En revanche, cette façon de travailler était totalement nouvelle pour nous.

Nous aurions presque pu nous passer d’un POC, mais dans ce contexte il a été très utile car il nous a permis d’essayer la solution à moindre coût et de se rassurer.

Après quelques mois de tests, nous étions convaincus et nous l’avons déployer sur plusieurs boutiques. Fait notable, dans ce projet, le POC a clairement aider à la réussite de la partie conduite du changement.

Le choix d’une solution pour la dématérialisation des contrats

Notre besoin était de dématérialiser les documents clients, notamment les contrats. Il existait de nombreuses solutions éprouvées sur le marché.

Ce qui a motivé la mise en place d’un POC :

  • La mise en concurrence de 2 solutions pour retenir la meilleure
  • Vérifier les promesses commerciales (taux de reconnaissance et bon classement des documents notamment)
  • Nous rassurer sur le gain de productivité pour les équipes

Nous avons donc convenu de choisir plusieurs types de documents que nous avons soumis aux 2 prestataires pour vérifier l’efficacité des solutions.

Ce POC ne nous a rien couté, contrairement aux 2 autres. Nous avons pu choisir une solution en toute confiance. Ce test a pris seulement 2 semaines.

Les limites de cette exercice

Il n’est pas toujours nécessaire de faire un POC et il n’est pas toujours possible d’en faire un non plus.

En effet, voici les critères qui doivent motiver son intégration ou non dans les étapes de votre projet :

  • Avez-vous le temps à disposition pour le réaliser ?
  • Si vous ne le faites pas, prenez vous un risque ?
  • Les solutions sont-elles déjà connues et reconnus sur le marché ?
  • Les solutions sont-elles déjà connus dans votre entreprise ?

Attention, un POC ne se substitue pas à une phase pilote. Parfois, cela peut y ressembler, mais c’est assez différent. Dans le premier cas, il s’agit de tester pour valider ou non un choix de solution.

Dans le cas de la phase pilote, il s’agit d’un déploiement restreint sur une solution déjà choisie, dans le but d’éprouver et fiabiliser la solution avant un déploiement de masse.

Enfin, dans le cas d’un outil ou d’une application à intégrer dans un écosystème complexe, notamment avec des interfaces, il est rarement possible de faire un POC réaliste. En effet, le développement des interfaces étant souvent complexe et couteux, le POC ne peut se faire qu’en stand alone donc sans interconnexion.