Lorsque vient le moment de concrétiser une idée en un produit réel, le choix de la stack technique est une décision cruciale. Avec l’essor du no code et du low code, les options se sont multipliées, rendant l’arbitrage plus complexe qu’auparavant. Ce choix doit tenir compte de nombreux paramètres : compétences disponibles, faisabilité technique, évolutivité, et contraintes spécifiques du projet. Il est d’autant plus stratégique qu’une mauvaise décision peut avoir des conséquences lourdes quelques mois plus tard. L’objectif de cet article est de vous fournir une grille d’analyse claire pour orienter votre décision. Nous explorerons à la fois des critères objectifs comme les compétences ou la faisabilité et des considérations plus pragmatiques : composition de l’équipe, maturité du projet et autres questions que l’on regrette souvent de ne pas s’être posées plus tôt. Nous nous concentrerons ici sur le choix entre full code et low code, mais la démarche pourra s’appliquer à d’autres situations.

‍

‍

‍

Les bonnes questions à se poser avant de choisir entre no code, low code et full code

Avant de vous lancer, prenez le temps d’analyser les implications de votre choix.

Voici une liste de questions essentielles, que nous détaillerons ensuite, pour vous aider à faire le bon arbitrage :

Équipe

• Quelles sont les compétences techniques de mon équipe ?
• Ont-ils une appétence pour le low-code ? Sont-ils ouverts à apprendre ces outils ?
• Dans quelle architecture se sentent-ils à l’aise et motivés ?

Faisabilité

• Y a t’il des fonctionnalités bloquantes ? Certaines features nécessitent-elles absolument du full code ?
• Quelle proportion de full code  vais-je intégrer dans mon low code ? Est-ce réellement un gain ou vais-je finir par coder la moitié du projet ?

Sécurité, conformité, RGPD

• Est ce que mon application a des contraintes d’hébergement ?
• Est ce qu’elle a des contraintes de conformité ou d'agrément ? Où et comment les données doivent-elles être stockées ?
• Y a-t-il des obligations légales à respecter ? Certaines industries imposent des réglementations strictes en termes de sécurité.

SEO, efficacité, complexité

• Ai-je des besoins forts en SEO ? Certains outils low code ne permettent pas une optimisation fine du référencement.
• Les temps de réponse sont-ils un enjeu clé ? Mon application doit-elle être ultra-rapide ou gérer un grand volume d’utilisateurs ?

Réversibilité, passer du low code au full code

• Aurais-je besoin d’accéder au code source ? Est-ce une exigence à court ou long terme ?
• Si oui, l’outil le permet-il et dans quelles conditions ? Quel sera l’état du code récupéré ? Exploitable ou trop verrouillée ?

‍

‍

‍

L’équipe : compétence, affinité et adoption

‍

« Toute organisation qui conçoit un système, au sens large, concevra une structure qui sera la copie de la structure de communication de l’organisation. » — M. Conway

‍

L’équipe qui va porter le projet est le tout premier facteur à considérer. Il ne s’agit pas seulement de compétences techniques, mais aussi d’affinité, de curiosité, de synergie, de maturité ou de niveau de confiance. 

Quel est le niveau d’appétence pour le no code / low code ? Un développeur peut être réticent à l’idée d’utiliser des outils qui le brident, tandis qu’un product designer peut hésiter à entrer dans une logique plus technique. A contrario, ils peuvent tout aussi bien être enthousiastes à l’idée de cette nouvelle approche, quitte à sortir de leur zone de confort

Quel est le degré de confiance et d’adhésion ? Une équipe fédérée autour d’une stack avec laquelle elle se projette aura plus de chances de construire un produit évolutif et maintenable en harmonie avec les compétences de ses membres. 

Cela ne signifie pas qu’il faut choisir une solution en fonction des préférences de chacun. On cherche avant tout de la cohérence. Mais si une orientation technique va à l’encontre des attentes de l’équipe, il est crucial d’en discuter pour identifier des leviers de motivation et éviter les frustrations.

‍

La faisabilité : peut-on vraiment tout faire en low-code ?

Critère évident mais critique trop souvent ignorée, la faisabilité technique détermine si  les fonctionnalités souhaitées peuvent être réalisées avec la technologie choisie. En no code pur, certaines limitations peuvent rapidement apparaître. En low code, en revanche, la flexibilité est plus grande et il est souvent possible d’intégrer des morceaux de code custom, notamment dans le head ou le bas de chaque page. Cependant, bien qu’il soit “théoriquement” possible de tout faire (importer des librairies, déclarer des variables, etc), utiliser du code personnalisé trop fréquemment dans un outil no code revient à contourner sa logique, ce qui nuit à la maintenabilité du projet. 

Exemples de limitations 

• Interfaces graphiques très avancées,
• Sites proposant un rendu graphique ambitieux avec webgl,
• Maps enrichies de couches et de rendus personnalisés, 
• etc. 

Ainsi, au-delà de la faisabilité se pose la question de l’adéquation avec la philosophie de l’outil. Si vous devez utiliser du code custom toutes les cinq minutes, ou ajouter trois librairies javascript par page pour atteindre vos objectifs, ce sera certes possible mais bien trop en contradiction avec l’outil pour être une solution durable. 

🔎 Conseil : testez vos hypothèses

Avant de vous engager dans une stack, essayez de construire une fonctionnalité clé en respectant le cadre de l’outil. Si vous devez trop souvent contourner ses règles, il y a de fortes chances que ce ne soit pas la bonne solution. 

