> ## Documentation Index
> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Gérer les mods pour votre organisation
> Contrôlez les mods Claude Code avec des paramètres gérés : arrêtez les mods installés par les utilisateurs, autorisez uniquement les vôtres, examinez ce qu'un mod peut faire, et appliquez une politique avec votre propre mod.
Un [mod](/docs/fr/plugins/mods/overview) est un plugin qui exécute du code à l'intérieur de Claude Code avec les permissions de l'utilisateur qui l'a installé. Les mods ne sont pas isolés. Via les [paramètres gérés](/docs/fr/managed-settings), vous décidez si les mods s'exécutent sur les machines de vos utilisateurs, lesquels, et dans quel ordre. Vous pouvez également installer un mod de votre côté qui surveille ou refuse ce que font les autres mods.
Cette page s'adresse à la personne qui déploie les paramètres gérés pour Claude Code, que ce soit sous forme de fichier, via MDM, ou depuis la console d'administration claude.ai. Les mods sont activés par défaut dans Claude Code v2.1.287 et versions ultérieures. Commencez par la section qui correspond à ce que vous souhaitez faire :
* **Empêcher les mods des utilisateurs de se charger, avec ou sans vos propres mods** : [Arrêter le chargement des mods installés par les utilisateurs](#stop-user-installed-mods-from-loading)
* **Voir ce que vos utilisateurs obtiennent quand vous ne changez rien** : [Savoir ce qui se passe par défaut](#know-what-happens-by-default)
* **Laisser les mods activés avec d'autres limites** : [Choisir le niveau d'autorisation](#choose-how-much-to-allow)
Ces cas sont couverts sur d'autres pages :
* **Vous n'avez jamais déployé de paramètres gérés auparavant** : commencez par [Déployer les paramètres gérés](/docs/fr/managed-settings)
* **Vous souhaitez contrôler les plugins que les utilisateurs peuvent installer** : voir [Gérer les plugins pour votre organisation](/docs/fr/plugins/org)
Arrêter le chargement des mods installés par les utilisateurs
Pour empêcher chaque mod que vos utilisateurs apportent de se charger, définissez l'option `allowManagedModsOnly` sur la [garde intégrée](#know-what-happens-by-default), un mod de politique que Claude Code charge avant chaque mod qu'un utilisateur installe. L'option se trouve dans les paramètres gérés sous `pluginConfigs`, indexée par `cc-plugin-sec-default@builtin` :
```json managed-settings.json theme={null}
{
"pluginConfigs": {
"cc-plugin-sec-default@builtin": {
"options": {
"allowManagedModsOnly": true
}
}
}
}
```
Avec l'option définie dans les paramètres gérés :
* **Aucun mod qu'un utilisateur apporte ne se charge** : cela couvre un mod dans un plugin que l'utilisateur a installé, un mod chargé avec `--plugin-dir`, et un mod [que Claude a écrit pendant une session](/docs/fr/plugins/mods/create#ask-claude-for-a-mod)
* **Les mods de votre organisation se chargent toujours** : un mod qui [compte comme celui de votre organisation](#install-your-organizations-mods) n'est pas vérifié. Tous les autres mods comptent comme ceux d'un utilisateur et ne se chargent pas. Cela inclut un mod dans un plugin que vous activez à partir d'une place de marché GitHub ou autre distante, et un que votre organisation active pour ses membres sur claude.ai. Si aucun ne compte comme le vôtre, aucun mod installé ne se charge.
* **Les utilisateurs ne peuvent pas l'annuler** : la garde lit l'option uniquement à partir des paramètres gérés, donc la même entrée dans un fichier de paramètres utilisateur, projet ou local, ou dans un fichier passé avec `--settings`, ne change rien
* **Un fichier ou une politique MDM couvre chaque fournisseur** : quand vous livrez l'option sous forme de fichier ou via MDM, elle fonctionne de la même manière sur Amazon Bedrock, la plateforme Agent de Google Cloud, et Microsoft Foundry. Pour la livraison depuis la console d'administration claude.ai, voir [Disponibilité de la plateforme](/docs/fr/server-managed-settings#platform-availability)
* **Les autres personnalisations des utilisateurs continuent de fonctionner** : leurs [hooks dans les fichiers de paramètres](/docs/fr/hooks), les lignes d'état, et `/goal` ne sont pas affectés
* **Les mods intégrés continuent de s'exécuter** : les mods intégrés à Claude Code, comme le support `AGENTS.md`, ont chacun [leur propre commutateur](/docs/fr/plugins/mods/overview#mods-built-into-claude-code)
Pour confirmer l'option sur la machine d'un utilisateur, démarrez Claude Code là-bas avec `--plugin-dir` et le chemin d'un répertoire qui contient un mod, comme `claude --plugin-dir ./first-mod`. Les hooks du mod ne s'exécutent pas, et la transcription et le journal de débogage contiennent le [message de la garde](/docs/fr/plugins/mods/troubleshoot#messages-from-the-built-in-guard), qui nomme le mod et `allowManagedModsOnly`. Si le mod se charge, voir [Vérifier qu'une politique est en vigueur](/docs/fr/managed-settings#check-that-a-policy-is-in-force) et les [règles qui décident si une option prend effet](#set-options-on-the-built-in-guard).
Si vous avez défini `CLAUDE_CODE_ENABLE_FUNCTION_HOOKS` à `0` lors de l'accès anticipé, remplacez-le par cette option. Claude Code v2.1.287 et versions ultérieures ignorent la variable à n'importe quelle valeur, donc un `0` là-bas laisse les mods activés.
Savoir ce qui se passe par défaut
Sans vos propres paramètres de mod, voici ce que vos utilisateurs obtiennent :
* **Les mods sont activés.** Un utilisateur peut installer un plugin qui contient un mod à partir de n'importe quelle place de marché que vos paramètres de plugin autorisent, ou en charger un à partir d'un répertoire avec `--plugin-dir`.
* **Une garde intégrée s'exécute en premier.** Claude Code charge un mod intégré nommé `sec-default@builtin` avant chaque mod qu'un utilisateur installe. Les utilisateurs ne peuvent pas l'éteindre. `/plugin` et le journal de débogage le listent comme `cc-plugin-sec-default`. La garde se charge quand l'une de ces conditions est vraie :
* La machine a des paramètres gérés
* L'utilisateur est connecté à Claude Code avec un plan Team ou Enterprise
Un utilisateur qui s'authentifie avec une clé API, ou via Amazon Bedrock, la plateforme Agent de Google Cloud, ou Microsoft Foundry, n'obtient la garde que sur une machine qui a des paramètres gérés.
* **La garde protège ce que vous gérez.** Le mod d'un utilisateur ne peut pas changer ce que vos hooks gérés reçoivent ou décident, l'invite système, votre `CLAUDE.md` géré et autres instructions gérées, ce que n'importe quel mod lit comme paramètres, ou les outils et descriptions de vos serveurs MCP gérés.
* **Tout le reste est autorisé.** La garde n'ajoute aucune autre restriction. Le mod d'un utilisateur peut toujours lire et écrire des fichiers, démarrer des processus, faire des demandes réseau, réécrire les appels d'outils et les invites, refuser un appel d'outil, approuver un qui demanderait autrement, et dessiner dans l'interface, tout avec les permissions de cet utilisateur.
* **Les règles de refus et vos hooks gérés ont la priorité.** Là où la garde se charge, le mod d'un utilisateur ne peut pas approuver un appel qu'une règle `deny` refuse, quel que soit le fichier de paramètres qui contient la règle. Un bloc d'un hook `PreToolUse` dans les paramètres gérés est aussi final. Les deux s'appliquent aux appels d'outils de Claude. Aucun ne s'applique aux appels [`$.fs` et `$.process` propres à un mod](/docs/fr/plugins/mods/api#reach-files-processes-and-the-network) : avec `Read(.env)` refusé, un mod peut toujours lire ce fichier avec `$.fs.read` ou démarrer un programme qui le fait. Pour limiter ces appels, empêchez le mod de se charger ou accrochez l'appel dans un [mod de politique](#enforce-a-policy-with-a-mod-of-your-own).
* **Les autres vérifications de permission peuvent être contournées.** Le mod d'un utilisateur qui approuve les appels d'outils peut approuver un appel qu'une règle `ask` demanderait, ou qu'un hook `PreToolUse` en dehors des paramètres gérés a bloqué. En mode auto, un appel que le mod approuve s'exécute sans vérification de classificateur.
La source de la garde est publique dans le [répertoire `mods/sec-default` du référentiel Claude Code](https://github.com/anthropics/claude-code/tree/main/mods/sec-default).
Savoir quels contrôles s'appliquent toujours
Les mods ne remplacent pas les contrôles que vous avez déjà :
* **Les hooks de paramètres continuent de fonctionner.** Les hooks de commande, HTTP, d'invite, et d'agent dans les fichiers de paramètres et dans le `hooks/hooks.json` des plugins s'exécutent comme avant, aux côtés des mods. Rien à leur sujet n'est déprécié.
* **Les règles de refus ont la priorité là où la garde se charge.** Le mod d'un utilisateur ne peut pas approuver un appel qu'une règle `deny` refuse, sauf si vous définissez [`allowModsToOverrideDenyRules`](#set-options-on-the-built-in-guard).
* **Les hooks gérés s'exécutent en premier.** Un hook `PreToolUse` dans les paramètres gérés s'exécute avant que n'importe quel mod ne voie l'appel d'outil, et son bloc est final. Si un mod réécrit ensuite l'appel, vos hooks gérés s'exécutent à nouveau sur l'appel réécrit, donc un bloc s'applique toujours. Les hooks `PreToolUse` d'autres fichiers de paramètres et de plugins s'exécutent après le dernier mod, donc un mod qui retourne son propre résultat à la place d'exécuter l'outil les empêche de s'exécuter. Voir [L'ordre dans lequel les mods s'exécutent](/docs/fr/plugins/mods/events#the-order-mods-run-in).
* **La politique réseau couvre `$.http.fetch`.** Si votre organisation désactive la récupération web, ou si le trafic réseau non essentiel est désactivé pour la session, Claude Code refuse une demande réseau qu'un mod fait avec `$.http.fetch`. La politique ne couvre pas un programme que le mod démarre avec `$.process.run`. Ce programme atteint le réseau avec l'accès propre de l'utilisateur.
* **Les contrôles de plugin couvrent les mods.** Un mod est un plugin, donc les [paramètres qui limitent ce que les utilisateurs peuvent installer](/docs/fr/plugins/org#restrict-what-users-can-install), comme `strictKnownMarketplaces`, décident s'il peut être installé du tout.
* **Les mods ne peuvent pas changer l'invite de permission.** Un mod peut redessiner une grande partie de l'interface de Claude Code, mais pas l'invite de permission, donc il ne peut pas changer ce qu'une invite affiche. Un mod peut toujours approuver ou refuser un appel d'outil avant que l'invite n'apparaisse, comme [Savoir ce qui se passe par défaut](#know-what-happens-by-default) le décrit.
* **Les invites de confiance viennent en premier.** Dans une session interactive dans un répertoire que l'utilisateur n'a pas encore approuvé, aucun mod ne se charge jusqu'à ce qu'il réponde à l'invite de confiance.
* **`--safe-mode` désactive les mods installés, y compris les vôtres.** Démarrez une session avec `claude --safe-mode` pour vérifier si un mod a causé un problème.
Aucun de ces contrôles n'isole un mod. Un mod que vous autorisez s'exécute en tant qu'utilisateur, avec l'accès de l'utilisateur aux fichiers, processus, et réseau.
Décider de laisser les mods activés
Un mod peut faire plus que les autres parties d'un plugin car il s'exécute à l'intérieur de Claude Code. Il voit chaque invite et appel d'outil, peut les changer, et peut autoriser ou refuser un appel d'outil avant qu'une invite de permission n'apparaisse.
Ce qu'un utilisateur peut charger en tant que mod dépend des contrôles de plugin que vous avez déjà :
| Vos contrôles de plugin aujourd'hui | Ce qu'un utilisateur peut charger en tant que mod |
| :- | :- |
| Aucun | Un mod à partir de n'importe quelle place de marché, à partir de n'importe quel répertoire avec `--plugin-dir`, ou que Claude écrit pendant une session |
| Une liste d'autorisation de place de marché | Un mod à partir des places de marché que vous autorisez, ou à partir de n'importe quel répertoire avec `--plugin-dir`. Un mod que Claude écrit pendant une session se charge uniquement quand la liste d'autorisation [inclut `skills-dir`](/docs/fr/plugins/org#keep-skills-directory-plugins-loading). |
| Une liste d'autorisation de place de marché et `disableSideloadFlags` | Un mod à partir des places de marché que vous autorisez |
[Gérer les plugins pour votre organisation](/docs/fr/plugins/org) liste chaque façon dont un plugin se charge et le paramètre qui contrôle chacun.
Pour vérifier les mods dans une place de marché avant que vos utilisateurs les installent, voir [Examiner ce qu'un mod peut faire](#review-what-a-mod-can-do). Pour empêcher les mods des utilisateurs de se charger jusqu'à ce que vous ayez fait cela, voir [Arrêter le chargement des mods installés par les utilisateurs](#stop-user-installed-mods-from-loading).
Examiner ce qu'un mod peut faire
Vous pouvez voir ce qu'un mod est capable de faire sans l'exécuter. Dans votre shell, exécutez `claude plugin validate` sur le répertoire du plugin :
```bash theme={null}
claude plugin validate ./some-mod
```
Deux lignes de la sortie décrivent le code du mod :
```text theme={null}
❯ ./register.js hooks: session.start, tool.call, ui.render{component=Pane}
❯ ./register.js calls: $.fs.read, $.http.fetch, $.store.set, $.ui.open
```
La ligne `hooks:` liste les événements que le mod reçoit. La ligne `calls:` liste les méthodes de l'API des mods que son code appelle. L'[API des mods](/docs/fr/plugins/mods/api), écrite `$` dans le code d'un mod, est comment un mod atteint les fichiers, processus, et réseau. Claude Code refuse de charger un mod qui utilise l'API des mods d'une manière que cette commande ne peut pas lire.
Regardez la ligne `calls:` pour celles-ci :
| Appel | Ce que cela signifie |
| :- | :- |
| `$.fs.read`, `$.fs.write` | Lit ou écrit des fichiers n'importe où où l'utilisateur peut |
| `$.process.run`, `$.process.spawn` | Démarre des programmes en tant qu'utilisateur |
| `$.http.fetch` | Fait des demandes réseau |
| `$.env.get`, `$.settings.read` | Lit les variables d'environnement et les paramètres, qui peuvent contenir des clés API. Une ligne `env reads:` dans la sortie nomme chaque variable. |
| `$.env.set` | Définit une variable d'environnement pour Claude Code et pour chaque commande et serveur MCP qu'il démarre ensuite, ce qui peut changer ce que ces programmes exécutent. Une ligne `env writes:` nomme chaque variable. |
| `$.mcp.call` | Appelle un outil sur un serveur MCP connecté, selon les règles de permission de la session |
| `$.model.complete` | Utilise le plan ou la clé API de l'utilisateur pour les appels de modèle |
| `$.prompt.submit` | Soumet une invite, et peut l'envoyer comme les propres paroles de l'utilisateur |
| `$.session.send` | Envoie un message qu'une autre session ou sous-agent de Claude lit |
Dans la ligne `hooks:`, [`tool.call`](/docs/fr/plugins/mods/reference#tools) et [`prompt.submit`](/docs/fr/plugins/mods/reference#prompts-and-what-claude-reads) signifient que le mod voit chaque appel d'outil et chaque invite, et peut les changer. [`session.append`](/docs/fr/plugins/mods/reference#session) signifie que le mod peut réécrire chaque ligne de la conversation avant qu'elle ne soit stockée. [`ui.render{component=AskUserQuestion}`](/docs/fr/plugins/mods/interface#change-what-claude-code-already-draws) signifie que le mod peut redessiner la boîte de dialogue que Claude utilise pour poser une question à l'utilisateur. `tool.check` signifie que le mod peut approuver ou refuser un appel d'outil avant qu'une invite de permission n'apparaisse. [Savoir ce qui se passe par défaut](#know-what-happens-by-default) liste lesquels de vos règles et hooks ont la priorité sur sa réponse.
Choisir le niveau d'autorisation
Les politiques de mod vont d'aucun mod installé du tout à n'importe quel mod qu'un utilisateur choisit, avec votre propre mod vérifiant les autres, et chacun est quelques paramètres gérés. Trouvez la politique que vous voulez dans la première colonne et définissez ce que la deuxième colonne nomme. [Déployer les paramètres gérés](/docs/fr/managed-settings) couvre où vivent les paramètres gérés.
| Ce que vous voulez | Paramètres |
| :- | :- |
| Aucun mod installé, avec les hooks intacts | Définissez [`allowManagedModsOnly`](#set-options-on-the-built-in-guard) et ne déployez aucun mod de votre côté |
| Aucun mod installé et aucun hook du tout, y compris vos hooks gérés | Définissez `disableAllHooks` à `true` |
| Uniquement les mods de votre organisation | Définissez l'option [`allowManagedModsOnly`](#stop-user-installed-mods-from-loading) de la garde, et [installez vos mods](#install-your-organizations-mods) pour qu'ils comptent comme les vôtres |
| N'importe quel mod à partir des places de marché que vous approuvez | Gardez vos [restrictions de place de marché](/docs/fr/plugins/org#restrict-what-users-can-install), et définissez `disableSideloadFlags` à `true` |
| N'importe quel mod, avec votre propre mod vérifiant les autres | [Installez votre mod](#install-your-organizations-mods), et listez-le avec `sec-default@builtin` dans `prependPlugins` |
Ce que chaque paramètre fait :
* **`allowManagedModsOnly`** : une option sur la garde intégrée. Les mods des utilisateurs ne se chargent pas, et leurs hooks de paramètres, lignes d'état, et `/goal` continuent de fonctionner. [Arrêter le chargement des mods installés par les utilisateurs](#stop-user-installed-mods-from-loading) liste ce qu'il couvre.
* **`allowManagedHooksOnly`** : un paramètre plus large. Seuls [les mods de votre organisation](#install-your-organizations-mods) et les mods intégrés à Claude Code se chargent. Un mod qu'un utilisateur a installé lui-même ne se charge pas. Le paramètre bloque aussi les hooks dans les fichiers de paramètres propres des utilisateurs. Lisez [Ce qui s'exécute sous `allowManagedHooksOnly`](/docs/fr/settings-reference#what-runs-under-allowmanagedhooksonly) avant de le définir.
* **`disableAllHooks`** : le paramètre le plus large. Dans les paramètres gérés, il arrête les mods dans chaque plugin installé, y compris les vôtres, et désactive chaque hook dans les fichiers de paramètres, donc un hook `PreToolUse` dans vos paramètres gérés ne bloque plus rien. Les lignes d'état personnalisées et `/goal` cessent aussi de fonctionner. Lisez [`disableAllHooks`](/docs/fr/settings-reference#disableallhooks) avant de le définir.
* **`disableSideloadFlags`** : rejette `--plugin-dir` et `--plugin-url` au démarrage, donc personne ne charge un mod à partir d'un répertoire, et empêche les mods que Claude écrit pendant une session de se charger. Le paramètre rejette aussi `--agents` et `--mcp-config`. Lisez [`disableSideloadFlags`](/docs/fr/settings-reference#disablesideloadflags) avant de le définir.
Les mods intégrés à Claude Code, comme le support `AGENTS.md`, ne sont pas affectés par ces paramètres. Chacun a [son propre commutateur](/docs/fr/plugins/mods/overview#mods-built-into-claude-code).
Un utilisateur dont le mod ne s'est pas chargé trouve la raison dans son journal de débogage. [Messages de refus](/docs/fr/plugins/mods/troubleshoot#refusal-messages) liste les lignes pour `allowManagedHooksOnly` et `disableAllHooks`, et [Messages de la garde intégrée](/docs/fr/plugins/mods/troubleshoot#messages-from-the-built-in-guard) a la ligne pour `allowManagedModsOnly`.
Définir les options sur la garde intégrée
La garde intégrée prend deux options. Définissez-les dans les paramètres gérés sous `pluginConfigs`, indexées par `cc-plugin-sec-default@builtin`, comme l'exemple dans [Arrêter le chargement des mods installés par les utilisateurs](#stop-user-installed-mods-from-loading) le fait.
Le tableau donne ce que vos utilisateurs obtiennent avec chaque option non définie et avec elle définie à `true` :
| Option | Non définie | `true` |
| :- | :- | :- |
| `allowManagedModsOnly` | Les mods des utilisateurs se chargent | Seuls [les mods de votre organisation](#install-your-organizations-mods), et les mods intégrés à Claude Code, se chargent. Claude Code refuse tous les autres mods, y compris un que l'utilisateur a installé ou nommé avec `--plugin-dir`. |
| `allowModsToOverrideDenyRules` | Les règles de refus ont la priorité sur les mods des utilisateurs | Le mod d'un utilisateur qui approuve les appels d'outils peut approuver un appel qu'une règle `deny` refuse |
Ces règles décident si une option prend effet :
* **L'id a une seule orthographe ici** : Claude Code lit les options uniquement sous `cc-plugin-sec-default@builtin`. `prependPlugins` accepte aussi `sec-default@builtin`, et `pluginConfigs` ne le fait pas.
* **Seuls les paramètres gérés comptent** : la même entrée dans un fichier de paramètres utilisateur, projet ou local, ou dans un fichier passé avec `--settings`, ne définit ni ne desserre une option
* **La garde doit se charger** : si vous définissez `prependPlugins`, [nommez la garde dans la liste](#install-your-organizations-mods). Là où la garde ne se charge pas, aucune option ne s'applique.
* **La garde échoue fermée** : si la garde ne peut pas lire les paramètres gérés, elle refuse tous les mods des utilisateurs au chargement. Si elle ne peut pas vérifier les règles de refus pour un appel qu'un mod d'utilisateur a approuvé, elle refuse l'appel.
Les [messages de la garde intégrée](/docs/fr/plugins/mods/troubleshoot#messages-from-the-built-in-guard) sont ce que vos utilisateurs voient quand l'une ou l'autre option s'applique.
Exécuter les mods de votre organisation
Vous pouvez déployer des mods de votre côté à chaque utilisateur, choisir où ils s'exécutent par rapport aux mods des utilisateurs, et en utiliser un pour appliquer une politique.
Installer les mods de votre organisation et définir l'ordre
Les mods de votre organisation se chargent là où les mods des utilisateurs ne le font pas et peuvent s'exécuter avant eux, donc Claude Code doit pouvoir dire qu'un mod vient de vous. Il traite un mod comme celui de votre organisation uniquement quand tous ceux-ci sont vrais :
* Les `enabledPlugins` gérés définissent le plugin du mod à `true`
* Les paramètres gérés nomment la [place de marché](/docs/fr/plugins/create-marketplace) du plugin comme un répertoire sur la machine de l'utilisateur, par chemin absolu. Une entrée `extraKnownMarketplaces` le fait et enregistre aussi la place de marché pour l'utilisateur.
* La place de marché liste le plugin par un chemin relatif, donc Claude Code le [charge sur place](/docs/fr/plugins/loading#in-place-and-copied-plugins) à partir de ce répertoire
Pour les respecter, faites en sorte que votre gestion d'appareils copie le répertoire de la place de marché au même chemin sur chaque machine. Rendez le répertoire et chaque répertoire au-dessus de lui inscriptibles uniquement par un administrateur, comme le fichier de paramètres gérés l'est. Quiconque peut écrire là-bas peut réécrire votre mod. Les paramètres gérés que vous livrez à partir de la console d'administration claude.ai peuvent porter les clés, mais ils ne peuvent pas mettre le répertoire sur une machine.
Le répertoire contient le manifeste de la place de marché et le plugin :
```text theme={null}
/opt/acme/claude-plugins/
├── .claude-plugin/
│ └── marketplace.json
└── plugins/
└── acme-guard/
├── .claude-plugin/
│ └── plugin.json
└── hooks/
├── hooks.json
└── register.js
```
Le manifeste liste le plugin par son chemin relatif à ce répertoire :
```json /opt/acme/claude-plugins/.claude-plugin/marketplace.json theme={null}
{
"name": "acme-tools",
"owner": { "name": "Acme" },
"plugins": [
{ "name": "acme-guard", "source": "./plugins/acme-guard", "description": "Acme policy mod" }
]
}
```
Un plugin que Claude Code copie dans son cache compte comme celui d'un utilisateur, même quand les `enabledPlugins` gérés l'activent. Cela couvre chaque plugin à partir d'une source GitHub, git, URL, ou npm. Son mod s'exécute parmi les mods des utilisateurs, `prependPlugins` et `appendPlugins` le sautent, et il ne se charge pas sous `allowManagedModsOnly` ou `allowManagedHooksOnly`. Le journal de débogage de l'utilisateur a une ligne qui commence par l'id du plugin et `is enabled by managed settings, but`.
Claude Code lève un événement chaque fois qu'il est sur le point d'agir, comme exécuter un outil, et le passe à chaque mod à tour de rôle. Un mod qui compte comme le vôtre [s'exécute avant les mods des utilisateurs](/docs/fr/plugins/mods/events#the-order-mods-run-in) même quand vous ne le listez nulle part. Pour définir sa place, listez son id dans l'un de deux paramètres. L'id est le nom du plugin, `@`, et le nom de la place de marché, comme `acme-guard@acme-tools`.
* **`prependPlugins`** : votre mod voit chaque événement avant n'importe quel mod d'utilisateur et chaque résultat après. Il peut changer l'événement, le refuser, ou sauter les mods des utilisateurs.
* **`appendPlugins`** : votre mod s'exécute après chaque mod d'utilisateur, donc il voit uniquement les événements que ces mods transmettent, sous la forme qu'ils les transmettent
Cet exemple déclare la place de marché `acme-tools` à `/opt/acme/claude-plugins`, active `acme-guard` à partir de celle-ci, et exécute ce mod en premier, avec la garde intégrée après :
```json managed-settings.json theme={null}
{
"extraKnownMarketplaces": {
"acme-tools": {
"source": { "source": "directory", "path": "/opt/acme/claude-plugins" }
}
},
"enabledPlugins": { "acme-guard@acme-tools": true },
"prependPlugins": ["acme-guard@acme-tools", "sec-default@builtin"]
}
```
Chaque clé fait un travail :
* **`extraKnownMarketplaces`** : nomme le répertoire qui contient la place de marché `acme-tools`. `path` est le chemin absolu du répertoire qui contient `.claude-plugin/marketplace.json`.
* **`enabledPlugins`** : active `acme-guard` pour chaque utilisateur qui reçoit ces paramètres gérés
* **`prependPlugins`** : met `acme-guard` en premier et la garde intégrée en deuxième, tous deux avant n'importe quel mod qu'un utilisateur installe. Claude Code suit l'ordre que vous listez.
Pour confirmer qu'une machine d'utilisateur a reçu les paramètres, voir [Vérifier qu'une politique est en vigueur](/docs/fr/managed-settings#check-that-a-policy-is-in-force).
Pour confirmer où le mod s'exécute, démarrez une session sur cette machine avec `claude --debug` et recherchez dans le [journal de débogage](/docs/fr/plugins/mods/troubleshoot#read-the-debug-log) l'id du mod :
* **`hooks module acme-guard@acme-tools loaded`, avec `tier prepend`** : le mod compte comme celui de votre organisation et s'exécute en premier
* **La même ligne avec `tier user`** : Claude Code le traite comme un mod d'utilisateur. Une deuxième ligne, `prependPlugins names acme-guard@acme-tools, which is not an enabled managed plugin with a hooks module; skipped`, dit que la liste l'a sauté.
Ces règles décident quels ids dans les deux listes prennent effet :
* **La liste remplace la valeur par défaut** : quand vous définissez `prependPlugins` dans les paramètres gérés, nommez `sec-default@builtin` dans celle-ci pour garder la garde intégrée. La garde est intégrée et n'a besoin d'aucune entrée `enabledPlugins`.
* **Vos propres ids doivent compter comme les vôtres** : dans les paramètres gérés, Claude Code saute un id dont le plugin ne respecte pas les trois conditions pour un mod d'organisation
* **Les référentiels ne peuvent pas les définir** : Claude Code lit les deux paramètres uniquement à partir des paramètres gérés et jamais à partir du fichier de paramètres d'un référentiel. Un utilisateur peut les définir dans `~/.claude/settings.json` pour ordonner uniquement ses propres mods sur une machine sans paramètres gérés, et uniquement quand il n'est pas connecté avec un plan Team ou Enterprise. N'importe où ailleurs, Claude Code ignore les deux clés dans les paramètres utilisateur. Une liste là-bas n'ajoute ni ne supprime la garde intégrée.
Appliquer une politique avec un mod de votre côté
Pour empêcher tous les mods d'un utilisateur de se charger, vous n'avez pas besoin d'un mod de votre côté. Définissez [`allowManagedModsOnly`](#stop-user-installed-mods-from-loading). Écrivez un mod de politique quand vous voulez admettre certains mods d'utilisateurs et en refuser d'autres, ou pour enregistrer ce que les mods font.
Chaque fois qu'un autre mod est sur le point de se charger, votre mod reçoit la liste que `claude plugin validate` imprime, dans un événement nommé [`plugin.register`](/docs/fr/plugins/mods/reference#other-mods). Un mod dans `prependPlugins` peut lire cette liste et refuser le mod. Il peut aussi [accrocher n'importe quel appel de l'API des mods par nom](/docs/fr/plugins/mods/api#reach-files-processes-and-the-network) pour enregistrer ou refuser cet appel pour tous les autres mods. Le nom est la méthode sans le `$.`, donc un crochet sur `fs.write` voit chaque appel `$.fs.write`.
Ce mod de politique refuse n'importe quel mod d'utilisateur dont le propre code appelle `$.process.run` ou `$.process.spawn`. Il garde aussi un journal d'audit, écrivant chaque appel d'outil et chaque fichier qu'un mod écrit dans le journal de débogage. Parce qu'il s'exécute en premier, le journal enregistre ce qui a été demandé, avant que n'importe quel mod d'utilisateur ne le change. Enregistrez-le comme `acme-guard/hooks/register.js` :
```javascript acme-guard/hooks/register.js theme={null}
// Les méthodes qu'aucun mod d'utilisateur ne peut appeler, chacune orthographiée namespace.method
const BLOCKED_CALLS = ['process.run', 'process.spawn']
export function register(on) {
// S'exécute chaque fois qu'un autre mod est sur le point de se charger
on('plugin.register', async ($, e, next) => {
// Gardez les appels dans le code de ce mod qui sont sur la liste bloquée
const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
if (e.tier === 'user' && blocked.length > 0) {
// Retourner refuse empêche le mod de se charger, et le texte est la raison
return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
}
// Laissez tous les autres mods se charger
return next(e)
})
// Enregistrez chaque appel d'outil, puis laissez-le continuer inchangé
on('tool.call', async ($, e, next) => {
$.ui.log('audit tool.call ' + e.tool, { to: 'debug' })
return next(e)
})
// Enregistrez quel mod a écrit un fichier, puis le chemin, entre guillemets car le mod l'a choisi
on('fs.write', async ($, e, next) => {
$.ui.log('audit fs.write by ' + next.origin.plugin + ' ' + JSON.stringify(e.path), { to: 'debug' })
return next(e)
})
}
```
Le fichier enregistre trois crochets :
* **`plugin.register`** : décide si un autre mod se charge. Il refuse un mod d'utilisateur qui appelle une méthode bloquée et transmet tous les autres mods.
* **`tool.call`** : écrit une ligne comme `audit tool.call Bash` dans le journal de débogage pour chaque appel d'outil, et ne change rien
* **`fs.write`** : écrit une ligne comme `audit fs.write by reader "/tmp/notes.md"` pour chaque appel `$.fs.write` qu'un autre mod fait, et ne change rien. Le nom du mod vient en premier et le chemin est entre guillemets, donc un chemin qu'un mod choisit ne peut pas passer pour un autre champ de la ligne.
Le crochet `plugin.register` lit deux champs de l'événement :
* **`e.tier`** : où le mod s'exécuterait, l'un de `prepend`, `user`, `append`, ou `builtin`. Chaque mod qu'une personne installe est `user`.
* **`e.uses.calls`** : les méthodes de l'API des mods que le mod appelle, chacune orthographiée `namespace.method` comme `process.run`, sans le `$.` que `claude plugin validate` imprime
Quand un utilisateur installe un mod qui appelle `$.process.run`, le mod ne se charge pas, et son journal de débogage a une ligne qui se termine par `refused by acme-guard:` et votre raison. Le refus atteint aussi la transcription dans une [session qui recharge à chaud un répertoire de plugin](/docs/fr/plugins/mods/troubleshoot#find-out-why-a-mod-does-nothing). Pour bloquer un appel sans refuser le mod entier, retournez `{ deny: 'your reason' }` d'un crochet sur le nom de cet appel.
Pour envoyer les lignes d'audit quelque part d'autre que le journal de débogage, appelez `$.http.fetch` à partir des mêmes crochets.
Une session peut s'exécuter sans votre mod. Si le thread de travail qui exécute les mods installés [plante trois fois](/docs/fr/plugins/mods/troubleshoot#mods-that-run-in-the-hooks-worker-are-off-for-this-session), Claude Code décharge tous les mods qui ne sont pas intégrés, y compris le vôtre, jusqu'à ce que l'utilisateur exécute `/reload-plugins` ou démarre une nouvelle session. Et un utilisateur qui démarre Claude Code avec `--safe-mode` s'exécute sans mods installés, y compris les vôtres.
[Créer un mod](/docs/fr/plugins/mods/create) couvre les fichiers qu'un mod a besoin. [Tester un mod qui juge d'autres mods](/docs/fr/plugins/mods/test#test-a-mod-that-judges-other-mods) a un fichier de test pour ce mod de politique.
Refuser les mods quand votre vérification échoue
Si votre crochet `plugin.register` lève une exception ou dépasse sa limite de temps, Claude Code saute le crochet, donc la vérification échoue ouvertement et le mod qu'il vérifiait se charge. Pour échouer fermé et refuser les mods des utilisateurs, déplacez la vérification dans une fonction nommée et ajoutez un gestionnaire `.catch` qui retourne le refus. Cette version du fichier montre uniquement le crochet `plugin.register`, donc gardez les deux crochets d'audit de la première version dans `register` :
```javascript acme-guard/hooks/register.js theme={null}
const BLOCKED_CALLS = ['process.run', 'process.spawn']
// La même vérification qu'avant, déplacée dans sa propre fonction
async function checkMod($, e, next) {
const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
if (e.tier === 'user' && blocked.length > 0) {
return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
}
return next(e)
}
export function register(on) {
// Le gestionnaire s'exécute uniquement quand checkMod lève une exception ou dépasse sa limite de temps
on('plugin.register', checkMod).catch(async ($, e, next) => {
// Laissez les mods de votre organisation et les mods intégrés se charger
if (e.tier !== 'user') return next(e)
// Refusez le mod d'utilisateur qui n'a pas pu être vérifié
return { refuse: 'Acme policy check failed, so this mod was not loaded' }
})
}
```
Avec le gestionnaire en place, un mod qui était en cours de vérification quand la vérification a levé une exception ou a dépassé le délai d'attente ne se charge pas, et la ligne de refus porte la deuxième raison, comme dans `refused by acme-guard: Acme policy check failed, so this mod was not loaded`. Le gestionnaire transmet chaque mod en dehors du tier `user` à `next(e)`, donc une vérification échouée n'arrête pas les mods que votre organisation liste. [Gérer un crochet qui échoue](/docs/fr/plugins/mods/events#handle-a-hook-that-fails) couvre `.catch` pour d'autres événements.
Étapes suivantes
* [Sécurité des plugins](/docs/fr/plugins/security) : ce que n'importe quel plugin peut faire sur la machine d'un utilisateur, et comment en examiner un avant qu'il ne soit installé
* [Aperçu des mods](/docs/fr/plugins/mods/overview) : ce qu'est un mod et comment il se compare aux crochets, compétences, et serveurs MCP
* [L'ordre dans lequel les mods s'exécutent](/docs/fr/plugins/mods/events#the-order-mods-run-in) : comment `prependPlugins` et `appendPlugins` s'adaptent aux mods des utilisateurs
* [Paramètres et variables d'environnement](/docs/fr/plugins/mods/reference#settings-and-environment-variables) : chaque paramètre nommé sur cette page dans un tableau