Danila (Dayfing)
Retour aux articles
2 184 mots9 min

Agentic coding en pratique : Codex, Claude Code et Copilot CLI avec PR et tests

L’agentic coding ne consiste pas seulement à demander à un modèle d’écrire une fonction. L’agent lit un dépôt, choisit des outils, modifie plusieurs fichiers, exécute des commandes et prépare un changement auquel une personne ou un système CI doit pouvoir faire confiance. La comparaison utile porte donc sur toute la boucle de contrôle : démarrage, règles du dépôt, accès, vérification, diff et pull request.

Cet article compare les flux en terminal documentés pour OpenAI Codex CLI, Anthropic Claude Code et GitHub Copilot CLI. L’état de la documentation a été vérifié le 28 août 2026. Il ne s’agit ni d’un benchmark personnel, ni d’un test de vitesse, ni d’un compte rendu d’exécution manuelle. Les commandes sont des exemples représentatifs de la documentation des produits et doivent être adaptées aux scripts et aux politiques du dépôt. « Vérifié » signifie que le fournisseur documente la capacité. « Implication pratique » est une recommandation déduite de ces contrôles documentés.

Une tâche et trois plans de contrôle

Prenons une tâche délimitée : « Ajoute la validation d’une session expirée, mets à jour les tests unitaires, lance les vérifications utiles, affiche le diff et prépare une pull request sans pousser vers la branche par défaut ». Elle montre où chaque produit attend une décision humaine.

Plan Codex CLI Claude Code GitHub Copilot CLI
Entrée locale codex ou codex exec claude copilot ou copilot -p
Règles du dépôt Hiérarchie AGENTS.md CLAUDE.md, import de AGENTS.md Instructions Copilot, règles de chemin, AGENTS.md
Permissions Sandbox et politique d’approbation Règles allow, ask, deny et modes Portées outil, chemin, URL et sandbox
Boucle de test Commande du dépôt Trouver, écrire, lancer, corriger Commandes de l’agent ou hook après changement
Revue /review, sans modifier l’arbre Revue Git et automatisation Actions /review et agent de revue
Pull request Action de revue, Git pour un PR local PR Git et @claude dans Actions /pr, correction CI et délégation cloud
Mode non interactif codex exec avec flags sandbox claude -p et Actions -p, autopilot, Actions

C’est une carte de capacités, pas un palmarès.

Installation et premier lancement sûr

La documentation Codex décrit l’installation du CLI autonome, l’ouverture d’un répertoire de projet et la connexion au premier lancement. Commencez dans un dépôt Git, demandez un résumé et inspectez les permissions avec /status et /permissions. Pour l’automatisation, utilisez codex exec.

Claude Code documente l’installation native sur macOS, Linux, WSL et Windows PowerShell, puis claude dans le projet et l’authentification initiale. Homebrew et WinGet sont aussi documentés. Considérez le premier lancement comme une décision de confiance, car le CLI peut lire, exécuter et modifier des fichiers.

Copilot CLI s’installe avec un canal de paquet ou de plateforme pris en charge, puis se lance avec copilot. La première session demande si le dossier est fiable. GitHub avertit que le CLI peut lire, modifier et exécuter les fichiers situés dans ce dossier et ses sous-dossiers. Utilisez /login et ne mémorisez le dossier qu’après avoir compris ses scripts.

Pour les trois outils, utilisez une branche ou un worktree jetable, notez le test de référence, inspectez les instructions chargées, n’autorisez que les commandes nécessaires et protégez la branche par défaut.

Les instructions du dépôt font partie de l’interface

Codex lit AGENTS.md avant de travailler. Sa chaîne documentée comprend un fichier global et un fichier par répertoire entre la racine du projet et le répertoire courant. AGENTS.override.md prévaut dans son répertoire, tandis que les fichiers plus spécifiques suivent les règles générales. Placez les commandes de test et de sécurité à la racine, puis les conventions d’un service dans son sous-répertoire.

Claude Code lit CLAUDE.md et CLAUDE.local.md dans la hiérarchie des répertoires. Il ne lit pas directement AGENTS.md, mais CLAUDE.md peut l’importer avec @AGENTS.md. Gardez les règles partagées de build, de test et d’architecture dans CLAUDE.md, les préférences personnelles dans le fichier local ignoré et les règles de chemin dans .claude/rules/.

Copilot CLI accepte .github/copilot-instructions.md, des fichiers .instructions.md spécifiques à un chemin et AGENTS.md. copilot init aide à créer les premières règles. Ces fichiers façonnent le prompt, mais ne constituent pas une frontière de permission. « Ne jamais toucher aux identifiants de production » doit aussi être appliqué par des chemins interdits, l’environnement et la CI.

