Connecter Claude ou ChatGPT/Codex à Salesforce : du fichier Markdown au dashboard

Vous souhaitez demander à un assistant d’analyser vos données Salesforce, puis de préparer un tableau de bord lisible. Le premier fichier Markdown peut être très court. La connexion, elle, demande plusieurs éléments : un outil capable d’exécuter le travail, une authentification Salesforce, les permissions adaptées et des règles pour vérifier les données restituées.

La méthode présentée ici associe un fichier d’instructions à un accès API authentifié. Elle permet d’étudier un parcours de lecture : identifier l’organisation, collecter un périmètre autorisé, rapprocher les résultats et produire un dashboard HTML ou un fichier CSV daté. Elle s’adresse aux responsables CRM et aux administrateurs qui veulent comprendre ce qu’il faut réellement mettre en place.

Les exemples sont fictifs. Les paramètres d’une organisation cliente et ses identifiants ne sont pas réutilisables d’un projet à l’autre.

Réunir les trois éléments de la connexion

Le fichier Markdown décrit le travail : objectif, objets, champs, filtres, définitions des indicateurs et format de restitution. Il permet à l’équipe de relire et de maintenir les consignes.

L’environnement d’exécution fournit les capacités effectives : lire les fichiers autorisés, exécuter le client prévu, accéder aux destinations réseau nécessaires et ouvrir le parcours d’authentification. Un fichier simplement joint à ChatGPT web ne crée pas cet environnement ni une connexion Salesforce. Il faut vérifier les outils réellement disponibles dans la surface utilisée.

L’accès Salesforce repose sur l’application autorisée, l’utilisateur, les permissions et les politiques de l’organisation. La connexion n’étend pas automatiquement les droits de cet utilisateur.

Codex, Claude Code ou une autre surface adaptée peuvent porter le travail selon la configuration retenue. Le guide des usages de ChatGPT, Claude et Codex avec Salesforce aide à choisir le point de départ. La procédure ci-dessous doit être vérifiée sur l’outil et le compte utilisés ; elle ne suppose pas une compatibilité universelle.

Choisir l’environnement avant de créer l’application

Vérifiez où le client d’accès s’exécutera et où ses fichiers seront conservés. La capacité à exécuter du code n’implique pas forcément la possibilité d’atteindre Salesforce, de conserver une session ou d’utiliser le même navigateur que l’utilisateur.

Le mode d’exécution doit également être explicite. La documentation actuelle de Cowork décrit des sessions dans le cloud et des configurations locales existantes. Elle précise aussi les règles d’accès aux fichiers et au réseau. L’utilisation d’une application de bureau ne permet donc pas de conclure que le traitement reste intégralement sur le poste. (Architecture de Claude Cowork.)

Pour Codex, les accès aux fichiers, au réseau et les approbations dépendent de la configuration. Le périmètre du projet doit correspondre à ces contrôles effectifs. (Documentation OpenAI sur les approbations et la sécurité.)

À ce stade, on doit pouvoir décrire le chemin complet : l’utilisateur autorise l’accès, le client récupère les données permises, l’outil les traite dans l’environnement choisi et le résultat est remis aux destinataires prévus. Les données transmises au modèle font partie de cette description.

Configurer une External Client App et le flux OAuth approprié

La variante décrite utilise OAuth Authorization Code avec PKCE S256. L’utilisateur s’authentifie dans Salesforce ; le client reçoit un code, puis l’échange selon le flux configuré. PKCE associe cet échange à un vérificateur créé pour la demande. Salesforce documente le challenge fondé sur SHA-256 et sa vérification lors de l’échange du code. (Flux OAuth Web Server Salesforce.)

Le choix entre client public et client confidentiel compte. Un client public ne peut pas protéger durablement un secret d’application. Pour ce cas, Salesforce indique de désactiver l’exigence de secret pour les flux Web Server et Refresh Token et recommande PKCE. Un client confidentiel disposant d’un serveur capable de protéger le secret conserve une configuration différente. Ces réglages ne doivent pas être copiés indistinctement. (Paramètres OAuth d’une External Client App.)

Le point d’entrée documentaire de cette variante est le flux Web Server pour External Client App. Il ne s’agit pas d’un parcours Headless Identity où le client recueille les identifiants de l’utilisateur.

La préparation comprend notamment :

• l’organisation visée et les utilisateurs autorisés ;
• le type de client et le flux réellement implémenté ;
• l’URL de retour exacte prise en charge par ce client ;
• les scopes nécessaires et la politique de durée de session ;
• l’emplacement protégé des éléments d’authentification et leur révocation.

L’URL de retour doit correspondre au mécanisme choisi. Un callback proposé par un connecteur MCP ne devient pas, par simple copie, le callback d’un client REST distinct. Aucun serveur MCP n’est requis pour la variante REST décrite ici ; un autre projet peut retenir ce protocole pour exposer ses outils.

Établir une lecture seule réelle

Les scopes api et refresh_token ne constituent pas une garantie de lecture seule. Les permissions Salesforce de l’utilisateur doivent être adaptées aux objets, aux champs et aux enregistrements concernés. Il faut ensuite limiter les opérations que le client expose au travail demandé.

Pour un premier dashboard, nous recommandons une liste explicite de lectures métier : descriptions d’objets nécessaires et requêtes de consultation bornées. Le client ne propose pas de création, modification ou suppression de données métier. Les échanges OAuth peuvent utiliser POST pour obtenir ou renouveler une session : ils doivent être distingués des opérations sur les données du CRM.

