Chapitre 5.3 — Permissions & sécurité
⏱️ TL;DR — L’autonomie de l’agent est un curseur, pas un interrupteur. Tu l’ajustes via les modes de permission (demander / accepter les éditions / plan / autonomie élargie) et des règles fines dans
settings.json(autoriser tel type de commande, refuser tel autre). La bonne règle : l’autonomie se gagne en installant le filet de sécurité d’abord — git propre, commits fréquents, tests, hooks. Plus le filet est solide, plus tu peux lâcher du lest sans risque.
🎯 Objectifs
- Choisir le bon mode de permission selon le contexte.
- Écrire des règles de permission utiles (allow/deny).
- Bâtir le filet de sécurité qui autorise plus d’autonomie.
- Éviter les excès dans les deux sens (tout confirmer / tout autoriser).
Le curseur d’autonomie
- Plan : conception seule, zéro modification. Pour cadrer (P2).
- Demander (défaut) : l’agent confirme les actions sensibles. Bon défaut au quotidien.
- Accepter les éditions : il applique ses modifs sans confirmer à chaque fichier, mais reste prudent sur l’exécution. Pour avancer vite sur une tâche cadrée.
- Autonomie élargie : peu d’interruptions. À réserver aux tâches à faible risque et bien outillées (filet en place).
Le bon mode dépend de l’enjeu × la confiance × le filet. On ne met pas « autonomie élargie » sur un refactor risqué d’un repo sans tests.
Les règles de permission (settings.json)
Au-delà des modes, tu affines quelles actions précises passent sans demande, dans settings.json :
{
"permissions": {
"allow": [
"Bash(npm test)",
"Bash(npm run lint)",
"Bash(git status)",
"mcp__pencil"
],
"deny": [
"Bash(rm -rf *)",
"Bash(git push --force*)"
],
"defaultMode": "default"
}
}Logique :
- allow : les commandes fréquentes et sûres (lancer les tests, lint, status git, un serveur MCP de confiance). Tu supprimes les confirmations qui ne t’apportent rien.
- deny : les commandes dangereuses que tu ne veux jamais voir passer sans réflexion (suppressions massives, push forcé).
Résultat : moins d’interruptions sur l’anodin, un garde-fou dur sur le destructeur. C’est du réglage fin, pas du tout-ou-rien.
💡 Réflexe d’architecte — Construis ton
allowempiriquement : quand une même confirmation revient dix fois pour une commande sûre (npm test…), ajoute-la à l’allow-list. Il existe même des outils pour scanner tes sessions et proposer une allow-list (voir la skill de réduction des prompts, Partie 10). Tu réduis le bruit sans baisser la garde sur le reste.
Le filet de sécurité : ce qui rend l’autonomie sûre
Élargir l’autonomie n’est prudent que si une erreur est rattrapable. Le filet :
- Git propre + commits fréquents : un mauvais changement se
git reset/reverten une commande. Sans ça, une dérive de l’agent est irréversible. - Une branche de travail : jamais l’agent en autonomie sur
main. - Des tests : ils attrapent les régressions que l’autonomie pourrait introduire.
- Des hooks (P7) : ils imposent lint/format/tests mécaniquement, même en autonomie.
⚠️ Piège — Le raisonnement inversé : « je mets tout en autonomie pour ne pas être dérangé », sur un repo sans tests, sans commits récents, directement sur
main. C’est le scénario des dégâts silencieux : l’agent avance, casse quelque chose, et tu n’as ni test pour le voir ni commit pour revenir en arrière. D’abord le filet, ensuite l’autonomie.
Deux excès à éviter
| Excès | Symptôme | Correction |
|---|---|---|
| Tout confirmer | tu passes ta vie à cliquer « oui » sur npm test | allow-list les commandes sûres |
| Tout autoriser | l’agent a poussé sur main / supprimé un truc | deny-list le destructeur + branche + tests |
Le bon réglage est entre les deux, et il évolue avec la solidité de ton filet.
🧭 Sur TaskFlow — On travaillera TaskFlow sur une branche, avec
npm test/linten allow-list et le push forcé en deny. Une fois les hooks de la Partie 7 en place (tests auto), on pourra élargir l’autonomie sur les tâches mécaniques — parce que le filet, lui, sera solide.
✏️ Exercices
Exercice 1 — Ton allow/deny. Écris une première allow-list (3-5 commandes sûres que tu confirmes tout le temps) et une deny-list (2-3 commandes destructrices). Applique-la et note la baisse d’interruptions.
✅ Solution
allow typique : npm test, npm run lint, git status, git diff. deny typique : rm -rf, git push --force, suppression de branches. Tu gagnes en fluidité sur l’anodin sans toucher au garde-fou sur le dangereux. Ajuste au fil des sessions.
Exercice 2 — Évalue ton filet. Pour un de tes projets, coche : git propre ? commits fréquents ? tests ? branche de travail ? Selon le score, quel niveau d’autonomie est raisonnable ?
✅ Solution
Filet complet (git + commits + tests + branche) → tu peux élargir l’autonomie sur les tâches à faible risque. Filet troué (pas de tests, commits rares) → reste en « demander », et construis le filet d’abord. L’autonomie n’est pas un réglage de confort, c’est une conséquence du filet.
🧠 Quiz de révision
1. Les modes de permission, du plus prudent au plus autonome ?
Plan (ne modifie rien) → Demander (confirme le sensible) → Accepter les éditions (écrit sans confirmer) → Autonomie élargie (peu d’interruptions). Le choix dépend de enjeu × confiance × filet.
2. À quoi servent les listes allow et deny ?
allow et deny ?allow supprime les confirmations sur des commandes fréquentes et sûres (npm test…) ; deny bloque des commandes dangereuses (rm -rf, push --force). Réglage fin, pas tout-ou-rien.
3. Pourquoi « l’autonomie se gagne » ?
Parce qu’elle n’est sûre que si une erreur est rattrapable : git propre, commits, branche, tests, hooks. Sans ce filet, l’autonomie produit des dégâts irréversibles.
4. Quel est le danger de « tout autoriser » sur un repo sans tests, sur main ?
Les dégâts silencieux : l’agent casse quelque chose sans qu’un test le signale ni qu’un commit récent permette de revenir en arrière. D’où : filet d’abord, autonomie ensuite.
5. Comment construire une bonne allow-list ?
Empiriquement : ajouter une commande quand sa confirmation revient sans cesse alors qu’elle est sûre. Des outils peuvent scanner tes sessions pour la proposer (Partie 10).
Chapitre suivant : Vérifier le travail — observer que ça marche, au lieu de le croire.