n8n Cloud limite les exécutions parallèles : Starter 5, Pro 20, Enterprise 200+. Impact sur le traitement en masse et comment le batching aide.
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.
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.
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.
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 :
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.
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.
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.
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.
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.
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.
Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.
Certifications
Le Self-hosted AI Starter Kit de n8n démarre n8n, Ollama, Qdrant et PostgreSQL via Docker Compose pour des workflows d'IA locaux sans API cloud.
L'édition Community est gratuite et illimitée, Business coûte 667 EUR par mois. Ce qui différencie vraiment les plans et quand une PME a besoin d'Enterprise.
n8n facture par exécution de workflow, Zapier par étape d'action. Cette différence détermine quel plan convient réellement à votre automatisation.
Quand la file d'attente s'allonge dans n8n Cloud, le batching n'aide que jusqu'à un certain point. En auto-hébergement, vous fixez vous-même concurrency, queue mode et workers, et NordFlux se charge de la mise en place et de l'exploitation au quotidien. Votre instance absorbe ainsi même les traitements de masse sans engorgement.
