--- title: "Les champs à écrire en retour dans le CRM" description: "Presque toutes les intégrations n'écrivent que le numéro. Il en faut sept, et deux d'entre eux décident de ce que vous dépenserez le mois suivant." canonical: "https://listar.fr/fr/champs-crm-enrichissement-mobile" updated: "2026-11-11" published: "2026-11-11" --- # Les champs à écrire en retour dans le CRM > 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](https://listar.fr/fr/tracabilite-des-donnees). **`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](https://listar.fr/fr/ligne-pro-ou-personnelle-prospection). ## 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 - [HubSpot, choisir ses actions de workflow](https://knowledge.hubspot.com/workflows/choose-your-workflow-actions), sur les actions des applications connectées - [Salesforce, créer un Flow déclenché par enregistrement](https://help.salesforce.com/s/articleView?id=platform.ls_create_record_triggered_flow.htm), sur la mise à jour d'enregistrement - CNIL, 16 octobre 2026, sur l'obligation d'expliquer dès que possible l'origine des coordonnées - Documentations d'intégration CRM des principaux fournisseurs de données B2B, consultées le 11 novembre 2026 - Pages consultées le 11 novembre 2026 ## À lire ensuite - [Enrichir HubSpot et Salesforce sans Zapier : les routes natives](https://listar.fr/fr/enrichir-hubspot-sans-zapier) - [Déclencher l'enrichissement sans brûler de crédits](https://listar.fr/fr/declencher-enrichissement-sans-bruler-credits) - [Traçabilité des données : la grille que votre DPO va demander](https://listar.fr/fr/tracabilite-des-donnees)