Une tâche assez récurrente dans nos activités de développement web concerne l’importation de données. Que l’on mette en place une solution basée sur WordPress, Dolibarr, ou tout autre système relié à une base SQL, nous avions tendance  à sous estimer la tâche d’importation des données existantes. L’expérience nous a montré que l’import de données pouvait se révéler assez chronophage, très délicate, et nous avons mis en place une procédure permettant d’accélérer et de sécuriser cette phase, en nous aidant de différents scripts que nous avons créé.

Procédure d’import de données

Voici le découpage de la procédure que nous avons mis en place pour cette tâche d’import de données :

  1. Définir les données à importer
  2. Corriger les données d’origine
  3. Adapter les données au nouveau système
  4. Recréer des liens croisés.
  5. Tester le nouveau système.
  6. Relier ancien et nouveau système

Exemples de tâches d’import de données

Récupérer à partir d’un fichier CSV les fiches de renseignement concernant 15000 personnes , un autre fichier CSV renseignant 50000 factures liées à ces personnes, et importer cela dans l’ ERP/CRM Dolibarr.

Récupérer un site ancien et comportant un annuaire de personnes, des galeries d’images, des agendas, des factures d’adhésion au site, et importer ces données dans un système WordPress équipé du logiciel de réseau social BuddyPress, du logiciel de gestion d’événement et de lieux Event Manager, du logiciel de gestion d’images RTmedia et du logiciel de facturation/gestion des autorisations Paid Member Pro (nous sommes spécialisés dans toute ces solutions).

Ce type d’import  exige la mise en place de la procédure étape par étape .

Définition des données à importer

La première étape consiste à donner une typologie aux données. Les données seront traitées différemment selon leur type, comme par exemple les noms, les adresses, les mails, les liens web, les dates, les fichiers, les prix, les indexs, les listes, etc. qui peuvent être transformés selon des méthodes propres.

Bien définir le type de données à importer permettra de prévoir la nature des transformations à appliquer à ces données.

Correction des données d’origine

Le transfère de données vers un nouveau système est l’occasion de corriger ces données. Il serait dommage d’intégrer dans un système neuf des données erronées, obsolètes ou mal formatées. C’est souvent le cas.

Par exemple, récupérer un fichier ancien, c’est souvent découvrir que des mails sont obsolètes, des adresses web aussi, que des adresses ont été rentrés d’une manière non uniforme (adresse complète dans une colonne pour certaine fiches, ou répartie sur plusieurs colonnes pour d’autres fiches) , qu’il y a  des données obsolètes ou incomplètes, qu’il y a des doublons de données, qu’il faut créer ou revoir les catégories, que du HTML est non sécurisé, etc.

Cet étape est d’autant plus évidente quand il s’agit de récupérer des données anciennes, ou des bases de données alimentées par de nombreux utilisateurs.

Un cas fréquent est aussi de récupérer des données dans divers systèmes, comme par exemple, de vérifier la validité d’un mail en allant interroger une autre base de données, et importer ce mail.

Il s’agit donc, dans un premier temps, de tester les données d’une base de données afin de repérer les anomalies, puis de les corriger.

Cette phase s’accomplie grâce à l’utilisation de scripts qui vont vérifier et corriger automatiquement certaines données, comme par exemple tester des liens web, ajouter des majuscules aux noms, vérifier l’orthographe des villes ou la validité des codes postaux, etc. Notre banque de scripts permet toute sortes de vérification/manipulation de ce type.

Cependant, il ne faut pas négliger dans cette phase l’importance des vérifications/manipulations humaines. Cette tâche de vérification humaine est d’autant plus lourde que la base de donnée à traiter est étendue. Même si les scripts peuvent souvent régler la grande majorité des anomalies, certaines ne peuvent être repérées et corrigées que par une intervention humaine.

Par exemple, une base de données d’adresse mise à jour par de nombreux utilisateurs produira nécessairement des fautes d’orthographe ou des inexactitudes, que les scripts régleront à 80%. Sur une base de 10000 adresses, ça laisse 2000 adresses à traiter humainement, ce qui peut demander 20 jour/homme de vérification/correction.

Ainsi, il est primordial de bien estimer ce poste « vérification/correction humaine » dès le départ, en faisant une bonne estimation de cette tâche. Il sera ainsi plus facile de la prendre en charge, soit en interne, soi via des services de micro-tâche comme Turk Mechanical d’Amazon

Adaptation des données au nouveau système

Cette étape consiste à envoyer ces informations dans la nouvelle base via des scripts qui récupèrent les données de la base corrigée et qui les adapte aux différentes parties de la base de données du nouveau site.

Pour cette tâche, il s’agit d’une part de repérer les tables qui seront impactées dans le nouveau système, et de définir précisément comment ces tables sont modifiées quand on importe une nouvelle donnée.

D’autre part, la phase d’adaptation des données permet  de déterminer le formatage des données accepté par ce nouveau système.

Les scripts se chargent alors de récupérer les données de l’ancien système, de les transformer pour qu’il soit adaptés, puis de les injecter dans les différentes tables du nouveau système.

Ce processus, au niveau de chaque données, peut consister par exemple à adapter le formatage des dates, à renommer des noms de fichiers spécifiés en table, à tronquer des informations trop longues, à remplacer des données absentes, à adapter les anciennes régions aux nouvelles régions, à déduire un nom de département en fonction d’un code postal, etc.