Conservez un AGENTS.md court, ajoutez un import Claude et des règles Copilot. Indiquez les commandes de paquet, le test minimal, les fichiers générés, les chemins interdits, la migration et les preuves attendues dans le PR.

Sandbox et approbations sont deux contrôles différents

Codex les distingue explicitement. Le sandbox détermine les fichiers et ressources réseau accessibles aux commandes. Les approbations déterminent quand Codex s’arrête avant une action. Pour une modification locale, le profil courant est workspace-write avec des approbations on-request. read-only convient à l’exploration ou à une revue CI sans écriture. danger-full-access et l’alias --yolo retirent la barrière de sécurité et doivent rester réservés à un environnement isolé.

Pour une session locale, rendez le contrat explicite :

codex --sandbox workspace-write --ask-for-approval on-request

Dans la CI, codex exec est documenté en lecture seule par défaut. Ajoutez --sandbox workspace-write seulement si le job doit produire un patch. N’utilisez --ask-for-approval never qu’avec un runner, un checkout, une liste de commandes et une sortie contrôlés. N’introduisez pas l’ancien flag --full-auto dans de nouveaux scripts.

Claude Code propose des permissions par niveaux. Les lectures et les commandes shell intégrées en lecture seule ne demandent pas d’approbation en mode Manual. Les éditions, Bash général, recherches et web fetch peuvent en demander une. Le client, et non le modèle, applique les règles allow, ask et deny. Les modes Manual, Plan, Auto et bypass existent, ce dernier étant destiné à un conteneur ou une machine virtuelle isolée. Bash sandboxé ajoute l’isolation des fichiers et du réseau via /sandbox.

Copilot CLI demande une approbation avant les outils qui modifient ou exécutent des fichiers, tandis que les recherches et lectures en lecture seule sont automatiques. Les permissions peuvent cibler les outils, chemins et URL. Le sandbox local est un contrôle expérimental séparé, et GitHub documente aussi un sandbox cloud éphémère. Vérifiez /sandbox policy et les permissions effectives avant un lancement autonome.

Accordez les capacités par couches : lecture du dépôt, formatter et tests exacts, puis écriture dans la branche ou le worktree. Gardez réseau, installation, identifiants, push et déploiement séparés. Un sandbox limite la portée, pas la correction sémantique.

Outils, MCP et hooks d’automatisation

Les trois produits utilisent shell, opérations sur les fichiers et recherche dans le dépôt. Codex documente skills, plugins, MCP et GitHub Action. Claude Code documente serveurs MCP, skills, hooks et subagents. Copilot CLI documente MCP, skills, plugins, agents personnalisés, hooks et un serveur GitHub MCP intégré.

Traitez chaque extension comme du code exécuté dans le flux. Vérifiez sa source, limitez les identifiants et décidez si elle appartient à l’agent ou au réviseur. Un serveur MCP qui crée des tickets ou fusionne des PR n’a pas le même risque qu’un serveur de documentation en lecture seule.

Les hooks peuvent formater après une édition ou lancer un test rapide. Gardez-les déterministes.

Les tests forment une boucle de preuve

Un bon prompt indique le comportement, les fixtures, les commandes et la condition d’arrêt. Demandez d’inspecter les tests, d’ajouter un cas d’expiration de session, de faire le plus petit correctif, puis de lancer le test ciblé et les vérifications requises. Exigez la commande et son exit status dans le rapport. Si le test ciblé passe déjà, demandez pourquoi au lieu d’une seconde implémentation.

La documentation des workflows Claude Code décrit explicitement la recherche de code non couvert, le scaffolding, les edge cases, l’exécution des tests et la correction des échecs. Codex et Copilot CLI peuvent lancer les commandes du dépôt quand les permissions et outils le permettent. Des tests générés ne prouvent pas la couverture. Une personne vérifie le contrat, les fixtures, les chemins d’intégration et les cas de sécurité.

Utilisez trois niveaux : test ciblé rapide, suite du paquet ou du service, puis checks PR obligatoires comme barrière de fusion. Limitez les corrections et conservez le message d’erreur initial. Relancer une commande instable ne fournit pas une nouvelle preuve.

Diff, revue et pull requests

La revue commence avant le PR. Demandez les fichiers modifiés, les invariants, les tests exécutés et les lacunes. Comparez avec la tâche, puis lisez vous-même le diff Git. Le résumé de l’agent n’est pas la source de vérité.

