---
title: "CRM — Charger des mairies prospectes depuis le connecteur MCP"
module: crm
type: functional
status: active
updated: 2026-10-01
---

# 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](../ai/mcp-server.md)