Agents IA et n8n : quand le low-code suffit

La question arrive presque toujours sous la même forme : « est-ce que je peux faire ça avec n8n, sans mobiliser un développeur ? » Derrière, il y a rarement une curiosité technique. Il y a un budget, un délai, et une personne dans l'équipe qui a déjà monté deux ou trois automatisations et qui s'en sort très bien.

Une orchestration low-code suffit tant que vous pouvez dessiner le chemin complet à l'avance : un déclencheur, des étapes connues, un résultat attendu. Dès que le travail demande de boucler, de se souvenir d'une exécution à l'autre ou de décider du chemin en cours de route, vous n'êtes plus dans l'automatisation et le low-code devient un plafond.

Ce qu'une orchestration low-code fait vraiment bien

Je vois passer beaucoup de mépris pour ces outils dans les équipes techniques, et il est mal placé. Enchaîner des étapes déterministes entre des services qui ont des API, avec un déclencheur clair et un chemin visible, c'est exactement ce pour quoi ils sont faits, et ils le font mieux que du code maison. Un formulaire remplit une ligne dans un tableur, qui crée une fiche dans le CRM, qui envoie une notification. Une facture arrive dans une boîte mail, elle est classée, extraite, poussée en comptabilité. Ces chaînes représentent une part énorme du travail administratif d'une PME, et elles n'ont aucun besoin d'intelligence.

Le vrai bénéfice n'est d'ailleurs pas technique. Il est organisationnel : la personne qui a monté le flux peut le modifier seule, six mois plus tard, sans ticket, sans sprint, sans attendre que quelqu'un se libère. Dans beaucoup d'entreprises, cette autonomie vaut plus cher que l'élégance du code. Un flux low-code un peu bancal mais compris par trois personnes bat un script parfait que seul son auteur sait relancer, et son auteur a changé de poste.

Un enchaînement d'étapes n'est pas un agent, même quand il appelle un modèle

C'est là que la confusion s'installe, et elle est entretenue par le vocabulaire commercial. Ces outils proposent tous, désormais, un bloc « IA » ou « agent » que vous posez au milieu du flux. Vous lui donnez un texte, il vous rend un résumé, une classification, une réponse rédigée. C'est utile, parfois spectaculaire, et ça ne fait pas de votre flux un agent.

La différence est simple à énoncer : dans un flux, c'est vous qui avez décidé de l'ordre des étapes, au moment de la conception. Le modèle est appelé à un endroit précis pour produire un morceau de texte, puis le flux continue sur le rail que vous avez posé. Un agent, lui, reçoit un objectif et choisit lui-même quoi faire, dans quel ordre, et quand s'arrêter. J'ai détaillé ce qu'il y a dans le capot d'un agent : des outils, une boucle, et une mémoire. Un bloc de modèle dans un flux n'a aucun des trois.

Trois signaux qui indiquent que vous avez atteint le plafond

Le premier, c'est le besoin de boucler. Agir, regarder ce que ça a produit, constater que ce n'est pas bon, corriger, recommencer. Un flux peut avoir des conditions et des branches, mais chaque branche a été prévue par un humain. Quand le nombre de cas à prévoir explose, ou quand la bonne action dépend de ce que l'étape précédente a réellement renvoyé plutôt que de ce qu'elle était censée renvoyer, vous passez votre temps à rajouter des branches. Le flux devient un labyrinthe que plus personne ne relit, et vous avez perdu le bénéfice principal du low-code.

Le deuxième, c'est la mémoire. Un flux démarre vierge à chaque exécution. Tant que le travail tient dans une exécution, ça ne pose aucun problème. Mais dès que la tâche s'étale (un dossier qu'on instruit sur trois semaines, un suivi commercial où ce qui s'est dit en mars change ce qu'on fait en juin), il faut que le système sache ce qui a déjà été décidé. On peut bricoler ça avec une base externe, et ça marche un temps, jusqu'au moment où ce qu'il faut retenir n'est plus une donnée mais un contexte.

Le troisième, c'est l'imprévisibilité du chemin. Certaines tâches ne peuvent pas être dessinées à l'avance parce que la bonne étape suivante dépend de ce qu'on trouve en route. Diagnostiquer une panne, instruire une demande atypique, explorer une base pour répondre à une question qu'on n'avait pas anticipée. Vous pouvez tenter de modéliser l'arbre complet des possibilités : vous découvrirez qu'il est plus grand que votre patience.

Le critère de décision tient en une question

Avant de choisir, posez-vous celle-ci, honnêtement : pouvez-vous dessiner le chemin complet au tableau, avec ses branches, avant d'écrire la première ligne ?

Ce critère a un avantage : il ne demande aucune compétence technique pour être appliqué. Un directeur d'exploitation sait parfaitement dire si le travail qu'il décrit suit toujours le même chemin ou si ses équipes improvisent. C'est généralement une meilleure source que l'avis de l'éditeur de l'outil.

Les deux approches cohabitent mieux qu'elles ne se remplacent

L'opposition que je viens de poser est utile pour décider, elle est fausse en production. Les montages qui tiennent le mieux font les deux : une orchestration low-code porte la plomberie (le déclencheur, la récupération des données, l'envoi du résultat, les notifications) et appelle un agent sur la seule partie du travail qui demande du jugement. Chacun fait ce qu'il sait faire. Le flux reste lisible par l'équipe métier, l'agent reste cantonné à un périmètre où on peut vérifier ce qu'il produit.

Le piège, dans ce montage, n'est pas technique non plus. C'est de laisser l'agent démarrer sans que le travail de préparation ait été fait. Un agent ne peut utiliser que ce qui est écrit, et la préparation prime très largement sur l'exécution : deux heures passées à écrire ce que le processus attend vraiment économisent des jours de corrections. C'est aussi vrai pour un flux low-code, mais un flux rate bruyamment, alors qu'un agent mal cadré rate en silence et avec conviction.

Le réflexe que je recommande n'est donc pas « agent partout » et encore moins « low-code jamais ». C'est de commencer par le low-code quand le chemin se dessine, parce que c'est moins cher et plus autonome pour l'équipe, et de ne construire un agent que lorsqu'on a buté sur une des trois limites, en sachant laquelle. Une équipe qui sait dire « on est bloqués sur la mémoire » a déjà fait le plus dur du cadrage. Celle qui demande un agent parce que le mot circule en comité de direction s'apprête à payer cher une automatisation qu'elle aurait pu monter en deux après-midi.