Chapitre 4.6Cron et les tâches planifiées

Nous avons vu, dans le chapitre sur le back-end, qu'une bonne partie du travail d'un système n'est déclenchée par personne. La newsletter du mardi matin, les relances de paiement, la mise à jour des prix d'un fournisseur : aucun de ces traitements n'attend qu'un utilisateur clique quelque part.

Il faut donc quelque chose qui les lance à sa place, à l'heure dite, tous les jours, sans que personne n'y pense. C'est le rôle du planificateur de tâches.

Un réveil pour les programmes

Sur les serveurs, ce réveil s'appelle le plus souvent cron. Le nom vient du grec "chronos", le temps. C'est un vieil outil, né dans les années 1970, et il fait toujours exactement la même chose : lire une liste de rendez-vous et lancer le programme prévu quand l'heure arrive.

Cette liste porte un nom que tu entendras peut-être en réunion, la "crontab". Chaque ligne y décrit un rendez-vous : quand, et quoi lancer.

0 3 * * *   php /site/relancer-les-paiements.php

Les cinq premières valeurs sont l'horaire, dans cet ordre : la minute, l'heure, le jour du mois, le mois, le jour de la semaine. Une étoile veut dire "tous". Cette ligne se lit donc : à la minute 0 de la 3e heure, n'importe quel jour, n'importe quel mois, n'importe quel jour de la semaine. Autrement dit, tous les jours à trois heures du matin.

Cette syntaxe a mauvaise réputation, et elle la mérite un peu. Beaucoup de développeurs passent par un site qui la traduit en français avant de la valider. Tu n'as pas à la retenir, mais savoir la lire te permet de vérifier toi-même qu'un traitement tourne bien au moment que tu croyais.

Ce que ça fait tourner chez toi

Tu utilises probablement le résultat de plusieurs de ces traitements tous les jours, sans le savoir.

• Les relances commerciales : panier abandonné depuis deux heures, abonnement qui arrive à échéance, carte bancaire bientôt périmée.
• Les envois en masse : une newsletter part rarement d'un coup. Elle est découpée et étalée pour ne pas saturer les boîtes mail ni se faire prendre pour du spam.
• Les échanges avec l'extérieur : récupérer un catalogue fournisseur, envoyer les commandes du jour au transporteur, transmettre la comptabilité.
• Les chiffres : pendant la nuit, les données de la veille sont rassemblées et calculées, pour que ton tableau de bord s'ouvre en une seconde le matin au lieu de mouliner cinq minutes.
• Le ménage : supprimer les paniers abandonnés depuis six mois, archiver les vieux fichiers, vider ce qui doit l'être au regard du RGPD.
• Les sauvegardes : la copie quotidienne de la base de données, celle dont personne ne parle jusqu'au jour où tout le monde en dépend.

Tu remarqueras que beaucoup tournent la nuit. Ce n'est pas un hasard : le site est calme, donc les traitements lourds ne ralentissent personne, et la journée de la veille est terminée, donc les chiffres sont complets.

Ce que ça change à ce que tu vois

C'est ici que se cache la réponse à deux questions qui reviennent sans cesse. "Pourquoi mon tableau de bord affiche encore les chiffres d'hier soir ?" et "pourquoi le stock met un quart d'heure à bouger ?"

Parce que la donnée n'est pas calculée au moment où tu la regardes, elle a été préparée à l'avance par un traitement planifié, et elle restera telle quelle jusqu'au passage suivant. Ce n'est pas un bug, c'est un choix, le même que celui du cache, qui produit exactement la même illusion pour les mêmes raisons. Avant de demander "du temps réel", demande à quelle fréquence le traitement tourne. Bien souvent, le passer de la nuit à toutes les heures règle la question à peu de frais.

Décaler la newsletter de 8h à 9h a l'air d'un réglage. C'est une modification sur le serveur, donc une mise en production, avec la relecture et le délai qui vont avec. Ce n'est pas long, mais ce n'est pas instantané, et ça se planifie.

Les pièges

Un traitement planifié n'a pas d'utilisateur devant lui. C'est tout son intérêt, et c'est aussi tout son problème : quand il se passe mal, il n'y a personne pour s'en apercevoir.

Un site en panne se voit en trente secondes. Un traitement de nuit qui ne tourne plus peut passer inaperçu pendant des semaines. Le jour où tu t'en rends compte, ce sont trois semaines de relances jamais envoyées.

Les autres pièges reviennent si souvent qu'ils méritent d'être connus, ne serait-ce que pour poser la bonne question à ton équipe.

• Le chevauchement : un traitement prévu toutes les dix minutes qui met un quart d'heure à s'exécuter. Le suivant démarre avant que le précédent ait fini, et les deux se marchent dessus.
• Le doublon : relancer un traitement interrompu semble anodin, jusqu'à ce que les clients déjà traités reçoivent l'email une deuxième fois. La parade consiste à écrire le traitement pour qu'il puisse être relancé sans conséquence, en notant ce qui a déjà été fait. Les développeurs disent qu'il est idempotent, et c'est une question à leur poser avant la première panne, pas après.
• Le rattrapage : une nuit sans traitement, ce sont des relances, des exports ou des chiffres qui manquent. Est-ce que le traitement reprend là où il s'est arrêté, ou faut-il rejouer la journée à la main ? La réponse doit exister avant la panne.
• La fenêtre qui rétrécit : un traitement de nuit qui prenait dix minutes à ses débuts en prend quatre heures avec dix fois plus de clients, et finit par mordre sur les heures d'ouverture. C'est un symptôme classique de croissance, et souvent le moment où l'on passe à une autre organisation.
• L'heure : le serveur n'est pas forcément à l'heure de Paris, et le passage à l'heure d'été fait disparaître une heure de la nuit. Un traitement prévu à 2h30 ce jour-là ne tourne tout simplement pas. Nous en avons parlé dans le chapitre sur les fuseaux horaires.
• L'oubli : ces lignes vivent sur le serveur, pas toujours à côté du reste du projet. Un déménagement de machine ou une refonte, et personne ne se souvient qu'il fallait les recopier.

La question à poser

Tu n'as pas besoin de savoir comment un traitement planifié est configuré. Une seule question suffit à couvrir l'essentiel du risque.

Qui est prévenu, et comment, quand ce traitement ne tourne pas ou se termine en erreur ?

Si la réponse est "on s'en rendrait compte", c'est qu'il n'y a pas de réponse. Les équipes qui font ça sérieusement mettent en place une surveillance : le traitement signale qu'il a bien fini, et c'est l'absence de ce signal qui déclenche l'alerte. C'est le sujet du chapitre sur le monitoring et les logs.

Cron reste la solution la plus répandue parce qu'elle est simple et présente partout. D'autres approches existent pour les besoins plus exigeants. Les hébergeurs cloud proposent des planificateurs gérés, qui journalisent chaque exécution et alertent d'eux-mêmes, souvent couplés à des fonctions serverless. Et quand un traitement doit démarrer dès qu'un évènement survient plutôt qu'à heure fixe, on passe par une file de messages, que nous verrons dans la partie sur les API.