Les offres de plateforme no code se mettent progressivement à niveau. Petit à petit elle fournissent à leurs utilisateurs des outils à la hauteur de ce qui existe dans le développement professionnel standard (avec code).

Un entrepreneur ou un développeur no-code est très sensible aux diverses possibilités techniques des outils no-code. 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à de la simple “démo”.

Dans cet article vous trouverez les dix questions à vous poser avant de choisir une plateforme no-code. Des questions qui vous permettront d’identifier les plateformes qui vous accompagnent sur des projets au delà de la simple démo ou du MVP jetable. 

Pour vous aider dans votre choix de plateforme No Code

Pour vous aider à choisir les plateformes no code qui correspondent aux besoins de vos projets, vous trouverez en dessous de chaque question :

1. Les fonctionnalités minimales attendues (pour des besoins de base),
2. Les fonctionnalités standards (pour aller au delà de la phase de test),
3. L’idéal (pour faire évoluer votre projet dans le temps tout en optimisant vos charges).

C’est parti !

1 – Est-ce que la plateforme no code propose du support ?

Pourquoi est-ce important ?

Lors du développement no-code, comme dans tout type de développement, vous allez toujours rencontrer des difficultés à faire en sorte que l’application fasse ce que vous voulez.

Il y a toujours des choix de conception à faire :

• Quel(s) composants utiliser pour résoudre votre problème ?
• Comment assembler les composants pour aboutir au résultat ?
• Est-il possible de résoudre des cas qui ne sont pas couverts explicitement par la documentation ?
• Et la gestion des bugs ?

Pour être efficace, il faut pouvoir trouver de l’aide.

Les différents niveaux de maturité :

1. Un forum actif avec des utilisateurs qui posent régulièrement des questions,
2. Un support en anglais accessible par chat ou par email,
3. Un support éditeur en français qui répond rapidement lorsque vous le sollicitez.

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. A moins que la plateforme ne soit extrêmement jeune, passez votre chemin.

2 – Est-ce qu’elle propose une Interface Homme Machine avec du traitement et du stockage

Pourquoi est-ce important ?

Une application complète doit pouvoir interagir avec vous (affichage et saisie). Vous permettre d’effectuer un minimum de traitements sur les données et finalement vous donner la possibilité de stocker de l’information.

Un outil qui ne présenterait, par exemple, que de l’affichage et du stockage, va vous obliger à utiliser un autre outil pour faire des traitements, ce qui va rendre compliqué le développement de l’application.

AirTable par exemple é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 encore une fois.

Les différents niveaux de maturité :

1. Une Interface Humain Machine de type WEB, avec des traitements de type conditionnel (“if.. then .. else”) et un stockage de type “tableur”,
2. Une IHM de type WEB Responsive, avec 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). Et aussi un stockage supportant des relations entre entités,
3. 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.

3 – Est-ce que vous pouvez créer des sessions utilisateurs ?

Pourquoi est-ce important  ?

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. Un prérequis à de nombreux cas d’utilisation. Exemple : 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é :

1. Capacité à gérer une session utilisateur et se loguer avec un user et un mot de passe,
2. Gérer nativement les workflows de réinitialisation et de changement de mot de passe (envoi d’email par exemple). Possibilité d’étendre les attributs (informations) liés à l’utilisateur,
3. Intégration avec les systèmes d’authentification tiers de type Google, Facebook, Microsoft…

Si rien n’est fourni, il sera possible, suivant la plateforme, de rajouter cette fonctionnalité en faisant appel à des composants tiers. 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, il vous sera difficile d’obtenir ce que vous voulez.

4 – Les groupes de composants sont-ils réutilisables ?

Pourquoi est-ce important ?

Dès qu’une application prend de l’ampleur des éléments graphiques comme le menu, les en-têtes ou le bas de page vont se répéter sur toutes les pages. D’autres traitements comme des contrôles de saisie peuvent se retrouver sur de multiples pages aussi. Une plateforme qui ne permet pas la duplication des éléments n’est pas viable.

