Réussir sa reprise de données

Changer de logiciel, oui. Perdre ses données, non ! C’est tout l’enjeu de la reprise de données, une phase cruciale d’un projet de réinformatisation.

Quel que soit le logiciel documentaire (ECM, SAE, SIGB, Ged, etc.) (1), un projet de réinformatisation passe toujours par plusieurs phases : l’étude des besoins, les spécifications fonctionnelles et techniques, le paramétrage et le développement, la reprise de données et la recette. Parmi ces phases, l’un des facteurs-clés de succès du renouvellement de son application documentaire, paradoxalement sous-estimé par les équipes métier en charge du projet, est la reprise de données. Une bonne préparation de cette reprise est pourtant fondamentale : c’est l’un des postes budgétaires les plus importants dans le cadre d’une réinformatisation, parfois plus encore que le paramétrage ! Une bonne méthodologie est nécessaire pour éviter les écueils. Voici quelques conseils :

1 - clarifier le périmètre de la reprise

C’est la question primordiale de toute reprise de données : est-ce nécessaire de tout reprendre ? Avec le temps, et surtout dans le cas de systèmes déjà repris d’installations antérieures, certaines données constituent des reliquats dont l’intérêt est oublié de tous. Par exemple, avez-vous besoin de garder des fiches produits datant de plusieurs années et concernant des produits obsolètes ? Avez-vous besoin de conserver les profils de lecteurs n’ayant pas emprunté depuis cinq ans ? Faut-il réellement garder toutes ses versions du même document ou la version finale suffit-elle ? Indépendamment de contextes de sécurité particuliers, certaines données peuvent être effacées sans risque. Par exemple, la table des utilisateurs peut être nettoyée : pourquoi garder une trace dans le système des anciens collaborateurs qui ne sont plus dans l’entreprise depuis des années ? Si l’application n’est pas sensible, pourquoi garder les traces, ou fichiers de log, qui peuvent prendre une place très importante en base de données ? Certaines statistiques peuvent n’avoir aucun intérêt. Il peut arriver également, dans le cas de montée de version, que certaines données de gestion ne puissent pas être reprises. Un dialogue avec le fournisseur du nouveau logiciel doit permettre de lister les problèmes de ce type et d’agir en conséquence. N’oubliez pas : réduire le périmètre limite les risques d’erreur de reprise, les besoins de nettoyage et le temps nécessaire aux tests de reprise !

2 - estimez la volumétrie

Une fois que vous êtes fixé sur le périmètre de la reprise, estimez la volumétrie de vos données : combien de factures, combien de clients, combien de prêts, combien de documents, etc. Cette estimation doit porter sur le nombre d’enregistrements dans la table considérée et vous permettra d’élaborer les plans de tests nécessaires pour le nettoyage de vos données.

3 - nettoyez vos données

Nettoyez ce qui doit l’être ! Faites le tour de vos tables utilisateur, faites la traque aux doublons, le ménage dans vos scripts, vérifiez vos critères d’unicité s’ils doivent l’être, assurez-vous que les données obsolètes et inutilisées peuvent bien être supprimées… Attention aux liens entre les tables : dans le cas d’une application de gestion comptable, par exemple, il faut s’assurer qu’aucun fournisseur ou article présent dans une facture ou une commande ne soit supprimé. Cette opération de nettoyage, certes fastidieuse, facilitera grandement la reprise. Pour la réaliser, deux solutions :
- utiliser l’interface d’administration de votre outil pour nettoyer vos données table par table ;
- extraire vos données dans un fichier plat, appelé également fichier pivot, qui servira de base aux opérations de nettoyage. Ce fichier peut être de type CSV (comma separated values ou valeurs séparées par des virgules). Une fois les données nettoyées dans le fichier, celui-ci pourra être importé dans le système.

Dans le premier cas, il peut être utile de vérifier un nombre d’enregistrements aléatoire sur des tables diverses de l’application afin de déterminer plus finement les besoins en nettoyage. Les données incohérentes sur un champ, les informations parfois présentes et parfois non, doivent vous alerter : tout ce qui n’est pas cohérent indique un éventuel besoin de nettoyage. Le nettoyage de votre base de données peut être l’occasion de s’interroger sur la cohérence de certaines données. Par exemple, il peut être intéressant d’ajouter des contrôles sur certains champs : vocabulaire contrôlé sur un champ mot-clé, retravail sur le plan de classement, passage sur un langage normalisé de type Unimarc ou Dublin Core, etc. Chaque nettoyage doit bien sûr être suivi d’une nouvelle estimation de la volumétrie, car c’est cette dernière qui fera foi lorsque les données propres seront intégrées dans le système cible.