Codex documente /review pour les changements non commités, un commit ou une comparaison de branches. Le reviewer rapporte des problèmes prioritaires sans modifier l’arbre. Sa documentation GitHub Action comprend un workflow qui révise les pull requests et publie le résultat. La création locale d’un PR utilise toujours les outils Git ou GitHub et leurs permissions.

Claude Code documente staging, commits, branches et PR. Son intégration GitHub Actions accepte @claude dans une issue ou un commentaire de PR, les tâches issue-to-PR et les workflows de revue. Gardez le token et les permissions étroits et conservez les gates CI habituelles.

Copilot CLI documente /review, /pr create et /pr fix feedback, ainsi que la correction des conflits et de la CI. /delegate envoie la tâche à l’agent cloud, qui ouvre un PR brouillon et continue à distance. Ces commandes ne garantissent pas un PR fusionnable.

Séparez « préparer » et « publier ». Laissez l’agent créer branche, patch, tests et description brouillon. Réservez push, labels, approbation et fusion à une personne ou une identité protégée. Le PR doit indiquer la tâche, les fichiers, les commandes, les résultats, les risques et les zones non testées.

CI et reproductibilité

Le mode non interactif de Codex est destiné aux pipelines. Il sépare la sortie finale de la progression, émet du JSON Lines, écrit le dernier message et accepte un schéma de sortie. Le workflow doit tout de même traiter correctement l’authentification, les logs et les échecs.

Claude Code fonctionne avec -p et dans GitHub Actions. Utilisez un job de revue en lecture seule pour les PR non fiables, et un job d’écriture séparé pour la maintenance autorisée. Les règles de déclenchement et de token restent une frontière de sécurité.

Copilot CLI propose -p, des formats de sortie, autopilot et Actions. --max-autopilot-continues borne les continuations. Dans Actions, choisissez l’identité qui paie le modèle et le token qui peut écrire. Une réponse du modèle n’est pas un succès CI tant que le vrai job de test n’a pas réussi.

Sécurité et coûts

Une injection de prompt peut venir d’une issue, d’une fixture, d’un README, d’un fichier généré ou d’une page web. N’accordez pas un accès réseau large ou des identifiants de production pour lire le code. Interdisez les chemins de secrets, n’affichez pas les variables d’environnement, séparez l’installation des paquets des tests et examinez MCP et hooks comme des dépendances de la chaîne d’approvisionnement.

Les limites et crédits Codex varient selon le plan et la taille de la tâche. Claude Code distingue la facturation API de l’abonnement et expose /usage; le raisonnement étendu et le contexte long peuvent augmenter la consommation. Copilot CLI utilise les GitHub AI Credits et documente --max-ai-credits. Ces systèmes comptables ne sont pas directement comparables.

Définissez un budget de workflow. Utilisez un effort réduit pour cartographier le dépôt et un modèle plus puissant pour une décision à haut risque. Limitez retries, agents parallèles, autopilot et durée cloud. Nettoyez ou compactez les sessions entre tâches sans rapport. Comptez le coût d’ingénierie et le temps de revue humaine, pas seulement les tokens.

Des workflows adaptés au contexte

Pour une modification locale, démarrez l’un des trois outils en mode plan ou lecture seule. Faites cartographier le dépôt, citer les instructions importantes et proposer les fichiers et tests. Autorisez le minimum, lancez les tests ciblés et requis, puis lisez le diff avant toute commande PR.

Pour un travail GitHub centré sur les retours de PR et les échecs CI, Copilot CLI documente un cycle /pr direct. Pour des tâches déclenchées par commentaire, les Actions Claude Code et l’Action de revue Codex offrent des chemins documentés. Pour une sortie locale structurée, exec de Codex documente JSONL et les schémas. Ce sont des constats d’adéquation d’interface, pas un classement.

Pour le code sensible, choisissez le mode que votre organisation peut imposer. Un réviseur en lecture seule dans un runner verrouillé peut être plus sûr qu’une session locale autonome. Placez la politique dans la CI et les contrôles du fournisseur, pas seulement dans le texte. Consultez AGENTS.md et les coding agents, les évaluations d’agents IA et l’architecture d’un agent IA en production.

Un petit contrat d’exploitation

Avant de commencer, définissez le dépôt, la branche, les chemins autorisés, la commande de test, le réseau, la limite de corrections et le responsable du PR. Exigez des outils visibles et des approbations bornées. Terminez par le diff, les preuves de test, les risques et l’usage. Le réviseur et la CI décident si le changement est prêt.

Documentation officielle utilisée

Plus d’articles