Vercel Schedules lance des tâches ponctuelles et récurrentes sans redéploiement

Cron fonctionne très bien quand le développeur connaît le calendrier à l'avance : purger les enregistrements expirés à deux heures du matin, mettre à jour un index une fois par jour, synchroniser des données toutes les dix minutes. Les problèmes commencent lorsque l'heure est choisie non par le développeur, mais par l'utilisateur, et ce après le lancement de l'application.

Imaginez une simple requête adressée à un agent : « Demain matin, rassemble les cinq principales actualités de Hacker News et prépare un bref résumé ». Dans le schéma traditionnel, l'application enregistre la demande et l'heure d'exécution en base, tandis qu'un cron distinct vérifie régulièrement quelles tâches doivent être exécutées. C'est une solution viable, mais elle s'accompagne d'une infrastructure annexe : table de tâches, mécanisme d'interrogation, verrous, gestion des répétitions et logique d'annulation.

Vercel a présenté Schedules, un service qui permet à l'application de créer, modifier et annuler des tâches ponctuelles et récurrentes pendant son fonctionnement. Il n'est nécessaire ni de modifier la configuration du projet ni de redéployer l'application. Le service est entré en bêta publique.

Comment ça marche

L'application transmet à Vercel l'heure, le fuseau horaire, la cible d'exécution et la charge utile. Un tel planning peut être créé via le SDK JavaScript, l'API ou la CLI. Lorsque le moment venu arrive, Vercel livre les données enregistrées dans le topic Vercel Queues indiqué, et le code de l'application reçoit le message et effectue le travail.

Dans l'exemple de Vercel, l'agent dispose d'un outil scheduleTask. L'utilisateur formule sa tâche, le modèle appelle l'outil, qui crée un planning à exécution unique avec les identifiants de l'utilisateur et du locataire. Le lendemain, le gestionnaire lit le message dans la file, vérifie les droits actuels de l'utilisateur, lance l'agent et enregistre le résultat.

C'est un détail important : le planning répond uniquement à la question « quand transmettre le travail ». Le travail lui-même, la vérification des accès, l'enregistrement du résultat et la gestion des erreurs restent à la charge de l'application.

Pour les tâches connues à l'avance, la configuration statique dans vercel.json ou dans la Build Output API demeure. Par exemple, le nettoyage quotidien de la base peut être associé à une fonction privée et à un fuseau horaire précis. Vercel appelle cette fonction directement, sans adresse HTTP publique, et confirme lui-même que l'exécution provient du service de planification.

Ce qui change pour le développeur

L'avantage principal : la couche maison d'interrogation de la base pour les minuteurs utilisateur disparaît. Le planning devient un objet géré à part entière : on peut le créer, le déplacer ou l'annuler depuis l'application en cours d'exécution. L'historique des exécutions s'affiche dans le tableau de bord Vercel, et une tâche peut être lancée manuellement pour test.

Schedules prend en charge les déploiements Preview et les environnements personnalisés. Le gestionnaire peut donc être testé avant la production, sans attendre l'heure réelle de déclenchement. Le développement local est disponible via vercel dev.

Il ne faut toutefois pas voir dans ce service un remplacement complet d'une file d'attente ou d'un moteur de processus en arrière-plan. Les tâches dynamiques sont livrées précisément via Vercel Queues ; il faut donc réfléchir à la relivraison, à l'idempotence du gestionnaire et à l'observabilité. Si une opération débite de l'argent ou envoie un e-mail, une réexécution ne doit pas accomplir l'action deux fois.

Il existe aussi un risque produit : l'utilisateur a pu perdre son accès entre la création du planning et son déclenchement. Vercel montre explicitement la bonne approche : revérifier les autorisations avant de lancer l'agent, plutôt que de se fier aux données enregistrées la veille.

Conclusion pratique

Si votre application tourne déjà sur Vercel et a besoin de rappels, d'actions différées de l'agent ou de tâches de maintenance régulières, Schedules mérite d'être testé dans un environnement Preview. Il est raisonnable de commencer par une tâche non critique, d'ajouter l'idempotence et la journalisation, puis de vérifier l'annulation, le changement de fuseau horaire et la relivraison.

Pour une équipe qui dispose déjà d'un planificateur et d'une file d'attente fiables, il n'y a pas de raison urgente de migrer. Mais pour un nouveau produit, Vercel Schedules réduit la quantité d'infrastructure à maintenir et transforme la phrase de l'utilisateur « fais-le demain matin » en simple appel d'API, plutôt qu'en sous-système à part.