Checklist d’importation de données CRM : comment tester un CRM auto-hébergé avant de transférer vos enregistrements

Pourquoi la qualité de l’importation compte davantage qu’un premier import réussi

Un bouton d’importation ne constitue pas un plan de migration. Un premier import peut sembler réussi tout en créant silencieusement des contacts en double, en attribuant des enregistrements à la mauvaise équipe, en rattachant une opportunité à la mauvaise organisation ou en écartant des lignes qui échouent à la validation.

Évaluez la capacité d’importation comme un système de contrôle. Vous devez savoir ce que l’application crée, met à jour, rejette et signale ; si vous pouvez corriger les échecs ; et si une exécution répétée est sûre. La vraie question n’est pas « Peut-il importer des CSV ? », mais « Pouvons-nous produire, à partir de nos vraies données source, des enregistrements fiables de manière répétable ? ».

Les différents CRM mettent en œuvre ces contrôles de façons différentes. Par exemple, EspoCRM documente les modes d’importation Créer uniquement, Créer et mettre à jour, et Mettre à jour uniquement. Ses modes permettant la mise à jour imposent à l’opérateur de choisir les champs qui identifient un enregistrement existant. Ce choix relève de la gouvernance des données, et non d’un paramètre technique par défaut. Consultez la documentation d’importation d’EspoCRM : https://docs.espocrm.com/administration/import/.

• N’approuvez pas un CRM uniquement sur la base d’un fichier de démonstration propre.
• Testez avec les mêmes types de données, incohérences et relations que ceux présents dans l’export de production.
• Consignez chaque décision de configuration utilisée pour chaque exécution de test.
• Définissez la réussite comme des enregistrements exacts et exploitables, avec des exceptions explicables.

Commencez par un inventaire des données source

Créez un inventaire avant de mapper une seule colonne. Les tableurs et les CRM sortants contiennent couramment des informations liées dans des onglets, modules, notes en texte libre et espaces de stockage de fichiers distincts. Si l’inventaire ne compte que les contacts, la migration peut sembler complète tout en perdant le contexte commercial, l’attribution des responsables ou l’historique opérationnel.

Pour chaque table source ou export, identifiez son objectif métier, son nombre d’enregistrements, son identifiant principal, son responsable actuel, son gestionnaire de données, son entité de destination et ses dépendances relationnelles. Indiquez quelles données sont essentielles dès le premier jour et lesquelles peuvent être différées ou archivées en dehors du CRM.

N’incluez les activités qu’après avoir confirmé que le modèle de destination prend en charge les enregistrements et panneaux concernés. Dans EspoCRM, par exemple, les panneaux Activités, Historique et Tâches disponibles dépendent du type d’entité configuré. Ne supposez pas que chaque entité personnalisée affichera les mêmes informations liées qu’un enregistrement de personne ou d’organisation. Consultez la documentation du gestionnaire d’entités d’EspoCRM : https://docs.espocrm.com/administration/entity-manager/.

• Enregistrements principaux : personnes, organisations, prospects, opportunités ou entités équivalentes.
• Relations : contact-organisation, opportunité-contact, enregistrements parent-enfant et tout lien plusieurs-à-plusieurs.
• Contexte opérationnel : notes, appels, réunions, tâches, e-mails et historique, lorsque nécessaire.
• Fichiers : pièces jointes, documents, chemins de fichiers et liens vers des référentiels externes.
• Données de configuration : champs personnalisés, valeurs énumérées, étiquettes, équipes, responsables et statuts.
• Identifiants source : identifiants provenant du tableur ou de l’ancien système pour chaque entité.

Définissez le modèle de données de destination avant de mapper les champs

Le mappage des champs doit suivre un modèle de destination délibérément validé, et non une volonté de conserver chaque colonne source. Décidez quelles entités de destination existeront, quels champs sont obligatoires, quels champs sont personnalisés, quelles valeurs appartiennent à des listes contrôlées et quelles informations doivent rester hors du CRM.

