Tâches planifiées

Tâches planifiées

Planifiez des tâches récurrentes dans ChatGPT

Planifiez des tâches récurrentes à exécuter en arrière-plan. Sur ChatGPT sur le Web et sur mobile, les forfaits éligibles permettent aussi de déclencher des tâches à partir d’événements d’applications compatibles. Consultez les tâches actives, en pause ou terminées et les exécutions récentes dans Planifiées. Vous pouvez combiner les tâches planifiées avec des skills pour des travaux plus complexes.

GPT-5.5 est retiré de Codex avec une connexion ChatGPT le 14 octobre 2026 à midi PDT (19 h 00 UTC). Vérifiez les tâches planifiées qui utilisent GPT-5.5 dans Codex et choisissez gpt-6.1-sol (GPT-6.1 Sol) si votre offre et votre espace de travail y donnent accès. L’OpenAI API et les sessions Codex authentifiées avec une API key ne sont pas concernées. Consultez Retrait de GPT-5.5 pour connaître les modèles de remplacement propres à chaque offre.

Dans l’application de bureau ChatGPT, les tâches planifiées peuvent interagir avec des projets locaux et s’exécuter dans le répertoire du projet ou dans un worktree isolé. Laissez l’ordinateur allumé et l’application en cours d’exécution lorsqu’une tâche planifiée a besoin de fichiers locaux.

Vous pouvez, par exemple, planifier une tâche pour évaluer les erreurs de télémétrie et soumettre des correctifs, ou pour créer des rapports sur les modifications récentes de la base de code. Pour un travail continu qui doit conserver le même contexte, planifiez une tâche dans un chat existant.

Pour les tâches planifiées associées à un projet, laissez la machine allumée et l’application de bureau ChatGPT en cours d’exécution. Le projet sélectionné doit toujours être disponible sur le disque au moment où la tâche doit s’exécuter.

Dans les dépôts Git, vous pouvez choisir d’exécuter une tâche planifiée dans votre projet local ou dans un nouveau worktree. Les deux options s’exécutent en arrière-plan. Les worktrees séparent les modifications des tâches planifiées du travail local inachevé, tandis qu’une exécution dans votre projet local peut modifier des fichiers sur lesquels vous travaillez encore. Dans les projets sans contrôle de version, les tâches planifiées s’exécutent directement dans le répertoire du projet.

Vous pouvez également conserver les paramètres par défaut du modèle et de l’effort de raisonnement, ou les choisir explicitement si vous souhaitez contrôler plus précisément l’exécution de la tâche planifiée.

Si une tâche planifiée utilise un modèle retiré, mettez-la à jour en choisissant un modèle de remplacement disponible. Consultez les conseils de migration des modèles.

Les tâches planifiées s’exécutent sans supervision avec vos paramètres de bac à sable par défaut. Commencez par les accès les plus restreints permettant à la tâche d’aboutir et n’accordez un accès au réseau ou un accès plus large aux fichiers que si nécessaire. Comprendre le fonctionnement des bacs à sable.

Gérer les tâches planifiées

Retrouvez toutes les tâches planifiées et leurs exécutions dans Planifié, dans la barre latérale de l’application de bureau ChatGPT.

La vue Planifiées fait office de boîte de réception. Les exécutions de tâches planifiées qui produisent des résultats y apparaissent, et un indicateur de contenu non lu signale celles qui nécessitent votre attention.

Les tâches planifiées autonomes démarrent une nouvelle discussion à chaque exécution planifiée et présentent leurs résultats dans Tâches planifiées. Utilisez-les lorsque chaque exécution doit être indépendante ou lorsqu’une tâche planifiée doit s’exécuter sur un ou plusieurs projets. Si vous avez besoin d’une fréquence personnalisée, utilisez les commandes de planification personnalisée. Pour une planification avancée, modifiez sa règle de récurrence RFC 5545 (RRULE), par exemple RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0.

Pour les dépôts Git, chaque tâche planifiée peut s’exécuter soit dans votre projet local, soit dans un worktree dédié en arrière-plan. Utilisez les worktrees lorsque vous souhaitez isoler les modifications de la tâche planifiée du travail local inachevé. Utilisez le mode local lorsque vous souhaitez que la tâche planifiée agisse directement dans votre checkout principal, en gardant à l’esprit qu’elle peut modifier des fichiers que vous êtes en train d’éditer. Dans les projets sans contrôle de version, les tâches planifiées s’exécutent directement dans le répertoire du projet. Vous pouvez exécuter la même tâche planifiée sur plusieurs projets.

