Comment organiser ses répertoires pour empêcher les agents IA de modifier le mauvais code dans un monolithe géant
Lorsque l'on connecte Claude Code ou Aider à un monolithe de plusieurs centaines de milliers de lignes, ils commencent généralement par lire les mauvais fichiers. La fenêtre de contexte du modèle étant limitée, il accumule des fichiers non pertinents jusqu'à saturer la limite de jetons (tokens) et finit par modifier du code inadéquat.
Ce problème ne se résout pas en écrivant des prompts plus longs. Il faut réduire le rayon d'action physique du code exploré par l'agent et intégrer localement des règles de vérification mécaniques.
1. Séparer les répertoires provoquant des références circulaires
Dans un dépôt monolithique, les points où l'agent se perd dans une exploration infinie sont généralement au nombre de trois : le dossier d'utilitaires communs regroupant des fonctions diverses (src/utils/), la couche de service où la logique métier s'entremêle (src/services/), et le répertoire des modèles globaux (src/models/). Dès que ces trois dossiers commencent à s'auto-référencer, l'agent doit lire des dizaines de fichiers rien que pour modifier une seule ligne de code.
Regrouper et isoler les dossiers classés par couche technique en unités de domaine permet de réduire la portée de la recherche.
| Catégorie |
Structure centrée sur les couches |
Structure séparée par domaine |
Évolution du comportement de l'agent |
| Critère de dossier |
Séparation par couche technique (/controllers, /services) |
Séparation par domaine (/domains/order) |
Recherche uniquement des fichiers nécessaires dans un seul dossier |
| Connexion des dépendances |
Importation directe des entités globales |
Communication via des frontières d'interface de domaine |
Blocage du chargement en chaîne de fichiers non pertinents |
| Logique commune |
Fonctions mélangées dans un unique src/utils/ |
Séparation en utilitaires dédiés au domaine et en paquets communs |
Prévention de la pollution inutile du contexte global |
Voici l'ordre à suivre pour déplacer les répertoires sans interrompre le service en cours :
- Identifiez les relations de dépendance excessivement appelées par l'agent pour déterminer le domaine à isoler.
- Créez des interfaces de frontière de service pour rompre les références directes entre domaines.
- Déplacez la logique métier associée dans le dossier
src/domains/{nom_domaine}/ et mettez à jour les alias de chemin dans tsconfig.json.
- Placez un fichier de configuration dédié à ce domaine (
CLAUDE.md) à l'intérieur du sous-répertoire isolé.
2. Remplacer les règles en langage naturel ambigu par des contraintes chiffrées
Les agents passent facilement à côté des conventions de codage rédigées en de longs textes naturels. Des chiffres clairs et des interdictions explicites doivent être placés en haut du fichier de configuration pour que les consignes soient suivies à la lettre.
`markdown
Contraintes du projet (Placées en haut de CLAUDE.md)
- Sécurité et gestion des exceptions
- NEVER allow raw SQL string concatenation. ALWAYS use parameterized queries with ORM.
- NEVER throw generic Exception or Error. ALWAYS throw domain-specific exceptions inheriting from BaseDomainException.
- ALWAYS enforce tenant_id filtering in all database queries under src/domains/.
- Contraintes numériques de structure du code
- Functions MUST NOT exceed 40 lines of code.
- Cyclomatic complexity MUST be kept under 8 per function.
- ALWAYS return Result<T, E> pattern for business layer operations instead of null.
`
Si un fichier de configuration dépasse 200 lignes, les instructions situées à la fin ont tendance à être ignorées.
- Dans le
CLAUDE.md du répertoire racine, conservez uniquement les commandes de build et les règles de commit globales, le tout en moins de 200 lignes.
- Répartissez les règles des sous-dossiers (comme
src/domains/order/) dans des fichiers de règles dédiés situés directement dans ces répertoires.
- Rédigez les préférences personnelles des développeurs dans
CLAUDE.local.md et enregistrez-le dans .gitignore pour éviter les conflits.
3. Valider automatiquement le code modifié par l'agent grâce aux hooks locaux
Les erreurs de syntaxe ou de régression dans le code généré par l'agent doivent être détectées automatiquement au moment du commit. Utiliser Lefthook, qui fonctionne comme un binaire unique en Go, permet d'exécuter des vérifications parallèles plus légères que les outils basés sur Node.js.
Placez lefthook.yml à la racine pour séparer les contrôles statiques légers des étapes de tests lourdes.
`yaml
pre-commit:
parallel: true
commands:
linter:
glob: ".{ts,tsx}"
run: npx eslint --fix {staged_files}
stage_fixed: true
formatter:
glob: ".{ts,tsx,json,md}"
run: npx prettier --write {staged_files}
stage_fixed: true
security-scan:
run: gitleaks git --staged --no-banner
pre-push:
parallel: false
commands:
typecheck:
run: npx tsc --noEmit
unit-tests:
run: npm run test:unit -- --passWithNoTests
`
L'étape pre-commit vérifie uniquement les fichiers indexés en moins de 10 secondes, tandis que la vérification complète des types et les tests unitaires sont reportés à l'étape pre-push.
Enregistrez un intercepteur dans .claude/hooks/block-no-verify.mjs pour empêcher l'agent d'utiliser l'option --no-verify afin de contourner les hooks.
`javascript
import fs from 'fs';
const input = fs.readFileSync(0, 'utf8');
const parsed = JSON.parse(input);
if (parsed.tool_input?.command?.includes('--no-verify')) {
console.error("Policy Violation: --no-verify flag is strictly prohibited.");
process.exit(1);
}
process.exit(0);
`
Si un hook échoue, la sortie d'erreur de la console est injectée dans le prompt suivant, permettant à l'agent de corriger son code de lui-même.
4. Limiter la portée de la recherche pour éviter le gaspillage de jetons
Si l'agent commence à lire les artefacts de build ou les fichiers de verrouillage (lock files), les jetons s'épuisent rapidement. Il est indispensable de restreindre le champ de recherche de fichiers pour éviter des coûts imprévus.
Créez un fichier .ignore ou .aiderignore à la racine du projet et y inscrire les artefacts volumineux.
`text
node_modules/
dist/
build/
coverage/
*.min.js
*.svg
*.lock
package-lock.json
public/assets/
db/migrations/
`
Spécifiez également le répertoire de travail lors de l'exécution dans le terminal pour bloquer les analyses globales.
`bash
aider "Refactor Order validation logic" --path=src/domains/order/ --exclude=src/domains/order/tests/
`
Passer en mode planification pour vérifier les modifications avant de modifier le code, rédiger des tests unitaires qui échouent au préalable, puis s'assurer de ne rédiger que du code qui les fait passer permettra de maintenir le rayon d'action de l'agent en toute sécurité.