Aller au contenu principal
PraktikPraktikLe guide IA utile
S'abonner
Avancé10 min

Automatiser Codex

Ce que tu vas apprendre

Lancer Codex sans interaction : CLI non-interactif, GitHub Actions, SDK. Garder les garde-fous quand personne ne surveille en temps reel.

Prerequis

  • Avoir lu les modules 01 a 08
  • Comprendre les modes sandbox et approbations (module 07)
  • Un repo avec CI fonctionnelle

Le concept en 30 secondes

L’automatisation supprime l’humain du loop. C’est utile pour les taches repetitives et bornees. C’est dangereux pour les decisions produit ambigues. Le contrat d’automatisation = entrees + sorties + verification + review humaine.

@diagram:flow
Entrees :: Fichiers, branche, chemins d'artifacts.
Sorties :: Resume, fichiers modifies, resultat.
Verification :: Commande exacte qui prouve le travail.
Review humaine :: Inspecter le diff avant merge.

Etapes

1. Workflow non-interactif avec codex exec

Usage : taches scriptees avec entrees, sorties et verification claires.

Bons cas :

  • Lint et reparation de documentation
  • Resume de mise a jour de dependances
  • Notes de review generees
  • Codemods bornes avec tests solides

Forme canonique du prompt :

Objectif : resultat exact.
Entrees : fichiers, branche, ou chemins d'artifacts.
Modifications autorisees : chemins ou sous-systemes explicites.
Ne pas modifier : exclusions explicites.
Verification : commande exacte.
Sortie : resume, fichiers modifies, resultat de verification.

Exemple concret :

codex exec \
  --sandbox workspace-write \
  --ask-for-approval untrusted \
  "Goal: repair the smallest docs contract drift.
   Allowed changes: docs and validation files only.
   Do not change: package manager files, CI, or unrelated examples.
   Verification: npm run test && npm run validate.
   Return: files changed, root cause, verification result, and remaining risk."

Garde-fous :

  • Partir d’un worktree propre ou intentionnellement prepare
  • Borner les chemins en ecriture
  • Faire echouer la commande sur erreur de validation
  • Inspecter le diff avant commit

2. GitHub Action

Usage : evenements repo declenchent Codex automatiquement.

Bons cas :

  • Assistance review PR
  • Verification de notes de release
  • Taches de maintenance recurrentes
  • Triage d’issue produisant une proposition bornee

Forme du workflow :

name: Codex Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - name: Run Codex review
        run: |
          codex exec \
            --sandbox read-only \
            --ask-for-approval never \
            "Review this PR for behavioral risks.
             Prioritize bugs, regressions, missing tests, unsafe assumptions.
             Return severity-ordered findings with file references.
             Do not comment on style unless it affects correctness.
             Include any checks you ran or could not run."

Prompt contract type :

Review cette PR pour les risques comportementaux.

Priorise :
- bugs, regressions
- tests manquants
- hypotheses non sures
- risques deploiement ou compatibilite

Retourne les findings par severite avec references de fichiers.
Ne commente pas le style sauf si ca affecte la correction.
Inclus les checks que tu as lances ou que tu n'as pas pu lancer.

Ce qu’il faut eviter :

  • Merger automatiquement les changements Codex
  • Demander des refactors larges depuis un trigger generique
  • Cacher les echecs dans des logs que personne ne lit

3. SDK Codex

Usage : integrer Codex dans un outil interne ou un workflow engineering existant.

Bons cas :

  • Bot de maintenance avec contrat de prompt fixe
  • Assistant de review interne
  • Helper de migration dans un tooling existant
  • Action portal dev creant un draft PR

Checklist de design :

  • Quelle action utilisateur declenche le run ?
  • Quel repo et environnement sont prepares ?
  • Quel est le contrat de prompt exact ?
  • Quels outils et perimetre d’ecriture sont autorises ?
  • Comment les humains reviewnt le resultat ?
  • Quels logs, gestion d’erreur et retry ?

Exemple de contrat SDK :

const run = await codex.run({
  prompt: `Goal: update dependency summary.
           Inputs: package.json, package-lock.json.
           Allowed: docs/dependencies.md only.
           Verification: npm run validate.
           Output: summary + files changed + validation result.`,
  sandbox: "workspace-write",
  approvals: "untrusted",
  allowedPaths: ["docs/dependencies.md"]
});

Ce qu’il faut eviter :

  • Cacher des prompts vagues derriere un bouton
  • Donner un acces ecriture large sans verification
  • Sauter la review humaine pour les changements de code

Verification

  • Le prompt d’automatisation est borne (objectif, entrees, exclusions, verification)
  • Le mode sandbox est read-only pour la review, workspace-write uniquement si necessaire
  • La commande de verification est incluse dans le prompt
  • Le diff est inspecte avant merge ou publication
  • Les logs d’erreur sont visibles et actionnables
  • Pas de merge automatique sans review humaine

Pieges courants

  • Automatiser une decision produit ambigue → L’automation execute, elle ne decide pas
  • Sauter la review du diff parce que c’est automatise → C’est le moment le plus dangereux
  • Oublier la commande de verification dans le prompt → Codex ne saura pas quoi lancer
  • Laisser l’automation ecrire dans des zones non liees → Borne les chemins

Recapitulatif

Type Quand l’utiliser Surface Sandbox recommande
codex exec non-interactif Taches scriptees bornees CLI workspace-write + untrusted
GitHub Action Evenements repo recurrents GitHub read-only pour review
SDK Integration outil interne API/Code Selon le perimetre

Pour aller plus loin