Une connexion réussie n’est que le début de la vérification. Lisez un élément connu, comparez-le dans Salesforce, puis essayez un périmètre qui doit être refusé. Un test de refus permet de constater une limite réelle plutôt que de la déduire du seul nom d’un réglage.

Écrire le fichier Markdown autour du métier

Le fichier utile décrit les règles du tableau de bord. Il doit rester compréhensible par la personne qui le demande, même lorsque certaines annexes sont techniques.

Exemple de consigne pour une PME fictive :

Prépare une photographie des opportunités ouvertes du périmètre autorisé. Utilise uniquement les champs convenus et les montants renseignés. Distingue les étapes commerciales ; ne transforme pas ces montants en chiffre d’affaires acquis. Affiche la date de collecte, la devise et les filtres. Signale les montants absents et les lignes exclues. Produis une vue HTML et un export CSV permettant de rapprocher les totaux. Aucune écriture Salesforce ni aucun envoi n’est demandé.

Ajoutez un dictionnaire des indicateurs. « Opportunité ouverte » doit correspondre à une condition précise. Un montant absent ne devient pas zéro par défaut. Si plusieurs devises sont présentes, la règle de conversion doit être fournie ou les montants doivent rester séparés.

Le fichier peut également préciser les contrôles de qualité, la taille maximale d’un lot, les limites de consommation et les cas où le traitement doit s’arrêter pour demander une décision. Il référence les moyens de connexion approuvés sans intégrer de jetons ni de secrets.

Collecter, rapprocher puis construire le dashboard

La collecte doit gérer les résultats complets du périmètre, y compris leur éventuelle pagination. Conservez le nombre de lignes et les filtres appliqués. Si une limite empêche de terminer, le rapport doit annoncer une collecte partielle et éviter de présenter ses totaux comme complets.

Avant de dessiner les graphiques, rapprochez les indicateurs. Dans notre exemple fictif, trois opportunités portent des montants de 12 000 €, 18 000 € et 8 000 €. Le total brut est de 38 000 €. Deux sont à l’étape Proposition pour 30 000 €, la troisième à l’étape Qualification pour 8 000 €. Ce tableau décrit un pipeline d’exemple, sans prévision de revenu acquis.

Le lecteur doit pouvoir retrouver ces trois lignes depuis les agrégats. Une carte graphique seule ne permet pas de vérifier qu’un filtre a exclu une opportunité ou qu’un montant a été compté deux fois. La vue détaillée doit rester limitée aux données que le destinataire est autorisé à consulter.

Pour un CFA, les indicateurs pourraient porter sur les dossiers par rentrée et les pièces à contrôler. Pour une association, ils pourraient rapprocher promesses de dons, règlements et affectations, en conservant leurs différences. Les définitions précèdent les graphiques.

Distinguer une photographie exportée et un tableau connecté

Un dashboard HTML produit à partir d’une collecte est une photographie datée. Il peut être interactif dans son affichage, avec des filtres ou des graphiques, tout en conservant des données figées. Un fichier CSV correspond lui aussi au périmètre et à la date de son extraction.

Un tableau connecté demande un mécanisme supplémentaire : accès disponible au moment de l’usage, actualisation, gestion des sessions expirées, droits du lecteur et indication de la dernière mise à jour réussie. Un échec d’actualisation doit être visible.

La documentation de Claude décrit désormais des artifacts connectés et un modèle Dashboards en bêta, avec des conditions d’abonnement et d’administration. Elle précise que chaque utilisateur connecte ses propres applications. Un export HTML ne récupère pas automatiquement cette connexion. (Artifacts et applications connectées dans Claude.)

Pour une première livraison, un export daté peut répondre à un besoin de réunion. Si le besoin est une consultation quotidienne partagée, il faut chiffrer et concevoir l’exploitation correspondante. Un environnement d’agents sur Mac mini peut être étudié selon le contexte, sans présumer que tous les traitements seront locaux.

Prévoir la continuité et la remise à l’équipe

Le dossier remis doit permettre de retrouver les instructions, les définitions d’indicateurs, la configuration non secrète, les accès à demander et la procédure de renouvellement ou de révocation. Les changements de personne ou de poste ne doivent pas laisser l’équipe dépendante d’une session impossible à identifier.

La recette couvre aussi une session expirée, une permission retirée, un champ indisponible et une collecte interrompue. Elle vérifie que le résultat reste clairement daté et que les éléments d’accès n’apparaissent pas dans l’HTML ou le CSV.

Pour un besoin plus large, un audit Salesforce avec un périmètre défini peut aider à identifier les sources et les difficultés à traiter. Le coût du parcours dépend ensuite des accès, du volume, de la fréquence, de la restitution et du niveau de suivi attendu.

Mettre en place votre premier dashboard assisté

Cloud Girafe propose de définir le besoin, configurer l’accès Salesforce de l’outil retenu et formaliser les instructions Markdown avec les contrôles associés. Le livrable peut commencer par une photographie vérifiée, puis évoluer vers une consultation connectée si cela répond à un usage identifié.

Préparez les indicateurs souhaités, leurs utilisateurs et un exemple de restitution. Décrivez-nous votre projet de connexion Salesforce et IA.