🔐 Chapitre 3

Gérer les permissions MCP dans Claude Code

Claude vous redemande la permission à chaque appel d'un outil Spendesk MCP ? Comprenez les modes de permission, la différence entre réglages personnels et organisation, et comment vous débloquer une fois pour toutes.

CFOControllerAP ManagerFinance AnalystProcurement6 min de lecture

Le problème : une fenêtre de permission à chaque appel

Vous venez d'installer un skill (voir le chapitre précédent), vous posez votre première vraie question, et Claude vous demande confirmation avant chaque appel d'outil MCP — spendesk_analyze_spend, puis get_payables, puis encore un autre. Si votre requête en mobilise plusieurs, vous cliquez "Autoriser" en boucle.

Ce n'est pas un bug : c'est le comportement par défaut de Claude Code, et il est réglable. Ce chapitre explique comment, et où se situe la frontière entre "c'est vous qui décidez" et "c'est votre organisation qui décide".

Les modes de permission de Claude Code

Mode	Comportement général	Effet sur les outils MCP
`default`	Demande confirmation au premier appel de chaque outil ; les appels suivants au même outil passent sans redemander, mais uniquement pour la session en cours	Chaque outil MCP redéclenche une fenêtre à son premier usage dans une nouvelle session
`acceptEdits`	Auto-approuve les modifications de fichiers et commandes courantes dans le répertoire de travail	Les appels d'outils MCP continuent à demander confirmation
`plan`	Lecture seule : auto-approuve les lectures, bloque toute modification	Les outils MCP en lecture pure peuvent s'exécuter sans confirmation ; ceux capables d'écrire redemandent
`auto`	Auto-approuve avec des vérifications de sécurité en tâche de fond qui contrôlent la cohérence avec votre demande	Les outils MCP passent, sous réserve de ces vérifications automatiques
`dontAsk`	Refuse tout par défaut, sauf ce qui est explicitement pré-autorisé	Un outil MCP non pré-autorisé ne s'exécute jamais
`bypassPermissions`	Ignore toutes les fenêtres de confirmation, sauf les règles `ask` explicites	Les outils MCP s'exécutent sans aucune confirmation

Le mode se règle via defaultMode dans un fichier de configuration (voir plus bas) — pas besoin de retenir la syntaxe exacte, l'essentiel est de savoir que ce réglage existe et ce qu'il change concrètement pour les outils MCP.

Se débloquer en 10 secondes

Sur la fenêtre de permission elle-même, choisissez "Yes, don't ask again" plutôt que "Yes" tout court. Ce choix est enregistré dans .claude/settings.local.json — un fichier personnel, non partagé avec le reste de l'équipe (à la différence de .claude/settings.json, qui lui est versionné et donc commun à tous).

La règle enregistrée ressemble à ceci :

Prompt à copier

{
  "permissions": {
    "allow": [
      "mcp__<nom-du-connecteur-spendesk>__*"
    ]
  }
}

Le nom exact du connecteur dépend de la façon dont il a été configuré chez vous — remplacez <nom-du-connecteur-spendesk> par le nom réel, visible via la commande /mcp. Le * final autorise tous les outils de ce connecteur en une seule règle, plutôt que d'accepter outil par outil.

Astuce : pas besoin d'éditer ce fichier à la main pour un usage courant — cliquer "Yes, don't ask again" fait exactement ça pour vous, au bon endroit.

Niveau personnel vs niveau organisation

Plusieurs fichiers de réglages coexistent, avec un ordre de priorité strict :

Niveau	Emplacement	Qui le contrôle	Partagé ?
Managed (organisation)	Chemin système, déployé par l'IT	Votre administrateur Claude/IT	Imposé, non modifiable par vous
Ligne de commande	Option `--settings`, ponctuel	Vous, pour un lancement précis	Non
Projet (personnel)	`.claude/settings.local.json`	Vous, sur ce projet	Non (non versionné)
Projet (partagé)	`.claude/settings.json`	L'équipe, via Git	Oui (commité)
Utilisateur global	`~/.claude/settings.json`	Vous, sur tous vos projets	Non

Règle à retenir : en cas de conflit, un refus (deny) l'emporte toujours sur une autorisation (allow), quel que soit le niveau où il se trouve. Un administrateur peut aussi verrouiller la liste des serveurs MCP autorisés (allowedMcpServers) ou interdire complètement tout ajout de règle personnelle (allowManagedMcpServersOnly).

Si le MCP Spendesk n'apparaît pas dans /mcp, ou si un outil reste bloqué malgré vos propres réglages : c'est très probablement une politique organisation, pas un problème de configuration personnelle. Il n'y a pas de contournement — le bon réflexe est de contacter votre administrateur Claude, pas d'essayer de forcer le déblocage.

Claude.ai et Claude Desktop : un modèle plus simple

Sur claude.ai et Claude Desktop, l'approbation se fait généralement au niveau du connecteur entier, pas outil par outil : une fois le connecteur Spendesk MCP autorisé une fois, l'ensemble de ses outils devient disponible sans refenêtre de confirmation individuelle. Ce comportement peut varier légèrement selon votre configuration exacte (workspace, politique d'organisation) — si un doute persiste, le plus fiable reste de vérifier directement dans les réglages de connecteurs de votre propre espace de travail plutôt que de se fier uniquement à ce résumé.

Bonnes pratiques pour une équipe qui déploie le MCP Spendesk

Le MCP Spendesk est presque entièrement en lecture (un seul outil d'écriture existe, archive_supplier — voir le chapitre "partenaire de réflexion") : pour un serveur read-only, allow-lister largement une fois la confiance établie est raisonnable et évite la friction au quotidien.
Ne recommandez jamais bypassPermissions à un utilisateur non-technique — ce mode retire tous les filets de sécurité, pas seulement ceux liés au MCP.
Gardez une vigilance particulière autour de archive_supplier : c'est la seule action qui modifie réellement une donnée côté Spendesk. Une règle ask explicite sur cet outil précis (plutôt qu'un allow général) garde un point de contrôle humain là où ça compte.

Pour aller plus loin

Deux commandes évitent d'éditer du JSON à la main :

/permissions — affiche et modifie l'ensemble des règles actives, avec leur origine (managed, utilisateur, projet, session).
/mcp — affiche les serveurs MCP connectés, leur statut, et permet de gérer l'authentification.

Une fois débloqué, la friction disparaît définitivement pour ce projet — retour au chapitre suivant pour apprendre à bien formuler vos demandes.

← Chapitre précédent Chapitre suivant →