Claude Code Enterprise Mastery

1Sans règles, Claude Code lit votre .env sans broncher

Team Pulse, la petite application du cours, est livrée sans aucun réglage. Vajariya demande à Claude de lire le .env, le fichier où un projet range ses mots de passe, et de tout afficher. Claude obéit, clés AWS (l'accès au nuage d'Amazon) comprises, sans demander la permission (vidéo 2_2).

Le cours énumère quatre menaces, quatre façons de se faire piéger, et celle-ci n'en est qu'une (vidéo 2_3). Les voici :

• Fuite d'identifiants : vos mots de passe et vos clés deviennent lisibles, donc ils peuvent sortir du projet. C'est la démonstration du .env.
• Injection de prompt : un prompt est un message écrit à Claude. Quelqu'un cache une consigne dans un fichier que Claude lit, comme un commentaire de code ou un README (la page de présentation d'un projet). Claude la lit comme du texte, puis la suit comme un ordre.
• Chaîne d'approvisionnement : votre projet utilise du code écrit par d'autres, des bibliothèques de code. Si l'une est piégée, npm install, la commande qui les télécharge, lance un petit programme qui envoie vos identifiants ailleurs.
• Sous-agents : un sous-agent est un petit assistant que Claude lance pour une partie du travail. D'après le cours, chacun reçoit vos droits complets : il peut donc faire tout ce que vous pouvez faire. La documentation ne le dit pas, mais prévoit des règles pour choisir quels sous-agents Claude peut lancer.

2Refuser d'abord, ouvrir ensuite

Contre ces menaces, la consigne du cours est simple : interdire tout ce qui est dangereux, puis ouvrir au cas par cas. Une règle dit à Claude ce qu'il a le droit de faire. Elle existe en trois sortes :

• allow autorise sans demander.
• ask fait poser la question.
• deny refuse.

Si deux règles se contredisent, le refus gagne sur la question, et la question sur l'autorisation (le cours le dit, la documentation le confirme).

La liste de refus de départ du cours interdit :

• rm -rf : supprimer un dossier et tout son contenu.
• La lecture du .env, des clés SSH et des identifiants AWS.
• curl, wget et les outils web de Claude : des commandes qui vont chercher ou envoyer des données sur le web.
• chmod 777 : ouvrir un fichier à tout le monde en lecture, écriture et exécution.
• sudo : s'attribuer des droits d'administrateur.

La liste de refus s'écrit dans un fichier de réglages. Avec ce seul fichier, on refait l'essai de la démonstration : Claude refuse de lire le .env, et la commande npm test, qui lance les tests, reste permise.

Cet extrait vient de la documentation, pas du cours. Il ne montre que trois règles. Dans Bash(curl *), Bash désigne les commandes tapées dans le terminal. L'étoile * remplace n'importe quelle suite de caractères : la règle vise donc toute commande qui commence par curl.

{
  "permissions": {
    "deny": ["Read(./.env)", "Bash(curl *)"],
    "allow": ["Bash(npm run test *)"]
  }
}

Un détail m'a frappé : le cours ne donne pas une liste de refus, mais quatre, qui ne s'accordent pas. La première est celle de la vidéo, les cinq lignes ci-dessus. Les trois autres sont dans les fichiers à télécharger du cours :

• La matrice des permissions, un tableau qui dit ce que chaque rôle a le droit de faire : huit refus.
• Le fichier de l'administrateur, qu'il impose à tous les ordinateurs (idée 3) : dix-neuf refus.
• Le fichier d'un projet : dix refus.

Aucune ne contient toutes les autres. Le fichier de dix-neuf refus ne bloque pas les outils de Claude qui lisent des pages web, que la vidéo bloque. La matrice oublie sudo, la commande qui donne les droits d'administrateur. À vous de les fusionner.

Le fichier de dix-neuf refus bloque aussi npx -y et pip install, deux commandes qui téléchargent du code puis l'exécutent ou l'installent. La documentation n'en parle pas. Il écrit Bash(curl:*) là où elle montre Bash(curl *) : d'après elle (consultée le 30/10/2026), c'est la même règle écrite autrement.

