Vérifier que les données de contact sont exactes avant un import CRM
La question que l'on se pose une fois le fichier déjà ouvert : ce que « exact » couvre ici, ce que cette vérification contrôle réellement, et ce que seul votre CRM peut vous dire.
L'outil lui-même
CRM Import Check
Déposez un fichier CSV ou Excel, choisissez HubSpot, Salesforce ou Pipedrive, et voyez ce que l'import rejetterait, tronquerait ou fusionnerait silencieusement.
Vérifier un fichierSix questions de plus
Les neuf posées avant tout téléversement — ce que fait l'outil, quels CRM il prend en charge, si le fichier est envoyé, et le reste — trouvent leur réponse sur la page de l'outil elle-même, là où elles sont utiles. Celles-ci arrivent une fois que vous regardez votre propre fichier en vous demandant ce que « exact » couvre réellement.
- Comment puis-je vérifier que les données de contact sont exactes avant de les importer dans mon CRM ?
- « Exact » couvre deux choses différentes, et cet outil n'en referme qu'une seule. Ce qu'il vérifie, selon la cible choisie : que chaque champ obligatoire est présent (Nom pour un contact Salesforce, une adresse e-mail ou les deux noms pour un contact HubSpot), que chaque adresse e-mail et numéro de téléphone est structurellement utilisable, que les dates et les nombres sont écrits comme la cible les attend, qu'aucune ligne ne partage le même e-mail ou la même clé qu'une autre — ce que l'import du CRM lui-même laisse silencieusement s'écraser l'une l'autre —, et qu'aucune valeur ne dépasse la limite de champ publiée par la cible. Ce qu'il ne peut pas vérifier : si un propriétaire, un statut de prospect ou une autre valeur de liste déroulante correspond réellement à une option configurée dans votre CRM, si une adresse e-mail reçoit réellement du courrier, et si la personne ou l'entreprise nommée est la bonne. Un verdict propre signifie que le fichier ne sera ni rejeté, ni tronqué, ni fusionné silencieusement sur les vérifications ci-dessus — ce n'est pas une affirmation que chaque fait qu'il contient est vrai.
- Peut-il vérifier qu'une valeur de liste déroulante ou de propriétaire correspond à la configuration de mon CRM ?
- Non. Les options de listes déroulantes, les statuts de prospect, les attributions de propriétaire et les liens vers des fiches existantes n'existent que dans la configuration propre de votre CRM, et cet outil ne s'y connecte jamais — il lit uniquement le fichier que vous vous apprêtez à remettre. Une valeur qui semble correcte dans le fichier peut quand même être rejetée à l'import parce que le CRM n'a pas d'option correspondante ; seul le CRM lui-même, ou une personne qui connaît sa configuration, peut vérifier cela.
- Si le verdict indique « prêt », l'import est-il garanti de réussir ?
- Cela signifie que chaque ligne a passé les vérifications exécutées contre la cible choisie — champs obligatoires, formats, doublons internes au fichier, longueurs de champ, correspondance des colonnes. Ce n'est pas une garantie contre ce que le CRM décide de son côté : une valeur de liste déroulante sans correspondance, un propriétaire qui n'existe plus, un doublon par rapport à une fiche déjà présente dans le CRM plutôt qu'à une autre ligne de votre fichier, ou une permission que le compte effectuant l'import n'a pas. Cela dépend d'un état interne au CRM qu'une vérification de fichier ne peut pas voir.
- La vérification d'exactitude fonctionne-t-elle de la même façon pour les fiches d'entreprise ?
- Oui, avec un jeu de règles différent. Une fiche d'entreprise n'a pas besoin d'adresse e-mail — HubSpot en accepte une avec soit un domaine, soit un nom d'entreprise, et Salesforce et Pipedrive ont leurs propres équivalents. Les vérifications de formatage, de doublons et de longueur de champ fonctionnent de la même façon, mais contre les champs obligatoires et les limites propres à l'objet entreprise plutôt qu'à l'objet contact.
- Vérifie-t-il que les adresses e-mail sont réelles et ne rebondiront pas ?
- Non. Il vérifie qu'une adresse est structurellement valide — dans la forme attendue par l'importeur d'un CRM — et signale les adresses génériques comme info@ ou sales@, les domaines jetables et les fautes de frappe probables comme un domaine se terminant par gmial.com. Savoir si une boîte aux lettres existe réellement et accepte le courrier est une question qui exige de contacter un serveur de messagerie, et cet outil n'effectue aucun appel réseau transportant vos données — vérifier la délivrabilité reviendrait à envoyer chaque adresse quelque part.
- Si j'applique toutes les corrections suggérées, le fichier devient-il totalement exact ?
- Il devient exempt des problèmes que cet outil peut voir et est disposé à corriger automatiquement — espaces superflus supprimés, e-mail mis en minuscules, caractère invalide retiré, espace réservé effacé. Il ne devient pas vérifié au sens ci-dessus : corriger le formatage ne confirme pas une valeur de liste déroulante, n'invente pas une adresse e-mail fonctionnelle et ne décide pas laquelle de deux lignes en double est la fiche réelle. Cela reste des décisions à prendre, et le journal des modifications montre exactement ce qui a été touché pour que vous puissiez les prendre.
À quoi cela ressemble sur un fichier réel
Trois cas où le fichier semblait correct au premier regard et ne l'était pas.
- Un domaine qui semble correct jusqu'à ce qu'on le relise
Entrée : ada@gmial.com dans la colonne e-mail, une ligne parmi douze cents.
Sortie : un avertissement nommant la ligne et le domaine probablement correct.
Constat : l'outil suggère gmail.com et affiche les deux valeurs côte à côte. Rien ne change tant que vous ne cochez pas la correction — une suggestion n'est pas un fait.
- Une valeur saisie pour passer outre un champ obligatoire
Entrée : la colonne Intitulé du poste indique « n/a » sur quarante lignes ajoutées le même jour.
Sortie : un avertissement nommant les lignes et la valeur répétée.
Constat : l'outil efface l'espace réservé plutôt que d'inventer un intitulé réel — il laisse la cellule vide pour qu'une personne la remplisse ou la laisse ainsi.
- Deux colonnes revendiquant le même champ
Entrée : un fichier avec à la fois une colonne « Company » et une colonne « Company Name ».
Sortie : un avertissement nommant les deux en-têtes et le champ auquel elles correspondent toutes les deux.
Constat : l'outil en propose une et marque l'autre comme non associée — il ne décide pas laquelle est la bonne, car il ne peut pas savoir en quelle colonne vous avez confiance.
Qui pose cette question
La question vient de personnes qui ont déjà le fichier en main, à quatre moments différents du même travail.
Quelqu'un qui effectue son premier import
Le premier import CRM qu'une entreprise réalise fixe la forme de sa base de données pour des années. Bien faire « exact » une fois, avant que quoi que ce soit ne soit écrit, coûte moins cher que de le corriger après.
Quiconque est responsable de la qualité des données
Un titre que peu d'entreprises attribuent, mais quelqu'un finit toujours par faire ce travail. C'est la vérification qui a lieu avant un import, plutôt qu'un projet de nettoyage après.
Les consultants qui intègrent un client
Un fichier différent à chaque client, sans connexion permanente à son CRM sur laquelle s'appuyer. Le fichier est la seule chose à vérifier.
Quiconque dirige une migration CRM
Un export de l'ancien système n'a jamais été écrit en pensant aux règles du nouveau. Le vérifier par rapport aux règles de la destination, avant la bascule, est tout l'intérêt de la démarche.
L'outil
Vérifier un fichier maintenant
Déposez le CSV que vous vous apprêtez à importer. Rien à installer, pas de compte, rien à envoyer.
Vérifier un fichier