+150 XP

Sécurité, permissions et gouvernance des connecteurs

Dès que vous connectez Google Drive à Claude, vous remettez à un modèle de langage une clé donnant accès à de vrais documents, de vrais noms de clients et de vrais chiffres de revenus. C'est tout l'intérêt de la chose, et c'est exactement pour cela que cette leçon existe. Les connecteurs font passer Claude d'un moteur de texte astucieux à un outil qui va puiser dans vos systèmes réels, donc la question n'est plus « est-ce que ça peut aider » mais « qu'est-ce que je viens d'autoriser, et qui voit ce qui se passe ensuite ».

Ce qu'un connecteur accorde réellement

Un connecteur est un pont entre Claude et un service externe (Gmail, Google Drive, Notion, GitHub, Slack, et une marketplace qui s'étoffe). Sous le capot, la plupart des connecteurs parlent le Model Context Protocol (MCP), le standard ouvert qu'Anthropic a introduit pour permettre aux applications d'IA d'appeler des outils et de lire des ressources depuis des systèmes extérieurs. Vous connaissez déjà MCP au niveau conceptuel ; ici, ce qui nous intéresse, c'est ce qu'il autorise.

Quand vous ajoutez un connecteur, vous complétez un flux OAuth. OAuth, c'est le schéma « Se connecter avec Google » que vous avez vu partout : vous vous authentifiez sur la page du fournisseur, et le fournisseur remet à Claude un token restreint au lieu de votre mot de passe. Le mot clé est scope. Un scope est une permission nommée et précise, du type « lire vos fichiers » ou « envoyer des e-mails en votre nom ».

Deux connecteurs nommés « Google Drive » peuvent demander des scopes très différents. L'un peut ne demander que `drive.readonly`. L'autre peut demander un accès complet en lecture-écriture. Lisez l'écran de consentement. Ce n'est pas du blabla juridique ; c'est la liste réelle de ce que Claude peut désormais faire avec votre compte.

json
{
  "connector": "google-drive",
  "scopes": [
    "https://www.googleapis.com/auth/drive.readonly",
    "https://www.googleapis.com/auth/drive.metadata.readonly"
  ],
  "access": "read-only",
  "can_write": false
}

Si l'écran de consentement demande l'écriture ou la suppression alors que vous voulez seulement que Claude résume des documents, il y a là un décalage qui mérite qu'on s'arrête. Accordez le scope le plus étroit qui fait le travail.

Lire, chercher et agir sont trois niveaux de risque distincts

Les permissions des connecteurs se ramènent à trois comportements, et ils ne sont pas dangereux à égalité.

Lire permet à Claude de faire entrer du contenu dans la fenêtre de contexte. Le risque ici est l'exposition : des données sensibles arrivent dans un prompt, et de là dans la réponse de Claude, dans un Artifact, ou dans un Project partagé avec des collègues.

Chercher permet à Claude d'interroger vos données pour trouver les éléments pertinents. Risque légèrement supérieur, parce que c'est Claude qui décide de ce qui est pertinent et qui peut faire remonter des documents que vous aviez oubliés.

Agir permet à Claude de modifier le monde extérieur : envoyer un message Slack, créer une issue GitHub, modifier un événement de calendrier, envoyer un e-mail. C'est la catégorie qui mérite une vraie prudence, parce qu'un détail halluciné ou une instruction mal comprise a maintenant des conséquences en dehors de la conversation.

Une habitude utile : quand un connecteur peut agir, partez du principe que Claude finira par faire la mauvaise chose au moins une fois, et demandez-vous si cette erreur unique est réparable. Envoyer un brouillon d'e-mail à la mauvaise personne, ça se répare. Supprimer en masse un dossier Drive, non.

Compte personnel contre compte professionnel

C'est la distinction que la plupart des gens ratent, et elle n'a rien à voir avec l'adresse e-mail que vous avez saisie.

Quand vous connectez un compte personnel, le connecteur s'autorise généralement sur *vos* permissions individuelles. Le rayon d'impact correspond à ce que vous pouvez voir personnellement. C'est souvent très bien pour votre Gmail ou votre Notion.

Quand vous connectez un compte professionnel, deux choses changent. D'abord, l'admin de votre organisation peut décider si les connecteurs sont autorisés, lesquels, et pour qui. Sur les plans Claude Team et Enterprise, les admins gèrent la disponibilité des connecteurs et peuvent restreindre la marketplace. Ensuite, le connecteur hérite de *vos permissions professionnelles*, qui peuvent être bien plus larges que vous ne l'imaginez : drives partagés, wikis internes, dossiers clients. Claude a désormais une fenêtre sur tout cela via votre token.

Le piège consiste à connecter une source de données professionnelle dans un compte Claude personnel, ou à faire entrer des données professionnelles dans un Project que vous partagerez ensuite en externe. Des données encadrées par les contrôles d'accès de votre entreprise sont maintenant encadrées par votre hygiène de conversation. Gardez les connecteurs professionnels dans l'organisation Claude gérée par l'entreprise, là où la politique admin et les logs s'appliquent.

Si vous administrez un workspace, la documentation des connecteurs Claude et les paramètres admin sont l'endroit où vous posez ces garde-fous. Passez-les en revue avant de déployer des connecteurs à une équipe.

Ce qui est loggué, et ce qui ne l'est pas

La gouvernance est impossible sans piste d'audit, donc sachez ce qui est enregistré.

Sur les plans gérés, Anthropic fournit une visibilité admin sur l'usage et l'activité des connecteurs, et les plans Enterprise ajoutent des logs d'audit et des contrôles plus détaillés. Ce qui est généralement capturé : quels connecteurs sont activés, qui les a connectés, et l'activité des connecteurs au niveau du compte. C'est votre couche de responsabilité quand quelqu'un demande « qui a donné à Claude l'accès au drive finance ».

Ce qui ne remplace *pas* les logs du système source : quand Claude lit un Google Doc via un connecteur, cet accès peut aussi apparaître dans les logs d'audit de Google comme une activité de *votre* compte, parce que le token OAuth agit en votre nom. Une action de connecteur peut donc apparaître à deux endroits : la vue de votre organisation Claude et la vue du fournisseur en amont. Les équipes sécurité doivent cartographier les deux.

À part cela, n'oubliez pas le volet modèle. Par défaut, les conditions commerciales et API d'Anthropic stipulent que vos données d'entreprise ne servent pas à entraîner les modèles. Le fait qu'un connecteur fasse entrer des données ne change pas ce réglage par défaut, mais cela signifie que du contenu sensible vit maintenant dans l'historique des conversations et peut-être dans des Projects partagés. La rétention de *cela* est régie par les paramètres de données de votre plan, pas par le connecteur.

Understanding OAuth Scopes in 5 Minutes

Watch on YouTube

La marketplace et les connecteurs personnalisés

La marketplace de connecteurs abaisse la barrière à l'ajout d'outils, ce qui est excellent et pose aussi une question de supply chain. Un serveur MCP distant tiers que vous connectez, c'est du code qui tourne sur l'infrastructure de quelqu'un d'autre, qui reçoit les données que vous lui envoyez et qui renvoie ce qu'il veut. Traitez un nouveau connecteur comme l'installation d'une extension de navigateur : privilégiez les éditeurs officiels et vérifiés, regardez qui opère le serveur, et évitez de coller des identifiants dans des connecteurs que vous ne pouvez pas auditer.

Si votre équipe construit un connecteur personnalisé (un serveur MCP interne), c'est souvent la voie *la plus sûre* pour les systèmes sensibles, parce que vous contrôlez les scopes, l'hébergement et les logs. La spécification et les SDK sont sur modelcontextprotocol.io, et les serveurs de référence d'Anthropic sont ouverts sur github.com/anthropics. Construire le vôtre vous permet d'exposer uniquement les trois outils dont un workflow a besoin au lieu de toute une surface d'API.

Vérification des acquis

1. Dans le contexte des connecteurs, que représente réellement un « scope » ?

2. Pourquoi la leçon insiste-t-elle sur le flux OAuth lors de l'ajout d'un connecteur ?

3. Vous voulez seulement que Claude résume des documents dans Google Drive, mais l'écran de consentement demande un accès complet en lecture-écriture et suppression. Quelle est la meilleure action ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les affirmations correctes sur les connecteurs et le Model Context Protocol (MCP).

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les affirmations correctes sur la différence entre les comportements Lire et Chercher d'un connecteur.

Sélectionnez toutes les réponses correctes.

Une règle simple pour décider quoi connecter

Oubliez le long document de politique interne. Posez une seule question avant chaque connecteur :

« Si un inconnu disposait exactement de cet accès pendant une heure, quel est le pire qu'il pourrait faire, et pourrais-je l'annuler ? »

Cette seule phrase vous force à penser au scope (quel accès), au rayon d'impact (combien de données) et à la réversibilité (agir contre lire) en même temps. Appliquez-la ainsi :

  • Connectez librement : accès en lecture seule à des données qui vous appartiennent, faible sensibilité, là où un résumé ou une recherche par Claude fait gagner du temps réel. Vos notes Notion personnelles. Un dépôt GitHub public. Un Drive en lecture seule sur un dossier de brouillons.
  • Connectez avec intention : les sources de données professionnelles, mais uniquement dans une organisation Claude gérée par un admin, avec le scope le plus étroit, et jamais dans un Project que vous pourriez partager en externe. Le wiki interne de votre équipe, en lecture seule.
  • Ne connectez pas (ou verrouillez fort) : l'accès en écriture ou en suppression aux systèmes de référence, tout ce qui touche à des PII clients ou à des données réglementées, les systèmes financiers et l'infrastructure de production, sauf si votre organisation l'a explicitement approuvé et qu'un humain confirme chaque action. Un accès en écriture à une base de données de production via un connecteur ne vaut presque jamais le confort qu'il apporte.

L'asymétrie compte. Lire le mauvais document est un problème de confidentialité que vous pouvez contenir. Laisser Claude *agir* sur un système de référence est un problème opérationnel que vous ne pourrez peut-être pas inverser.

Garder un humain dans la boucle pour les actions

Quand vous activez des connecteurs capables d'agir, concevez le workflow de sorte que Claude propose et qu'un humain décide. En pratique, cela veut dire demander à Claude de rédiger le message Slack ou l'issue GitHub et de vous le montrer avant envoi, plutôt que de câbler une exécution totalement autonome. Pour de véritables agents autonomes bâtis sur le Claude Agent SDK, vous contrôlez cela au niveau du code avec les réglages de permissions d'outils et des étapes de confirmation, sujet plus profond que les connecteurs sur Claude.ai mais qui suit le même principe : les outils dangereux exigent une approbation explicite.

Un modèle mental rapide pour tout connecteur que vous ajoutez :

yaml
connector: github
scope: repo-readonly        # le plus étroit qui fonctionne
account: work-managed-org   # pas personnel
shared_in_projects: false   # éviter les fuites externes
can_act: false              # lecture seule ; pas d'écriture d'issue/PR
review: human-confirms-actions

Si vous ne pouvez pas remplir ces lignes avec assurance, vous n'êtes pas encore prêt à connecter cette source.

Révoquer un accès proprement

Les permissions que vous accordez sont des permissions que vous devez pouvoir révoquer. Déconnecter un connecteur dans Claude le retire de votre application, mais la révocation la plus propre se fait aussi chez le fournisseur. Allez dans les paramètres de sécurité du service source (par exemple, « Applications tierces ayant accès à votre compte » dans votre compte Google) et révoquez-y aussi le token. Cela garantit que l'autorisation OAuth est bien morte, même si quelque chose est en cache. Faites de la revue périodique des connecteurs une habitude : chaque trimestre, regardez ce qui est connecté et retirez ce que vous n'utilisez plus. L'accès dormant est le risque silencieux le plus courant.

Points clés

  • Les scopes sont la véritable frontière. Lisez l'écran de consentement OAuth et accordez la permission la plus étroite qui fait le travail. Privilégiez la lecture seule, sauf si un workflow a vraiment besoin d'agir.
  • Compte personnel et compte professionnel ne sont pas interchangeables. Gardez les sources de données professionnelles dans une organisation Claude gérée par un admin, là où la politique et les logs s'appliquent, et ne faites jamais entrer des données encadrées dans un Project que vous pourriez partager en externe.
  • Agir est la catégorie dangereuse. Pour tout connecteur capable d'envoyer, d'écrire ou de supprimer, gardez un humain qui confirme chaque action et demandez-vous si une erreur unique est réversible.
  • Utilisez le test en une phrase : « Si un inconnu disposait de cet accès pendant une heure, quel est le pire qu'il pourrait faire, et pourrais-je l'annuler ? » Laissez la réponse décider.
  • Révoquez à la source et faites une revue trimestrielle. Déconnecter dans Claude ne suffit pas ; tuez le token dans les paramètres de sécurité du fournisseur et élaguez les connecteurs que vous n'utilisez plus.

À faire, tiré de cette leçon

Ces actions sont compilées dans le plan d'action du rôle.

  • Accordez aux connecteurs des scopes en lecture seule et révoquez les tokens chez le fournisseur chaque trimestre
  • Appliquez le test de l'inconnu avec une heure d'accès avant de connecter une source de données
Voir le plan d'action complet →

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.