Gérer la concurrence (limites Cloud : Starter 5 / Pro 20 en parallèle)

Dans n8n Cloud, chaque forfait limite le nombre d'exécutions de workflow pouvant s'exécuter simultanément : le plan Starter autorise 5 exécutions parallèles, le plan Pro 20, et le niveau Enterprise se situe, selon l'aperçu des tarifs n8n, à 200 exécutions parallèles ou plus. Si la limite est dépassée, n8n place automatiquement les exécutions supplémentaires dans une file d'attente et les traite selon le principe FIFO dès qu'une capacité se libère à nouveau. Pour les entreprises qui traitent régulièrement de grands volumes de données, par exemple des imports en masse, des envois d'e-mails en masse ou le traitement de longues listes via des déclencheurs webhook, cette limite est un facteur à connaître avant de construire un workflow, sinon les exécutions s'accumulent sans être remarquées dans la file d'attente. État : juillet 2026.

Comment fonctionne la limite de concurrence dans n8n Cloud

La limitation s'applique, selon la documentation n8n sur la concurrence Cloud, exclusivement aux exécutions de production, c'est-à-dire celles déclenchées par un webhook ou un nœud déclencheur. Les exécutions de test manuelles, les sous-workflows et les workflows d'erreur ne sont pas comptabilisés et continuent de s'exécuter indépendamment de la limite. Si le nombre d'exécutions de production simultanées dépasse la valeur du plan, les exécutions supplémentaires ne sont pas rejetées mais attendent dans une file d'attente. Important en pratique : les exécutions en attente ne peuvent pas être relancées (pas de nouvelle tentative), et quiconque annule une exécution en attente la supprime complètement de la file d'attente. Après un redémarrage de l'instance, n8n reprend les exécutions en attente jusqu'à la limite de capacité et remet le reste en file d'attente. Le niveau d'utilisation actuel est visible directement dans l'onglet des exécutions d'un projet ou d'un workflow.

Impact sur le traitement en masse

Par exemple, quiconque déclenche 500 enregistrements individuellement comme des exécutions séparées via un webhook obtient automatiquement une file d'attente dans le plan Starter après les 5 premières exécutions simultanées, même si n8n lui-même n'affiche aucun message d'erreur. Cela retarde le traitement global, mais n'entraîne pas de perte de données, tant que personne n'annule les exécutions en attente. Cela devient plus critique pour les processus sensibles au temps, par exemple lorsqu'un système externe attend une réponse rapide et que la file d'attente rallonge de façon imprévisible le temps de réponse. Lors des redémarrages d'instance également (par exemple en raison de fenêtres de maintenance), la file d'attente peut s'accumuler brièvement avant d'être traitée.

Solutions de contournement via le batching

Plutôt que de déclencher de nombreuses exécutions de production individuelles en parallèle, la charge peut être gérée au sein d'un même workflow. Approches courantes en pratique :

• Utiliser Split in Batches : les enregistrements sont traités par groupes au sein d'une seule exécution de workflow, au lieu de démarrer une exécution de production distincte pour chaque enregistrement. Cela réduit nettement le nombre d'exécutions simultanées.
• Prévoir des temps d'attente : un nœud Wait entre les lots soulage les systèmes en aval (par exemple des API avec leurs propres limites de débit) en complément de la file d'attente interne de n8n.
• Utiliser des sous-workflows : comme les exécutions de sous-workflows, selon la documentation, ne comptent pas dans la limite de concurrence, la logique de traitement peut en partie être structurée de façon à générer moins d'exécutions de production de premier niveau simultanées.
• Réguler la fréquence des déclencheurs : pour les imports en masse, il est utile de cadencer le processus déclencheur (par exemple une tâche cron ou un import en amont) de sorte qu'il maintienne dès le départ le nombre d'appels webhook simultanés sous la limite du plan.

En toute honnêteté, aucune de ces astuces ne remplace un plan supérieur si un véritable parallélisme accru est nécessaire de façon permanente. Le batching déplace la charge dans le temps, mais ne crée pas de capacité supplémentaire.

Auto-hébergé : contrôle total sur la limite

Quiconque exploite n8n lui-même dispose de plus de marge de manœuvre : selon la documentation n8n sur le contrôle de la concurrence, la limitation est désactivée par défaut en auto-hébergement et peut être définie spécifiquement via la variable d'environnement N8N_CONCURRENCY_PRODUCTION_LIMIT, y compris en mode file d'attente. Cela signifie plus de contrôle sur sa propre infrastructure, mais aussi plus de responsabilité personnelle : sans limite définie consciemment, une instance peut être surchargée lors d'un pic de charge soudain. C'est exactement là qu'intervient une conception rigoureuse, par exemple pour déterminer si un plan Cloud ou une infrastructure propre correspond au volume de données réel et aux exigences de contrôle d'une entreprise. NordFlux accompagne précisément cette évaluation dans le cadre de son conseil n8n.

Questions fréquentes sur le contrôle de la concurrence dans n8n

Que se passe-t-il pour les exécutions qui dépassent la limite ?

Elles ne sont pas rejetées, mais placées automatiquement dans une file d'attente et traitées dans l'ordre d'arrivée (FIFO) dès qu'une capacité se libère à nouveau.

La limite s'applique-t-elle aussi aux exécutions de test manuelles ?

Non. Selon la documentation, la limite de concurrence dans n8n Cloud ne concerne que les exécutions de production via webhook ou nœud déclencheur. Les exécutions manuelles, les sous-workflows et les workflows d'erreur en sont exclus.

Puis-je simplement relancer une exécution en attente ?

Non, les exécutions en attente ne peuvent pas être relancées. Quiconque les annule les supprime complètement de la file d'attente ; elles doivent alors être redéclenchées.

Vaut-il la peine de passer au plan Pro à cause de la limite de concurrence ?

Cela dépend du volume de traitement réel. Quiconque a régulièrement besoin de nettement plus de 5 exécutions de production simultanées ressentira plus souvent des retards liés à la file d'attente dans le plan Starter. Le batching peut atténuer cela, mais pour un volume durablement élevé, il ne remplace pas un plan supérieur.