Constructeur d'expressions cron: Quartz, AWS, alerte DST

Que fait le constructeur ?

Le constructeur d’expressions cron est un éditeur live pour les quatre dialectes cron dominants : Unix cron classique à cinq champs, Quartz à six ou sept champs, AWS EventBridge à forme fixe six champs et Spring @Scheduled avec la même forme six champs sans année. Quand vous tapez dans le champ, le constructeur traduit l’expression immédiatement en une phrase lisible en français, liste les cinq prochaines exécutions dans votre fuseau IANA et signale les passages à l’heure d’été, les combinaisons de dates impossibles et le piège OR quand jour du mois et jour de la semaine sont définis simultanément.

Sous l’explication, vous voyez à quelle fréquence la planification tourne vraiment, par jour d’exécution, par mois et par an. * * * * * fait 525 600 exécutions par an, 527 040 lors d’une année bissextile. Qui paie à l’invocation devrait avoir vu ce chiffre avant le déploiement. Là où le calendrier ne donne aucun chiffre fixe, vous obtenez une fourchette et sa raison plutôt qu’un nombre inventé, car une année compte 52 ou 53 lundis, et avec jour du mois et jour de la semaine définis tous les deux la logique OU compte les deux résultats. Un clic sur un champ montre son sens, la plage de valeurs de la variante choisie et les caractères spéciaux qui y sont admis. L’expression, la variante et le fuseau tiennent aussi dans l’adresse, un lien partagé rouvre donc le même état.

Pur client. Chaque expression reste dans votre navigateur. Pas de serveur, pas de tracking, pas de mur de cookies. L’outil fonctionne hors ligne dès que la page est chargée.

Pourquoi a-t-on besoin d’un outil pour cron ?

Cron paraît anodin, cinq étoiles suffisent à atteindre chaque minute. Mais dès que vous devenez plus spécifique, les détails mordent. 0 0 31 2 * se parse proprement comme chaque 31 février à minuit, mais ne tourne jamais. 0 0 * * 0,1 semble ne tourner que dimanche et lundi, sur les timers systemd c’est exact, sur les implémentations Vixie-Cron classiques le système relie les deux champs jour par OU, et vous attrapez deux fois plus de jours que prévu. 0 2 * * * tourne 364 jours par an, et ce dimanche de mars où l’heure d’été commence, il ne tourne pas, parce que 02:00 n’existe simplement pas dans beaucoup de fuseaux européens. AWS EventBridge documente cela derrière un paragraphe qui commence par les mots intentionally-skipped.

Le constructeur attrape ces trois classes avec la même interface : explication en clair, liste Next-Run dans votre fuseau et un panneau d’indications qui nomme l’heure d’été, le piège OR et les dates impossibles dans un langage unifié.

Quatre dialectes dans un éditeur

Unix cron est la forme à cinq champs qui accompagne chaque distribution Linux. Quartz, le scheduler derrière Spring Batch et Quartz.NET, ajoute un champ secondes devant et optionnellement un champ année derrière. Quartz compte le jour de la semaine de 1 à 7 avec dimanche à 1, Unix de 0 à 7, où 0 et 7 désignent tous deux dimanche. AWS EventBridge reprend la forme Quartz avec cette même numérotation. Les deux exigent exactement un point d’interrogation, dans jour du mois ou jour de la semaine, et le constructeur refuse tout le reste. Spring @Scheduled est un clone Quartz sans année, mais il compte le jour de la semaine comme Unix.

Le constructeur distingue les quatre dialectes via le sélecteur d’onglet en haut. Chaque clic sur un preset (Hourly, Weekdays 09:00, Weekend 10:00) tire automatiquement l’expression adaptée à la variante actuellement choisie. Un changement de variante traduit aussi le preset sélectionné, sans que vous ayez à retaper l’expression.

Explication en clair: Voice-Search-First

La première ligne de l’explication répond directement à la question, par exemple : Chaque lundi à 09:00. Cette convention facilite Voice-Search et la citation par LLM : la phrase fonctionne comme mot-clé sans étapes de contexte supplémentaires. Les réponses Google Assistant et Perplexity lisent typiquement les dix premiers mots du premier paragraphe, l’explication est exactement formée pour cela.

Aperçu de fuseau horaire

La liste Next-Run calcule en arrière-plan via Intl.DateTimeFormat et vérifie pour chaque jour du calendrier de la zone cible si le mois, le jour et le jour de semaine correspondent, avant de résoudre les heures de ce jour. Huit fuseaux populaires sont préréglés, UTC, Europe/Berlin, Europe/London, America/New_York et quatre autres. La base IANA des fuseaux horaires est la référence mondiale pour les données de fuseaux, navigateurs, serveurs et bibliothèques runtime l’utilisent.

Alerte heure d’été

