Comment nettoyer sa base CRM avec l'IA, sans rien supprimer ?
Nettoyer une base CRM, c'est poser sur chaque fiche un verdict écrit, gardée ou exclue. La règle est celle qu'on applique déjà aux nouvelles fiches. Puis on vérifie les adresses de ce qu'on garde. On ne supprime rien. On rend la base lisible en une journée, et le taux de bounce baisse dans les quinze jours.
De quoi parle-t-on quand on dit « nettoyer une base » ?
Une base de prospection grossit pendant des années. Un import de salon, un outil d'enrichissement, un fichier repris d'un ancien commercial, un scraping de la période d'avant. Au bout de dix-huit mois, personne ne sait plus quelle part correspond encore à la cible, quelle part est joignable, ni quelle part il ne faut surtout plus contacter. Les séquences partent quand même. Le taux de bounce monte. La boîte d'envoi se dégrade, et le commercial coche des cases à l'aveugle.
Nettoyer ne veut pas dire trier à la main ni supprimer en masse. Cela veut dire couper la base en deux moitiés lisibles avec une règle, une colonne et un filtre : ce qu'on travaille, ce qu'on ne touche plus. La règle existe déjà chez presque tout le monde. C'est celle que l'agent de prospection applique chaque jour aux nouvelles fiches, et que personne n'a jamais appliquée au stock.
Quelle règle appliquer à dix mille fiches ?
La même que celle de l'agent, mot pour mot. Les postes cibles, les marqueurs obligatoires, les marqueurs qui disqualifient, les domaines de concurrents, les extensions de domaine hors zone, les secteurs hors cible. La tentation est d'écrire une règle « raisonnable » pour l'historique, plus souple. C'est une deuxième doctrine, et elle diverge de la première dès la semaine suivante.
Sur une base de plus de dix mille fiches constituée avant le durcissement de la règle, la moitié sort. C'est le chiffre vrai, pas un défaut de méthode. Le plus gros bloc exclu n'est pas fait de fiches fausses : ce sont des fonctions proches sans le marqueur exigé, par exemple des milliers d'acheteurs sans mention d'achats indirects, que l'agent refuse chaque jour depuis des mois. Le nettoyage ne fait que rendre visible ce que la règle décide déjà.
Deux exceptions se tranchent avant d'écrire une ligne. Toute personne rattachée à une affaire ouverte est gardée, quel que soit son intitulé. Et une fiche créée par un agent est gardée par construction : un agent l'a déjà jugée.
Pourquoi on n'écrit rien avant d'avoir montré un tableau ?
Parce qu'un dirigeant ne valide pas un pourcentage, il valide un choix. La passe à blanc lit toute la base en lecture seule et rend un tableau d'options : la règle stricte, la règle plus la direction générale, la règle plus les intitulés vides dont le persona est déjà connu, la règle plus les acheteurs sans marqueur. Pour chaque ligne, le nombre de gardés, d'exclus, de gardés avec une adresse, et le nombre de crédits de vérification à dépenser. Ce dernier chiffre est celui qu'on demande toujours en premier.
Le tableau ne coûte rien et se rejoue autant de fois qu'il faut. Ce qui convainc, ce ne sont pas les pourcentages mais les exemples : dix intitulés gardés, dix exclus pour « autre fonction », dix exclus pour « achats génériques », dix pour « secteur public ». Le choix se prend en dix secondes, sur des cas réels, et il ne se conteste plus après coup.
| Avant | Après |
|---|---|
| Une base où personne ne sait quelle part est encore la cible | Un verdict écrit sur chaque fiche, gardée ou exclue, et un filtre par verdict |
| Des séquences qui partent vers des adresses jamais vérifiées | Chaque adresse gardée vérifiée, les adresses mortes dans un statut à part |
| Une règle appliquée aux nouvelles fiches, jamais au stock | La même règle, mot pour mot, sur toute la base |
| Un nettoyage qui supprime, donc irréversible et contesté | Une colonne qu'on réécrit le jour où la cible change |
| Un taux de bounce qui monte sans qu'on sache pourquoi | Le taux de bounce comme preuve du résultat, mesuré à quinze jours |
Comment vérifier les adresses sans construire une deuxième machine ?
Presque tous les dispositifs de prospection ont déjà un vérificateur d'adresses en production, branché sur une file : à vérifier, prêt, douteux. Les fiches gardées entrent dans cette file par la porte prévue, et le vérificateur fait son travail par lots, la nuit, avec son cache. On n'écrit pas un deuxième appel. On hérite au passage des filtres et de la traçabilité de la machine.
Les ordres de grandeur sur une base ancienne : sept adresses délivrables sur dix parmi les vérifiées, une adresse morte sur seize, le reste douteux. Un piège attend à la fin : la plupart des machines rangent « douteux » et « mort » dans le même statut. Celui qui a demandé le nettoyage veut voir les adresses mortes. Il faut une passe finale qui relit le journal du vérificateur et pose un statut à part, sur décision écrite, avec un export daté. Sans elle, le nettoyage est invisible pour celui qui l'a commandé.
Sur quels chiffres juger que c'est fait ?
Cinq, dans cet ordre. La part de la base gardée, qui dit ce que vaut la base par rapport à la cible d'aujourd'hui. La part des gardés qui ont une adresse, qui est la matière réellement travaillable. La part d'adresses délivrables et la part d'adresses mortes parmi les vérifiés. Le taux de bounce des envois, avant et après, qui est le seul chiffre que la boîte d'envoi voit. Et le nombre de fiches gardées jamais contactées, qui est souvent le vrai gisement : des mois de capacité d'envoi déjà payés, alors qu'on continue de dépenser pour trouver des noms nouveaux.
Le temps commercial est rare : selon l'étude State of Sales de Salesforce, un commercial consacre 28 % de sa semaine à vendre. Une base qui envoie vers des adresses mortes et des fonctions hors cible consomme une part de ce temps en réponses automatiques, en bounces à traiter et en désabonnements à gérer. Le nettoyage rend ce temps à la vente.
Quels pièges avons-nous payés en le faisant ?
Trois, tous silencieux. Le coût d'écriture par fiche ne se lit pas dans la documentation du CRM mais dans les en-têtes de réponse, sur cinq fiches de test : c'est ce chiffre qui dit s'il faut couper le lot en deux jours. Sept échecs consécutifs sans message d'erreur n'étaient pas des échecs mais une limite de débit : tous sont passés à la reprise, et un journal qui les aurait comptés comme faits aurait sauté sept fiches pour toujours. Enfin, un contrôle par lot a dit « vide » sur huit fiches qui portaient toutes la bonne valeur, parce que l'endpoint de liste ignorait le paramètre d'identifiants : relire à l'unité avant de conclure, toujours.
Ce chantier suit la méthode que nous appliquons à tous nos agents : valider sur cinq avant des milliers, relire le résultat à la cible, ne jamais croire un statut vert. Pour un exemple de base rendue fiable puis actionnable, lisez le cas un CRM fiable et actionnable.
Les questions qu'on nous pose
Pourquoi ne pas simplement supprimer les fiches hors cible ?
Parce qu'une suppression dans l'interface d'un CRM n'est répercutée nulle part : les automates qui référencent la fiche continuent de la chercher, et une doctrine change. Le jour où la direction générale entre dans la cible, on refait la passe à blanc et on réécrit une colonne. Une fiche exclue garde son historique.
Combien de temps prend le nettoyage d'une base de dix mille fiches ?
Une journée de travail. Une demi-journée pour la passe à blanc et l'arbitrage, une heure d'écriture par tranche de cinq mille fiches, et la vérification des adresses qui tourne seule la nuit suivante. Le budget d'appels quotidien du CRM peut imposer de couper l'écriture en deux jours.
Que fait-on des personnes en cours de négociation qui tombent en exclu ?
On tranche avant d'écrire : toute personne rattachée à une affaire ouverte est gardée, quel que soit son intitulé. Si elle porte en plus une opposition, l'opposition reste posée. Le commercial voit la fiche, le pont d'envoi continue de la refuser. Ces cas sont listés nommément dans le compte rendu.
Faut-il un vérificateur d'adresses payant ?
Oui, et c'est le poste le moins cher du chantier : quelques dizaines d'euros pour plusieurs milliers d'adresses. Une adresse morte détectée avant l'envoi est un bounce évité, et le taux de bounce est le seul chiffre que la boîte d'envoi voit vraiment.
L'IA décide-t-elle seule de qui est gardé ?
Non. Elle applique une règle écrite, produit un tableau d'options chiffré et des exemples par catégorie, et s'arrête. Le dirigeant choisit une ligne. Rien n'est écrit dans le CRM avant ce choix, et un test sur cinq fiches précède toujours le lot.