L'IA pour les développeurs : agents de programmation, coûts et délégation sûre

Comment faire

1. 1Avant de confier la tâche, écrivez la vérification ou indiquez-la : le test en échec, ou la commande et sa sortie attendue.
2. 2Donnez-lui la tâche avec le prompt de cette page, en précisant les fichiers qu'il peut modifier et ceux auxquels il ne doit pas toucher.
3. 3Laissez-le lancer lui-même la vérification et coller la sortie finale.
4. 4Relisez le diff comme la pull request d'un collègue ; une vérification réussie ouvre la revue, elle ne la clôt pas.

Intégré

• ChatGPT · Codex
• Claude · Claude Code

Prompt à copier

Tâche : [modification].
C'est terminé quand : [test ou commande] passe et affiche [sortie attendue]. Lance-le avant de terminer et colle le résultat.
Tu peux modifier : [chemins]. Ne modifie pas : [chemins], les dépendances ni les tests.
Si tu n'arrives pas à le faire passer, arrête-toi et explique pourquoi au lieu de contourner la vérification.

Les pièges

• Les agents font parfois passer un test en l'affaiblissant. Interdisez la modification des tests, et cherchez-en la trace dans le diff.
• Une tâche trop grosse pour une seule vérification est trop grosse pour une seule délégation. Découpez-la.

Comment faire

1. 1Choisissez celui qui est proche de votre code : Codex Cloud, le Copilot cloud agent sur GitHub, ou Claude Code on the web.
2. 2Assurez-vous que son environnement peut installer vos dépendances et exécuter vos tests ; sans cela, l'agent devine.
3. 3Envoyez des tâches petites et indépendantes, chacune avec sa propre vérification, comme dans la tâche ci-dessus.
4. 4Laissez d'abord un relecteur automatique lire chaque pull request, puis relisez-la vous-même.

Intégré

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

Prompt à copier

Dans ce dépôt : [tâche].
Contexte : [où dans le code, ticket lié].
Terminé quand : [test ou commande] passe dans ton environnement ; mets sa sortie dans la description de la pull request.
Limite la pull request à moins de [n] lignes modifiées. S'il en faut plus, arrête-toi et propose un découpage.

Les pièges

• Les tests qui nécessitent des secrets ou des services que vous n'avez pas configurés sont ignorés ou échouent. Un résultat vert sans eux ne prouve pas grand-chose.
• Plusieurs agents sur du code lié produisent des pull requests en conflit. Gardez les tâches parallèles dans des zones séparées.

Comment faire

1. 1Mettez vos commandes de build, de test et de lint dans le fichier d'instructions que votre agent lit au début de chaque session ; la documentation de chaque agent indique le nom de ce fichier.
2. 2Dans Claude Code, ajoutez des hooks qui exécutent le formateur et les tests après chaque modification, pour que l'agent voie les échecs et les corrige.
3. 3Faites relire chaque pull request par un bot : activez « Automatic review » dans Codex, ou demandez Copilot comme relecteur.
4. 4Quand l'agent fait deux fois la même erreur, transformez-la en test ou en règle dans le fichier d'instructions.

Intégré

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

Prompt à copier

Lis ce dépôt et rédige le fichier d'instructions pour les agents de programmation :
1. Les commandes exactes pour installer, compiler, tester, linter et formater.
2. L'organisation du projet en 10 lignes maximum.
3. Les conventions sur lesquelles les nouveaux venus se trompent ici, avec un exemple pour chacune.
4. Ce qu'un agent ne doit jamais faire ici, par exemple modifier les migrations ou éditer des fichiers générés.
Ne liste que les commandes que tu as exécutées avec succès ; marque les autres « non vérifié ».

Les pièges

• Un fichier d'instructions dont les commandes ne fonctionnent plus apprend à l'agent à l'ignorer. Relancez-les quand la configuration change.
• Les bots de revue font aussi des erreurs avec assurance. Traitez leurs commentaires comme des suggestions.

Comment faire

1. 1Listez ce que vous collez le plus souvent dans les conversations, comme des tickets, des logs d'erreur, de la documentation ou le schéma. Connectez ceux-là en premier.
2. 2Ajoutez le serveur MCP officiel de chacun, avec un token qui ne peut que lire. Dans Gemini CLI, une extension peut regrouper le serveur MCP et sa configuration.
3. 3Donnez-lui une tâche qui en a besoin et vérifiez qu'il a appelé le bon serveur.
4. 4À intervalles de quelques semaines, retirez les serveurs que vous n'utilisez plus.