Si vous devez refaire la conception à chaque fois que vous utilisez un éléments dans un nouvel emplacement, votre productivité et votre créativité seront rapidement impactés.

Pour pouvoir développer des applications dépassants 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é :

1. Capacité à réutiliser un groupe de composants graphiques sur plusieurs pages (par exemple un menu),
2. Possibilité de créer des groupes de composants avec des paramètres et des actions enregistrés. Ainsi, quelque soit l’endroit où vous l’utilisez, le groupe fonctionnera avec les mêmes propriétés,
3. 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.

5 – Est-ce que la plateforme no code est extensible ?

Pourquoi est-ce important ?

Lors de l’utilisation des 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, la plateforme 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 vous scriptez directement dans la plateforme,
• nouveaux composants que vous développez avec des langages classiques (javascript, java, .net, …),
• éléments que vous développez et que vous intégrez 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é :

1. Fournir des composants génériques comme par exemple un composant pouvant accueillir du javascript et du code HTML,
2. Proposer de la documentation et les outils (compilateurs, scripts) permettant de développer et de packager des nouveaux composants qui seront ensuite utilisables par la plateforme comme des composants natifs,
3. Disposer d’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.

6 – Est-ce qu’elle est API Ready

Pourquoi est-ce important ?

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é d’appeler des APIs externes pour obtenir des informations, par exemple, qui pourront alimenter des collections.

Les différents niveaux de maturité:

1. Pouvoir échanger des flux sécurisés via des plateformes d’intégration de type Zapier ou Integromat,
2. 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é,
3. Publication des APIs spécifiques à l’application développée. 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.

7 – Les gestions de versions et d’environnements sont-elles prévues ?

Pourquoi est-ce important ?

Une fois que l’application est en production vous voudrez 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 à plusieurs sur la même application (gestion des modifications concurrentes) de manière pérenne.

Les différents niveaux de maturité :

1. Avoir plusieurs environnements avec chacun une version de l’application. Pouvoir faire passer les applications d’un environnement à l’autre,
2. Pouvoir comparer les différences entre deux versions de l’application. Être capable de revenir sur une version passée,
3. Avoir la capacité de gérer des branches parallèles de versions. Les merger en gérant les conflits et en fournissant 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). Des applications, par exemple, qui fonctionnent par campagne (ouverture pour une date et une durée  limitée et ensuite fermeture).

8 – Vos développeurs peuvent-ils travailler en mode collaboratif ?

Pourquoi est-ce important ?

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é :

1. Permettre à plusieurs développeurs no-code de travailler sur l’application avec leur propre profil utilisateur et avec une gestion minimaliste des conflits (le dernier qui modifie l’emporte),
2. Gérer les conflits de modification de manière explicite pour les développeurs (alertes, blocage de modification),
3. 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.

9 – Est-ce que l’offre tarifaire est progressive ?

Pourquoi est-ce important ?

Parce que vous avez besoin de 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.

En plus de la progressivité, le modèle de tarification doit être adapté au cas d’utilisation. Par exemple une tarification à l’application, ou à l’utilisateur, ou au développeur, ou à la consommation machine.

Les différents niveaux de maturité :

1. 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,
2. Une évolution de la tarification qui permette d’obtenir de nouveaux services (multi-utilisateurs) et composants (scanner QR Code par exemple) évolués,
3. 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.

10 – Est-ce que l’hébergement de la plateforme no code est flexible ?

Pourquoi est-ce important ?

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 à elle seuls être une contre-indication à un choix d’une plateforme no-code. Attention, toutefois, à ne pas être trop exigeant. 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, de disponibilité, d’administration et de scalabilité.

Les différents niveaux de maturité :

1. Pouvoir choisir sa zone géographique,
2. Pouvoir choisir un provider de cloud. Avoir une information sur l’accès aux données, pouvoir chiffrer les données sensibles,
3. 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 géographique, transparence sur les opérations, compatibilité RGPD) peut constituer à lui seul un blocage pour utiliser la solution.