Faut-il copier les données du CRM dans la base de connaissances de l'assistant ?

Rarement. Les documents stables (conditions, procédures) vont dans la base de connaissances ; les données qui changent (statut d'un ticket, d'une commande) se lisent en direct dans le CRM, avec les droits adaptés.

Les limites d'appels du CRM peuvent-elles bloquer un assistant ?

Oui, en période de pointe. Chez HubSpot, une application privée sur un compte Free ou Starter est limitée à 100 requêtes par 10 secondes : à vérifier dès le cadrage.

Intégrer un chatbot IA à un CRM : la méthode intégrateur

Un chatbot IA s'intègre à un CRM (logiciel de gestion de la relation client) par deux voies qui se complètent. Il répond à partir de documents rangés dans sa base de connaissances. Et il interroge le CRM en direct pour les données qui changent. Le travail de l'intégrateur consiste à décider, objet par objet, ce que l'assistant lit, ce qu'il a le droit d'écrire, à quelle fréquence, et ce qui se passe quand un appel échoue.

Deux sortes d'informations, deux voies

La première erreur est de tout mettre au même endroit. Un assistant qui répond sur des conditions générales n'a pas besoin du CRM. Un assistant qui donne le statut d'un dossier ne peut pas se contenter d'un document copié la veille.

Information demandée	Où elle vit	Voie conseillée
Conditions de vente, procédures, fiches produit	Documents, site web	Base de connaissances de l'assistant
Statut d'un ticket, étape d'une transaction	CRM, change souvent	Lecture en direct (API ou MCP)
Coordonnées d'un contact	CRM, données personnelles	Lecture en direct, droits restreints
Création d'un prospect après une conversation	CRM	Écriture contrôlée, champs limités
Historique des échanges avec un client	CRM, activités	À n'ouvrir que si le besoin est démontré

La lecture en direct passe par une API (interface de programmation, la porte d'entrée officielle du logiciel) ou par un serveur MCP (un protocole standard qui expose des outils à un assistant). La différence est expliquée dans MCP ou API.

La grille objet par objet

Dans un projet d'intégration classique, on tranche pour chaque objet : le système maître, le sens du flux, la fréquence et la conduite à tenir en cas d'erreur. Un article de cabinet consacré au cadrage ERP-CRM (kolonell.com, 02/09/2026) le résume ainsi : « Un projet d'intégration ERP-CRM ne se rate pas à la technique, il se rate au cadrage ». La même grille s'applique à un assistant, avec une colonne de plus : ce que l'assistant a le droit de faire.

Objet	L'assistant lit ?	L'assistant écrit ?	Fréquence	En cas d'erreur
Contacts	Oui, champs utiles seulement	Création de prospect, sans écraser l'existant	À chaque question	Réponse prudente, transfert à un humain
Entreprises	Oui	Non	À chaque question	Réponse sans la donnée
Transactions	Étape et montant si le profil le permet	Non	À chaque question	Message d'indisponibilité
Tickets	Statut et dernier échange	Création d'un ticket	À chaque question	Ticket mis en file, alerte
Notes et activités	À discuter	Ajout d'une note de synthèse	Fin de conversation	Journal des rejets

Remplissez ce tableau avec votre client avant de chiffrer. Chaque « oui » en écriture ajoute des tests, des droits et de la maintenance.

Exemple : ce que permet HubSpot en 2026

HubSpot a rendu son serveur MCP distant disponible pour tous les comptes le 13/04/2026. D'après son journal des changements :

l'assistant peut lire, créer et mettre à jour des contacts, entreprises, transactions, tickets, produits et activités (appels, réunions, notes, tâches, e-mails) ;
il respecte les permissions HubSpot existantes : il ne voit et ne modifie que ce que l'utilisateur connecté peut voir et modifier ;
la connexion se fait par OAuth 2.1 (protocole d'autorisation), obligatoire ;
si les données sensibles sont activées sur le compte, les objets d'activité sont bloqués pour le serveur MCP.

Ce dernier point compte : un assistant qui marchait en démonstration peut perdre l'accès aux notes chez un client qui a activé les données sensibles. À vérifier en atelier. Les autres outils sont recensés dans Serveurs MCP des outils métier.

Les limites d'appels, à chiffrer dès le départ

Un assistant appelle le CRM plusieurs fois par question. Les limites de l'éditeur deviennent alors une contrainte de conception. Chez HubSpot (page des règles d'utilisation, lue le 15/11/2026) :

Type d'application et de compte	Par 10 secondes	Par jour
Application privée, Free et Starter	100	250 000
Application privée, Professional	190	625 000
Application privée, Enterprise	190	1 000 000
Application publique OAuth	110 par compte installé	—

Pour les applications privées, la limite journalière est partagée entre toutes les applications du même compte. Votre synchronisation existante et l'assistant puisent donc dans le même réservoir.

Exemple de calcul, en hypothèse. Prenons un assistant qui fait 3 appels au CRM par question, sur un compte Starter. En pointe, 100 appels par 10 secondes laissent passer environ 33 questions dans cette fenêtre, moins ce que consomment vos autres flux. Sur une journée, 2 000 questions font 6 000 appels, loin des 250 000. Le risque n'est pas le volume du jour, c'est le pic.

Points à vérifier avant de chiffrer

La liste des objets et des champs que l'assistant lit, validée par le client.
Les écritures autorisées, champ par champ, et ce qu'il ne doit jamais modifier.
Le compte sous lequel l'assistant agit, et ses droits (voir Droits d'accès).
Les limites d'appels du compte et ce que consomment déjà les flux existants.
Le comportement attendu quand le CRM ne répond pas.
Les champs personnalisés et les doublons, qui faussent les réponses.

Ces points forment le cœur du cadrage, détaillé dans Cadrer le projet.