Sur-mesure ou no-code : où passe la frontière, vraiment

Nous avons construit des choses en no-code, et nous en avons reconstruit certaines en sur-mesure deux ans plus tard. Ces migrations m’ont appris quelque chose de plus utile que les débats habituels : la frontière n’est pas là où on la place généralement.

On oppose souvent no-code et développement sur un axe de complexité — « au-delà d’un certain niveau, il faut du code ». C’est faux, ou du moins imprécis. Une application no-code peut être très riche fonctionnellement. Ce qui décroche, c’est autre chose.

Ce qui décroche vraiment : le modèle de données

Les plateformes no-code reposent presque toutes sur des tables souples, faiblement typées, où les contraintes sont faciles à contourner. C’est exactement ce qui les rend rapides au départ.

Le problème apparaît quand votre domaine exige de l’intégrité. Une commande doit référencer un client qui existe. Un paiement ne peut pas être rattaché à deux factures. Un statut ne peut passer de « annulé » à « livré ». Ces règles ne sont pas du confort : ce sont elles qui font que vos données restent exploitables dans cinq ans.

Sur une base relationnelle, elles se déclarent une fois et le moteur les fait respecter, quoi qu’il arrive. Sur la plupart des plateformes no-code, elles se réimplémentent dans chaque automatisation — et il suffit qu’une seule les oublie pour que la base se dégrade silencieusement.

C’est le vrai point de bascule, et il arrive plus tôt qu’on ne l’imagine.

Photo : rawpixel — licence CC0.

Les quatre autres seuils

Le modèle de données est le premier, mais quatre autres arrivent en général peu après.

La concurrence d’accès. Deux utilisateurs qui modifient le même enregistrement en même temps : sur une base relationnelle, cela se traite par transactions et verrous. Sur beaucoup de plateformes no-code, le dernier qui écrit gagne, silencieusement. Tant que trois personnes utilisent l’outil, personne ne le remarque. À trente, cela produit des pertes de données inexpliquées.

Le volume. Les plateformes annoncent des limites généreuses. Ce qui coince en pratique, ce n’est pas le nombre de lignes mais le temps de réponse sur des vues filtrées et triées. Les performances se dégradent progressivement, sans point de rupture net — ce qui les rend difficiles à anticiper.

Les intégrations. Une intégration est facile. Trois qui doivent rester cohérentes entre elles, avec reprise sur erreur, deviennent un sujet d’ingénierie à part entière. C’est là que les automatisations no-code deviennent un enchevêtrement que personne n’ose modifier.

La testabilité. C’est le seuil dont on parle le moins et qui pèse le plus dans la durée. On ne teste pas automatiquement une automatisation no-code comme on teste une fonction. Chaque modification demande une vérification manuelle, et le coût du changement augmente avec le temps au lieu de diminuer.

Ce que le no-code fait mieux que nous

Il faut être honnête : sur son terrain, il gagne largement.

Valider une hypothèse. Construire en trois jours ce qui prendrait trois semaines, pour savoir si quelqu’un l’utilisera. À ce jeu, aucun développement sur mesure n’est compétitif.

Outiller une équipe restreinte. Un suivi interne pour cinq personnes, avec des règles simples et peu d’enjeu d’intégrité : développer serait un gaspillage.

Rendre autonome une équipe métier. Quand ceux qui utilisent l’outil peuvent l’ajuster eux-mêmes, le cycle de décision disparaît. C’est un gain réel, souvent sous-estimé par les développeurs.

Photo : Christina Morillo — licence CC0.

La stratégie que nous appliquons

Nous ne recommandons ni l’un ni l’autre par principe. Nous recommandons une séquence.

Étape 1 — valider en no-code. Le besoin est incertain : construisez vite, mettez entre les mains des utilisateurs, observez. Le coût d’abandon doit rester faible, parce que la plupart des idées ne passent pas cette étape.

Étape 2 — mesurer les seuils. Combien d’utilisateurs réels ? Quelle volumétrie ? Combien d’automatisations enchaînées ? Des incohérences de données sont-elles apparues ? Ces réponses factuelles remplacent le débat d’opinion.

Étape 3 — reconstruire ce qui a trouvé son public. Avec un avantage considérable : le besoin est désormais connu précisément, et la version no-code sert de spécification exécutable. Un développement mené après cette étape est bien plus rapide qu’un développement mené à l’aveugle.

Cette séquence a un coût — vous construisez deux fois. Mais elle évite le scénario le plus cher de tous : développer six mois une application que personne n’utilisera.

Photo : domaine public (CC0).

Ce qu’il faut vérifier avant de s’engager sur une plateforme

Trois points contractuels et techniques, à regarder avant de construire, jamais après.

La sortie des données. Peut-on exporter l’intégralité du contenu, dans un format exploitable, sans intervention du fournisseur ? Un export limité aux tables visibles, sans les relations ni les fichiers joints, ne permet pas de reconstruire quoi que ce soit.

Le modèle tarifaire à l’échelle. La plupart de ces plateformes facturent à l’utilisateur, à l’enregistrement ou à l’exécution d’automatisation. Le coût est dérisoire au départ et croît avec l’usage — c’est-à-dire avec le succès. Il faut projeter la facture à trois ans avec les volumes attendus, pas avec les volumes actuels.

L’hébergement des données. Où sont-elles, sous quelle juridiction, et qu’est-ce que cela implique pour vos propres engagements clients. Cette question devient bloquante dès qu’un appel d’offres ou un marché public entre dans l’équation.

Le cas hybride, qui marche bien

Une configuration que nous mettons en place régulièrement et dont on parle peu : garder le no-code pour ce qu’il fait bien, et développer uniquement le noyau.

Concrètement, la base de données et les règles métier critiques vivent dans un système sur-mesure, avec les contraintes d’intégrité que cela permet. Autour, les écrans internes, les tableaux de bord et les petits outils d’équipe restent en no-code, connectés à ce noyau par une interface stable.

L’équipe métier garde ainsi son autonomie sur la partie qui change souvent, et les données restent protégées là où cela compte. C’est souvent la réponse la plus économique, et elle est rarement proposée parce qu’elle oblige à sortir du débat « l’un ou l’autre ».

Le signal qui doit vous alerter

Un seul, et il est fiable : quand plus personne n’ose modifier une automatisation existante.

Ce moment arrive toujours. Il signifie que la complexité a dépassé ce que l’outil permet de maîtriser, et que vous avez commencé à payer des intérêts sur une dette que vous ne mesurez pas. À partir de là, chaque mois passé à empiler augmente le coût de la reconstruction.

Ce n’est pas un échec du no-code. C’est le signe qu’il a fait son travail — il vous a menés assez loin pour que la question se pose.