Codex Automations pour les tâches longues: déclencheurs planifiés, heartbeats et travail sur plusieurs jours

Si vous confiez à Codex les vérifications répétitives, le suivi de PR, les relances après déploiement ou la triage sur plusieurs jours, la première question n’est pas de savoir si l’automatisation est possible. C’est plutôt de savoir quel type de tâche mérite d’être automatisé et comment. Les Automations ne transforment pas Codex en agent de fond toujours actif. Elles le font revenir au bon moment, dans la bonne limite, pour exécuter une seule chose bien définie.

1. Juger d’abord si la tâche doit être automatisée

1.1 standalone/project automation: tâches de fond indépendantes

Standalone automation et project automation sont toutes deux des tâches de fond indépendantes. La différence tient au périmètre. Standalone n’est pas liée à un projet précis; project automation est liée à un chemin de projet, ce qui la rend plus adaptée au travail récurrent autour d’un dépôt fixe.

Chaque déclenchement lance une exécution neuve. Une fois terminée, le résultat va dans inbox ou triage; s’il n’y a rien de nouveau, il peut être archivé automatiquement. Les cas d’usage typiques sont les vérifications hebdomadaires de dépendances, la triage quotidienne des issues et les contrôles planifiés après déploiement.

La contrainte principale est l’environnement local: la machine qui exécute Codex doit rester allumée, l’application doit continuer à tourner, et le chemin du projet doit toujours exister. Si la machine se met en veille, s’éteint ou si l’app se ferme, rien ne continue. Ce n’est pas la bonne couche pour de l’hébergement de fond sans surveillance.

1.2 thread automation (heartbeat): réveils périodiques sur le même fil

Thread automation est un réveil périodique de type heartbeat attaché au fil de conversation courant. L’idée centrale est de préserver le contexte: à chaque réveil, la même conversation continue au lieu de créer une nouvelle exécution indépendante.

C’est un bon choix pour les contrôles de logs après déploiement, le suivi sur plusieurs jours et la triage continue. Par exemple, vous pouvez demander à Codex de vérifier les logs de déploiement toutes les 10 minutes, de signaler uniquement en cas d’erreur ou de réussite, et de rester silencieux sinon. Ce type de travail a besoin de continuité de contexte, donc standalone automation est un mauvais choix.

Le heartbeat n’est ni un daemon permanent ni une boucle infinie. C’est un rythme du type réveil -> vérification -> rapport -> attente. Si l’app se met en pause ou se ferme, le heartbeat s’arrête aussi.

1.3 Tableau comparatif

Dimension	standalone/project automation	thread automation (heartbeat)
Emplacement d’exécution	Thread de fond indépendant	Fil de conversation courant
Conservation du contexte	Nouveau contexte à chaque exécution	Le contexte de la session courante est conservé
Cas d’usage adaptés	Tâches répétitives indépendantes, triage des issues, contrôles de dépendances	Suivi des tâches longues, triage continu, vérification de logs de déploiement, travail sur plusieurs jours
Dépendances	L’app locale / la machine / le chemin du projet doivent exister	Le fil courant doit rester attaché
Surface de résultat	inbox / triage, archivage automatique lorsqu’il n’y a rien	Fenêtre de conversation courante
Mécanisme d’arrêt	Désactiver l’automatisation	Mettre l’app en pause ou la fermer

La décision est simple: la tâche doit-elle garder le contexte ? Si oui, utilisez thread automation. Est-elle liée à un projet précis ? Si oui, utilisez project automation; sinon, standalone automation.

2. Quels types de tâches conviennent aux Automations ?

Toutes les tâches répétitives ne méritent pas Automations. Il faut d’abord regarder la forme de la tâche.

2.1 Caractéristiques des tâches adaptées

Les tâches adaptées aux Automations partagent généralement trois caractéristiques: répétition élevée, règles claires et sortie vérifiable.

Une tâche très répétitive revient sur un rythme fixe et vise à peu près le même résultat à chaque fois. Les contrôles hebdomadaires de dépendances, la triage quotidienne des issues et les vérifications fixes après déploiement en sont de bons exemples. Le périmètre d’inspection, les critères de décision et le format de sortie peuvent être définis à l’avance.

