Ce qui sort de l'entreprise avec Claude Code, c'est le contenu des fichiers que l'agent lit pour comprendre le contexte, et les commandes qu'il exécute réellement dans le terminal. Ce que l'agent exécute sans supervision dépend entièrement du mode de permission choisi et des règles d'autorisation configurées. Le code produit, lui, vaut ce que vaut la relecture qui suit : aucun agent ne dispense une équipe de vérifier ce qui part en production.
Ces trois sujets, ce que l'outil voit, ce qu'il peut faire, et ce qu'il produit, reviennent systématiquement dans les sessions de formation que nous animons auprès d'équipes de développement. Les questions ne portent presque jamais sur les capacités de l'agent : elles portent sur le contrôle qu'on garde dessus.
Cet article répond dans l'ordre à ces trois questions, avec les réglages concrets à connaître avant de laisser un agent de code travailler sur un dépôt d'entreprise.
1. Ce qui est réellement transmis quand vous utilisez Claude Code
Claude Code n'est pas un outil qui s'exécute intégralement sur votre poste. Pour répondre à une demande, l'agent lit des fichiers, parcourt l'arborescence du dépôt, et envoie ce contenu au modèle pour qu'il raisonne dessus. Concrètement, ce qui transite vers les serveurs d'Anthropic inclut :
- le code source des fichiers ouverts ou consultés pour construire le contexte de la tâche
- les sorties de commandes exécutées (logs, résultats de tests, messages d'erreur)
- tout ce qui se trouve dans ces fichiers, y compris des éléments qui n'auraient jamais dû y figurer
C'est ce dernier point qui pose le plus de risques en pratique. Une clé d'API codée en dur dans un fichier de configuration, un mot de passe de base de données oublié dans un script, un jeu de données de test qui reprend des informations clients réelles : l'agent ne fait pas le tri. Il traite ce qu'il trouve.
La documentation officielle de sécurité de Claude Code détaille les engagements d'Anthropic sur le traitement des données, avec des garanties différentes selon le plan souscrit (grand public, Team, Enterprise). Un responsable technique ne doit jamais se fier à une impression générale glanée en ligne : il doit lire les conditions applicables au contrat réellement signé par son entreprise, en particulier sur la conservation des données et leur usage éventuel pour l'entraînement des modèles.
La conséquence opérationnelle est simple : avant toute session sur un dépôt sensible, un audit rapide des secrets en clair (variables d'environnement, clés, tokens) doit précéder l'arrivée de l'agent, pas la suivre.
2. Les modes de permission : ce que l'agent peut faire sans vous demander
Claude Code fonctionne avec plusieurs modes de permission, et c'est le premier réglage à comprendre avant de déléguer du travail à l'agent.
Mode par défaut
Chaque action sensible (modification de fichier, exécution de commande, appel réseau) déclenche une demande de confirmation explicite. C'est le mode le plus prudent, adapté à la découverte de l'outil ou à un dépôt critique.
Mode d'acceptation automatique des éditions
L'agent applique les modifications de fichiers et une liste de commandes de manipulation de fichiers dans le dossier de travail sans redemander à chaque fois. C'est le mode le plus utilisé une fois la confiance installée, et c'est aussi le plus risqué : l'attention de l'utilisateur baisse justement au moment où l'agent gagne en autonomie. Une commande destructrice qui serait passée en revue en mode par défaut peut s'exécuter sans qu'on la voie passer.
Mode plan
L'agent analyse la demande, propose une démarche détaillée, mais n'exécute rien tant que le plan n'est pas validé. C'est le mode recommandé pour les tâches à fort impact : refactoring large, modification de la logique de paiement, changement de schéma de base de données.
Le piège que nous observons le plus souvent en formation : une équipe bascule en acceptation automatique dès les premières sessions concluantes, sans avoir posé de règles d'autorisation en amont. L'agent devient alors plus rapide, mais aussi plus opaque.
3. Allow, deny, ask : construire ses propres règles d'autorisation
Au delà des modes globaux, Claude Code permet de définir des règles d'autorisation précises par commande ou par chemin de fichier, via trois catégories : allow, deny, ask. Ces règles sont évaluées dans un ordre fixe, deny d'abord, puis ask, puis allow, et la première règle qui correspond l'emporte.
Ce mécanisme change la manière de cadrer un agent en entreprise. Plutôt que de choisir entre "tout valider" et "tout autoriser", une équipe peut :
- pré-autoriser (allow) les commandes sûres et répétitives : lancer les tests, formater le code, lister les fichiers d'un dossier
- bloquer (deny) les commandes destructrices et les chemins sensibles : suppression récursive, accès au dossier des clés SSH, lecture d'un fichier de secrets
- laisser en confirmation (ask) tout ce qui ne rentre dans aucune des deux catégories précédentes
Le point de sécurité important : une règle deny ne peut pas être contournée par une règle allow définie ailleurs. Une fois un chemin ou une commande bloqués, ils le restent, même si une autre règle de la configuration semble les autoriser. C'est ce qui rend la règle deny fiable pour protéger un dossier de secrets ou un répertoire de données clients, sans dépendre de la vigilance de chaque développeur au moment de la session.
Point de vigilance
Les règles de permission se cumulent depuis plusieurs niveaux de configuration : politique d'entreprise, paramètres du projet, préférences locales, paramètres utilisateur. En pratique, cela signifie qu'un développeur seul ne peut pas toujours voir l'ensemble des règles qui s'appliquent à sa session. Documenter la configuration au niveau du projet, dans un fichier versionné, évite les mauvaises surprises entre postes de travail.
4. Repérer une commande destructrice avant de l'accepter
Même avec des règles bien posées, une confirmation finit toujours par apparaître pour une commande qui ne rentre dans aucune catégorie pré-autorisée. C'est là que la lecture attentive du développeur reste irremplaçable.
Quelques signaux qui doivent systématiquement déclencher une pause avant d'accepter :
- une commande de suppression qui cible un chemin large ou une variable (dossier parent, wildcard mal placé)
- une commande qui écrit ou écrase un fichier de configuration partagé entre plusieurs services
- une commande réseau qui sort du périmètre attendu (appel vers un domaine inconnu, envoi de données vers un service tiers)
- une commande git qui réécrit l'historique (force push, reset dur) sur une branche partagée
- une commande qui modifie des permissions système ou des droits d'accès
La bonne pratique en formation que nous transmettons est simple à retenir : si la commande proposée est plus large que ce que la tâche demandée exigeait, elle mérite une relecture ligne par ligne avant validation, pas un clic réflexe. L'agent explique généralement pourquoi il propose une commande : cette explication doit être lue, pas seulement l'action approuvée.
5. Le filet de sécurité : travail en local, versions et points de restauration
Aucune configuration de permissions ne remplace un filet de sécurité au niveau du dépôt lui-même. Deux réflexes réduisent fortement l'impact d'une erreur, humaine ou générée par l'agent.
Privilégier le travail en local
Faire travailler l'agent sur une copie locale du dépôt, plutôt que directement sur un environnement partagé ou de production, limite l'exposition des données d'entreprise et réduit le rayon d'impact d'une commande mal calibrée. C'est la configuration par défaut la plus sûre pour toute session exploratoire.
Committer souvent, sur une branche dédiée
Git et les plateformes comme GitLab deviennent le véritable filet de sécurité d'une session d'agent. Un commit avant de lancer une tâche complexe crée un point de restauration immédiat : en cas de dérive, un retour arrière annule le travail de l'agent sans toucher au reste du dépôt. La discipline recommandée : une branche par tâche, des commits fréquents et atomiques, jamais de session longue sans point de sauvegarde intermédiaire.
Cette discipline rejoint les pratiques déjà en place pour les workflows dynamiques avec plusieurs agents Claude Code : plus une session est longue ou parallélisée, plus les points de restauration réguliers deviennent indispensables.
6. La gestion du contexte, la relecture du code et la charte d'équipe
Nettoyer et compacter le contexte
Une session d'agent qui s'étire accumule du contexte : fichiers lus, commandes passées, discussions précédentes. Ce contexte alourdit le raisonnement de l'agent et peut le faire dériver sur des décisions prises tôt dans la session, devenues obsolètes. Nettoyer la session entre deux tâches distinctes, ou compacter le contexte sur une tâche longue, maintient la pertinence des réponses et limite la quantité d'information exposée dans une seule session.
La relecture reste non négociable
Le code produit par un agent se relit exactement comme le code produit par un développeur, avec une attention renforcée sur les points de sécurité classiques : validation des entrées utilisateur, gestion des droits d'accès, dépendances ajoutées sans justification. Un agent peut produire du code qui fonctionne et qui reste vulnérable : la syntaxe correcte ne garantit jamais la sécurité fonctionnelle. Notre guide pour relire du code généré par IA détaille les points de contrôle à appliquer systématiquement avant toute fusion. Sur ce sujet, la question n'est pas seulement celle de l'agent utilisé, mais de la place des agents de code face à un développement sur mesure encadré quand la criticité du projet augmente.
Formaliser une charte d'équipe
Les équipes qui tirent le meilleur parti de l'agent sur la durée sont celles qui ont posé leurs règles par écrit, avant les incidents plutôt qu'après. Une charte d'équipe efficace tient sur une page et précise :
- les dépôts autorisés et les dépôts explicitement interdits à l'agent
- le mode de permission par défaut accepté pour les sessions courantes
- la liste des commandes pré-autorisées (allow) et bloquées (deny)
- l'obligation de travailler sur une branche dédiée, avec des commits fréquents
- la règle de relecture humaine avant toute fusion vers la branche principale
Cette charte se construit en formation avec l'équipe elle-même, à partir de ses dépôts réels et de ses incidents passés : c'est ce que nous mettons en place dans notre formation Claude Code sécurité, en partant des permissions déjà en place dans vos projets plutôt que d'un modèle générique. Cette étape s'inscrit plus largement dans la démarche à suivre pour déployer Claude Code en équipe, où la charte de permissions n'est qu'une des briques à cadrer. Pour les équipes qui découvrent l'outil, notre formation vibecoding avec Claude Code pose d'abord les bases de l'usage courant avant d'aborder ces réglages de sécurité.
Pour aller plus loin :
- MCP (Model Context Protocol) en entreprise : comprendre les connecteurs que Claude Code peut mobiliser au delà du terminal.
- Dynamic workflows dans Claude Code : orchestrer plusieurs agents en parallèle sans perdre le contrôle.
- Agents de code contre développement sur mesure : quand la criticité du projet change la réponse.
- Formation vibecoding avec Claude Code : les bases avant d'aborder les réglages de sécurité.
- Claude Opus 5 pour l'entreprise : le modèle qui exécute les tâches de code derrière Claude Code.
Claude Code en entreprise
Cadrez les permissions et la relecture avant de déléguer du code à un agent.
