Décision IA dans n8n ou Make :
la brancher sans tout confier

Dans un scénario n8n ou un flux Make, un nœud classique transforme une donnée ou déclenche une action. Un point de décision IA ajoute une étape différente : ce nœud interroge un modèle, et la réponse pilote la branche suivante. Trier une demande, noter une urgence ou classer un document deviennent des étapes automatisées, pas seulement des tâches reportées à plus tard.

Il faut distinguer ce geste d’une simple génération de texte. Un nœud IA qui rédige une réponse client produit du texte libre, à relire avant l’envoi. Un point de décision renvoie une valeur fermée : une catégorie, une note, une probabilité. C’est cette valeur que le flux utilise ensuite pour choisir une branche, sans qu’une personne relise chaque cas.

Une règle simple garde tout son intérêt quand le critère est objectif et stable : un montant au-dessus d’un seuil, un mot-clé précis dans un objet d’e-mail, une case cochée dans un formulaire. Le point de décision IA prend le relais quand le critère dépend d’une formulation libre : le ton d’un message, l’intention derrière une demande, la complétude d’un dossier rédigé en langage naturel.

Comprendre un modèle de décision (Jev), pour aller plus loin

n8n et Make permettent tous les deux d’appeler un modèle IA depuis un nœud HTTP et de brancher la suite du flux sur sa réponse. La différence se joue sur trois points précis pour une décision automatisée : le format de la réponse, la gestion d’une erreur ou d’une réponse imprévue, et l’endroit où tournent vos données.

Sur le format de la réponse, n8n propose un nœud Code distinct, en JavaScript, pour retraiter la sortie du modèle avant de la brancher. C’est utile si la réponse sort parfois du format attendu et doit être corrigée avant la suite du flux. Make ne propose pas cet accès au code dans son module HTTP : le corps de requête se règle en JSON, sans ligne de script (documentation Make, apps.make.com/http, consultée le 20 septembre 2026).

Sur la gestion des erreurs, le nœud HTTP Request de n8n propose une option « Never Error », qui force une réponse de succès même si l’appel renvoie un code d’erreur (documentation n8n, docs.n8n.io, consultée le 20 septembre 2026). Make gère ce cas avec un module Error Handler séparé, aux directives nommées Ignore, Retry, Resume, Commit ou Rollback selon ce que vous voulez faire du reste du scénario (documentation Make, help.make.com, consultée le 20 septembre 2026).

Sur l’hébergement, n8n propose une offre cloud et une option d’auto-hébergement, notamment via Docker ou un déploiement Kubernetes, ce qui compte si vos données ne peuvent pas transiter par un service tiers (documentation n8n, docs.n8n.io, consultée le 20 septembre 2026). Make reste un service cloud uniquement. Aucun des deux points ne rend l’un des outils supérieur à l’autre : le choix dépend de votre contrainte réelle sur ces trois critères.

La construction suit toujours le même déroulé, que vous partiez d’un formulaire, d’un e-mail reçu ou d’un document déposé. Les quatre étapes suivantes s’appliquent aussi bien dans n8n que dans Make.

Techniquement, l’appel au modèle se fait par une simple requête HTTP POST, comme celle envoyée ci-dessous à l’API REST de Cloudflare Workers AI. Le nœud HTTP de n8n ou le module HTTP de Make se contentent d’ajouter le jeton d’API en en-tête et le corps JSON attendu par le modèle. Le détail complet de cet appel, y compris la lecture des probabilités renvoyées, est expliqué pas à pas dans le guide de référence de La Refonte.

1. Préparer les données envoyées au modèle : le texte du message, et tout champ utile à la décision (numéro de commande, historique, catégorie déjà connue).
2. Écrire une instruction qui force une réponse exploitable : une catégorie fermée parmi une liste que vous avez définie, plutôt qu’un texte libre à interpréter.
3. Brancher le résultat vers les étapes suivantes, avec un nœud IF dans n8n ou un module Router dans Make, qui lit la valeur renvoyée par le modèle.
4. Prévoir une sortie par défaut si la réponse est ambiguë ou absente : une branche qui transmet le cas à une personne plutôt qu’un flux qui s’arrête.

POST /client/v4/accounts/{ACCOUNT_ID}/ai/run
Authorization: Bearer {API_TOKEN}

{
  "model": "typesafe/jev",
  "input": {
    "state": "Le client demande un remboursement pour une commande jamais reçue.",
    "questions": {
      "service": {
        "type": "choice",
        "instructions": "Quel service doit traiter cette demande ?",
        "criteria": {
          "livraison": "Colis manquant ou en retard",
          "facturation": "Remboursement, double paiement",
          "technique": "Panne, bug, accès au compte"
        }
      }
    }
  }
}

Trancher selon vos critères avec le sélecteur n8n ou Make

Utiliser Jev sur Cloudflare Workers AI : le guide pas à pas (La Refonte)

Voir un exemple concret de décision automatisée mise en place dans une petite structure

Voici le même point de décision suivi du début à la fin, sur un cas courant : une demande de remboursement arrive par le formulaire du site. Le modèle choisit le service, le flux route, et l’action irréversible, rembourser, reste à une personne.

À chaque étape, le scénario garde une trace : la réponse du modèle, sa confiance et la branche suivie. C’est ce journal qui permet ensuite de régler le seuil sur des cas réels plutôt qu’à l’intuition.

Les mêmes pièges reviennent d’un projet à l’autre, indépendamment de l’outil choisi. Les repérer avant la mise en production évite une bonne partie des reprises.

Un garde-fou n’est utile que s’il se trouve au bon endroit : après la réponse du modèle, et avant toute action qui ne se rattrape pas. Trois emplacements se combinent dans un même flux.

Test déléguer ou garder : quelles étapes gardent une validation

Fiche de cadrage d’une décision : options, seuil, cas à faire remonter

Les guides généralistes sur n8n et Make détaillent rarement ce point, pourtant central pour une petite structure : décider quelles étapes restent automatiques et lesquelles gardent un contrôle humain avant l’action finale.

Trois critères permettent de trancher, ensemble plutôt qu’isolément. L’impact sur le client si la décision est mauvaise : un mauvais tri de service se corrige en une minute, un remboursement erroné beaucoup moins. La réversibilité de l’erreur : une étiquette mal posée se change, un e-mail déjà envoyé non. La fréquence attendue de l’erreur, observée sur les premiers cas réels plutôt que supposée à l’avance.

Pour une petite structure à La Réunion, ce choix se pose souvent sur un nombre limité de cas par semaine. Il devient alors possible de garder une relecture humaine sur les cas à fort impact, et de laisser le flux agir seul sur le reste, sans renoncer à l’automatisation dans son ensemble.

Un point de décision qui fonctionne le jour de sa mise en place n’est pas acquis pour les mois suivants. Un modèle appelé depuis un service tiers évolue, un volume de cas change, une catégorie prévue au départ devient trop étroite.

Une fois le flux construit, deux tâches restent à votre charge dans la durée : surveiller la dérive du seuil de confiance sur des cas réels, et faire évoluer les catégories quand un nouveau type de demande apparaît. L’accompagnement en automatisation de tâches de DodoIA prend en charge le cadrage initial des questions posées au modèle, le branchement dans votre scénario n8n ou Make existant, et la mise en place du seuil et de la relecture humaine.

Automatisation n8n : faites cadrer et brancher ce scénario

Agent IA pour entreprise : quand la suite d’étapes ne peut pas être écrite à l’avance

Estimer le budget d’un projet d’automatisation avant de se lancer