Les dix commandements d'une plateforme no-code mature
Un entrepreneur ou un développeur no-code est très sensible aux diverses possibilités techniques des outils no-code, comme la capacité à afficher une carte Gmaps, faire une saisie par scan de QRCode ou générer une App mobile native. Par contre, la sensibilité aux fonctionnalités liées au développement, comme la gestion des versions par exemple, est beaucoup plus faible. Et pourtant, ces fonctionnalités de développement deviennent absolument indispensables lorsque le projet no-code va au-delà du démonstrateur. Les plateformes no-code ne s’y trompent pas et se mettent progressivement à niveau pour fournir à leurs utilisateurs des outils à la hauteur de ce qui existe dans le développement professionnel standard (avec code).
Cet article présente les dix commandements qu’une plateforme de no-code doit suivre pour vous accompagner sur des projets dont l'ambition dépasse l'application de démonstration ou le MVP jetable
Pour finir nous avons appliqué ces commandements à deux outils phares du marché : Adalo et les 10 commandements et Bubble et les 10 commandements.
Les dix commandements du NoCode
Pour chaque commandement nous indiquons les fonctionnalités minimales attendues, les fonctionnalités standards et l’idéal. Par ailleurs, nous précisons les difficultés que vous allez rencontrer si la plateforme n’est pas suffisamment mature et n’atteint pas le minimum syndical.
| Quel est le minimum syndical attendu | Que doit fournir une plateforme mature | Ce dont on rêve | Quelles difficultés si la plateforme n’est pas mature |
Les dix commandements
| I | Du support tu fourni__ra__s |
| II | Les trois piliers d’une application tu couv__rir__as |
| III | Les sessions utilisateurs tu __gé__reras |
| IV | La réutilisation tu permettras |
| V | Extensible, ta plat__ef__orme sera |
| VI | API R__ead__y tu seras |
| VII | Versions et environnem__ents__ tu géreras |
| VIII | Multi-dév__el__oppeur tu seras |
| IX | Une offre tarifaire adaptée et progressive tu offriras |
| X | Un hébergement flexible tu permettras |
I - Du support tu fourniras
Pourquoi est-ce important ?
Lors du développement no-code, comme dans tout type de développement, le développeur va toujours rencontrer des difficultés à faire en sorte que l’application fasse ce qu’il veut. Il y a toujours des choix de conception à faire (quel(s) composants utiliser pour résoudre mon problème), des patterns d’usage (comment assembler mes composants pour aboutir au résultat ?), des cas qui ne sont pas couverts explicitement par la documentation et, bien sûr, des bugs. Pour être efficace, il faut pouvoir trouver de l’aide.
Les différents niveaux de maturité:
| Un forum actif des utilisateurs | |
| Un support en anglais par email | |
| Un support éditeur en français qui répond rapidement | |
| S’il n’y a pas de support, vous allez perdre du temps à chercher des solutions et plus probablement être bloqué. Une communauté dynamique est aussi l’indication d’un produit qui vit. Sauf à ce que la plateforme soit extrêmement jeune, passez votre chemin. |
Maturité : Du support tu fourniras
II- Les trois piliers d’une application tu couvriras : Interface homme machine + traitement + stockage
Une application complète doit pouvoir interagir avec l’utilisateur (affichage et saisie), effectuer un minimum de traitements sur les données et finalement doit pouvoir stocker de l’information. Un outil qui ne présenterait, par exemple, que de l’affichage et du stockage, va devoir s’interfacer avec un autre outil pour faire des traitements, ce qui va complexifier le développement de l’application.
AirTable était dans ce cas avant d’introduire les scripting blocks. Pour implémenter un traitement, il fallait récupérer les données dans Zapier, les traiter et renvoyer le résultat dans AirTable.
Les différents niveaux de maturité:
| Une IHM de type WEB, des traitements de type conditionnel ( “if.. then .. else”), un stockage de type “tableur” | |
| Une IHM de type WEB Responsive, la gestion de logique plus complexe combinant un enchaînement de traitements (conditions, boucles, support de variables, mise à disposition de fonctions de traitement de dates, chaînes et listes) . Un stockage supportant des relations entre entités. | |
| Des IHM Web et mobiles avec la possibilité d’applications natives. La gestion de logique côté client et côté serveur. La possibilité de combiner des workflows | |
| Si un des piliers est manquant, examinez la road-map de l’éditeur. Ce sont des produits qui évoluent vite. Si rien n’est prévu, choisissez une autre plateforme. |
Maturité : Les trois piliers d’une application tu couvriras
III - Les sessions utilisateurs tu géreras
De nombreuses fonctionnalités ne peuvent être fournies qu’en ayant enregistré des informations relatives aux actions de l’utilisateur (identifié ou non), par exemple, n'afficher la page de préférences que lors de la première utilisation de l’application. Ce mécanisme de session est aussi nécessaire pour mettre en place l’authentification des utilisateurs qui est un prérequis à de nombreux cas d’utilisation, globalement dès que l’utilisateur a un rôle actif : effectuer une réservation ou une commande, poster un commentaire, se mettre en relation avec un autre utilisateur etc...
Les différents niveaux de maturité:
| Capacité à gérer une session utilisateur et se loguer avec un user et un mot de passe | |
| Gérer nativement les workflows de réinitialisation et changement de mot de passe (envoi d’email par exemple). Possibilité d’étendre les attributs (informations) liés à l’utilisateur | |
| Intégration avec les systèmes d’authentification tiers de type Google, Okta, Facebook, Microsoft... | |
| Si rien n’est fourni il pourra être possible, suivant la plateforme, de rajouter cette fonctionnalité en faisant appel à des composants tiers (voir Extensible, ta plateforme sera), par exemple sur Webflow on peut utiliser FireBase ou MemberFlow. Si le besoin est limité, comme par exemple avoir l’identité de l’utilisateur pour lui envoyer un email, cela est acceptable. Cependant si de nombreuses fonctionnalités sont liées à l’identité de l’utilisateur, chacune de ces fonctionnalités va se retrouver complexifiée. |
Maturité : Les sessions utilisateurs tu géreras
IV - La réutilisation de groupes de composants tu permettras
Dès qu’une application prend de l’ampleur des éléments graphiques, comme le menu, les en-têtes ou bas de page vont se retrouver sur toutes les pages. D’autres traitements comme des contrôles de saisie peuvent se retrouver sur de multiples pages. La duplication de ces éléments n’est pas viable car une modification ultérieure devra être répétée sur chaque réplicat. Pour pouvoir développer des applications dépassant la dizaine de pages, la plateforme no-code doit fournir un mécanisme de création de blocs de composants réutilisables.
Les différents niveaux de maturité:
| Capacité à réutiliser un groupe de composants graphiques sur plusieurs pages (par exemple un menu) | |
| Possibilité de créer des groupes de composants graphiques avec des paramètres qui sont passées à chaque instanciation du groupe | |
| Possibilité de créer des composants côté traitement (fonctions) réutilisables à l’intérieur d’autres traitements | |
| Si rien n’est fourni, la maintenance d’applications de plus d’une dizaine de pages va s’avérer extrêmement coûteuse. |
Maturité : La réutilisation de groupes de composants tu permettras
V - Extensible, ta plateforme sera
Lors de l’utilisation de plateformes no-code il est important de se limiter à utiliser les fonctionnalités fournies en standard par la plateforme. Cependant, il peut arriver qu’une fonction absolument obligatoire ne soit pas possible via des composants standards. Pour répondre à ce besoin et éviter un blocage, la plateforme de no-code doit offrir des mécanismes permettant d’intégrer du code de manière contrôlée : c’est l’extensibilité. Il peut s’agir de composants génériques que l’utilisateur scripte directement à l’intérieur de la plateforme de no-code ou carrément de nouveaux composants développés en utilisant des langages classiques (javascript, java, .net, ...) et intégrés ensuite dans la plateforme de manière à être utilisés de la même façon que les composants natifs. Cette dernière capacité a l’avantage d’accélérer le développement de nouveaux composants en s’appuyant sur un écosystème lié au produit.
Les différents niveaux de maturité:
| Fournir d__es composants génériq__ues comme par exemple un composant pouvant accueillir du javascript et du code HTML | |
| Fournir la documentation et les outils (compilateurs, scripts) permettant de développer et de packager __des nou__v__eaux compo__sants qui seront ensuite utilisables par la plateforme comme des composants natifs | |
| Fournir une place de marché permettant de publier les composants de manière privée ou publique, gratuite ou payante | |
| Si la plateforme n’est pas extensible, un besoin métier non couvert par la plateforme n’aura pas de plan B. Il sera nécessaire d’attendre les évolutions de la plateforme ou la recherche d’une solution de contournement. C’est un risque accru à assumer pour le projet. |
Maturité : Extensive ta plateforme sera
VI - API Ready tu seras
Une application ne reste pas isolée longtemps et est amenée à s’intégrer dans son écosystème, que ce soit dans l’entreprise ou avec des partenaires. Pour permettre cette intégration, de manière directe ou via des outils comme Zapier, la plateforme doit fournir des APIs qui seront consommables par des tiers. Elle doit aussi donner la capacité à notre application no-code d’appeler des APIs externes, par exemple pour obtenir des informations qui permettront d’alimenter des collections.
Les différents niveaux de maturité:
| Pouvoir échanger des flux sécurisés via des plateformes d’intégration de type Zapier ou Integromat | |
| Pouvoir appeler des API REST externes à partir de l’application no-code. Fournir des APIs REST génériques appelables depuis d’autres applications de type no-code ou non. Sécurisation par api-key ou secret partagé. | |
| Publication des APIs spécifiques à l’application développée.<br><br>Gestion avancée de la sécurité pour les appels sortants et entrants (management d’api key pour les API implémentées sur la plateforme, intégrations de type OAuth2) | |
| Si rien n’est fourni, la plateforme de no-code ne permettra que des applications isolées. Cela limite les cas d’utilisations |
Maturité : API Ready tu seras
VII - Versions et environnements tu géreras
Une fois que l’application est en production on veut pouvoir travailler (développer, tester, homologuer) sur les évolutions sans casser la production, pour cela il faut plusieurs environnements. Pour avoir plusieurs environnements, il faut savoir gérer des versions : reprendre la version de production pour faire une évolution corrective, pousser la version de développement en production. La gestion de version est aussi un outil d’investigation très pratique lorsqu’une régression apparaît lors du développement ; il est possible de voir ce qui a changé, voire revenir sur des versions intermédiaires pour mieux cerner le problème.
Finalement, la gestion de version est aussi un prérequis pour travailler de manière pérenne à plusieurs sur la même application (gestion des modifications concurrentes)
Les différents niveaux de maturité:
| Avoir plusieurs environnements avec chacun une version de l’application, pouvoir faire passer les applications d’un environnement à l’autre | |
| Pouvoir comparer les différences entre deux versions de l’application, être capable de revenir sur une version passée | |
| Avoir la capacité à gérer des branches parallèles de versions, les merger en gérant les conflits, fournir une copie de travail isolée pour chaque utilisateur | |
| Sans gestion minimale de version et d’environnement il va falloir utiliser des mécanismes manuels de duplications et de sauvegardes, voire reporter les modifications deux fois. Ne convient qu’à des applications de faible envergure et avec un faible nombre d’utilisateurs (quelques dizaines de pages et d’utilisateurs), ou des applications qui fonctionnent par campagne (ouverture pour une date et une durée limitée et ensuite fermeture). |
Maturité : Versions et environnements tu géreras
Automatisation des tests
La notion d’environnement est intimement liée à la notion de test : si on a besoin d’un environnement de développement ou de qualification c’est pour pouvoir tester avant de mettre en prod ! L’objectif numéro 1 est d’éviter qu’une évolution crée un bug qui n’existait pas avant : on parle de régression. La mise en place de tests de non régression automatisés devient rapidement indispensable quand la taille de l’application augmente. Dans le monde no-code il sera possible de tester au niveau de fonctions métiers (appelés workflows en général) ou au niveau de l’interface utilisateur. L’automatisation des tests au niveau de l’interface utilisateur passe par l’utilisation d’outils no-code spécialisés permettant d’enregistrer, variabiliser et rejouer les séquences utilisateurs les plus importantes. Il existe de nombreux outils dont testProject, testComplete, Pcloudy ou AccelQ .
VIII - Multi-développeurs tu seras
Parce qu’il est très rare qu’une application soit développée par une seule personne. Parce que toutes les parties prenantes de l’équipe doivent être autonomes et faire évoluer l’application.
Les différents niveaux de maturité:
| Permettre à plusieurs développeurs no-code de travailler sur l’application avec leur propre profil utilisateur et une gestion minimaliste des conflits (le dernier qui modifie l’emporte) | |
| Gérer les conflits de modification de manière explicite pour les développeurs (alertes, blocage de modification) | |
| Permettre à chaque utilisateur de travailler de manière autonome et fusionner les modifications en gardant la trace des modifications de chacun | |
| Sans capacité de travail collaboratif, l’ambition des applications développées sera réduite et devra être compensée par une grande coordination des intervenants |
Maturité : Multi-développeurs tu seras
IX - Une offre tarifaire adaptée et progressive tu offriras
Parce que l’on veut pouvoir payer suivant l’activité de la plateforme. Ne pas payer cher au début et ensuite acheter plus de services pour soutenir la croissance et garantir une qualité de service aux utilisateurs finaux de l’application. En plus de la progressivité, le modèle de tarification doit être adapté au cas d’utilisation, par exemple tarification à l’application, à l’utilisateur, au développeur, ou à la consommation machine.
Les différents niveaux de maturité:
| Offrir une offre “free” pour tester la plateforme et une offre qui permette de commencer de manière opérationnelle pour moins de 100 Euros/Mois | |
| Une évolution de la tarification qui permette d’obtenir de nouveaux services (multi-utilisateurs) et composants (scanner QR Code) évolués. | |
| Une offre de puissance de calcul adaptée à son usage qui permet de passer les premiers caps de croissance : garantir des ressources minimales et une qualité de service pour un coût non prohibitif. Par exemple, Bubble permet de réserver progressivement des ressources de calculs, appelées reserved units, à partir du plan professionnel. | |
| Même avec une offre progressive, le mode de tarification peut devenir prohibitif si le modèle de tarification n’est pas adapté. Par exemple une plateforme qui tarifie à l’utilisateur mensuel, alors que l’on a une application utilisée peu souvent, mais par de nombreux utilisateurs. |
Maturité : Une offre tarifaire progressive tu offriras
X - Un hébergement flexible tu permettras
Les questions d’hébergement recoupent des enjeux techniques (performances), réglementaires (RGPD) et stratégiques (sensibilité des données pour l’entreprise). Une rigidité sur l’hébergement peut à lui seul être une contre-indication à un choix d’une plateforme no-code. Attention toutefois à ne pas être trop exigeant car dans le domaine du no-code demander un hébergement ‘on-premise’ réduit à la fois l’offre du marché et l’intérêt apporté par ces solutions, notamment en termes de déploiement, disponibilité, administration et scalabilité.
Les différents niveaux de maturité:
| Pouvoir choisir sa zone géographique | |
| Pouvoir choisir un provider de cloud. Avoir une information sur l’accès aux données, pouvoir chiffrer les données sensibles. | |
| Pouvoir faire héberger sur son cloud, dans un cloud RGPD ou ‘on premise’ | |
| Un hébergement non compatible avec les exigences du client, (localisation en Europe, transparence sur les opérations, compatibilité RGPD) peut constituer à lui seul un blocage pour utiliser la solution |
Maturité : Un hébergement flexible tu permettras
Les 10 commandements et Adalo
Pour une plateforme de no-code (et pas low-code), Adalo est relativement complète. Elle a cependant trois lacunes : pas de réutilisation de groupe de composants, pas de gestion d'environnements et un seul hébergement aux Etats-Unis. Cela implique qu’il sera difficile de développer des applications qui dépassent quelques dizaines d’écrans. De plus, si un hébergement en Europe est exigé, la plateforme ne pourra pas y répondre.
| I- Du support tu fourniras | Un contact nommé chez Adalo (Account manager) avec support par email | |
| II- Les trois piliers d'une application tu couvriras | Les trois piliers sont couverts, la partie processing est minimale | |
| III- Les sessions utilisateurs tu gereras | Gestion du workflow utilisateur, possibilité de personnaliser les champs. Sign in avec Google et Apple. D’autres, comme facebook, sont en cours d'implémentation | |
| IV- La réutilisation de composants tu permettras | Uniquement de la duplication sans possibilité de réutilisabilité | |
| V- Extensible ta plateforme sera | Absence de composants génériques scriptables prêts à l’emploi.<br><br>Possibilité de créer ses composants et de les publier sur la place de marché, mais les composants sont uniquement publics | |
| VI- API Ready tu seras | Possibilité d’appeler des APIs et publication d’APIs génériques pour accéder aux données | |
| VII- Versions et environnements tu géreras | Absence de gestion d’environnements | |
| VIII- Multi-développeur tu seras | Le multi-utilisateur est supporté | |
| IX- Une offre tarifaire adaptée tu offriras | Une offre tarifaire progressive qui permet d’avoir plus de fonctionnalités mais pas plus de garanties sur les performances | |
| X- Un hébergement flexible tu permettras | Pas de choix. Les applications sont exclusivement hébergées sur AWS aux US |
Les 10 commandements et Bubble
Bubble est un outil qui est à la limite du low-code, sa prise en main est plus longue, mais il répond de manière maximale à pratiquement toutes les exigences et a n’a pas de lacune.
| I- Du support tu fourniras | Support de la communauté pour les versions gratuites, support éditeur par email pour les versions payantes | |
| II- Les trois piliers d'une application tu couvriras | Les trois piliers sont couverts, il est possible de créer des processus de manière visuelle. Par contre pas de packaging pour les applications mobiles | |
| III- Les sessions utilisateurs tu gereras | Gestion des utilisateurs, disponibilité de nombreux plug-in pour se connecter via Google ou les réseaux sociaux | |
| IV- La réutilisation de composants tu permettras | Réutilisation des composants graphiques via les “Reusable elements” avec possibilité de paramétrage. Réutilisation de portions de processus via les “Custom Events” | |
| V- Extensible ta plateforme sera | Possibilité de créer ses composants, appelés plug-in. Place de marché pour publier ses composants qu’il est aussi possible de garder privés | |
| VI- API Ready tu seras | Capacité à appeler et exposer des API avec diverses méthodes de sécurisation | |
| VII- Versions et environnements tu géreras | Gestion de versions élaborée (branches) et multiples environnements | |
| VIII- Multi-développeur tu seras | Multi-utilisateurs supporté, associé à une gestion fine des conflits | |
| IX- Une offre tarifaire adaptée tu offriras | Plans qui permettent d’avoir plus de fonctionnalités et des capacités dédiées. Offre à l’attention des agences, permettant à un développeur d’avoir accès à toutes les fonctionnalités pour un prix réduit. | |
| X- Un hébergement flexible tu permettras | Bubble est hébergé chez AWS, il est cependant possible de choisir sa zone géographique |
Pour aller plus loin
- No-code/low-code : les trois bonnes raisons de s’y mettre ; https://blog.octo.com/no-code-low-code-les-trois-raisons-de-sy-mettre/
- La démocratisation du développement : https://www.youtube.com/watch?v=jXFKyC0tEiw&list=PLXlbmbYadKH5wS5tkVUDuP9ygC3lYOVaA&index=5