Inngest : workflows durables, jobs en arrière-plan et crons pour TypeScript en 2026

Pendant des années, faire tourner des tâches asynchrones fiables en Node.js exigeait d'orchestrer Redis, BullMQ, des workers dédiés et toute une infrastructure de retries et de monitoring. En 2026, Inngest renverse l'équation : vous écrivez vos fonctions comme du code TypeScript ordinaire et le moteur s'occupe de la durabilité, des retries, des étapes idempotentes et de la visibilité, sans serveur de queue à maintenir.

Le problème : les jobs asynchrones sont devenus la dette cachée des SaaS

Tout SaaS sérieux finit par accumuler des traitements en arrière-plan : envois d'e-mails transactionnels, génération de PDF, ingestion de webhooks Stripe, embeddings IA, synchronisations CRM, rapports planifiés. Sur Node.js, la pile classique consiste à monter un Redis, brancher BullMQ, déployer des workers séparés et instrumenter manuellement les retries exponentiels. Le résultat est une infrastructure parallèle au backend, difficile à débugger en production et qui multiplie les sources de panne. Sur les architectures serverless (Vercel, Cloudflare Workers, Lambda) le problème s'aggrave : pas de processus long, pas de mémoire partagée, et chaque tâche doit être orchestrée par un service tiers.

L'approche Inngest : des fonctions durables déclenchées par événements

Inngest propose un modèle simple : vous publiez des événements typés depuis votre code applicatif (`inngest.send({ name: 'user/signup', data })`), et vous écrivez des fonctions qui réagissent à ces événements ou s'exécutent sur un cron. Chaque fonction est découpée en `step.run()`, `step.sleep()`, `step.waitForEvent()` et `step.invoke()` — chaque étape est mémorisée par le moteur, idempotente et reprise sans rejouer le travail déjà fait. Si votre serveur crashe au milieu d'un workflow de cinq étapes, Inngest reprend exactement à l'étape suivante après le redéploiement. Tout cela tient dans un handler HTTP que vous montez sur n'importe quel framework : Next.js, Express, Fastify, Hono, Remix, Nuxt, SvelteKit, ou directement sur des Cloudflare Workers.

Concrètement : workflows multi-étapes, fan-out et delays sans infrastructure

Là où Inngest brille, c'est sur les workflows métier qui s'étalent dans le temps. Un onboarding peut se déclarer en quelques lignes : envoyer l'e-mail de bienvenue, attendre 3 jours, vérifier si l'utilisateur a complété son profil, et selon la réponse envoyer une relance ou déclencher un nurturing différent. Avec `step.waitForEvent('user/profile.completed', { timeout: '7d' })`, le moteur met le workflow en pause sans consommer de ressources et le réveille à l'arrivée de l'événement. Le fan-out est tout aussi naturel : un événement `order/created` peut déclencher en parallèle l'envoi du reçu, la mise à jour de l'inventaire et la synchronisation comptable, chaque fonction avec ses propres règles de retry et de concurrence (`concurrency: { limit: 5, key: 'event.data.userId' }` pour throttler par utilisateur).

DX et observabilité : un dev server local et une Cloud avec replay

Le `inngest dev` lance un serveur local qui découvre automatiquement vos fonctions via l'endpoint HTTP de votre app, vous laisse déclencher des événements à la main et inspecter chaque étape avec ses inputs, outputs et logs. En production, la Cloud Inngest (ou la version self-hosted publiée en 2025) offre un dashboard avec timeline complète des runs, replay d'une fonction sur un événement passé, throttling, debouncing, priorité dynamique par tenant et alerting Slack/PagerDuty natif. Pour les équipes qui faisaient tourner BullMQ + Bull Board + Sentry + un cron Kubernetes, c'est un seul outil qui remplace la stack et un seul fichier de fonctions à maintenir. La tarification reste raisonnable pour les petites équipes (free tier généreux) et l'option self-hosted ouvre la porte aux contraintes RGPD strictes.