« Je comprends que c’est pratique. Mais honnêtement, n’est-ce pas effrayant que l’IA exécute des commandes sur les PC des employés ? »
C’est la préoccupation la plus courante que j’entends de la part des dirigeants lorsqu’il s’agit d’accompagner le déploiement de l’IA. Une IA qui reste dans un navigateur, comme ChatGPT, n’est pas aussi intimidante. Mais Claude Code lit les fichiers sur les ordinateurs des employés, exécute des commandes et accède à Internet. « Je sais que ça accélère les choses. Mais qui prend la responsabilité si un accident se produit ? » De nombreuses entreprises sont probablement bloquées à ce stade.
Une grande entreprise a apporté une réponse à cette angoisse. Mercari a récemment partagé ses « réglages de sécurité et méthodes de distribution » utilisés lors du déploiement de Claude Code auprès de centaines d’employés, lors d’une session d’étude.
De plus, le contenu ne concernait pas des systèmes propriétaires coûteux. En préparant et en distribuant un seul fichier de configuration, même les petites et moyennes entreprises (PME) peuvent reproduire l’essentiel.
La raison pour laquelle Mercari a pu le distribuer à des centaines de personnes n’était pas un mécanisme onéreux, mais un simple « fichier de configuration que les employés ne peuvent pas supprimer ». Les PME peuvent faire de même dès aujourd’hui.
Dans cet article, je vais décomposer la conception de Mercari de la manière la plus simple possible, en abordant « ce qu’il faut craindre », « comment Mercari l’a géré » et « par où votre entreprise peut commencer ». J’ajouterai des explications sur les termes techniques au fur et à mesure, afin que les dirigeants non ingénieurs et les chefs de produit puissent suivre.
Vous trouverez les supports de présentation référencés ici :
(Paramètres de sécurité du déploiement organisationnel de Claude Code chez Mercari / Speaker Deck).
La syntaxe exacte des paramètres a été vérifiée par rapport à la documentation officielle d’Anthropic.
Pourquoi Claude Code est-il « pratique mais effrayant » ?
Commençons par clarifier la nature de la peur. Je pense que si vous copiez les réglages sans comprendre cela, vous ne saurez pas ce que vous protégez réellement.
Ce qui distingue Claude Code d’un chat IA standard, c’est qu’il peut agir de lui-même sur votre ordinateur local. Il peut chercher et lire des fichiers, les réécrire et exécuter des commandes shell (commandes tapées dans un terminal). Il peut aussi accéder à Internet. En d’autres termes, presque tout ce que vous pouvez faire sur cet ordinateur, l’IA peut aussi le faire.
Concrètement, que pourrait-il mal tourner ? Les ordinateurs contiennent généralement des choses que vous ne voulez pas voir exposées :
- Des informations servant de mots de passe pour les services cloud ou les API (fichiers de configuration comme
.env,~/.aws/credentials, etc.) - Des clés pour se connecter aux serveurs (contenu de
~/.ssh/) - Des fichiers importants dont la suppression serait désastreuse
L’IA n’a pas de mauvaise intention. Cependant, en raison d’instructions ambiguës ou de commandes intégrées dans un texte suspect sur le Web (appelé injection de prompt), elle pourrait accidentellement lire ces fichiers secrets et les envoyer sur Internet, ou supprimer des éléments importants avec la commande rm. La documentation officielle d’Anthropic recommande une conception qui restreint les permissions en fonction de ces risques (Paramètres de permissions – Officiel).
En résumé, il y a trois choses à protéger : empêcher les fuites d’informations secrètes, empêcher l’exécution automatique d’opérations dangereuses et limiter le périmètre de ce qui peut être touché. Les mesures de Mercari deviennent beaucoup plus faciles à comprendre lorsqu’on les lit à travers ces trois prismes.
Décomposition des « 5 mesures » de Mercari
La présentation de Mercari résumait cinq mesures principales. Nous allons voir « l’objectif » et « comment la mettre en œuvre » pour chacune.
Veuillez noter que les diapositives de la présentation se concentrent sur les concepts et n’incluent pas tous les détails du fichier de configuration. Je présenterai donc cela sous la forme « comment mettre en œuvre les politiques de Mercari en utilisant les paramètres officiels de Claude Code. » Les noms des clés et la syntaxe sont tous vérifiés à partir de la documentation officielle d’Anthropic.
Mesure ① : Rendre la confirmation humaine « obligatoire »
Claude Code dispose d’un mode qui procède automatiquement sans demander de confirmation à chaque fois. Bien que pratique pour les développeurs sur leurs PC d’expérimentation, autoriser ce mode lors d’un déploiement à toute l’entreprise retire les freins de sécurité.
Mercari a désactivé ce « mode de contournement de confirmation ». Officiellement, des réglages comme permissions.disableBypassPermissionsMode (et disableAutoMode pour bloquer le mode automatique) sont disponibles. Les définir sur « disable » empêche les utilisateurs d’entrer dans ces modes. De plus, s’ils sont placés dans les « paramètres gérés » décrits plus loin, les employés ne peuvent pas les désactiver eux-mêmes (Paramètres de permissions – Officiel).
Le sens est simple : il impose la règle « un humain doit donner son accord avant que l’IA n’agisse » à l’échelle de toute l’entreprise.
Mesure ② : Bloquer les commandes dangereuses, ou toujours demander confirmation
Ensuite, nous mettons une laisse aux commandes elles-mêmes. Par exemple, curl (une commande pour récupérer des données sur Internet). Si elle est utilisée librement, elle peut devenir un moyen d’envoyer des fichiers secrets à l’extérieur.
Dans Claude Code, vous pouvez définir une liste deny pour des commandes spécifiques et une liste ask qui nécessite une confirmation avant exécution. La syntaxe ressemble à ceci :
1{2 "permissions": {3 "deny": [4 "Bash(curl:*)",5 "Bash(wget:*)"6 ],7 "ask": [8 "Bash(git push:*)"9 ]10 }11}
Bash(curl:*) signifie « bloquer toutes les commandes commençant par curl » (le :* à la fin représente « tout ce qui suit »). Une remarque importante : la documentation officielle indique qu’essayer d’autoriser curl uniquement pour des destinations spécifiques comme GitHub peut être facilement contourné par des redirections. Par conséquent, la recommandation officielle est de bloquer complètement les communications Internet et d’unifier les récupérations nécessaires par un port sûr séparé (Paramètres de permissions – Officiel). Ce « port sûr » est WebFetch (une fonctionnalité intégrée de Claude Code pour la récupération sur Internet), dont les destinations peuvent être listées en blanc.
Mesure ③ : Empêcher la lecture des fichiers secrets et la modification du système
Nous bloquons également l’accès aux informations secrètes elles-mêmes, comme les fichiers .env où résident les mots de passe, ou la commande sudo utilisée pour des modifications profondes du système.
1{2 "permissions": {3 "deny": [4 "Read(.env)",5 "Read(.env.*)",6 "Read(**/.ssh/**)",7 "Bash(sudo:*)"8 ]9 }10}
Écrire Read(.env) rend .env illisible à tous les niveaux sous le dossier de travail. Une chose à savoir pour la sécurité : même si cette liste d’interdiction fonctionne contre la lecture de fichiers par Claude ou des commandes évidentes comme cat, elle ne peut pas arrêter complètement un script écrit par l’IA qui ouvrirait un fichier secrètement en arrière-plan (Paramètres de permissions – Officiel). C’est pourquoi la mesure ④ est nécessaire.
Mesure ④ : Enfermer la « portée » avec un bac à sable (sandbox)
Alors qu’une liste d’interdiction consiste à tracer des lignes pour des commandes spécifiques, un bac à sable crée un mur au niveau du système d’exploitation. Il restreint physiquement l’IA à ne pas toucher à quoi que ce soit en dehors du dossier de travail, ni à se connecter à autre chose que les domaines Internet autorisés.
1{2 "sandbox": {3 "enabled": true,4 "network": {5 "allowedDomains": ["*.github.com", "registry.npmjs.org"]6 }7 }8}
Lorsqu’il est activé, même si l’IA essaie accidentellement d’atteindre un fichier secret, elle ne peut pas y accéder car il se trouve en dehors du « bac à sable ». La documentation officielle explique que vous devez superposer à la fois la liste d’interdiction (mesures ② et ③) et le bac à sable pour la frontière finale (Bac à sable – Officiel). Considérez cela comme ayant à la fois des règles individuelles et une clôture périmétrique.
Une contrainte : le bac à sable fonctionne sur macOS, Linux et WSL2 (Linux sur Windows), mais il n’est pas pris en charge sur Windows natif. Dans les environnements centrés sur Windows, la décision serait de renforcer les paramètres de permission des mesures ① à ③.
Mesure ⑤ : Faire lire à l’IA « ce qu’il faut protéger » à chaque fois
Enfin, un angle différent des réglages rigides : écrivez la politique de sécurité de l’entreprise dans un manuel d’instructions que l’IA lit à chaque fois. Si les réglages sont des « verrous physiques », cela équivaut à une « révision des règles de l’entreprise ».
Il existe plusieurs façons techniques de le faire, et les supports ne précisent pas laquelle Mercari a utilisée. Cependant, le moyen le plus simple est de placer un fichier nommé CLAUDE.md directement dans le dossier de travail et d’y lister les règles internes. Claude Code lit ce fichier à chaque fois.
1# Demandes de sécurité2- Ne pas ouvrir les fichiers .env ou les clés (~/.ssh/, etc.)3- Ne pas envoyer d’informations clients ou de secrets commerciaux vers des services externes4- Toujours confirmer avec un humain avant d’exécuter des opérations de suppression ou de publication
Action du jour : Coller simplement ces trois lignes dans un fichier CLAUDE.md ajoute une couche de bon sens au comportement de l’IA. Vous pouvez commencer par là avant même les fichiers de configuration.
Action du jour : Vous n’êtes pas obligé de tout implémenter d’un coup. Commencez par ajouter uniquement la ligne Read(.env) de la mesure ③ dans un fichier de configuration nommé .claude/settings.json. Créez un dossier nommé .claude (avec un point au début) dans votre dossier de projet et enregistrez-y un fichier texte nommé settings.json. Si vous voulez l’appliquer à tous les projets, placez-le dans ~/.claude/settings.json dans votre répertoire personnel. Vous pouvez commencer par l’action la plus efficace : empêcher l’IA de lire les fichiers secrets.
Le vrai savoir-faire de Mercari résidait dans la « distribution »
Jusqu’ici, nous avons couvert « quoi configurer ». La présentation de Mercari était particulièrement pratique car elle abordait la manière de distribuer ces réglages à des centaines de personnes.
Normalement, les fichiers de configuration sont placés sur l’ordinateur de chaque personne (paramètres utilisateur), ce qui signifie que les employés peuvent les modifier. Cela conduit à des situations où « les réglages de sécurité ont été distribués, mais quelqu’un les a désactivés ».
Pour résoudre ce problème, Mercari a utilisé un MDM (Mobile Device Management – un système permettant aux entreprises de gérer les PC des employés) pour distribuer simultanément des « paramètres gérés » que les employés ne peuvent pas écraser. Claude Code dispose d’un emplacement dédié pour les paramètres gérés, qui ont priorité sur les paramètres individuels et ne peuvent pas être modifiés par l’utilisateur. Sur macOS, il s’agit de /Library/Application Support/ClaudeCode/managed-settings.json (Paramètres – Officiel). En y inscrivant les mesures ① à ④, celles-ci ne peuvent pas être assouplies sur le terrain.
Encore plus intelligent : différencier les niveaux de sécurité pour les ingénieurs et les non-ingénieurs :
- Pour les ingénieurs : des réglages qui autorisent une certaine personnalisation et ne nuisent pas trop à la productivité.
- Pour les non-ingénieurs : les réglages les plus sûrs par défaut, avec moins de marge de manœuvre.
Même pour le même outil, ils ont ajusté la longueur de la laisse en fonction de la littératie de l’utilisateur. Si tout le monde est strictement restreint, le travail s’arrête ; si tout le monde est laxiste, les accidents surviennent. Ils ont résolu ce problème en variant les réglages distribués.
Par où les PME peuvent commencer à reproduire
La plupart des entreprises n’ont probablement pas de MDM. Ce n’est pas grave. Vous pouvez extraire les parties de la conception de Mercari qui fonctionnent indépendamment de l’échelle.
Tout ce que vous avez à faire est distribuer un seul fichier avec les réglages de sécurité et demander de le placer. Si vous avez un MDM, distribuez-le en tant que paramètre géré ; sinon, partagez-le en disant : « Merci de placer ce settings.json dans votre dossier .claude/. » Le niveau d’application est moindre, mais la direction est la même.
En ensemble minimal, voici ce que donne la combinaison des mesures ① à ③. Je recommande de l’utiliser comme base et d’ajouter les commandes spécifiques que votre entreprise souhaite interdire.
1{2 "permissions": {3 "disableBypassPermissionsMode": "disable",4 "deny": [5 "Bash(curl:*)",6 "Bash(wget:*)",7 "Bash(sudo:*)",8 "Read(.env)",9 "Read(.env.*)",10 "Read(**/.ssh/**)"11 ],12 "ask": [13 "Bash(git push:*)",14 "Bash(rm:*)"15 ]16 }17}
De haut en bas : désactiver le contournement de confirmation, bloquer les communications Internet et les opérations d’administration, interdire la lecture des fichiers secrets, et toujours demander confirmation pour la suppression ou la publication. Même si vous n’en comprenez pas le contenu, cela fonctionnera si vous le copiez-collez.
Si vous distribuez à des non-ingénieurs, je recommande la version la plus sûre, qui ajoute le bac à sable (mesure ④). La combinaison des deux réglages en un seul fichier ressemble à ceci :
1{2 "permissions": {3 "disableBypassPermissionsMode": "disable",4 "deny": [5 "Bash(curl:*)",6 "Bash(wget:*)",7 "Bash(sudo:*)",8 "Read(.env)",9 "Read(.env.*)",10 "Read(**/.ssh/**)"11 ],12 "ask": [13 "Bash(git push:*)",14 "Bash(rm:*)"15 ]16 },17 "sandbox": {18 "enabled": true,19 "network": {20 "allowedDomains": ["*.github.com", "registry.npmjs.org"]21 }22 }23}
J’ai simplement placé permissions et sandbox côte à côte, séparés par une virgule. Modifiez allowedDomains pour qu’ils correspondent aux services utilisés par votre entreprise. Rappelez-vous que le bac à sable fonctionne sur macOS, Linux et WSL2.
Ce que je dis toujours aux gens lorsque j’accompagne un déploiement, c’est : ne vous arrêtez pas parce que vous visez la perfection. Même si vous ne pouvez pas construire une défense multicouche comme celle de Mercari tout de suite, protéger .env avec une seule ligne réduit considérablement la probabilité d’un accident.
Action du jour : Si ne serait-ce qu’une seule personne dans votre entreprise commence à utiliser Claude Code, partagez l’ensemble minimal ci-dessus sous forme de texte et demandez-lui de le coller dans .claude/settings.json. C’est une taille parfaite pour une répétition de distribution.
Pièges : 3 choses à savoir avant de distribuer les réglages
Comme il s’agit de durcir la sécurité, il y a des points dangereux à méprendre.
- « Écrire une liste d’interdiction » ne signifie pas que c’est parfaitement sûr. Comme mentionné dans la mesure ③, une liste d’interdiction ne peut pas tout arrêter ce qu’un script pourrait faire en arrière-plan. Même si vous bloquez
curl, d’autres méthodes de communication peuvent subsister. Si vous voulez vraiment enfermer, n’oubliez pas le principe de la superposer avec un bac à sable (mesure ④). - Ne vous fiez pas au filtrage par arguments. Anthropic lui-même prévient que les permissions conditionnelles, comme autoriser
curluniquement pour une URL spécifique, sont facilement contournées. Il est plus robuste de bloquer complètement les choses dangereuses et de fournir une alternative sûre. - Ne vous contentez pas de distribuer les réglages et de vous en laver les mains. Même si vous imposez des paramètres gérés, cela ne sert à rien si les employés installent eux-mêmes d’autres outils suspects. Les réglages sont un « mécanisme pour réduire les accidents » et fonctionnent mieux lorsqu’ils sont associés à une éducation sur l’utilisation. C’est là que la mesure ⑤, « leur faire lire les règles », entre enfin en jeu.
FAQ pour les utilisateurs intermédiaires
Q. Y a-t-il un intérêt à configurer cela pour un usage personnel ?
Oui. Le critère est de savoir si des informations secrètes se trouvent sur cet ordinateur, pas s’il s’agit d’une entreprise. Les freelances et les développeurs individuels ont aussi des .env et ~/.ssh/ en local. Au minimum, il est plus sûr d’inclure l’interdiction de lecture de la mesure ③.
Q. Restreindre les permissions ne va-t-il pas rendre l’IA inutile ?
C’est une question de comment on les restreint. Les commandes en lecture seule (comme ls ou cat) fonctionnent sans confirmation par défaut, donc le travail quotidien est rarement arrêté. Ce qui s’arrête, ce sont les opérations comme la suppression, la publication et la communication Internet – des choses qui font mal si elles tournent mal. En fait, en passant à « les humains vérifient seulement quand c’est dangereux », vous pouvez étendre en toute sécurité la gamme de tâches que vous confiez à l’IA en automatique.
Q. Quelle est la différence entre `settings.json` et les paramètres gérés (`managed-settings.json`) ?
L’emplacement et la « force » diffèrent. settings.json dans le dossier .claude/ d’un projet est un paramètre partagé que tout le monde peut modifier. managed-settings.json est distribué par l’entreprise et ne peut pas être changé par l’utilisateur. Pour les individus ou les petits groupes, le premier suffit ; passez au second lorsque vous atteignez le stade où « c’est un problème si quelqu’un assouplit les réglages ».
Q. Puis-je utiliser la même logique pour Cursor ou d’autres outils de codage IA ?
Les choses que vous voulez protéger (secrets, opérations dangereuses, portée) sont les mêmes, donc le concept s’applique. Cependant, la syntaxe et la présence du bac à sable varient selon l’outil, considérez donc cette notation settings.json comme spécifique à Claude Code. Si vous utilisez d’autres outils, le raccourci est d’appliquer ces trois mêmes perspectives à leur documentation officielle respective.
Résumé : Passer de « Ne pas utiliser » à « Distribuer en toute sécurité »
Lorsque je reçois des consultations sur le déploiement de l’IA, la réponse la plus courante était « C’est dangereux, on ne peut pas encore les laisser l’utiliser ». Mais cette décision jette aussi tous les avantages pratiques.
Mercari nous a montré une issue à ce choix binaire. Désactiver le contournement de confirmation, arrêter les opérations dangereuses, interdire de toucher aux fichiers secrets, enfermer dans un bac à sable et faire lire les règles. Ensuite, distribuer le tout sous forme de réglages que personne ne peut modifier. C’est une conception qui fait passer de « interdit parce que c’est effrayant » à « distribué avec une laisse parce que c’est effrayant ».
- Cibles à protéger : Empêcher les fuites de secrets / Empêcher les opérations dangereuses / Limiter la portée.
- Les 5 mesures de Mercari : Désactiver le contournement, restreindre les commandes dangereuses, interdire les fichiers secrets, bac à sable, et lecture des règles.
- Distribution : Utiliser des paramètres gérés que l’utilisateur ne peut pas écraser, différenciés selon la littératie.
Enfin, voici trois étapes à réaliser dès aujourd’hui :
- Ajoutez `Read(.env)` sur votre propre ordinateur : Commencez par interdire la lecture des fichiers secrets. C’est l’action unique la plus efficace.
- Créez un seul fichier avec l’ensemble minimal : En vous basant sur l’exemple
permissionsci-dessus, ajoutez les commandes que votre entreprise souhaite arrêter. - Distribuez-le à une personne de l’entreprise pour tester : Demandez-lui de le coller dans
.claude/settings.jsonet vérifiez ensemble que le travail ne s’arrête pas.
Le premier pas est une seule ligne pour protéger .env. Vous pouvez ensuite superposer une défense multicouche parfaite, une par une. Pourquoi ne pas placer ce premier fichier aujourd’hui et passer de « stopper parce que c’est effrayant » à « déléguer avec une laisse » ?
