Toutes les idées de business ne se testent pas de la même façon.
Ouvrir une boulangerie et lancer un service qui n’existe pas encore n’appellent ni la même méthode, ni le même rapport au risque.
Dans le premier cas, l’offre existe déjà. Passer plusieurs mois sur une étude de marché a du sens : vous cherchez une zone de chalandise, un positionnement, un niveau de prix, et les données existent parce que d’autres avant vous ont fait la même chose.
Dans le second, il n’y a rien à étudier. Personne ne peut vous dire s’il achèterait un produit qu’il n’a jamais vu, et les réponses à cette question sont notoirement mauvaises. L’étude de marché donne alors une fausse assurance, payée plusieurs mois.
C’est exactement le problème que la méthode Lean Startup cherche à résoudre : remplacer la prédiction par l’expérimentation. Construire le minimum pour apprendre le maximum, puis décider sur des faits.
Encore faut-il pouvoir construire ce minimum en quelques jours.
Méthodologie du “Lean Startup”
C’est après avoir analysé l’échec de beaucoup d’entrepreneurs qu’Eric Reis a défini une méthodologie ayant pour but de minimiser le risque pris.
L’idée principale de cette méthode est de réduire le temps entre l’hypothèse et le résultat c’est-à-dire la confrontation finale avec votre cible.
Le process est le suivant :
1. Définition d’un problème
On formule l’hypothèse selon laquelle un certain personna, une certaine cible de consommateurs souhaitent recevoir chaque mois la version encadrée des 3 meilleures photos prises le mois précédant avec leur téléphone.
2. Définition d’une solution
Créer une application dans laquelle déposer ses 3 meilleures photos pour les recevoir encadrées.
3. Développement de la solution
Développement de cette application et mise sur le marché.
4. Tests utilisateurs
Mes potentiels clients testent mon application et me font des retours.
Et on recommence.
5. Définition d’un autre / nouveau problème
Mes utilisateurs ne font pas l’effort de déposer 3 photos.
6. Définition d’une solution
Je me base sur leurs posts Instagram pour définir par défaut les 3 meilleures photos.
7. Développement d’une solution
Je me connecte en API à leur compte pour récupérer les photos.
8. Tests utilisateurs et … on recommence.
La clé de réussite d’un projet réside donc dans votre capacité à tester vos hypothèses et ainsi minimiser le risque de dépenser du temps dans des hypothèses non vérifiées.
Quelle place pour le no-code ?
Dans ce contexte de lancement ou pré-lancement où l’exécution est clé les outils no-code sont l’une des solutions les plus efficaces pour vous aider à tester vos hypothèses et concrétiser votre vision, sans avoir à maîtriser des compétences techniques complexes.
En effet, avec ces outils, vous pouvez créer rapidement des applications web, des sites internet, des chatbots, des automatisations de tâches et bien plus encore, sans avoir besoin de coder une seule ligne de code. Cela vous permet de gagner un temps précieux et de vous concentrer sur d’autres aspects de votre projet.
Exemple
Un de nos tout premiers projets chez Bienfait a été la construction d’une application de suivi des outils et matériels d’une agence Eurovia (BTP). Un des employés de cette agence est venu nous voir pour nous demander de créer cet outil qui était à destination interne.
Itération #1
Puisque ce projet n’étant pas encore validé par sa hiérarchie nous avons fait un premier test avec une application Glide dont le back était sur Airtable. Les utilisateurs pouvaient s’inscrire et scanner des QR code liés à des machines et outils. Pour ajouter une machine l’opérateur de l’agence devait se connecter à Glide.
Itération #2
Voyant que cette version fonctionnait nous avons ensuite développé une interface Airtable afin de mieux suivre les actions des utilisateurs et facilité l’enregistrement d’une nouvelle machine.
Itération #3
Nous avons permis à un utilisateur, toujours sur Glide d’ajouter un commentaire.
À partir de cette itération le projet a été validé par la direction de l’agence et nous pouvions désormais passer à l’échelle.
Itération #4
Nous avons basculé la partie utilisateurs sur une interface Bubble, toujours lié à Airtable en base.
Itération #5
Nous avons basculé la partie admin sur Bubble, toujours lié à Airtable en base.
Itération #6
Nous avons migré la base de données sur Bubble.
Un an après, avec le recul, peut-être que nous aurions choisi d’autres outils mais nous n’aurions sans doute pas changé notre méthodologie. Grâce à ces différentes itérations nous avons pu, en un temps record, valider la solution (et l’hypothèse avec elle), valider l’intérêt global du projet et développer une application performante. Aujourd’hui cette application tourne toujours et est ouverte aux partenaires de l’entreprise afin qu’ils puissent alimenter les données eux-mêmes.
Un autre avantage des solutions no-code, qui est lui moins palpable, c’est qu’il annihile considérablement la valeur “émotionnelle” que l’on peut mettre dans son produit. Puisque le temps de développement est court et beaucoup moins coûteux il est plus facile de s’en défaire. A contrario, le même produit, ayant entraîné un coût bien supérieur va souvent biaiser la valeur qu’on lui donne et ainsi favoriser une forme obstination à le faire fonctionner, malgré les signaux contraires du marché.
Questions fréquentes
Qu'est-ce que la méthode Lean Startup ?
Une méthodologie définie par Eric Ries après avoir analysé l'échec de nombreux entrepreneurs. Son but : minimiser le risque en réduisant le temps entre l'hypothèse et la confrontation avec la cible réelle.
Quelles sont les étapes du cycle ?
Définir un problème sous forme d'hypothèse. Définir une solution. La développer et la mettre sur le marché. La faire tester par de vrais utilisateurs. Puis recommencer avec le problème suivant, révélé par ces tests.
Pourquoi ne pas faire d'étude de marché ?
Sur une idée qui existe déjà, l'étude a du sens : les données existent. Sur une idée nouvelle, personne ne peut dire s'il achèterait un produit qu'il n'a jamais vu. L'étude donne alors une fausse assurance, payée plusieurs mois.
Que signifie construire le minimum ?
Assez pour apprendre quelque chose de vrai, pas assez pour tout risquer. Le critère n'est pas le nombre de fonctionnalités : c'est de savoir quelle hypothèse précise ce prototype permet de vérifier.
Que demande vraiment cette méthode ?
De pouvoir construire vite. Une boucle d'apprentissage qui prend six mois n'est plus une boucle : c'est un projet classique sous un autre nom.