Les tâches planifiées créées avec ChatGPT Work sur le web, ou avec ChatGPT Work ou Codex dans l’application de bureau, peuvent utiliser des plugins. Les tâches planifiées peuvent également utiliser des skills. Pour que les tâches planifiées restent faciles à maintenir et à partager entre les équipes, utilisez des skills afin de définir l’action et de fournir les outils et le contexte. Sélectionnez ou invoquez un skill précis dans le prompt de la tâche lorsque le workflow ne doit pas reposer sur la sélection automatique des outils.

Demander à ChatGPT de créer ou de mettre à jour des tâches planifiées

Vous pouvez créer et mettre à jour des tâches planifiées depuis une conversation ChatGPT ou Codex. Décrivez le travail à effectuer, le moment de son exécution et précisez si chaque exécution doit revenir dans la conversation actuelle ou en ouvrir une nouvelle. ChatGPT peut rédiger le prompt, choisir la bonne destination et mettre à jour la tâche lorsque son périmètre ou sa fréquence change.

Vous pouvez, par exemple, demander à ChatGPT de planifier un suivi depuis le chat actuel pendant qu’un déploiement se termine, ou lui demander de créer une tâche planifiée autonome qui vérifie régulièrement un projet.

Les skills peuvent également créer ou mettre à jour des tâches planifiées. Par exemple, un skill chargé de surveiller une pull request pourrait configurer une tâche planifiée qui vérifie l’état de la PR avec le plugin GitHub et corrige les nouveaux retours de revue.

Planifier une tâche dans un chat

Planifiez une tâche dans un chat existant lorsque vous souhaitez que ChatGPT revienne dans ce chat selon une fréquence définie. La tâche planifiée utilise le contexte existant du chat au lieu de repartir d’un nouveau prompt à chaque fois.

Les tâches planifiées dans un chat peuvent utiliser des intervalles exprimés en minutes pour les boucles de suivi actives, ou des planifications quotidiennes et hebdomadaires lorsque vous avez besoin d’un point de contrôle à une heure précise.

Planifiez une tâche dans un chat pour :

  • vérifier une opération de longue durée jusqu’à ce qu’elle se termine
  • vérifier une source connectée à fréquence fixe lorsque vous avez besoin d’un instantané périodique plutôt que d’une réponse à un événement pris en charge dans une application
  • rappeler à ChatGPT de poursuivre un cycle de révision à fréquence fixe
  • exécuter un flux de travail piloté par un skill qui utilise des plugins, comme vérifier le statut d’une PR et traiter les nouveaux commentaires
  • poursuivre une discussion de recherche ou de triage en cours sans perdre son contexte

Utilisez une tâche planifiée autonome lorsque chaque exécution doit être indépendante ou lorsque les résultats doivent apparaître sous forme d’exécutions distinctes dans Planifié.

Lorsque vous planifiez une tâche dans un chat, rendez le prompt durable. Il doit décrire ce que ChatGPT doit faire à chaque exécution planifiée, comment déterminer s’il existe un élément important à signaler et quand s’arrêter ou vous demander des précisions.

Tester les tâches planifiées

Avant de planifier une tâche, testez d’abord manuellement le prompt dans un chat standard. Cela vous permet de confirmer les points suivants :

  • Le prompt est clair et son périmètre est correctement défini.
  • Le modèle sélectionné ou par défaut, l’effort de raisonnement et les outils fonctionnent comme prévu.
  • Le résultat produit peut être facilement examiné.

Lorsque vous commencez à planifier des exécutions, examinez les premiers résultats et ajustez le prompt ou la fréquence selon les besoins.

Dans l’application de bureau ChatGPT, vous pouvez déclencher explicitement un skill dans le prompt d’une tâche planifiée en utilisant $skill-name.

Nettoyage des worktrees pour les tâches planifiées

Si vous choisissez d’utiliser des worktrees pour les dépôts Git, des planifications fréquentes peuvent créer de nombreux worktrees au fil du temps. Archivez les exécutions planifiées dont vous n’avez plus besoin et évitez d’épingler des exécutions, sauf si vous souhaitez conserver leurs worktrees.

Modèle d’autorisations et de sécurité

Les tâches planifiées s’exécutent sans surveillance et utilisent vos paramètres de sandbox par défaut.

Pour une explication accessible de ces limites, consultez la présentation du sandboxing. Pour les règles relatives au système de fichiers et au réseau, consultez Autorisations.

  • Si votre mode de sandbox est read-only, les appels d’outils échouent s’ils nécessitent de modifier des fichiers, d’accéder au réseau ou d’interagir avec des applications sur votre ordinateur. Envisagez de définir les paramètres du bac à sable sur workspace write.
  • Si votre mode de sandbox est workspace-write, les appels d’outils échouent s’ils nécessitent de modifier des fichiers en dehors de l’espace de travail, d’accéder au réseau ou d’interagir avec des applications sur votre ordinateur. Vous pouvez autoriser de manière sélective l’exécution de commandes en dehors du sandbox à l’aide de règles.
  • Si votre mode de sandbox est full access, les tâches planifiées en arrière-plan présentent un risque accru, car ChatGPT peut modifier des fichiers, exécuter des commandes et accéder au réseau sans demander d’autorisation. Envisagez de définir les paramètres du bac à sable sur workspace write et d’utiliser des règles pour définir de manière sélective les commandes que l’agent peut exécuter avec un accès complet.

