Un agent qui code en autonomie est devenu une réalité opérationnelle en 2026. Claude Code, Cursor en mode agent, Devin, Copilot Workspace, plus tous les wrappers maison. Ces agents ont accès au repo, à la CI, parfois à la prod. La question n'est plus s'ils sont utiles — ils le sont — c'est ce qu'ils peuvent casser quand ils dérapent.
Le périmètre par défaut est trop large dans 90% des cas
Quand un développeur installe un agent de coding et lui donne accès à son repo de travail, le réflexe est de lui accorder le périmètre dont le développeur dispose. Si le dev a un PAT GitHub avec scope repo complet, l'agent l'hérite. Si le dev peut pousser sur main, l'agent peut.
Ce n'est pas la bonne valeur par défaut. Un agent est :
- Plus rapide que le dev (donc plus d'opérations par minute).
- Moins prudent (pas d'intuition sur les conséquences hors du contexte explicite).
- Plus vulnérable à la prompt injection (un README malicieux peut le détourner).
L'équation risque/bénéfice est différente. Le scope doit l'être aussi.
6 leviers de scoping concrets
1. Token dédié à l'agent, pas du dev
Créer un fine-grained PAT ou une GitHub App dédiée à l'agent, avec accès limité aux dépôts sur lesquels il travaille. Si vous travaillez sur 3 projets, l'agent a 3 tokens distincts — ou un token unique avec accès aux 3 dépôts uniquement. Pas plus.
2. Pas de droit de push direct sur les branches protégées
Activer la branch protection sur main et release/* :
- Pull request obligatoire.
- Review humaine requise.
- Status checks (CI) verts.
- Pas de push direct, même par admin.
L'agent peut créer une PR. Il ne peut pas la merger. La séparation est nette : l'humain garde la décision finale sur ce qui entre en prod.
3. Sandbox de filesystem
L'agent ne doit pouvoir écrire que dans un dossier de travail dédié. Pas d'accès aux dossiers contenant des secrets locaux (~/.aws, ~/.config, ~/.ssh). Sous macOS et Linux, c'est un container ou un user dédié.
Beaucoup d'agents 2026 proposent un "sandbox mode" qui matérialise ça côté config. C'est à activer par défaut, à relâcher cas par cas — pas l'inverse.
4. Capabilities CI/CD séparées
Si vous laissez l'agent lancer des jobs CI :
- Lui donner un runner dédié, pas le runner partagé qui a accès aux secrets de prod.
- Limiter les workflows qu'il peut déclencher (allowlist explicite).
- Forcer le dry-run sur les workflows de déploiement, sauf validation manuelle.
5. Confirmation humaine sur les actions sensibles
Identifier la liste des actions à toujours faire confirmer par l'utilisateur, pas seulement par l'agent :
- Push (et a fortiori
push --force). - Création/suppression de branches sur le remote.
- Merge.
- Modification des workflows CI (le code qui définit ce que CI fait est lui-même sensible).
- Modification des secrets/env vars.
- Suppression de fichiers.
Le pattern "l'agent propose le diff, l'humain valide" est la défense de référence. Très peu d'agents l'imposent par défaut. C'est à vous de l'imposer côté config.
6. Logging et replay
L'agent doit logger :
- Chaque commande qu'il exécute (
git,npm,pytest,bash). - Chaque fichier qu'il modifie (diff complet, pas juste le nom).
- Chaque outil externe appelé.
Ces logs doivent être consultables après coup et idéalement permettre de rejouer une session. Sans replay, un incident agent est presque impossible à analyser.
Le scénario d'incident type
Voici une trame que j'ai vue trois fois en mission depuis février 2026 :
- Un dev demande à l'agent "corrige ce bug et déploie en staging".
- L'agent lit le code, lit un README. Le README contient une instruction injectée par un PR review malicieuse (jamais mergée, mais branchée).
- L'agent modifie un workflow CI pour y ajouter un step "backup secrets to external endpoint".
- L'agent push, déclenche la CI, les secrets sont exfiltrés.
La défense qui aurait cassé ce scénario : confirmation humaine sur la modification des workflows. Coût : une boîte de dialogue. Bénéfice : exfiltration évitée.
Le sujet réglementaire qui arrive
L'AI Act (entrée en vigueur des obligations système haut risque le 2 août 2026) considère certains agents de coding autonomes comme potentiellement haut risque si utilisés sur du code critique. Côté pratique, ça signifie qu'à partir d'août 2026 vous devrez documenter, pour un agent intégré dans votre chaîne de production logicielle :
- Le périmètre d'autonomie de l'agent.
- Le mécanisme de supervision humaine.
- Le log audit conservé.
- Les tests de robustesse réalisés.
Si vous n'avez aucun de ces livrables aujourd'hui, c'est un chantier 3-6 mois.
La règle simple à se dire en arrivant le matin
Avant de donner accès à votre repo à un agent, posez la question : "Si demain je découvre que mon agent a poussé une régression catastrophique en prod, comment je remonte au prompt qui a causé ça ? Comment je l'arrête ? Comment je restaure ?". Si vous n'avez pas de réponse pour les trois, il faut serrer les permissions avant d'aller plus loin.
Pour la migration des tokens GitHub, Fine-grained PAT en 30 minutes. Pour le confinement général, Confinement d'un agent.