For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale

Suggestions

Flux de travail

Capacités

Référence

API Dashboard
Essayer ChatGPT

Tâches planifiées

Exécutez des tâches à des horaires définis ou en réponse à des événements d’applications pris en charge dans ChatGPT

Planifiez des tâches récurrentes à exécuter en arrière-plan. Dans ChatGPT sur le web et sur mobile, les forfaits éligibles permettent aussi d’exécuter des tâches en réponse à des événements d’applications pris en charge. Consultez les tâches actives, en pause et terminées ainsi que 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 sera retiré de ChatGPT, ChatGPT Work et Codex pour tous les forfaits le 14 octobre 2026. Examinez les tâches planifiées qui utilisent GPT-5.5 et choisissez un modèle de remplacement disponible avant cette date. Pour Codex avec connexion via ChatGPT, remplacez gpt-5.5 par gpt-5.6-sol (GPT-5.6 Sol). L’API OpenAI n’est pas concernée. Consultez la page Retrait de GPT-5.5.

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

Par exemple, planifiez une tâche pour analyser les erreurs de télémétrie et soumettre des correctifs, ou pour créer des rapports sur les modifications récentes du code source. Pour un travail en cours qui doit continuer à utiliser le même contexte, planifiez une tâche dans une discussion existante.

Pour les tâches planifiées limitées à un projet, laissez l’ordinateur allumé et l’application de bureau ChatGPT en cours d’exécution. Le projet sélectionné doit toujours être disponible sur le disque au moment prévu pour l’exécution de la tâche.

Dans les dépôts Git, vous pouvez choisir d’exécuter une tâche planifiée dans votre projet local ou dans un nouvel arbre de travail. Dans les deux cas, l’exécution se fait en arrière-plan. Les arbres de travail isolent les modifications des tâches planifiées du travail local en cours, tandis qu’une exécution dans votre projet local peut modifier des fichiers sur lesquels vous êtes encore en train de travailler. Dans les projets sans gestion de versions, les tâches planifiées s’exécutent directement dans le répertoire du projet.

Vous pouvez aussi conserver les paramètres par défaut du modèle et de l’effort de raisonnement, ou les choisir explicitement pour mieux contrôler l’exécution de la tâche planifiée.

Si une tâche planifiée utilise gpt-5.4 ou gpt-5.4-mini avec une connexion via ChatGPT, mettez-la à jour avant le retrait de ces modèles le 31 août 2026. Remplacez gpt-5.4 par gpt-5.6-terra et gpt-5.4-mini par gpt-5.6-luna.

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. Comprenez le fonctionnement du bac à sable.

Gérez les tâches planifiées

Retrouvez toutes les tâches planifiées et leurs exécutions dans Planifiées , 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 ayant des résultats à signaler y apparaissent, et un indicateur de contenu non lu signale qu’une exécution nécessite votre attention.

Les tâches planifiées autonomes démarrent une nouvelle discussion à chaque exécution prévue et affichent leurs résultats dans Planifiées. Utilisez-les si chaque exécution doit être indépendante ou si une même 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 la 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 arbre de travail dédié en arrière-plan. Utilisez des arbres de travail pour isoler les modifications des tâches planifiées du travail local en cours. Utilisez le mode local pour que la tâche planifiée travaille directement dans votre copie de travail principale, en gardant à l’esprit qu’elle peut modifier les fichiers que vous êtes en train d’éditer. Dans les projets sans gestion de versions, les tâches planifiées s’exécutent directement dans le répertoire du projet. Vous pouvez faire exécuter une 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. Elles peuvent aussi utiliser des skills. Pour faciliter la maintenance des tâches planifiées et leur partage entre équipes, utilisez des skills pour définir l’action et fournir les outils et le contexte. Sélectionnez ou invoquez une skill précise dans le prompt de la tâche lorsque le workflow ne doit pas dépendre de la sélection automatique des outils.

Demandez à 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 discussion ChatGPT ou Codex. Décrivez le travail à effectuer, le moment où il doit s’exécuter et précisez si chaque exécution doit revenir dans la discussion en cours ou en démarrer 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.

Par exemple, demandez à ChatGPT de planifier un suivi depuis la discussion en cours en attendant qu’un déploiement se termine, ou de créer une tâche planifiée autonome qui vérifie un projet à intervalles réguliers.

