Accueil › Codex › Automations

Codex Automations : des agents qui travaillent en arrière-plan sans intervention

Les automations Codex permettent de planifier des tâches récurrentes qui s’exécutent en arrière-plan, sans prompt manuel. Vous définissez des instructions, attachez des skills optionnelles, choisissez une fréquence, et l’agent travaille de manière autonome. Les résultats arrivent dans une file de review intégrée à l’app Codex.

Qu’est-ce qu’une automation Codex ?

Les automations transforment Codex d’un outil réactif (qui attend votre prompt) en un agent proactif (qui travaille seul sur un planning défini). Le concept est simple : vous écrivez un prompt, vous choisissez une fréquence (chaque matin, toutes les 3 heures, tous les lundis), et l’agent exécute cette tâche automatiquement en arrière-plan, sans que vous soyez au clavier.

Chez OpenAI, les équipes utilisent les automations pour le triage quotidien des issues, la détection et le résumé des échecs CI, la génération de briefs de release, la recherche proactive de bugs, et la création périodique de nouvelles skills.

La différence fondamentale avec les outils d’automatisation classiques comme n8n ou Zapier : ces plateformes exécutent des flux déterministes (les mêmes étapes à chaque fois). Les automations Codex sont pilotées par un LLM qui raisonne, s’adapte au contexte, et persiste sa mémoire entre les exécutions. L’agent se souvient de ce qu’il a trouvé lors des runs précédents et peut ajuster son comportement en conséquence.

Comment ça fonctionne

Les trois composants d’une automation

Chaque automation combine trois éléments :

Les instructions (le prompt) : ce que l’agent doit faire. Comme pour toute interaction avec Codex, plus le prompt est spécifique et bien cadré, meilleur sera le résultat. Testez toujours votre prompt manuellement dans un thread classique avant de le planifier en automation.

Les skills (optionnelles) : vous pouvez attacher une ou plusieurs skills à l’automation pour donner à Codex des workflows spécialisés. Invoquez une skill explicitement dans le prompt avec $nom-skill. Par exemple, une automation de review de code peut utiliser la skill $gh-fix-ci pour diagnostiquer les échecs CI.

La fréquence : à quelle cadence l’automation doit s’exécuter. Exemples typiques : chaque matin à 9h, toutes les 3 heures pendant les heures ouvrées, chaque lundi matin, ou après chaque push (via des triggers cloud, en développement).

Modes d’exécution

Pour les repos Git, chaque automation peut s’exécuter selon deux modes :

Mode worktree (recommandé) : l’automation s’exécute dans un worktree Git dédié, isolé de votre travail local en cours. Les modifications de l’automation ne touchent pas votre branche principale et n’interfèrent pas avec vos fichiers en cours d’édition. C’est le mode recommandé pour les automations qui modifient du code.

Mode local : l’automation travaille directement dans votre checkout principal. Utile pour les automations qui ne modifient pas de fichiers (audits read-only, analyses, génération de rapports), mais risqué si l’automation édite des fichiers que vous êtes en train de modifier.

Pour les projets non versionnés (pas de Git), les automations s’exécutent directement dans le répertoire du projet.

La file de review (Triage)

Quand une automation termine son exécution, les résultats apparaissent dans la section Triage de la sidebar de l’app Codex. Cette section fonctionne comme une inbox :

Les runs avec des findings (résultats notables) apparaissent comme non lus. Les runs sans résultat significatif sont automatiquement archivés. Vous pouvez filtrer l’inbox pour afficher toutes les runs ou uniquement les non lues. Depuis la file de review, vous pouvez continuer à travailler sur les résultats de l’automation, demander des révisions, ou ouvrir une PR avec les changements proposés.

Mémoire persistante entre les runs

C’est la fonctionnalité qui distingue véritablement les automations Codex des automatisations classiques. Après chaque exécution, l’agent écrit ce qu’il a trouvé dans un fichier de mémoire. Au run suivant, il lit ce fichier avant de commencer, ce qui lui permet de :

Éviter de signaler les mêmes issues deux fois. Suivre l’évolution d’un problème au fil du temps. Détecter des tendances (par exemple, un module qui accumule les bugs). Ajuster sa stratégie en fonction de ce qu’il a appris précédemment.

Voici un exemple simplifié de ce à quoi ressemble cette mémoire après quelques exécutions :

# Automation Memory

