Un lead arrive. Formulaire du site, message LinkedIn, badge scanné sur un salon. Quelqu'un dans votre équipe cherche la boîte sur Google, devine sa taille, classe son secteur, essaie de deviner la fonction derrière l'intitulé de poste, remplit les champs du CRM à la main, puis décide qui doit le prendre. Une fois, ça prend cinq minutes. Multiplié par des dizaines de leads chaque semaine, ça devient des heures perdues et des erreurs de routage qui coûtent des deals.
Pourquoi la peur de pourrir sa base freine tout le monde
La réaction la plus courante face à ce constat, c'est la prudence. On a peur qu'un script mal réglé vienne remplir le CRM de mauvaises informations, qu'un mauvais routage envoie un lead stratégique dans la mauvaise file, ou qu'un champ halluciné par un modèle de langage passe inaperçu pendant des mois. Cette peur est légitime. Elle vise la bonne cible : ce n'est pas l'IA le problème, c'est l'absence de garde-fous autour d'elle.
Ce qui protège la base, ce sont deux choses : un contrat de données écrit avant le premier script, et un marquage systématique de ce qui a été rempli automatiquement. Le reste, ce sont des étapes.
Étape 1 : écrire le contrat de données
Avant d'enrichir quoi que ce soit, on liste noir sur blanc les champs concernés (secteur, taille d'entreprise, fonction, pays, source) et les valeurs permises pour chacun. Un champ secteur avec une liste fermée de quinze valeurs se contrôle. Un champ secteur en texte libre rempli par un modèle de langage, non. Ce contrat, c'est la frontière entre ce que l'IA a le droit d'écrire et ce qu'elle doit laisser vide.
Étape 2 : enrichir en cascade, pas en vrac
L'enrichissement se fait dans un ordre précis. D'abord les données publiques structurées : nom légal de l'entreprise, taille, secteur déclaré, à partir de bases type Clearbit ou d'une recherche web ciblée. Ensuite seulement, le modèle de langage intervient pour l'interprétation : deviner la fonction réelle derrière un intitulé de poste flou, classer une activité dans la bonne catégorie sectorielle, résumer un message entrant en une ligne exploitable. La donnée factuelle passe par une source vérifiable en premier. Le LLM arrive en dernier, sur ce qu'aucune base structurée ne peut trancher.
- un intitulé « Head of Growth & Ops » devient fonction = growth, avec une confiance haute
- un intitulé ambigu type « Manager » reste vide plutôt que deviné au hasard
- un secteur absent des bases publiques est classé par le modèle depuis la description de l'activité, avec une étiquette de confiance
Étape 3 : scorer et router avec des règles explicites
Le routage ne doit jamais dépendre d'une décision opaque du modèle. On pose des règles lisibles par n'importe qui dans l'équipe : taille au-dessus d'un seuil et fonction revenue, ça part chez le commercial senior ; secteur hors cible, ça part en nurturing ; champ obligatoire manquant, ça part en file de vérification humaine. Le LLM alimente les critères (la fonction, le secteur, un score de pertinence). Les règles qui décident où va le lead restent un tableau simple, pas un prompt.
Étape 4 : garder un humain sur les cas ambigus, tout logguer
Deux réflexes ferment la boucle. D'abord, tout ce qui reste incertain après la cascade atterrit dans une file de vérification humaine plutôt que d'être deviné à tout prix. Ensuite, chaque champ rempli automatiquement porte une trace : source, date, niveau de confiance. Un commercial qui ouvre une fiche sait immédiatement ce qui vient d'une donnée vérifiée et ce qui vient d'une interprétation du modèle.
un champ vide vaut mieux qu'un champ faux
Ce que ça change concrètement sur la base
Le CRM reste la source de vérité, pas le script d'enrichissement. Rien n'est écrit sans passer par le contrat de données. Rien n'est deviné sans être marqué comme tel. Et le routage reste un ensemble de règles que n'importe qui dans l'équipe peut lire et corriger, pas une boîte noire qu'on découvre en marchant dessus six mois plus tard. C'est le même principe qui fait tourner le second cerveau que j'ai construit pour mon propre usage : des agents qui interprètent, un système de règles qui décide, et une trace de ce qui a été fait automatiquement.
Ce chantier de tri des leads entrants rejoint deux autres irritants qu'on retrouve souvent côté ops : automatiser un reporting commercial qui tourne sans vous une fois que les données sont propres, et synchroniser Notion et le CRM sans ressaisie quand l'information doit vivre à deux endroits à la fois.