Les agents LLM modifient votre code.
Sans workflow structuré, vous perdez :
Ce module est référencé dans tous les TP.
Appliquez-le systématiquement.
# JAMAIS travailler sur main/master directement
git checkout main
git pull origin main
git checkout -b feature/nom-de-la-feature
Pourquoi ?
Un commit = Une logique.
# BON : commits atomiques
git add src/auth.ts
git commit -m "feat: add JWT token validation"
git add src/middleware.ts
git commit -m "feat: add auth middleware"
git add tests/auth.test.ts
git commit -m "test: add auth JWT tests"
# MAUVAIS : un gros commit
git add .
git commit -m "feat: add auth system with tests and fixes and refactors"
Comment écrire un bon message :
<type>: <description courte>
Types possibles:
- feat: nouvelle fonctionnalité
- fix: correction de bug
- refac: refactoring
- test: ajout de tests
- docs: documentation
- chore: tâche maintenance
Git est votre fenêtre sur ce que l’agent fait.
# Avant de demander à l'agent
git status # Vérifier l'état
# Après que l'agent a fait des changements
git diff # Voir exactement ce qui a changé
# Si l'agent modifie 50 fichiers
git diff --stat # Vue d'ensemble
# Isoler les changements par fichier
git diff src/specific-file.ts
Pattern de sécurité :
YOU: "Add authentication to the app"
AGENT: [modifies 12 files]
YOU:
git diff --stat
# Hmm, pourquoi setup.py a changé ?
git diff setup.py
# L'agent a ajouté une dépendance suspicieuse ?
# Questionner l'agent avant de commit
# Push à chaque milestone
git push origin feature/ma-feature
# En cas de problème majeur
git reset --hard origin/feature/ma-feature # Revenir au dernier push
Isolation des environnements agents.
| Avantage | Description |
|---|---|
| Sandbox | L’agent ne peut pas casser votre système |
| Reproductibilité | Même environnement pour toute l’équipe |
| Cleanup facile | docker rm et c’est propre |
Container = Protection du filesystem.
# Dockerfile pour agent sandbox
FROM node:20-slim
WORKDIR /app
# Pas de volumes sensibles
# Pas de USER root (si possible)
# Network limité
COPY package*.json ./
RUN npm install
COPY . .
CMD ["bash"]
# Lancer un agent dans un container
docker build -t agent-sandbox .
docker run -it --rm \
-v $(pwd):/app \
agent-sandbox \
bash
# L'agent travaille dans /app
# Il ne peut pas toucher au reste du système
Alternative : User Linux sans permissions.
# Créer un user limité
sudo useradd -m -s /bin/bash agentuser
# Donner accès uniquement au projet
sudo chown -R agentuser:agentuser /path/to/project
# Lancer les commande agent en tant que agentuser
sudo -u agentuser bash
cd /path/to/project
# L'agent ne peur pas toucher à ~, /etc, etc.
Avantages :
Inconvénients :
Les agents génèrent du code “slop” - code inutile qu’il faut nettoyer.
| Type | Exemple | Pourquoi c’est un problème |
|---|---|---|
| Commentaires TODO | // TODO: improve this |
Reste dans le code |
| Code commenté | // function oldVersion() |
Pollue le code |
| Imports inutilisés | import { unused } |
Bundle size |
| Console.log | console.log("debug") |
Logs en production |
| Fonctions mortes | function oldHelper() |
Maintenance burden |
| Types inutilisés | interface OldFormat |
Confusion |
# APRÈS que l'agent a fini, AVANT de commit
git diff --stat
# Vérifier quels fichiers sont modifiés
# Identifier le slop
git diff src/new-feature.ts
# L'agent a-t-il laissé des console.log ?
# Des commentaires TODO ?
# Des imports inutilisés ?
# Demander le cleanup
YOU: "Remove all console.log, commented code, and unused imports from src/new-feature.ts"
# Re-vérifier
git diff src/new-feature.ts
# Maintenant commit propre
git add src/new-feature.ts
git commit -m "feat: add new feature"
Avant chaque commit, vérifier :
- [ ] Pas de console.log/print statements
- [ ] Pas de code commenté
- [ ] Pas de TODO/FIXME laissés
- [ ] Imports inutilisés supprimés
- [ ] Fonctions mortes supprimées
- [ ] Variables inutilisées supprimées
Une feature = Plusieurs commits atomiques.
❌ BAD: Un seul commit pour toute la feature
YOU: "Add user authentication"
AGENT: [modifies 15 files, adds auth, tests, middleware, docs]
YOU: git add . && git commit -m "feat: add auth"
# Diff énorme, impossible à review, rollback tout ou rien
✅ GOOD: Guide l'agent commit par commit
YOU: "Add user authentication. Commit after each logical step."
AGENT:
1. Creates auth types
2. git add src/types/auth.ts && git commit -m "feat: add auth types"
3. Adds JWT validation
4. git add src/auth/jwt.ts && git commit -m "feat: add JWT validation"
5. Creates middleware
6. git add src/middleware/auth.ts && git commit -m "feat: add auth middleware"
7. Adds tests
8. git add tests/auth.test.ts && git commit -m "test: add auth tests"
YOU: git log --oneline -5
# 5 commits reviewables, rollbackables
YOU: "Implement [FEATURE]. Make atomic commits after each logical step:
1. Types/interfaces first
2. Core implementation
3. Integration/middleware
4. Tests
5. Documentation
Run slop removal before each commit."
AGENT: [Implements step 1]
[Removes slop]
[Commits]
[Implements step 2]
...
- [ ] Chaque commit a un message descriptif
- [ ] Chaque commit passe les tests
- [ ] Chaque commit est reviewable seul
- [ ] `git log --oneline` raconte l'histoire
- [ ] Rollback possible à n'importe quelle étape
Avantages :
Définition : Laisser l’agent opérer sans supervision.
❌ BAD:
YOU: "Fix the bug in auth.ts"
[AGENT modifies auth.ts]
[AGENT modifies package.json]
[AGENT modifies .env ← DANGER]
[AGENT modifies database schema]
YOU: "Thanks!" ← Vous n'avez rien vérifié
✅ GOOD:
YOU: "Fix the bug in auth.ts. Only touch auth.ts."
[AGENT modifies auth.ts]
YOU: git diff auth.ts
# Vérifiez les changements
YOU: "Why did you change line 42?"
AGENT: Explains the reasoning
YOU: "OK, commit that separately from the fix."
git add auth.ts
git commit -m "fix: auth token expiration check"
⚠️ Si l’agent n’a pas de guardrails intégrés, l’oubli catastrophique contournera vos protections.
Ce qui arrive :
package.jsonSolution : Le test du nom
Dans votre AGENTS.md (ou instructions agent):
"Call me by my name at the beginning of each message.
If you forget my name, it means you're experiencing
catastrophic forgetting and should compress context."
Agent: "Hadrien, here's the fix..."
Agent: "Here's another fix..." ← ALERTE : forgetting!
Vous: /compact ← Compresser le contexte
Pourquoi ça fonctionne :
L’instruction “call me by name” est en préfixe du contexte.
Si le contexte grossit trop, cette instruction est éjectée.
L’agent arrête de vous nommer = signal d’alerte.
Les agents ont besoin de rechercher hors du code.
MCP Search = Interface unifiée.
| MCP | Usage |
|---|---|
| Google Custom Search | Recherche générale |
| DuckDuckGo | Search sans tracking |
| Brave Search | Alternative privacy-first |
// mcp-config.json
{
"mcpServers": {
"brave-search": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-brave-search"],
"env": {
"BRAVE_API_KEY": "your-key-here"
}
}
}
}
Pattern :
YOU: "Search for the latest best practices for Next.js 14 authentication"
AGENT: [uses MCP Brave Search]
AGENT: "Based on the search results, NextAuth.js v5 with OAuth
is recommended. Here's the pattern..."
Les TP qui utilisent MCP Search :
feature/nom-feature)git diff avant chaque commitdocker rm)Ce module est référencé dans :
Appliquez ce workflow partout.
C’est votre filet de sécurité.