Une base se dégrade toute seule
Un CRM est un stock de données qui décrit un monde en mouvement. Les entreprises déménagent, changent de dirigeant, se font racheter, cessent. Les personnes changent de poste et d’entreprise. Un contact saisi il y a trois ans a une probabilité élevée d’être faux sur au moins un point.
Cette dégradation est silencieuse, et elle produit trois coûts.
Le coût direct : des messages qui n’arrivent pas, des appels vers des postes vacants, des courriers retournés.
Le coût de confiance : à partir d’un certain taux d’erreur, l’équipe cesse de se fier à la base et retient les informations importantes ailleurs — dans un carnet, dans une boîte mail, dans une tête. Le CRM devient alors une formalité administrative, et c’est le début de sa fin.
Le coût de décision : un pipeline qui compte des affaires mortes donne des prévisions fausses.
La saisie manuelle ne résout pas ce problème, elle le crée. Personne ne met à jour une fiche pour le plaisir ; la mise à jour se fait quand elle sert immédiatement, c’est-à-dire trop tard et partiellement.
Ce qu’on automatise
L’enrichissement à la création. Une fiche créée à partir d’un nom ou d’une adresse de messagerie se complète seule avec les informations publiques de l’entreprise.
La normalisation. Téléphones au format international, adresses normalisées, raisons sociales cohérentes, domaines extraits.
La détection de doublons à la création et par passe régulière sur l’existant.
La surveillance des changements. Déménagement du siège, changement de dirigeant, procédure collective, cessation : détectés par comparaison périodique avec le répertoire public.
La détection de silence. Fiches sans interaction depuis un seuil, affaires ouvertes sans mouvement.
Le rattachement des interactions. Messages échangés, rendez-vous, documents envoyés, factures : l’historique se remplit à partir de ce qui se passe, pas à partir de ce que quelqu’un saisit.
La purge légale. Suppression ou anonymisation des données dont la durée de conservation est dépassée, selon la politique que vous avez écrite.
Comment ça marche techniquement — pour qui veut le détail
Les sources publiques. L’API Recherche d’entreprises (annuaire-entreprises) pour la recherche par nom et l’accès aux données courantes ; la base SIRENE en téléchargement complet pour les traitements de masse, avec les fichiers stock mensuels et les mises à jour quotidiennes. Pour une base de plusieurs milliers de comptes, charger SIRENE en local et faire les rapprochements en PostgreSQL est incomparablement plus rapide et plus économe que des milliers d’appels d’API — et cela fonctionne sans réseau.
La normalisation, avant tout le reste. Téléphones en E.164 avec libphonenumber, qui gère les indicatifs et les numéros spéciaux correctement. Adresses de messagerie en minuscules, avec attention aux règles propres à chaque fournisseur. Adresses postales via l’API Adresse (BAN), qui renvoie une adresse normalisée et des coordonnées — c’est ce qui permet de reconnaître que « 12 r. de la Gare » et « 12 rue de la gare » sont la même. Raisons sociales normalisées : majuscules sans accents, formes juridiques retirées (SARL, SAS, EURL), ponctuation et espaces réduits. Cette clé normalisée est stockée dans une colonne dédiée et indexée ; c’est elle qui sert aux comparaisons, jamais la valeur affichée.
Le rapprochement. Blocage d’abord pour éviter la comparaison quadratique : on ne compare que les fiches partageant un préfixe de nom normalisé, un code postal ou un domaine de messagerie. Puis score sur les paires candidates : SIREN identique (décisif), domaine identique hors fournisseurs grand public (fort), similarité trigrammes du nom normalisé via pg_trgm avec index GIN (moyen), adresse normalisée identique (fort), téléphone identique (fort). Les seuils sont calibrés sur un échantillon de votre base étiqueté à la main — une heure de travail qui évite des mois de fusions douteuses.
La fusion non destructive. Pas de DELETE. La fiche absorbée reçoit un fusionnee_vers et sort des vues actives ; ses interactions, documents et affaires sont repointés vers la principale. Un champ divergent entre les deux fiches est conservé en alternative plutôt que perdu. L’opération est journalisée et réversible.
La provenance par champ. Chaque valeur porte sa source et sa date : saisie_humaine, sirene, site_web, import, modele. La règle de préséance est explicite — une saisie humaine l’emporte toujours sur une source automatique, et une source automatique récente l’emporte sur une source automatique ancienne. Sans ce marquage, un enrichissement finit toujours par écraser une correction manuelle, et l’équipe cesse alors de corriger.
La surveillance des changements. Passe hebdomadaire ou mensuelle : pour chaque SIREN de la base, comparaison avec l’état SIRENE courant. Les différences sur l’état administratif — cessation, procédure collective —, l’adresse du siège ou la dénomination génèrent un événement. Un compte en procédure collective qui a une facture ouverte est une alerte prioritaire, et c’est le genre d’information qu’on apprend habituellement trop tard.
La détection de silence. Vue matérialisée : date de la dernière interaction tous canaux confondus, ancienneté de l’affaire ouverte la plus vieille, absence de mouvement de statut. Rafraîchie chaque nuit. Le seuil de « dormant » se règle sur votre cycle de vente réel, pas sur une valeur par défaut — six mois de silence n’ont pas le même sens sur un cycle court et sur un cycle d’équipement industriel.
La purge. Une politique de conservation par catégorie, écrite et exécutée : prospects sans interaction au-delà de la durée retenue, demandes sans suite, pièces jointes. La purge peut être une suppression ou une anonymisation — conserver les statistiques agrégées en retirant l’identification est souvent le bon compromis. L’exécution est journalisée, parce que prouver qu’on purge fait partie de la conformité.
Le modèle, à sa place. Un modèle de langage peut, à partir du site d’une entreprise, résumer son activité en deux lignes ou proposer un segment. Sa sortie est stockée comme telle — source modele —, elle ne remplace jamais une donnée factuelle du répertoire officiel, et elle est clairement distinguée dans l’interface. Confondre une déduction et un fait est ce qui rend une base inexploitable.