Michael JohnsonOpenAI a annoncé Scheduled Automations pour l’Agents API le 23 octobre 2026. Cette fonctionnalité permet de lancer des tâches d’agent selon une planification cron ou à un moment donné ; lorsque l’outil automations est activé, l’agent peut également planifier lui-même des tâches ultérieures. L’annonce a été publiée sur le forum de la communauté OpenAI ; les détails de mise en œuvre figurent dans la documentation de Scheduled Automations.
Pour les applications, cela ajoute une planification persistante à l’API, où l’agent travaille au moyen de sessions qui conservent leur configuration et leur contexte. Les équipes peuvent ainsi confier plus facilement à l’agent des vérifications régulières ou des rappels différés, sans avoir à déclencher manuellement chaque exécution.
Fonctionnement du lancement
La planification définit la session cible et l’heure à laquelle la tâche doit lui être transmise. Pour une exécution périodique, le développeur indique une expression cron et un fuseau horaire IANA, par exemple America/New_York. Pour une exécution unique, il spécifie un horodatage Unix futur en secondes.
La tâche peut créer une nouvelle session à chaque exécution ou reprendre une session existante. La première option convient aux opérations récurrentes indépendantes ; la seconde conserve le contexte antérieur de la session. Après sa création, la planification reçoit le statut active, mais la tâche ne s’exécute qu’à l’heure prévue : sa création ne la lance pas immédiatement.
Il est également possible de fournir à l’agent l’outil automations. Il peut alors planifier une vérification ultérieure dans le cadre de la session en cours. Cette option est utile pour les tâches à plusieurs étapes dont le prochain lancement dépend du résultat précédent, par exemple pour surveiller périodiquement l’état d’une tâche.
La transmission de la tâche est distincte de son exécution
Chaque lancement crée une invocation, c’est-à-dire un enregistrement de la tentative de transmission de la tâche à la session cible. Le développeur peut vérifier le statut de l’appel et l’identifiant de la session. Si la session est occupée, la tâche attend ; le fait que la session reçoive la tâche ne signifie pas que le travail de l’agent est terminé. Sa progression et son résultat sont suivis séparément au moyen des événements de session, comme l’explique la documentation sur les invocations et les résultats.
En pratique, le suivi doit porter sur deux états : la tâche planifiée a-t-elle été transmise à la session, et celle-ci a-t-elle terminé la tâche ? Pour les processus périodiques, il est utile de conserver l’identifiant de la planification et de l’associer à l’historique des exécutions afin de repérer les omissions et d’analyser les tentatives infructueuses.
Points à vérifier avant le déploiement
- Fuseau horaire. Indiquez-le explicitement et vérifiez la correspondance entre les heures planifiées et les changements d’heure d’été ou d’hiver dans le fuseau choisi.
- Type de session. Utilisez une nouvelle session pour les exécutions indépendantes, et une session existante lorsque la tâche a besoin du contexte antérieur.
- File d’attente et résultat. Tenez compte du fait qu’une session occupée peut retarder la transmission et que la prise en charge de la tâche ne signifie pas que le travail est terminé.
- Gestion des planifications. L’API permet de créer, mettre à jour, suspendre, reprendre et supprimer des planifications ; après une modification de la configuration, vérifiez les exécutions à venir.
Scheduled Automations ajoute à l’Agents API des planifications gérées : chaque exécution peut être associée à une session et suivie séparément. Lors du déploiement, les développeurs doivent déterminer si une exécution nécessite le contexte accumulé, et surveiller à la fois la transmission et le résultat de la tâche.