LE REPLAY : https://www.youtube.com/watch?v=7tJYcM9sMwc&t=1s&ab_channel=No-codeFrance
[POINT#1]
La première Table ronde organisée par la guilde professionnalisation de l'association Nocode France sur "comment organiser sa stack d'outils Nocode" nous amène peut-être à revoir UNE définition :
L'approche "modulaire" versus l'approche "tout intégré" !? 💡
"Finalement tout est [une approche] modulaire, Bubble tu ne l'utilises jamais seul".
Certes, on cristallise beaucoup sur le fait de qualifier Bubble comme un outil "tout-en-un", et c'est que nous retrouvons souvent comme qualificatif au sein de la communauté NCF, mais prenons ce postulat…
... qui finalement ne tient pas.
Pourquoi ?
Nous l'avons mentionné lors cet échange, notamment Thibault Marty, la myriade de plugins qui existent dans l'écosystème Bubble et que l'on utilise pour répondre au besoin de son client, est compte fait une approche modulaire.
Nous aurons beau avoir deux corps de métiers bien différents (un plombier et un menuisier, par exemple) possédants chacun une même stack d'outils (un marteau ou une clé de 12), ce n'est pas pour le même besoin qu'ils l'utiliseront. L'outil que l'on propose s'adapte au besoin, et non l'inverse.
Dans le même temps, la notion de MSV (Minimum Stack Viable) qu'évoque Florent Isidore prends tout son sens.
🔖BREF :
Utiliser (pourquoi pas) la notion du QQOQCP pour bien comprendre et cerner le besoin de son client, car c'est là la finalité. Ensuite seulement on s'adapte avec l'outil qui y répondra le mieux.
[POINT#2]
Le fait d'avoir une approche dite "modulaire", c'est-à-dire séparer le back du front et y mettre une logique d'intégration pour coller le tout peut être vu avec certains avantages :
✅ Diversifier ses outils permet de ne pas être dépendant que d'un seul, notamment si celui-ci venait à disparaitre (quoique…si jamais l'outil venait à disparaître nous rappelle Thibault, il n'est pas rare que l'éditeur le transforme en open-source et le metet à disposition pour la communauté. Il est donc possible de faire une transition progressive sur un autre dans le pire des cas.
✅ Il est plus facile de maîtriser les performances de sa solution et ne changer qu'une brique plutôt que de tout refaire (exemple en changeant un backend en le faisant évoluer d'un Airtable à un Xano puis à un PostgreSQL)
✅ C'est peut-être un peu plus abordable pour les personnes n'ayant pas de connaissances de développement, car la courbe d'apprentissage de certains outils nocode est bien plus longue.
... et certains inconvénients tels que :
❌ Maintenir en condition opérationnelle (MCO) est toutefois bien plus complexe, y compris réaliser le monitoring de sa solution
❌ À multiplier le nombre d'outils dans sa stack, nous perdons peut-être un peu d'expertise sur les principaux, et ne pas oublier qu'il faut faire une veille active sur ces derniers
❌ Et en plus documenter sa solution lorsqu'on utilise plein d'outils est bien plus fastidieuse.
🔖 BREF :
Partir avec Bubble comme solution technique, par exemple, c'est que votre client a déjà bien mûri son projet. Partir sur une stack de quelques outils pour réaliser un MVP ou tester son marché, c'est certainement là que l'approche modulaire joue son rôle. Vous ne trouvez pas ?
[POINT#3]
⚗️Dernier point et non des moindres !!
Le débat que nous avons animé pour l'association #NocodeFrance a révélé une liste assez exhaustive de critères à étudier dans le choix d'un outil #nocode.
Bien choisir tes outils nocode, tu devras obligatoirement :
✅ Vérifier qu'il existe un modèle économique viable
➡️ Fremium c'est bien, mais l'éditeur doit maintenir sa plateforme et son infrastructure... ça coûte
✅ Vérifier que la plateforme existe depuis quelque temps
➡️ Plus l'outil est vieux, plus il y a une expertise de certaines personnes qui auront la connaissance ... à condition également d'avoir une communauté active autour du produit
✅ Vérifier qu'il existe un cycle de mise à jour régulier
➡️ Ne pas avoir de nouvelles releases pendant un temps peut t'inquiéter sur la bonne santé en interne chez l'éditeur
✅ Vérifier qu'il existe un help desk sur la plateforme
➡️ S'assurer que le support est correct, rapide et efficace
✅ Vérifier que la sécurité est un critère considéré au moins par l'éditeur
➡️ Le ticket d'entrée des outils nocode est tellement faible que ne pas prendre en compte cet aspect dès le début engendra des soucis futurs
✅ Vérifier si le modèle économique de prix correspond au budget de ton client
➡️ Certaines plateformes facturent à l'utilisateur, certaines aux nombres de lignes, etc...
Et puis il te faudra peut-être aussi :
✔️ Connaître les critères "excluants" de ton client
➡️ Car certains outils ne sont pas multilingues, conformes RGPD ou HDS
✔️ Connaître le degré de personnalisation de l'UI/UX de ton outil
➡️ Car il te faut cibler les utilisateurs finaux de ta solution
✔️ Connaître le degré d'autonomie recherché par ton client
➡️ Va-t-il être capable de prendre la main une fois la solution livrée ou pas ? Le veut-il ?
✔️ Connaître la stack actuelle de ton client et la compétence associée
➡️ Afin peut-être de commencer petit et faire évoluer la solution progressivement en fonction de sa maturité
Bonus comme le dit Joyce Kettering :
✔️ S'il existe un channel slack sur NocodeFrance
➡️ C'est bon signe
🔖 LAST BUT NOT LEAST : L'idéal serait de modéliser un arbre de décision lorsqu'on doit chercher quels outils #nocode peut répondre au besoin de nos clients. Qui se lance ?