Interface, modes et permissions

Pourquoi ce chapitre compte

Claude CodeClaude CodeIAInterface en ligne de commande agentique qui lit, édite et exécute des actions dans un dépôt de code sous contrôle de permissions, par opposition à un simple chat web.Voir dans le glossaire n'est pas un chat auquel on colle du texte en attendant une réponse. C'est un agent en ligne de commandeAgent CLIIAProgramme en terminal qui enchaîne raisonnement et outils (lecture, édition, commandes) pour accomplir une tâche dans un environnement local.Voir dans le glossaire : il lit des fichiers, en écrit, exécute des commandes shell, et peut modifier un dépôt versionné sans qu'on ait retapé quoi que ce soit ailleurs. Cette capacité change la nature du risque. Un assistant conversationnel qui se trompe produit du texte incorrect ; un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire CLI qui se trompe peut supprimer un fichier, écraser une configuration ou lancer une commande destructrice — avec les droits du compte qui l'exécute.

Ce chapitre couvre trois leviers qui déterminent votre marge de sécurité au quotidien : le mode de fonctionnement (interactif ou printMode printIAMode non interactif de Claude Code adapté aux scripts et à l'automatisation : la réponse est émise puis le processus se termine.Voir dans le glossaire/headless), le choix du modèle sollicité, et le système de permissions qui arbitre entre autonomie de l'agent et contrôle humain. Les maîtriser n'est pas un raffinement optionnel : c'est ce qui sépare un usage productif d'un incident évitable.

Le mode interactif : une session de travail

Lancé sans argument particulier depuis un dépôt, Claude Code ouvre une session interactive dans le terminal. Vous décrivez un objectif, l'agent propose un plan ou agit directement selon le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, et chaque action sensible (écriture de fichier, commande shell) peut déclencher une demande de confirmation avant exécution.

Ce mode convient à la majorité du travail réel : explorer une base de code inconnue, déboguer un test qui échoue, refactorer un module, écrire une fonctionnalité en plusieurs itérations. La session garde le contexte de l'échange — fichiers déjà lus, décisions déjà prises, corrections déjà demandées — ce qui évite de tout réexpliquer à chaque tour.

Deux réflexes structurent une bonne session interactive :

• Décrire l'objectif, pas la procédure. Plutôt que d'énumérer chaque commande à taper, formulez le résultat attendu et laissez l'agent proposer une démarche. Vous restez libre de la corriger avant qu'elle ne s'exécute.
• Lire les diffs avant d'accepter. Une modification de fichier proposée reste une proposition tant qu'elle n'est pas validée. La lire prend quelques secondes ; la corriger après coup, beaucoup plus.

Avant de laisser l'agent modifier quoi que ce soit, il est possible de lui demander explicitement un plan d'action — une liste des étapes envisagées, sans exécution. C'est l'équivalent d'une revue de conception avant chantier : on négocie l'approche pendant qu'elle ne coûte rien à changer, plutôt qu'après que les fichiers ont déjà bougé.

Le mode print / headless : une commande, une sortie

À l'opposé du mode interactif, le mode print (parfois appelé headless) exécute une seule requête, produit une sortie texte ou structurée, puis termine le processus. Il n'y a pas d'échange, pas de confirmation à l'écran, pas de session à maintenir ouverte.

Ce mode est fait pour l'automatisation : un script de build qui demande un résumé de changelog, une étape de pipeline CI qui vérifie la cohérence d'une documentation, un cron qui génère un rapport. On l'invoque, on récupère la sortie, on l'utilise dans la suite du pipeline — exactement comme n'importe quel outil en ligne de commande classique.

En mode print, personne ne regarde l'écran au moment de l'exécution. Cela ne dispense pas de contrôle : cela déplace le contrôle en amont, dans la configuration des permissions et dans la conception du script qui invoque l'agent. Un pipeline qui appelle Claude Code en headless avec des droits d'écriture et d'exécution shell non restreints reproduit, sans supervision, les mêmes risques qu'une session interactive mal cadrée.

Choisir un modèle selon la tâche

Claude Code permet de sélectionner le modèle sollicité pour une session ou une tâche donnée. Ce choix n'est pas cosmétique : un modèle plus rapide et moins coûteux convient à des tâches mécaniques et bien cadrées (renommer des occurrences, écrire un test unitaire simple, résumer un fichier de log) ; un modèle plus capable se justifie pour du raisonnement en plusieurs étapes, une architecture à concevoir, ou un bug dont la cause n'est pas localisée.

Le critère pratique n'est pas « quel est le meilleur modèle dans l'absolu », mais « quel est le rapport entre la difficulté réelle de la tâche et le coût — en temps, en tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire, en risque d'erreur — d'un modèle insuffisamment capable pour elle ». Confier une refonte d'architecture à un modèle taillé pour la vitesse produit des réponses plausibles mais superficielles ; à l'inverse, mobiliser le modèle le plus capable pour renommer une variable dans douze fichiers est simplement un gaspillage.

Une session de refactoring important commence avec un modèle capable pour explorer le code, comprendre les dépendances et proposer une stratégie. Une fois le plan validé, les modifications mécaniques qui en découlent — appliquer le même changement dans une trentaine de fichiers similaires — peuvent être déléguées à un modèle plus rapide, avec une supervision allégée puisque le schéma de modification a déjà été validé une fois.

Le modèle de permissions : lecture, écriture, exécution

Les capacités de Claude Code se répartissent en trois paliers de risque croissant, visibles dans le schéma ci-dessus.

Lecture. Parcourir l'arborescence, ouvrir des fichiers, effectuer des recherches dans le code. C'est la base de tout travail utile et le risque associé est faible : lire un fichier ne le modifie pas. La plupart des configurations autorisent ces opérations sans confirmation systématique.

Écriture. Créer ou modifier un fichier versionné. Le risque devient réel : une modification malvenue peut casser une fonctionnalité, introduire une régression silencieuse, ou écraser un travail en cours non commité. C'est pourquoi l'écriture déclenche, par défaut, une demande de confirmation — sauf configuration explicite pour l'accepter automatiquement dans un périmètre défini.

Shell et réseau. Exécuter une commande système, installer une dépendance, appeler une API externe, pousser un commit. C'est le palier le plus sensible : une commande shell peut agir en dehors du dépôt, affecter l'environnement local, ou avoir des effets qui ne sont pas triviaux à annuler. C'est aussi le palier où une instruction ambiguë ou un fichier compromis peut, en théorie, être détourné pour exécuter autre chose que ce qui était prévu.

Entre ces trois paliers, Claude Code propose plusieurs postures de validation : demander confirmation à chaque action sensible, accepter automatiquement certaines catégories d'actions dans un projet de confiance, ou restreindre certains outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire à une liste explicite d'autorisations. Le réglage adapté dépend du terrain : un dépôt personnel expérimental ne justifie pas le même niveau de friction qu'un dépôt de production partagé.

CLAUDE.md et MCP : cadrer sans tout redemander

Un fichier CLAUDE.md placé à la racine d'un dépôt permet de documenter, une fois, les conventions du projet : structure des dossiers, commandes de test à utiliser, style de code attendu, actions à éviter. L'agent lit ce fichier automatiquement en début de session et s'y conforme, ce qui évite de répéter les mêmes consignes à chaque nouvelle conversation. C'est un espace de configuration du comportement, pas un espace de permissions au sens strict — mais il influence directement la qualité des propositions faites, y compris sur les zones sensibles du projet.

Le protocole MCP (Model Context ProtocolMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire) étend les capacités de l'agent en le connectant à des outils ou sources de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire externes — un gestionnaire de tickets, une base documentaire, un service interne. Chaque serveur MCP connecté élargit la surface de ce que l'agent peut lire ou déclencher. Le principe de prudence reste le même que pour le shell : connecter un serveur MCP, c'est accorder une capacité, et cette capacité doit être évaluée pour ce qu'elle permet réellement, pas seulement pour ce qu'elle est censée faire.

Documenter une convention dans CLAUDE.mdCLAUDE.mdIAFichier Markdown de consignes stables placé dans un projet pour orienter Claude Code (stack, conventions, périmètre, interdits) sans les répéter à chaque prompt.Voir dans le glossaire aide l'agent à mieux se comporter, mais ne constitue pas une garantie de sécurité. Un fichier de configuration reste une instruction en langage naturel, pas un mécanisme de contrôle d'accès. Les permissions techniques (lecture, écriture, shell) restent le vrai périmètre de sécurité ; CLAUDE.md agit sur la qualité, pas sur le contrôle.

Les pièges de l'acceptation trop large

Le principal risque opérationnel n'est pas que l'agent propose une mauvaise action : c'est qu'un humain fatigué finisse par valider sans lire, parce que les confirmations répétées deviennent un bruit de fond qu'on écarte par réflexe. Ce phénomène a un nom générique en ergonomie de la sécurité : la lassitude d'alerte. Plus les confirmations sont fréquentes et peu informatives, plus la probabilité de validation automatique — sans lecture réelle — augmente.

Les erreurs de configuration les plus fréquentes suivent ce schéma :

• Passer en acceptation automatique généralisée « pour aller plus vite », sur un dépôt de production, sans limiter le périmètre des commandes shell autorisées.
• Copier une configuration de permissions d'un projet expérimental vers un projet sensible, sans revoir ce qu'elle autorise réellement.
• Laisser un mode print en production avec des droits d'écriture larges, en supposant à tort que l'absence d'interface signifie l'absence de risque.
• Connecter un serveur MCP par commodité, sans vérifier la nature exacte des actions qu'il expose une fois branché.

Accorder une acceptation automatique à toutes les actions revient à retirer le dernier point de contrôle humain avant exécution. Cette posture ne doit s'envisager que dans un environnement jetable ou isolé — un conteneur sans accès aux identifiants réels, un dépôt de test sans conséquence en cas d'erreur. Sur tout ce qui touche à un système de production, à des données réelles, ou à des secrets d'accès, le principe reste : accorder le minimum nécessaire, réviser régulièrement ce qui a été accordé, et ne jamais élargir un périmètre de permissions par lassitude plutôt que par décision.

Un dernier point mérite d'être répété séparément : Claude Code ne doit jamais se voir confier directement des secrets en clair (clés d'API, jetons, mots de passe) dans une invite ou un fichier lu en clair par l'agent si ce n'est pas strictement nécessaire à la tâche. Les secrets doivent rester dans des mécanismes prévus pour cela — variables d'environnement chargées par l'application, gestionnaires de secrets, fichiers exclus du contrôle de version — et non dans le texte que l'agent lit ou écrit.

Checklist avant de démarrer un projet

Avant de lancer une session sur un nouveau dépôt, quelques vérifications rapides évitent la plupart des incidents évitables :

1. Le dépôt est-il sous contrôle de version, avec un état propre avant de commencer ? Un historique git est le meilleur filet de sécurité contre une modification malvenue.
2. Le périmètre de permissions correspond-il à la sensibilité réelle du projet — pas à la sensibilité du dernier projet sur lequel vous avez travaillé ?
3. Les secrets et identifiants sont-ils hors de portée directe de l'agent (variables d'environnement, fichiers ignorés) ?
4. Un fichier CLAUDE.md documente-t-il les commandes de test et les conventions, pour réduire les allers-retours et les propositions hors sujet ?
5. Le mode choisi (interactif ou print) correspond-il à la présence réelle d'une supervision humaine au moment de l'exécution ?

Ces cinq points ne suffisent pas à éliminer tout risque — aucune checklist ne le fait — mais ils couvrent la majorité des incidents qui surviennent, dans la pratique, non pas à cause d'une défaillance du modèle, mais à cause d'une configuration de permissions mal calibrée pour le contexte réel du projet.