Intégré

• Gemini CLI · Extensions

Prompt à copier

Avant de modifier quoi que ce soit : lis le ticket [id] dans l'outil de suivi, trouve l'erreur dans les logs, et consulte la documentation de [bibliothèque].
Dis ce que chacun t'a appris et quel fichier est selon toi en cause.
N'écris dans aucun outil connecté.

Les pièges

• Une page web, un ticket ou un document peut contenir un texte écrit pour manipuler l'agent. Ne donnez pas d'accès en écriture aux outils qui lisent du contenu venu de l'extérieur.
• Les tokens dans les fichiers de configuration finissent par fuiter. Utilisez le stockage de secrets du client ou des variables d'environnement, jamais le dépôt.

Comment faire

1. 1Vérifiez ce que vous payez déjà : les offres ChatGPT incluent Codex, et les offres payantes de Claude incluent Claude Code.
2. 2Notez la consommation de tokens de quelques sessions typiques, là où votre agent l'affiche.
3. 3Chiffrez cette consommation sur notre page des prix des API et comparez-la avec l'abonnement.
4. 4Pour l'automatisation et la CI, utilisez des clés API avec une limite de dépenses, pour qu'une boucle ne puisse pas faire exploser la facture.

Intégré

• ChatGPT · Codex
• Claude · Claude Code

Prompt à copier

Voici ma consommation sur [n] sessions typiques : [tokens en entrée et en sortie]. Je travaille environ [jours] jours par semaine.
Estime mon coût mensuel au token à ces prix : [à coller depuis la page des prix des API].
Compare-le avec un abonnement à [prix] par mois. Montre le calcul pour que je puisse le vérifier.

Les pièges

• Les abonnements ont aussi des limites d'utilisation. En atteindre une en pleine tâche fait perdre du temps ; vérifiez la limite, pas seulement le prix.
• C'est le modèle qui fait le plus varier la facture. Comparez avec le modèle que vous utilisez réellement.

Comment faire

1. 1Lancez /init dans le dépôt : il analyse la base de code et rédige un premier CLAUDE.md, ou propose des améliorations à celui que vous avez déjà.
2. 2Gardez les règles d'équipe, comme les commandes de build et de test et les normes de code, dans ./CLAUDE.md et commitez-le. Vos préférences personnelles vont dans ~/.claude/CLAUDE.md pour tous les projets, ou dans CLAUDE.local.md pour celui-ci.
3. 3Renvoyez vers les documents longs au lieu de les coller : @path/to/file importe un autre fichier au lancement.
4. 4Chaque fois que Claude se trompe deux fois sur la même chose, ajoutez la ligne qui l'aurait évité.

Prompt à copier

Lis ce dépôt et améliore CLAUDE.md. Garde-le sous les 60 lignes :
1. Les commandes exactes pour compiler, tester et linter.
2. L'organisation en quelques lignes.
3. Les conventions sur lesquelles un nouveau venu se trompe ici.
4. Les fichiers et dossiers à ne jamais modifier.
Supprime tout ce qui n'est plus vrai. Marque les commandes que tu n'as pas exécutées « non vérifié ».

Les pièges

• Tout ce qui est dans CLAUDE.md est chargé à chaque session et occupe du contexte. Déplacez les détails dans des fichiers qu'il importe.
• Des instructions qui ne sont plus vraies sont pires que pas d'instructions du tout. Revérifiez les commandes quand la configuration change.

D'après la documentation officielle : Claude Code docs: How Claude remembers your project

Comment faire

1. 1Appuyez sur Shift+Tab jusqu'à ce que la barre d'état affiche « plan mode on », ou commencez votre prompt par /plan.
2. 2Décrivez la modification et ce qui ne doit pas changer. Claude peut encore lancer des commandes pour explorer, mais il ne modifie aucun fichier pendant qu'il planifie.
3. 3Lisez le plan comme une note de conception : un mauvais fichier, un cas oublié, une modification trop grosse. Demandez des changements jusqu'à ce qu'il soit juste, puis validez-le.
4. 4Avant la tâche suivante, sans rapport, repartez de zéro avec /clear.

Prompt à copier

/plan Modifie [quoi] pour que [objectif]. Contraintes : [ce qui ne doit pas changer].
Liste les fichiers que tu vas toucher, l'ordre des modifications, le test qui prouve chaque étape, et tout ce dont tu n'es pas sûr. Ne modifie rien tant que je n'ai pas validé.

