Tous les articles

Le no-code tient très bien. Jusqu'à un point précis.

Opposer no-code et développement est un faux débat. La vraie question est de savoir où se situe la limite, et ce qui se passe quand elle est franchie.

·2 min de lecture

Le no-code est présenté tantôt comme la fin du développement, tantôt comme un jouet. Les deux positions évitent la seule question utile : jusqu’où cela tient, et que se passe-t-il ensuite.

Là où il gagne largement

Pour valider une idée, outiller un processus interne simple, ou remplacer un tableur partagé, le no-code est difficile à battre. Ce qui prendrait des semaines en développement se monte en quelques jours, se modifie sans intermédiaire, et coûte un abonnement.

Refuser cela par principe fait perdre du temps et de l’argent. Beaucoup d’outils internes ne méritent pas une ligne de code sur mesure.

Les cinq signaux de la limite

Elle ne se franchit pas d’un coup. Elle s’annonce :

Les contournements se multiplient. Un champ détourné de son usage, une automatisation qui en déclenche une autre, une formule de trois cents caractères que son auteur ne relit plus.

Les performances se dégradent avec le volume. Ces plateformes sont conçues pour des jeux de données modestes. Au-delà de quelques dizaines de milliers d’enregistrements, l’affichage d’une liste devient pénible.

Les droits deviennent grossiers. Le besoin est « chacun voit son agence » ; l’outil propose « tout le monde voit tout » ou « chacun voit ses propres fiches ». L’écart se comble par des duplications de bases, qui divergent.

La facture suit le nombre d’utilisateurs. Le modèle par siège est indolore à dix personnes et devient le premier poste à deux cents. C’est fréquemment le déclencheur réel du changement.

L’intégration bute. Tant qu’il s’agit de connecteurs prévus, tout va bien. Dès qu’il faut dialoguer avec un système interne ancien, l’effort dépasse celui d’un développement.

Préparer la sortie avant d’en avoir besoin

C’est le point négligé, et c’est celui qui décide du coût final. Trois précautions, à prendre dès le premier jour :

  • vérifier que l’export contient tout, relations et fichiers joints compris, dans un format relisible ailleurs ;
  • écrire les règles métier en français, quelque part, plutôt que de les laisser vivre uniquement dans des automatisations cliquées ;
  • ne pas construire le cœur de métier sur une plateforme dont la sortie n’a jamais été testée.

Une organisation qui a documenté ses règles migre en semaines. Une organisation qui les a seulement cliquées les redécouvre une par une, en production.

La combinaison qui fonctionne

Le no-code pour l’outillage interne et l’expérimentation. Le développement sur mesure pour ce qui est exposé aux clients, soumis à un volume réel, ou porteur d’un avantage concurrentiel.

La frontière n’est pas idéologique. Elle est mesurable, et elle se déplace.