Isi-APP Docs fonctionnelles
Toutes les docs
Markdown brut
CRM — Charger des mairies prospectes depuis le connecteur MCP
Actif crm functional Revu le 2026-10-01 crm/crm-prospects-import.md

CRM — Charger des mairies prospectes depuis le connecteur MCP

Objectif

Charger dans le CRM, par lots, une liste de mairies à prospecter — avec leur directeur général des services (DGS) quand on l'a trouvé — sans créer de doublons ni écraser ce que l'équipe commerciale a déjà saisi. Né de la campagne de prospection des collectivités (projet « Isi-APP - Communication », backlog 2010) : 300 communes à charger, alors que le CRM contenait déjà plus de 4 000 mairies importées en 2025, dont certaines avec les coordonnées d'un homonyme d'un autre département.

Pour qui

Les comptes ISI-admin qui utilisent le connecteur MCP d'ISI-APP (Claude Code, Claude Desktop), avec le module CRM souscrit et le droit de créer et modifier des fiches clients. L'outil n'apparaît pas dans le chat IA de l'application.

Comment ça marche

On demande à l'assistant de charger une liste (50 mairies au plus par lot). L'outil crm_prospects_import répond d'abord par un aperçu, sans rien écrire :

  • pour chaque ligne, ce qui serait fait : création d'une fiche, mise à jour d'une fiche existante (avec l'avant/après de chaque champ), inchangée, ou écartée (ligne invalide, ambiguë, ou droits insuffisants), avec la raison ;
  • les mêmes informations pour le contact de la ligne (le DGS) ;
  • un récapitulatif chiffré.

Si l'on confirme, le lot est écrit en entier ou pas du tout. Si le CRM a changé entre l'aperçu et la confirmation (une fiche corrigée à la main, par exemple), rien n'est écrit et l'assistant redemande un aperçu.

Comment une mairie est retrouvée

L'outil cherche une fiche existante de l'entité, dans cet ordre :

  1. même SIRET ;
  2. même SIREN (un autre établissement de la même commune) ;
  3. même nom, même département, secteur « Mairie » — c'est ce qui permet de corriger une fiche qui porte le SIRET et les coordonnées d'une commune homonyme.

Si plusieurs fiches correspondent, la ligne est déclarée ambiguë et laissée de côté : c'est à l'équipe de fusionner ou de corriger les doublons dans l'application.

Ce qui est modifié, et ce qui ne l'est jamais

Champ Fiche créée Fiche existante
Nom posé jamais modifié
SIRET, téléphone, e-mail, site, département, région, population posés mis à jour s'ils diffèrent (un même numéro écrit autrement n'est pas une différence)
Secteur (Mairie), statut juridique (Public), suivi par posés posés seulement s'ils sont vides
État commercial Prospect jamais modifié (un client reste client)
Étiquette (ex. « Cluster collectivités 2026 ») posée ajoutée aux étiquettes existantes
Description (source des données) posée ajoutée à la suite, une seule fois

Pour le contact : il est rattaché à la fiche, retrouvé par son e-mail ou, à défaut, par ses nom et prénom. Un contact existant est complété (fonction, e-mail, téléphone), jamais renommé. L'adresse de la page où le contact est publié est notée dans sa description.

Règles

  • Rien d'inventé : l'assistant ne transmet que des contacts et des e-mails publiés, avec l'adresse de la page source — jamais une adresse reconstituée du type prénom.nom@.
  • Le consentement marketing des contacts n'est pas touché, et aucun e-mail ni aucune notification ne part.
  • Chaque fiche et chaque contact créés ou modifiés laissent une trace dans l'historique, au nom de la personne qui a confirmé.

Voir aussi

  • Doc technique : .claude/technical-docs/crm/crm-prospects-import.md
  • Le connecteur MCP : mcp-server