Non.
Voilà, c’est dit d’entrée, parce que c’est la question que mes client·es finissent toujours par me poser, un jour ou l’autre, souvent après le troisième mail « ça bug » du mois. Depuis bientôt dix ans que je fais du no-code, ce mail revient plusieurs fois par semaine. Une automatisation restée muette, un bloc qui s’affiche de travers. Alors je peux le dire d’entrée : le no-code ne bug pas plus qu’un logiciel classique. Il vous montre simplement ce que les autres vous cachent.
Ce que vous voyez, et pourquoi ça saute aux yeux
Un chiffre qui remonte mal dans un tableau de bord. Une automatisation censée partir à 9h qui n’est jamais arrivée. Un élément d’interface cassé après une mise à jour. Ces incidents-là, vous les voyez parce que vous êtes physiquement en train de regarder l’endroit où ils se produisent. Un exemple très concret : un moment où on est arrivé à notre max d’automatisation dans le plan du logiciel qu’on utilise. Évidemment, les automations ne partent pas et tout semble OK, mais si on n’est pas le destinataire des alertes concernant le workspace, évidemment, on ne peut pas comprendre.
Et c’est là que se niche le malentendu.
Le no-code ne bug pas plus. Il bug en revanche plus visiblement
Un logiciel classique du marché (un CRM propriétaire, un ERP fermé, une appli mobile grand public) bug tout autant. Sauf que vous n’en voyez presque rien. Les équipes qui le construisent sont aussi celles qui surveillent ses journaux d’erreurs, en interne, loin de vos yeux. Un patch silencieux corrige un bug la nuit ; vous ne saurez jamais qu’il a existé.
Dans le no-code, l’inverse se produit : les outils sont transparents par construction. L’historique d’exécution d’une automatisation Make, les logs d’erreur d’un scénario, le message qui dit noir sur blanc « ce champ attend un nombre, pas du texte » tout ça est sous vos yeux, ou sous les miens. Ce n’est pas un défaut du no-code. C’est sa nature même : on vous donne accès à la mécanique, plutôt que de la verrouiller dans une boîte noire.
Deux règles fixe dans le développement (classique ou no-code)
Face à un dysfonctionnement, quel que soit l’outil, deux principes guident le métier depuis ses débuts :
- Être intelligemment paresseux. Ne jamais refaire ce qui existe déjà, capitaliser sur le travail des autres, ne pas réinventer la roue à chaque projet.
- 99 % du temps, le problème se trouve entre le clavier et la chaise. Ce n’est pas du mépris, c’est un point de départ statistique. La grande majorité des « bugs » remontés sont, en réalité, des manipulations qui n’ont pas produit l’effet attendu.
Ces deux règles ne sont pas propres au no-code. Elles guident n’importe quel développeur, no-code ou pas, depuis toujours.
Une nuance honnête : le no-code a bien une fragilité qui lui est propre
Je ne vais pas m’arrêter à « c’est juste une question de perception » ce serait malhonnête. Quand vous construisez un outil en assemblant plusieurs briques (Airtable, Make, WordPress, Softr…), vous créez plusieurs points de rupture possibles là où un logiciel fermé et monolithique n’en a qu’un seul, contrôlé de bout en bout par un seul éditeur.
Si un service tiers change son API sans prévenir, si un webhook expire, si une limite de requêtes est atteinte, l’automatisation qui les relie peut se rompre. C’est un vrai point de vigilance technique, pas un mythe à balayer d’un revers de main.
Mais cette fragilité a une contrepartie que le logiciel fermé ne vous offre jamais : vous n’êtes dépendant·e d’aucun éditeur unique, vous pouvez remplacer une brique sans tout reconstruire, et surtout : vous voyez le problème au moment où il survient, au lieu de le découvrir six mois plus tard quand plus personne ne s’en souvient.
Pourquoi les bugs « classiques » restent invisibles
Quand j’entends la frustration du type « avec un logiciel classique, ça n’arrive jamais », c’est faux. Ça bug tout autant. Simplement, l’utilisateur·rice n’a pas accès aux messages d’erreur. Une automatisation qui ne part pas, mais dont personne ne savait qu’elle devait partir : personne ne remarque rien. Les équipes qui développent ces logiciels, elles, le savent très bien, elles passent leurs journées à régler ces problèmes, dans l’ombre.
La vraie question n’est pas « combien de bugs », mais « qui peut les lire »
Voilà, je crois, le cœur du sujet. Le no-code ne produit pas plus de dysfonctionnements. Il vous met simplement face à eux. Et si on ne vous a jamais appris à les lire, cette transparence-là ne rassure pas, elle angoisse.
C’est mon cheval de bataille depuis toujours : au lieu de prendre les client·es pour des personnes qui « ne comprennent rien » ou qui « ont encore cassé leur truc » (des évidences pour un·e développeur·se, des mystères pour tout le monde d’autre) il faut bannir ce mépris ambiant.
La formation doit être le premier palier de debugging. Pas un service après-vente qu’on active quand ça casse : le point de départ.
Dans mes missions de maintenance, à chaque fois qu’on fait remonter un bug qui provient d’un point ignoré par l’utilisateur ou d’une manipulation erronnée, je prends le temps de débbuger, expliquer et surtout mettre à jour la documentation pour que le problème ne se repose pas.
On apprend par l’erreur, donc l’opportunité d’une erreur du client va permettre de mieux sceller la connaissance, ne serait-ce que par le souvenir : « Cette situation est déjà arrivée. Je sais que, dans la documentation d’Alix, il va y avoir la solution. »
Alors non, le no-code ne bug pas plus. Il vous fait simplement confiance pour regarder sous le capot. La vraie question, ce n’est pas de fermer cette transparence, c’est de vous donner les clés pour qu’elle cesse d’être une source d’angoisse et devienne ce qu’elle devrait toujours être : de l’autonomie.