## 2026-03-18
- 3 nouvelles issues trouvées. Tickets créés : LIN-47, LIN-48, LIN-49.
- 1 issue ignorée (doublon de LIN-44).

## 2026-03-19
- 1 nouvelle issue trouvée. Ticket créé : LIN-52.
- LIN-47 (timeout webhook) a été corrigé et mergé. Retiré de la watchlist.

## 2026-03-20
- Aucune nouvelle issue dans les modules webhook ou retry.
- Module auth signalé pour review approfondie demain :
  patterns détectés pouvant mener à une fixation de session.

L’agent accumule de l’intelligence contextuelle au fil du temps, ce qui rend chaque exécution plus pertinente que la précédente.

Exemples d’automations concrètes

Triage quotidien des issues

L’automation la plus courante chez OpenAI : chaque matin, l’agent parcourt les nouvelles issues GitHub ou Linear, les catégorise (bug, feature request, question), estime la priorité, et assigne les labels appropriés. Il peut aussi créer des tickets dans votre outil de gestion de projet si nécessaire.

Prompt type :

Parcourir les issues GitHub ouvertes depuis la dernière exécution sur
mon-org/mon-repo. Pour chaque nouvelle issue :
1) Catégoriser en bug / feature / question / documentation
2) Estimer la priorité (P0-P3) selon l'impact décrit
3) Ajouter les labels correspondants
4) Si c'est un bug P0 ou P1, créer un résumé dans la section Triage
Si aucune nouvelle issue, archiver silencieusement cette run.

Monitoring CI/CD

L’agent surveille les pipelines CI en continu. Quand un build échoue, il analyse les logs, identifie la cause probable, et peut même proposer un correctif en utilisant la skill $gh-fix-ci :

$gh-fix-ci Vérifier les derniers workflows GitHub Actions sur
mon-org/mon-repo. Si un check est en échec sur la branche main :
1) Analyser les logs d'erreur
2) Identifier la cause racine
3) Si c'est un test flaky, le documenter
4) Si c'est un vrai bug, proposer un correctif dans un worktree
5) Résumer les findings dans le Triage

Review de code automatique

Planifiez une review quotidienne des PRs ouvertes. L’agent examine les diffs, vérifie la conformité avec vos conventions (via AGENTS.md), et signale les problèmes potentiels :

Parcourir les PRs ouvertes sur mon-org/mon-repo.
Pour chaque PR non encore reviewée par cette automation :
1) Lire le diff complet
2) Vérifier la conformité avec les conventions AGENTS.md
3) Identifier les risques de sécurité, de performance, ou de breaking change
4) Poster un commentaire de review sur la PR avec les findings
5) Si tout est OK, laisser un commentaire "LGTM - automated review"

Scan de sécurité périodique

L’agent vérifie régulièrement les dépendances pour des vulnérabilités connues et peut proposer des mises à jour :

Vérifier les dépendances du projet pour des vulnérabilités connues :
1) Exécuter npm audit (ou pip-audit, cargo audit selon le projet)
2) Pour chaque vulnérabilité high ou critical, évaluer l'impact
3) Si un fix existe, créer un worktree avec la mise à jour
4) Générer un résumé avec la liste des vulnérabilités et les actions prises
Fréquence : quotidienne, 6h du matin

Création automatique de skills

Une automation méta : l’agent analyse les sessions récentes de Codex pour identifier les tâches répétitives et crée automatiquement des skills pour les automatiser à l’avenir :

Scanner les fichiers de sessions Codex des dernières 24h
(~/.codex/sessions). Si des patterns répétitifs sont détectés
(mêmes types de tâches demandées plusieurs fois) :
1) Identifier les workflows candidats à une skill
2) Créer une skill avec $skill-creator
3) Résumer les nouvelles skills créées dans le Triage

Brief de release quotidien

Chaque matin, l’agent génère un résumé des changements mergés la veille, des issues fermées, et de l’état de la prochaine release :

Générer un brief de release quotidien :
1) Lister les PRs mergées hier sur main
2) Résumer les changements en 2-3 phrases par PR
3) Lister les issues fermées et leur résolution
4) Vérifier si des migrations sont nécessaires
5) Indiquer l'état de la branche release (stable / instable)
Poster le résumé dans le Triage.

Configuration et paramètres

Créer une automation

Les automations se créent et se gèrent dans l’app Codex desktop. Dans la sidebar, accédez à la section Automations pour créer, éditer, ou supprimer des automations. L’interface permet de :

