Automatisations et changement d’heure : garder vos rappels à la bonne heure

Une relance commerciale prévue à 9 heures doit arriver à 9 heures pour la personne qui la reçoit. Pourtant, un scénario peut fonctionner pendant des mois, puis se décaler au changement d’heure. Le problème se cache souvent dans une consigne trop vague : « demain », « chaque matin » ou « après une journée ».

En France métropolitaine, le prochain passage à l’heure d’hiver aura lieu le dimanche 25 octobre 2026 : à 3 heures, les horloges reviendront à 2 heures. C’est un bon moment pour examiner vos rappels, rendez-vous et traitements programmés. Source : Service Public.

L’objectif est simple : préciser ce que chaque horaire signifie, puis vérifier le résultat dans les applications utilisées par votre équipe. Les situations ci-dessous sont des exemples de conception, pas des retours clients.

Trois demandes qui nécessitent des réglages différents

« Envoyer le récapitulatif à 9 heures chaque matin »

Cette demande exprime une heure locale récurrente. Pour une équipe travaillant à Paris, documentez « 9 heures, fuseau Europe/Paris ». Évitez de remplacer cette règle par une heure UTC fixe valable toute l’année.

Un décalage comme « UTC+2 » décrit un écart à un instant donné. Le fuseau nommé permet, lui, d’appliquer les règles locales aux différentes dates. L’IANA maintient la base de référence utilisée par de nombreux logiciels et la met à jour lorsque ces règles changent. Les mises à jour arrivent généralement via les éditeurs de logiciels et de systèmes. Source : IANA.

Dans n8n, le nœud Schedule Trigger utilise le fuseau du workflow lorsqu’il est défini ; sinon, il utilise celui de l’instance. Contrôlez donc les deux niveaux. Une exécution manuelle réussie ne prouve pas que le prochain déclenchement aura lieu à l’heure voulue. La documentation demande également d’enregistrer et de publier le workflow pour son fonctionnement programmé. Source : n8n, Schedule Trigger.

Demandez une preuve lisible : la prochaine date prévue, son heure locale et le fuseau appliqué. Faites cette vérification avec la configuration réellement destinée à la production.

« Relancer après 24 heures »

Ici, il faut choisir entre une durée écoulée et une échéance du calendrier. « Attendre exactement 24 heures » et « relancer demain à la même heure locale » peuvent produire des résultats différents autour d’un changement d’heure. La documentation de Temporal distingue précisément le temps exact de l’heure affichée sur une horloge locale. Source : TC39, temps et fuseaux horaires.

Pour une relance commerciale, la bonne question est métier : doit-elle partir après une durée précise, le prochain matin ouvré ou pendant les horaires de l’équipe ? Écrivez la réponse avant de choisir un nœud d’attente.

Ajoutez les exceptions utiles : que faire si l’échéance tombe un dimanche, pendant une fermeture ou après une réponse du client ? Une règle « jours ouvrés » doit s’appuyer sur un calendrier défini pour votre organisation. Le fuseau horaire ne connaît pas vos jours de fermeture.

Conservez aussi l’événement de départ : réception de la demande, envoi du devis ou validation interne. Deux équipes peuvent parler de « lendemain » tout en comptant à partir de moments différents.

« Réserver une intervention le 26 octobre »

Une date sans heure peut désigner une journée entière ou une demande encore incomplète. Évitez de lui attribuer silencieusement minuit pour pouvoir la transmettre à un autre outil.

Google Calendar distingue les événements avec horaires des événements couvrant une journée entière. Son API utilise des champs différents pour ces deux cas. Pour un événement récurrent avec horaires, elle exige également un fuseau pour développer les occurrences. Les événements en journée entière restent définis par des dates, sans fuseau horaire associé. Source : Google Calendar, calendriers et événements.

Pour une intervention avec créneau, demandez l’heure et le lieu ou le fuseau pertinent. Pour une journée réservée sans créneau, conservez cette signification dans toute la chaîne. Vérifiez l’affichage côté équipe et côté client, surtout si leurs paramètres régionaux diffèrent.

Si une IA extrait « lundi prochain » d’un message, faites-lui proposer une date explicite. La validation doit montrer cette date, l’heure éventuelle et le fuseau retenu. Une ambiguïté doit rester visible avant toute invitation ou notification externe.

Le cas à anticiper pendant la nuit du changement d’heure

Le 25 octobre, 2 h 30 se présentera deux fois sur une horloge réglée sur l’heure de Paris. Une consigne contenant seulement la date et cette heure locale ne distingue pas les deux instants. Au passage inverse, au printemps, certaines heures locales sont sautées. Temporal documente ces ambiguïtés et différentes manières de les traiter. Source : TC39.

Pour un traitement nocturne, demandez à votre intégrateur le comportement de votre planificateur dans ces cas. Ne supposez pas qu’il choisira automatiquement la règle attendue : exécuter une seule fois, décaler le lancement ou signaler une anomalie sont des décisions à expliciter.

Si le traitement n’a aucune raison métier de démarrer pendant cette plage, un horaire moins exposé peut simplifier l’exploitation. Cela ne dispense pas de vérifier les autres contraintes, notamment l’arrivée des données et les dépendances entre traitements.

Une répétition avant le basculement

Organisez un essai isolé, avec des destinataires de test et sans envoi réel aux clients. Préparez des dates de référence avant et après le changement d’heure, puis examinez quatre résultats :

• Le récapitulatif quotidien reste prévu à l’heure locale convenue.
• La relance respecte la durée ou le calendrier métier choisi.
• Le rendez-vous conserve le même créneau dans les applications reliées.
• Le traitement nocturne suit la règle décidée lorsqu’une heure se répète.

Un simple affichage correct ne suffit pas : comparez la valeur reçue, celle enregistrée et l’heure de l’action prévue. Un outil peut afficher une conversion correcte alors que le déclencheur travaille avec un autre réglage.

Pour les échéances déjà en attente, vérifiez séparément l’effet d’un changement de configuration. Modifier le fuseau d’un scénario ne garantit pas que tous les rappels déjà créés seront recalculés. Faites l’essai sur une copie ou un petit jeu de données de test avant toute modification générale.

Ce que votre équipe doit pouvoir retrouver

Gardez une fiche courte par automatisation : règle horaire en français, fuseau de référence, événement de départ, exceptions et personne responsable. Pour diagnostiquer un décalage, les journaux devraient permettre de retrouver l’instant technique et son équivalent local, avec le fuseau indiqué.

Avant le 25 octobre, commencez par les flux qui contactent des clients ou conditionnent le travail du matin. Le livrable utile est une liste de prochaines exécutions vérifiées, accompagnée des anomalies à corriger.

Vous souhaitez contrôler un rappel ou un parcours de réservation ? Décrivez vos outils et l’horaire attendu à KADRI AI pour cadrer les vérifications nécessaires.

Sources

Sources primaires consultées le 13 octobre 2026. Les réglages disponibles dépendent des versions et des services utilisés.

• Service Public — Passage à l’heure d’hiver
• IANA — Time Zone Database
• n8n — Schedule Trigger
• TC39 — Time Zones and Resolving Ambiguity
• Google Calendar — Calendars and events