Un PoC qui fonctionne ne prouve pas que vous avez un produit

La démonstration fonctionne.

Le phénomène recherché est observable. L’algorithme produit le résultat attendu. Le prototype réagit correctement.

Bonne nouvelle : l’hypothèse technique vient peut-être d’être validée.

Mauvaise nouvelle : cela ne dit encore presque rien du produit.

Un PoC répond à une question #

La fonction d’une preuve de concept est justement de réduire une incertitude.

• « Peut-on mesurer ce phénomène ? »
• « Cet algorithme permet-il d’extraire cette information ? »
• « Ces deux technologies peuvent-elles fonctionner ensemble ? »

Le prototype nécessaire pour répondre à cette question peut être laid, fragile, coûteux ou dépendre d’un environnement parfaitement contrôlé.

Ce n’est pas nécessairement un défaut. Si son objectif est de tester rapidement une hypothèse, lui demander immédiatement d’être industrialisable peut même ralentir l’expérimentation.

Le problème apparaît lorsqu’on confond preuve de faisabilité et maturité technologique.

Fonctionner n’est qu’une étape #

Les échelles TRL (Technology Readiness Levels) utilisées notamment par la NASA illustrent bien cette progression. Une preuve de concept expérimentale correspond aux premiers niveaux de maturité technologique.

Viennent ensuite la validation en laboratoire, la validation dans un environnement représentatif, la démonstration d’un prototype dans son environnement opérationnel, puis le système final.

Entre « ça fonctionne sur ma table » et « quelqu’un peut réellement l’utiliser » se trouvent donc beaucoup de questions.

• Le résultat est-il reproductible ?
• Que se passe-t-il lorsque l’environnement change ?
• Les composants choisis existent-ils encore dans deux ans ?
• Le système tolère-t-il les variations de fabrication ?
• Peut-on le tester ? Le maintenir ? Le produire à un coût compatible avec son marché ?

Ne demandons pas au PoC de prouver ce qu’il ne teste pas #

Un bon PoC n’est donc pas un produit miniature. C’est une expérience construite autour d’une incertitude clairement identifiée.

Avant de développer le prototype, une question simple mérite d’être écrite : « qu’est-ce que cette expérience doit nous permettre de décider ? »

Si le résultat ne change aucune décision, le PoC teste probablement la mauvaise chose.

Et lorsqu’il fonctionne, la bonne réaction n’est pas nécessairement « nous avons notre produit », mais plutôt : « très bien. Quelle incertitude vient de disparaître, et quelle est maintenant la suivante ? »

C’est ainsi qu’un prototype devient progressivement une technologie. Puis, éventuellement, un produit.

Perspective 03 — lundi prochain : Chaque composant fonctionne. Pourtant, le système échoue.

Source #

• NASA — Technology Readiness Levels (TRL), progression de la preuve de concept au système démontré en environnement opérationnel.