Connecter une IA à son CRM : agents, MCP et garde-fous

Un assistant relié au CRM lit les fiches au lieu de les inventer. La connexion passe par MCP, un protocole ouvert. On ouvre la lecture en premier, l'écriture plus tard et sous conditions.

Préparer un rendez-vous commercial, ça veut dire ouvrir le CRM, relire les derniers échanges, remettre la main sur le devis envoyé au printemps, vérifier ce qui a été promis au téléphone, puis écrire la note. Vingt minutes quand le dossier est propre. Le lendemain on recommence, pour le rendez-vous suivant.

Demandez la même note à un assistant qui n'a pas accès au CRM : il rend un texte impeccable et faux. Le nom de l'interlocuteur, la date du dernier échange, le montant du devis, tout est inventé, et rien dans la mise en forme ne le signale. Coller les fiches dans la conversation règle le problème pour un rendez-vous. Pas pour les douze de la semaine.

Ce que change un assistant qui lit vraiment la fiche client

La différence n'est pas une question de degré. Un assistant à qui on décrit une situation écrit à partir de ce qu'on lui a raconté. Un assistant connecté écrit à partir de ce qu'il est allé chercher, et il peut dire d'où ça sort : l'identifiant de la fiche, la date de l'échange.

Les usages qui en profitent se ressemblent tous. La préparation de rendez-vous, où l'historique, les engagements pris, les dossiers ouverts et la dernière facture tiennent en une page. La qualification d'un contact entrant, où le nom d'une société suffit à retrouver la fiche existante et à voir qu'un collègue l'a rencontrée l'an dernier, avant que quelqu'un crée un doublon. Le compte rendu d'entretien, qui se range dans la fiche pendant que les tâches se créent et que la relance se date.

Aucun de ces gestes n'est difficile ; ils reviennent chaque semaine, et c'est ce qui les rend intéressants à mettre en procédure.

MCP, la prise standard entre l'assistant et vos outils

La connexion ne se recode pas pour chaque outil. Depuis novembre 2024 elle passe par un protocole ouvert, le Model Context Protocol, publié par Anthropic puis repris par OpenAI, Google, Microsoft et AWS, et confié depuis à la Linux Foundation. C'est devenu la façon normale de brancher un assistant sur un système existant.

Un serveur MCP expose des actions nommées, du type « chercher un contact » ou « créer une note », et l'assistant les appelle quand la conversation en a besoin. Il n'a accès à rien d'autre.

Pour un CRM du marché, l'installation suit toujours le même ordre.

1. Créez un jeton d'accès dédié à cet usage, avec sa propre trace dans les journaux du CRM. Pas celui d'un utilisateur existant : le jour où quelque chose se passe mal, il faut savoir qui a écrit.
2. Ouvrez-le en lecture seule, le temps de vérifier que ce que l'assistant rapporte correspond vraiment au contenu de la base.
3. Déclarez le serveur MCP côté assistant, avec la liste des actions ouvertes.
4. Ajoutez l'écriture ensuite, action par action.

L'ordre a son importance. Un assistant qui se trompe en lecture produit une note fausse, et on la corrige avant le rendez-vous. Un assistant qui se trompe en écriture laisse trois contacts en double et une opportunité fermée par erreur, que personne ne remarque avant le tableau de bord du mois suivant.

Une note de préparation, du début à la fin

La demande, telle qu'on la tape vraiment : « Rendez-vous demain avec la société X. Sors-moi ce qu'on lui a dit, ce qu'on lui a vendu, ce qui traîne. »

L'assistant enchaîne les appels. Il cherche l'entreprise par sa raison sociale, récupère les contacts associés, les transactions et leur étape, les échanges des six derniers mois, les tâches restées ouvertes. Ensuite il rédige.

La qualité vient de ce qu'on a écrit une fois pour toutes dans la procédure : le format attendu, l'ordre des rubriques, la règle qui veut qu'un montant soit recopié tel quel et jamais recalculé, la consigne de signaler une information manquante plutôt que de la combler.

La première fois, on écrit la consigne. Les fois suivantes, on écrit le nom de la société.

Les garde-fous à poser avant la première écriture

Un assistant qui écrit dans un système métier mérite la même prudence qu'un script qui écrirait au même endroit. Les règles tiennent dans la procédure, en français.

• Chercher avant de créer. Sans ça, « ajoute ce contact » fabrique un doublon à chaque exécution.
• Proposer avant d'exécuter, sur tout ce qui touche une donnée commerciale : l'assistant affiche ce qu'il s'apprête à écrire, et il attend. Le mode automatique reste pour les écritures sans conséquence, une note, une tâche.
• Laisser la suppression fermée. Ce qui doit disparaître se traite à la main, par quelqu'un qui sait pourquoi.
• Cloisonner par périmètre. Un commercial voit son portefeuille, son assistant aussi. Sinon la connexion devient un contournement des habilitations.
• Garder la trace. Ce que l'assistant a lu et écrit reste dans les journaux du CRM, et c'est là qu'on ira chercher, six mois plus tard, d'où sort une ligne bizarre.

Reste la question juridique. Brancher un assistant sur le CRM revient à envoyer chez un fournisseur des données de clients identifiables. Ce qui sort, ce qui est conservé et sous quel régime se décide avant la connexion, pas après le premier incident. Nous traitons ce cadre dans la charte IA en entreprise.

Pourquoi la compétence reste dans l'équipe

Une connexion, ça se commande. On fait écrire le serveur MCP, on fait régler les droits, on récupère une procédure qui tourne le jour de la recette.

Le contenu de la procédure, non. Quel champ fait foi quand deux se contredisent, quelle étape du cycle de vente mérite d'être remontée, ce qu'on veut lire en tête d'une note, ce qu'on refuse d'écrire tout seul dans une fiche : ce sont des arbitrages de métier, et ils appartiennent à la personne qui suit les affaires.

Ces arbitrages bougent, en plus. Une étape ajoutée au pipeline, un champ créé pour une campagne, une équipe qui change de périmètre, et la procédure livrée une fois puis jamais rouverte se décale en un trimestre. L'équipe qui ne sait pas la modifier revient au copier-coller.

Ce qu'il faut savoir faire n'a rien d'inaccessible pour un consultant, un chef de projet ou un dirigeant : écrire une procédure lisible, déclarer un serveur MCP, régler des droits, éprouver la lecture avant d'ouvrir l'écriture, tout cela sans écrire une ligne de code.

C'est le programme de IA utilisateur avancé. Cinq demi-journées espacées, de quoi mettre en place entre deux séances et revenir avec les cas qui ont résisté, et un dernier atelier où chacun présente l'outil qu'il a monté sur ses propres données. Une équipe commerciale qui veut d'abord traiter son cycle de vente prendra le sujet par le métier avec IA pour les ventes.

Le mécanisme se rejoue dès qu'un livrable revient à l'identique. Nous l'avons déroulé sur les devis dans automatiser la rédaction de ses devis avec l'IA, et mesurer l'adoption de l'IA dans son entreprise explique quel relevé faire avant la première session, celui qu'on ne peut plus reconstituer après.