La checklist avant une reprise de données ERP

1. Définir ce que la reprise doit contenir

Une reprise de données commence par une décision de périmètre. Quels clients et fournisseurs doivent être repris ? Faut-il conserver les tiers inactifs, les contacts secondaires et les anciens identifiants ? Qui valide ces choix ? Répondre à ces questions évite de nettoyer des colonnes inutiles tout en oubliant un champ indispensable.

La bonne sortie de cette étape est une liste des objets à reprendre, accompagnée d’un responsable métier. La liste doit préciser les exclusions et les points encore ouverts. L’absence de réponse n’est pas une règle de traitement.

2. Conserver un export source inchangé

Gardez une copie datée du fichier original avant toute modification. Travaillez sur une copie et conservez un identifiant de ligne stable. Si plusieurs exports alimentent la reprise, indiquez leur origine et leur date pour savoir quelle source fait référence en cas de conflit.

Les identifiants ne sont pas des quantités : évitez de les traiter comme des nombres. Un code avec un zéro initial peut changer lorsqu’il est importé dans un tableur. Vérifiez les paramètres d’import et les formats attendus avant de sauvegarder une nouvelle version.

3. Obtenir le modèle de l’outil cible

Demandez le modèle d’import correspondant à la version et au paramétrage de votre ERP. Deux projets utilisant le même éditeur peuvent avoir des champs obligatoires ou des référentiels différents.

Pour chaque colonne source, notez le champ cible, la transformation prévue et la règle si la valeur manque. Une colonne sans destination explicite ne doit pas disparaître par accident.

• Nom exact du champ et caractère obligatoire ou facultatif.
• Type attendu : texte, date, nombre, valeur d’une liste.
• Longueur maximale et formats acceptés.
• Règles de rattachement entre les tiers et les autres objets.

4. Séparer contrôles techniques et décisions métier

La longueur d’un code postal ou l’absence d’une colonne sont des observations techniques. Le choix du bon établissement, la fusion de deux comptes ou l’activation d’un fournisseur exigent souvent une connaissance du métier.

Un journal des écarts doit distinguer les corrections appliquées selon une règle convenue, les propositions à valider et les informations manquantes. Une donnée non vérifiable reste signalée ; elle n’est pas inventée pour faire disparaître une alerte.

5. Tester un lot représentatif

Avant l’import complet, prévoyez avec l’intégrateur un essai dans l’environnement adapté. Choisissez des exemples simples et des cas limites : établissement secondaire, caractères accentués, champ vide autorisé, relation entre plusieurs objets.

Comparez les données réellement créées dans l’outil avec le fichier attendu. Le nombre de lignes importées ne suffit pas : les identifiants, les rattachements et les champs sensibles doivent également être relus.

6. Préparer la validation et le retour arrière

Fixez un moment de gel de la source pour éviter qu’elle continue à changer pendant la reprise. Définissez qui donne le feu vert, où sont conservées les copies et comment revenir à l’état précédent en cas de problème.

Archivez ensemble le fichier source, le fichier préparé, les règles, les exceptions et le compte rendu de l’import. Cette traçabilité sera utile quand une question apparaîtra après la bascule.

• La source de référence est conservée et datée.
• Le mapping et les champs obligatoires ont été relus.
• Les doublons probables ont une décision ou un statut ouvert.
• Le lot d’essai a été validé dans l’outil cible.
• Le responsable de validation et la procédure de reprise sont définis.