Qu'est-ce que le Cloud Code planifié (cron jobs) ?

Un cron job est une tâche qui s’exécute automatiquement selon un planning horaire ; le Cloud Code planifié applique l’idée aux fonctions serverless. La lignée part de Unix Version 7, passe par Vixie cron (1987) et mène aux planificateurs des plateformes d’aujourd’hui, et le modèle a à peine bougé : un daemon se réveille chaque minute, lit une table de lignes planning + commande — la crontab — et déclenche ce qui correspond. Ce qui a changé, c’est tout ce qui entoure le modèle : où vit l’horloge, ce qui se passe quand une exécution échoue, et si quelqu’un s’en aperçoit.

Points clés

Cron en un écran

┌ minute (0–59)   ┌ heure (0–23)  ┌ jour du mois (1–31)    ┌ mois    ┌ jour de la semaine (0–7)
*                 *               *                        *         *        commande

0 2 * * *        chaque jour à 02:00     */15 * * * *   toutes les 15 minutes
0 9 * * 1-5      en semaine à 09:00      0 6,18 * * *   à 06:00 et 18:00
0 0 1,15 * *     le 1er et le 15         @daily         = 0 0 * * *
@reboot          une fois au démarrage   @hourly        = 0 * * * *

crontab -e   éditer la table      crontab -l   la lister
crontab -ri  supprimer (avec confirmation — un -r seul l'efface sans rien demander)

L’équivalent moderne — le job dans le code, le planning dans un dashboard, le client qui se contente de lire les résultats :

// JavaScript — Cloud Code (cloud/main.js)
// A scheduled job: defined in code, scheduled in the dashboard
Parse.Cloud.job('nightlyReport', async (request) => {
  const since = new Date(Date.now() - 24 * 60 * 60 * 1000);

  // Idempotent by date key: a rerun overwrites tonight's report, not duplicates
  const existing = await new Parse.Query('DailyReport')
    .equalTo('runDate', dateKey(new Date()))
    .first({ useMasterKey: true });
  const report = existing ?? new Parse.Object('DailyReport');

  report.set('runDate', dateKey(new Date()));
  report.set('summary', await summarizeOrdersSince(since));
  await report.save(null, { useMasterKey: true });
  request.message('Report written'); // shows in the dashboard's job status
});

// Flutter / Dart — Back4app Flutter SDK
// Clients consume what the schedule produces — no crontab in sight
final query = QueryBuilder<ParseObject>(ParseObject('DailyReport'))
  ..orderByDescending('runDate')
  ..setLimit(1);
final latest = (await query.query()).results?.first as ParseObject?;
print(latest?.get<String>('summary'));
// The report exists because a scheduled Cloud Job ran at 02:00 UTC —
// defined in code, scheduled in the dashboard, logged by the platform.

// iOS / Swift — Back4app Swift SDK
// Clients consume what the schedule produces — no crontab in sight
let latest = try await DailyReport.query()
    .order([.descending("runDate")])
    .first()
print(latest.summary ?? "")
// The report exists because a scheduled Cloud Job ran at 02:00 UTC —
// defined in code, scheduled in the dashboard, logged by the platform.

// Android / Kotlin — Back4app Android SDK
// Clients consume what the schedule produces — no crontab in sight
val query = ParseQuery.getQuery<ParseObject>("DailyReport")
query.orderByDescending("runDate")
query.limit = 1
val latest = query.find().firstOrNull()
println(latest?.getString("summary"))
// The report exists because a scheduled Cloud Job ran at 02:00 UTC —
// defined in code, scheduled in the dashboard, logged by the platform.

Les pièges que la page de manuel connaît

Quatre sémantiques de crontab(5) qui surprennent presque tout le monde. La règle du OU : quand le jour du mois et le jour de la semaine sont tous deux restreints, le job se déclenche dès que l’un ou l’autre correspond — 0 0 13 * 5 s’exécute le 13 du mois et chaque vendredi, pas seulement le vendredi 13. L’heure d’été, au pied de la lettre : les jobs planifiés dans « l’heure manquante » du passage à l’heure d’été ne s’exécutent jamais ; les horaires qui surviennent deux fois au retour à l’heure d’hiver s’exécutent deux fois — planifiez en UTC, gardez le travail critique hors des petites heures locales. Les pas repartent à zéro aux limites du champ : */90 dans le champ des minutes ne peut pas signifier « toutes les 90 minutes » — le compteur repart à chaque heure ; les vrais intervalles irréguliers exigent un vrai planificateur. Le plancher de la minute : le daemon parcourt la table une fois par minute ; tout ce qui est plus fin relève d’un autre outil.

Le déficit de fiabilité

Le cron classique est un planificateur, pas un système de fiabilité, et ce déficit a une forme précise : pas de nouvelles tentatives (une exécution ratée reste ratée) ; pas de rattrapage (une machine en veille à 02:00 saute l’exécution — anacron et l’option de persistance des timers systemd existent précisément pour cela) ; pas de réponse pour le cluster (deux serveurs avec la même crontab exécutent tout en double ; un seul serveur est un point de défaillance unique) ; l’échec silencieux (la sortie est envoyée par mail à un compte local que personne ne lit). Les planificateurs modernes répondent à chaque manque par une politique nommée : les politiques de misfire (le fire-now vs. skip de Quartz), les politiques de concurrence (le allow/forbid/replace de Kubernetes pour les exécutions qui se chevauchent) et une sémantique de saut fondée sur une échéance — tout en documentant honnêtement que la planification distribuée est approximativement unique : une exécution peut, à l’occasion, être doublée ou ne pas se déclencher du tout. D’où la discipline que les deux mondes partagent : les jobs planifiés doivent être idempotents — indexés sur leur période (le rapport des onglets de code, indexé par date) pour qu’une réexécution écrase au lieu de dupliquer, et qu’une exécution manquée se rattrape en tournant en retard.

Cron classique vs. timers systemd vs. planificateurs distribués vs. fonctions planifiées

Surveiller les plannings

L’échec planifié est l’échec le plus silencieux de l’informatique : un job qui ne s’est jamais déclenché n’émet rien — ni exception, ni ligne de log, ni e-mail — puisque rien ne s’est exécuté. Le motif qui corrige cela inverse l’alarme : le monitoring par heartbeat — le job pingue une URL quand il se termine avec succès, le moniteur attend ce ping dans un délai de grâce, et c’est l’absence qui déclenche l’alerte. Associez-le à l’hygiène élémentaire que le cron classique n’a jamais eue : la durée des exécutions suivie dans le temps (le rapport qui prenait 4 minutes le mois dernier et 40 ce soir vous dit quelque chose), la sortie capturée dans de vrais logs plutôt que dans le mail local, et l’inventaire des plannings documenté — parce qu’une crontab éparpillée sur cinq serveurs, c’est ainsi que les organisations découvrent des jobs dont elles avaient oublié l’existence.

Cas d’usage courants

• Rapports et synthèses — l’agrégation nocturne esquissée dans les onglets de code : agréger, écrire, notifier.
• Nettoyage et expiration — balayages de TTL, élagage des orphelins, passes d’expiration des sessions et des tokens.
• Synchronisation de données — récupérations périodiques depuis des systèmes tiers qui ne proposent pas de webhooks.
• Rappels et réengagement — envois déclenchés par le temps : fins de période d’essai, paniers abandonnés, avis de renouvellement.
• Santé et réconciliation — l’audit planifié qui rattrape ce que les chemins événementiels ont manqué.

Quel planificateur devriez-vous utiliser ? Matrice de décision

Limites et trade-offs

• Un déclenchement horaire dit quand, pas s’il faut. Un planning se déclenche qu’il y ait du travail ou non ; les triggers événementiels et les files d’attente conviennent au travail qui arrive de façon irrégulière.
• L’« approximativement une fois » est le contrat honnête. Même les planificateurs gérés doublent ou sautent parfois une exécution ; l’idempotence est partout la responsabilité du job.
• Le fuseau horaire est une décision de politique. Les plannings en UTC survivent au changement d’heure ; les plannings en heure locale servent les humains — choisissez délibérément, documentez clairement.
• La fréquence a un plancher et un prix. À la minute pour le cron classique, des planchers dépendants de la plateforme ailleurs ; un polling par cron à haute fréquence n’est généralement qu’une file d’attente déguisée en horloge.
• Les plannings s’accumulent en silence. Chaque job nocturne « temporaire » est permanent tant qu’il n’est pas inventorié ; le dashboard qui les liste tous est une fonctionnalité sous-estimée.

Le Cloud Code planifié sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La planification y rend concrète la colonne moderne du tableau comparatif : définissez Parse.Cloud.job dans Cloud Code — le rapport nocturne des onglets de code, idempotent grâce à sa clé de date, avec accès master key pour l’agrégation multi-utilisateurs — puis planifiez-le dans le panneau Background Jobs du dashboard : nom du job, heure de départ, récurrence, sans syntaxe crontab ni serveur pour héberger cette crontab. Exécutions, statuts et erreurs arrivent dans les logs du serveur et dans le panneau des jobs — la colonne « visibilité des échecs » réglée par défaut — et les disciplines sur lesquelles se clôt cet article restent les vôtres par conception : indexez les jobs sur leur période, gardez-les idempotents, et laissez un heartbeat confirmer que l’horloge de la plateforme et votre logique se sont bien accordées ce soir, comme tous les soirs.