Il est également essentiel de distinguer le low code côté front et côté back. Si les contraintes d’affichage sont généralement bien gérées par les outils low code front, la situation est plus complexe côté backend. Implémenter et maintenir des algorithmes avancés peut rapidement devenir un casse-tête, et la couche automatisée par des solutions comme Supabase, Xano ou Airtable (dans une moindre mesure) peut souvent être remplacée par des librairies ou frameworks plus flexibles. Ainsi, sauf si vos besoins backend se limitent à des opérations simples (CRUD principalement), le low code back doit être évalué avec attention, notamment en tenant compte des "cas particuliers" évoqués précédemment.

‍

‍

Sécurité, conformité, RGPD

Le choix d’un outil ne se limite pas à ses fonctionnalités : il doit aussi répondre à vos exigences légales et de sécurité.

Hébergement et conformité

• Où sont stockées les données ? (Europe, USA, Cloud Act, RGPD...)
• L’outil est-il compatible avec des contraintes spécifiques (ex : hébergement agréé données de santé - HADS) ? 

Sécurité des échanges

Les solutions no code facilitent souvent les intégrations avec des services tiers (OAuth, API, etc.). Il est important de vérifier que ces échanges sont sécurisés et bien documentés.

💡 Bon réflexe : consulter la documentation et les CGU

Les solutions sérieuses mettent en avant ces aspects dans leurs documents officiels. Si ce n’est pas le cas, posez directement la question au support.

Veuillez noter que plusieurs outils proposent (dans les plans premium) la possibilité de télécharger le code généré pour l’héberger selon vos conditions. Ce peut être une alternative intéressante, mais il faut en vérifier les conditions. 

‍

SEO, performance, complexité

Les besoins en performance varient selon l’usage :

• Une landing page pour le grand public doit être bien optimisée pour le référencement. 
• Un module intranet pour une entreprise a des enjeux techniques différents (temps de réponse ou First Contentful Paint - FCP, scalabilité...).. 

Les outils no code et low code offrent généralement de bonnes performances pour des cas simples, mais peuvent montrer leurs limites sur des sites complexes nécessitant un contrôle précis du SEO ou une gestion avancée des temps de chargement.

Si vous avez besoin de l’un ou l'autre, cela peut orienter votre choix. Si vous avez besoin des deux, tout d’abord bonne chance, mais cela peut vous aider à faire  le choix d’un outil front full code. 

‍

Réversibilité, peut-on passer du low code au full code ?

Un argument souvent avancé en faveur du low code est la possibilité de démarrer rapidement pour valider au plus vite les hypothèses (logique prototype MVP) puis de migrer vers du full code en cas de besoin. C’est une possibilité que proposent plusieurs outils, notamment Weweb. 

Les bonnes questions à se poser

• L’outil permet-il d’exporter le code ? Certains le proposent, mais là aussi, via un plan payant (ils ne vont pas vous laisser partir comme ça).
• ‍Quel est le langage utilisé ? Weweb génère du Vue.js, Toddle du React… Vérifiez que cela correspond aux compétences de votre équipe.‍
• La qualité du code généré est-elle exploitable ? Certains outils produisent un code structuré, d’autres un spaghetti code difficilement maintenable. Dans tous les cas, un travail de reprise sera nécessaire, notamment pour les variables qui n’ont pas été nommées.

📌 La meilleure manière de se projeter sur la qualité du code que vous allez réceptionner, est de comprendre la philosophie de l’outil no code. Deux approches existent : 

• Les outils "top-down" : ils partent des besoins utilisateurs et créent des interfaces simplifiées.
• Les outils "bottom-up" : ils ajoutent une dimension graphique au langage qu’ils prennent pour source, mais le langage restera la première contrainte. On peut citer Weweb en vue.js, Toddle en React, ou Flutter Flow en Flutr pour les apps mobiles par exemple. Ces approches là ont bien plus de chance de produire un code lisible, grâce au garde fou que constituait leur langage de départ. 

‍

Conclusion : faut-il éviter le low code ? 

Cette analyse s’est principalement concentrée sur toutes les raisons qui pourraient freiner l’adoption du no code ou du low code. Mais si ces prérequis sont validés, alors ces outils méritent d’être sérieusement envisagés : ils offrent une approche viable, efficace et pragmatique.

De notre expérience sur une quinzaine de projets variés (réservation dé véhicules, médical, actuariat, hôtellerie, objets connectés, etc.), nous avons identifié une architecture particulièrement performante : un frontend en low code couplé à un backend en full code.

‍

Pourquoi ce choix ?

‍
✅ Rapidité et confort de développement côté front : le low code facilite le style, la mise en page et l’expérimentation d’alternatives.‍

✅ Flexibilité et ambition : contrairement au no code, le low code laisse la porte ouverte à des évolutions plus poussées, tout en restant maîtrisable techniquement.

✅ Puissance et évolutivité côté back : le full code garantit une totale liberté pour gérer la logique métier et l’architecture des données.

✅ Optimisation des efforts et des coûts : cette approche permet de concentrer les ressources au bon endroit, là où elles apportent le plus de valeur.

‍

Concrètement, nous utilisons WeWeb pour le frontend low code, et un backend TypeScript avec Nest.js (un framework spécialisé dans les API, complémentaire à Next.js, qui excelle davantage en synergie avec son propre frontend).

Bien sûr, cette architecture ne convient pas à tous les projets et est systématiquement remise en question selon les besoins. Mais dans la majorité des cas, elle offre un environnement agréable, performant et pérenne.

Dans nos prochains articles, nous détaillerons cette architecture et illustrerons les concepts clés pour aborder proprement un projet low code.