Automatisation et intégration continue (CI/CD) : faire travailler Codex en arrière-plan
📚 Navigation dans la série : Le chapitre précédent [26 · Intégration Git et GitHub] présentait le déclenchement de relectures de code sur GitHub. Ce chapitre détaille le passage à l'exécution autonome (sans supervision humaine) : comment configurer Codex au sein d'une chaîne GitHub Actions (CI/CD) ou planifier des tâches périodiques locales (Automations) pour exécuter des revues, formater du code en cas d'erreur de build, ou générer des synthèses d'activité quotidiennes. Le chapitre suivant [28 · Exécution non interactive (codex exec)] détaillera la commande système utilisée en sous-main par ces processus d'automatisation.
On entend souvent dire : « L'intérêt principal d'un outil d'IA de codage réside dans le développement en pair programming, pour coder et interagir en direct ». Cette analyse ne couvre qu'une partie de la réalité.
Après plusieurs mois d'utilisation de Codex, je constate que son principal intérêt en matière de productivité se manifeste lorsque vous n'êtes pas devant votre écran. En mode pair programming, vous devez être présent, analyser et valider chaque modification ; l'activité s'arrête dès que vous vous absentez. Pourtant, l'activité de développement regorge de tâches répétitives, prévisibles et chronophages — auditer chaque PR entrante, analyser les pannes de CI au milieu de la nuit, ou compiler le lundi matin la liste des modifications de la semaine passée pour votre rapport d'activité. Ces tâches ont des étapes récurrentes que personne ne souhaite accomplir manuellement au quotidien.
C'est ici qu'intervient l'automatisation. Intégrer Codex au sein de vos chaînes de CI/CD ou de planifications de tâches locales transforme l'assistant : il passe d'un compagnon d'écriture à un agent d'entretien de votre dépôt de code actif en continu. Ce chapitre présente la mise en œuvre de ces deux approches : l'intégration via GitHub Actions (côté serveur CI/CD) et l'usage de la fonction d'automatisation (Automations) de l'application de bureau (côté machine locale).
À la fin de ce chapitre, vous aurez en main :
- La différence entre l'intégration GitHub Action (
openai/codex-action) et la fonction d'automatisation locale (Automations). - Un fichier YAML d'exemple prêt à l'emploi pour GitHub Actions, pour auditer automatiquement vos Pull Requests.
- La configuration des variables d'entrée de
codex-action(prompt-file,sandbox,safety-strategy,final-message, etc.). - La sécurisation de vos clés OpenAI API au sein des Secrets de GitHub, avec les règles d'isolation des variables d'environnement.
- Le paramétrage des tâches d'automatisation (Automations) locales, la planification (syntaxe cron) et la gestion de l'espace de travail.
- Un exercice pratique pas à pas pour configurer une tâche de reporting d'activité quotidienne.
01 Distinguer les deux voies : Intégration CI/CD vs Tâches locales
En résumé : l'automatisation s'articule autour de deux approches : l'intégration cloud (GitHub Actions, déclenchée par des événements du dépôt) et la planification locale (Automations de l'application de bureau, déclenchée par la date ou l'heure).
Analogie : Le gardien de l'immeuble et l'assistant personnel à domicile. Le gardien de l'immeuble (GitHub Actions) réside sur place (les serveurs de GitHub). Il n'intervient que si un événement survient sur les parties communes (une nouvelle PR, une alarme de build de CI), et gère les accès selon le règlement de l'immeuble. L'assistant personnel à domicile (Automations locales) travaille à votre bureau (votre machine de développement). Il applique des consignes planifiées à des heures précises (« Compiler les courriers reçus à 9h ») et son activité s'arrête si vous fermez le bureau (si vous éteignez votre ordinateur).
Spécificités des deux approches :
| Caractéristique | GitHub Actions (codex-action) | Tâches d'automatisation (Automations) |
|---|---|---|
| Environnement d'exécution | Serveur cloud (GitHub runner) | Votre machine de développement locale |
| Événement déclencheur | Activité du dépôt (commit, PR, build) | Heure, planification cron, récurrence temporelle |
| Dépendance système | Autonome (s'exécute sur le cloud) | Exige que votre machine et Codex soient actifs |
| Usage principal | Audit de PR, validation de commits, correction de build | Rapports d'activité, analyses périodiques |
| Périmètre d'action | Projets collaboratifs de l'équipe | Outils individuels et workflows locaux |
La suite de ce chapitre détaille d'abord l'intégration GitHub Actions (sections 02 à 05), puis la planification locale (section 06) et l'exercice pratique (section 07).
💡 En résumé : Choisissez GitHub Actions pour les processus d'équipe déclenchés par l'activité de vos dépôts, et privilégiez les Automations locales de l'application de bureau pour vos tâches périodiques individuelles.
02 Intégration GitHub Actions : Automatiser Codex sur le cloud
L'action officielle openai/codex-action installe l'outil CLI de Codex sur la machine virtuelle de GitHub, configure l'agent d'authentification et exécute la commande de traitement codex exec d'après vos paramètres. Elle évite d'avoir à configurer manuellement l'environnement sur le serveur.
Cette action s'appuie sur la commande de traitement non interactive codex exec (détaillée au chapitre 28). Cette commande exécute Codex en mode script : elle reçoit une consigne en paramètre, effectue la tâche et se ferme, sans afficher la console interactive.
La documentation officielle définit son rôle :
Utilisez l'action GitHub Actions de Codex (
openai/codex-action@v1) pour exécuter Codex, appliquer des correctifs de code ou publier des revues au sein de vos flux de CI/CD. L'action installe l'outil CLI, démarre l'agent d'authentification Responses API et exécute la commandecodex execavec les permissions spécifiées.
Analogie : L'outillage de chantier livré sur place. Pour intervenir sur un chantier distant (le serveur virtuel de GitHub), vous pouvez apporter et assembler chaque outil manuellement (télécharger le CLI de Codex, configurer les clés de sécurité, coder les redirections de flux). La solution alternative consiste à commander un conteneur d'outillage prêt à l'emploi (l'action codex-action) : vous l'ouvrez, les outils sont branchés et configurés, et vous n'avez plus qu'à indiquer la tâche à réaliser (votre consigne).
L'action s'intègre aux événements standards de vos workflows (déclenchement par bloc on: lors d'un commit ou d'une PR). L'audit s'effectue de façon systématique selon l'activité, sans exiger de saisie de commentaire.
💡 En résumé : L'action
openai/codex-actionautomatise l'installation et l'exécution non interactive decodex execsur les serveurs de GitHub Actions. Elle réagit aux événements du dépôt pour auditer le code.
03 Structure d'un workflow type : Audit automatique de Pull Request
Voici un fichier de configuration YAML de workflow type pour auditer automatiquement chaque Pull Request et publier les commentaires sur GitHub.
Analogie : L'organisation d'une équipe de sécurité à deux postes. Le premier agent (le job codex) effectue l'inspection du colis (audit du code de la PR) et rédige un rapport de contrôle sur une fiche (le paramètre de retour final-message). Le second agent (le job post_feedback) reçoit la fiche et colle les étiquettes de signalement aux endroits indiqués (publication des commentaires sur les lignes concernées). Cette répartition des rôles est une mesure de sécurité (présentée à la section 05) : l'agent inspecteur n'a aucun droit d'écriture sur le dépôt, seul l'agent chargé du collage dispose de ces droits.
Exemple de fichier de workflow à enregistrer sous .github/workflows/codex-review.yml :
# Fichier : .github/workflows/codex-review.yml
name: Codex pull request review
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
codex:
runs-on: ubuntu-latest
permissions:
contents: read
outputs:
final_message: ${{ steps.run_codex.outputs.final-message }}
steps:
- uses: actions/checkout@v5
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
persist-credentials: false
- name: Run Codex
id: run_codex
uses: openai/codex-action@v1
with:
openai-api-key: ${{ secrets.OPENAI_API_KEY }}
prompt-file: .github/codex/prompts/review.md
output-file: codex-output.md
post_feedback:
runs-on: ubuntu-latest
needs: codex
if: needs.codex.outputs.final_message != ''
permissions:
issues: write
pull-requests: write
steps:
- name: Post Codex feedback
uses: actions/github-script@v7
with:
github-token: ${{ github.token }}
script: |
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.payload.pull_request.number,
body: process.env.CODEX_FINAL_MESSAGE,
});
env:
CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}Détail du fonctionnement du workflow :
Le déclencheur on : Cible l'événement pull_request sur les actions opened (création), synchronize (nouveaux commits) et reopened (réouverture). Le workflow s'exécute dès qu'une modification est soumise. L'étape checkout : Récupère le code du dépôt. Cette étape est indispensable avant l'appel de Codex pour lui permettre de lire les fichiers. L'option persist-credentials: false supprime les clés d'accès Git locales de la machine virtuelle, et ref cible la version fusionnée de la PR pour l'auditer. L'action Run Codex : Exécute le module codex-action :
openai-api-key: Transmet la clé d'authentification stockée dans vos Secrets (section 05).prompt-file: Référence un fichier textuel contenant vos instructions de relecture (ex:.github/codex/prompts/review.md).output-file: Enregistre le rapport généré dans un fichier de logs local. L'étape de publicationpost_feedback: Le paramètreneeds: codexlie ce job au premier. Le blocifvérifie que le rapport de relecture (final-message) n'est pas vide. L'outilactions/github-scriptpublie ensuite le texte du rapport sous forme de commentaire sur la Pull Request.
La clé d'échange de données de l'action est :
L'action retourne le rapport généré par Codex dans le paramètre de sortie
final-message. Vous pouvez le mapper comme variable de retour ou l'exploiter dans les étapes suivantes.
Vous pouvez également utiliser le paramètre prompt (pour écrire une consigne textuelle en ligne dans le YAML) plutôt que de pointer vers un fichier prompt-file. Ces deux clés sont exclusives ; n'en déclarez qu'une.
💡 En résumé : Le workflow standard récupère le code de la PR, exécute
codex-actionselon vos instructions, et publie le rapport de sortie (final-message) sous forme de commentaire sur GitHub.
04 Configuration des paramètres de l'action
Les variables de l'action codex-action correspondent aux options de la commande CLI codex exec :
| Paramètre YAML | Rôle | Description |
|---|---|---|
prompt / prompt-file | Instructions de la tâche (texte en ligne ou fichier local) | Paramètres exclusifs. |
sandbox | Politique de bac à sable appliquée | read-only (par défaut) / workspace-write / danger-full-access |
model / effort | Sélection du modèle et intensité de réflexion | Par défaut géré par l'application si non renseigné |
output-file | Fichier local de stockage du rapport | Recommandé pour générer des artefacts de builds |
codex-args | Paramètres CLI complémentaires | Tableau JSON (ex: ["--ephemeral"]) ou chaîne système |
codex-version | Version spécifique du CLI de Codex | Utilise la version stable la plus récente par défaut |
codex-home | Dossier principal de données de Codex | Utile pour partager des configurations ou des serveurs MCP entre étapes |
Détails d'intégration à retenir :
Le mode de bac à sable (sandbox) : La documentation conseille d'utiliser le privilège minimal adapté à la tâche. Pour un audit de code (lecture seule), la valeur par défaut read-only suffit. Si Codex doit modifier des fichiers et soumettre un correctif, positionnez explicitement sandbox: workspace-write.
Par défaut,
codex execs'exécute en mode lecture seule (read-only). Si votre workflow demande à Codex de modifier des fichiers de code, vous devez déclarer le paramètresandbox: workspace-write.
Le paramètre codex-args : Il permet d'injecter des options de console. Un cas d'usage fréquent consiste à renseigner l'argument --output-schema pour exiger un retour au format JSON structuré, simplifiant le traitement par des scripts en aval.
Le stockage du rapport (output-file) : Renseigner ce champ permet de conserver le texte de l'audit dans un fichier. Vous pouvez ensuite utiliser l'action standard de GitHub upload-artifact pour le sauvegarder au sein des livrables du build de CI.
Note technique concernant le jeton d'authentification : l'action configure un serveur proxy local pour transmettre de manière sécurisée votre clé API OpenAI, réduisant l'exposition de la clé sur la machine virtuelle.
💡 En résumé : Les paramètres YAML configurent le fonctionnement de
codex-action. Par défaut, le mode est en lecture seule (read-only) ; modifiez-le pourworkspace-writesi le script doit appliquer des modifications de fichiers.
05 Sécurisation de la clé d'API et des permissions réseau
Cette section présente les règles de sécurité indispensables lors du paramétrage d'outils d'IA au sein de chaînes de CI/CD.
Sécurisation de la clé avec GitHub Secrets
Règle de sécurité essentielle : n'écrivez jamais votre clé API OpenAI en clair dans le fichier YAML de configuration :
Enregistrez votre clé API OpenAI au sein des Secrets de votre dépôt GitHub (ex:
OPENAI_API_KEY), et référencez-la comme variable d'environnement dans votre workflow.
Analogie : L'accès sécurisé à un coffre-fort. Écrire la clé en clair revient à coller le code d'accès sur la porte d'entrée de l'atelier, lisible par tous les visiteurs. Enregistrer la clé dans les Secrets de GitHub équivaut à la placer dans un coffre-fort sécurisé : le fichier YAML contient uniquement le nom de la variable (la clé d'accès), et le système de GitHub injecte la valeur de manière cryptée lors de l'exécution, sans l'afficher dans les logs.
Pour enregistrer votre clé : ouvrez l'onglet Settings de votre dépôt GitHub, sélectionnez Secrets and variables → Actions, cliquez sur New repository secret, nommez-le OPENAI_API_KEY et collez-y votre clé d'API.
Restriction de l'exposition des variables d'environnement
La documentation officielle alerte sur une mauvaise pratique courante :
N'associez pas la variable
OPENAI_API_KEYcomme variable d'environnement globale au niveau du job (env:). Les scripts tiers de vos tests unitaires ou de vos dépendances npm locales pourraient lire cette variable et exporter votre clé d'API.
Associez la clé uniquement à l'étape (step) spécifique de l'action codex-action via la section with:, afin de restreindre son accès aux seuls processus de l'action.
Restriction des privilèges système sur le runner
La documentation de Codex propose des options pour encadrer le fonctionnement sur les serveurs virtuels de GitHub :
| Paramètre YAML | Rôle | Description / Recommandation |
|---|---|---|
safety-strategy | Supprime les droits d'administration (sudo) avant l'exécution | Activé par défaut (drop-sudo). Indispensable sur les serveurs partagés. |
unprivileged-user | Spécifie un compte d'utilisateur restreint pour l'exécution | Permet d'isoler les processus de Codex sur le serveur. |
allow-users / allow-bots | Liste des utilisateurs autorisés à déclencher l'action | Par défaut, seuls les membres ayant des droits d'écriture sur le dépôt peuvent l'exécuter. |
Règles de sécurité pour la CI/CD :
- Conservez la valeur
safety-strategy: drop-sudoactive. Cette option supprime les droits d'administration de la machine virtuelle avant de lancer Codex, protégeant les données du système. - Restreignez le déclenchement de l'action aux seuls membres de confiance via
allow-userspour éviter que des contributeurs externes ne déclenchent des builds coûteux via des Pull Requests frauduleuses. - Nettoyez les données d'entrée : si Codex doit analyser des données externes (fichiers issus de PR externes), assurez-vous que les textes ne contiennent pas d'instructions de contournement de sécurité (prompt injection).
Recommandations pour la sécurisation de la CI :
| ❌ Pratique à risque | ✅ Pratique recommandée |
|---|---|
| Clé d'API écrite en clair dans le fichier YAML | Clé enregistrée dans GitHub Secrets |
Clé d'API déclarée dans le bloc global env: du job | Clé déclarée uniquement au niveau de l'étape with: |
Désactivation de la sécurité avec safety-strategy: unsafe | Maintien de la politique drop-sudo |
| Autoriser l'exécution automatique sur toute PR externe | Restreindre le déclenchement aux membres validés |
💡 En résumé : Sécurisez l'intégration en enregistrant la clé API dans GitHub Secrets, en la déclarant uniquement au niveau de l'étape d'exécution, et en conservant la restriction des droits d'administration (
drop-sudo) sur le serveur.
06 Planification de tâches locales (Automations)
La seconde méthode d'automatisation s'exécute localement sur votre machine via la fonction Automations de l'application de bureau Codex.
La documentation officielle présente son rôle :
Planifiez des tâches périodiques en arrière-plan. Codex consigne ses conclusions dans votre boîte de réception (inbox) et archive automatiquement la tâche si aucune alerte n'est détectée.
Analogie : Le rapport d'activité du gardien de nuit. Le gardien effectue sa ronde périodique dans l'usine (votre projet). Si tout est en ordre, il note simplement « ras » dans son cahier de contrôle (archivage silencieux). S'il détecte une anomalie (une fuite d'eau, une porte ouverte), il vous alerte directement (notification dans votre boîte de réception).
Cas d'usages types
La fonction Automations est adaptée aux tâches suivantes :
- Reporting d'activité quotidien : Lire les commits des dernières 24 heures et compiler une synthèse des modifications.
- Audit périodique de sécurité : Analyser les modifications récentes pour détecter d'éventuels bugs ou failles.
- Suivi de processus longs : Surveiller le statut de builds ou d'API réseau.
Deux types d'automatisation
L'application classe les automatisations selon deux structures :
| Type d'automatisation | Comportement | Cas d'usage de référence |
|---|---|---|
| Tâche indépendante (standalone) | Initialise une nouvelle session à chaque exécution, sans historique. | Rapports d'activité quotidiens, audits périodiques autonomes. |
| Automatisation de fil (thread) | Reprend la même session de discussion et conserve son contexte. | Suivi d'un processus long, boucles d'interrogations réseau récurrentes. |
Pour les automatisations de fil (thread), veillez à rédiger des consignes robustes décrivant comment évaluer le statut de l'outil à chaque réactivation, et à quel moment arrêter le traitement.
Exécution en Local ou dans un Worktree
Pour les projets configurés sous Git, l'automatisation s'exécute au choix :
- En mode Worktree : Codex crée une arborescence de travail isolée en arrière-plan pour exécuter la tâche. Les modifications éventuelles n'altèrent pas vos fichiers de travail en cours.
- En mode Local : Codex exécute le traitement directement dans votre répertoire de travail principal. Cette option peut modifier vos fichiers en cours d'édition.
La documentation officielle conseille d'utiliser le mode Worktree par défaut pour isoler les tâches d'arrière-plan.
Création et droits d'exécution
Pour créer une tâche d'automatisation, demandez-le directement en langage naturel à Codex dans le chat : « Planifie une tâche d'audit quotidienne à 9h en mode Worktree ». Codex génère le script et initialise la tâche.
Les automatisations s'exécutent avec le paramètre approval_policy = "never" (les outils sont exécutés sans invite de confirmation). Configurez vos politiques de bac à sable dans config.toml pour encadrer les droits d'écriture locaux.
💡 En résumé : Les tâches locales d'arrière-plan (Automations) s'exécutent de façon périodique (standalone ou thread) en mode Local ou Worktree. Utilisez le mode Worktree pour isoler le traitement et encadrez les droits avec le bac à sable.
07 En pratique : Créer et tester un rapport d'activité planifié
Voici un exercice pour configurer un rapport d'activité quotidien dans l'application de bureau, valider ses paramètres et forcer son exécution de test.
Note technique : L'exercice s'exécute dans l'application de bureau Codex. Le projet cible doit être configuré sous Git.
Étape 1 : Valider le prompt en session courante
Avant de planifier la tâche, testez votre consigne dans une discussion classique pour vérifier le format de réponse :
Analyse les commits des dernières 24 heures sur ce dépôt Git et rédige une synthèse en français :
- Regroupe les commits par thématique de modifications.
- Rédige une phrase explicative par thématique.
- Si aucun commit n'a été enregistré, affiche « Aucun commit récent détecté ».Comportement attendu : Codex lit l'historique Git et affiche le rapport correspondant dans le chat. Le format est correct.
Étape 2 : Planifier l'automatisation
Demandez à Codex de planifier cette tâche au sein d'une automatisation dans la même discussion :
Planifie ce rapport sous forme d'automatisation indépendante chaque matin à 9h. Exécute le traitement au sein d'un worktree isolé. Si aucun commit n'est détecté, archive silencieusement la tâche.Comportement attendu : Codex configure les paramètres de la tâche (planification à 9h, exécution en mode Worktree) et l'enregistre. Validez la configuration dans l'invite.
Étape 3 : Vérifier la tâche dans le panneau d'administration
Ouvrez l'onglet Automations dans le panneau latéral de l'application de bureau.
Comportement attendu : La nouvelle tâche planifiée apparaît dans la liste des automatisations actives avec sa récurrence (chaque matin à 9h) et son mode d'exécution (Worktree).
Étape 4 : Exécuter un test manuel
Dans le panneau des automatisations, sélectionnez votre tâche et cliquez sur le bouton d'exécution manuelle Run now pour tester son fonctionnement sans attendre le lendemain.
Comportement attendu : Codex lance l'exécution en arrière-plan. Une fois le traitement terminé :
- Si des commits ont eu lieu : une notification apparaît dans votre boîte de réception (Triage) contenant le rapport d'activité.
- Si aucun commit n'a été appliqué : la tâche est archivée silencieusement et n'apparaît pas dans votre boîte de réception.
Étape 5 : Gestion de la tâche
Vous pouvez modifier le prompt de la tâche ou modifier sa récurrence dans le panneau d'administration. Si l'outil n'est plus requis, archivez la tâche pour libérer les ressources.
💡 En résumé : L'exercice montre comment valider le prompt en chat, planifier la tâche locale via Codex, et forcer son exécution de test avec le bouton Run now pour vérifier le retour d'information dans la boîte de réception.
08 Résumé
Ce chapitre a présenté l'automatisation des tâches de Codex au sein des chaînes de CI/CD et des tâches planifiées locales.
Voici les points clés à retenir :
| Aspect | GitHub Actions (codex-action) | Tâches locales (Automations) |
|---|---|---|
| Utilité | Intègre Codex dans vos pipelines de build et de relecture automatique de code. | Planifie des tâches périodiques de reporting ou d'audit en arrière-plan. |
| Déclencheur | Événements de versionnage Git (PR, push). | Horloge système, syntaxe cron. |
| Exécution | Serveur virtuel cloud (runner GitHub). | Machine de développement locale (exige Codex actif). |
| Sécurité | Clé API stockée dans Secrets ; exclusion du env: global ; restriction drop-sudo. | Exécution en mode Worktree pour isoler les écritures ; politique de bac à sable. |
| Validation | Retour du rapport via le paramètre de sortie final-message. | Notification dans la boîte de réception (Triage) en cas d'alerte. |
Vous êtes désormais en mesure de choisir la méthode d'automatisation adaptée à votre besoin, de configurer un workflow GitHub Actions pour auditer vos Pull Requests, d'encadrer la sécurité de vos clés et variables d'environnement dans la CI, d'exploiter les paramètres d'entrée de codex-action pour affiner les privilèges de bac à sable, de configurer des tâches planifiées locales (Automations) en mode Worktree, et de gérer le suivi des rapports dans votre boîte de réception.
Le chapitre suivant 28 · Exécution non interactive (codex exec) présente la commande système de traitement : comment utiliser la commande codex exec en ligne de commande, comment structurer les flux d'entrées et de sorties au format JSON pour l'intégrer à des scripts d'administration locaux, et comment gérer sa sécurité ? Nous verrons comment programmer nos propres scripts d'automatisation.