Vajariya promet trop : « ce sont vos limites dures, Claude ne peut pas les franchir, quoi qu'il arrive » (vidéo 2_1). La documentation nuance : voir « Mon avis », plus bas.

3Cinq couches de réglages, et celle de l'entreprise gagne

Claude Code ne lit pas ses réglages à un seul endroit, mais à cinq, que le cours appelle des couches. Les voici, de la plus forte à la plus faible :

1. Réglages gérés (managed-settings.json) : posés par l'administrateur, la personne qui gère les ordinateurs de l'entreprise. Ils valent pour tous les employés.
2. Ligne de commande : les options tapées au lancement de Claude Code. Elles valent pour une seule session, une utilisation du lancement à la fermeture.
3. Local du projet (.claude/settings.local.json) : vos réglages personnels pour ce projet, gardés hors de Git, le logiciel qui garde l'historique du projet.
4. Partagé du projet (.claude/settings.json) : enregistré dans Git, donc toute personne qui récupère le projet reçoit ce fichier.
5. Utilisateur : vos réglages valables pour tous vos projets.

Première règle : quand deux couches fixent la même chose, la plus haute gagne. Exemple tiré de la documentation : l'équipe règle le modèle d'IA par défaut sur Sonnet dans le fichier partagé, et vous préférez Opus. Vous l'écrivez dans votre fichier local, qui est au-dessus : seules vos sessions changent. La couche de l'entreprise est tout en haut, donc rien dans vos fichiers ne défait un réglage géré.

Deuxième règle : les listes de règles, comme allow et deny de l'idée 2, s'additionnent au lieu de s'écraser. Exemple du cours : un développeur autorise curl dans ses réglages globaux, les réglages gérés l'interdisent, et l'interdiction gagne. Ce n'est pas l'ordre des couches qui décide ici, c'est la règle de l'idée 2 : un refus gagne toujours.

Le cours ajoute que le développeur ne peut ni voir ni changer la couche gérée, et qu'une couche haute écrase les basses. La documentation nuance : il peut voir quelle source s'applique, avec la commande /status, et les listes s'additionnent, comme dans la deuxième règle ci-dessus.

4Le bac à sable contre la fatigue d'approbation

Des règles bien posées créent un autre problème : les demandes de permission s'empilent. Chacune est un message qui vous demande d'approuver une action de Claude. Après la dixième en cinq minutes, dit Vajariya, « vous finissez par cliquer sur approuver sans même lire ce que Claude vous demande » (vidéo 2_4). C'est la fatigue d'approbation : on laisse passer une erreur sans la voir.

La réponse du cours est le bac à sable, activé par la commande /sandbox. Ce n'est pas une machine virtuelle, un faux ordinateur dans l'ordinateur. C'est une barrière que le système de l'ordinateur pose autour des commandes que Claude lance. À l'intérieur, Claude travaille normalement : il lance les tests, il écrit dans le dossier du projet. D'après le cours, les limites portent sur les fichiers et sur internet. Dès qu'une commande les dépasse, le système la bloque, quoi que Claude décide.

C'est là que se trouve l'intérêt. La barrière est tenue par le système, pas par la bonne volonté de Claude : on peut donc approuver d'office les commandes qui restent dedans. Elles passent sans question (vidéo 2_4), et les demandes qui restent sont celles que vous lirez encore. Un autre mode, accept edits (accepter les modifications), fait de même pour les fichiers : Claude les modifie sans demander. Dans la démonstration, Claude lance les tests et Git sans poser de question.

Le bac à sable ne remplace pas les règles de refus. Le .env reste bloqué parce que ces règles restent actives (la documentation le confirme pour les commandes). Sa limite sur la lecture est dans « Toujours valable en 2026 ? ».

5Avant de déployer, quatre questions de conformité, puis une liste par secteur

Une fois les ordinateurs encadrés, une autre question arrive : la conformité. C'est le travail du service sécurité, qui vérifie que l'outil respecte les règles de l'entreprise. Selon Vajariya, elle décide si l'on adopte Claude Code ou si l'on arrête le pilote, l'essai mené par quelques ingénieurs. Elle demande où va le code et si l'on peut l'auditer, c'est-à-dire vérifier ce qu'il a fait. Le cours répond (vidéo 8_1) :

