Fournir de la plus-value au lieu d’applications

Le développement de logiciels reste souvent un processus complexe, au cours duquel de nombreuses étapes et activités successives doivent être judicieusement étudiées et synchronisées. Il fait souvent appel à différents spécialistes et équipes possédant leurs agendas,  spécialisations et sensibilités propres. Dans de telles conditions, on fait vite des fautes. 

Chez Pàu Studio, l’équipe interne de développement du consultant en design et informatique anversois Pàu, on connaît bien le problème. Pour éviter ce genre de chausse-trappes,  elle utilise volontiers Lean Startup pour autant que ce soit possible. « Lean Startup est un type de méthodologie qui vous offre rapidement une vue exacte d’un projet et qui permet de corriger rapidement le tir, » explique Kevin Wenninger, Digital Product Expert chez Pàu. « Les idées essentielles en ont été présentées dans l’ouvrage The Lean Startup, publié en 2011 par l’Américain Eric Ries. Il y décrit comment une start-up peut lancer rapidement un produit efficient à faible coût, ce qu’il qualifie de lean product development. Ce sont ces méthodes que nous appliquons désormais pour le développement logiciel. » 

Qui est intéressé par cette solution ?

Lean Startup se fonde sur deux grands principes, indique Wenninger. « Supposons que vous soyez un boulanger qui veut ouvrir une nouvelle boulangerie ; vous avez déjà de nombreuses références et meilleures pratiques dont vous pouvez profiter. Vous savez à peu près à quoi ressemblera votre magasin, quels produits vous allez devoir fabriquer, combien de clients potentiels vous pouvez atteindre. Pour un nouveau produit, une nouvelle idée ou une nouvelle fonctionnalité, vous n’avez généralement pas ce luxe. Souvent même, vous ne savez pas exactement ce que cela va devenir, ou comment cela va fonctionner précisément. Vous faites de nombreuses suppositions à propos de votre produit, mais en fait, vous n’en savez rien. La première étape consistera donc à tester ces suppositions : ce que vous assumez à propos de votre produit correspond-il à la réalité ? Et le public, est-il prêt à acquérir votre produit ? Il y a-t-il une demande ? Qui est intéressé par votre solution ? »

Cela peut sembler bizarre, mais ce sont des questions fondamentales que beaucoup d’entreprises oublient de se poser, » précise Wenninger. Et il est bien placé pour le savoir. « J’ai eu un jour l’idée de créer une appli destinée à simplifier une demande de permis de construire. En Allemagne (son pays natal, ndlr), les autorités avaient publié un nouveau document de 250 pages que les maîtres d’oeuvre devaient lire, ce qui leur prenait des heures.  Nous pensions que notre appli numérique pourrait considérablement simplifier cette tâche et nous nous sommes donc mis à programmer avec enthousiasme. Nous allions construire une plate-forme pour gérer les utilisateurs, nous avions ajouté des fonctions pour travailler à plusieurs utilisateurs sur un même document, et à un certain moment, nous avions même intégré des fonctions de paiement (rires). Nous étions occupés avec tant de choses à la fois qu’il nous aurait fallu au moins un an pour réaliser une première version de l’appli. Pire encore : nous nous sommes rendus compte très tard qu’en fait, les planificateurs n’avaient pas besoin d’une telle appli. Si nous ne nous étions pas égarés dans toutes ces fonctions superflues, nous l’aurions sans doute compris beaucoup plus vite. » 

C’est un travers qu’on retrouve dans de nombreux projets logiciels, souligne Kevin Wenninger. Il arrive souvent que les projets prennent une envergure telle qu’au final, plus personne ne sait de quoi il retourne. On gaspille ainsi beaucoup de temps et d’argent. 

Build, Measure, Learn

Le deuxième principe, c’est que Lean Startup procède par courtes étapes gérables, qui permettent aux développeurs d’obtenir rapidement une vue claire de leur produit. « Chaque étape intermédiaire est validée selon le principe « build, measure and learn », » explique Wenninger. « Build est le processus de développement même, par exemple en Scrum, dans lequel vous travaillez avec des sprints courts auxquels vous ajoutez des fonctions. Cela peut également se faire avec des plates-formes low code ou no code, en principe cela n’a pas d’importance. Dans Measure, vous allez définir les attentes et résultats précis : si je programme ceci, ceci et que j’ajoute ceci, je peux convaincre autant d’utilisateurs additionnels de mon logiciel de créer un compte. Je vais donc mesurer. Dans ce cas-ci, mesurer si mon taux de conversion augmente. Dans Learn, vous vérifiez si votre supposition (« grâce à ces fonctions, mon taux de conversion augmente ») était la bonne. Si c’est le cas, très bien. Si ce n’est pas le cas, vous devrez trouver une autre solution pour valider votre supposition, ou bien adapter votre supposition. » 

