Cron job
Définition
Tâche programmée pour s'exécuter automatiquement à des horaires définis (chaque heure, chaque nuit, le 1er du mois). Utile pour des rapports, des synchronisations ou des nettoyages de base.
Comment ça marche
Un cron job est une tâche planifiée qui s'exécute automatiquement à intervalle régulier : chaque heure, chaque nuit à 3h, tous les premiers du mois. Le nom vient de l'outil Unix cron qui programme les scripts depuis 1975. La syntaxe d'expression cron ("0 3 * * *") décrit minute, heure, jour du mois, mois, jour de la semaine. Sur un serveur Linux, le démon cron lit le fichier crontab et lance le script au moment voulu. Sur le web moderne, les plateformes managées (Vercel Cron, Supabase pg_cron, GitHub Actions schedule) reprennent cette syntaxe et lancent une fonction au lieu d'un script shell.
À quoi ça sert
Les usages classiques sont nombreux. Rapports périodiques (digest hebdomadaire envoyé chaque lundi à 9h). Synchronisations (récupérer les commandes Shopify toutes les heures pour les pousser en compta). Nettoyages (purger les sessions expirées, supprimer les fichiers temporaires de plus de 30 jours). Envois d'e-mails programmés (rappel de paiement, notification de renouvellement). Re-builds programmés (régénérer le sitemap chaque nuit, invalider le cache d'un blog). Calculs périodiques (agréger les statistiques quotidiennes pour le dashboard). Sur tout SaaS un peu sérieux, on finit par avoir 5 à 15 crons actifs.
Les outils
Sur Vercel, Cron Jobs lance une route API à l'heure dite, jusqu'à 60 invocations par jour en plan Pro. Sur Supabase, pg_cron exécute des fonctions SQL directement dans la base, parfait pour les nettoyages ou les calculs en SQL pur. Sur un VPS, le cron Unix classique reste très bien, ou systemd timers pour plus de fiabilité. GitHub Actions schedule offre un cron gratuit pour les tâches qui n'ont pas besoin de production. Inngest et Trigger.dev proposent du cron avec retry et monitoring intégrés, parfait pour les workflows complexes. Le bon outil dépend de la nature de la tâche (SQL, API, workflow) et de l'environnement déjà en place.
L'idempotence est obligatoire
Un cron job qui n'est pas idempotent (relançable sans casser) finit toujours par causer des problèmes. Si le cron envoie un e-mail récapitulatif et qu'on le relance par erreur, le client reçoit deux e-mails. Si il facture, le client est facturé deux fois. On conçoit chaque cron pour qu'une double exécution soit sans effet : marquer le traitement en base avant de l'envoyer, utiliser des identifiants uniques (idempotency keys), filtrer les enregistrements déjà traités. Cette discipline est moins évidente qu'elle paraît, mais elle évite des incidents catastrophiques en production.
Le monitoring est obligatoire
Un cron qui plante peut passer inaperçu pendant des semaines, surtout sur des tâches mensuelles. On utilise Healthchecks.io, Cronitor, Better Stack ou un Sentry Cron Monitoring : le cron "ping" l'outil au début et à la fin de son exécution, et l'outil alerte si le ping n'arrive pas dans la fenêtre attendue. Sans ce filet de sécurité, on découvre les pannes par hasard, souvent quand un client se plaint. Pour les crons critiques (facturation, sauvegardes), on ajoute aussi une alerte si le résultat est anormal (zéro lignes traitées un lundi matin).
Quand l'utiliser
Le cron est l'outil parfait pour les traitements périodiques avec une tolérance de quelques minutes ou heures sur le timing : rapports, nettoyages, synchronisations non temps réel, agrégations. Pour le temps réel ou la réaction à un événement (un paiement validé, un formulaire envoyé), on préfère un webhook qui déclenche immédiatement le traitement. Pour les workflows avec retry, gestion d'erreur, état persistant, on utilise un orchestrateur comme Inngest ou Trigger.dev plutôt qu'un simple cron qui ne sait pas reprendre où il s'est arrêté.
Les pièges à éviter
Le piège du double scheduling : si plusieurs serveurs lancent le même cron sans coordination, la tâche s'exécute plusieurs fois en parallèle. On utilise un verrou en base ou un service dédié (un seul cron sur Vercel, pg_cron sur une seule instance). Le piège des fuseaux horaires : un cron Vercel tourne en UTC, un cron sur un VPS en France peut être en CET. On précise toujours le fuseau, idéalement on travaille en UTC partout. Le piège des dépendances longues : un cron qui prend 30 minutes et qui se relance toutes les 15 minutes finit par avoir 2 instances qui tournent en parallèle. On vérifie le temps d'exécution réel et on ajuste l'intervalle ou on ajoute un verrou.