Les tâches fondées sur des règles se transforment très bien en prompt. Par exemple: “Vérifie les versions dans package.json, liste les paquets qui ont de nouvelles versions et recommande un ordre de mise à jour.” Les critères de jugement restent stables, donc pas besoin de les répéter manuellement à chaque fois.

La sortie vérifiable compte aussi. Une bonne automatisation doit revenir dans inbox / triage, s’archiver toute seule lorsqu’il n’y a rien à faire, et montrer clairement la prochaine étape lorsqu’elle trouve quelque chose. C’est ainsi qu’on voit qu’elle fait gagner du temps au lieu de déplacer le bruit ailleurs.

2.2 Caractéristiques des tâches qui ne conviennent pas

Les tâches qui ne conviennent pas aux Automations ont généralement quatre caractéristiques: elles exigent un jugement humain fréquent, elles dépendent d’un état externe qui change vite, le prompt n’est pas encore stable, ou elles ont besoin d’un hébergement sans surveillance sur le long terme.

Les tâches qui demandent souvent un jugement humain ont des frontières floues. Les décisions d’architecture, les chasses aux bugs complexes et les arbitrages de situation demandent tous une adaptation au cas par cas, donc ils s’accommodent mal d’une automatisation figée.

Les tâches dépendantes d’un état externe qui évolue vite demandent aussi prudence. Le suivi en temps réel d’un service de production, par exemple, change trop vite et relève plutôt d’outils de monitoring spécialisés que d’Automations.

N’automatisez pas non plus un prompt qui n’a pas encore fait ses preuves. Faites-le tourner manuellement quelques fois, stabilisez les règles, le périmètre et la sortie, puis seulement ensuite transformez-le en automatisation.

L’hébergement sans surveillance à long terme n’est pas la bonne couche pour une project-scoped automation. Elle dépend de l’app locale, de la machine et du chemin du projet. Si la machine disparaît, l’automatisation s’arrête. Ce n’est pas une solution d’hébergement cloud.

2.3 Tableau d’adéquation

Type de tâche	Adaptée ?	Pourquoi	Approche recommandée
Vérifications hebdomadaires de dépendances	Oui	Répétitif, fondé sur des règles, vérifiable	standalone automation ou project automation
Triage quotidien des issues	Oui	Peut aller dans inbox, peut être archivé automatiquement, prompt stable	standalone automation ou thread heartbeat
Vérification des logs après déploiement	Oui	Même fil de conversation, le contexte doit rester présent	thread automation
Décisions d’architecture	Non	Jugement humain fréquent, frontières floues	conversation manuelle
Chasse aux bugs complexes	Non	Adaptation au cas par cas nécessaire	conversation manuelle
Monitoring en temps réel	Non	L’état externe change trop vite	outils de monitoring spécialisés
Hébergement sans surveillance à long terme	Non	La project-scoped automation dépend de l’environnement local	approche CI ou cloud
Flux d’automatisation non éprouvés	Non	Prompt instable, exécutions manuelles incohérentes	stabiliser manuellement d’abord

Le flux de décision est simple: vérifiez d’abord que le prompt est stable, puis demandez-vous si la tâche doit garder le contexte, et enfin si un hébergement cloud durable est vraiment nécessaire.

3. Créer votre première standalone/project automation

3.1 Flux de création

1. Décrivez d’abord la tâche clairement. Définissez le périmètre, l’entrée, la sortie, les critères de réussite et les conditions d’arrêt.
2. Choisissez le type d’automatisation. Le travail répétitif indépendant va dans standalone; le travail répétitif autour d’un dépôt fixe va dans project automation.
3. Choisissez l’emplacement d’exécution. Dans un dépôt Git, commencez par un worktree pour ne pas perturber l’espace de travail courant.
4. Définissez la fréquence. Les tâches à la minute doivent avoir des conditions d’arrêt explicites pour ne pas réveiller indéfiniment.
5. Faites d’abord quelques cycles de test. Quand la sortie est stable, passez à la fréquence réelle.