4 - déterminer la correspondance de vos champs

Il s’agit ici d’identifier à quels champs de votre future base de données (champs cible) correspondent vos champs actuel (champs source). On parle de mapping des données. Par exemple, un champ balisé « titre » dans un champ balisé « title ». Ce peut être aussi l’occasion de réunir les champs source qui peuvent l’être en un seul champ cible.  Cette phase est généralement réalisée par le prestataire de la nouvelle solution et nécessite votre validation pour toute opération.

5 - convertissez les champs le nécessitant

Selon la base de données utilisée, il faut déclarer le type de champ selon les données qu’il sera amené à recevoir. Par exemple, la métadonnée « date de création » doit être incluse dans un champ de type « date ». Les données texte dans des champs de type alphanumériques. La phase de conversion peut être également l’occasion de revoir la longueur de certains champs : certaines bases de données nécessitent de déclarer le nombre de caractères, ce qui peut aboutir à des données tronquées lorsque les informations sont trop longues.

Toute cette phase de conversion est réalisée par le prestataire avec votre validation.

6 - chargez les données

Cette phase est réalisée par le prestataire sur une base neutre. Plusieurs itérations seront peut-être nécessaires en fonction de la qualité des données d’entrée et de la volumétrie. Plus votre base de données est propre, meilleure sera la qualité de la reprise.

7 - testez et contrôlez

La responsabilité de cette phase incombe autant au commanditaire qu’au prestataire. Il s’agit de vérifier que les données source ont bien été intégrées dans le système cible. Pour le prestataire, le travail va se borner à une vérification de base des données : volumétrie - dispose-t-on du même nombre d’enregistrements qu’après nettoyage des données, ceci sur toutes les tables -, forme des données, champs de lien fonctionnels entre les tables, éventuellement encodage. Le commanditaire devra également vérifier ses données : sont-elles dans les bons champs ? Les contrôles jouent-ils leur rôle ? Peut-on enregistrer de nouvelles données sans risque pour l’intégrité de la base ? Comme il est généralement impossible de contrôler toutes les données, les tests se borneront à un échantillon de celles-ci. Cet échantillon sera établi en suivant une règle de vérification aléatoire sur un pourcentage des enregistrements d’une table. L’idéal est de distribuer la charge des tests entre tous les membres de l’équipe et de ne pas faire porter cette responsabilité sur le seul chef de projet, d’autant que cette phase peut se répéter selon le nombre d’itérations. Si la reprise présente un nombre d’erreurs trop important, et en conformité avec des règles contractuelles établies à l’avance, le prestataire devra procéder à une nouvelle itération de la reprise, le cas échéant en adaptant sa méthodologie. Cette phase de test est longue et fastidieuse, mais elle est fondamentale dans le projet. Elle ne doit pas être sous-estimée en termes budgétaires ou de temps de travail.

8 - basculer

Une fois que la reprise est jugée concluante, le fournisseur peut procéder à la bascule. Cette phase incombe au seul prestataire. Il s’agit de basculer définitivement les données de l’ancien système dans le nouveau système et de mettre le nouveau système en production. Une fois cette bascule réalisée, les nouvelles données seront enregistrées dans le nouveau système. Si vous en avez la possibilité, préservez votre ancien serveur - et surtout vos données source ! - quelques temps après cette bascule, afin de pouvoir comparer les données des deux applications si des problèmes de cohérence interviennent.

Baptiste Montoya Consultant Serda

(1) ECM, SAE, SIGB, Ged : gestion de contenu d’entreprise, système d’archivage électronique, système intégré de gestion de bibliothèque, gestion électronique de documents.

+ repères
enfin, soyez positifs !
La reprise de données est une phase critique, et le prestataire doit adapter sa méthodologie à votre contexte. Comme dans tout projet, un dialogue constructif et régulier avec ce dernier est nécessaire afin de coconstruire la préservation et le transfert de vos données.