Le constructeur cherche les prochains changements d’heure du fuseau choisi, sur environ treize mois, et vérifie pour chacun si une heure planifiée tombe dans la plage qui disparaît ou dans celle qui se répète. Ce n’est qu’alors qu’une alerte apparaît à côté de la liste Next-Run, avec le saut réel de ce fuseau : Le 28/03/2027 l'exécution de 02:30 n'a pas lieu, l'horloge saute de 02:00 à 03:00 ou Le 25/10/2026 le job tourne deux fois à 02:30, l'horloge recule de 03:00 à 02:00. Le saut est mesuré, pas supposé : Pacific/Chatham change à 02:45 et Australia/Lord_Howe change d’une demi-heure, et c’est bien ce que dit l’alerte. Ces phrases évitent l’erreur d’interprétation la plus fréquente pour les jobs de sauvegarde et de reporting.

Que vérifie la validation sémantique ?

Syntaxiquement valide ne veut pas dire sémantiquement sensé. Le constructeur distingue trois classes :

• Ne tournera jamais, 0 0 31 2 * se parse proprement, mais le 31 février n’existe pas. Le constructeur le reconnaît à partir de la table des longueurs de mois et signale l’alerte immédiatement.
• Piège OR, Quand jour du mois et jour de la semaine sont tous deux définis, Vixie-Cron relie par OU, systemd et Spring par ET. 0 0 1 * MON tourne sur Vixie-Cron chaque 1er plus chaque lundi, sur systemd seulement le 1er si c’est un lundi. L’alerte nomme les deux attentes d’implémentation, pour que le réviseur ne s’étonne pas plus tard.
• Erreur de variante, Qui tape des secondes dans un Unix cron ou pose le point d’interrogation dans un champ Unix obtient un message clair d’erreur de variante au lieu d’un échec de parse silencieux.

Quels exports sont intégrés ?

Quatre formats cibles sont prêts. Chacun livre exactement le bloc que vous pouvez copier dans votre YAML, manifeste ou crontab :

Chaque export est traduit dans le dialecte de la cible, il n’est pas simplement recopié. Une expression AWS avec point d’interrogation et champ année est réécrite en cinq champs Unix valides pour la crontab, et une expression Unix devient six champs avec point d’interrogation pour EventBridge. Ce que la cible ne sait pas exécuter sort commenté, avec la raison au-dessus, pour qu’un collage à l’aveugle n’installe pas une planification cassée.

• crontab, une simple ligne cron plus en-tête de commentaire et CRON_TZ avec le fuseau choisi, pour que le job ne tourne pas dans le fuseau du serveur. Convient à crontab -e ou à un fichier /etc/cron.d.
• GitHub Actions, bloc on.schedule complet avec name et cron entre guillemets simples. L’heure reste dans ton fuseau, à côté de la clé timezone: que GitHub Actions comprend depuis mars 2026. En dessous, commentée, la même ligne convertie en UTC pour les versions plus anciennes de GitHub Enterprise Server sans cette clé ; là, une conversion qui décale le jour décale le jour de la semaine avec lui.
• CronJob Kubernetes, manifeste complet avec apiVersion: batch/v1, kind: CronJob, spec.timeZone avec le fuseau choisi, nom DNS-1123 nettoyé et container d’exemple busybox. Vous ne remplacez que image et command.
• AWS EventBridge, wrap cron(...) dans la forme à six champs avec année et point d’interrogation qu’exige la console AWS.

Qu’est-ce qui n’est délibérément pas construit ?

Le constructeur est builder-only : il planifie, valide et exporte. Monitoring, alerting, historique et appel de jobs cron n’y appartiennent pas. Ces fonctions:

• Pas de monitoring ni de dead man’s switch, pour cela il y a Cronitor et services équivalents.
• Pas de stockage d’historique au-delà de la session courante, le hard-cap « pas de localStorage » vaut ici aussi.
• Pas de simulation au-delà de quatre ans, 0 0 29 2 * figerait sinon l’aperçu.
• Pas de dialectes vendor (Jenkins H-Hash, Nomad-spécifique, extensions Camel-Quartz).
• Pas de traduction NLP texte-vers-cron, cela appartient aux outils LLM et brise la promesse pur-client.

Comment la confidentialité est-elle gérée ?

Le constructeur tourne entièrement dans votre navigateur. Il n’y a pas d’appel serveur, pas d’endpoint de télémétrie, pas de bandeau cookie. Les seules API hôtes utilisées par le constructeur sont new Date() pour l’ancre temporelle de la prévision Next-Run et Intl.DateTimeFormat pour la conversion de fuseau IANA. Les deux sont des standards web depuis des années, sans implication de tracking.

Thèmes liés

• Cron sur Wikipédia : histoire, Vixie-Cron, timers systemd
• Base IANA des fuseaux horaires : source des données de transition DST
• Manuel GNU mcron : extensions au-delà de Vixie-Cron, lecture optionnelle pour des patterns scheduler custom