Mauvaises heures dans n8n : bien configurer UTC, GENERIC_TIMEZONE et Cron

Les heures incorrectes dans le node Schedule Trigger sont presque toujours dues au fuseau horaire de n8n, et non à l'expression cron elle-même. Sans aucune configuration, selon la documentation officielle, n8n utilise par défaut le fuseau horaire America/New_York, et non Europe/Berlin, ce qui fait que les workflows planifiés démarrent avec plusieurs heures de décalage par rapport à l'heure attendue. Il existe deux réglages qui agissent indépendamment l'un de l'autre : la variable d'environnement GENERIC_TIMEZONE, valable pour toute l'instance, dans les installations auto-hébergées, et un réglage de fuseau horaire propre à chaque workflow, qui remplace la valeur de l'instance. À jour en juillet 2026.

Pourquoi mon workflow n8n démarre-t-il à la mauvaise heure ?

La raison la plus fréquente est que ni l'instance ni le workflow individuel n'ont de fuseau horaire défini, si bien que n8n revient à la valeur par défaut America/New_York. Vous saisissez par exemple 09:00 dans le node Schedule Trigger en pensant Europe/Berlin, alors que n8n interprète cette saisie comme 09:00 heure de New York. Selon l'heure d'été ou d'hiver, cela entraîne un décalage de cinq à six heures par rapport à l'heure allemande souhaitée. Selon les indications de dépannage du node Schedule Trigger, c'est exactement la cause typique lorsque des workflows s'exécutent "at wrong times", et la documentation renvoie directement à la configuration du fuseau horaire comme première étape de résolution (Documentation n8n : Schedule Trigger, Common Issues).

Comment définir le fuseau horaire pour toute l'instance n8n ?

Dans les installations auto-hébergées, vous définissez la variable d'environnement GENERIC_TIMEZONE avec la valeur souhaitée, par exemple Europe/Berlin, ce qui définit le fuseau horaire par défaut pour l'ensemble de l'instance. Selon la documentation n8n, cette variable est "important for schedule nodes (such as Cron)" et prend par défaut la valeur America/New_York si elle n'est pas précisée (Documentation n8n : Set the timezone for self-hosted n8n).

• GENERIC_TIMEZONE : Variable d'environnement qui définit le fuseau horaire par défaut de l'ensemble de l'instance n8n auto-hébergée, par exemple via export GENERIC_TIMEZONE=Europe/Berlin.
• Valeurs valides : Identifiants de fuseaux horaires IANA comme Europe/Berlin, et non de simples abréviations comme CET.
• n8n Cloud : Ici, il n'existe pas de variable d'environnement, mais une sélection de fuseau horaire sous Dashboard, Manage et le menu déroulant Timezone, qui concerne également le node Schedule Trigger et le node Date & Time (Documentation n8n : Set your timezone in n8n Cloud).

Comment définir le fuseau horaire pour un seul workflow ?

Chaque workflow peut recevoir son propre fuseau horaire, qui a priorité sur le réglage de l'instance pour ce workflow. Pour cela, ouvrez le workflow, cliquez en haut à droite sur le menu à trois points, sélectionnez Settings et réglez la zone souhaitée dans le champ Timezone avant d'enregistrer. Selon la documentation, ce réglage est "important for the Schedule Trigger node" et convient aux cas où certaines automatisations doivent délibérément s'exécuter dans un autre fuseau horaire, par exemple pour des clients ou des sites situés en dehors de l'Allemagne (Documentation n8n : Configure workflow settings).

L'ordre de priorité est le suivant : n8n utilise d'abord le fuseau horaire du workflow s'il est défini, sinon le fuseau horaire de l'instance issu de GENERIC_TIMEZONE, et seulement si les deux manquent, la valeur par défaut America/New_York. Quiconque exploite plusieurs workflows avec des clients allemands s'évite ainsi un travail manuel répété en définissant une fois GENERIC_TIMEZONE sur Europe/Berlin pour toute l'instance, plutôt que de modifier chaque workflow individuellement.

Comment savoir si une erreur de planification est vraiment due au fuseau horaire ?

Un indice clair est qu'un workflow se déclenche systématiquement avec un nombre d'heures fixe de décalage par rapport à l'heure attendue, ou que le comportement change après le passage à l'heure d'été, car les deux indiquent un réglage de fuseau horaire incorrect ou manquant plutôt qu'une expression cron erronée. Vérifiez d'abord l'expression cron elle-même avec crontab.guru et assurez-vous qu'elle respecte la syntaxe à six colonnes, secondes incluses, attendue par n8n. Il est également important de noter que, selon la documentation, les modifications des variables de planification ou de l'intervalle ne prennent effet qu'après la republication du workflow, le planning recomptant alors à partir du moment de la republication, ce qui peut également donner l'impression que les premières exécutions sont incorrectes.

Si vous exploitez déjà plusieurs workflows n8n pour des clients ou au sein de votre propre entreprise et souhaitez faire configurer proprement les fuseaux horaires, la logique cron ou des chaînes d'automatisation complètes, NordFlux prend en charge la mise en place technique dans le cadre de l'automatisation n8n à prix fixe, y compris la transmission de la configuration.

Questions fréquentes sur les fuseaux horaires n8n

Quelle est la différence entre GENERIC_TIMEZONE et le fuseau horaire du workflow ?

GENERIC_TIMEZONE est une variable d'environnement qui définit le fuseau horaire par défaut de l'ensemble de l'instance n8n auto-hébergée. Le fuseau horaire du workflow, en revanche, est défini dans les paramètres d'un workflow individuel et remplace la valeur de l'instance pour ce workflow précis. Si aucun des deux n'est défini, n8n revient à America/New_York selon la documentation.

Quel fuseau horaire n8n utilise-t-il si je ne configure rien du tout ?

Sans aucune configuration, n8n utilise par défaut America/New_York, que la documentation désigne également comme le fuseau horaire EDT. Cela concerne surtout le node Schedule Trigger et le node Date & Time et entraîne généralement, pour les utilisateurs allemands, un décalage de cinq à six heures par rapport à Europe/Berlin.

Dois-je réactiver le workflow après un changement de fuseau horaire ?

Oui, selon la documentation n8n, les modifications des variables de planification et des intervalles ne prennent effet qu'après la republication du workflow. Le planning recompte à partir de ce moment de republication, si bien que la première exécution après une modification peut se produire à un horaire différent de celui attendu. Vérifiez donc, après chaque ajustement de fuseau horaire, que le workflow a bien été enregistré activement.

GENERIC_TIMEZONE s'applique-t-il également à n8n Cloud ?

Non, GENERIC_TIMEZONE est une variable d'environnement destinée aux installations n8n auto-hébergées. Pour n8n Cloud, vous réglez plutôt le fuseau horaire de l'instance via le Dashboard, sous Manage et le menu déroulant Timezone. L'effet sur le node Schedule Trigger et le node Date & Time est le même dans les deux cas.