Pour chaque champ source, choisissez un résultat : mapper directement, transformer, scinder, combiner, placer dans un champ personnalisé contrôlé, conserver dans une archive ou exclure. Documentez la justification. Par exemple, une colonne « statut » en texte libre ne doit pas être mappée vers un champ de statut restreint avant que ses valeurs source distinctes aient été examinées et normalisées.

Vérifiez l’éligibilité à l’importation au niveau du champ. La documentation Studio de SuiteCRM décrit la configuration des champs et des relations, y compris si les champs sont autorisés, interdits ou obligatoires pour les imports via l’assistant d’importation. Elle indique également que le type de champ, l’audit et les paramètres de fusion des doublons sont des propriétés de champ. Les contrôles exacts varient selon le CRM ; validez donc l’application cible plutôt que de les déduire d’un autre produit. Consultez la documentation Studio de SuiteCRM : https://pre-release.docs.suitecrm.com/admin/administration-panel/studio/.

• Entité de destination et nom du champ.
• Table source, colonne et type de données source.
• Règle de transformation et valeurs autorisées.
• Statut obligatoire, facultatif, sensible ou en lecture seule.
• Éligibilité à l’importation et comportement par défaut.
• Responsable de la décision de mappage et du résultat de test.

Créez un import de test représentatif au lieu d’utiliser un échantillon nettoyé

Un échantillon soigné prouve seulement que des données soignées peuvent être importées. Constituez un petit jeu de données de test représentatif à partir de copies d’enregistrements réels, en protégeant les valeurs sensibles si nécessaire. Conservez les problèmes réellement présents dans vos données de production afin que le test révèle le comportement de l’importateur.

Incluez à la fois des enregistrements ordinaires et des cas limites intentionnels. Testez les valeurs obligatoires vides, les valeurs incompatibles avec des listes contrôlées, les noms en double, les adresses e-mail en double, les identifiants source répétés, les formats de téléphone incohérents, les champs à valeurs multiples, la ponctuation, les caractères non ASCII et les dates écrites dans plusieurs styles.

Les échecs de validation constituent des éléments de preuve précieux. EspoCRM indique qu’une ligne qui échoue à la validation ne crée pas d’enregistrement, et cite notamment les valeurs énumérées incompatibles et les valeurs vides pour une énumération non vide. Votre test doit confirmer le comportement équivalent dans le CRM que vous évaluez, y compris ce qui arrive aux champs valides d’une ligne partiellement invalide. Consultez la documentation d’importation d’EspoCRM : https://docs.espocrm.com/administration/import/.

• Utilisez un nombre d’enregistrements connu pour chaque fichier de test.
• Étiquetez les enregistrements de test afin de pouvoir les retrouver et les examiner ultérieurement.
• Conservez une copie intacte de l’extrait de test original.
• Incluez des lignes connues comme valides, connues comme invalides et volontairement ambiguës.
• Ne remplacez pas les valeurs de production par des valeurs fictives irréalistement uniformes.

Testez les décisions qui créent de mauvaises données CRM : doublons, valeurs manquantes, formatage et attribution

Le contrôle des doublons commence par une politique de rapprochement explicite. Décidez quels identifiants source font autorité, si l’adresse e-mail est suffisamment unique dans votre cas d’usage et comment le CRM doit traiter une correspondance sur un champ, mais pas sur un autre. Consignez les champs de rapprochement exacts sélectionnés pour chaque exécution.

Les identifiants source stables sont particulièrement importants pour les cycles de correction. Odoo indique que des identifiants externes cohérents peuvent permettre des imports répétés sans créer de doublons, tandis que modifier ou supprimer un identifiant externe peut entraîner la création d’un nouvel enregistrement plutôt qu’une mise à jour. Que votre CRM choisi utilise des identifiants externes ou un autre mécanisme d’identification, vérifiez que son identifiant est conservé exactement comme prévu lors d’une réimportation. Consultez la documentation d’exportation et d’importation d’Odoo : https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html.