Les pièges

• Un plan qui touche plus de fichiers que prévu est le signal d'alerte. Demandez pourquoi avant de valider.
• Le mode plan exécute quand même des commandes pour explorer. Il ne suffit pas à rendre sûre l'exécution d'un dépôt que vous ne connaissez pas.

D'après la documentation officielle : Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

Comment faire

1. 1Ouvrez /permissions pour voir chaque règle et le fichier de paramètres dont elle provient.
2. 2Mettez les règles de l'équipe dans .claude/settings.json et commitez-le. Les règles personnelles vont dans ~/.claude/settings.json ou .claude/settings.local.json.
3. 3Les règles sont vérifiées dans l'ordre deny, puis ask, puis allow : une seule règle deny l'emporte donc sur n'importe quelle règle allow.
4. 4Changez de mode avec Shift+Tab : acceptEdits approuve les modifications de fichiers dans le répertoire de travail. bypassPermissions désactive les demandes et les contrôles de sécurité ; la documentation indique de ne l'utiliser que dans des conteneurs ou des VM isolés sans accès à Internet.

Prompt à copier

Regarde les commandes que tu as lancées dans cette session. Propose des règles de permission pour .claude/settings.json : autorise les commandes en lecture seule et de test que nous utilisons tous les jours, interdis tout ce qui lit des secrets ou supprime en dehors du projet, et laisse tout le reste en demande de confirmation. Explique chaque règle en une ligne.

Les pièges

• Une règle allow qui correspond à n'importe quelle commande revient à n'avoir aucune demande. Autorisez des commandes exactes.
• Les règles de .claude/settings.json s'appliquent à toute l'équipe une fois commitées. Relisez-les comme du code.

D'après la documentation officielle : Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

Comment faire

1. 1Entre des tâches sans rapport, /clear lance une nouvelle conversation avec un contexte vide.
2. 2Dans une longue tâche, /compact avec une consigne, par exemple « /compact garde le plan et le test qui échoue », résume ce qui précède.
3. 3Confiez les recherches larges à un sous-agent : chacun s'exécute dans sa propre fenêtre de contexte, et seule sa réponse revient dans votre session.
4. 4Claude Code compacte aussi de lui-même à l'approche de la limite ; compacter vous-même au bon moment permet de garder ce que vous choisissez.

Intégré

• Claude Code · Subagents

Prompt à copier

/compact Garde : l'objectif, le plan, les fichiers modifiés jusqu'ici et le test qui échoue encore. Laisse tomber l'exploration.

Les pièges

• /clear oublie la conversation. Tout ce dont vous aurez encore besoin doit d'abord aller dans CLAUDE.md.
• La réponse d'un sous-agent est tout ce que vous récupérez. Demandez-lui des chemins de fichiers et des numéros de ligne, pas seulement des conclusions.

D'après la documentation officielle : Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

Comment faire

1. 1Lancez chaque session avec claude --worktree <name> (ou -w). Cela crée un worktree git sous .claude/worktrees/<name>/ sur la branche worktree-<name>.
2. 2Ajoutez .claude/worktrees/ à .gitignore, comme le recommande la documentation.
3. 3Donnez à chaque session une seule tâche avec sa propre vérification, pour pouvoir les relire une par une.
4. 4Relisez et fusionnez chaque branche comme n'importe quelle pull request.

Prompt à copier

Tu travailles dans un worktree sur la branche worktree-[nom]. Tâche : [une modification]. Terminé quand : [test ou commande] passe. Commite uniquement sur cette branche ; ne fais ni merge ni rebase d'autres branches.

Les pièges

• Chaque worktree est un dossier distinct : les dépendances et les sorties de build ne sont pas partagées. Installez-les dans chacun.
• Deux tâches qui touchent les mêmes fichiers entrent quand même en conflit à la fusion, avec ou sans worktree.

D'après la documentation officielle : Claude Code docs: Run parallel sessions with worktrees

Comment faire

1. 1Appuyez deux fois sur Esc dans un prompt vide, ou tapez /rewind (/checkpoint et /undo fonctionnent aussi).
2. 2Choisissez le point d'avant les problèmes et restaurez la conversation, le code, ou les deux.
3. 3Connaissez les limites : les fichiers modifiés par des commandes shell comme rm, mv ou cp ne sont pas restaurés, pas plus que les modifications faites en dehors de Claude Code ou dans une autre session.
4. 4Commitez avant les étapes risquées. Les checkpoints servent à récupérer rapidement au sein d'une session, ils ne remplacent pas git.

