90% des startups ou projets innovants échouent lors de la première année, c’est le constat que fait Eric Ries, auteur du livre “The Lean Startup” qui baptisera donc la méthodologie du même nom. Selon lui, la cause principale de cet échec précoce est la part du temps, de l’énergie et de l’argent alloué à des idées qui ne fonctionnent pas.
Jusque-là tout le monde peut être d’accord avec Eric Ries, l’idée selon laquelle il est plus probable d’échouer lorsque l’on travaille sur quelque chose que ne fonctionne pas est assez communément admise. L’important ici est moins le fait de fournir des efforts sur quelque chose voué à l’échec que de s’en apercevoir trop tard.
Ainsi, lorsqu’une entreprise ou un projet de manière générale est en phase de lancement, le temps est compté. Chaque jour passé à travailler sur une hypothèse de solution est un risque pris qui engage donc un risque financier.
Comment cadrer un projet no-code ?
Découvrez notre nouveau livre blanc dédié au cadrage d'un projet no-code. 35 pages sur notre méthodologie.
Avant de poursuivre essayons de faire une différence dans ce rapport au risque entre une idée de business “classique” et une idée “innovante”.
Dans le cas d’une idée de business classique, c’est-à-dire lorsque vous comptez développer une offre qui existe déjà, par exemple créer une boulangerie, il n’est pas anormal de passer des mois sur une étude de marché pour définir quelle sera votre cible, où vous devrez vous implanter, etc. Vous ne créez pas de nouvelle offre ni créez de nouveau marché. L’intérêt des consommateurs pour votre produit est déjà établi.
Dans le cas d’un projet innovant où votre ambition est de créer un nouveau produit ou service vous basez l’intégralité de votre capacité à réussir votre lancement sur des hypothèses jusque-là non vérifiées. Vous allez donc passer du temps à développer une solution à un problème dont l’existence ne tient qu’à votre intuition. Ça n’est d’ailleurs pas un problème en soi mais le fait de passer 6 mois à concevoir une solution pour finalement se planter en est un. Car à part si vous disposez de ressources illimitées, un échec au lancement après une phase de conception très longue est souvent synonyme de coup d’arrêt.
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 :
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.
Créer une application dans laquelle déposer ses 3 meilleures photos pour les recevoir encadrées.
Développement de cette application et mise sur le marché.
Mes potentiels clients testent mon application et me font des retours.
Et on recommence.
Mes utilisateurs ne font pas l’effort de déposer 3 photos.
Je me base sur leurs posts Instagram pour définir par défaut les 3 meilleures photos.
Je me connecte en API à leur compte pour récupérer les photos.
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.
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.
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.
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.
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.
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.
Nous avons basculé la partie utilisateurs sur une interface Bubble, toujours lié à Airtable en base.
Nous avons basculé la partie admin sur Bubble, toujours lié à Airtable en base.
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é.
Le choix d’un environnement technique basé sur des solutions no-code va donc vous permettre d’itérer rapidement sur vos différentes solutions mais cela va aussi vous inciter fortement à être dans une démarche de “test and learn” où la valeur d’une idée ou d’une intuition est beaucoup moins élevée que celle d’un retour client.
Il est donc important et ce, que vous choisissiez des solutions no-code ou non, d’accepter de s’être trompé pour recommencer et d’accepter de lancer un produit ou service qui ne ressemble pas à la vision à 3 ans que vous avez de lui.
.jpg)
Cette méthode est une approche systématique de résolution de problèmes qui consiste à se poser cinq fois la question "pourquoi" pour identifier la cause racine d'un problème. Elle permet ainsi de déterminer les solutions les plus adaptées pour résoudre un problème et de les mettre en œuvre de manière efficace.
On entend beaucoup parler de no code et son impact sur les process en entreprises mais comment savoir si votre projet no code tient ses promesses ?
"Le no-code c'est parfait pour commencer", alors oui, mais pas seulement.
Essayons de démystifier quelques idées reçues tout en dessinant les quelques limites du no-code.
