EPISODE 2 : obtenir rapidement un produit à tester, en dépit des contraintes techniques
Dans les méthodes Agile, la notion de Minimum Viable Product (MVP) est centrale. Le MVP est un produit « qui fonctionne » mais sans embarquer l’ensemble des fonctionnalités attendues. Et même, il ne comporte souvent que le minimum nécessaire pour le proposer à des utilisateurs. L’enjeu est d’évaluer l’intérêt marché le plus rapidement possible et ce de manière très concrète, en mettant le produit entre les mains des utilisateurs. On peut alors observer leurs réactions plutôt que de leur demander de se projeter dans des fonctionnalités « qu’on envisage de développer si… ».
Dans le monde du software, on testera telle ou telle application en paramétrant et en recombinant des briques logicielles existantes. Produire un MVP est donc plutôt rapide.
Il en va tout autrement dans la Deeptech.
La valeur du projet réside principalement dans la levée d’un verrou technologique et les performances supérieures qu’elle implique. Si une hydrolienne à membrane ondulante n’opère pas avec un rendement très supérieur aux solutions concurrentes, il y a peu de chance de trouver une proposition de valeur alternative pour le projet. Il faut donc aller au bout des développements.
Et cela est d’autant plus compliqué que ces projets comportent, plus souvent que la moyenne, une dimension hardware, qui rend le prototypage plus complexe. Sans même évoquer les obligations réglementaires…
Produire un MVP dans la Deeptech est particulièrement complexe.
Alors, comment tester des produits hardware en dépit de ces contraintes ? Quel type de MVP peut-on produire dans l’univers Deeptech ?
Levier n°5 : ne tester qu’une seule dimension à la fois (design, faisabilité technique, etc.)
Produire un MVP rapidement nécessite de s’abstraire de la logique du « tout ou rien » et de développer un produit partiel. Il est donc indispensable de clarifier ce que l’on attend de ce MVP et de spécifier la dimension à tester.
Il faut être très spécifique sur ce que l’on souhaite tester.
Schématiquement, on pourra :
- Tester l’appétence des utilisateurs en évacuant certaines contraintes techniques
C’est l’approche retenue par Tesla (encore eux !) en 2006, lors de leur soirée de lancement à l’aéroport de Santa Monica. Les convives pouvaient effectuer des essais du fameux roadster électrique, ressentir ses accélérations, entendre le sifflement si caractéristique de son moteur… Heureusement, l’envers du décor ne leur a pas été montré : « Les deux véhicules étaient détruits à la fin de la soirée. Nous devions les conduire derrière un rideau pour les refroidir afin qu’ils puissent supporter d’autres essais ».
- Tester la faisabilité technique à l’exclusion de tout autre aspect
Ici, c’est tout l’inverse. On veut valider que le produit envisagé est techniquement réalisable. On a beaucoup écrit sur les Proof of Concept (PoC), mais évoquons une méthode issue du logiciel, moins utilisée pour le hardware et qui peut pourtant y être déployée avec profit : il s’agit du « Développement Piloté par les Tests » (« Test Driven Development », TDD).
Dans tout travail d’ingénierie, des tests sont nécessaires pour valider les développements. L’originalité du TDD consiste à définir ces procédures de test avant de commencer les développements. Ces derniers sont considérés comme achevés si et seulement si ils passent avec succès les tests définis.
Quelle différence avec le schéma classique, puisque dans tous les cas, des tests finissent par être réalisés ?
Eh bien, définir les procédures de test en premier permet préciser l’objectif recherché et d’être totalement focalisé sur ce dernier, à l’exclusion de tout autre aspect (amélioration de l’interface, fonctionnalités et bénéfices connexes, etc.). Dans une phase où l’on cherche à aller le plus vite possible et avec des moyens limité, cette approche impose une « discipline » particulièrement intéressante.
Levier n°6 : clarifier et délimiter son segment cible, avec des logiques spécifiques à la Deeptech
L’entrepreneur qui estime son marché ancre d’ordinaire son analyse sur trois niveaux :
- Le marché potentiel, ou l’ensemble des clients qu’il pourra un jour conquérir. Pour un producteur de jus d’orange (oublions un instant la Deeptech !), ce sera l’ensemble de la population.
- Le marché adressable, qui restreint le premier agrégat à des clients qu’il pourra approcher à moyen-terme. Ici, l’ensemble des consommateurs de boissons sucrées.
- Enfin, le marché cible, ou la clientèle qu’il va viser de façon prioritaire et immédiate. Par exemple, le segment des adolescents (en utilisant une communication et un prix adaptés).
Dans un projet logiciel Agile, une démarche d’essai et erreur permettra de confirmer son segment cible. Puis, l’enjeu sera d’agrandir le terrain de jeu au marché « adressable » en évangélisant de nouveaux clients. D’un point de vue technique, le chemin est plutôt balisé (nous simplifions !). Il faut approfondir les fonctionnalités les plus plébiscitées et renforcer l’infrastructure IT sous-jacente.
Ma séquence de développement des projets Deeptech présente des spécificités non négligeables.
Tout d’abord, l’expérimentation, même à petite échelle, peut rapidement devenir onéreuse, ce qui renforce la nécessité d’avoir un objectif circonscrit (cf. levier n°1) et de viser une clientèle rentable (i.e. pour réinvestir les revenus générés).
Ensuite, les chemins peuvent vite devenir non-linéaires : on peut choisir tel ou tel segment parce qu’il est permet de développer une technologie cœur, sachant que des développements applicatifs ultérieurs nous mèneront sur un tout autre marché. Ainsi, pour une technologie de Transmission Variable Continue (CVT, une sorte de boîte de vitesses automatique, mais sans couples fixes), le marché de l’éolien pourra être un très bon segment cible. Tout en sachant que le gros du marché sera in fine dans l’automobile.
Le MVP Deeptech amorce une trajectoire souvent non-linéaire.
En outre, le passage à l’échelle en Deeptech (i.e. augmenter la puissance, la portée, la performance d’une technologie) génère des effets de seuil et de nouveaux verrous. Par exemple, une batterie électrique gardera la même densité quand on augmente sa capacité, mais elle générera alors une surchauffe difficile à dissiper. C’est une dimension à prendre en compte si le marché visé à terme nécessite un bond en matière de performances.
Tout comme l’industrialisation (i.e. la fabrication du produit), qui peut elle-même présenter des défis sérieux…
C’est donc, autant que possible, l’ensemble de la trajectoire qu’il faut en permanence garder à l’esprit dans les projets Deeptech. Développer un produit ici et maintenant, qui permette de capitaliser sur des revenus et une technologie. Avec une feuille de route qui orchestre de manière cohérente les enjeux technologiques et « marché ».
A la rentrée, nous verrons, dans un troisième épisode, comment intégrer les retours marché dans la Deeptech, quand de très nombreux acteurs sont sollicités et que ces derniers formulent parfois des demandes contradictoires.