For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/modules/schedules.md (or send Accept: text/markdown).
Tâches planifiées
Le travail récurrent des workspaces via les schedule actions.
Parcours pas à pas pour débuter
Prérequis : Lisez les deux guides pour débutants ci-dessous, terminez la configuration locale du Web et ouvrez ce monorepo à sa racine dans votre éditeur. Les paramètres Web appartiennent à apps/web/.env.local ; Next.js ne lit pas la racine .env. /dashboard dans le mode faux par défaut est une démo sans base de données ; /auth nécessite une base de données migrée.
Termes rapides : un espace de travail est constitué des utilisateurs, des données et des paramètres distincts d'une équipe. Le serveur est le backend de confiance ; gardez les clés du fournisseur hors du code du navigateur et du téléphone. Une migration est une modification de base de données versionnée qui crée ou met à jour des tables. Un modèle d'IA est le moteur qui répond ; le catalogue de modèles est la liste du serveur des identifiants de modèles et des prix disponibles. Un fournisseur est un service externe tel qu'un service d'IA, de messagerie ou de facturation. Un droit est une subvention qui permet à un espace de travail d'utiliser une fonctionnalité. Un webhook est un message qu'un service envoie au URL d'un autre service.
1. Ouvrez Settings → Developers et utilisez les contrôles Planifications pour créer une tâche de test avec un environnement d'exécution UTC.
2. Gardez l'application en cours d'exécution et rendez le même SCHEDULER_TICK_SECRET réservé au serveur disponible pour l'application et le terminal ; exécutez la commande ci-dessous à partir de la racine du référentiel.
3. Confirmez l'avance du délai et le travail atteint son propre statut. Si rien ne fonctionne, vérifiez l'heure du UTC, le fournisseur du planificateur et les journaux du serveur ; ne collez jamais le secret dans le chat.
Pour le code personnalisé, commencez par le prompts/README.md fourni et copiez l'invite la plus proche : prompts/new-app-screen.md pour un écran d'application ou prompts/new-landing-page.md pour une page publique. Pour le travail sur un serveur, une base de données ou un fournisseur, confiez à votre agent de codage la tâche de ce guide et demandez-lui de lire les miroirs AGENTS.md, .ai/PROJECT_CONTEXT.md et .ai/ correspondants ; inspectez les fichiers sources exacts nommés ici ; lister les fichiers et les vérifications avant de les modifier ; préserver la propriété de l'espace de travail et les secrets du serveur ; et je vous montre la différence. Indiquez-lui le comportement souhaité, les champs d'entrée et de sortie, les rôles autorisés, les succès et erreurs attendus, ainsi que le compte, le fournisseur ou l'appareil de test. Utilisez des exemples de valeurs ; ne collez jamais un vrai secret.
corepack pnpm jobs:tickStocker les tâches récurrentes dans la base de données
La planification des paramètres stocke le type de tâche et la règle cron dans les lignes job_schedule limitées à l’espace de travail. Les champs cron sont évalués en UTC. createDrizzleJobScheduler.claimDueSchedules revendique les lignes échues avec FOR UPDATE SKIP LOCKED, avance leur prochaine exécution puis distribue les gestionnaires.
Le contrat générique JobRunner garantit uniquement la mise en file, l’état et l’annulation. La récurrence appartient aux lignes du planificateur ; les garanties de workflow Trigger.dev restent explicites.
Déclencher les cycles du planificateur
Définissez un SCHEDULER_TICK_SECRET réservé au serveur pour activer POST /api/internal/scheduler-tick. corepack pnpm jobs:tick l'appelle pour dev/CI ; la configuration absente renvoie 404. Sous JOB_PROVIDER=trigger, le cron scheduler.tick déployé pilote le planificateur.
# Against a running local app, with SCHEDULER_TICK_SECRET configured:
corepack pnpm jobs:tickVérifier séparément les revendications et l’exécution
Testez des déclenchements qui se chevauchent, les règles de date échue ou non, les lignes désactivées, l’échec d’un gestionnaire, l’annulation et le planning d’un autre espace de travail. Examinez séparément la revendication, l’avancement et la fin de la tâche : une ligne revendiquée ne prouve pas que le travail est terminé.
Configuration et paramètres
Le travail planifié — digests, nettoyages, renouvellements — passe par schedule-actions plutôt que des timers ad hoc : listWorkspaceSchedules, upsertScheduleAction et removeScheduleAction gèrent les tâches cron d'un workspace.
Un schedule nomme la tâche, l'expression cron et le workspace sous lequel elle tourne. Le worker résout le contexte à l'exécution — un schedule mis en pause ou supprimé cesse de produire du travail sans redéploiement.
listWorkspaceSchedules()
upsertScheduleAction({ task, cron })
removeScheduleAction(formData)Processus d’implémentation
Traitez chaque exécution planifiée comme une entrée non fiable : re-résolvez workspace et entitlement dans l'exécution, car l'état a pu changer depuis l'enregistrement. Rendez la tâche idempotente — une exécution retentée ou doublée ne doit pas dupliquer les effets.
Les schedules sont une surface opérationnelle : gardez-les visibles dans les settings ou les logs pour qu'un schedule bloqué ou emballé soit trouvé avant que les utilisateurs ne le remarquent.
Vérification et dépannage
Déclenchez le schedule manuellement dans un sandbox, mettez-le en pause, vérifiez qu'un workspace désactivé ne produit plus d'exécutions, et confirmez qu'un double déclenchement ne produit qu'un effet. Gardez les expressions cron dans la configuration gérée, pas dispersées dans le code des tâches.