Si vous utilisez un environnement géré, les administrateurs peuvent limiter ces comportements au moyen d’exigences imposées par l’administration. Ils peuvent, par exemple, interdire approval_policy = "never" ou restreindre les modes de sandbox autorisés. Consultez Exigences imposées par l’administration (requirements.toml).

Les tâches planifiées utilisent approval_policy = "never" lorsque la politique de votre organisation l’autorise. Si les exigences de l’administrateur interdisent approval_policy = "never", les tâches planifiées adoptent le comportement d’approbation du mode d’autorisation sélectionné.

Exemples

Créer automatiquement de nouveaux skills

Scan all of the `~/.codex/sessions` files from the past day and if there have been any issues using particular skills, update the skills to be more helpful. Personal skills only, no repo skills.

If there’s anything we’ve been doing often and struggle with that we should save as a skill to speed up future work, let’s do it.

Definitely don't feel like you need to update any- only if there's a good reason!

Let me know if you make any.

Restez à jour sur votre projet

Look at the latest remote origin/master or origin/main . Then produce an exec briefing for the last 24 hours of commits that touch <DIRECTORY>

Formatting + structure:

- Use rich Markdown (H1 workstream sections, italics for the subtitle, horizontal rules as needed).
- Preamble can read something like “Here’s the last 24h brief for <directory>:”
- Subtitle should read: “Narrative walkthrough with owners; grouped by workstream.”
- Group by workstream rather than listing each commit. Workstream titles should be H1.
- Write a short narrative per workstream that explains the changes in plain language.
- Use bullet points and bolding when it makes things more readable
- Feel free to make bullets per person, but bold their name

Content requirements:

- Include PR links inline (e.g., [#123](...)) without a “PRs:” label.
- Do NOT include commit hashes or a “Key commits” section.
- It’s fine if multiple PRs appear under one workstream, but avoid per‑commit bullet lists.

Scope rules:

- Only include changes within the current cwd (or main checkout equivalent)
- Only include the last 24h of commits.
- Use `gh` to fetch PR titles and descriptions if it helps.
  Also feel free to pull PR reviews and comments

Combinez les tâches planifiées et les skills pour corriger vos propres bugs

Créez un nouveau skill qui tente de corriger un bug introduit par vos propres commits en créant un nouveau fichier $recent-code-bugfix, puis stockez-le dans vos skills personnels.

---
name: recent-code-bugfix
description: Find and fix a bug introduced by the current author within the last week in the current working directory. Use when a user wants a proactive bugfix from their recent changes, when the prompt is empty, or when asked to triage/fix issues caused by their recent commits. Root cause must map directly to the author’s own changes.
---

# Recent Code Bugfix

## Overview

Find a bug introduced by the current author in the last week, implement a fix, and verify it when possible. Operate in the current working directory, assume the code is local, and ensure the root cause is tied directly to the author’s own edits.

## Workflow

### 1) Establish the recent-change scope

Use Git to identify the author and changed files from the last week.

- Determine the author from `git config user.name`/`user.email`. If unavailable, use the current user’s name from the environment or ask once.
- Use `git log --since=1.week --author=<author>` to list recent commits and files. Focus on files touched by those commits.
- If the user’s prompt is empty, proceed directly with this default scope.

### 2) Find a concrete failure tied to recent changes

Prioritize defects that are directly attributable to the author’s edits.

- Look for recent failures (tests, lint, runtime errors) if logs or CI outputs are available locally.
- If no failures are provided, run the smallest relevant verification (single test, file-level lint, or targeted repro) that touches the edited files.
- Confirm the root cause is directly connected to the author’s changes, not unrelated legacy issues. If only unrelated failures are found, stop and report that no qualifying bug was detected.

### 3) Implement the fix

Make a minimal fix that aligns with project conventions.

- Update only the files needed to resolve the issue.
- Avoid adding extra defensive checks or unrelated refactors.
- Keep changes consistent with local style and tests.

### 4) Verify

Attempt verification when possible.

- Prefer the smallest validation step (targeted test, focused lint, or direct repro command).
- If verification cannot be run, state what would be run and why it wasn’t executed.

### 5) Report

Summarize the root cause, the fix, and the verification performed. Make it explicit how the root cause ties to the author’s recent changes.

Créez ensuite une nouvelle tâche planifiée :

Check my commits from the last 24h and submit a $recent-code-bugfix.