Ressources · Intégration n8n

Intégration Cortex n8nAutomatiser Cortex avec n8n.

Une analyse qui traîne dans une file d'attente, c'est une alerte que personne ne regarde. L'intégration Cortex n8n donne 4 opérations sur 3 ressources : Analyzer, Responder et Job. Aucun trigger Cortex n'existe : le workflow part d'un horaire ou d'un appel extérieur, puis lance l'analyse et récupère le rapport.

Tester l'intégration Cortex sur n8nVoir les 4 opérations

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Pourquoi automatiser

À quoi sert l'intégration Cortex n8n ?

Le nœud Cortex applique un analyseur ou un responder à une entité donnée, sur un serveur Cortex que tu héberges toi-même. L'analyseur reçoit un observable, c'est-à-dire la valeur à faire vérifier, et rend un verdict. Le responder, lui, reçoit une entité et agit dessus. Dans les deux cas le serveur crée un job, et le nœud sait ensuite relire ce job et son rapport.

Le premier usage tient en une phrase : plus une seule valeur analysée à la main. Un Schedule Trigger, le déclencheur qui se réveille à intervalle fixe, lit les lignes en attente dans MySQL, le nœud passe chacune à analyzer.execute, et le verdict arrive dans un canal Slack avec la valeur concernée. L'analyste ouvre son canal, plus la console.

Deuxième usage : traiter les pièces jointes sans les ouvrir. Une boîte Gmail alimente le workflow, chaque fichier part en analyse, et la sortie binaire atterrit dans le champ que tu as nommé. Un template public, 1602, associe d'ailleurs le nœud Cortex au nœud TheHive pour analyser des emails.

Troisième usage : garder une trace consultable. Les jobs finissent sur le serveur, job.report rend le rapport à partir d'un identifiant de job, et tu l'écris où tu veux. Trois mois plus tard, la question « qu'est-ce qui a été vérifié, et qu'est-ce que ça a donné » se répond sans rouvrir Cortex. Le template 809 ne fait que ça : récupérer les détails d'un job.

Les limites sont nettes. Le nœud couvre les analyseurs, les responders et les jobs, rien d'autre de l'API Cortex. Pour le reste, le nœud HTTP Request appelle n'importe quel endpoint de l'API en réutilisant le même credential, c'est-à-dire l'accès enregistré une fois dans n8n. Et comme il n'y a pas de trigger Cortex, le workflow démarre toujours ailleurs.

Si la question porte sur la plateforme plutôt que sur le nœud, l'Avis n8n traite l'hébergement et le coût, et la Formation n8n revient sur les expressions et la gestion d'erreur sur des workflows réels.

Connexion

Comment connecter Cortex à n8n ?

  1. 01

    Installe Cortex sur ton serveur

    Cortex est un logiciel que tu fais tourner chez toi, donc la première étape se passe en dehors de n8n. Installe-le sur une machine que ton instance n8n peut joindre sur le réseau, et note l'adresse sur laquelle il répond. C'est cette adresse que le credential attend ensuite, sous la forme http://<your_server_address>:9001/ affichée par défaut dans le champ.

  2. 02

    Génère une clé API dans Cortex

    L'authentification passe par une clé API, et une seule. Elle se génère depuis Cortex, pour le compte dont les analyseurs et les responders serviront au workflow : un job s'exécute avec les droits attachés à cette clé. Copie la valeur tout de suite, puis laisse-la en dehors du workflow. Sa place est dans le credential, pas dans un champ de nœud.

  3. 03

    Crée le credential Cortex dans n8n

    Dans n8n, ouvre le menu Credentials et crée un credential Cortex, l'accès que n8n conserve pour s'authentifier. La clé va dans API Key, l'adresse du serveur dans Cortex Instance. Un credential se crée une fois et se retrouve ensuite dans la liste déroulante de chaque nœud Cortex : le deuxième workflow n'a plus rien à configurer.

Actions

Que sait faire le nœud Cortex ?

Le nœud Cortex expose 4 opérations sur 3 ressources. Pour chacune : le nœud tel que tu le configures dans n8n, les champs obligatoires, et nos notes de terrain.

Matrice ressources × opérations
RessourceGetExecuteReport
Analyzer✓
Job✓✓
Responder✓

Analyzer

1 opération
01

Execute an analyzer

analyzer.execute

Ce que tu vois dans n8n

Notes & cas d'usage

Lance un analyseur sur un observable et rend le job que Cortex vient de créer.

Paramètres clés

  • Analyzer Type Name or ID : se choisit dans la liste chargée depuis ton serveur, ou se force par une expression du type {{ $json.analyzer }}.
  • Observable Type Name or ID : le type de la valeur soumise, dans une liste similaire.
  • Observable Value : la valeur elle-même.
  • Put Output File in Field : le nom du champ binaire de sortie où le fichier est déposé.
  • TLP : le niveau de partage de l'observable analysé, de 0 (White) à 3 (Red).
  • Force : contourne le cache, quand une valeur a déjà été analysée et que tu veux un résultat frais.
Cas d'usage
vérifier chaque valeur d'une file avant tout regard humain.

Job

2 opérations
02

Get a job

job.get

Ce que tu vois dans n8n

Notes & cas d'usage

Renvoie les détails que Cortex garde sur un job, à partir de son identifiant.

