Plan de la formation
Ingénierie agentique : la formation pratique · Module 2: L’ingénierie du contexte
Des fichiers d’instructions de dépôt qui marchent (AGENTS.md / CLAUDE.md)
Rédigez un court fichier d’instructions qui dit aux agents comment bâtir, tester et se comporter dans votre code, et gardez-le assez léger pour vraiment aider.
Leçon 6 / 24 · ⏱ 8 min
À chaque nouvelle session, l’agent arrive dans votre dépôt comme un contractuel à sa première journée. Il ne sait pas comment vous roulez les tests, quel dossier est du legacy, ni que personne ne touche au client généré à la main.
Un fichier d’instructions de dépôt, c’est la note collée sur la porte. La plupart des agents de code en cherchent un (avec des noms comme AGENTS.md ou CLAUDE.md) et le chargent automatiquement au début de chaque session. Vérifiez dans la doc de votre outil le nom exact du fichier et s’il lit aussi ceux des sous-dossiers.
Comment il se rend à l’agent
- Vous l’écrivezDu markdown simple à la racine du dépôt
- La session démarreL’agent le charge avant votre brief
- À chaque étapeIl oriente chaque lecture, modification et commande
- Vous l’ajustezQuand l’agent répète une erreur
↺ Chaque erreur répétée est une ligne que vous n’avez pas encore écrite
Ce dernier point compte. Comme il se charge chaque fois, le fichier fait partie de la portion fixe de votre budget de contexte (leçon 2.1). Un fichier gonflé taxe chaque tâche, sans exception.
Ce qui entre, ce qui reste dehors
✕ Des fichiers qui n’aident pas
- –Une copie de l’intro marketing du README
- –« Écris du code propre et maintenable » et autres vertus vagues
- –Tout le document d’architecture collé tel quel
- –Des règles que personne n’applique et que le linter couvre déjà
- –Des contradictions accumulées au fil de trois ans de modifications
✓ Des fichiers qui marchent
- +Les commandes exactes : installer, bâtir, tester un fichier, linter
- +Où se trouvent les choses, en cinq à dix lignes
- +Des règles fermes avec une raison : « ne jamais modifier /gen, il est régénéré »
- +Des liens vers la doc détaillée plutôt que des copies
- +Comment savoir qu’on a fini : quelles vérifications doivent passer
Voici la forme de départ que j’utilise. Elle est courte exprès. Adaptez les commandes et les chemins à votre stack.
# Instructions pour l'agent
## Commandes
- Installer : pnpm install
- Rouler un fichier de tests : pnpm test chemin/vers/fichier.test.ts
- Vérification complète avant de finir : pnpm lint && pnpm typecheck && pnpm test
## Structure
- apps/web : front-end Next.js
- packages/billing : logique de prix et de facturation (montants en cents entiers)
- packages/api-client : GÉNÉRÉ, ne jamais modifier à la main, rouler pnpm gen
## Règles
- Ajouter ou mettre à jour un test pour chaque changement de comportement.
- Ne pas ajouter de dépendance sans expliquer pourquoi dans le résumé.
- Les migrations de base de données sont dans db/migrations; ne jamais modifier une migration déjà appliquée.
## Plus de contexte
- Règles de facturation : docs/billing.md
- Conventions de gestion d'erreurs : docs/errors.mdPetite vérification
🧠 Vérification : fichier d’instructions
Pointage: 0 / 4
1. Votre agent roule toujours toute la suite de tests, qui prend 12 minutes. Quelle est la meilleure solution?
2. Pourquoi garder le fichier d’instructions court?
3. Quelle ligne est la plus utile?
4. L’agent a fait la même erreur deux fois cette semaine. Que faites-vous?
Les conventions d’équipe pour ces fichiers, et le partage de prompts dans une équipe, reviennent au module 6.
Avant de continuer
✅ À retenir
0 / 5 complété