Ne faites pas confiance à la détection automatique des dates. Odoo indique que les formats de date peuvent être mal reconnus, notamment par inversion jour-mois, et recommande de vérifier ou de définir un format ISO 8601. Placez des dates ambiguës telles que 03/04/2024 dans le fichier de test et examinez la valeur enregistrée, pas uniquement l’aperçu d’importation.

L’attribution des responsables exige le même niveau d’examen. EspoCRM peut appliquer des valeurs par défaut, notamment Utilisateur attribué et Équipes, aux enregistrements nouveaux et mis à jour pendant l’importation. Testez si le responsable source est conservé, traduit, remplacé par une valeur par défaut ou laissé vide. Décidez ensuite quel comportement est acceptable pour chaque entité. Consultez la documentation d’importation d’EspoCRM : https://docs.espocrm.com/administration/import/.

• Créez un enregistrement avec un identifiant source existant et des données non clés modifiées ; testez le parcours de mise à jour prévu.
• Créez deux enregistrements aux noms similaires mais aux identifiants différents ; assurez-vous qu’ils ne fusionnent pas par erreur.
• Testez les champs vides dans un fichier de mise à jour pour déterminer s’ils effacent les valeurs existantes, sont ignorés ou échouent à la validation.
• Testez les formats de date, nombre, devise, téléphone et sélection multiple.
• Testez un enregistrement dont le responsable d’origine n’existe plus dans la destination.
• Examinez les valeurs de responsable et d’équipe après les exécutions de création comme de mise à jour.

Vérifiez les relations et l’historique : contacts, organisations, opportunités, notes, tâches et pièces jointes

L’exactitude des relations fait souvent la différence entre un CRM utile et un annuaire d’enregistrements déconnectés. Créez des cas de test où une organisation possède plusieurs contacts, une opportunité est associée à plusieurs personnes et des enregistrements ont des noms affichés similaires ou identiques. Vérifiez chaque relation depuis les deux côtés dans l’interface de destination.

Importez les entités parentes avant les entités enfants lorsque la relation dépend d’enregistrements importés auparavant. SuiteCRM indique aux utilisateurs d’importer les comptes avant les contacts associés afin que la relation puisse être établie. Odoo documente également l’importation préalable des objets liés lorsque les relations sont recréées via des identifiants externes. Consultez la documentation de gestion des enregistrements de SuiteCRM : https://docs.suitecrm.com/8.x/user/core-concepts/record-management/ et la documentation d’exportation et d’importation d’Odoo : https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html.

Évitez de vous appuyer sur les noms pour le rapprochement des relations lorsqu’une ambiguïté est possible. Odoo avertit que, si plusieurs enregistrements liés portent le même nom, les données peuvent être liées au premier enregistrement correspondant. Utilisez des identifiants stables pour les champs de relation lorsque la destination les prend en charge, et prouvez le résultat avec des enregistrements de test délibérément ambigus.

Les pièces jointes et l’historique des activités méritent des tests d’acceptation distincts. Confirmez si les fichiers sont importés, liés, ignorés ou s’ils nécessitent une procédure distincte spécifique au produit. Ne supposez pas que l’importateur CSV utilisé pour les enregistrements principaux importe également les pièces jointes, notes, tâches ou l’historique. Pour toute procédure prise en charge, confirmez que les dates, auteurs, enregistrements parents et autorisations sont appropriés.

• Importez les organisations ou comptes avant les contacts associés.
• Importez les opportunités ou dossiers parents avant leurs notes et activités dépendantes lorsque le modèle l’exige.
• Utilisez autant que possible des identifiants source, et non des noms affichés, pour relier les enregistrements.
• Examinez le nombre de relations et les liens individuels dans l’application.
• Ouvrez des pièces jointes d’exemple et vérifiez leur association à l’enregistrement prévu.
• Vérifiez les dates d’activité, créateurs, personnes assignées et la visibilité.

Vérifiez comment l’application signale les enregistrements rejetés ou modifiés

