11:05Maximilian Schwarzmüller
Log in to leave a comment
No posts yet
L'époque où l'éditeur se contentait d'écrire du code à votre place est révolue. Désormais, des agents comme Claude Code ouvrent directement le terminal, parcourent le système de fichiers et modifient le code. C'est pratique, mais aussi un peu effrayant. Une seule injection de prompt pourrait entraîner la fuite de fichiers .env ou de clés SSH vers l'extérieur. Il est nécessaire d'établir des méthodes de contrôle concrètes pour donner de l'autonomie à l'agent sans lui permettre de franchir la ligne rouge.
Par défaut, un agent tente de scanner l'intégralité du projet pour accomplir sa mission. Si on le laisse faire, il risque de lire des configurations sensibles. La défense la plus fiable consiste à créer un fichier de règles dédié à l'agent dans le répertoire racine du projet.
CLAUDE.md ou .agent-rules à la racine..env, ~/.ssh ou ~/.aws/credentials doivent faire l'objet de règles deny pour qu'il ne puisse même pas les consulter.--allowedTools lors de l'exécution de l'agent pour n'autoriser que les fonctionnalités nécessaires. Il s'agit d'activer uniquement les outils minimaux tels que Bash, Read ou Write.En utilisant le mode Default de Claude Code, qui nécessite l'approbation de l'utilisateur pour toute opération d'écriture, vous pouvez bloquer physiquement les risques de fuite de code source. Un simple fichier de configuration suffit pour empêcher un agent d'envoyer vos variables d'environnement à l'extérieur sans votre permission.
Les outils centrés sur les agents planifient et s'exécutent de manière autonome. Le problème survient lorsqu'ils tombent dans une erreur logique. Un agent qui ne trouve pas de solution peut tourner en boucle infinie, multipliant les appels API et facturant des dizaines de dollars en un instant. Selon les données de recherche d'Anthropic, le simple fait de définir des critères de sortie (Exit Criteria) explicites dans le prompt peut réduire le temps d'exécution jusqu'à 62 %.
Pour éviter l'explosion des coûts, vous devez concevoir un « coupe-circuit » directement dans le prompt :
npm test ou la réussite d'un test unitaire spécifique comme critère absolu de fin..cursorrules pour limiter l'agent à la lecture de règles de répertoires spécifiques, comme src/api/**/*, afin d'éviter le gaspillage inutile de jetons.L'établissement de ces barrières de sortie permet de limiter la consommation de jetons due à des instructions ambiguës, économisant ainsi plus de 40 % des coûts mensuels d'API.
Le fait que l'agent modifie directement les fichiers locaux est rapide, mais dangereux. Un code non vérifié pourrait corrompre la branche principale. L'équipe d'ingénierie de Shopify, qui utilise son propre outil agent nommé Sidekick, a introduit une méthode de validation croisée des résultats par un modèle distinct. Nous devons également isoler l'espace de travail dédié à l'agent.
La méthode la plus propre est d'utiliser git worktree. Créez un répertoire et une branche indépendants dédiés à la session de l'agent. Une fois le travail terminé, demandez-lui de générer un rapport de synthèse des modifications via git diff, et automatisez l'exécution des tests unitaires avec des outils comme Playwright ou Vitest. Ce processus permet de réduire le temps de revue manuelle de 70 % tout en ne fusionnant que du code validé dans la branche principale.
La vitesse à laquelle un agent écrit du code est bien supérieure à la frappe humaine. À ce moment-là, si la fonction editor.formatOnSave de VS Code est activée, le format du fichier change de force pendant que l'agent écrit, provoquant des erreurs de correspondance de texte (text matching). C'est l'outil qui finit par se prendre les pieds dans le tapis.
De plus, les shells non interactifs exécutés par l'agent ne lisent souvent pas les variables d'environnement configurées dans .zshrc, ce qui entraîne l'échec de l'exécution des outils.
editor.formatOnSave en le réglant sur false dans le fichier .vscode/settings.json du projet collaboratif..zshrc vers le fichier .zshenv, qui est chargé quel que soit le mode d'exécution du shell.Husky pour configurer des hooks de pré-commit afin que le linter et le formateur ne s'exécutent que lorsque l'agent a terminé son travail et effectue un commit.Si vous ne voulez pas voir un agent rester planté bêtement parce qu'il ne trouve pas ses variables d'environnement, vous devez d'abord revoir la configuration de votre shell.
| Catégorie de réglage | Nom du fichier | Contenu recommandé | Visibilité de l'agent |
|---|---|---|---|
| Variables d'environnement globales | .zshenv | Chemins PATH, API_KEY, SDK | Chargé dans toutes les sessions |
| Configuration interactive | .zshrc | alias, prompt, theme | Peut être ignoré lors de l'exécution de l'agent |
| Configuration de connexion | .zprofile | Scripts d'initialisation système | Valide uniquement dans le shell de connexion |