Prompt à copier

Avant de commencer, commite l'état actuel avec le message « checkpoint avant [tâche] ». Ensuite, [tâche]. Demande-moi avant toute commande qui supprime ou déplace des fichiers.

Les pièges

• Rewind ne ramène pas un fichier supprimé par une commande. Seul git le peut.
• Les modifications que vous avez faites à la main entre-temps ne sont pas capturées non plus. Commitez-les avant de revenir en arrière.

D'après la documentation officielle : Claude Code docs: Checkpointing · Claude Code docs: Commands

Comment faire

1. 1claude -p "..." s'exécute en mode non interactif. --output-format json ou stream-json produit une sortie qu'un script peut analyser.
2. 2Il renvoie 0 en cas de succès et une valeur non nulle en cas d'échec, pour que la CI puisse agir en conséquence.
3. 3Ajoutez --bare en CI pour les exécutions qui ne doivent pas dépendre de la configuration locale.
4. 4Pour les pull requests, /install-github-app configure Claude Code GitHub Actions (dépôts github.com uniquement) ; mentionnez ensuite @claude dans un commentaire de pull request ou de ticket.

Prompt à copier

claude -p "Lis le diff par rapport à main. Liste chaque modification qui ajoute une dépendance, touche à l'authentification ou modifie une migration de base de données, au format JSON : {\"files\": [], \"reason\": \"\"}. Renvoie une liste vide s'il n'y en a aucune." --output-format json

Les pièges

• Un script s'exécute avec les permissions que vous lui donnez. Donnez à la CI le strict nécessaire.
• /install-github-app ne fonctionne qu'avec des dépôts hébergés sur github.com.

D'après la documentation officielle : Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

Comment faire

1. 1Lancez /init dans la CLI pour rédiger un premier AGENTS.md dans le dossier courant.
2. 2Mettez vos consignes personnelles dans ~/.codex/AGENTS.md et les règles du projet dans le dépôt. Un sous-dossier peut avoir son propre fichier ; les fichiers les plus proches de l'endroit où Codex travaille l'emportent.
3. 3Gardez les fichiers courts : leur taille cumulée est plafonnée, à 32 KiB par défaut.
4. 4Ajoutez une section « ## Code Review Rules » : les revues de Codex sur GitHub la suivent.

Prompt à copier

Lis ce dépôt et rédige AGENTS.md :
1. Les commandes exactes pour installer, compiler, tester et linter.
2. L'organisation en quelques lignes.
3. Les conventions sur lesquelles un nouveau venu se trompe ici.
4. Une section « ## Code Review Rules » avec ce qu'un relecteur doit toujours signaler.
Ne liste que les commandes que tu as exécutées avec succès ; marque les autres « non vérifié ».

Les pièges

• Les fichiers longs jouent contre vous : la taille cumulée est plafonnée à 32 KiB par défaut.
• Un fichier de sous-dossier qui contredit celui de la racine sans le dire déroute les humains autant que Codex. Indiquez ce qu'il remplace.

D'après la documentation officielle : Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

Comment faire

1. 1Dans la CLI, /permissions change de mode, et /status affiche la politique d'approbation et les dossiers accessibles en écriture en vigueur.
2. 2Avec « Ask for approval », le mode par défaut recommandé, Codex modifie des fichiers et lance des commandes dans l'espace de travail, et s'arrête avant d'en sortir.
3. 3« Approve for me » garde le même bac à sable mais envoie les demandes d'approbation à une revue automatique plutôt qu'à vous.
4. 4« Full access » supprime les limites sur le système de fichiers et le réseau. La documentation ajoute une mise en garde ; réservez-le à des environnements jetables.

Prompt à copier

Avant de commencer, lance /status et indique-moi la politique d'approbation et les dossiers accessibles en écriture. Ensuite, [tâche]. Demande avant toute commande qui a besoin du réseau ou qui écrit en dehors de ce dépôt.

Les pièges

• Avec « Approve for me », aucune personne ne lit chaque demande. Utilisez-le là où une mauvaise action est facile à annuler.
• « Full access » s'applique à toute la machine, pas seulement au dépôt.

D'après la documentation officielle : Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

Comment faire

1. 1codex exec "..." s'exécute en mode non interactif et utilise par défaut un bac à sable en lecture seule.
2. 2Ajoutez --sandbox workspace-write quand il doit modifier des fichiers ; --full-auto est obsolète.
3. 3--json émet un flux d'événements JSON Lines pour les scripts qui ont besoin de chaque étape.
4. 4Dans GitHub Actions, openai/codex-action@v1 lance codex exec pour vous.