Au niveau des tables, cela peut consister à créer de nouvelle rangées dans des tables, à ajouter des meta-données sous forme de Json, à mettre des données qui étaient en colonnes en rangée, ou inversement, des donnée qui étaient en rangées en colonnes.

Par exemple, l’import d’un fichier d’adresse dans un système WordPress Buddypress va exiger le modification des tables user, usermeta, bp_x_profil, posts et postmeta du nouveau système, où il faudra parfois créer des listes sous forme Json et les mettre en table, et cela va s’étendre à une dizaine de tables pour peu que l’on utilise aussi des logiciels de paiement, de e-commerce, de gestion d’événement et de lieux ou autre.

Cette phase d’adaptation des données va impacter la nouvelle base de données, mais aussi son système de fichier, dans le cas où on a besoin d’importer des fichiers dans le nouveau système. Ainsi, c’est dans cette phase que vont par exemple être intégré les médias, qu’il s’agira de copier au bon endroit du nouveau site, avec le bon nom de fichier, et éventuellement effectuer des réglages sur ces médias (taille de l’image par exemple).

Recréer des liens croisés.

Souvent, il s’agira aussi de créer de nouveaux liens entre les données, en particulier quand on récupère des bases de données non-relationnelles.

Par exemple, si on a deux fichiers avec dans l’un des factures, et dans l’ autre  des adresses de client, sans qu’un index reliant ces deux bases soit défini.

Un autre exemple que l’on a eu a traité est de récupérer une liste de lieux dans un tableur comportant des milliers d’événement, où pour chaque événement un adresse était défini en colonne. Il s’agit alors de récupérer les adresses dans une base différente, et de lier les événements à l’index de celle base de lieux, de sorte qu’il soit possible de repérer les différents événement ayant lieu dans un lieu.

Là aussi, aidé de scripts, il s’agira de recréer des liens entre les données, par exemple, en se basant sur des données communes, comme le nom ou l’email ou la position géographique.

Test du nouveau système.

Après l’import de données, il convient de tester convenablement le nouveau système. C’est lors de cette phase que l’on peut encore découvrir des données à corriger, des doublons, etc. que les méthodes précédentes n’avaient pas vu.

Par exemple, on peut repérer visuellement, une adresse  mal été rentrée si une fois mise sur une carte de type Google Map, le point apparaît visiblement mal placé. Ou alors, on peut encore débusquer un nom de ville en doublon, ayant une orthographe différente (par exemble, « Brive » et « Brive-la gaillarde » sont une seule et même ville, mais orthographiés de deux manières différentes) si dans une liste des villes du département ce doublon apparaît clairement .

Cette phase de test consistera aussi à repérer les pages absente (« erreur 404 ») ou les données qui n’aurait pas été correctement formatées.

La phase de test sera réduite si la phase de correction de données de départ et la phase d’adaptation ont été bien menées. Mais dans de nombreux cas, les scripts et l’analyse en amont vont  régler la plupart des problèmes, et les quelques omissions vont alors apparaître plus clairement dans cette phase de test.

Ainsi, vérifier attentivement un lot de fiches pour repérer les éventuelles anomalies et définir leur fréquence, vérifier les différents index disponibles pour l’utilisateur du site, puis appliquer des correctifs, est une tâche qu’il faut planifier.

Relation ancien-nouveau système

Cette phase d’import de donnée ne doit pas faire perdre la relation avec l’ancien système. Il faut ainsi conserver une norme d’indexage permettant de faire le lien entre l’ancien et le nouveau système, ceci pour deux raisons essencielles :

La première est qu’il il faut être en mesure de modifier le système d’import même une fois les données importée, dans le cas où il faudrait apporter des correctifs. Il faut donc être en mesure de renouveler l’import, et de vérifier les données d’origine.

La seconde raison essentielles est qu’il s’agit de réorienter les anciennes données vers les nouvelles, principalement pour rediriger les liens de l’ancien système vers le nouveau (redirection permanente), ce qui est essentiel pour conserver son référencement dans le cas d’un site web.

Il s’agira donc de créer des scripts et des procédures permettant de réimporter les données, de vérifier les données d’origines, et d’envoyer les utilisateurs sur les nouvelles fiches.

Conclusion

L’importation de données dans un nouveau système peut demander de nombreuses ressources en temps et en compétences, et peut s’avérer assez délicate, car les données sont traitées en masse et aussi, par l’intervention humaine.

La procédure en six grandes étapes que nous proposons permet de bien évaluer cette tâche d’importation en terme de ressource à déployer, et l’utilisation de scripts permettant de vérifier/corriger/valider les données donne la possibilité d’accélérer ce processus, et de le sécuriser.

Ainsi, une tâche d’import de données peut demander d’une journée de travail, par exemple pour l’import des articles d’un système type Joomla à WordPress (il existe des scripts spécialisés pour cette tâche), mais peut aussi demander 10 jours dans le cas où il faut intervenir sur ne nombreuses tables, et plus s’il s’agit d’apporter de nombreuses corrections à une base de donnée existante.

Seule une analyse au cas par cas permet de fournir une estimation précise.