• Où va le code : par défaut, vos prompts partent chez Anthropic. Si l'entreprise utilise plutôt le cloud d'Amazon (Bedrock) ou de Google (Vertex AI), ils passent par son compte chez ce fournisseur. Ils transitent par son VPC, un réseau privé réservé à votre entreprise. Anthropic ne les voit « littéralement jamais ».
  • La documentation est moins absolue. Deux petites choses partent quand même vers Anthropic : le nom du site que l'outil web consulte, et la note du sondage de satisfaction (jamais votre conversation). Des réglages coupent les deux.
• Entraînement : entraîner un modèle, c'est lui faire apprendre à partir de textes. Anthropic n'entraîne pas ses modèles sur les données des offres commerciales, celles vendues aux entreprises. La documentation le confirme, sauf si le client choisit de lui fournir ses données.
• ZDR (Zero Data Retention, aucune conservation de données) : une fois la réponse donnée, Anthropic ne garde ni vos prompts ni les réponses. Le cours ajoute que trois choses restent quand même : les données d'usage et de facturation (de quoi vous facturer), les verdicts des filtres de sécurité et les alertes d'usage abusif.
  • La documentation ne reprend pas la liste du cours. Elle donne deux autres cas où Anthropic peut garder des données. D'abord, si la loi l'exige. Ensuite, si ses systèmes de sécurité repèrent une session (une conversation avec Claude Code) contraire aux règles d'usage : il peut alors la garder jusqu'à deux ans.
  • Le ZDR ne vient pas avec l'offre Enterprise. L'entreprise doit le demander à Anthropic, qui l'accorde à celles qui remplissent ses conditions. Il se demande séparément pour chaque compte d'entreprise.
  • Il protège seulement les échanges avec Claude Code. Le chat sur claude.ai et les outils d'autres éditeurs branchés à Claude Code n'en profitent pas. Anthropic garde aussi les adresses e-mail des comptes et les statistiques d'usage.
• Audit local : chaque session laisse un journal en clair (non chiffré) dans le dossier ~/.claude/projects/, où ~ désigne votre dossier personnel (chemin vérifié).

Pourquoi passer par Amazon ou Google ? Une grande entreprise a déjà un contrat avec l'un des deux : une facture, des accès contrôlés, des règles sur l'endroit où ses données ont le droit d'aller. Envoyer son code à Anthropic, c'est un fournisseur de plus à faire valider par le service sécurité. Via Bedrock ou Vertex, elle utilise les mêmes modèles Claude chez un fournisseur qu'elle a déjà accepté.

Les modèles récents y sont : la documentation d'Anthropic du 30/10/2026 cite Opus 5.5, Sonnet 5.5 et Haiku 5.5 sur Bedrock. Je n'ai pas trouvé d'engagement officiel sur le délai d'arrivée d'un nouveau modèle. Des comparatifs tiers parlent de quelques jours à quelques semaines après Anthropic.

