Ressources · Intégration n8n

Intégration Taiga n8nAutomatiser Taiga avec n8n.

Un board Taiga qui avance sans que personne l'ouvre, c'est possible. L'intégration Taiga n8n donne 20 opérations réparties sur 4 ressources, epics, user stories, tâches et issues. Le Taiga Trigger, lui, écoute 6 types d'événement par webhook. Pensé pour les équipes qui tiennent un board agile à côté d'autres outils.

Tester l'intégration Taiga sur n8nVoir les 20 opérations

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

Pourquoi automatiser

À quoi sert l'intégration Taiga n8n ?

L'intégration Taiga n8n relie les boards de projet Taiga aux workflows n8n, dans les deux sens. Le nœud Taiga couvre 20 opérations réparties sur 4 ressources, epics, user stories, tâches et issues : un workflow peut donc créer, lire, mettre à jour ou supprimer chacun de ces objets. Le Taiga Trigger fait l'inverse. Il enregistre un webhook, c'est-à-dire une URL que Taiga appelle, et démarre le workflow dès que quelque chose bouge sur le board.

Premier scénario, la prise en charge des demandes. Un message client arrive dans n8n via Gmail, une étape de tri écarte ce qui n'est pas un bug, et issue.create dépose l'issue dans le bon projet avec sa priorité et sa sévérité déjà renseignées. Personne ne recopie quoi que ce soit à la main.

Deuxième scénario, le reporting de sprint. Un déclencheur horaire lance userStory.getAll sur le milestone en cours, Return All activé, puis task.getAll pour les tâches rattachées. Le résultat part dans MySQL pour alimenter un tableau de bord, ou dans un résumé du lundi matin sur Slack.

Troisième scénario, la mémoire longue. Le Taiga Trigger réagit à l'événement issue, le workflow lit la charge utile et archive chaque mouvement dans MongoDB. Six mois plus tard, l'historique existe encore même si la carte a été supprimée du board.

Quand basculer sur HTTP Request. Le nœud expose les 20 opérations listées plus bas. L'API Taiga propose des endpoints au-delà de cette liste, et le nœud HTTP Request les appelle en réutilisant le même credential Taiga grâce à l'authentification prédéfinie. Un seul identifiant sert donc aux deux nœuds.

Deux limites à connaître avant de construire. Sur les quatre opérations Get Many, c'est Return All qui fait enchaîner toutes les pages de résultats à n8n : désactivé, Limit plafonne ce qui revient, ce qui convient pour un aperçu et casse un export. Ensuite, chaque liste déroulante marquée Name or ID attend un identifiant quand tu l'alimentes par une expression, pas le libellé affiché sur le board. Si n8n est encore nouveau pour toi, la Formation n8n pose les bases avant de toucher au board.

Connexion

Comment connecter Taiga à n8n ?

  1. 01

    Créer le credential Taiga

    Il faut d'abord un compte Taiga. Dans n8n, ouvre le menu Credentials et ajoute un credential Taiga : un credential, c'est le jeu d'identifiants que n8n stocke une fois pour toutes. Le nœud s'authentifie en basic auth, donc il demande un Username, qui accepte ton nom d'utilisateur ou l'adresse e-mail du compte, et un Password.

  2. 02

    Choisir le bon environnement

    Le champ Environment décide à quel Taiga le credential parle. Cloud vise le service hébergé. Self-Hosted vise ton installation, et il fait apparaître un champ URL où tu saisis l'adresse de cette instance. Règle ce duo avant tout test : la suite dépend entièrement du fait que n8n appelle la bonne machine.

  3. 03

    Sélectionner le credential dans le nœud

    Pose un nœud Taiga ou un Taiga Trigger sur le canevas et choisis le credential enregistré dans sa liste déroulante. Les deux nœuds acceptent le même, donc un workflow qui écoute et un workflow qui écrit partagent un seul identifiant. Choisis ensuite la ressource et l'opération : la liste Project Name or ID se remplit toute seule depuis ton compte.

Déclencheurs

Qu'est-ce qui déclenche un workflow depuis Taiga ?