Paramètres clés

  • Job ID : l'identifiant du job, le plus souvent {{ $json.id }} repris du nœud qui l'a lancé.
Cas d'usage
la boucle d'attente sur un analyseur lent. Le workflow lance le job, un nœud Wait met en pause, cette opération relit le job, et un IF décide s'il faut refaire un tour ou avancer. C'est l'appel léger des deux opérations Job : il dit où en est le travail, pas ce qu'il a trouvé.
03

Get a job report

job.report

Ce que tu vois dans n8n

Notes & cas d'usage

Récupère ce que l'analyseur ou le responder a produit, une fois le job terminé.

Paramètres clés

  • Job ID : le même identifiant, mais utilisé après la fin du job plutôt que pendant.
Cas d'usage
l'archivage. Le rapport est la partie qui mérite d'être conservée, donc il part en base ou en tableur, ou bien on en extrait un champ pour composer un message court. Appelée trop tôt sur une analyse longue, l'opération ne rend rien d'utile : c'est le rôle de la boucle Wait décrite au-dessus.

Responder

1 opération
04

Execute a responder

responder.execute

Ce que tu vois dans n8n

Notes & cas d'usage

Confie une entité à un responder, pour que Cortex agisse dessus au lieu de se contenter de la décrire.

Paramètres clés

  • Responder Type Name or ID : le responder à exécuter, depuis la liste ou par expression.
  • Entity Type Name or ID : le type de données de l'objet transmis.
  • Entity Object (JSON) : l'objet lui-même, en JSON.
  • JSON Parameters : bascule entre un objet JSON unique et des attributs séparés, saisis dans Parameters.
Cas d'usage
l'étape qui suit un verdict négatif, où l'entité sortie de l'analyse part directement en réponse sans que personne la ressaisisse.
Besoin d'aide

Besoin d'aide pour automatiser Cortex avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

Cortex et n8n, les questions qui viennent ensuite

01L'intégration Cortex n8n est-elle gratuite dans n8n ?
Oui, côté n8n. Le nœud Cortex est livré avec n8n : rien à installer, aucun module à acheter, et le comportement est le même sur n8n Cloud, l'offre hébergée par n8n, que sur une instance auto-hébergée en Docker ou en npm. Un workflow construit d'un côté tourne à l'identique de l'autre. Ce qui se trouve derrière le credential est une autre histoire : Cortex est un logiciel que tu installes sur ton propre serveur, et c'est un prérequis pour que le nœud ait quelqu'un à qui parler. Le coût de ce côté-là n'est pas traité ici.
02Quels accès faut-il pour connecter Cortex à n8n ?
Une clé API, plus l'adresse de ton serveur. Cortex accepte l'authentification par clé API et rien d'autre, donc pas d'OAuth à négocier, pas de liste de scopes à cocher. Le formulaire du credential demande deux choses : la clé, et l'URL de l'instance Cortex, un champ prérempli d'un gabarit qui pointe vers le port 9001 de ton propre serveur. Les deux vivent dans un credential unique, enregistré dans le menu Credentials de n8n, que chaque nœud Cortex retrouve ensuite dans sa liste. Les droits sont ceux du compte derrière la clé : une clé restreinte limite les analyseurs et les responders accessibles au workflow.
03Qu'est-ce que le nœud Cortex ne sait pas faire ?
Beaucoup de choses, et c'est assumé. Le nœud expose 4 opérations sur 3 ressources : exécuter un analyseur, exécuter un responder, lire un job, lire un rapport de job. Tout le reste de l'API Cortex n'a pas d'opération dédiée, et se rattrape avec le nœud HTTP Request, qui appelle n'importe quel endpoint en réutilisant le même credential. Il n'y a pas non plus de trigger, donc rien du côté Cortex ne peut démarrer un workflow tout seul. Enfin, les analyseurs travaillent en job plutôt qu'en réponse immédiate : sur une analyse longue, il faut attendre avant que le rapport vaille la peine d'être demandé.
04Comment déclencher un workflow Cortex sans trigger dédié ?
En le faisant partir d'ailleurs, puisque le nœud trigger Cortex n'existe pas. Trois montages couvrent presque tous les cas. Le Schedule Trigger se réveille à intervalle fixe et traite ce qui attend. Le nœud Webhook donne à n8n une URL, une adresse qu'un service extérieur appelle quand il se passe quelque chose : l'outil qui détecte l'observable le pousse directement dedans. Sinon, le trigger d'un autre outil ouvre la chaîne et le nœud Cortex se place plus loin. Une fois le job lancé, les opérations Job disent où il en est.
05n8n ou Make pour piloter Cortex ?
La réponse dépend de l'endroit où les données ont le droit de passer. Cortex tourne sur ton serveur, et n8n peut tourner juste à côté, auto-hébergé en Docker ou en npm : les observables ne sortent pas d'une infrastructure que tu maîtrises. Make est hébergé, sans option d'auto-hébergement, et se facture à l'opération, ce qui change le calcul dès qu'un workflow analyse beaucoup de valeurs une par une. En revanche, son éditeur visuel se lit souvent plus vite quand on ne construit pas d'automatisations tous les jours. Make pour un flux hébergé et court, n8n quand l'analyse doit rester à la maison.
Même plateforme

Autres docs utiles sur ce stack.

Voir toutes les intégrations