Côté prix, des sites tiers donnent le même tarif qu'en direct. Le tarif exact est sur la page de tarifs d'Amazon. Un point est officiel. Une adresse d'accès régionale garantit que les données passent par une région précise. Elle coûte 10 % de plus que l'adresse globale, qui choisit seule le chemin le plus disponible (tarifs d'Anthropic). Le vrai coût reste le travail d'administration : comptes, accès, régions, modèles à choisir.

Les abonnements Team et Max sont des forfaits par personne, vendus par Anthropic. D'après la documentation que j'ai lue, Amazon ne les vend pas. Une quatrième voie existe : Claude Platform on AWS. Anthropic la fait tourner, et la facture passe par AWS. Pour distinguer les voies :

Voie	Qui voit le code	Comment on paie
Abonnement Team ou Max	Anthropic	Forfait par personne
API directe	Anthropic	À l'usage
Claude Platform on AWS	Anthropic	À l'usage, facture AWS
Bedrock ou Vertex	Amazon ou Google, pas Anthropic	À l'usage, facture du fournisseur

Pour préparer ce dossier, la vidéo 8_3 renvoie elle-même à une liste par secteur, à télécharger dans les ressources du cours. Cette liste de conformité tient en deux pages. Elle commence par dix exigences communes, comme un audit des permissions chaque trimestre. Viennent ensuite cinq blocs, un par cadre de règles :

• SOC 2 Type II, un audit qui atteste qu'un fournisseur protège les données de ses clients dans la durée : journaux d'audit gardés au moins 30 jours, puis envoyés à un SIEM. Un SIEM rassemble les journaux de sécurité de toute l'entreprise pour y repérer les incidents.
• Santé (HIPAA), la loi américaine qui protège les données de patients : ZDR « obligatoire », journaux de session effacés au bout de 7 jours au plus, et un BAA signé avec Anthropic. Le BAA est le contrat qui engage un fournisseur à protéger ces données.
• Finance : chaque échange avec Claude journalisé, et les données gardées dans les pays autorisés. Le code des systèmes de trading, qui achètent et vendent des titres, passe par une relecture humaine.
• Administration publique (FedRAMP), le programme qui autorise un service cloud pour l'État fédéral américain : passage obligatoire par un VPC, curl et wget refusés.
• RGPD, le règlement européen sur les données personnelles : un accord de traitement des données signé avec Anthropic, et un droit à l'effacement à organiser.

6Pour éviter un déploiement dans le chaos, trois phases, en commençant par un pilote mesuré

Reste la question du responsable d'équipe : comment passer de quelques curieux à 20, 50 ou même 100 ingénieurs sans que tout parte dans tous les sens ? Vajariya répond par trois phases (vidéo 10_1). Sa phrase d'ouverture : avancer par phases fait « la différence entre le succès et le chaos ».

Le chaos a des visages précis. Le guide d'adoption du dépôt, deux pages à remplir, en liste six :

• Pas de gouvernance : on déploie sans règles de refus, sans CLAUDE.md (le fichier de consignes de l'équipe), sans politique écrite.
• Trop vite : cent ingénieurs reçoivent l'outil avant que les règles soient prêtes.
• Trop lent : l'élan se perd à force d'analyser le pilote.
• Mauvais usages : on généralise des tâches où l'IA n'aide pas.
• Pas de suivi des coûts : on découvre « une facture de 10 000 $ au bout de trois mois ».
• Pas de relais : la direction impose l'outil au lieu de s'appuyer sur l'enthousiasme des équipes.

La vidéo et le guide donnent les mêmes trois phases, avec des durées différentes : quatre semaines chacune dans la vidéo, six puis six puis treize et plus dans le guide. Le cours ne dit pas laquelle suivre. L'ordre compte plus que les durées :

1. Pilote : un petit groupe d'ingénieurs essaie Claude Code, et on mesure leur travail avant l'outil, par exemple le temps qu'ils passent à relire une PR. Une PR (pull request) est une proposition de changement du code. Dans les mots de la vidéo : « il vous faut ces chiffres avant et après ». On repère aussi deux ou trois personnes qui aideront ensuite les autres : la vidéo les appelle des « champions internes ».
2. Standardisation : ce que le pilote a appris devient la règle de toute l'entreprise. On écrit des modèles de CLAUDE.md, le fichier de consignes d'une équipe, des règles de permissions et des réglages communs. Le guide ajoute une politique d'usage de l'IA, validée par la sécurité et le juridique, et un suivi des coûts par équipe.
3. Déploiement : on forme tout le monde et on ouvre des lieux pour poser ses questions, dont une permanence chaque semaine. Les champions internes aident leurs collègues à démarrer.

Avant la première phase, la liste d'accueil du dépôt détaille le travail de l'administrateur. Il branche le SSO, la connexion unique avec le compte de l'entreprise. Il active aussi le SCIM, un protocole qui crée ou supprime les comptes quand un employé arrive ou part. Il fixe des plafonds de dépense et pose le fichier de réglages gérés. Pour chaque développeur, un test simple clôt l'installation : demander à Claude de lire le .env, qui doit être refusé.