Taiga Trigger est le nœud qui démarre un workflow quand quelque chose se passe dans Taiga. Il écoute 6 événements, listés ci-dessous par famille. Tu en choisis un ou plusieurs, tu actives le workflow : n8n enregistre le webhook (l'URL que Taiga appelle) sur ton compte.

Ce que tu vois dans n8n

Tous les événements, par famille

Une ligne par objet, une puce par action. L'événement à cocher dans le nœud s'écrit objet.action ; survole une puce pour lire quand il se déclenche.

all.*1
  • all.
    • all
issue.*1
  • issue.
    • issue
milestone.*1
  • milestone.
    • milestone
task.*1
  • task.
    • task
userstory.*1
  • userstory.
    • userstory
wikipage.*1
  • wikipage.
    • wikipage

Notes de configuration

01Set up the Taiga TriggerLe Taiga Trigger est la porte d'entrée : il reçoit les événements de Taiga par webhook, une URL que Taiga appelle quand quelque chose se passe, et lance le workflow en quelques secondes. Aucun polling, donc aucun intervalle à régler.

Le Taiga Trigger est la porte d'entrée : il reçoit les événements de Taiga par webhook, une URL que Taiga appelle quand quelque chose se passe, et lance le workflow en quelques secondes. Aucun polling, donc aucun intervalle à régler.

Paramètres clés

  • Project Name or ID : le projet à surveiller, choisi dans la liste ou fourni comme identifiant via une expression. Le champ est requis, donc un trigger couvre un projet.
  • Operations : la sélection multiple de ce qu'on écoute, requise elle aussi. Six valeurs sont disponibles et plusieurs peuvent cohabiter dans le même trigger.
Quand l'utiliser
dès que le workflow doit réagir au board plutôt qu'à une horloge. Active le workflow pour enregistrer le webhook, et garde en tête qu'un workflow désactivé ne reçoit plus rien.
02Issue eventsLa valeur issue envoie au trigger chaque mouvement d'issue sur le projet surveillé. C'est le côté bug et incident de Taiga, et souvent le plus bavard des six, ce qui rend le routage d'autant plus utile.

La valeur issue envoie au trigger chaque mouvement d'issue sur le projet surveillé. C'est le côté bug et incident de Taiga, et souvent le plus bavard des six, ce qui rend le routage d'autant plus utile.

Cas d'usage
une issue qui arrive est confrontée au planning d'astreinte, et le message part dans le bon canal. Autre variante : le workflow lit la charge utile, appelle issue.get pour la fiche complète, puis écrit une ligne dans une base de suivi pour mesurer les délais de réponse plus tard.
Quand l'utiliser
pour tout ce qui doit se passer vite après le dépôt ou la modification d'un bug. Place un filtre tôt dans le workflow, parce qu'un projet actif peut déclencher cet événement plusieurs fois par jour, et tu veux rarement que chacun d'eux traverse la chaîne entière.
03User Story and Task eventsDeux valeurs distinctes, userstory et task, couvrent le côté livraison du board. Coche les deux dans un même trigger quand un workflow suit toute la chaîne, ou sépare-les en deux workflows quand les réactions diffèrent.

Deux valeurs distinctes, userstory et task, couvrent le côté livraison du board. Coche les deux dans un même trigger quand un workflow suit toute la chaîne, ou sépare-les en deux workflows quand les réactions diffèrent.

Cas d'usage
une story qui bouge sert de signal pour rafraîchir une page de statut destinée au client. Une tâche qui bouge sert à recalculer le reste à faire du sprint, avec task.getAll filtré sur le milestone.
Quand l'utiliser
pour des signaux d'avancement plutôt que pour des alertes. Ces deux valeurs portent le rythme quotidien d'une équipe, donc elles alimentent bien les tableaux de bord et les résumés. À retenir : le trigger signale qu'un événement a eu lieu sur ce type d'objet ; quand le workflow a besoin des valeurs à jour, une opération Get juste après le trigger reste la façon fiable de les obtenir.
04Milestone (Sprint) eventsLa valeur milestone se déclenche au niveau du sprint. Dans Taiga, le milestone est le conteneur de sprint : cet événement marque donc le début et la fin d'une itération, pas le déplacement d'une carte isolée.

La valeur milestone se déclenche au niveau du sprint. Dans Taiga, le milestone est le conteneur de sprint : cet événement marque donc le début et la fin d'une itération, pas le déplacement d'une carte isolée.

Cas d'usage
quand un sprint change, un workflow récupère les stories rattachées avec userStory.getAll et le filtre milestone, puis rédige le compte rendu de sprint que personne n'aime écrire à la main.
Quand l'utiliser
pour les rituels. Revue de sprint, préparation de rétro, point de capacité envoyé au client. Le volume reste faible comparé aux issues ou aux tâches, ce qui en fait un bon candidat pour des workflows qui se terminent par un document ou un long message : aucun risque de noyer qui que ce soit. Un même trigger peut la porter à côté d'autres valeurs si un seul workflow gère plusieurs rythmes.
05Wikipage and All eventsDeux valeurs ferment la liste. wikipage réagit au côté wiki d'un projet Taiga, les pages où s'écrivent les specs et les décisions. all joue le rôle de fourre-tout : coche-la et le trigger accepte tous les types d'événement au lieu d'un sous-ensemble choisi.

Deux valeurs ferment la liste. wikipage réagit au côté wiki d'un projet Taiga, les pages où s'écrivent les specs et les décisions. all joue le rôle de fourre-tout : coche-la et le trigger accepte tous les types d'événement au lieu d'un sous-ensemble choisi.

Cas d'usage
une modification du wiki envoie une notification aux personnes qui s'appuient sur cette page. Avec all, un seul workflow collecte tout et un nœud Switch trie par type, ce qui garde le canevas compact quand plusieurs réactions partagent les mêmes étapes de préparation.
Quand l'utiliser
prends wikipage quand le problème à résoudre est une documentation qui dérive. Prends all quand tu allais construire quatre workflows presque identiques. Aucun caractère joker à saisir ici : la valeur all est la façon d'écouter l'ensemble.
Actions

Que sait faire le nœud Taiga ?

Le nœud Taiga expose 20 opérations sur 4 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
RessourceCreateGetGet ManyUpdateDelete
Epic✓✓✓✓✓
Issue✓✓✓✓✓
Task✓✓✓✓✓
User Story✓✓✓✓✓

Epic

5 opérations
01

Create an epic

epic.create

Ce que tu vois dans n8n

Notes & cas d'usage

Cette opération ouvre un epic dans un projet Taiga et renvoie l'epic créé, identifiant compris, prêt pour les nœuds suivants.

Paramètres clés

  • Project Name or ID : le projet auquel l'epic appartient, choisi dans la liste ou passé comme identifiant via une expression du type {{ $json.projectId }}.
  • Subject : le titre de l'epic, seul autre champ requis.
  • Color : dans Additional Fields, un code couleur en notation hexadécimale, pratique quand chaque domaine produit a sa teinte sur le board.
Cas d'usage
une feuille de cadrage trimestriel est lue ligne par ligne et chaque ligne devient un epic, étiqueté via Tag Names or IDs pour que le board soit rangé dès le premier jour.
02

Delete an epic

epic.delete

Ce que tu vois dans n8n

Notes & cas d'usage

Supprimer un epic demande une seule valeur, et une fois l'appel passé, Taiga ne détient plus cet epic.

Paramètres clés

  • Epic ID : l'identifiant de l'epic à supprimer, généralement récupéré d'un nœud précédent avec {{ $json.id }} plutôt que saisi à la main.
Cas d'usage
un workflow qui crée des epics depuis un backlog externe a besoin de sa branche de ménage. Quand la fiche d'origine est annulée, la même exécution supprime l'epic ouvert plus tôt, et le board ne se remplit pas de coquilles vides.
03

Get an epic

epic.get

Ce que tu vois dans n8n

Notes & cas d'usage

Lire un epic renvoie son état courant tel que Taiga le stocke, exactement ce dont un nœud IF a besoin avant de trancher.

Paramètres clés

  • Epic ID : l'identifiant de l'epic à récupérer. Le nœud ne renvoie que celui-là, c'est donc l'appel d'une recherche ciblée et pas d'un balayage.
Cas d'usage
avant qu'un point d'avancement parte chez un client, le workflow récupère l'epic et vérifie s'il est toujours bloqué. Annoncer des progrès sur un travail à l'arrêt, ça se voit, et le contrôle coûte un nœud.
04

Get many epics

epic.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Un seul appel ramène les epics d'un projet, un item n8n par epic, prêts à être parcourus en boucle.

Paramètres clés

  • Project Name or ID : requis, il cadre tout l'appel sur un projet.
  • Return All : activé, n8n parcourt toutes les pages d'epics ; désactivé, Limit fixe le nombre maximal d'epics renvoyés.
  • Is Closed : dans Filters, garde ou écarte les epics clos.
Cas d'usage
un export mensuel de la feuille de route tourne avec Return All activé et Is Closed désactivé, pour que le fichier ne montre que ce qui est encore vivant.
05

Update an epic

epic.update

Ce que tu vois dans n8n

Notes & cas d'usage

Un epic évolue au fil du trimestre. Cette opération réécrit les champs que tu renseignes et laisse le reste intact.

Paramètres clés

  • Epic ID : l'identifiant de l'epic à mettre à jour.
  • Is Blocked : dans Update Fields, l'interrupteur qui marque l'epic comme bloqué.
  • Blocked Note : la raison du blocage. Elle a besoin de l'interrupteur Is Blocked activé pour avoir du sens, donc règle les deux ensemble.
Cas d'usage
une dépendance glisse en amont, le workflow marque l'epic avec la raison écrite noir sur blanc, et le point du matin part du board plutôt que des souvenirs de chacun.

Issue

5 opérations
06

Create an issue

issue.create

Ce que tu vois dans n8n

Notes & cas d'usage

Les issues, c'est le côté bug et incident de Taiga. Cette opération en dépose une dans un projet et renvoie l'issue créée.

Paramètres clés

  • Project Name or ID et Subject : les deux champs requis, le projet de destination et le titre de l'issue.
  • Priority Name or ID, Severity Name or ID et Type Name or ID : dans Additional Fields, les trois qualificatifs qui permettent à un workflow de tri de donner sa forme à l'issue dès la création.
Cas d'usage
un signalement entrant est classé en amont, et la sévérité qu'il mérite s'inscrit directement dans l'issue au lieu d'être corrigée plus tard.
07

Delete an issue

issue.delete

Ce que tu vois dans n8n

Notes & cas d'usage

Parfois, un workflow doit défaire son propre travail : cette opération efface une issue du projet.

Paramètres clés

  • Issue ID : l'identifiant de l'issue à supprimer. Alimente-le depuis le nœud qui a trouvé l'issue, pour que la suppression vise bien la fiche inspectée.
Cas d'usage
une étape de dédoublonnage compare un nouveau signalement à la file ouverte. Quand deux entrées décrivent le même bug, la plus récente part et l'originale conserve son historique, ses commentaires et la personne assignée.
08

Get an issue

issue.get

Ce que tu vois dans n8n

Notes & cas d'usage

Quand un workflow a besoin de l'état réel d'une issue, c'est cet appel. Il renvoie l'issue telle qu'elle est maintenant, pas telle qu'elle était au moment où un événement est parti.

Paramètres clés

  • Issue ID : l'identifiant de l'issue à récupérer, souvent tiré de la charge utile d'un trigger.
Cas d'usage
une alerte qui dit seulement qu'une issue a bougé ne sert à rien. Placer cette opération juste après le trigger permet au message de porter le sujet, le statut et la personne dessus, ce que le lecteur cherche vraiment.
09

Get many issues

issue.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Un projet accumule vite des issues, alors cette opération arrive avec le jeu de filtres le plus fourni des quatre listings.

Paramètres clés

  • Project Name or ID : requis, c'est le périmètre de la requête.
  • Order By : dans Filters, trie le résultat, par exemple sur created_date ou sur severity.
  • Return All : activé pour un export complet, désactivé pour s'arrêter à Limit.
Cas d'usage
la liste de tri du matin remonte les issues ouvertes triées par created_date, pour que le signalement le plus ancien soit la première chose que l'équipe lise.
10

Update an issue

issue.update

Ce que tu vois dans n8n

Notes & cas d'usage

Tout peut bouger sur une issue après son dépôt, et c'est ici que ces changements s'appliquent.

Paramètres clés

  • Issue ID : l'identifiant de l'issue à mettre à jour, seul champ requis.
  • Status Name or ID : dans Update Fields, le nouveau statut de l'issue.
  • Milestone (Sprint) Name or ID : le milestone auquel l'issue appartient, c'est ainsi qu'un workflow tire un bug dans le sprint en cours.
Cas d'usage
un client confirme qu'un correctif fonctionne, et l'issue se ferme en rejoignant le sprint courant dans la même exécution, sans rouvrir le board.

Task

5 opérations
11

Create a task

task.create

Ce que tu vois dans n8n

Notes & cas d'usage

Les tâches vivent sous une user story dans Taiga. Cette opération en ajoute une à un projet et la renvoie.

Paramètres clés

  • Project Name or ID et Subject : requis, le projet et le titre de la tâche.
  • User Story Name or ID : dans Additional Fields, la story à laquelle la tâche se rattache, ce qui garde le taskboard lisible.
  • Taskboard Order : la position de la tâche sur le taskboard.
Cas d'usage
une checklist récurrente se déplie en tâches sous la story qui porte le travail, chacune placée dans l'ordre où l'équipe l'exécute.
12

Delete a task

task.delete

Ce que tu vois dans n8n

Notes & cas d'usage

Sortir une tâche du board tient à un seul champ, et l'action est définitive côté Taiga.

Paramètres clés

  • Task ID : l'identifiant de la tâche à supprimer. Fais-le passer par un filtre d'abord, parce qu'aucune confirmation n'arrive une fois que le nœud s'exécute.
Cas d'usage
une checklist générée automatiquement ne s'applique finalement pas, le périmètre change, et le workflow retire les tâches qu'il avait créées dans le même lot pour que la story ne garde que le travail encore réel.
13

Get a task

task.get

Ce que tu vois dans n8n

Notes & cas d'usage

Ramener une tâche dans un workflow renvoie tous les champs que Taiga conserve à son sujet, en un seul item.

Paramètres clés

  • Task ID : l'identifiant de la tâche à récupérer.
Cas d'usage
un suivi de temps reçoit une référence de tâche depuis un outil externe et lui manque le sujet et le statut avant d'écrire quoi que ce soit. Cette opération résout la référence, et la ligne enregistrée se lit comme une phrase au lieu d'un numéro.
14

Get many tasks

task.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Les listes de tâches deviennent longues, alors ce listing embarque ses propres filtres, orientés taskboard plutôt que backlog.

Paramètres clés

  • Project Name or ID : requis.
  • User Story Name or ID : dans Filters, restreint le résultat aux tâches d'une seule story.
  • Is Closed : garde ou écarte les tâches déjà terminées.
  • Return All : activé pour parcourir toute la liste, désactivé pour s'arrêter à Limit.
Cas d'usage
un comptage quotidien des tâches ouvertes par story alimente un burn-down simple, sans toucher à un tableur.
15

Update a task

task.update

Ce que tu vois dans n8n

Notes & cas d'usage

Faire avancer une tâche, ou la déplacer de côté, passe par cette opération. Seuls les champs remplis sont écrits.

Paramètres clés

  • Task ID : l'identifiant de la tâche à mettre à jour.
  • Status Name or ID : dans Update Fields, le nouveau statut de la tâche.
  • User Story Order : la position de la tâche à l'intérieur de sa user story, utile quand la séquence compte plus que le statut.
Cas d'usage
un développeur clôt une tâche depuis une commande de messagerie, et le workflow réécrit le statut dans Taiga pour que le board colle au réel avant le point du matin.

User Story

5 opérations
16

Create a user story

userStory.create

Ce que tu vois dans n8n

Notes & cas d'usage

Les user stories portent le travail dans Taiga. Cette opération en ajoute une à un projet et renvoie la story créée.

Paramètres clés

  • Project Name or ID et Subject : les deux champs requis.
  • Backlog Order : dans Additional Fields, la position de la story dans le backlog, pour qu'une nouvelle arrivée se pose en haut plutôt qu'en bas.
  • Milestone (Sprint) Name or ID : le sprint auquel la story appartient, quand elle est déjà planifiée.
Cas d'usage
les notes d'un entretien de cadrage deviennent des stories, ordonnées selon la priorité donnée pendant l'entretien.
17

Delete a user story

userStory.delete

Ce que tu vois dans n8n

Notes & cas d'usage

Certaines stories n'auraient jamais dû exister. Cette opération en retire une du projet pour de bon.

Paramètres clés

  • User Story ID : l'identifiant de la story à supprimer, que le nœud attend sous forme d'identifiant et pas sous le titre affiché sur le board.
Cas d'usage
un workflow en cours de test a écrit une dizaine de stories dans un vrai projet. Une exécution de nettoyage relit les identifiants journalisés pendant le test et les supprime une à une, laissant le backlog dans l'état où il était.
18

Get a user story

userStory.get

Ce que tu vois dans n8n

Notes & cas d'usage

Une story, récupérée par son identifiant, revient avec les champs que Taiga garde sur elle, dont son statut et ses valeurs d'ordre.

Paramètres clés

  • User Story ID : l'identifiant de la story à récupérer.
Cas d'usage
une note de version se rédige à partir d'une liste de références livrées. Pour chacune, cette opération fournit le sujet et la description, si bien que la note vient du board et pas du souvenir approximatif qu'on garde d'un sprint.
19

Get many user stories

userStory.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Les listes de stories, c'est là que commence le reporting, et les filtres suivent ici l'organisation d'un backlog.

Paramètres clés

  • Project Name or ID : requis.
  • Epic Name or ID : dans Filters, ne renvoie que les stories rattachées à un epic.
  • Is Archived : garde ou écarte les stories archivées.
  • Return All : activé pour tout le backlog, désactivé pour s'arrêter à Limit.
Cas d'usage
un point d'avancement par epic compte les stories de cet epic par statut, archives exclues, et envoie le ratio au product owner.
20

Update a user story

userStory.update

Ce que tu vois dans n8n

Notes & cas d'usage

Réécrire une story après coup, voilà le rôle de cette opération, que le changement porte sur un statut ou sur une position.

Paramètres clés

  • User Story ID : l'identifiant de la story à mettre à jour.
  • Status Name or ID : dans Update Fields, le nouveau statut.
  • Kanban Order et Sprint Order : la position de la story dans le kanban et dans le milestone, les deux valeurs qui décident de l'endroit où elle apparaît.
Cas d'usage
une validation arrive de l'extérieur de l'équipe, et la story passe à la colonne suivante au bon rang.
Besoin d'aide

Besoin d'aide pour automatiser Taiga avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

Taiga et n8n, les questions qui suivent

01L'intégration Taiga n8n est-elle gratuite ?
Oui, côté n8n. Le nœud Taiga et le Taiga Trigger sont livrés avec n8n : rien à installer, rien de plus à payer, que tu travailles sur n8n Cloud ou sur une instance auto-hébergée en Community Edition sous licence Sustainable Use. Un workflow se comporte de la même façon dans les deux cas. Ce qu'il faut en revanche, c'est un compte Taiga, puisque le credential s'authentifie comme un vrai utilisateur de ce compte. Ce que coûte Taiga lui-même sort du cadre de cette page.
02Quels credentials faut-il pour le nœud Taiga ?
De la basic auth, rien de plus compliqué. Le credential demande un Username, qui accepte soit le nom d'utilisateur soit l'adresse e-mail du compte, et un Password. Il demande aussi un Environment, Cloud ou Self-Hosted, et le choix Self-Hosted fait apparaître un champ URL pour l'adresse de ton instance. Un seul credential sert au nœud Taiga et au Taiga Trigger, et une fois enregistré dans le menu Credentials il s'affiche dans la liste déroulante de tous les workflows qui en ont besoin.
03Quelles sont les limites du nœud Taiga dans n8n ?
Deux comptent en pratique. La pagination d'abord : sur les quatre opérations Get Many, epics, issues, tâches et user stories, c'est Return All qui fait parcourir toutes les pages à n8n, et quand il est désactivé la valeur Limit plafonne le résultat. La couverture ensuite : le nœud expose 20 opérations sur 4 ressources, et tout ce que l'API Taiga propose au-delà de cette liste s'atteint avec le nœud HTTP Request, qui réutilise le même credential Taiga via l'authentification prédéfinie. Un endpoint manquant coûte donc un nœud de plus, pas un second identifiant.
04Le Taiga Trigger réagit-il en temps réel ?
Oui. Le Taiga Trigger fonctionne par webhook : n8n enregistre une URL que Taiga appelle quand quelque chose se produit, et l'événement atteint ton workflow en quelques secondes. Aucun polling, aucun intervalle à régler. Le webhook s'enregistre au moment où tu actives le workflow, donc un workflow laissé inactif ne reçoit rien. Ce qui arrive se choisit dans le paramètre Operations, qui propose 6 valeurs, et il n'y a aucun caractère joker à saisir : sélectionne la valeur all pour recevoir tous les types d'événement.
05n8n ou Make pour Taiga ?
Ça dépend de quatre critères, et le prix n'est pas le premier. L'hébergement : n8n tourne sur ton propre serveur avec Docker ou npm, ou sur n8n Cloud, tandis que Make existe seulement en hébergé. La maîtrise des données suit, puisqu'une instance auto-hébergée garde les charges utiles Taiga dans ton infrastructure. Le modèle de coût : Make facture à l'opération, ce qui change la façon de concevoir un workflow qui boucle sur un long backlog. Et la logique visuelle, où les deux outils ne se ressemblent pas. Monte le même petit workflow Taiga sur les deux, la réponse se voit vite.
Même plateforme

Autres docs utiles sur ce stack.

Voir toutes les intégrations