Votre application auto-hébergée a-t-elle besoin d’un ordonnanceur ? Checklist de préparation aux tâches planifiées

Pourquoi les tâches planifiées sont une dépendance opérationnelle, et non un détail d’implémentation

Une interface web prouve que les utilisateurs peuvent ouvrir des pages et soumettre des données. Elle ne prouve pas que l’application accomplira un travail destiné à se produire plus tard, sans présence d’un utilisateur. Pour de nombreuses applications auto-hébergées, ce travail non supervisé est essentiel au service attendu par les utilisateurs.

La [documentation Nextcloud Server 26 sur les tâches d’arrière-plan](https://docs.nextcloud.com/server/26/admin_manual/configuration_server/background_jobs_configuration.html) fournit un exemple spécifique à une version de cette étendue : les tâches d’arrière-plan documentées couvrent le nettoyage de la base de données, la suppression des fichiers temporaires, les vérifications de fichiers du stockage externe, les e-mails d’activité et l’expiration de la corbeille. L’ensemble exact des tâches varie selon l’application, mais l’enseignement opérationnel est général : le travail planifié peut affecter l’hygiène des données, les notifications, les importations, les rapports, les intégrations et la maintenance.

Considérez chaque flux de travail planifié comme une dépendance de production avec un résultat défini et une conséquence en cas d’échec. Une tâche qui supprime simplement d’anciens fichiers temporaires peut tolérer un retard. Une tâche qui envoie des messages urgents, traite une importation client ou rapproche des données métier peut ne pas le tolérer.

• Ne considérez pas que « l’application fonctionne dans le navigateur » prouve que les flux de travail non supervisés fonctionnent.
• Classez chaque tâche selon son impact métier : commodité, importance opérationnelle ou criticité.
• Définissez un retard maximal tolérable pour chaque tâche importante ou critique.
• Attribuez un responsable et un processus d’escalade pour enquêter sur une exécution en échec et la rétablir.
• Utilisez la documentation actuelle d’administration et de déploiement de l’éditeur de l’application comme référence faisant autorité pour les exigences liées aux tâches.

Ordonnanceur, worker d’arrière-plan et requête web : des différences qui affectent le déploiement

Ces termes sont souvent employés de manière imprécise, mais ils décrivent des modèles d’exécution différents. Les confondre peut aboutir à un déploiement qui semble sain alors que des travaux importants sont retardés ou ne démarrent jamais.

Un ordonnanceur lance un travail à une heure ou selon un intervalle défini. Une entrée cron sur l’hôte, un timer systemd ou un Kubernetes CronJob sont des exemples de mécanismes de planification. Un worker d’arrière-plan est un processus qui reste disponible et interroge ou consomme le travail issu du système de tâches de l’application. Un mécanisme déclenché par une requête web ne tente d’exécuter du travail que lorsqu’une personne visite l’application.

La documentation Nextcloud fournit des exemples de ces trois modèles. La [documentation Server 26 sur les tâches d’arrière-plan](https://docs.nextcloud.com/server/26/admin_manual/configuration_server/background_jobs_configuration.html) indique que son mode AJAX exécute une tâche lors d’une visite de page et le décrit comme l’option la moins fiable, car il dépend de visites régulières. La [documentation actuelle sur les commandes système et de maintenance de Nextcloud](https://docs.nextcloud.com/server/latest/admin_manual/occ_system.html) distingue également l’invocation périodique par cron d’un worker persistant de tâches d’arrière-plan qui interroge indéfiniment ; exécuter ce worker une seule fois équivaut à une seule exécution cron. L’application choisie peut prendre en charge d’autres modèles : confirmez donc son modèle pris en charge au lieu de transposer des hypothèses issues d’un autre produit.

• Requête web : adaptée uniquement lorsque la documentation officielle l’autorise explicitement et qu’une exécution irrégulière est acceptable.
• Ordonnanceur périodique : exécute une commande ou une tâche documentée selon une fréquence définie.
• Worker continu : reste actif pour traiter le travail mis en file d’attente ou nouvellement disponible.
• File d’attente : stockage ou mécanisme qui conserve du travail à traiter ultérieurement ; ce n’est pas nécessairement le worker lui-même.
• Ne supposez pas qu’un ordonnanceur assure automatiquement le traitement des files, ni qu’un worker effectue automatiquement une maintenance récurrente.

Trouver les exigences des tâches planifiées dans la documentation officielle de l’application

Commencez par la documentation de l’éditeur concernant l’administration, l’installation, le déploiement, la ligne de commande et les tâches d’arrière-plan. Recherchez dans ces sources des termes tels que cron, ordonnanceur, tâches planifiées, tâches d’arrière-plan, file d’attente, worker, timer, maintenance, consommateur de file, interface en ligne de commande et tâches récurrentes.

Recherchez des instructions opérationnelles explicites plutôt que de vous fier uniquement aux pages de fonctionnalités. Des preuves solides comprennent une commande documentée à exécuter périodiquement, un processus worker documenté, un paramètre d’environnement qui sélectionne un mode de planification, ou des commandes d’administration qui répertorient les tâches et leur historique. Par exemple, la [documentation Nextcloud sur les commandes système et de maintenance](https://docs.nextcloud.com/server/latest/admin_manual/occ_system.html) documente des commandes permettant de lister les tâches enregistrées, d’afficher les tâches en cours, d’inspecter l’historique des tâches et d’exécuter manuellement une tâche.

Consignez l’URL de la documentation ainsi que la version de l’application ou la branche de documentation évaluée. Les exigences peuvent évoluer entre les versions, et cet enregistrement facilite l’examen des mises à niveau.

• Identifiez chaque commande planifiée, commande de worker et commande de maintenance documentée.
• Vérifiez si l’éditeur désigne une méthode comme préférée ou prise en charge en production.
• Identifiez l’utilisateur d’exécution requis, le répertoire de travail, les variables d’environnement et les autorisations.
• Déterminez si des tâches sont enregistrées dynamiquement par des extensions, modules ou par la configuration de l’application.
• Vérifiez si l’application fournit un statut, un historique, une commande d’exécution manuelle ou une action de test.
• Faites remonter toute incertitude à l’éditeur, au responsable de maintenance ou à un opérateur expérimenté avant de considérer la charge de travail comme prête pour la production.

Établir un inventaire des tâches planifiées avant de choisir l’infrastructure

Un inventaire transforme une exigence vague — « configurer cron » — en plan exploitable. Créez un enregistrement par tâche ou famille de tâches. Incluez le travail récurrent et le travail événementiel ponctuel, car tous deux peuvent dépendre de workers, de files d’attente ou de procédures de reprise.

Le [guide du développeur Nextcloud Server 26](https://docs.nextcloud.com/server/26/developer_manual/basics/backgroundjobs.html) distingue les tâches uniques mises en file d’attente des tâches temporisées avec un intervalle minimum entre les exécutions. Cette distinction propre à cette version est utile pour tout inventaire : un rapport récurrent a une planification ; une importation déclenchée par un téléversement ou un événement API peut plutôt nécessiter une consommation fiable de la file. Les contrôles opérationnels peuvent se recouper, mais le déclencheur et l’approche de reprise peuvent différer.

Conservez l’inventaire avec la documentation de déploiement et mettez-le à jour lors de l’activation de modules, de la modification d’intégrations ou de la mise à niveau de l’application.

• Nom de la tâche et référence à la documentation de l’éditeur.
• Objectif métier et utilisateur ou processus concerné.
• Type de déclencheur : planification récurrente, file événementielle, maintenance manuelle ou mixte.
• Fréquence attendue, retard acceptable et échéance, exprimés dans un fuseau horaire nommé.
• Modèle d’exécution et commande, worker ou configuration prise en charge exacte.
• Responsable de la revue courante et responsable de la réponse aux incidents.
• Entrées : enregistrements de base de données, fichiers, files d’attente, API ou configuration.
• Sorties : messages, rapports, changements d’état, fichiers générés, suppressions ou appels API externes. L’inventaire doit aussi consigner les dépendances, l’impact des échecs, le comportement de nouvelle tentative, la politique de chevauchement, la preuve de réussite et les étapes de reprise.

Définir le comportement en cas d’exécutions manquées, de doublons, de chevauchements et de nouvelles tentatives

Une planification décrit le moment où une tentative doit commencer ; elle ne définit pas ce qui doit se passer lorsque les systèmes sont indisponibles ou qu’une tentative précédente est encore en cours. Ces choix doivent être explicites pour les flux de travail critiques.

La [documentation Kubernetes CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) indique que la planification est approximative : dans certaines circonstances, deux Jobs ou aucun Job peuvent être créés. Elle recommande que les Jobs soient idempotents. L’idempotence signifie que répéter une opération ne produit pas d’effet supplémentaire incorrect : par exemple, une nouvelle tentative ne doit pas envoyer deux fois le même message métier ni appliquer deux fois la même mise à jour financière.

Kubernetes illustre également des décisions présentes dans de nombreux systèmes de planification, même si leur nom diffère. Ses [CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) peuvent autoriser les exécutions qui se chevauchent, interdire une nouvelle exécution lorsque la précédente est encore active, ou remplacer une exécution active. Ils peuvent ignorer un démarrage tardif après une échéance définie ; lorsqu’un CronJob précédemment suspendu est repris sans comporter une telle échéance, les exécutions manquées peuvent être planifiées immédiatement. Vérifiez le comportement réel de votre application et de l’ordonnanceur choisi plutôt que de supposer que ces contrôles exacts sont disponibles.

• Exécution manquée : l’ignorer, l’exécuter une seule fois après reprise ou exiger une revue manuelle ?
• Exécution en double : qu’est-ce qui rend la tâche sûre lorsqu’elle est exécutée plusieurs fois ?
• Chevauchement : deux instances peuvent-elles s’exécuter sans risque sur les mêmes données ou le même service externe ?
• Nouvelle tentative : combien de tentatives, quel délai entre elles et quels échecs peuvent faire l’objet d’une nouvelle tentative ?
• Délai d’expiration : à quel moment une exécution bloquée doit-elle être considérée comme échouée ?
• Achèvement partiel : la tâche peut-elle reprendre, compenser ou être relancée sans risque ?
• Effets externes : protégez-vous contre les e-mails en double, les appels API en double et le traitement répété de fichiers.

Définir délibérément les règles d’heure, de fuseau horaire et d’heure d’été

Une récurrence sans fuseau horaire est incomplète. La même expression peut s’exécuter à une heure locale différente après un déplacement de serveur, un changement de plateforme ou une modification de configuration. Les [Kubernetes CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) utilisent le fuseau horaire local du controller manager lorsqu’aucun fuseau horaire n’est explicitement défini, tandis que leur spécification peut définir un fuseau horaire nommé tel que Etc/UTC.

Pour les tâches opérationnelles, UTC est souvent le choix le moins ambigu. Pour les tâches orientées métier — comme un rapport quotidien attendu à une heure ouvrée locale — consignez le fuseau horaire régional nommé pertinent et décidez de la manière dont les transitions à l’heure d’été doivent être gérées. Une heure locale peut se produire deux fois ou ne pas se produire du tout lors d’un changement d’heure.

Distinguez également l’heure à laquelle un ordonnanceur démarre une tâche de la période métier traitée par cette tâche. Un rapport quotidien démarrant à 00:05 ne dispose pas nécessairement de données complètes pour la journée précédente si les systèmes connectés transmettent leurs données tardivement.

• Consignez le fuseau horaire dans l’inventaire, et pas seulement dans un fichier de configuration de l’ordonnanceur.
• Utilisez un fuseau horaire nommé, et non une hypothèse non documentée concernant l’heure locale du serveur.
• Définissez le comportement attendu pour les changements d’heure d’été et les exceptions de calendrier.
• Définissez une heure limite de disponibilité des données ou un filigrane pour les rapports, les importations et les tâches de rapprochement.
• Vérifiez la synchronisation des horloges et des horodatages entre l’application, la base de données, le worker et le système de journalisation.
• Testez au moins une limite de planification et un scénario de reprise avant la mise en production.

Cartographier les dépendances des services connectés et la préparation au démarrage

Une tâche planifiée peut démarrer avec succès tout en échouant parce qu’une dépendance n’est pas prête. Les dépendances typiques comprennent la base de données de l’application, le service de distribution d’e-mails, le stockage objet ou de fichiers, les API externes, le DNS et les identifiants. Considérez-les comme faisant partie de la conception d’exploitation de la tâche.

La [documentation Docker Compose](https://docs.docker.com/compose/how-tos/startup-order/) explique que Compose démarre les conteneurs selon l’ordre des dépendances mais n’attend pas qu’un conteneur soit prêt. Un conteneur de base de données peut être en cours d’exécution avant d’accepter des connexions SQL. Compose prend en charge des conditions basées sur les healthchecks, notamment `service_healthy`, lorsqu’un service doit attendre qu’une dépendance soit prête. C’est un modèle utile à évaluer chaque fois qu’un processus planifié démarre avec le reste d’une pile applicative.

Distinguez l’ordre de démarrage de la résilience continue. Un contrôle d’état peut réduire les échecs évitables immédiatement après le déploiement, mais une tâche doit toujours disposer d’un traitement défini pour un redémarrage de base de données, un identifiant expiré, une API indisponible ou une défaillance temporaire du stockage survenant plus tard.

• Base de données : disponibilité des connexions, compatibilité du schéma, verrous de requêtes et fenêtres de sauvegarde ou de maintenance.
• Service de messagerie : authentification, configuration de l’expéditeur, échecs de débit ou de distribution et protection contre les envois en double.
• API externes : identifiants, limites de débit, délais d’expiration des requêtes, pagination et comportement sûr des nouvelles tentatives.
• Stockage : autorisations, capacité, disponibilité des objets et protections contre le nettoyage involontaire.
• DNS et TLS : uniquement lorsque la tâche appelle des points de terminaison publics ou dépend de chemins de rappel externes.
• Secrets : disponibilité sécurisée pour le processus pris en charge, sans les exposer dans les journaux ou la sortie des tâches.

Choisir un modèle de déploiement pris en charge, puis vérifier ses limites

Il n’existe pas d’emplacement universellement optimal pour exécuter le travail planifié. Choisissez le modèle officiellement pris en charge par l’application, puis évaluez s’il correspond à vos capacités opérationnelles et à vos exigences en cas de défaillance.

Un ordonnanceur géré par l’application peut convenir lorsque l’éditeur le documente clairement et que l’application peut exécuter ses propres tâches récurrentes en toute sécurité. Un ordonnanceur au niveau de l’hôte peut convenir à une application qui documente une commande cron ou un timer de système d’exploitation. À titre d’exemple spécifique à une version, la [documentation Nextcloud Server 26 sur les tâches d’arrière-plan](https://docs.nextcloud.com/server/26/admin_manual/configuration_server/background_jobs_configuration.html) décrit cron du système d’exploitation comme sa méthode privilégiée pour les tâches régulières et présente un timer systemd comme alternative. Un processus worker dédié peut convenir aux applications qui exigent un traitement continu des files d’attente ou documentent un worker persistant.

Pour les environnements conteneurisés, une tâche planifiée au niveau de la plateforme peut être adaptée lorsque l’application documente une commande pouvant s’exécuter comme une invocation isolée et que la sémantique de la plateforme est comprise. Les [Kubernetes CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) offrent des contrôles pour les échéances, les chevauchements et les fuseaux horaires, mais leur planification approximative implique que la conception des tâches doit rester sûre face aux doublons. Ne remplacez pas une méthode d’exécution prise en charge par l’application par une fonctionnalité de plateforme.

Une infrastructure gérée peut réduire le travail lié à l’hébergement d’une application, mais elle ne décide pas de la sémantique des tâches de l’application, des échéances métier, des règles d’accès ou de la politique de reprise. Airbip déploie les instances d’applications de son catalogue comme des charges de travail Docker sur des serveurs cloud et fournit des capacités d’infrastructure incluant l’automatisation du routage et de TLS, les vérifications DNS, la gestion du cycle de vie des services et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. La disponibilité, la configuration et la responsabilité opérationnelle des ordonnanceurs, workers, files d’attente et mécanismes de supervision spécifiques à l’application ne sont pas établies par ces capacités d’infrastructure et doivent être confirmées auprès d’Airbip pour l’application choisie avant le déploiement.

• Planification gérée par l’application : vérifiez comment elle survit aux redémarrages, comment elle est supervisée et si la documentation de l’éditeur prend en charge son utilisation en production.
• Cron de l’hôte ou timer systemd : vérifiez la commande, l’utilisateur d’exécution, l’environnement, les journaux, le verrouillage et le comportement de persistance du timer.
• Worker dédié : vérifiez la supervision du processus, le comportement au redémarrage, la visibilité sur la file, les limites de montée en charge et l’arrêt progressif.
• Ordonnanceur de plateforme : vérifiez le fuseau horaire de la planification, les règles pour les exécutions manquées, les règles de concurrence, les autorisations et l’observabilité.
• Pour chaque modèle : consignez la limite exacte de prise en charge dans la documentation officielle et testez le modèle dans des conditions d’échec.