Vous confiez une petite tâche à un agent de codage : corriger un test qui échoue. Vingt minutes plus tard, il a réécrit trois fichiers sans aucun rapport, lancé une migration de base de données sur la DATABASE_URL qu’il a trouvée dans votre shell, et forcé le push vers une branche que quelqu’un d’autre utilisait. Rien dans le prompt ne demandait quoi que ce soit de tout cela. L’agent avait les pleins pouvoirs sur la machine, alors il en a usé.
Les permissions sont la manière de décider à l’avance ce qu’un agent peut toucher. Une permission d’agent de codage est une règle qui définit quels fichiers, quelles commandes, quels identifiants et quels dépôts un agent donné peut atteindre pendant une exécution, et à quel moment un humain doit intervenir. Bien calibrées, elles font qu’un agent qui sort du script échoue sans danger dans la boîte que vous avez dessinée. Mal calibrées, une seule exécution ratée atteint la production.
Cet article déroule le modèle de permissions couche par couche, nomme le mode de défaillance à chaque étape et se termine par une checklist que vous pouvez appliquer dès aujourd’hui. Il s’appuie sur Sharkly pour rendre chaque couche concrète, car le rôle de Sharkly est de se placer au-dessus de vos agents de codage et de centraliser ce périmètre en un seul endroit. Vous avez déjà des agents de codage. Sharkly en fait une équipe, et une équipe a besoin de règles sur ce que chacun a le droit de faire.
Les trois couches où vivent les permissions d’un agent
Les permissions d’un agent de codage ne se résument pas à un seul réglage. Elles vivent à trois endroits, et une faille dans l’une annule les deux autres.
- Le runtime décide quels outils l’agent peut appeler : lire un fichier, modifier un fichier, exécuter une commande shell, accéder au réseau. C’est Claude Code, Codex, Gemini CLI, ou l’agent qui exécute le travail.
- La machine décide ce que ces outils peuvent atteindre : quels répertoires, quels identifiants, quelles variables d’environnement, quel réseau. Un Computer dans Sharkly « fournit le système d’exploitation, les fichiers, les identifiants, l’accès réseau et les outils requis par un Agent » ; la machine constitue donc le véritable rayon d’impact.
- La tâche décide de la frontière de l’intention : à quel dépôt cette exécution est rattachée, quels statuts l’agent peut définir, et le moment où un humain accepte le résultat.
Une frontière mérite d’être posée clairement : une permission n’est pas un point de validation. Une permission, c’est ce que l’agent peut faire. Un point de validation, c’est le moment où un humain décide. Vous avez besoin des deux. Des permissions strictes sans point de validation signifient que personne ne vérifie le résultat. Un point de validation avec des permissions laxistes signifie que les dégâts sont déjà faits au moment où quelqu’un regarde.
Étape 1 : délimiter les outils du runtime
Commencez là où l’agent agit. La plupart des agents de codage embarquent un système de permissions : une liste d’autorisation et une liste de refus d’outils, plus une demande de confirmation avant toute action destructrice. Claude Code, par exemple, permet d’autoriser ou de refuser des outils précis et demande confirmation avant d’exécuter des commandes shell ; les noms exacts des réglages varient selon le runtime et changent souvent, alors lisez la documentation actuelle de votre agent plutôt qu’un extrait trouvé l’an dernier.
Le réglage par défaut sûr consiste à être généreux en lecture et avare en écriture. Laissez l’agent lire le dépôt, lancer les tests, le typecheck et le build sans rien demander. Encadrez les modifications de fichiers et les commandes shell par une confirmation ou une liste d’autorisation explicite.
Le mode de défaillance a un nom, et c’est celui vers lequel tout le monde se tourne sous pression : le mode « tout ignorer ». Chaque runtime possède une option qui désactive toutes les confirmations, bien pratique en session supervisée. Le danger, c’est de la laisser active pour une exécution sans surveillance. Un agent qui n’a jamais à demander, travaillant à partir d’un plan qui s’avère erroné, supprimera allègrement ce qu’il a mal compris. Utilisez l’acceptation automatique quand vous regardez. Désactivez-la quand vous quittez votre poste.
Étape 2 : délimiter la machine et ses identifiants
La liste d’outils du runtime ne vaut rien si la machine donne tout à l’agent. Un agent autorisé à exécuter des commandes shell sur votre machine du quotidien peut lire chaque clé SSH, chaque .env et chaque identifiant accessible depuis votre propre session. Le mode de défaillance est silencieux : rien ne semble anormal jusqu’à ce qu’un agent utilise une clé de production qu’il n’aurait jamais dû voir.
Deux gestes réduisent le rayon d’impact. D’abord, faites tourner les agents dans un environnement délimité plutôt que sur l’ordinateur portable où vous gardez vos vrais secrets. Sharkly enregistre un Computer avec un jeton d’installation à durée de vie courte et à usage unique, et la documentation est sans ambiguïté : ne placez pas ce jeton dans une image réutilisable, un script, une Task ou un commentaire. Que le Computer soit un conteneur, un serveur ou une machine de rechange, la portée de l’agent est celle de cet environnement, pas la vôtre. Si vous voulez que les agents travaillent pendant que vous êtes hors ligne, faites-les tourner sur un Computer distant plutôt que sur votre portable ouvert.
Ensuite, ne transmettez que ce dont une exécution a besoin. L’environnement d’une exécution Sharkly est assemblé à partir d’une configuration explicite : dépôts attachés, variables d’environnement, liaisons de secrets et répertoire de travail. Attachez des dépôts à un Agent lorsqu’il a besoin d’un périmètre de code plus étroit que celui défini par défaut dans le Space, pour qu’un Agent frontend ne récupère jamais le service de facturation. Gardez chaque exécution dans son propre worktree isolé, ce qui fait toute la différence entre une mauvaise modification qui reste dans un checkout et deux agents qui corrompent le même arbre de travail. La règle maison s’applique à tous les champs : ne saisissez que la configuration demandée par le produit, et ne collez jamais de mots de passe ni de jetons dans des champs sans rapport ou des commandes de démarrage.
Étape 3 : délimiter la tâche et réserver la fusion à un humain
La dernière couche, c’est l’intention. Même un agent correctement isolé et doté d’identifiants délimités peut faire le mauvais travail : marquer sa propre tâche comme terminée, pousser une modification à moitié finie dans une branche partagée, ou décider qu’une PR est prête à être fusionnée.
C’est ici que le contrat humain-agent a sa place. Les agents font la recherche, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l’autorité et acceptent le résultat. L’automatisation s’arrête là où le jugement de l’équipe est requis. Un agent doit pouvoir ouvrir une PR en brouillon et y joindre la sortie de ses tests ; il ne doit ni approuver cette PR ni la fusionner dans votre branche protégée. La protection de branche côté hébergeur et la revue humaine côté tâche sont les deux verrous qui maintiennent cette ligne.
Dans Sharkly, la tâche elle-même porte cette limite. Un Workflow de type Task restreint les statuts qu’un Agent peut sélectionner, de sorte qu’un Agent ne peut pas déplacer discrètement du travail vers un état « Terminé » ou « Publié » qui appartient à un humain. Quand un Agent a besoin d’une décision, il laisse la Task en attente d’une revue humaine ou d’une réponse humaine, ce qui remonte dans l’Inbox pour que la personne responsable accepte, demande des modifications ou réattribue. L’exécution, les blocages, les résultats et la revue reviennent tous à la même Task au lieu de se disperser sur cinq terminaux.
C’est aussi là que la configuration maison cesse de passer à l’échelle. Un agent, un dépôt, un ingénieur méticuleux : vous pouvez garder tout le modèle de permissions en tête. Ajoutez un deuxième puis un troisième agent, davantage de dépôts et un collègue, et « que peut faire chaque agent ici » devient une question à laquelle personne ne peut répondre de mémoire. Un tableau de tâches transforme ces règles en configuration partagée et inspectable : qui a assigné le travail, quel périmètre avait l’exécution, quelles preuves en sont revenues et qui les a acceptées. C’est la couche de gestion au-dessus de vos agents de codage. Vous pouvez la construire à la main avec des worktrees, des identifiants délimités et la protection de branche, ou faire tourner vos agents de codage existants via Sharkly et gérer les permissions, les tâches et la revue au même endroit.
La checklist des permissions à appliquer dès aujourd’hui
Passez en revue cette liste pour chaque agent que vous laissez toucher à un vrai dépôt :
- Runtime : lectures et tests autorisés sans confirmation ; modifications et commandes shell encadrées ; mode « tout ignorer » désactivé pour les exécutions sans surveillance.
- Machine : l’agent tourne sur un Computer délimité, pas sur votre machine du quotidien ; jetons d’installation et d’accès à usage unique et jamais commités.
- Identifiants : uniquement les variables d’environnement et liaisons de secrets dont cette exécution a besoin, rien de collé dans des champs sans rapport.
- Périmètre des dépôts : l’agent est attaché aux dépôts exigés par son travail, pas à tous les dépôts du Space.
- Isolation : chaque exécution dispose de son propre worktree, pour qu’une mauvaise modification ne puisse pas corrompre un checkout partagé.
- Périmètre de la tâche : l’agent peut définir des statuts de travail, mais pas déplacer une tâche vers un état accepté ou publié qui appartient à un humain.
- La fusion : la protection de branche et une revue humaine étayée par des preuves au niveau de la tâche se dressent entre la PR de l’agent et la branche principale.
Si une ligne est trop lâche, resserrez-la avant la prochaine exécution, pas après l’incident qui vous aura appris pourquoi elle comptait.
FAQ
Quelle est la différence entre les permissions d’un agent de codage et les points de validation ? Les permissions définissent ce qu’un agent est techniquement capable de faire : quels fichiers, quelles commandes et quels identifiants il peut atteindre. Un point de validation est le moment où un humain décide d’accepter ou non ce que l’agent a fait. Il faut les deux, car des permissions strictes laissent malgré tout du travail qu’un humain doit valider, et les points de validation ne servent à rien si l’agent avait déjà la permission de causer des dégâts.
Un agent de codage doit-il pouvoir fusionner ses propres PR ? Non, pas par défaut. Laissez l’agent ouvrir une PR en brouillon et y joindre ses résultats de vérification, puis réservez la fusion à un humain ou à une revue obligatoire. La logique est celle du contrat humain-agent : les agents exécutent et rendent compte, les humains acceptent et publient. Cela vaut même pour les workflows avec humain dans la boucle où l’agent fait l’essentiel du travail.
Est-il sûr de faire tourner un agent avec toutes les confirmations de permission désactivées ? Uniquement pendant que vous le surveillez. Les modes d’acceptation automatique sont utiles en session supervisée, où vous pouvez interrompre une mauvaise étape. Pour les exécutions sans surveillance ou de nuit, gardez les confirmations ou une liste d’autorisation, et placez l’agent sur une machine délimitée pour qu’une erreur reste contenue.