Un point très important de la phase Learn consiste à impliquer des utilisateurs, relève Kevin Wenninger. « Vous devez non seulement mesurer si, et combien de personnes créent un compte, mais aussi pourquoi elles ne le font pas, par exemple à l’aide d’interviews. Cela fournit souvent des aperçus indispensables pour améliorer votre logiciel lors de la phase Build suivante. Car « Build, Measure, Learn » est comme un cycle infini qui se répète en boucle. »

Minimum Viable Product

Outre la validation des suppositions et le cycle « Build, Measure, Learn », Lean Startup applique encore un principe important : le Minimum Viable Product ou MVP. « Le Minimum Viable Product est une version du produit qui comporte des fonctionnalités minimales, mais qui fournit d’emblée une plus-value pour l’utilisateur, » explique Wenninger. « Supposons que vous deviez développer une solution de mobilité. Vous constituez une équipe, vous commencez à travailler d’arrache-pied, et après cinq ans, disons, vous présentez… une nouvelle voiture. Lean Startup procède de façon totalement différente. Vous commencez à développer, et après six mois, vous dévoilez une trottinette. C’est loin d’être aussi confortable qu’une voiture, mais elle vous permet déjà de parcourir de longues distances. C’est un Minimum Viable Product qui fournit d’emblée une plus-value aux utilisateurs, car ils peuvent aussi se déplacer avec une trottinette. Vous retournez dans votre cave et quelques mois plus tard, alors que tout le monde utilise déjà votre trottinette, vous dévoilez une trottinette qui équipée d’un moteur. Une fois encore : plus-value, car les déplacements sont désormais beaucoup plus rapides. Encore un peu plus tard, vous y ajoutez deux roues supplémentaires. Vous obtenez ainsi une sorte de go-cart  nettement plus confortable qu’une trottinette. Et c’est seulement alors que vous allez améliorer ce go-cart de sorte à obtenir finalement une voiture. À chaque étape intermédiaire, vous allez donc intégrer une plus-value via des idées progressives et du feed-back. Et en même temps, le Minimum Viable Product veille à ce que chaque nouvelle génération de votre produit continue à répondre à vos suppositions initiales. » 

Une autre approche, une autre idée

En tenant compte systématiquement de ces suppositions initiales et en raison de la nécessité de fournir rapidement et constamment une plus-value, il peut arriver que des clients s’adressent à Pàu avec une idée déterminée, mais que cette idée change radicalement d’orientation en cours de processus. » relève Kevin Wenninger. « Si nous envisageons les projets qui comportent des algorithmes très complexes ou de l’AI, il peut certainement être utile de mettre en question les suppositions à leur propos et d’examiner quelle valeur les résultats peuvent avoir pour les utilisateurs. L’AI est souvent très complexe, et cela peut prendre du temps d’élaborer l’algorithme correct qui répond exactement aux besoins de l’utilisateur. La remise en question de cette option peut entraîner une approche totalement différente du projet. Il pourrait ainsi arriver que le développement de l’algorithme soit reporté à plus tard, après que nous ayons collecté les avis des utilisateurs. De cette façon, vous pouvez exécuter manuellement des calculs qui seraient faits par AI en Excel, par exemple. En prévenant bien sûr au préalable que les données ne seront disponibles que dans quelques heures ou jours. » (Rires) 

De cette manière, on crée une base pour discuter avec les utilisateurs et déterminer clairement quelles sont exactement leurs attentes. Il est toujours possible qu’ils indiquent par exemple qu’ils souhaitent avoir leurs données en temps réel. Ou qu’un autre type de calcul serait utile. « Vous savez alors rapidement ce qu’il faut développer exactement, et vous pouvez le planifier de manière efficace avec un moindre risque, » précise Kevin. 

Il arrive que les projets logiciels soient étendus trop rapidement et deviennent un écheveau inextricable. Comme les entreprises consacrent beaucoup de temps et d’argent à des fonctions non testées et peut-être même indésirables, elles ne seront pas disposées à les supprimer rapidement par la suite. Et cela car elles ont « coûté de l’argent ». En outre, beaucoup de produits novateurs sont encore trop souvent développés avec une mentalité de « founders », remarque Kevin. « Cette mentalité implique de tout développer et implémenter immédiatement. Et plutôt aujourd’hui que demain. (Rires) Donc au lieu de tester, on programme d’arrache-pied, sans rassembler les fondements essentiels et élaborer par étapes.  Et on continue ainsi jusqu’à ce que le budget soit épuisé. Et il arrive alors souvent qu’on n’ait pas encore de produit définitif à ce stade. » 

Partenaire stratégique

L’approche Lean Startup, au contraire, présente de nombreux avantages. « Vous pouvez commercialiser rapidement une application et être très proche des utilisateurs. Nous les impliquons le plus rapidement possible, car leur feed-back est crucial ; en fin de compte, ce sont eux qui doivent utiliser le produit. En outre, nous savons très rapidement si la direction prise est bien la bonne et si le budget dont nous disposons est utilisé au mieux. De cette façon, Pàu devient également plus qu’un simple constructeur d’applis. Nous sommes un partenaire stratégique dans l’ensemble du processus de développement et fournissons de la plus-value au lieu d’une simple application. »