3.2 Comment choisir entre worktree et local project

Emplacement d’exécution	Isolation	Cas adaptés	Risque
worktree	Les changements sont isolés du répertoire de travail courant	Tâches qui modifient des fichiers, écrivent du code ou proposent des PR	Les erreurs restent généralement dans le worktree et se jettent facilement
local project	Pas d’isolation; exécution directe dans le répertoire courant	Vérifications en lecture seule, génération de rapports, triage	Peut affecter les fichiers que vous êtes en train d’éditer

Dans un dépôt Git, les tâches de modification doivent démarrer dans un worktree. N’utilisez local project que lorsque la tâche est explicitement en lecture seule, en inspection ou en confirmation.

4. Créer une thread automation (heartbeat)

4.1 Flux de création

1. Vérifiez d’abord que le fil courant gère déjà une tâche longue.
2. Attachez ensuite la thread automation à ce fil.
3. Écrivez précisément ce qu’il doit vérifier à chaque réveil, quand il doit rapporter et quand il doit rester silencieux.
4. Définissez les conditions d’arrêt: succès, échec, timeout ou nombre maximal de cycles.
5. Commencez avec une fréquence basse et vérifiez qu’il ne spamme pas avant de passer au rythme final.

4.2 Exemple de prompt heartbeat

Vérifie les logs de déploiement toutes les 10 minutes et ne rapporte que dans les cas suivants:

1. Un signal d'erreur apparaît (contient "error", "failed" ou "exception")
2. Un signal de réussite apparaît (contient "deployed", "success" ou "completed")
3. La tâche n'est toujours pas terminée après 30 minutes

Format du rapport:
- Status: [in progress / success / failure]
- Extrait de log clé: [jusqu'à 3 lignes]
- Prochaine étape: [s'il y en a une]

Reste silencieux quand rien ne change.

Ce prompt rend explicites le périmètre de vérification, la frontière de sortie et les conditions d’arrêt. Il n’a pas besoin de répéter “vérification terminée” à chaque réveil et ne doit pas transformer l’absence de changement en bruit.

5. Sécurité: sandbox, approval policy et gouvernance d’équipe

5.1 Paramètres de sandbox et d’approval policy

Les Automations tournent par défaut dans une sandbox. La sandbox décide quels fichiers peuvent être touchés, si les limites peuvent être franchies et si une autorisation supplémentaire est nécessaire. Pour l’automatisation de fond, plus la frontière par défaut est petite, mieux c’est.

Mode sandbox	Périmètre des droits	Adapté à	Niveau de risque
read-only	Lecture seule, pas d’écriture	Tâches d’inspection et d’analyse pures	Faible
workspace-write	Lecture/écriture dans le workspace; les actions externes demandent encore une approbation	Automatisations quotidiennes, modifications de fichiers, suggestions de PR	Moyen
danger-full-access	Accès système sans restriction	Environnements isolés ou tâches très fiables	Élevé

L’approval policy détermine si l’agent doit demander une autorisation lorsqu’il rencontre une action plus risquée.

approval policy	Comportement	Cas d’usage
on-request	Demande des droits plus élevés si nécessaire	Un peu d’autonomie, mais avec revue humaine
never	Exécute tout automatiquement, sans demander	Scripts d’automatisation ou environnements non interactifs

La valeur par défaut devrait être workspace-write + rules/allowlist, pas full access + unattended. La seconde option est tout simplement trop large quand quelque chose tourne mal.

5.2 Conseil de gouvernance d’équipe

Les équipes peuvent figer sandbox et approval dans requirements.toml pour éviter d’accorder trop de droits par défaut.

[agent]
approval_policy = "never"
sandbox = "workspace-write"

Le but n’est pas de tout bloquer. Le but est de garder le périmètre par défaut étroit et de l’élargir seulement quand la tâche en a vraiment besoin.

6. Trois modèles d’automatisation prêts à l’emploi

6.1 Revue hebdomadaire des dépendances

• Fréquence de déclenchement: une fois par semaine
• Emplacement d’exécution: worktree à privilégier dans les dépôts Git
• Sortie réussie: liste des dépendances à mettre à jour et priorités suggérées
• Condition d’arrêt: s’il n’y a rien à mettre à jour, limitez-vous à un résultat bref
• Périmètre des droits: lecture seule ou rédaction légère de rapport

6.2 Suivi heartbeat après déploiement

• Fréquence de déclenchement: toutes les 10 minutes, jusqu’à 30 minutes
• Emplacement d’exécution: thread automation
• Sortie réussie: résumé bref du succès, de l’échec ou du timeout
• Condition d’arrêt: signal de réussite, signal d’échec ou timeout
• Périmètre des droits: lire les logs seulement, ne pas toucher à la production

6.3 Triage quotidien des issues / PR

• Fréquence de déclenchement: une fois par jour
• Emplacement d’exécution: standalone automation ou thread heartbeat
• Sortie réussie: envoyer dans inbox ce qui demande une attention humaine
• Condition d’arrêt: rester silencieux quand il n’y a rien de nouveau
• Périmètre des droits: par défaut workspace-write; éviter l’accès total

7. Si l’automatisation échoue, vérifiez d’abord ces 6 points

1. L’app Codex tourne-t-elle encore, et la machine est-elle réveillée ?
2. Le chemin du projet existe-t-il toujours, ou le worktree a-t-il été déplacé ou supprimé ?
3. La sandbox bloque-t-elle une écriture ou une action réseau ?
4. La thread automation a-t-elle réellement besoin de conserver le contexte ?
5. Le worktree s’est-il trop accumulé et doit-il être nettoyé ?
6. Le prompt dit-il clairement quand arrêter et quand rapporter ?

8. Checklist FAQ

8.1 Automations est-il une tâche planifiée ou un agent qui tourne en continu ?

C’est plutôt une tâche de fond planifiée ou réveillée périodiquement. À chaque réveil, elle vérifie, agit, rapporte, puis revient en attente. Ce n’est pas une boucle infinie.

8.2 Quelle est la différence entre standalone/project et thread automation ?

Standalone/project automation est une exécution de fond indépendante qui repart à zéro à chaque fois, et son résultat va dans inbox / triage. Thread automation est un heartbeat sur le même fil et conserve le contexte de la conversation courante.

8.3 Quelles tâches conviennent aux Automations, et lesquelles non ?

Les bons cas sont répétitifs, fondés sur des règles et vérifiables. Les mauvais cas sont les tâches qui exigent un jugement humain fréquent, dépendent d’un état externe qui change vite ou reposent sur un prompt instable.

8.4 Comment choisir entre worktree et local project ?

Pour tout ce qui peut modifier des fichiers, privilégiez worktree. Utilisez local project seulement pour des vérifications en lecture et des tâches de type rapport.

8.5 Est-ce que ça continue si l’app se ferme ou si l’ordinateur dort ?

Non. L’automatisation liée au projet dépend de l’application locale, de la machine et du chemin du projet. Si l’app se ferme ou si la machine dort, cela s’arrête.

8.6 Quand faut-il utiliser Computer Use ?

Uniquement lorsqu’il faut manipuler directement une interface graphique et qu’il n’existe ni API ni interface web. Si du code normal suffit, Computer Use n’en vaut généralement pas la peine.

8.7 Comment contrôler le coût et la fréquence ?

Gardez la fréquence au niveau nécessaire, vérifiez l’état avec /status, définissez des conditions d’arrêt pour chaque automatisation et évitez le polling trop serré.

9. Résumé

Computer Use, le navigateur intégré et Automations résolvent des couches différentes du même problème. Automations servent à confier à Codex, en arrière-plan, un travail stable, vérifiable et répétitif; thread automation sert au suivi des tâches longues sur plusieurs jours; worktree et sandbox servent à garder le risque sous contrôle.

L’ordre le plus sûr est toujours le même: d’abord juger si la tâche doit être automatisée, puis choisir l’emplacement d’exécution et les droits, et seulement ensuite régler la fréquence. Stabilisez d’abord le processus humain, puis laissez Codex le faire tourner un peu plus longtemps.