Les champs à écrire en retour dans le CRM

Mis à jour le

Presque toutes les intégrations d'enrichissement écrivent une seule chose dans votre CRM : le numéro. C'est la raison pour laquelle, six mois plus tard, personne ne sait d'où il vient, si quelqu'un l'a vérifié, ni pourquoi la même fiche a été enrichie trois fois.

Il faut sept propriétés. Deux portent la donnée, trois portent la preuve, et deux portent l'état du traitement. Ce sont ces deux dernières qui décident de votre facture le mois suivant, et ce sont celles que personne ne livre.

Les sept propriétés

Propriété Type Pourquoi elle existe
mobile_verifie Texte, format international Le numéro lui-même. En E.164, pas en format local, pour qu'il reste composable depuis n'importe où
type_de_ligne Liste : mobile, fixe, VoIP Décide du routage de l'appel et, selon le pays, du régime juridique applicable
rattachement_personne Liste : confirmé, non confirmé, non vérifié La seule propriété qui répond à la question qui compte : cette ligne est-elle celle de cette personne
date_verification Date Une vérification de dix-huit mois est un fait historique, pas un fait courant
source_donnee Texte La première chose demandée quand une personne réclame l'origine de son numéro
statut_enrichissement Liste : trouvé, non trouvé, non tenté, en erreur Empêche de rejouer indéfiniment une fiche sur laquelle il n'y a rien à trouver
date_derniere_tentative Date Permet de fixer une cadence au lieu de relancer à chaque modification de fiche

Les deux dernières n'ont rien à voir avec la qualité de la donnée et tout à voir avec votre budget. Sans elles, votre condition de déclenchement ne peut pas distinguer une fiche jamais traitée d'une fiche traitée sans résultat, donc elle retente, donc elle paie.

Pourquoi presque personne ne les écrit

Nous avons lu en novembre 2026 les documentations d'intégration CRM des principaux acteurs du marché. Aucune ne publie le schéma des propriétés écrites en retour.

Ce que les pages décrivent, c'est le mécanisme : la connexion, le déclencheur, le fait que les données « sont ajoutées » à la fiche. Ce qu'elles ne décrivent pas, c'est quelles propriétés, avec quels types, et quelles valeurs possibles.

La conséquence pratique est que vous découvrez le schéma après l'installation, en regardant ce qui apparaît sur une fiche. Et comme les propriétés sont créées automatiquement par l'intégration, vous héritez de noms et de types que vous n'avez pas choisis, dans un CRM où un champ mal typé est pénible à corriger ensuite.

Posez donc la question avant : quelles propriétés écrivez-vous, de quel type, avec quelles valeurs possibles.

Les trois propriétés de preuve, et à quoi elles servent

Celles-là ne servent pas à appeler. Elles servent le jour où quelqu'un demande des comptes.

source_donnee et date_verification répondent à la demande d'un prospect qui veut savoir d'où vient son numéro, et à celle de votre DPO qui veut l'origine de chaque enregistrement. La CNIL, dans sa fiche du 16 octobre 2026 sur la reconstitution d'adresses professionnelles, demande d'expliquer aux personnes dès que possible comment leurs coordonnées ont été obtenues. On ne peut le faire que si l'information est dans la fiche. Nous détaillons la grille complète dans traçabilité des données.

rattachement_personne est la propriété la plus utile et la plus rare. Un numéro peut être valide, actif, correctement typé, et appartenir à quelqu'un d'autre. Cette propriété est la différence entre un fichier dont vous connaissez le taux de bonne personne et un fichier dont vous l'ignorez.

Attention à ce qu'elle ne dit pas : elle n'indique pas si la ligne est professionnelle ou personnelle, qui est une autre question et dont dépend votre régime juridique depuis le 11 août 2026. Aucun fournisseur ne livre cette distinction, et nous expliquons pourquoi sur la page dédiée.

Les erreurs de modélisation à éviter

Quatre, par ordre de fréquence.

Écraser le champ téléphone standard du CRM. Le numéro enrichi doit aller dans sa propre propriété, pas dans le champ que vos commerciaux remplissent à la main. Sinon vous perdez la saisie humaine, qui est souvent la meilleure donnée de la fiche, et vous ne pouvez plus comparer les deux.

