Les socles no-code

Ce qui casse en premier, ce sont les données

Le chapitre précédent a produit une liste de candidats à automatiser. Avant de brancher la première plateforme d’automatisation, il reste un préalable que l’enthousiasme fait souvent sauter : structurer proprement les données que le workflow va manipuler. Un scénario d’automatisation, aussi bien construit soit-il, hérite entièrement de la qualité des données qu’on lui donne à traiter. Une base mal typée, des doublons, des champs libres qui contiennent tantôt une date, tantôt du texte, et c’est tout l’édifice qui produit des erreurs silencieuses, les plus coûteuses à détecter parce que rien ne s’arrête, tout continue, mais faux.

Structurer avant d’automatiser

Un socle de données no-code, qu’il s’agisse d’un outil comme Airtable, Notion ou d’une alternative comparable, repose sur trois notions qu’il faut poser avant la première ligne de workflow.

Les types : un champ « date de naissance » doit être un champ date, pas un champ texte libre où l’on peut écrire indifféremment « 12/03/1990 » ou « le 12 mars 90 ». Un type contraint la saisie et évite qu’une automatisation en aval doive deviner ce qu’elle reçoit. Les relations : la plupart des processus réels associent plusieurs objets entre eux, un client à ses commandes, une commande à ses lignes de produits. Modéliser ces relations dans des tables liées plutôt que dans une table unique surchargée de colonnes évite les répétitions et les incohérences, et permet à un workflow de suivre la relation plutôt que de la reconstituer. Les vues : une même base sert des usages différents selon qui la consulte ; une vue filtrée et triée pour l’équipe commerciale, une autre pour la comptabilité, sans dupliquer la donnée source.

Cette discipline de structuration n’est pas un luxe méthodologique : c’est elle qui détermine si un workflow tiendra six mois ou s’effondrera à la première exception qu’on n’avait pas prévue.

Formulaires et minimisation dès la conception

Le formulaire est souvent le premier maillon de la chaîne, celui par lequel une donnée entre dans le système. C’est aussi le moment le plus simple, et le plus systématiquement raté, pour appliquer un principe du RGPD trop souvent traité en aval plutôt qu’en amont : la minimisation, qui veut qu’on ne collecte que les données strictement nécessaires à la finalité poursuivie.

Concrètement, cela signifie qu’un champ « numéro de téléphone » ajouté à un formulaire « parce que ça peut toujours servir » n’a rien d’anodin : c’est une donnée personnelle de plus à sécuriser, à conserver selon une durée définie, et à pouvoir justifier si une personne demande pourquoi elle a été collectée. Concevoir un formulaire minimal dès le départ coûte moins cher, à tous les sens du terme, que d’en retirer des champs après coup une fois qu’ils ont déjà alimenté vingt automatisations en aval.

Les constructeurs d’applications : ce qu’ils promettent

Au-delà des bases de données et des formulaires, une deuxième famille d’outils permet de construire des applications internes ou des sites plus complexes sans écrire de code : les app builders, comme Bubble, Webflow ou Softr, chacun avec sa spécialité, application métier, site vitrine ou interface au-dessus d’une base existante. Leur promesse commune est réelle : livrer en quelques semaines ce qui aurait demandé un développement sur mesure de plusieurs mois, avec une équipe réduite, parfois une seule personne.

Cette rapidité a un prix qui n’apparaît pas à la démonstration.

Les limites structurelles à connaître avant de s’engager

Le verrouillage propriétaire, ou enfermement propriétaire, désigne la difficulté à faire sortir une application construite sur une plateforme fermée pour la porter ailleurs. Le code généré, quand il existe, n’est souvent ni lisible ni exportable dans un format réutilisable : changer de plateforme signifie généralement reconstruire, pas migrer.

La dette technique invisible : une application no-code s’empile de règles, d’automatisations et d’exceptions ajoutées au fil de l’eau, sans la discipline qu’impose un code versionné et relu. Elle devient, avec le temps, aussi difficile à faire évoluer qu’un développement classique mal documenté, sans que personne ne l’ait vu venir puisque chaque ajout, pris isolément, semblait anodin.

La sécurité : ces plateformes mutualisent l’hébergement de milliers d’applications clientes, et un paramétrage de permissions mal maîtrisé, un champ exposé publiquement par erreur, une automatisation qui aspire plus de données que nécessaire, deviennent des incidents dont la plateforme n’est responsable qu’en partie. La configuration reste de la responsabilité de qui construit.

Le coût à l’échelle, enfin : la facturation de ces outils suit presque toujours une logique par utilisateur, par enregistrement ou par exécution. Un prototype à dix utilisateurs et mille lignes coûte peu ; la même application à mille utilisateurs et un million de lignes change complètement de gamme de prix, parfois au point de rendre pertinent un développement sur mesure qu’on avait écarté au départ pour aller plus vite.

Ce qu’il faut retenir

Un socle no-code solide se juge à sa structure de données et à sa réversibilité, pas à la vitesse de la première démonstration. Une base bien typée, un formulaire minimal et une lucidité sur les limites de l’outil choisi valent mieux qu’un prototype impressionnant construit sur du sable. Le chapitre suivant s’attaque à la brique qui orchestre ces socles entre eux : les plateformes d’automatisation, et la manière de construire un workflow qui tienne en production, pas seulement en démonstration.