Les skills peuvent aussi créer ou mettre à jour des tâches planifiées. Par exemple, une skill de suivi d’une pull request pourrait configurer une tâche planifiée qui vérifie l’état de la PR avec le plugin GitHub et apporte les corrections demandées dans les nouveaux retours de revue.

Planifiez une tâche dans une discussion

Planifiez une tâche dans une discussion existante lorsque vous souhaitez que ChatGPT y revienne à des moments définis. La tâche planifiée utilise le contexte existant de la discussion au lieu de repartir d’un nouveau prompt à chaque fois.

Les tâches planifiées dans une discussion peuvent utiliser des intervalles en minutes pour assurer un suivi rapproché, ou des planifications quotidiennes et hebdomadaires lorsque vous avez besoin d’un point à une heure précise.

Planifiez une tâche dans une discussion pour :

  • vérifier une opération de longue durée jusqu’à ce qu’elle se termine
  • consulter une source connectée à intervalles réguliers lorsque vous avez besoin d’un état des lieux périodique plutôt que d’une réponse à un événement d’application pris en charge
  • rappeler à ChatGPT de poursuivre un cycle de revue à intervalles réguliers
  • exécuter un workflow piloté par une skill qui utilise des plugins, par exemple pour vérifier l’état d’une PR et traiter les nouveaux retours
  • 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 dans des exécutions distinctes dans Planifiées.

Lorsque vous planifiez une tâche dans une discussion, rédigez un prompt qui reste valable dans le temps. Il doit décrire ce que ChatGPT doit faire à chaque exécution prévue, comment déterminer s’il y a un élément important à signaler et quand s’arrêter ou vous demander des précisions.

Testez les tâches planifiées

Avant de planifier une tâche, testez d’abord le prompt manuellement dans une discussion ordinaire. Vous pourrez ainsi vérifier les points suivants :

  • Le prompt est clair et son périmètre est bien défini.
  • Le modèle, l’effort de raisonnement et les outils, qu’ils soient sélectionnés explicitement ou utilisés par défaut, se comportent comme prévu.
  • Le résultat produit peut être 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 une skill dans le prompt d’une tâche planifiée en utilisant $skill-name.

Nettoyage des arbres de travail des tâches planifiées

Si vous choisissez des arbres de travail pour les dépôts Git, des exécutions fréquentes peuvent créer de nombreux arbres de travail 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 arbres de travail.

Autorisations et modèle de sécurité

Les tâches planifiées s’exécutent sans supervision et utilisent vos paramètres de bac à sable par défaut.

Pour une explication simple de ces limites, consultez la vue d’ensemble du bac à sable. Pour les règles relatives au système de fichiers et au réseau, consultez Autorisations.

  • Si votre bac à sable est en lecture seule, les appels d’outils échouent s’ils nécessitent de modifier des fichiers, d’accéder au réseau ou d’utiliser des applications sur votre ordinateur. Envisagez de régler les paramètres du bac à sable sur Écriture dans l’espace de travail.
  • Si votre bac à sable est en mode 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’utiliser des applications sur votre ordinateur. Vous pouvez autoriser certaines commandes à s’exécuter en dehors du bac à sable à l’aide de règles.
  • Si votre bac à sable est en mode accès complet, les tâches planifiées en arrière-plan présentent un risque élevé, car ChatGPT peut modifier des fichiers, exécuter des commandes et accéder au réseau sans vous le demander. Envisagez de régler les paramètres du bac à sable sur Écriture dans l’espace de travail et d’utiliser des règles pour définir précisément les commandes que l’agent peut exécuter avec un accès complet.

Si vous utilisez un environnement géré, les administrateurs peuvent restreindre ces comportements à l’aide d’exigences qu’ils imposent. Par exemple, ils peuvent interdire approval_policy = "never" ou limiter les modes de bac à sable autorisés. Consultez Exigences imposées par les administrateurs (requirements.toml).

Les tâches planifiées utilisent approval_policy = "never" lorsque la politique de votre organisation le permet. Si les exigences des administrateurs interdisent approval_policy = "never", les tâches planifiées appliquent alors le comportement d’approbation du mode d’autorisation sélectionné.

Exemples

Créez 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.

Suivez l’évolution de 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 tâches planifiées et skills pour corriger vos propres bugs

Créez un nouveau skill $recent-code-bugfix qui tente de corriger un bug introduit par vos propres commits et enregistrez-le parmi 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.