Une démo no-code, c'est trois minutes de magie. Un formulaire qui se remplit tout seul, un devis qui part par mail, un tableau qui se met à jour sans qu'on y touche. On comprend l'engouement, et il est mérité. Mais une démo ne ment jamais — elle omet. Ce qu'on assemble en une après-midi, il faut ensuite le faire vivre pendant des années. Et c'est tout ce qui se passe après la démo qui décide si vous avez gagné du temps ou hérité d'un problème supplémentaire.
La démo de trois minutes
Soyons justes : le no-code a changé quelque chose de réel. Avant, automatiser une tâche supposait un projet, un développeur, un budget, des semaines d'attente, des tests et des corrections. Aujourd'hui, un dirigeant peut connecter deux outils et voir le résultat dans l'après-midi. La barrière a baissé, l'autonomie a grandi — c'est une bonne nouvelle, et je ne suis pas là pour la nier. Je construis moi-même avec ces outils. Et pour beaucoup de petits usages — un rappel qui se déclenche tout seul, un tri d'e-mails sans données sensibles — se lancer seul est parfaitement légitime. Je ne crache pas sur le bricolage ; je veux juste qu'on sache où il s'arrête.
Une démo répond toujours à une seule question : est-ce que je sais le construire ? Mais la démo ne répond jamais à l'autre, celle qui compte en réalité, celle qui fera que votre système s'inscrira dans la durée : est-ce que ça va tenir ? Construire et s'approprier sont deux choses différentes. La première prend une après-midi. La seconde vous accompagne pendant des années — et c'est là que se cachent les angles morts.
Voici les quatre que je rencontre le plus souvent.
Angle mort n°1 — Une dette technique invisible
Une automatisation, ce n'est jamais une seule action. C'est une chaîne de petites décisions : quel déclencheur, quel format de date, que faire si un champ est vide, où envoyer l'erreur. En démo, ces décisions sont déjà prises — par celui qui présente. Chez vous, elles sont différentes et dépendent de votre contexte, elles s'accumulent, et souvent elles ne sont écrites nulle part.
Au début, ce n'est pas parfait mais ça marche. Alors vous ajoutez une exception, puis une autre, et six mois plus tard vous avez un assemblage que plus personne, y compris vous, ne comprend. Imaginons un artisan qui a bricolé lui-même son circuit de devis : il fonctionne, parfait. Son entreprise, son activité évolue, mais il n'ose plus toucher à son outil de peur de tout casser. Ce n'est plus un outil, ça devient un château de cartes qu'on regarde de loin. La dette technique n'est pas un défaut de l'outil ; c'est ce qui arrive quand on construit sans structure.
Angle mort n°2 — Vos données, et où elles partent vraiment
Brancher quatre services entre eux, c'est pratique. C'est aussi faire voyager vos données. Le nom d'un client, son numéro, le montant d'un devis : à chaque connexion, cette information transite par un serveur, est recopiée quelque part, parfois hors d'Europe. La démo ne vous dira jamais « au passage, cette fiche client part sur un serveur américain ».
Ce n'est pas de la paranoïa, c'est une question de responsabilité : c'est vous, et pas l'éditeur, qui répondez du RGPD devant vos clients. Savoir où vivent vos données et sous quel droit, ce n'est pas une case à cocher après coup — c'est une décision à prendre au moment de choisir l'outil, pas le jour où un client vous le demande.
Angle mort n°3 — Une dépendance forte à l'éditeur
Quand votre relance client automatique repose sur un outil gratuit, vous ne possédez pas votre automatisation : vous la louez. Le propriétaire peut changer les règles du jour au lendemain. Le plan gratuit se met à plafonner, le tarif double du jour au lendemain, une fonction clé pour vous bascule dans l'offre supérieure, ou le service ferme tout simplement.
Imaginons un commerçant dont les relances de paiement tournaient gratuitement : un matin, l'éditeur fait passer la fonction à plusieurs dizaines d'euros par mois. Rien de scandaleux — c'est son droit. Mais le processus, lui, est pris en otage : payer, ou tout refaire ailleurs dans l'urgence. Plus une automatisation devient utile, plus cette dépendance pèse lourd. La démo vend la facilité d'entrer ; elle ne montre jamais le coût de sortie.
Angle mort n°4 — La montée en charge
Une démo tourne toujours sur le scénario idéal : trois lignes de données propres, un cas parfait, aucune surprise. Le réel est moins poli. Les noms sont mal saisis, les fichiers arrivent dans le mauvais format, un client a deux adresses, et le volume grimpe.
Ce qui marche pour dix enregistrements peut s'effondrer à mille : quotas atteints, traitements qui ralentissent, cas particuliers que personne n'avait anticipés. Le paradoxe est cruel — c'est souvent le jour où votre activité décolle, là où l'automatisation devrait vous sauver, qu'elle lâche. Concevoir pour le pic et pas pour la démo, ça ne s'improvise pas en une après-midi.
Ce qu'une démo ne connaît pas : votre entreprise
Reprenons les quatre. Aucun n'est un problème d'outil. La dette technique, les données, la dépendance, la montée en charge : ce sont des problèmes de conception. Le no-code a abaissé la barrière technique — fabriquer est devenu facile. Il n'a rien changé à l'autre barrière, la vraie : savoir quoi construire, et surtout pour qui.
Et ce « pour qui », c'est vous. Une automatisation qui tient ne part jamais de l'outil ; elle part de votre entreprise — ce que vous faites, ce qui vous distingue, où vous voulez aller, qui sont vos clients, comment vous êtes organisé. Une démo ignore tout de ça : par nature, elle parle à tout le monde, donc à personne en particulier. Elle vous montre un devis qui s'envoie tout seul, mais elle ne sait pas si vos devis engagent une caution, partent à des collectivités ou doivent être conservés dix ans.
Voilà pourquoi je ne commence jamais par l'outil, mais par un cahier des charges construit avec vous : votre métier, vos contraintes, votre trajectoire. C'est lui qui dicte l'automatisation, pas l'inverse — l'outil n'est que la dernière étape, celle qui exécute une décision déjà prise. La démo, elle, vous vend l'exécution en sautant la décision. Et c'est toute la décision qui fait qu'un système tient.
C'est pour ça que je ne vous dirai pas « lancez-vous seul, c'est facile ». Pas par mépris de vos capacités, mais parce que dès qu'une automatisation touche vos clients, votre facturation ou vos données, ce qui sépare un outil qui marche le jour de la démo d'un système qui tient deux ans ne se voit pas dans la démo.
Vous pouvez m'objecter que j'ai tout intérêt à vous tenir ce discours. C'est exact mais ça ne le rend pas faux pour autant. C'est précisément ce travail que je prépare avec ICyam : non pas cliquer à votre place, mais regarder une automatisation comme on regarde un investissement — ce qu'elle vous rapporte, et ce qu'elle vous coûtera quand vous ne la surveillerez plus.
La démo de trois minutes ou de dix minutes, elle, n'a qu'un seul défaut : elle s'arrête à la dernière minute.