Le fantasme actuel, c’est l’agent qui “se débrouille”. Le problème, c’est que dans un repo réel, se débrouiller veut souvent dire toucher aux mauvais fichiers, oublier un test, contourner un garde-fou, ou “simplifier” une sécurité parce qu’elle gêne. L’agent n’est pas méchant. Il optimise pour finir la tâche. Et si tu ne lui donnes pas un cadre, il va inventer le cadre à ta place.
Les nouveautés agentic côté IDE (notamment Copilot dans JetBrains, avec découverte de fichiers d’instructions type AGENTS.md, commande /memory, et auto-approve configurable pour MCP) rendent ce sujet très concret. On peut enfin faire du “moins d’interruptions” sans tomber dans le “vas-y, fais ce que tu veux”. À condition d’écrire deux ou trois règles simples, mais non négociables.
Un agent sans cadre ne “code” pas, il produit du diff
Sur un projet un peu vivant, le risque n’est pas que l’agent écrive du mauvais code au sens “ça ne compile pas”. Le risque, c’est qu’il modifie le contrat implicite du repo. Il peut déplacer de la logique hors d’un module prévu pour ça, créer un nouveau pattern au milieu d’un codebase stable, ignorer des conventions de tests, ou ajouter une dépendance parce que “ça marche” localement. À la fin, tu as une PR qui passe peut-être les checks, mais qui coûte cher en maintenance.
Et quand tu lui donnes des capacités d’action (outils, accès repo, accès services via MCP), le problème n’est plus seulement la qualité. C’est le périmètre. Un agent qui peut lire partout, écrire partout, et appeler des outils “sans demander”, ça ressemble vite à un stagiaire hyper rapide… à qui tu aurais donné des droits prod.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
AGENTS.md : le contrat simple entre ton repo et l’agent
Le bon usage d’un AGENTS.md, ce n’est pas d’écrire un roman. C’est d’écrire un contrat de travail en 30 lignes. Le but est double : cadrer le style et cadrer la zone d’action. Le style, c’est pour éviter les PR “hors sol”. La zone d’action, c’est pour éviter les changements toxiques, surtout ceux que personne ne relit vraiment (config, CI, scripts, sécurité, permissions).
Ce que je veux voir dans un AGENTS.md utile : des conventions de code qui existent déjà (et qu’on veut garder), une liste claire des fichiers sensibles, une “definition of done” pragmatique, et les commandes de tests à lancer. Ça suffit à transformer un agent bavard en agent exploitable.
Conventions : pas “le style du monde”, le style de ce repo
Évite les règles génériques du genre “écris du code propre”. Ça ne sert à rien. Par contre, des consignes comme “on n’introduit pas de nouvelle lib pour une petite fonction”, “on garde le même framework de tests”, “on suit les patterns du dossier src/foo”, ça évite 80% des dérapages. L’agent est très bon pour imiter. Donne-lui quelque chose d’imitable.
J’aime bien être explicite sur les “non” : pas de refactor massif non demandé, pas de renommage de masse, pas de changements de formatting sans raison, pas de modification de l’outillage (CI, linter, pre-commit) sans validation humaine. C’est sec, mais ça marche.
Périmètre : les fichiers autorisés, et les zones où il doit lever la main
Si tu dois retenir une idée : sépare ce qui est “feature code” de ce qui est “gouvernance”. L’agent peut être très utile dans le code applicatif. Dans la gouvernance (CI, sécurité, secrets, scripts de déploiement, permissions), il doit te demander.
Concrètement, nomme les zones sensibles. Pas en mode parano, en mode “ça coûte cher si c’est touché”. Typiquement : .github/, les pipelines, les scripts de release, les manifests d’infra, les configs de SSO, les policies, les fichiers qui gèrent des tokens, et tout ce qui touche au réseau sortant.
Definition of done : ce que “terminé” veut dire ici
Le piège avec un agent, c’est qu’il peut s’arrêter au moment où “ça compile”. Donc tu écris noir sur blanc ce que tu attends : tests, non-régression, logs, migrations, et une explication claire du changement. Si tu veux un niveau de preuve minimal, tu le dis. Sinon tu vas le redécouvrir à la troisième PR cassée.
Et oui, mets les commandes. Même si c’est obvious pour toi. L’agent n’a pas ton muscle memory.
# AGENTS.md
Ce repo a des conventions. Si une règle manque, demande avant d'inventer.
## Portée
- Tu peux modifier : src/**, tests/**
- Tu dois demander avant de modifier : .github/**, scripts/**, infra/**, docs/policies/**
- Ne modifie jamais : fichiers de secrets, clés, tokens, ou exemples de secrets.
## Conventions
- Pas de nouvelle dépendance sans justification explicite.
- Pas de refactor massif non demandé.
- Garde les patterns existants (structure des dossiers, style des tests, naming).
## Definition of done
- Les tests passent localement (commande ci-dessous).
- Les changements sont minimaux et expliqués dans la PR.
- Pas de modification de garde-fous (auth, permissions, validation) sans validation humaine.
## Commandes
- Lint : npm run lint
- Tests : npm test
- Build : npm run build
Dernier point, très terre-à-terre : si ton AGENTS.md est trop long, personne ne le maintient. Si personne ne le maintient, il ment. Et un fichier d’instructions qui ment, c’est pire que pas d’instructions du tout.
/memory : pratique pour stabiliser, dangereux pour “se souvenir” de tout
La commande /memory (ou l’équivalent, selon l’outil) est tentante : tu as enfin un agent qui “retient” des choses. Je la trouve vraiment utile pour les faits stables et répétitifs. Typiquement, une convention de nommage, le fait qu’on n’utilise pas telle lib, le chemin d’un dossier à ne pas toucher, ou la commande de tests “qui est la vraie”.
En revanche, je suis beaucoup plus dur sur tout ce qui est volatile, sensible ou contextuel. Pas de secrets, évidemment. Pas de tokens, pas d’URLs internes, pas de dumps. Mais aussi pas de “notes” qui risquent de survivre à une refonte. Un agent qui se souvient d’une règle périmée, c’est un agent qui va casser le repo avec beaucoup d’assurance.
Mon standard : la mémoire doit être revue comme du code. Si l’équipe ne serait pas à l’aise de mettre l’info dans le repo, alors elle n’a rien à faire dans une mémoire persistante. Et si la mémoire sert à contourner une discussion (“on verra plus tard”), c’est un anti-pattern. Mieux vaut mettre une règle courte dans AGENTS.md ou ouvrir une issue.
Auto-approve MCP : gagner du temps sans ouvrir un accès illimité
MCP, c’est le moment où ton agent arrête d’être “juste du texte” et commence à utiliser des outils. Et l’auto-approve, c’est le moment où tu enlèves des confirmations. Ça peut être un énorme boost de productivité, surtout sur les tâches de lecture et de collecte d’infos. Mais c’est aussi exactement le genre de feature qui te fait franchir une frontière sans t’en rendre compte.
La règle que j’applique : auto-approve OK pour du read bien borné, très rarement OK pour du write. Lire des fichiers, inspecter un arbre de projet, récupérer des infos de doc interne, pourquoi pas. Écrire, déclencher, supprimer, publier, migrer, ça doit remonter une confirmation humaine, même si c’est pénible. L’objectif n’est pas d’empêcher l’agent d’agir. L’objectif est de l’empêcher d’agir dans le mauvais contexte.
Le deuxième garde-fou, c’est l’allowlist. Pas “l’agent peut appeler tous les outils”. Plutôt “l’agent peut appeler ces 2 outils, dans ces 2 modes, sur ces 2 scopes”. Et si ton outil le permet, ajoute une contrainte de logs. Tu veux pouvoir reconstituer ce qu’il a fait, quand, et avec quels inputs. Sinon tu vas déboguer un comportement fantôme.
Enfin, fais attention aux effets de bord. Un outil “inoffensif” peut devenir dangereux si l’agent peut le chaîner. Exemple classique : il lit une config, déduit un endpoint, appelle un service, récupère un token dans une réponse, et te le recolle dans un fichier parce que “c’est pratique”. Ce n’est pas de la malveillance. C’est de l’optimisation stupide. Et ça se prévient avec des règles explicites sur les secrets et sur les fichiers interdits.
La revue PR “agent-generated” : le rituel qui évite les surprises
Je traite une PR générée par agent comme une PR normale, sauf que je change mon focus. Je ne cherche pas seulement “est-ce que ça marche”. Je cherche “qu’est-ce que ça a touché qui n’aurait pas dû être touché”. L’agent est très bon pour faire des modifications annexes qui ont l’air logiques. Et c’est exactement ça qui mord en prod.
Tests : je veux voir des tests passés, et pas juste “ça compile”. Si le repo a des tests lents, tant pis. Ou alors on explicite dans AGENTS.md ce qui est acceptable localement et ce qui doit tourner en CI. Mais il faut un contrat clair, pas un flou artistique.
Diff suspect : je scanne les fichiers “bizarres” pour la tâche. Modification de pipeline, de config, de scripts, de droits, de dépendances, de lockfile, de Dockerfile. Parfois c’est justifié. Souvent, non. Et si c’est justifié, je veux une explication nette dans la PR, pas une phrase vague.
Garde-fous : je cherche les suppressions silencieuses. Une validation en moins, un check auth déplacé, un timeout augmenté “pour que ça passe”, une désactivation de sécurité parce que “ça échouait”. C’est le genre de micro-changement qui ne se voit pas au milieu d’un gros diff, et qui coûte une journée plus tard.
Secrets et accès : je pars du principe que tout ce qui ressemble à un token, une clé, une URL interne, un header d’auth, doit être considéré contaminé tant qu’on n’a pas prouvé le contraire. Et je préfère mille fois une PR qui dit “j’ai besoin de cet accès, peux-tu le faire toi” qu’une PR qui a “magiquement” réussi à se connecter.
Mon standard minimal en équipe : utile, pas bureaucratique
Si tu veux un setup qui marche sans transformer ça en gouvernance lourde, je ferais simple. Un AGENTS.md au root, court, maintenu, relu quand on change la CI ou les conventions. Une politique claire sur /memory (facts stables uniquement, jamais de sensible). Et une config MCP où l’auto-approve est réservé aux opérations de lecture, avec un périmètre explicite.
Le reste, c’est de la discipline de PR. Taguer ou mentionner clairement qu’une PR est “agent-generated”, et assumer que la revue doit être un peu plus attentive sur les zones à risque. Ça ne tue pas la productivité. Au contraire, ça évite l’effet yo-yo où tu actives l’agent, tu te fais peur, tu le coupes, puis tu le réactives en douce six semaines plus tard.
