Intégration CI/CD

Codex dans votre pipeline de livraison

Codex ne se limite pas aux tâches lancées à la main par un développeur. Il s’intègre dans vos pipelines CI/CD pour automatiser des tâches de développement à chaque étape du cycle de livraison. Le changement va plus loin qu’un simple gain de temps : la relecture, la génération de tests et la correction cessent de dépendre de la discipline individuelle pour devenir des étapes du pipeline, déclenchées par des événements et non par la bonne volonté du vendredi après-midi.

Faire relire chaque PR automatiquement

C’est le point d’entrée le plus courant, et celui qui rentabilise sa configuration en quelques jours. Le workflow se déclenche à l’ouverture d’une PR ainsi qu’à chaque nouveau push sur la branche, de sorte qu’une correction apportée après relecture soit elle aussi examinée :

# .github/workflows/codex-review.yml
name: Codex Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Codex Review
        uses: openai/codex-action@v1
        with:
          task: "review"
          criteria: |
            - Sécurité : injections, auth manquante
            - Performance : requêtes N+1, boucles
            - Types : pas de any, types stricts
            - Tests : couverture des changements
          api-key: ${{ secrets.OPENAI_API_KEY }}

Le bloc criteria mérite votre attention plus que le reste du fichier : c’est lui qui transforme une relecture générique en relecture conforme à vos priorités. Une équipe qui vit des incidents d’authentification y mettra la sécurité en tête ; une équipe qui souffre de lenteurs y mettra la performance. Codex poste ensuite ses commentaires directement sur la PR GitHub, à l’endroit exact où un relecteur humain les aurait laissés.

Combler les tests manquants

Un second workflow s’attaque à l’angle mort classique des PRs pressées : le code livré sans test associé. Le déclencheur se limite ici à l’ouverture, faute de quoi chaque commit de correction relancerait une génération de tests dont personne n’a besoin.

# .github/workflows/codex-tests.yml
name: Codex Generate Tests
on:
  pull_request:
    types: [opened]

jobs:
  generate-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate missing tests
        uses: openai/codex-action@v1
        with:
          task: "generate-tests"
          scope: "changed-files"
          framework: "vitest"
          api-key: ${{ secrets.OPENAI_API_KEY }}

Codex repère les fichiers modifiés dans la PR qui n’ont pas de tests et propose les tests manquants, soit en commentaire, soit en commit supplémentaire. Le développeur garde la main de bout en bout : il accepte, adapte ou refuse, et l’automatisation ne lui impose rien.

Réagir à un échec de CI

Le troisième workflow ne se branche pas sur une PR mais sur le résultat d’un autre workflow. Lorsque la CI échoue, Codex lit les logs d’erreur, identifie la cause et pousse un commit de correction sur la branche :

# .github/workflows/codex-fix.yml
name: Codex Auto-Fix
on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  fix:
    if: ${{ github.event.workflow_run.conclusion == failure }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Analyze and fix CI failure
        uses: openai/codex-action@v1
        with:
          task: "fix-ci"
          api-key: ${{ secrets.OPENAI_API_KEY }}

C’est celui qui exige le plus de prudence. Un test qui échoue signale parfois un défaut de conception, et un correctif automatique plausible peut le faire disparaître de l’écran sans le résoudre : la CI redevient verte, le problème reste entier.

Appeler Codex depuis vos propres scripts

Hors de GitHub Actions, le CLI s’insère dans n’importe quel script d’automatisation. Le hook de pre-commit ci-dessous refuse de laisser passer un fichier TypeScript dépourvu de test et déclenche la génération à la volée, avant même que le commit n’existe :

#!/bin/bash
# Script de pre-commit hook

# Vérifier que les fichiers modifiés ont des tests
CHANGED=$(git diff --cached --name-only --diff-filter=ACM | grep .ts)
for file in $CHANGED; do
  test_file="${file%.ts}.test.ts"
  if [ ! -f "$test_file" ]; then
    echo "⚠️ Fichier sans test : $file"
    codex "Génère les tests pour $file" --apply
    git add "$test_file"
  fi
done

Cartographier les points d’intégration

Une fois ces briques en place, raisonnez en termes d’événements du cycle de livraison plutôt qu’en termes de fichiers YAML. Les cinq scénarios ci-dessous couvrent la quasi-totalité des usages observés en équipe :

Garder la main sur l’automatisation

Une intégration CI/CD tourne sans surveillance, ce qui impose quelques précautions élémentaires. Utilisez un token API dédié aux permissions minimales plutôt que la clé personnelle d’un développeur qui quittera l’entreprise un jour, emportant avec lui le fonctionnement de vos pipelines. Ne mergez jamais automatiquement un correctif produit par Codex : la review humaine reste la condition d’entrée dans la branche principale. Fixez des limites explicites, en nombre de tâches par jour et en coût maximum, pour qu’une boucle de correction mal configurée ne consomme pas votre budget mensuel en une nuit. Conservez enfin l’historique des tâches Codex exécutées dans la CI : le jour où un comportement inattendu apparaît en production, ces logs seront votre seule piste sérieuse.

Points clés à retenir

• Codex s’intègre dans GitHub Actions et d’autres systèmes CI/CD
• La review automatique sur les PRs est le cas d’usage le plus courant
• Codex peut corriger les échecs CI automatiquement
• Le CLI permet l’intégration dans des scripts personnalisés
• Gardez toujours un humain dans la boucle pour valider les corrections