Un importateur qui ne signale qu’un total final est difficile à exploiter en toute sécurité. Exigez des éléments de preuve pour chaque ligne rejetée : sa ligne source ou son identifiant, le motif de l’échec et les valeurs fournies. Exigez également un moyen de distinguer les enregistrements nouvellement créés des mises à jour et des lignes ignorées.

EspoCRM fournit un panneau Erreurs comprenant le motif de l’échec, l’index de ligne et les valeurs de la ligne, et permet d’exporter les lignes en échec au format CSV afin de les corriger et de les réimporter. La documentation de SuiteCRM décrit de la même manière un onglet Erreurs permettant la revue et la correction avant de relancer un import. Considérez-les comme des exemples utiles des éléments de preuve à rechercher, et non comme l’assurance que chaque CRM propose des rapports identiques. Consultez la documentation d’importation d’EspoCRM : https://docs.espocrm.com/administration/import/ et la documentation de gestion des enregistrements de SuiteCRM : https://docs.suitecrm.com/8.x/user/core-concepts/record-management/.

Exécutez un test contenant des enregistrements valides, des enregistrements invalides et des candidats à la mise à jour. Rapprochez le nombre d’enregistrements source des résultats de création, mise à jour, rejet et ignorés. Toute différence inexpliquée constitue un critère d’acceptation non satisfait.

• Pouvez-vous exporter les lignes en échec pour les corriger ?
• Chaque erreur identifie-t-elle une ligne source ou un identifiant source stable ?
• Le rapport explique-t-il l’échec en termes opérationnels ?
• Pouvez-vous distinguer les créations, mises à jour, rejets et lignes ignorées ?
• Pouvez-vous enregistrer les paramètres de mappage et de contrôle des doublons pour une exécution répétable ?
• Pouvez-vous examiner les enregistrements résultants directement depuis le rapport d’importation ?

Testez la correction et la réimportation sans multiplier les enregistrements ni écraser involontairement des données fiables

Le test d’importation le plus important est généralement le deuxième. Corrigez un ensemble limité de lignes rejetées, puis réimportez le fichier corrigé en utilisant le mode de mise à jour et les règles de rapprochement prévus. Confirmez que les enregistrements corrigés sont créés ou mis à jour une seule fois, que les enregistrements déjà importés avec succès ne sont pas dupliqués et que les champs non concernés restent fiables.

Distinguez le comportement de création de celui de mise à jour dans vos critères d’acceptation. Dans EspoCRM, Créer uniquement crée des enregistrements, tandis que Créer et mettre à jour et Mettre à jour uniquement utilisent les champs de rapprochement sélectionnés pour trouver les enregistrements à mettre à jour. Une équipe de production doit savoir quel mode elle utilisera pour le chargement initial, la correction des erreurs et les mises à jour incrémentielles ultérieures. Consultez la documentation d’importation d’EspoCRM : https://docs.espocrm.com/administration/import/.

Testez les valeurs vides et modifiées avec attention. Une réimportation peut écraser des informations modifiées après le premier import, selon le mode et les mappages sélectionnés. Établissez une fenêtre de bascule, identifiez le système de référence pour chaque champ durant la migration et définissez si les modifications post-importation sont protégées, écrasées ou rapprochées manuellement.

Conservez l’identifiant source stable dans chaque fichier de correction. Ne le modifiez pas simplement pour faire disparaître une erreur ; cela peut transformer une mise à jour prévue en nouvel enregistrement. Odoo documente ce risque pour les identifiants externes. Consultez la documentation d’exportation et d’importation d’Odoo : https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html.

• Exécutez un import initial et consignez les identifiants créés et les identifiants source.
• Corrigez uniquement les lignes en échec et conservez leurs identifiants d’origine.
• Réimportez et comparez le nombre d’enregistrements avant et après.
• Testez délibérément une valeur modifiée sur un enregistrement existant.
• Testez délibérément une valeur vide sur un enregistrement existant.
• Vérifiez si les champs modifiés dans le CRM après le premier chargement sont conservés ou écrasés comme prévu.