À l’occasion du Web2Day, le festival de la tech à Nantes, Agathe Guillemot, Développeuse chez theTribe, a animé une conférence sur le thème du low code.
Lorsque l’on veut lancer un produit ou améliorer une plateforme existante, comment utiliser les outils no code pour aller plus vite ?
Entre utiliser un produit no code payant et développer soi-même une fonctionnalité, comment choisir ?
Et si la réponse était entre les deux ?
Dans cet article qui reprend le contenu de sa conférence, elle répond à ces questions avec des exemples très concrets.
Sommaire :
- Nocode et code : et si on les faisait marcher ensemble, main dans la main ? 🤝
- Intégrer code et no code : 3 conseils pour ne pas se planter ! 🚀
- Le coût du code, ce n’est pas de l’écrire : c’est de l’entretenir 🛠
Nocode ou code ? Telle est la question 🤔
Quand on lance un business, un produit, tout part souvent d’une intuition. On a découvert un problème, et on pense avoir le début d’une solution. Cette intuition, on va vite avoir besoin de la confirmer avec des données collectées auprès des utilisateurs. Et ça va continuer. Le développement d’un produit n’est pas un process linéaire mais cyclique : il va falloir développer, tester, analyser les retours, itérer et recommencer.
Il faut tester à toutes les étapes :
- au début, quand on a encore très peu de fonctionnalités et d’utilisateurs ;
- au milieu, lorsque l’on commence à avoir un produit qui tient la route et des utilisateurs satisfaits ;
- et on va continuer ainsi, à chaque fois que l’on veut faire avancer son produit.
C’est une idée qui commence à être admise : elle a commencé à faire son chemin chez les designers, puis auprès des entrepreneurs et des développeurs.
C’est pour cela que les outils no code ont connu un essor important ces dernières années, avec de belles promesses :
- diminuer le temps et les coûts de développement,
- s’affranchir des problématiques techniques, notamment d’infrastructure et d’hébergement,
- ne pas avoir à trouver et payer des développeurs, qui sont des profils chers et difficile à recruter
Bref : le no code facilite le fait de lancer un produit et d’obtenir des retours, rapidement, à moindre coût.
Pourtant, le no code peine encore à s’imposer car il fait face à deux réticences, que l’on rencontre chez nos clients :
- Est-ce que mon produit sera aussi beau que je l’ai imaginé ? Est-ce qu’il va correspondre aux maquettes que j’ai pris tant de temps à designer ?
- Est-ce que le no code va me permettre de mettre en place toutes les fonctionnalités que je souhaite proposer à mes utilisateurs, sans limite ?
La réponse à ces deux questions est simple : NON, et NON.
Le no code permet d’aller plus vite.
Mais la conséquence de cette vitesse, c’est que l’on va perdre en finesse, en capacité d’optimisation et de personnalisation.
Alors on pourrait avoir envie de se dire : tant pis ! On va chercher des développeurs et on va tout faire à la main. On va pouvoir tout optimiser, tout personnaliser. Mais en contrepartie : ça va coûter cher, et ça va prendre du temps.
On peut résumer dans un tableau très simple les avantages des deux solutions.
| No code | Code |
| 👉 Rapidité 👉 Simplicité 👉 Pas besoin de compétences techniques 👉 Go to market accéléré | 👉 Flexibilité 👉 Optimisation 👉 Customisation totale 👉 Propriété du code |
Alors que faire ?
Nocode et code : et si on les faisait marcher ensemble, main dans la main ? 🤝
Moi qui travaille essentiellement sur des POC, des MVP, j’ai l’habitude des projets où il faut aller très vite, avec peu de moyens.
Et je trouve que c’est dommage de se priver du meilleur de ces deux mondes, qui ont énormément de qualités et de potentiel.
Quand on creuse, on se rend compte que la limite entre les deux est très poreuse. En étant malin, on va pouvoir tirer parti de ces deux univers pour construire des applications rapidement, les mettre dans les mains des utilisateurs, et ainsi valider ou invalider les hypothèses que l’on avait émises initialement.
Mais lorsque l’on réfléchit à une architecture hybride, la question qui se pose immédiatement, c’est : où est-ce qu’on met le curseur ?
Quelle partie de mon produit vais-je développer from scratch, quelle partie vais-je pouvoir déléguer à un outil no code ?
Comment concevoir une architecture hybride pour tirer le meilleur parti de ces deux mondes, a priori opposés ?
Pour répondre à ces questions, le plus simple c’est de partir du terrain. Voici quelques exemples que nous avons rencontrés chez des clients, et pour lesquels une solution hybride était la meilleure réponse à apporter.
Cas 1 : Pour développer une fonctionnalité expérimentale et tester une intuition 🔬
Dans cet exemple, on partait d’une application existante, développée en Flutter. Cette plateforme permet de mettre en relation les métiers de l’événementiel (DJ, magiciens, traiteurs…) et les organisateurs d’événements.
Notre cliente, la fondatrice, avait l’intuition qu’il serait intéressant de proposer une fonctionnalité de prise de rendez-vous.
Malheureusement, quand on va voir des développeurs et qu’on leur demande de mettre en place un calendrier de rendez-vous, la réponse c’est : “On va voir, dans 4 semaines, peut-être que l’on va pouvoir commencer à créer des rendez-vous”. Dans une petite entreprise, 4 semaines, c’est long, c’est cher : on ne peut pas se permettre d’investir autant si jamais ça ne marche pas.
La solution que l’on a apportée ?
Calendly : un outil SaaS de prise de rendez-vous.
Calendly permet de générer des plannings de rendez-vous, il se connecte à Google Calendar et Outlook : il permet même de payer en ligne pour valider le rendez-vous !
En intégrant Calendly à la plateforme, on est passés sur 4 ou 5 jours de développement répartis en quelques étapes simples :
- Créer et configurer le compte
- Intégrer Calendly au produit
- Mettre en place le tracking
En une semaine, on a donc pu faire tester la fonctionnalité par des utilisateurs et obtenir des retours.
L’avantage est évident : si jamais ça ne marche pas, tant pis, on a perdu seulement quelques jours.
Et si ça marche : on a confiance dans la réalité du besoin client. Si Calendly ne convient pas à long terme, si on souhaite un calendrier sur mesure, brandé aux couleurs de la plateforme : pas de souci ! Cette fois, on a l’assurance que l’argent sera investi utilement.
Cas 2 : pour accélérer un développement qui n’est pas core business 🏃♂️
Dans ce deuxième exemple, il s’agissait d’une plateforme de démocratie participative, qui permet de faire collaborer les collectivités locales et les citoyens. L’objectif : donner de la visibilité aux projets des collectivités et interroger les citoyens pour avoir leur avis. Le cœur de métier du client, c’était d’animer des événements, des projets, de communiquer autour.
Mais à un moment est arrivé le besoin de mettre en place des sondages. Sauf qu’ils ne savaient pas vraiment vers où ils allaient : un sondage par mois ? un par jour ? avec des questions ouvertes, des questions fermées ? Aucun moyen de le savoir !
Alors on avait deux possibilités :
- Développer un système basique : une questions, une série de réponses possibles et c’est tout. L’avantage : le coût limité (1 semaine de développement). L’inconvénient ? Les limitations : dès que l’on voudrait changer quelque chose, il faudrait à nouveau chiffrer, planifier, développer.. et donc dépenser de l’argent.
- Développer un système complet, permettant de gérer tout type de sondage : mais là, ça aurait pris des semaines, et le coût était trop élevé.
La solution que l’on a apportée ?
Typeform, un outil SaaS de gestion de questionnaires. Typeform est un outil ultra complet, qui dispose d’une API très bien documentée.
Avec Typeform, l’implémentation des sondages a été extrêmement rapide : en 1 semaine, c’était fait !
- Pas besoin de gérer les données, les questions, les réponses : Typeform le fait très bien ;
- Pas besoin de coder le formulaire en tenant compte des problématiques d’accessibilité ou de responsive, puisqu’il suffit d’intégrer le questionnaire dans une iframe.
| ℹ️ Une iframe permet d’embarquer un site web ou un morceau de site à l’intérieur d’un autre site. Les deux peuvent être hébergés à deux endroits différents et vivre leur vie de manière autonome : un peu comme quand on embarque une vidéo Youtube dans une page web. |
Alors certes : on l’a dit, implémenter un sondage basique aurait coûté 1 semaine également.
Alors, code vs no code : match nul ?
Hé non ! Là où on a énormément gagné, c’est sur l’évolutivité. Avec Typeform, si on voulait ajouter des questions ou les modifier, on n’avait quasiment rien à faire. Et ça, pour pouvoir itérer dans le futur, ça change tout.
Cas 3 : Recourir au code quand le nocode ne suffit pas ⚙️
Dans les 2 exemples précédents, on avait au départ un produit dont le cœur avait été développé en JS code, et que l’on a enrichis grâce au no code.
Mais que se passe-t-il si c’est l’inverse ?
Si 90% d’un produit peut se faire en no code, mais que l’on a besoin de code pour les 10% restant ?
C’est un cas de figure courant. Dans beaucoup de projets web, 90% du produit est basique : gérer des comptes utilisateurs, afficher des produits, gérer des paiements : des choses standard qui sont faciles à faire en no code. Mais il y a toujours au moins 10% du produit qui est spécifique au métier.
Est-ce une raison suffisante pour abandonner le no code ?
Pas forcément !
Rappelez-vous : il y a 2 raisons d’avoir peur du nocode :
- Quand on souhaite que son produit soit customisé visuellement ;
- Quand on a besoin de puissance et d’optimisation.
Enrichir le no code avec du code est une réponse à ces 2 limites.
Exemple 1 : Pimper un produit développé à 90% en nocode
Une de nos clientes voulait aider les étudiants à se loger lorsqu’ils arrivent dans une nouvelle ville : découvrir les quartiers, trouver un logement, déménager.
Son produit était relativement simple… MAIS ! Il y avait un élément différenciant, le “bonbon” du produit, celui qui fait l’effet Wahou : la carte de la ville.
Notre cliente lançait son produit sur Lille au départ, et elle avait dessiné elle-même une très jolie carte de Lille. L’idée : pouvoir survoler sa carte, et visualiser les infos sur chaque quartier (lieux importants, commerces, bars, loyer moyen…).
Tout le produit pouvait être développé en nocode avec Bubble, tout : sauf la carte.
Fallait-il, à cause de cette carte, abandonner Bubble et tout développer from scratch ? Le coût aurait été trop élevé : au moins 4 ou 6 semaines de développement.
La solution que l’on a apportée ?
Nous avons proposé de développer l’essentiel du produit avec Bubble, et d’intégrer la carte dans une iframe.
Combien de temps ça a pris ?
- 5 jours pour développer le site avec Bubble
- 5 jours pour développer la carte interactive
Résultat : en 10 jours à peine, on avait un produit utilisable !
Exemple 2 : Repousser les limites de performances du no code
Le low code permet donc d’apporter la petite couche de personnalisation visuelle qui est difficile à atteindre quand on se contente des fonctionnalités de base des produits no code.
Mais il permet aussi de régler les problématiques de performances auxquelles on est très vite confrontés avec les plateformes no code.
Par exemple, les performances sont un défaut connu de la plateforme Bubble. On ne va pas pouvoir exécuter des calculs complexes avec cet outil, sauf si on y injecte un peu de code.
Comment ?
En externalisant une partie du traitement avec du js code, en utilisant ce que l’on appelle des cloud functions (en l’occurrence, Lambda chez AWS, ou Cloud Functions chez Firebase).
On prend une formule d’abonnement Bubble qui expose l’API, on récupère les données qui ont été générées, on les envoie dans le cloud et on va pouvoir faire ce que l’on veut avec, y compris des opérations lourdes, complexes ou très spécifiques.
On récupère les résultats et on les injecte dans une nouvelle table Bubble. Ça, c’est typiquement l’intérêt de faire du low code, et non pas du no code pur et dur : on va pouvoir gagner énormément de temps et ça permet de repousser les limites des plateformes no codes, qui sont, il faut l’admettre, assez vite atteintes.
Cas 4 : Intégrer de nombreuses API 🔑
Ce dernier exemple me tient particulièrement à cœur, car c’est un projet que l’on a développé pour des besoins internes, chez theTribe.
Le problème de départ ?
Lorsqu’une nouvelle recrue arrive dans une entreprise, il y a une liste de tâches assez chronophage qui est toujours la même : envoyer la promesse d’embauche, l’attestation pour la santé au travail, créer les comptes sur les outils internes (Google, Slack…)… Chez theTribe, on accueille parfois 10 personnes en 1 mois, et ça représente beaucoup de travail. Un travail répétitif, et pas très gratifiant : d’un document à l’autre, on va devoir répéter les mêmes informations (coordonnées, numéro de sécurité sociale…).
La solution que l’on a apportée ?
Si on abstrait ce process, on se rend compte que c’est finalement assez simple :
Le candidat nous envoie ses informations => on crée les comptes et on génère les documents.
Et, bien, c’est ce que l’on a fait !
Nous avons automatisé tout le process avec Airtable et Make (anciennement Integromat).
Airtable, c’est une sorte d’Excel sous stéroïdes, qui permet de gérer des bases de données.
Make, c’est un outil qui permet de créer des workflows et d’automatiser des tâches en se connectant à l’API de tout un tas d’applications.
Comment ça se passe ?
On expose un formulaire Airtable qui permet à la nouvelle recrue de saisir toutes les données dont on a besoin.
Du côté d’Airtable, on a intégré des boutons qui permettent de déclencher l’envoi des informations dans un workflow, et une fois que l’on a validé, les informations suivent leurs chemins :
- Vers Google Drive
- Vers la génération de documents
- Vers Slack pour créer le compte
- etc.
À la fin, on envoie juste un petit feedback vers Airtable, pour montrer que tout a bien fonctionné.
Résultat ?
Un gain de temps non-négligeable pour les 2 personnes chargées de ce process. Mais surtout, on leur a redonné du pouvoir !
Si on avait automatisé ce process en développant une application en code, ç’aurait été une boîte noire pour notre contrôleuse de gestion et notre office manager. À chaque problème ou demande, elles auraient dû contacter les développeurs, il aurait fallu trouver quelqu’un de disponible : bref, ç’aurait été compliqué.
Alors que Make, c’est du no code, c’est très visuel et compréhensible, comme des Légos qui s’imbriquent les uns dans les autres. Les utilisatrices peuvent faire évoluer le process et gérer elles-mêmes 80% des modifications, ce qui est un vrai plus, surtout quand on travaille souvent dans l’urgence !
Intégrer code et no code : 3 conseils pour ne pas se planter ! 🚀
Maintenant que l’on vous a montré tout ce qu’il est possible de faire en low code, il n’y a plus qu’à se lancer !
Mais avant cela, j’ai 3 conseils à vous donner pour une intégration qui fonctionne.
Conseil n°1 : Anticiper les coûts 💸
Qui dit no code ne veut pas dire gratuit.
La plupart du temps, vous allez avoir besoin d’acheter le droit d’utiliser les fonctionnalités d’un outil, via un abonnement.
Et un abonnement, ça va, mais quand on commence à en avoir plusieurs, ça va commencer à s’accumuler. Surtout que souvent, pour avoir accès à l’API d’un outil, on va devoir passer sur une formule d’abonnement plus chère que la formule basique.
Il faut donc inclure le coût des abonnements, au moins sur 1 an, pour estimer le coût de l’investissement.
Conseil n°2 : Architecture logicielle et données 📝
Lorsque vous faites travailler ensemble une application maison et un outil no code, il faut bien penser votre architecture, afin de ne pas être dépendant des outils no code choisis.
Chez theTribe, nous sommes très promoteurs de l’Architecture Hexagonale, ou Clean architecture. Pour faire très court, cela veut dire que la logique métier est isolée de l’implémentation technique.
Pour illustrer ce concept, reprenons l’exemple du sondage :
La logique métier va permettre de créer un sondage, de répondre au sondage, et de renvoyer les résultats. Mais elle se fiche complètement de savoir où sont les données et comment on les récupère. C’est une autre brique qui va s’en occuper, et qui peut fonctionner avec Typeform, avec Surveymonkey, ou une solution maison : peu importe.
Pourquoi c’est important ?
Parce que c’est évolutif ! Vous pouvez commencer à tester votre fonctionnalité de sondage avec Typeform et ensuite, décider de l’intégrer dans votre produit, sans tout casser.
Conseil n°3 : Pensez à la sécurité des données 🔒
La plupart des géants du no code sont américains. Ce qui veut dire qu’ils sont soumis au Patriot Act : les services de renseignements US peuvent regarder et exploiter toute donnée possédée par des entreprises américaines sans même que vous voyez informés. Or, vous ne voulez peut-être pas leur donner accès à des données sensibles.
Vous ne voulez pas non plus risquer de perdre des données de valeur, si un jour la solution tombe ou arrête d’exister !
C’est pour cela qu’il faut rester malin lorsque l’on décide d’acheter une fonctionnalité plutôt que la développer soi-même :
- En anonymisant les données tant que possible ;
- En évitant de transmettre des données sensibles ;
- En envoyant le minimum vital de données vers les plateformes.
Ainsi, vous garderez l’esprit tranquille.
Le coût du code, ce n’est pas de l’écrire : c’est de l’entretenir 🛠
Si vous ne deviez retenir qu’une seule chose de cet article, c’est la suivante :
S’il y a une entreprise quelque part qui se dédie à développer une fonctionnalité dont vous avez besoin, et qui n’est pas votre cœur de métier : achetez-la !
D’autant plus si vous êtes en phase de POC ou de MVP, et que vous n’êtes sûr ni de votre idée, ni de vos utilisateurs.
Avec une solution no code, la fonctionnalité sera plus stable, plus responsive, plus accessible que si vous la développez from scratch. Cela vous coûtera moins cher, à court et moyen terme, que de développer un produit maison.
Mais cela nécessite de laisser de côté certaines de vos envies. Abandonnez l’idée du produit parfait que vous avez en tête ! Vos utilisateurs ne vous en voudront jamais de résoudre votre problème en passant par un tiers. Ce qu’ils veulent, c’est que leur problème soit résolu !
Rappelez-vous le mantra suivant : le coût du code, ce n’est pas de l’écrire, c’est de l’entretenir.
Au fond (et c’est une développeuse qui vous dit ça !), écrire du code, tout le monde peut le faire. Ça va plutôt vite. Mais le maintenir : c’est ça qui coûte cher. Et plus votre code est ancien, plus il pèse lourd. C’est pour cela que tout le code que vous n’écrivez pas vous-même et que vous déléguez à un tiers, c’est du code qui vous coûte moins cher.
Alors, si on revient sur la question de départ : où mettre le curseur entre code et no code ?
Pour y répondre, posez-vous les questions suivantes :
- Est-ce que c’est mon cœur de métier ?
- Est-ce que ça va apporter de la valeur ?
- Est-ce que c’est ça qui va attirer mes utilisateurs et les faire rester ?
Si la réponse est non : alors achetez la fonctionnalité, au moins au début : ceux qui l’ont développée le feront mieux que vous. Est-ce que ça vous viendrait à l’idée de développer vous-même une solution de paiement en ligne pour votre site e-commerce ? Sans doute que non. Alors, n’hésitez pas à appliquer la même logique à d’autres fonctionnalités de votre produit.
