No-code en prod : ce qui casse à l'échelle
Bubble, Webflow, Make font très bien leur travail — jusqu'à une limite précise. Ma position : no-code pour la vitrine et le petit e-commerce, sur-mesure dès qu'il y a de la donnée sensible ou un cas avancé.
Le no-code n'est pas un compromis, c'est le bon outil pour un périmètre précis
Bubble, Webflow, Airtable, Make : ces outils font ce qu'ils promettent, et je ne les oppose jamais au sur-mesure comme s'il fallait choisir un camp. Ma position est plus étroite que ça : le no-code est le bon choix pour une vitrine, un blog, ou un petit e-commerce standard. Il devient le mauvais choix dès qu'il y a de la donnée sensible à protéger, ou un cas d'usage qui sort du cadre que la plateforme a prévu pour vous.
Là où le no-code tient très bien la route
Un site vitrine, une landing page, un formulaire connecté à un tableur, une automatisation entre deux outils existants : ce sont des cas où le no-code n'est pas un pis-aller, c'est l'outil le plus adapté. Rapide à construire, accessible sans équipe technique, et le coût de sortie reste faible si le besoin évolue peu.
Ce qui casse quand le produit sort du cadre prévu
La personnalisation des règles métier. Tant qu'on reste dans la logique que l'outil a prévue, tout va bien. Dès qu'un workflow spécifique ou un calcul particulier sort de ce cadre, on passe plus de temps à contourner les limites de la plateforme qu'à construire de la valeur — et le résultat est souvent plus fragile qu'une implémentation sur mesure équivalente.
La donnée sensible. Un produit qui manipule des données de paiement, de santé, ou soumises à une contrainte de conformité a besoin d'un contrôle direct sur où et comment cette donnée est stockée et traitée. Une plateforme no-code mutualisée n'offre pas ce niveau de garantie contractuelle.
La dépendance à la plateforme. Le produit vit entièrement chez un tiers. Si la tarification change, si une fonctionnalité clé est dépréciée, la marge de manœuvre est nulle — il n'y a pas de code à reprendre, juste une configuration propriétaire.
L'approche hybride que je recommande le plus souvent
Entre le tout no-code et le tout sur-mesure, il y a une troisième voie que j'utilise régulièrement en prod : confier les pages publiques et le contenu marketing à un outil comme Plasmic — donnant l'autonomie à l'équipe design sans dépendre de moi pour chaque changement de wording — pendant que la logique métier critique (tunnel de vente, gestion des comptes, intégrations) reste dans une API sur mesure. C'est ce que j'ai fait sur une refonte de site vitrine + tunnel de réservation pour un concessionnaire automobile : Plasmic pour les pages publiques, Nest.js pour tout ce qui touche à la réservation et à l'intégration métier.
Ce découpage évite le faux dilemme "tout no-code ou tout sur-mesure" : chaque brique du produit utilise l'outil adapté à son niveau de criticité, pas un compromis unique appliqué à l'ensemble.
La vraie question à se poser
Pas "no-code ou sur-mesure", mais : qu'est-ce qui, dans ce produit, touche à de la donnée sensible ou à une règle métier qui sortira forcément du cadre standard — et qu'est-ce qui n'y touche pas. La réponse découpe naturellement le produit entre ce qui peut rester no-code longtemps, et ce qui doit être sur-mesure dès le premier jour.