Stocker le statut dans une case à cocher. « Enrichi : oui / non » ne distingue pas « trouvé » de « non trouvé » de « non tenté ». Trois états minimum, et une case à cocher n'en porte que deux.

Confondre date de vérification et date de collecte. Un numéro collecté en 2022 et revérifié hier n'est pas un numéro récent. Les deux dates répondent à deux questions distinctes.

Ne pas prévoir le champ d'opposition. Si une personne demande à ne plus être contactée, cette information doit vivre dans la fiche et survivre au prochain import. Un fichier d'exclusion séparé finit toujours par être oublié lors d'une réimportation.

Le schéma minimal, en pratique

Si vous ne créez que trois propriétés, créez celles-ci.

Priorité Propriété Ce que vous perdez sans elle
1 statut_enrichissement Vous payez plusieurs fois pour la même absence de résultat
2 date_verification Vous ne savez jamais si vous appelez une donnée fraîche
3 source_donnee Vous ne pouvez pas répondre à une réclamation

Le numéro lui-même ne figure pas dans ce classement parce qu'il est évident. Les trois ci-dessus sont celles qu'on oublie et qui coûtent, dans cet ordre : de l'argent, des rendez-vous, et un dossier à défendre.

Où Listar se situe

Nous livrons le numéro et son type de ligne, et nous indiquons si le rattachement du numéro à la personne est formellement prouvé, à l'issue des quatre couches de vérification qu'il traverse avant livraison. La date de vérification à écrire est celle de l'enrichissement, que votre intégration connaît déjà.

Ce que vous devez modéliser de votre côté : le statut d'enrichissement et la date de dernière tentative. Ces deux propriétés décrivent l'état de votre traitement, pas la donnée, et aucun fournisseur ne peut les tenir à votre place. C'est à votre workflow de les écrire, y compris quand nous ne trouvons rien.

Sur ce que nous livrons, nous publions 95 % de mobiles confirmés rattachés à la bonne personne, sur 10 000 appels réels répartis sur 100 fichiers de 100 numéros, de mai à septembre 2026, en interne, non audité, dénominateur égal aux numéros livrés.

Et la limite que nous partageons avec toute la catégorie : nous ne distinguons pas une ligne professionnelle d'une ligne personnelle. Ne créez donc pas une propriété qui prétend le contraire.

FAQ

Quelles propriétés créer dans HubSpot pour un enrichissement de mobile ? Sept : le numéro en format international, le type de ligne, le rattachement à la personne, la date de vérification, la source, le statut d'enrichissement et la date de dernière tentative. Les deux dernières décrivent votre traitement et c'est à votre workflow de les écrire.

Pourquoi un statut d'enrichissement plutôt qu'une case à cocher ? Parce qu'une case ne porte que deux états et qu'il en faut au moins trois : trouvé, non trouvé, non tenté. Sans cette distinction, votre déclencheur rejoue indéfiniment les fiches sur lesquelles il n'y a rien à trouver.

Faut-il écrire le numéro dans le champ téléphone standard du CRM ? Non. Donnez-lui sa propre propriété, pour ne pas écraser la saisie de vos commerciaux et pour pouvoir comparer les deux sources.

Les fournisseurs publient-ils leur schéma de champs ? Aucune des documentations d'intégration CRM que nous avons lues en novembre 2026 ne publie les propriétés écrites en retour. Posez la question avant l'installation, parce que les propriétés sont généralement créées automatiquement avec des noms et des types que vous n'avez pas choisis.

Date de vérification ou date de collecte ? Les deux, et dans deux champs distincts. Un numéro collecté il y a quatre ans et revérifié hier n'est pas un numéro récent, et les deux informations servent deux usages différents.

Où stocker une opposition ? Dans la fiche, pas dans un fichier séparé. Une exclusion qui vit en dehors du CRM ne survit pas au prochain import, et c'est la défaillance la plus fréquente des dispositifs de prospection.

Sources

À lire ensuite

Tous les guides

Listar AI