Un workflow N8N qui boucle sur 100 items avec 5 secondes de traitement par item prend plus de 8 minutes. Avec l’exécution asynchrone, ce même workflow s’exécute en 5 secondes. La clé : lancer les sous-workflows en parallèle plutôt qu’en séquence. Cette technique transforme radicalement les performances de vos automatisations.
Le problème des boucles synchrones
Dans un workflow classique, chaque itération de boucle attend la fin de la précédente avant de démarrer. Si vous traitez 5 messages avec 5 secondes d’attente chacun, le temps total est de 25 secondes (5 × 5).
Exemple concret : envoi de messages Discord
Prenons un workflow simple :
- Un tableau de 5 messages en entrée
- Un nœud Split pour transformer le tableau en 5 items individuels
- Une boucle qui, pour chaque item, attend 5 secondes puis envoie un message Discord
Résultat : message 1 envoyé après 5 secondes, message 2 après 10 secondes, message 3 après 15 secondes… Le workflow complet prend 25 secondes.
Impact sur les gros volumes
| Nombre d’items | Temps par item | Temps total (synchrone) |
| 5 | 5 secondes | 25 secondes |
| 10 | 5 secondes | 50 secondes |
| 50 | 5 secondes | 4 minutes 10 secondes |
| 100 | 5 secondes | 8 minutes 20 secondes |
Le temps d’exécution croît linéairement avec le nombre d’items. Pour des workflows de production traitant des centaines d’éléments, c’est un problème majeur.
La solution : l’exécution parallèle avec sous-workflows
L’idée : extraire la logique de traitement dans un sous-workflow, puis l’appeler de façon asynchrone. Chaque appel démarre immédiatement sans attendre la fin du précédent.
Architecture de la solution
Deux workflows sont nécessaires :
- Workflow principal : reçoit les données, les splitte et appelle le sous-workflow pour chaque item
- Sous-workflow : contient la logique de traitement (attente + envoi Discord dans notre exemple)
Créer le sous-workflow
Le sous-workflow doit pouvoir être appelé par un autre workflow. Pour cela, utilisez le trigger spécial « When Executed by Another Workflow ».
Étape 1 : Ajouter le trigger
Créez un nouveau workflow et ajoutez le nœud « When Executed by Another Workflow » (recherchez « execute » ou « trigger » dans les nœuds). Ce trigger attend qu’un autre workflow l’appelle pour démarrer.
Étape 2 : Définir les paramètres d’entrée
Dans les paramètres du trigger, deux options :
- Accept all data : le sous-workflow reçoit toutes les données envoyées par le workflow parent
- Define fields : spécifiez les champs attendus (ex: « message » de type String)
La seconde option est recommandée pour la clarté et la validation des données.
Étape 3 : Ajouter la logique de traitement
Ajoutez les nœuds qui effectuent le traitement. Dans notre exemple : un nœud Wait (5 secondes) suivi d’un nœud Discord pour envoyer le message reçu en paramètre.
Configurer l’appel asynchrone
Dans le workflow principal, remplacez la logique de traitement par un appel au sous-workflow avec l’option asynchrone activée.
Étape 1 : Ajouter le nœud Execute Workflow
Recherchez « Execute Workflow » ou « Execute a sub-workflow » dans les nœuds. Sélectionnez le sous-workflow créé précédemment.
Étape 2 : Désactiver l’attente
L’option clé se trouve dans les paramètres du nœud : « Wait for Sub-Workflow Completion ». Par défaut, cette option est activée (le workflow attend la fin du sous-workflow avant de continuer).
Désactivez cette option. Le workflow principal lance le sous-workflow et passe immédiatement à l’itération suivante, sans attendre.
Étape 3 : Mapper les données
Si vous avez défini des champs spécifiques dans le sous-workflow (ex: « message »), mappez-les avec les données de l’item courant. Glissez-déposez le champ depuis le panneau de données vers le paramètre correspondant.
Comparaison des performances
| Mode | 5 items × 5s | 100 items × 5s | Gain |
| Synchrone | 25 secondes | 8 min 20 s | – |
| Asynchrone | ~5 secondes | ~5 secondes | 80% à 99% |
En mode asynchrone, le temps d’exécution ne dépend plus du nombre d’items, mais uniquement du temps de traitement d’un seul item. Les 5 sous-workflows s’exécutent en parallèle, chacun attendant ses 5 secondes simultanément.
Point d’attention : l’ordre d’exécution
Avec l’exécution parallèle, les sous-workflows se terminent dans un ordre imprévisible. Si vous lancez 5 messages numérotés 1 à 5, ils peuvent arriver dans l’ordre 1, 2, 3, 5, 4.
Conséquence : utilisez l’exécution asynchrone uniquement quand l’ordre des résultats n’a pas d’importance, ou quand chaque traitement est indépendant des autres.
Cas où l’asynchrone est adapté
- Envoi de notifications à plusieurs destinataires
- Traitement de fichiers indépendants
- Appels API vers des services externes
- Génération de rapports individuels
- Synchronisation de données vers plusieurs destinations
Cas où le synchrone reste nécessaire
- Traitements séquentiels dépendants (le résultat de l’item N est utilisé par l’item N+1)
- Ordre de traitement critique (transactions financières, logs chronologiques)
- Limitation de débit imposée par une API (rate limiting)
Débogage des sous-workflows asynchrones
Quand un sous-workflow échoue, l’erreur n’apparaît pas dans le workflow principal (qui a déjà terminé son exécution). Pour déboguer :
- Ouvrez le sous-workflow
- Consultez l’onglet « Executions » pour voir les exécutions récentes
- Identifiez les exécutions en erreur et analysez les données reçues
Dans notre exemple, une erreur « message is null » indiquait que le champ attendu n’était pas correctement mappé. La solution : vérifier le mapping entre le workflow principal et les paramètres définis dans le sous-workflow.
Bonnes pratiques
- Nommez clairement vos sous-workflows : « SubWorkflow – Envoi Discord », « SubWorkflow – Traitement Image »
- Définissez des champs typés : évitez « Accept all data » pour une meilleure validation
- Ajoutez un Error Trigger au sous-workflow pour être notifié des erreurs en production
- Testez d’abord en synchrone : vérifiez que la logique fonctionne avant de passer en asynchrone
- Surveillez la charge serveur : 100 sous-workflows lancés simultanément consomment plus de ressources
Cas d’usage pratiques
- Newsletter massive : envoyer 1000 emails personnalisés en parallèle plutôt qu’un par un
- Scraping multi-sites : récupérer les données de 50 pages web simultanément
- Traitement d’images : redimensionner 100 images en parallèle pour un temps constant
- Synchronisation CRM : mettre à jour des fiches contacts dans plusieurs systèmes en même temps
- Génération de documents : créer des PDF personnalisés pour chaque client d’une liste
Comment réduire le temps d'exécution d'une boucle N8N qui traite 5 items avec 5 secondes de traitement chacun ?
Conclusion
L’exécution asynchrone de sous-workflows est une technique puissante pour optimiser les performances de vos automatisations N8N. En désactivant l’option « Wait for Sub-Workflow Completion », vous passez d’un temps d’exécution linéaire (proportionnel au nombre d’items) à un temps quasi-constant. La clé : identifier les traitements indépendants où l’ordre d’exécution n’a pas d’importance.
Pour approfondir l’optimisation de vos workflows, explorez nos autres ressources N8N ou contactez notre équipe pour un accompagnement sur vos projets d’automatisation à grande échelle.
Créez un sous-workflow avec le trigger ‘When Executed by Another Workflow’. Dans votre workflow principal, utilisez le nœud ‘Execute Workflow’ pour appeler ce sous-workflow et désactivez l’option ‘Wait for Sub-Workflow Completion’. Les appels seront lancés en parallèle sans attendre la fin de chacun.
En mode synchrone, chaque itération attend la fin de la précédente avant de démarrer (5 items × 5 secondes = 25 secondes). En mode asynchrone, toutes les itérations démarrent simultanément et s’exécutent en parallèle (5 items × 5 secondes = ~5 secondes car ils s’exécutent en même temps).
Non. En mode asynchrone, les sous-workflows se terminent dans un ordre imprévisible. Si vous lancez les messages 1, 2, 3, 4, 5, ils peuvent arriver dans l’ordre 1, 2, 3, 5, 4. Utilisez l’asynchrone uniquement quand l’ordre n’a pas d’importance ou quand chaque traitement est indépendant.
L’erreur n’apparaît pas dans le workflow principal car il a déjà terminé son exécution. Ouvrez directement le sous-workflow, consultez l’onglet ‘Executions’ pour voir les exécutions récentes, identifiez celles en erreur et analysez les données reçues pour comprendre le problème.
Évitez l’asynchrone quand les traitements sont séquentiellement dépendants (le résultat de l’item N est utilisé par l’item N+1), quand l’ordre est critique (transactions financières, logs chronologiques), ou quand une API impose une limitation de débit (rate limiting) qui serait dépassée par les appels simultanés.
Dans le trigger ‘When Executed by Another Workflow’ du sous-workflow, définissez les champs attendus (ex: ‘message’ de type String). Dans le workflow principal, le nœud ‘Execute Workflow’ affiche ces champs. Mappez-les avec les données de l’item courant en glissant-déposant depuis le panneau de données.
