Le piège du POC collé à une API
La plupart des agents CRM naissent avec des appels HubSpot ou Salesforce en dur dans le prompt ou dans les tools. Le jour où le client change de CRM, où l’on veut tester sans toucher la prod, ou simplement écrire un test, tout casse. Le lab pose d’abord un contrat : Account, Ticket, Note, cinq méthodes, des erreurs typées.
Derrière ce contrat, trois adaptateurs : le sandbox JSON historique, HubSpot (companies, tickets, notes, associations) et Salesforce (Account, Case, Task via SOQL). Les vocabulaires sont normalisés : URGENT ou Critical deviennent « critique », un ticket en étape 4 ou un Case Closed deviennent « resolu ».
Mock d’abord — aux formats réels
Les fixtures du lab ne sont pas des JSON inventés : ce sont des réponses au format exact de l’API HubSpot v3 (properties, associations, createdAt) et de l’API REST Salesforce (attributes, records, done). Le mapping testé en mock est donc celui qui tournera en live. Le passage au réel est une variable d’environnement et un token de portail de test.
- HubSpot : Private App, scopes companies.read / tickets.read (+ notes.write), script de seed pour peupler un portail de test
- Salesforce : Developer Edition, OAuth client credentials, échappement SOQL systématique
- Écritures : dry-run tant que CRM_ALLOW_WRITE=1 et une approbation humaine ne sont pas réunis
Et MCP dans tout ça ?
Le serveur MCP `crm-saas` expose ce contrat en tools : quel que soit le CRM branché, un client MCP (Claude Desktop, Cursor, Claude Code) voit les mêmes six tools et la même resource décrivant le provider actif et la politique d’écriture. Le CRM devient un détail d’infrastructure — ce qui est exactement le rôle d’un standard.
Changer de CRM = changer une variable d’environnement, pas le code métier ni les prompts.