Distinguez l’accès d’un processus métier
Un connecteur qui récupère des enregistrements peut être utile pour une requête simple. Une tâche plus élaborée peut aussi nécessiter des définitions, des exclusions et une méthode reproductible : quelles requêtes sont en retard, comment gérer les dates manquantes et ce que l’analyste doit vérifier avant de diffuser une conclusion.
Ces procédures peuvent être représentées dans un agent configuré plutôt que ressaisies à chaque conversation. Elles restent des instructions à tester ; elles ne deviennent pas des contrôles de sécurité parce qu’elles sont derrière un point d’entrée MCP.
- Question dans Claude
- Agent REDA sélectionné
- Opérations Salesforce autorisées
- Réponse renvoyée à l’hébergeur
Le positionnement de la connexion REDA
REDA AI permet à un administrateur de rendre certains agents Internal accessibles via MCP. Les utilisateurs se connectent avec leur identité Salesforce, et l’agent conserve son contexte métier et ses outils configurés. L’hébergeur reçoit la réponse métier obtenue et le contenu structuré pertinent, et pas seulement un catalogue de noms d’outils. Découvrez l’expérience MCP.
MCP est un protocole reliant une application à des capacités. Sa spécification d’autorisation traite l’accès aux services protégés ; elle ne détermine pas si votre réponse métier est correcte ni si un processus particulier doit être automatisé. [1]
Exemple concret : préparer une revue de service
Processus illustratif, et non déploiement mesuré. Un analyste demande une synthèse hebdomadaire des requêtes non résolues. L’agent sélectionné utilise la définition convenue de « non résolue », récupère les informations autorisées et renvoie des thèmes étayés par les enregistrements. L’analyste vérifie les totaux et prépare les supports finaux de discussion dans l’application hôte.
Si la demande s’étend à la modification des propriétaires de requêtes ou à l’envoi de messages, le périmètre d’action change. Commencez par décider si ces capacités doivent être incluses dans l’agent, puis établissez les autorisations et le comportement de vérification applicables.
Évaluez les deux côtés de la connexion
| Limite | Question à résoudre |
|---|---|
| Identité et accès | Quelle identité Salesforce est utilisée et à quoi cet utilisateur peut-il accéder ? |
| Informations quittant Salesforce | Quelles réponses, quels enregistrements ou détails d’action parviennent à l’hébergeur et à ses fournisseurs ? |
| Exécution des actions | Quelles opérations sont autorisées et lesquelles exigent une approbation effectivement contrôlée ? |
| Éléments probants | Où peut-on examiner la conversation et les modifications d’enregistrements qui en résultent ? |
Ne supposez pas que REDA contrôle les autres connecteurs disponibles dans Claude ni qu’une confirmation dans l’application hôte impose aussi une approbation dans Salesforce. Une tâche planifiée peut également utiliser une identité d’exécution différente de celle d’une demande immédiate. La page de gouvernance et la documentation de configuration décrivent les réserves pertinentes.
Commencez par une tâche principalement en lecture
Une demande analytique précisément délimitée facilite l’examen de son utilité et de ses limites. Testez avec un utilisateur disposant d’accès représentatifs, un enregistrement inaccessible, des données incomplètes et une question hors du périmètre de l’agent. Examinez ensuite le résultat réel, pas seulement l’explication conversationnelle.
REDA peut vous aider à configurer la procédure métier et à évaluer la connexion. Un rapport, un export ou un connecteur plus simple peut toutefois suffire ; choisissez l’approche par agent lorsque la procédure réutilisable justifie sa place.
Sources
- Model Context Protocol — Authorization specification · Spécification du 25 novembre 2025. Consultée le 22 septembre 2026.