Prompt à copier

codex exec "Lis les modifications depuis le tag [v1.2.0]. Rédige des notes de version regroupées en Ajouts, Modifications et Corrections : une ligne par modification, avec des mots qu'un utilisateur comprend, sans hash de commit."

Les pièges

• Les anciens guides utilisent encore --full-auto. Cette option est obsolète ; utilisez --sandbox workspace-write.
• Une tâche qui ne fait que lire doit rester en lecture seule, en CI aussi.

D'après la documentation officielle : Codex docs: Non-interactive mode · Codex docs: GitHub Action

Comment faire

1. 1/review dans la CLI relit votre arbre de travail. codex review fait la même chose sans le chat, par rapport à une branche de base, un commit ou des modifications non commitées.
2. 2Sur GitHub, commentez @codex review sur une pull request.
3. 3Activez les revues automatiques dans « Personal preferences » des paramètres de Codex ; aucun commentaire n'est alors nécessaire.
4. 4Écrivez les règles de votre équipe dans une section « ## Code Review Rules » d'AGENTS.md.

Intégré

• Codex · Codex code review

Prompt à copier

## Code Review Rules
- Signale toute modification de l'authentification ou des permissions.
- Signale les migrations de base de données sans retour arrière possible.
- Signale les nouvelles dépendances et dis si elles sont nécessaires.
- Ignore la mise en forme ; le linter s'en charge.

Les pièges

• Les revues sur GitHub ne signalent que les problèmes P0 et P1. L'absence de commentaire ne signifie pas que la conception est bonne.
• Une revue est un second avis, pas une exécution de tests. Gardez les tests.

D'après la documentation officielle : Codex docs: CLI commands · Codex docs: GitHub integration

Comment faire

1. 1Créez un environnement avec les dépôts, les dépendances, les outils et les réglages d'accès dont les tâches ont besoin. Les nouveaux environnements enregistrent un script d'installation et une skill de démarrage.
2. 2Réglez l'accès à Internet par environnement : gestionnaires de paquets uniquement, domaines choisis, ou tout.
3. 3Lancez des tâches depuis ChatGPT, depuis l'extension IDE pour les tâches plus longues, ou depuis le terminal avec codex cloud exec ; --attempts 1-4 demande plusieurs tentatives à comparer.
4. 4Code Review et les intégrations GitHub et Linear fonctionnent encore sur l'ancien Codex Cloud (Legacy), qu'OpenAI prévoit de retirer.

Intégré

• Codex · Codex Cloud

Prompt à copier

codex cloud exec --attempts 3 "Tâche : [modification]. Contexte : [fichiers]. Terminé quand [test] passe dans cet environnement. Garde le diff sous les [n] lignes."

Les pièges

• Un accès Internet sans restriction permet à une tâche d'atteindre n'importe quel site, y compris des pages écrites pour la manipuler. N'autorisez que ce dont la tâche a besoin.
• S'il manque le script d'installation, les tests n'ont peut-être pas été exécutés. Vérifiez qu'une tâche les a réellement lancés.

D'après la documentation officielle : Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

Comment faire

1. 1Définissez le modèle et l'effort de raisonnement par défaut dans ~/.codex/config.toml (model et model_reasoning_effort). La CLI et l'extension IDE le partagent.
2. 2Créez un profil comme fichier distinct, ~/.codex/<name>.config.toml, et lancez avec --profile <name>.
3. 3Ajoutez des serveurs MCP avec codex mcp add <name> -- <command> ; chacun devient une table [mcp_servers.<name>], et /mcp liste ceux qui sont actifs.
4. 4/status affiche ce qui est en vigueur, et codex resume --last reprend la dernière session dans ce dossier.

Prompt à copier

Lis ~/.codex/config.toml et le fichier .codex/config.toml de ce projet. Indique-moi le modèle, l'effort de raisonnement, le bac à sable et les serveurs MCP en vigueur, de quel fichier vient chacun, et tout ce qui est en conflit.

Les pièges

• Les réglages de projet ne se chargent que pour les projets de confiance. Si l'un d'eux semble ignoré, vérifiez d'abord ce point.
• Les profils sont désormais des fichiers distincts. Les guides qui mettent [profiles.name] dans config.toml sont dépassés.

D'après la documentation officielle : Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands