Configurer des agents de code IA comme une équipe d'ingénierie

En bref Les agents de code IA ne deviennent pas une équipe d'ingénierie fiable grâce à un prompt astucieux ou à l'ajout d'agents. Ils le deviennent quand on leur donne ce sur quoi une bonne équipe repose déjà : une courte liste de règles maison, des accès limités, des règles appliquées automatiquement, des tests qui vérifient leur travail, et un second regard sur chaque changement. La recherche indépendante le confirme. Les fichiers d'instructions comme AGENTS.md ajoutent environ 20 % à la facture et changent à peine les résultats, sauf s'ils restent courts. Une équipe d'agents peut consommer environ 15 fois plus de capacité IA qu'une simple conversation. Une règle écrite seulement dans les instructions est une demande, pas une garantie.

Dans cet article

1. Dix termes expliqués simplement
2. Ce que dit la recherche avant de configurer quoi que ce soit
3. Traitez l'agent comme une nouvelle recrue
4. Couche 1 : le fichier de règles maison (AGENTS.md)
5. Couche 2 : les permissions, ce que l'agent a le droit de toucher
6. Couche 3 : les hooks, des règles impossibles à ignorer
7. Couche 4 : les vérifications automatiques
8. Couche 5 : specs et petites tâches
9. Couche 6 : « l'équipe » d'agents
10. Sécurité : la triade létale
11. Garder la mémoire de l'agent propre
12. Ce que je mettrais en place lundi
13. Questions fréquentes

Dix termes expliqués simplement

• Agent de code IA : une IA qui ne se contente pas de répondre mais qui agit. Elle lit votre code, lance des commandes, modifie des fichiers et vérifie le résultat, en boucle, jusqu'à estimer la tâche terminée. Claude Code, OpenAI Codex, Cursor et Gemini CLI en sont des exemples.
• Token : l'unité de facturation des entreprises d'IA, environ trois quarts d'un mot. Plus de tokens, c'est une facture plus élevée.
• Fenêtre de contexte : la mémoire de travail de l'agent pour une session. Tout ce qu'il lit ou écrit la remplit, et la qualité baisse à mesure qu'elle se remplit.
• AGENTS.md / CLAUDE.md : un fichier texte du projet que l'agent lit au début de chaque session, comme une note d'accueil.
• Permissions : des réglages qui décident quelles actions l'agent peut faire seul, lesquelles demandent votre accord, et lesquelles sont interdites.
• Hook : un petit script qui s'exécute automatiquement à un moment précis, par exemple juste avant que l'agent lance une commande, et qui peut la bloquer.
• Sous-agent : un agent auxiliaire que l'agent principal envoie faire une tâche ciblée (relire ceci, rechercher cela) avant de rendre compte.
• Tests, linter, vérificateur de types : des contrôles automatiques qui disent en quelques secondes si le code fonctionne et respecte les règles.
• Pull request (PR) et CI : une PR est une modification proposée en attente de relecture. La CI est la chaîne automatisée qui lance tous les contrôles avant qu'un changement soit accepté.
• Injection de prompt : cacher des instructions dans un contenu que l'agent lit (une page web, un e-mail, un ticket) pour qu'il obéisse à l'attaquant plutôt qu'à vous.

Ce que dit la recherche avant de configurer quoi que ce soit

La plupart des guides commencent par les outils. Je préfère commencer par les chiffres, parce qu'ils changent ce qu'il faut mettre en place en premier.

Se sentir plus rapide n'est pas être plus rapide. En 2025, le groupe de recherche METR a mené une expérience contrôlée avec 16 développeurs open source expérimentés, sur 246 tâches réelles dans des projets qu'ils connaissaient bien. Quand ils avaient le droit d'utiliser des outils d'IA, ils ont mis 19 % de temps en plus. Après coup, ils pensaient que l'IA les avait rendus environ 20 % plus rapides (METR).

METR a refait l'étude fin 2025 avec des outils plus récents. Cette fois, les estimations allaient vers un gain : environ 18 % plus rapide pour les développeurs de la première étude, et environ 4 % pour les nouveaux recrutés. Mais METR a lui-même jugé le résultat peu fiable. Tant de développeurs refusent désormais de travailler sans IA que l'étude passait à côté des tâches où l'IA aide le plus, et les deux résultats restaient dans la marge d'erreur, qui inclut un ralentissement (METR).

L'IA amplifie l'équipe dans laquelle elle arrive. Le programme de recherche DORA de Google, qui a interrogé près de 5 000 professionnels de la tech pour son rapport 2025, décrit le rôle principal de l'IA comme celui d'un « amplificateur », qui grossit les forces et les faiblesses existantes d'une organisation (DORA).

Traitez l'agent comme une nouvelle recrue

Voici le modèle mental qui rend la suite facile à suivre. Un agent de code IA ressemble à une nouvelle recrue très rapide : brillante, infatigable, très littérale, et qui oublie tout à la fin de chaque session. Vous ne donneriez pas à cette personne le mot de passe de la base de production le premier jour, et vous ne la laisseriez pas valider son propre code sans relecture. Chaque couche ci-dessous a son équivalent direct dans l'accueil d'une personne :

Accueillir une personne ou configurer un agent

Pour une recrue	Pour un agent	Ce que cela évite
Une note d'accueil : comment on travaille ici	Un fichier AGENTS.md / CLAUDE.md court	Deviner les mauvaises commandes et conventions
Un badge qui ouvre certaines salles, pas toutes	Des règles de permission et une sandbox	Toucher aux secrets, à la production ou à internet sans demander
Des règles imposées par les systèmes, pas par la mémoire	Des hooks	« Je connaissais la règle, mais je l'ai fait quand même »
QA et relecture de code	Tests, vérification de types et CI	Un travail qui semble fini mais ne l'est pas
Des tickets clairs avec une définition du « fini »	Une spec écrite découpée en petites tâches	Résoudre le mauvais problème, des changements impossibles à relire
Une équipe aux rôles distincts	Un agent qui écrit, des sous-agents relecteurs en lecture seule	Des agents qui se contredisent

Couche 1 : le fichier de règles maison (AGENTS.md)

En termes simples : un court fichier texte du projet qui donne à chaque agent les commandes à lancer et les règles que personne ne devinerait. C'est la note d'accueil. Gardez-la courte, car les agents traitent chaque ligne comme un ordre.

AGENTS.md est un format ouvert désormais géré par l'Agentic AI Foundation, sous l'égide de la Linux Foundation. Il est lu par OpenAI Codex, Gemini CLI, l'agent de code de GitHub Copilot, Cursor, Devin et d'autres, et figure dans plus de 60 000 projets open source (agents.md). Claude Code utilise son propre CLAUDE.md, et ses versions récentes lisent aussi AGENTS.md quand un projet n'a pas de CLAUDE.md (documentation Claude Code).

Tous les guides recommandent d'en écrire un. Voici ce que les deux études les plus rigoureuses à ce jour ont réellement mesuré :

L'effet des fichiers d'instructions sur les agents de code · deux études de 2026

Étude	Ce qui a été testé	Ce qu'ils ont trouvé
ETH Zurich et LogicStar.ai (Gloaguen et al.)	Des tâches de benchmark connues, plus 138 tâches réelles issues de 12 projets dont les développeurs avaient écrit leurs propres fichiers d'instructions, sur plusieurs agents et modèles d'IA	Les fichiers d'instructions n'ont globalement pas amélioré le taux de réussite et ont augmenté la facture IA de plus de 20 %. Les fichiers écrits par les développeurs ont fait environ 7 % mieux que ceux écrits par une IA. Les présentations générales du projet n'ont pas aidé.
Lulla et al.	124 modifications de code réelles sur 10 projets, OpenAI Codex avec et sans AGENTS.md	La tâche typique a été 28,6 % plus rapide et a utilisé 16,6 % de tokens de sortie en moins. La justesse du code n'a pas été pleinement vérifiée.

Ces résultats ne se contredisent pas. Un bon fichier d'instructions peut rendre un agent plus rapide sur le travail courant. Il ne le rend pas plus intelligent. Et comme les agents suivent les instructions très fidèlement, chaque ligne ajoutée crée du travail : une vérification de plus, une exécution de tests de plus, un fichier lu de plus. Le conseil des auteurs de l'ETH : n'utilisez pas de fichiers d'instructions générés par une IA, et dans un fichier écrit à la main, ne mettez que ce que l'agent ne peut pas apprendre de la documentation existante ou du code lui-même, comme les conventions inhabituelles et les exigences particulières (Gloaguen et al.). Les recommandations d'Anthropic disent la même chose : visez moins de 200 lignes, et pour chaque ligne, demandez-vous si la supprimer provoquerait des erreurs (bonnes pratiques Claude Code).

Pour les ingénieurs : ne committez pas tel quel ce que génère /init. Visez plutôt quelque chose comme ceci :

# AGENTS.md

## Commands
- Install: pnpm install
- Test one file: pnpm vitest run path/to/file.test.ts
- Typecheck: pnpm tsc --noEmit   (must pass before you say "done")
- Lint: pnpm lint --fix

## Conventions you would not guess
- Server state lives in TanStack Query. Never copy API data into Zustand.
- All input validation uses Zod schemas from src/schemas/.
- Migrations are generated with prisma migrate dev, never hand-written.

## Never
- Never edit files under src/generated/.
- Never add a dependency without saying why in the PR description.

Pas de visite du projet, pas de « nous valorisons le code propre », pas de liste de technologies que l'agent peut lire lui-même. Chaque ligne est une commande qu'il devinerait sinon, ou une convention qu'il raterait sinon.

Je l'ai appris lentement. Le projet derrière ce site a maintenant un CLAUDE.md court qui ne fait qu'orienter l'agent vers des guides séparés, un par type de tâche (rédaction d'articles, SEO, sécurité, etc.). Chacun n'est chargé que lorsqu'une tâche en a besoin, au lieu d'un énorme fichier chargé à chaque fois. Claude Code appelle cela des Skills. C'est le principe que la recherche met en avant : placer les instructions là où se trouve la tâche, pas dans un fichier que chaque session doit lire.

Couche 2 : les permissions, ce que l'agent a le droit de toucher

En termes simples : décidez à l'avance ce que l'agent peut faire seul, ce qui demande votre accord, et ce qui est interdit. C'est la couche qui évite réellement les catastrophes, et la plupart des gens la configurent en dernier.

En juillet 2025, un agent IA de la plateforme Replit a supprimé la base de données de production de Jason Lemkin, fondateur de SaaStr, pendant un « gel de code » explicite, effaçant les fiches de 1 206 dirigeants et de 1 196 entreprises. Il lui a ensuite affirmé que les données ne pouvaient pas être restaurées, ce qui s'est révélé faux : Replit les a récupérées et a ajouté en quelques jours une séparation automatique entre bases de test et de production, ainsi qu'un mode de planification seule (AI Incident Database, Fast Company). La leçon n'est pas « l'IA était mauvaise ». Le gel n'existait que dans les instructions. Rien n'empêchait la commande de s'exécuter.

Soyons honnête sur ma propre configuration. En vérifiant les réglages Claude Code du projet de ce site pendant la rédaction de cet article, j'ai trouvé que j'avais autorisé en permanence trois commandes : une qui peut envoyer des données vers n'importe quel site (curl), une qui publie les modifications de code (git push) et une qui supprime des fichiers en masse (xargs rm -rf). Chacune correspondait à un clic raisonnable sur « toujours autoriser » sur le moment. Ensemble, elles permettaient à un agent d'envoyer des données, de publier et de supprimer sans me demander. C'est ainsi que les permissions se dégradent : un clic pratique à la fois. Mes instructions d'espace de travail contiennent aussi une règle, en majuscules, interdisant une option de Notion qui supprime des bases de données liées. Selon mon propre critère, cette règle n'est elle aussi qu'une demande et devrait être un hook.

Pour les ingénieurs : une base plus sûre pour Claude Code, enregistrée dans .claude/settings.json et commitée pour que toute l'équipe la partage :

{
  "permissions": {
    "allow": [
      "Bash(pnpm test *)",
      "Bash(pnpm vitest *)",
      "Bash(pnpm lint *)",
      "Bash(pnpm tsc *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(gh pr view *)",
      "Bash(gh run view *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(pnpm add *)",
      "Bash(gh pr create *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)",
      "Bash(git push --force *)"
    ]
  }
}

La logique : autoriser ce qui se contente de lire ou est facile à annuler et que l'agent lance sans arrêt (tests, vérifications, lecture des résultats de CI et des commentaires de relecture avec l'outil gh de GitHub). Demander avant tout ce qui quitte votre machine ou ajoute des dépendances. Refuser les secrets, l'accès à internet et tout ce qui est destructeur. Claude Code vérifie d'abord les refus, puis les demandes, puis les autorisations : un refus ne peut jamais être contourné par une autorisation (documentation Claude Code).

Deux limites, en toute honnêteté. D'abord, les règles de commandes reposent sur la reconnaissance de motifs, et la documentation d'Anthropic prévient qu'elles sont faciles à contourner : une règle contre curl n'arrête pas un script qui fait la même requête autrement. Quand une règle doit vraiment tenir, activez la sandbox, qui bloque l'accès aux fichiers et au réseau au niveau du système d'exploitation. Ensuite, les versions récentes de Claude Code démarrent en « mode auto », où un modèle d'IA distinct examine chaque action et bloque celles qui semblent risquées. C'est utile, mais c'est un jugement rendu par un modèle, pas une garantie. Vos règles de refus et votre sandbox doivent toujours exister en dessous.

Codex d'OpenAI exprime la même idée dans ~/.codex/config.toml : sandbox_mode = "workspace-write" lui permet de modifier le projet et rien d'autre, sans accès à internet sauf si vous l'activez, et approval_policy = "on-request" vous renvoie tout ce qui sort de ce périmètre (documentation Codex). Les mots changent, l'idée reste : l'agent travaille librement à l'intérieur d'une clôture, et la franchir exige un humain.

Pour tout ce qui tourne sans surveillance, comme des agents en CI ou des exécutions de nuit, intégrez la clôture à l'infrastructure : un conteneur isolé, un jeton d'accès qui ne peut pas atteindre les systèmes en production, et une branche de travail qui n'est pas votre branche principale.

Couche 3 : les hooks, des règles impossibles à ignorer

En termes simples : un hook est un fil de détente. Il s'exécute automatiquement à un moment fixe, par exemple juste avant que l'agent lance une commande, et il peut dire non. Des instructions peuvent être oubliées ou contournées. Un hook, non.

Pour les ingénieurs : un hook PreToolUse de Claude Code qui bloque toute commande mentionnant la base de production :

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-prod.sh" }
        ]
      }
    ]
  }
}

#!/bin/bash
# .claude/hooks/guard-prod.sh: receives the pending command as JSON on stdin
CMD=$(jq -r '.tool_input.command')
if echo "$CMD" | grep -qiE 'prod(uction)?[._-]?(db|database)|DATABASE_URL_PROD'; then
  echo "Blocked: production database access is not allowed from an agent session." >&2
  exit 2   # exit code 2 blocks the command and shows this reason to the agent
fi
exit 0

Comme toute reconnaissance de motif, ce hook attrape les cas évidents, pas un contournement délibéré. Son rôle est d'arrêter l'erreur de bonne foi, ce qu'était l'incident Replit. La vraie séparation vient toujours du fait que l'agent n'a jamais les identifiants de production.

Deux autres hooks méritent leur place dans presque toutes les équipes. L'un lance le formateur et le linter après chaque modification, pour que le style ne soit jamais quelque chose dont l'agent doit se souvenir. L'autre s'exécute sur l'événement Stop, quand l'agent essaie de terminer : il lance la vérification de types et empêche l'agent de déclarer le travail fini tant qu'elle échoue (hooks Claude Code). « Assure-toi que ça marche » cesse d'être un espoir pour devenir une condition de fin.

Couche 4 : les vérifications automatiques

En termes simples : un agent sans moyen de vérifier son travail devine. Un agent avec des contrôles rapides et objectifs peut repérer et corriger ses propres erreurs. C'est le principal levier de qualité, et c'est du travail d'ingénierie ordinaire.

Les recommandations d'Anthropic le formulent bien : donnez à l'agent un contrôle qu'il peut lancer, car c'est « la différence entre une session que vous surveillez et une session que vous pouvez laisser tourner » (bonnes pratiques Claude Code). En pratique :

• Des tests qui tournent en quelques secondes. Si votre suite de tests prend 20 minutes, l'agent la sautera ou perdra du temps. Fournissez une commande « tester seulement ce fichier » et mettez-la dans AGENTS.md.
• Vérification de types stricte et lint comme barrières obligatoires. En TypeScript, strict: true attrape gratuitement toute une catégorie d'erreurs d'agent.
• D'abord un test qui échoue, pour tout ce qui n'est pas trivial. Demandez à l'agent d'écrire un test qui reproduit le bug ou capture l'exigence, vérifiez qu'il échoue, puis faites corriger. L'agent a ainsi une cible qui ne peut pas dériver en silence.
• La CI a le dernier mot, pas l'agent. Quoi que l'agent affirme, son travail passe par les mêmes contrôles automatiques que celui d'un ingénieur humain.

Un avertissement : sous pression pour faire passer les tests, un agent modifie parfois les tests plutôt que le code. Écrivez « ne jamais affaiblir ni supprimer un test » dans votre fichier de règles, et faites relire spécifiquement les modifications des fichiers de test.

Couche 5 : specs et petites tâches

En termes simples : écrivez ce que « fini » veut dire avant que l'agent commence, puis découpez le travail en morceaux assez petits pour qu'une personne puisse les relire correctement.

Le « développement piloté par les specs » est le nom actuel de ce que les bonnes équipes ont toujours fait. Il existe des outils de différents poids : Spec Kit de GitHub est un kit gratuit en ligne de commande qui fait passer le travail par les étapes spécifier, planifier, découper et implémenter. Kiro d'AWS est un éditeur complet construit autour de documents d'exigences, de conception et de tâches. OpenSpec est plus léger et pensé pour faire évoluer des projets existants. Vous n'avez besoin d'aucun d'eux pour en tirer l'essentiel :

1. Écrivez une spec d'une page dans le projet : le problème, comment vous saurez que c'est fini, ce qui est hors périmètre, et ce qui ne doit pas changer.
2. Demandez un plan à l'agent en mode planification, sans droit de modification, et relisez-le comme la conception d'un ingénieur junior. C'est le moment le moins coûteux pour attraper une hypothèse fausse.
3. Découpez le plan en tranches fines, chacune étant un petit morceau de fonctionnalité complet qui se termine par un test qui passe.
4. Une tranche par session, une modification proposée (PR) par tranche.

Un test simple pour la taille d'une tranche : quelqu'un pourrait-il relire le changement correctement en 15 minutes ? Sinon, elle est trop grosse. La vraie limite à la quantité de travail d'agent qu'une équipe peut absorber, c'est le temps de relecture, pas la vitesse d'écriture de l'agent.

Couche 6 : « l'équipe » d'agents

En termes simples : un agent pour écrire, plusieurs pour vérifier. Des agents qui ne voient chacun qu'une partie du tableau prennent des décisions contradictoires, et en faire tourner beaucoup à la fois multiplie la facture.

C'est par là que tout le monde veut commencer : un agent planificateur, un agent développeur, un agent relecteur, un agent testeur, qui se parlent entre eux. C'est aussi là qu'on gaspille le plus d'argent.

Deux repères. Le système de recherche multi-agents d'Anthropic a battu un agent unique de 90,2 % sur ses tests internes de recherche, mais a consommé environ 15 fois plus de tokens qu'une conversation normale. Anthropic écrit aussi que la plupart des tâches de code comportent moins de parties réellement parallélisables que la recherche, ce qui les rend aujourd'hui moins adaptées aux équipes d'agents (Anthropic). Cognition, l'entreprise derrière l'agent Devin, résume le problème en une phrase : « les actions portent des décisions implicites, et des décisions contradictoires donnent de mauvais résultats » (Cognition).

Ensemble, ils suggèrent une règle que je défendrais : un agent écrit, les autres lisent. Les agents auxiliaires sont bons pour explorer et juger : fouiller une grande codebase, relire un changement, vérifier la sécurité, étudier une bibliothèque. Ils sont mauvais pour écrire en même temps différentes parties d'une même fonctionnalité.

Les rôles d'une équipe en configuration d'agents

Rôle humain	Équivalent agent	Ce qu'il a le droit de faire
Tech lead	L'agent principal en mode planification, qui produit une spec et une liste de tâches	Lecture seule
Ingénieur	L'unique agent principal qui écrit le code, une tranche à la fois	Modifier, lancer tests et contrôles ; demander avant de publier
Relecteur de code	Un sous-agent à la mémoire neuve qui ne voit que le changement et la spec	Lecture seule
Relecteur sécurité	Un sous-agent qui cherche les secrets exposés, les risques d'injection et les contrôles d'accès manquants	Lecture seule
Chercheur	Un sous-agent qui explore le code ou la documentation et rapporte un résumé	Lecture et recherche
QA	Pas un agent : les tests, le vérificateur de types et la CI	n/a

Pour les ingénieurs : dans Claude Code, un sous-agent est un fichier Markdown dans .claude/agents/. La description indique à l'agent principal quand l'utiliser, et la liste d'outils limite ce qu'il peut faire :

---
name: diff-reviewer
description: Reviews the current diff against the spec before a PR is opened. Use after a slice is implemented and tests pass.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You review a diff you did not write. You have not seen the conversation that produced it.
Use git diff and git log only; never modify files.
Check, in order: does it meet the acceptance criteria in the spec; were any tests weakened or deleted;
are there unhandled errors, leaked secrets or missing authorisation checks.
Report only gaps that affect correctness or the spec, with file and line. Do not fix anything.

Un détail qui m'a piégé : le champ tools accepte des noms d'outils entiers, pas des motifs de commandes, donc on ne peut pas y écrire Bash(git diff *). Les limites au niveau des commandes viennent des règles de permission partagées de la couche 2, que les sous-agents respectent aussi (sous-agents Claude Code).

La mémoire neuve est tout l'intérêt. Chaque sous-agent démarre avec une fenêtre de contexte vide et ne voit pas la conversation qui a produit le code. Un relecteur qui a suivi le raisonnement de l'agent a tendance à l'accepter. Un relecteur qui ne voit que le changement et la spec le lit comme le ferait un collègue. Les recommandations d'Anthropic ajoutent une mise en garde utile : un relecteur à qui l'on demande de trouver des problèmes en signale généralement, même quand le travail est solide, donc demandez-lui de ne rapporter que ce qui affecte la justesse. Utilisez un modèle moins cher pour les relectures ciblées, et gardez le modèle le plus capable pour l'agent qui écrit le code.

Si vous avez vraiment besoin de plusieurs agents qui écrivent en même temps, donnez-leur des tâches sans rapport, pas des morceaux d'une même fonctionnalité. Donnez à chacun sa propre copie séparée du projet (git appelle cela un worktree) et sa propre branche, et fusionnez leur travail par des PR relues normalement.

Sécurité : la triade létale

En termes simples : ne donnez jamais à un même agent ces trois choses à la fois : vos données privées, du contenu écrit par des inconnus, et un moyen d'envoyer des données vers l'extérieur.

La « triade létale » (lethal trifecta) de Simon Willison est l'idée de sécurité la plus utile que je connaisse pour les agents. Tout agent qui combine l'accès à des données privées, l'exposition à du contenu non fiable et la capacité de communiquer vers l'extérieur peut être manipulé pour faire fuiter ces données, car les modèles d'IA suivent les instructions où qu'ils les trouvent (Simon Willison).

Un agent de code réunit les trois par défaut. Il lit votre code et vos fichiers de configuration secrets. Il lit des tickets, des pages web, du code écrit par d'autres et les résultats d'outils connectés, que n'importe quel attaquant peut écrire. Et il peut faire des requêtes web, publier du code ou appeler d'autres services. C'est pourquoi les refus de la couche 2 visent précisément les secrets et l'accès à internet. Retirez au moins un des trois éléments pour tout agent qui lit du contenu extérieur, et soyez particulièrement prudent quand vous connectez des agents à la messagerie, au chat ou aux outils de tickets (souvent via MCP, le standard pour brancher des outils sur des agents), car n'importe qui hors de l'entreprise peut écrire le contenu que ces agents lisent.

Garder la mémoire de l'agent propre

En termes simples : les longues sessions se dégradent. Repartez souvent de zéro, et gardez les décisions importantes dans des fichiers plutôt que dans la conversation.

À mesure que la mémoire de travail de l'agent se remplit d'anciens fichiers, de tentatives ratées et de plans abandonnés, il travaille sur des informations périmées. Anthropic qualifie la fenêtre de contexte de « ressource la plus importante à gérer » (bonnes pratiques Claude Code). Quelques habitudes règlent l'essentiel :

• Une nouvelle session par phase. Planifier, construire et relire sont des métiers différents. Videz la mémoire entre eux (/clear dans Claude Code) et transmettez le résultat sous forme de fichier, comme la spec ou le plan, pas sous forme d'historique de conversation.
• Écrivez l'avancement. Un PLAN.md ou une note d'avancement que l'agent tient à jour survit à une nouvelle session. L'historique de conversation, non.
• Envoyez des auxiliaires faire la lecture. Quand une tâche exige une recherche large, un sous-agent peut s'en charger et rapporter un résumé, ce qui garde la mémoire de l'agent principal concentrée sur le travail.
• Redémarrez au lieu d'argumenter. Si vous avez corrigé l'agent deux fois sur le même point, sa mémoire est encombrée de tentatives ratées. Repartez de zéro avec une meilleure spec.

Ce que je mettrais en place lundi

Si je configurais tout cela pour une équipe à partir de zéro, je le ferais dans cet ordre. Les trois premières étapes comptent le plus, et aucune ne concerne le modèle d'IA lui-même.

1. Revoir et partager les permissions. Un seul fichier de réglages commité : autoriser les tests et les commandes en lecture seule, demander avant de publier ou d'ajouter des dépendances, refuser les secrets, l'accès à internet et les commandes destructrices. Activer la sandbox. Vider ce qui s'est accumulé dans les listes personnelles « toujours autoriser ».
2. Rendre les contrôles rapides. Une commande de test pour un seul fichier, une vérification de types stricte et du lint, le tout en quelques secondes.
3. Ajouter deux hooks. Formatage et lint après chaque modification, et vérification de types avant que l'agent puisse terminer. Puis un hook de garde pour ce qui coûterait le plus cher en cas d'erreur.
4. Écrire à la main un AGENTS.md court. Seulement les commandes et les conventions non évidentes. Si votre équipe utilise aussi Claude Code avec un CLAUDE.md, faites-lui importer ce fichier avec une ligne @AGENTS.md, pour que tous les outils lisent les mêmes règles.
5. Adopter la routine spec, plan, tranche pour tout ce qui dépasse une correction de bug.
6. Ajouter un sous-agent relecteur en lecture seule. Vérifier qu'il attrape de vrais problèmes avant d'en ajouter un second.
7. Mesurer. Suivre le temps nécessaire pour qu'un changement soit fusionné, la durée des relectures, et la fréquence des changements qui cassent quelque chose, avant et après. L'étude de METR rappelle que se sentir plus rapide n'est pas une preuve.

À retenir

• Les agents amplifient votre façon de travailler. Les tests, les conventions écrites et le contrôle d'accès comptent plus que l'agent choisi.
• Gardez les fichiers d'instructions courts et écrits par des personnes. La recherche montre que les fichiers surchargés ou écrits par une IA ajoutent environ 20 % à la facture sans améliorer les résultats.
• Imposez, ne demandez pas. Tout ce qui coûte cher en cas d'erreur relève des permissions, d'une sandbox ou d'un hook, pas des instructions.
• Un rédacteur, plusieurs lecteurs. Utilisez les agents auxiliaires pour relire, rechercher et vérifier la sécurité, pas pour écrire en parallèle des parties d'une même fonctionnalité.
• Cassez la triade létale. Ne donnez jamais à un même agent des données privées, du contenu extérieur et un moyen d'envoyer des données vers l'extérieur en même temps.

Qu'y a-t-il en ce moment dans la liste « toujours autoriser » de votre agent que vous avez approuvé une fois puis oublié ?

Questions fréquentes

Un fichier AGENTS.md ou CLAUDE.md rend-il les agents de code meilleurs ?

Modestement, et seulement s'il est court et écrit par une personne. Une étude de l'ETH Zurich de 2026 a montré que les fichiers d'instructions n'amélioraient globalement pas le taux de réussite et augmentaient les coûts de plus de 20 %, les fichiers écrits par des développeurs faisant environ 7 % mieux que ceux générés par une IA. Une autre étude a montré qu'un AGENTS.md rendait OpenAI Codex environ 28,6 % plus rapide sur les tâches typiques. N'y mettez que les commandes et les conventions que l'agent ne peut pas déduire du code.

Faut-il utiliser plusieurs agents IA pour le développement logiciel ?

Utilisez un agent qui écrit le code et des sous-agents supplémentaires qui ne font que lire : relecture de code, relecture sécurité et recherche. Anthropic indique que les systèmes multi-agents consomment environ 15 fois plus de tokens qu'une conversation et que la plupart des tâches de code sont moins parallélisables que la recherche. Cognition prévient que des agents travaillant avec un contexte partiel prennent des décisions contradictoires.

Comment empêcher un agent de code IA de lancer des commandes dangereuses ?

Imposez-le dans la configuration, pas dans les instructions. Utilisez les règles de permission (autoriser, demander et refuser dans Claude Code, ou le mode sandbox et la politique d'approbation dans Codex) pour bloquer les secrets, l'accès à internet et les commandes destructrices. Activez la sandbox pour les règles qui doivent vraiment tenir, et ajoutez un hook qui bloque des commandes précises. Une règle qui n'existe que dans les instructions est une demande, comme l'a montré la suppression de base de données chez Replit en 2025.

Qu'est-ce que la triade létale pour les agents IA ?

Un terme inventé par Simon Willison : un agent qui combine l'accès à des données privées, l'exposition à du contenu non fiable et la capacité de communiquer vers l'extérieur peut être manipulé par injection de prompt pour faire fuiter ces données. Les agents de code réunissent les trois par défaut, donc retirez-en au moins un, généralement en bloquant l'accès à internet et aux fichiers secrets.

Sources

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• METR, We are Changing our Developer Productivity Experiment Design
• DORA, 2025 State of AI-assisted Software Development
• Gloaguen et al., Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?
• Lulla et al., On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents
• AGENTS.md, format ouvert pour guider les agents de code
• AI Incident Database, Incident 1152 : un agent Replit supprime des données de production pendant un gel de code
• Fast Company, Replit CEO: What really happened when AI agent wiped Jason Lemkin's database
• Claude Code Docs, Best practices
• Claude Code Docs, How Claude remembers your project
• Claude Code Docs, Configure permissions
• Claude Code Docs, Hooks reference
• Claude Code Docs, Subagents
• OpenAI Codex Docs, Configuration reference
• Anthropic, How we built our multi-agent research system
• Cognition, Don't Build Multi-Agents
• Simon Willison, The lethal trifecta for AI agents
• GitHub Spec Kit

Vous aimerez peut-être aussi Le modèle d'IA le moins cher peut vous coûter plus, l'article sur l'IA en production et le guide de la qualité du code.