Définir le prompt d’instructions. Attacher des skills. Choisir la fréquence d’exécution. Sélectionner le mode (worktree ou local). Choisir le modèle et le niveau de raisonnement. Utiliser des templates d’automations pré-configurées pour trouver l’inspiration.

La même automation peut s’exécuter sur plusieurs projets simultanément.

Sandbox et sécurité

Les automations utilisent vos paramètres sandbox par défaut. Attention aux implications :

En mode read-only : les appels d’outils qui modifient des fichiers, accèdent au réseau, ou interagissent avec des apps sur votre machine échoueront. Utile pour les automations d’audit pure.

En mode workspace-write : l’agent peut modifier les fichiers du workspace. C’est le mode recommandé pour les automations qui créent des worktrees ou des correctifs.

En mode full access : l’agent peut modifier des fichiers, exécuter des commandes, et accéder au réseau sans demander. C’est le mode le plus risqué pour les automations en arrière-plan car il n’y a personne pour superviser.

Les automations utilisent approval_policy = "never" quand votre politique organisationnelle le permet. Si votre admin a restreint cette option via requirements.toml, les automations se rabattent sur le comportement d’approbation du mode sélectionné.

Choix du modèle

Vous pouvez définir le modèle et le niveau de raisonnement par automation. Pour les tâches simples et fréquentes (vérification de statut, triage basique), GPT-5.4 mini avec un raisonnement « low » est économique et suffisant. Pour les analyses complexes (review de code, audit de sécurité), GPT-5.4 ou GPT-5.3-Codex avec un raisonnement « medium » ou « high » donne de meilleurs résultats.

Surveillez la consommation de vos quotas : chaque run d’automation consomme des crédits de votre abonnement ChatGPT. Des automations fréquentes avec un modèle puissant peuvent atteindre vos limites rapidement.

Bonnes pratiques

Toujours tester le prompt manuellement d’abord

Avant de planifier une automation, exécutez le prompt dans un thread Codex classique. Vérifiez que le prompt est clair et bien cadré, que le modèle et le niveau de raisonnement produisent les résultats attendus, et que le diff résultant est reviewable. Ne planifiez qu’après avoir validé que le prompt fonctionne de manière fiable.

Reviewer les premières exécutions

Examinez attentivement les résultats des 3 à 5 premières exécutions d’une nouvelle automation. Ajustez le prompt ou la cadence en fonction des résultats observés. Une automation mal calibrée qui tourne en boucle sans supervision peut créer du bruit (faux positifs dans le Triage) ou consommer des crédits inutilement.

Utiliser des skills pour la maintenabilité

Plutôt que de tout mettre dans le prompt de l’automation, déportez la logique complexe dans des skills. Une automation qui appelle $ma-skill-de-review est plus facile à maintenir et à partager qu’une automation avec un prompt de 50 lignes. Les skills peuvent aussi être testées indépendamment.

Garder un scope étroit

Les automations les plus efficaces font une seule chose bien. « Trier les issues » est mieux que « Trier les issues, reviewer les PRs, vérifier la CI, et mettre à jour la documentation ». Créez des automations séparées pour chaque tâche, avec des fréquences adaptées à chacune.

Limites actuelles et roadmap

En mars 2026, les automations s’exécutent uniquement quand l’app Codex est ouverte sur votre machine. OpenAI a annoncé travailler sur des triggers cloud qui permettront à Codex de tourner en continu en arrière-plan, même quand votre ordinateur est éteint. Cette fonctionnalité n’est pas encore disponible.

Les automations ne sont actuellement disponibles que dans l’app desktop, pas dans la CLI ou l’extension IDE. Pour des automatisations depuis la CLI (par exemple dans un pipeline CI/CD), utilisez codex exec avec des cron jobs système ou des GitHub Actions.

Il n’existe pas encore de marketplace ou de bibliothèque partagée de templates d’automations. Les templates disponibles sont ceux intégrés à l’app. Pour partager des automations entre membres d’équipe, partagez les prompts et les skills associées via votre repo.

Automations Codex vs alternatives

Notre verdict : les automations Codex sont le meilleur choix pour les workflows centrés sur le code et les repos (triage, review, CI/CD, refactoring). OpenClaw est plus polyvalent pour les automations de vie quotidienne et DevOps au-delà du code. n8n et Zapier restent imbattables pour les chaînes d’intégration entre services SaaS. Ces outils sont complémentaires, pas concurrents.