Trigger.dev

Trigger.dev est une plateforme open source de tâches en arrière-plan et de workflows IA créée par Matt Aitken et Eric Allam, une équipe basée à Dublin soutenue par Y Combinator et des investisseurs de série A, dont Standard Capital. Elle résout un problème spécifique et persistant : les fonctions serverless comme AWS Lambda et Vercel ont des limites strictes de délai d'attente (timeout) de quelques secondes ou minutes, alors que les pipelines IA, les tâches de traitement de documents et les workflows d'agents à plusieurs étapes nécessitent couramment de s'exécuter pendant des minutes, voire des heures. Trigger.dev permet aux développeurs de définir des tâches comme des fonctions TypeScript asynchrones ordinaires et de les exécuter sans cette contrainte, sur une infrastructure cloud gérée ou sur leurs propres serveurs via Docker ou Kubernetes.

La plateforme se présente sous la forme d'un SDK TypeScript qui s'intègre avec Node.js, Bun, Next.js, NestJS et la plupart des autres environnements serveur TypeScript. Ses capacités principales incluent l'exécution durable avec reprise par point de contrôle (les tâches se mettent en pause aux points await et reprennent sans perdre leur état), des tentatives automatiques avec délai d'attente configurable, une mise en file d'attente simultanée avec contrôle des priorités, la planification cron et une API Realtime qui diffuse la progression des tâches en direct vers les applications frontend React. Elle s'intègre avec Vercel AI SDK, OpenAI Agents SDK, LangChain, LangGraph, LlamaIndex, ainsi qu'avec les API de modèles directes d'Anthropic, OpenAI, Google, Cohere et Mistral. Pour les cas d'usage spécifiques à l'IA, Trigger.dev prend également en charge les points d'attente « human-in-the-loop » (humain dans la boucle), où les tâches se mettent en pause dans l'attente d'une approbation ou d'une saisie humaine, puis reprennent exactement là où elles s'étaient arrêtées sans consommer de temps de calcul inactif. La version stable actuelle est la v4, avec plus de 14 800 étoiles GitHub et une licence Apache 2.0.

Ce que fait réellement Trigger.dev en mai 2026

Le mécanisme central de Trigger.dev est l'exécution par point de contrôle-restauration (checkpoint-restore). Lorsqu'une tâche atteint un point await (en attente d'une autre tâche, d'un événement externe, d'un minuteur ou d'un humain), la plateforme sérialise l'état de la tâche à l'aide de CRIU (Checkpoint/Restore In Userspace) et suspend le conteneur. La tâche n'est pas facturée pendant cette pause. Lorsque la condition attendue est résolue, la tâche reprend exactement à partir de l'état sérialisé. C'est fondamentalement différent du serverless traditionnel, où une fonction doit soit se terminer dans le temps imparti, soit échouer.

Les tâches s'exécutent dans des workers basés sur Bun (des conteneurs à longue durée de vie, et non des invocations éphémères de type Lambda). Chaque tâche peut spécifier sa propre configuration machine : nombre de processeurs, RAM et paquets système optionnels comme FFmpeg, Puppeteer ou des environnements Python personnalisés via des extensions de build. Cela signifie qu'une tâche de transcodage vidéo et une tâche d'e-mail légère peuvent partager le même projet tout en s'exécutant sur des machines de taille appropriée.

L'API Realtime, sortie en disponibilité générale (GA) en décembre 2024 et construite sur Electric SQL (un moteur de synchronisation PostgreSQL open source), permet aux hooks React tels que useRealtimeRun et useRealtimeBatch de diffuser l'état des tâches en direct vers les interfaces utilisateur du navigateur. Un pipeline de traitement de documents peut montrer aux utilisateurs la progression en temps réel : « Extraction du texte.. Résumé du chapitre 3 sur 8.. » sans avoir recours au polling (interrogation répétée). Plus de soixante organisations ont adopté l'API Realtime dans les jours suivant sa sortie en GA, y compris Midday.ai et Papermark.io.

La planification est gérée nativement via des expressions cron ou des déclencheurs basés sur des intervalles, et les tâches prennent en charge les modèles de type « fan-out » : une tâche parente peut générer des centaines de sous-tâches simultanément, toutes suivies dans une arborescence d'exécution unique avec une observabilité unifiée. Le tableau de bord propulsé par OpenTelemetry affiche des arborescences de traces complètes, des journaux, l'historique des tentatives et des métriques de performance pour chaque exécution.

« Nous avons décidé d'utiliser Trigger.dev plutôt qu'Inngest ou de mettre en place notre propre solution dédiée.. [pour] l'automatisation des workflows, l'évolutivité, la rapidité de développement, la rentabilité et la pérennité. » - Sohrab Fadai, Product Hunt, 2024

Où se situe Trigger.dev par rapport à Inngest et Temporal

Les trois outils les plus couramment comparés dans le domaine de l'exécution durable axée sur les développeurs sont Trigger.dev, Inngest et Temporal. Chacun adopte une approche architecturale fondamentalement différente.

Inngest est l'outil qui présente le plus de chevauchements fonctionnels avec Trigger.dev, mais l'architecture diffère sur un point critique : Inngest n'exécute pas votre code (compute). Il s'agit d'une couche d'orchestration uniquement par API qui appelle vos points de terminaison serverless via HTTP et délivre des événements. Les développeurs doivent diviser le travail en fonctions step.run() distinctes, chacune étant relancée indépendamment et sauvegardée à la limite de l'étape. Cela signifie que les tâches Inngest restent contraintes par les limites d'exécution serverless par étape (environ 15 minutes par appel de fonction d'étape). Trigger.dev exécute votre code directement sur son infrastructure gérée (ou sur des workers auto-hébergés) dans des conteneurs à longue durée de vie, sans aucune exigence de division par étapes. Une fonction asynchrone continue peut s'exécuter pendant des heures. Le forfait payant Hobby de Trigger.dev commence à $10/mois ; le forfait payant d'Inngest commence à $75/mois. Trigger.dev est sous licence Apache 2.0 et peut être entièrement auto-hébergé sans restriction de fonctionnalités. Les conditions d'auto-hébergement d'Inngest sont plus limitées. En termes de volume de téléchargements hebdomadaires sur npm, Inngest attire environ 85 000 téléchargements par semaine contre 45 000 pour Trigger.dev, ce qui reflète la présence plus ancienne d'Inngest sur le marché, bien que Trigger connaisse une croissance plus rapide selon la trajectoire de ses étoiles GitHub.

Temporal se situe dans une catégorie totalement différente : une exécution durable de niveau entreprise pour des workflows polyglottes extrêmement complexes et à longue durée de vie. Temporal utilise une relecture déterministe basée sur l'event sourcing. Chaque action du workflow est enregistrée dans un journal d'historique en ajout seul (append-only) ; lors de la récupération, le workflow est rejoué depuis le début, réexécutant toutes les activités jusqu'au point actuel. Cela nécessite un code de workflow déterministe : pas de Date.now(), pas de nombres aléatoires, pas d'E/S directes à l'intérieur des fonctions de workflow. La courbe d'apprentissage est considérablement plus raide, obligeant les développeurs à comprendre les Workflows, les Activities, les Workers, les Task Queues, les Namespaces et les Signals avant de déployer leur première tâche. Temporal est polyglotte (Go, Java, Python, TypeScript, PHP, .NET) ; Trigger.dev est avant tout conçu pour TypeScript, avec une prise en charge de Python uniquement comme solution de contournement via des extensions. Pour les entreprises ayant besoin d'historiques de workflows sur plusieurs années, de pistes d'audit complètes ou de flottes de workers Java/Go, Temporal est le bon choix. Pour une équipe développant une application IA en TypeScript qui a besoin de tâches en arrière-plan fiables avec une surcharge d'infrastructure minimale, Trigger.dev est plus rapide et moins cher à exploiter. Comme l'a résumé un développeur sur la page de comparaison Trigger.dev vs Temporal : « Passer à Trigger pour les tâches en arrière-plan s'est avéré plus fiable, moins cher et plus facile. »

Les développeurs qui créent des pipelines ML principalement en Python devraient également évaluer Modal, qui offre un calcul serverless accéléré par GPU et d'excellents outils Python. Pour les équipes utilisant déjà n8n ou Activepieces pour l'automatisation visuelle des workflows, Trigger.dev n'est pas un outil de remplacement visuel, mais un complément au niveau du code pour les tâches nécessitant une durabilité et une exécution de longue durée.

À quoi ressemble la réalité de la boucle d'agent au quotidien

L'expérience de développement commence par l'installation du paquet @trigger.dev/sdk et l'ajout d'un fichier trigger.config.ts pour spécifier les paramètres du projet. Les tâches sont des fonctions exportées décorées avec task(). La CLI de Trigger.dev exécute un serveur de développement local qui se connecte au tableau de bord Trigger.dev Cloud (ou auto-hébergé), où les exécutions apparaissent en temps réel pendant le développement. Il n'y a pas d'infrastructure de file d'attente séparée à configurer ou à gérer localement.

Pour les workflows d'agents IA, le modèle consiste à définir une tâche racine qui orchestre des sous-tâches. Chaque sous-tâche peut appeler des API LLM, écrire dans des bases de données, envoyer des requêtes HTTP et appeler wait.forEvent() pour se mettre en pause jusqu'à l'arrivée d'un signal externe. Les workflows « human-in-the-loop » ajoutent un appel waitpoint qui sérialise l'état de l'agent et envoie une notification, puis reprend lorsqu'un humain soumet son approbation via le tableau de bord Trigger.dev ou un appel d'API personnalisé.

Le déploiement en production se fait via une seule commande CLI : npx trigger deploy. La CLI construit une image Docker, la pousse vers Trigger.dev Cloud (ou un registre auto-hébergé) et crée un déploiement versionné immuable. Les tâches déjà en cours d'exécution continuent sur leur version déployée ; les nouvelles tâches adoptent la dernière version. Ce versionnage atomique empêche les exécutions en cours d'être interrompues par de nouveaux déploiements de code, ce qui est un mode de défaillance courant avec les systèmes basés sur des files d'attente.

« La possibilité d'utiliser TypeScript pour définir des workflows est brillante. » - Charlie, Product Hunt, 2024

L'observabilité est intégrée via OpenTelemetry. Chaque exécution produit une arborescence de traces visible dans le tableau de bord : chaque étape, sa durée, ses entrées et sorties, ainsi que tout appel de sous-tâche imbriqué. Des alertes d'erreur configurables peuvent être acheminées vers Slack ou PagerDuty. La rétention des journaux va de 1 jour sur le forfait Free à 30 jours sur le forfait Pro, avec une rétention personnalisée sur le forfait Enterprise.

À qui s'adresse Trigger.dev

Trigger.dev est spécialement conçu pour les développeurs TypeScript qui créent des applications basées sur l'IA : des applications Next.js avec des fonctionnalités IA, des backends NestJS traitant des documents, ou tout code côté serveur qui appelle des API LLM et nécessite une logique de relance et de l'observabilité. L'outil est particulièrement précieux lorsque les pipelines IA se heurtent constamment aux limites de délai d'attente du serverless ou lorsque les développeurs se retrouvent à écrire manuellement une logique de relance fragile.

Les startups en phase de démarrage trouveront le forfait Hobby à $10/mois suffisant pour la plupart des charges de travail en production, le calcul étant facturé séparément en fonction de l'utilisation réelle. Les équipes qui traitent de grands volumes de tâches d'inférence IA trouveront que les plus de 200 exécutions simultanées et le support Slack dédié du forfait Pro justifient largement les $50/mois. Les déploiements auto-hébergés sur Docker sont documentés et matures depuis la v4 ; l'auto-hébergement sur Kubernetes est disponible et décrit dans une série d'articles de blog officiels.

Trigger.dev s'intègre naturellement dans les stacks qui utilisent déjà Zapier ou Make pour l'automatisation no-code, en intervenant sur une couche différente. Là où ces plateformes gèrent le routage d'événements inter-applications sans écrire de code, Trigger.dev gère ce qui se passe à l'intérieur de la couche de code lorsque les tâches doivent s'exécuter plus longtemps que ne le permet une fonction Lambda.

Les équipes ayant des engagements open source importants apprécient la licence Apache 2.0. L'ensemble de la plateforme peut être auto-hébergé sans limitation de fonctionnalités, sans limite d'exécution et sans enfermement propriétaire (vendor lock-in) au-delà du SDK TypeScript lui-même. La base de code compte plus de 14 800 étoiles GitHub, des mainteneurs actifs et plus de 617 versions publiées en date de mai 2026, ce qui indique une véritable pérennité.

Ce que Trigger.dev n'est pas

Ce n'est pas un outil Python. Le SDK est exclusivement en TypeScript. Les scripts Python peuvent être appelés en tant que sous-processus à l'intérieur des tâches via des extensions de build, mais il n'y a pas de SDK Python natif, pas de définition de tâche en Python, et pas de prise en charge de premier ordre pour la gestion des paquets Python à l'intérieur des tâches. Les équipes ML travaillant principalement en Python et exécutant des pipelines d'inférence devraient plutôt utiliser Modal, Prefect ou Temporal avec des workers Python.

Ce n'est pas une plateforme no-code ou low-code. Il n'y a pas de constructeur visuel de workflows, de nœuds en glisser-déposer ou d'interface graphique pour définir les tâches. Tout est sous forme de code. Les utilisateurs métiers ou les équipes non techniques ne peuvent pas utiliser Trigger.dev sans l'implication de développeurs. Pour l'automatisation visuelle des workflows, consultez n8n ou Activepieces.

Ce n'est pas une stack d'observabilité complète. Bien que le traçage OpenTelemetry intégré soit utile, les équipes disposant déjà d'une infrastructure d'observabilité (Datadog, Grafana, Honeycomb) devront intégrer les traces de Trigger.dev dans leurs outils existants. Le tableau de bord intégré est fonctionnel mais ne remplace pas les plateformes d'observabilité spécialisées.

Ce n'est pas encore une solution durcie pour l'entreprise à l'échelle de Temporal. L'incident de production de septembre 2025, au cours duquel les messages d'erreur surdimensionnés d'un seul client ont provoqué trois pannes cloud simultanées en cascade, a révélé que l'infrastructure était encore en cours de stabilisation face à une croissance rapide. L'équipe a publié un rapport d'incident public détaillé et a déployé des correctifs dans les 48 heures, ce qui est un signal positif. Cependant, les équipes pour lesquelles les défaillances de workflows sont critiques pour l'entreprise voudront peut-être attendre la migration vers MicroVM (prévue pour réduire la dépendance à Kubernetes) avant de s'engager à l'échelle de l'entreprise.

Ignorez Trigger.dev si votre équipe utilise déjà Inngest avec succès pour des workflows basés sur des étapes et sans problèmes de délai d'attente. Le coût de migration est réel et l'écart de fonctionnalités pourrait ne pas le justifier. Ignorez-le également si vous avez besoin de pistes d'audit de workflows sur plusieurs années et éprouvées au combat : c'est le domaine de Temporal, pas celui de Trigger.