C’est avec beaucoup de plaisir que l'application Karl, mon majordome numérique, approche de son premier anniversaire.
J'ai du sortir une vingtaine de release au cours de cette année où énormément de choses ont été testées.
Je ne regrette pas une seule seconde d'avoir fait le choix de construire en nocode. Comme je l'explique plus bas, c'est en faisant qu'on apprend.
Les avantages de construire en nocode
Pour quelqu'un qui ne vient pas du monde informatique et qui ne sais pas coder, construire en no-code a deux très gros avantages :
Ca coûte beaucoup, beaucoup moins chère. En 1 an, avec une vingtaine de relase, je pense que ça m'aurait coûté plus de 100 000 euro si j'avais du utiliser un prestataire externe. Avec les outils nocode utilisés, je suis à moins de 5000 euro.
Développer soi-même, avec les outils nocode, permet de réellement confronter son idée à la réalité du fonctionnement d'une application. Les logiques de développements ne sont pas nécessairement intuitives. Il y a des contraintes auxquelles on ne pense pas lorsqu'on imagine son idée. Par contre, en faisant, en construisant sa base de donnée, les fonctions et les rendus visuels, là on se rend compte des limites de l'idée.
Les enseignements de construire en nocode
En premier lieu, construire en nocode permet de comprendre ce qui constitue une application :
Les bases de données
Les liens entre les différents éléments des bases de données
Les fonctionnalités
L''interface utilisateur
Le community mangement
Je pense que le plus gros enseignement est que mon idée n'étais pas prête. On le sait qu'il est nécessaire de faire beaucoup d'itérations pour arriver à concrétiser quelque chose d'utile. On le lit partout. Mais j'étais tellement persuadé que mon idée était parfaite que je pensais que ce serait un peu différent dans mon cas. Evidemment il n'en était rien.
En faisant appel à des prestataires j'aurais généré beaucoup de frustration :
N’ayant pas l’expérience, je n’aurai pas su gérer correctement un prestataire de développement d’une application. Mes demandes auraient été floues, mal articulées, et parfois irréalisable…
Et surtout, mon idée, aussi séduisante qu’elle me paraissait, n’était pas mâture. En réalité j’avais grand besoin d’éprouver mon idée à la dure réalité du terrain pour comprendre les vrais besoins.
Faire soi-même c'est s'approprier les contraintes.
En s'appropriant les contraintes, on comprend les limites de ses idées, et on peut alors réfléchir à ce qui est vraiment nécessaire. Ce sont les renoncements qui font la qualité.
Ce que j'ai particulièrement aimé, c'était toutes les fois ou j'ai dû me poser et forcer la simplification de l'application :
Enlever les fonctions superflues,
Enlever les écrans inutiles,
Nettoyer les bases de données.
Je n’ai jamais vraiment eu « honte » des release, car j’étais trop content de pouvoir concrétiser mon idée. Cela dit, je pense être arrivé à un état de l’application qui est proche d’une version aboutie. Ce ne sera jamais terminé, mais cette version apporte vraiment une solution fonctionnelle et efficace au problème identifié.
Reste à voir si ce problème représente une souffrance suffisante pour d’autres qui justifierait l’utilisation de mon application Karl. La deuxième phase de l'application commence maintenant !
Votre dévoué majordome,
Comments