Pictogramme représentant la Modernisation du SI

VOS BESOINS

Migration et Fiabilisation de Données

Quand parle-t-on de Migration de données et de Fiabilisation de Données (data cleansing) pour un Système d'Information?

Les projets de transformation de système d’information, appelés « migration » recouvrent deux typologies de projets très différentes. A savoir les Projets de modification d’un ou de plusieurs composant technique du système : OS, langage, base de données… et ceux de reprise de données qui impliquent la Fiabilisation des données ou data cleansing.

Pour les distinguer, nous parlerons de « conversion » dans le premier cas et réserverons le terme « migration » aux projets de « reprise de données » ou « migration de données » qui présente une composante fonctionnelle importante[1].

[1] Remarque : Certains projets touchant aux données sont exclusivement techniques et consistent à changer la codification des données (EBCDIC pour ASCII par exemple), le SGBD qui les supporte, etc… Ces projets sont souvent intégrés à une conversion. Nous parlerons dans ce cas de « conversion de données ». Ces projets, beaucoup plus simples, très différents des projets de migration de données, et ils n’impliquent pas forcément de volet de fiabilisation de données / data cleansing).

Le présent article a pour objectif de fournir un ensemble de clés aux décideurs et gestionnaires de projet afin de les aider à initier et gérer le mieux possible leur projet de migration de données. Il a été rédigé par l’équipe de MOVE Solutions, SSII spécialisée dans les grands projets de transformation de système. Il s’appuie sur plus 25 ans de projets réalisés avec une volonté de capitalisation méthodologique et technique.

Histoire et origine de la Migration et Fiabilisation de Données ou Data Cleansing

Les projets de reprise de données existent depuis le début de l’ère informatique. Lors du démarrage des premiers systèmes, il a bien fallu rentrer les données qui étaient gérées dans des dossiers papier. Ces reprises étaient bien entendu manuelles.

Les grands projets de migration de données – data cleansing tels que nous les connaissons aujourd’hui, ont débuté dans les années 80, dans le monde bancaire, lors de la mise en place de la seconde génération de système.

A cette époque, les programmes étaient réalisés à la main, sur la base des « squelettes » de programme que tout bon développeur peaufinait de projet en projet.

Quelques rares sociétés innovantes comme Cisi Transtec (dans laquelle nous avons fait nos premières armes) cherchèrent à industrialiser l’écriture des programmes de migration de la fiabilisation des données. Les premiers générateurs étaient nés. Ces outils étaient assez rudimentaires mais les gains par rapport à une approche manuelle déjà présent.

Au fil des années et de l’expérience des projets, nous avons enrichi et modernisé notre technologie puis l’avons ouverte vers les maîtrises d’ouvrage pour partager les résultats des travaux, faciliter et fiabiliser les recettes.

Aujourd’hui, les charges de développement ont été réduites de 70% et sur l’ensemble du projet, compte tenu des gains au niveau des MOA, le gain est proche de 85%. Les délais ont été divisés par deux. Les incidents post démarrage liés à une mauvaise qualité des données ont quasiment disparu des projets sur lesquels nous intervenons, grâce en particulier à des modules spécifiques de fiabilisation des données.

Petit précis du vocabulaire autour du thème de la Migration et de la Fiabilisation de Données ou Data Cleasing

Source : Système d’Information existant qui contient les données à reprendre.

Cible : Système d’Information cible que l’on doit charger à partir des données Sources de manière à ce qu’il soit en mesure de fonctionner convenablement.

Migration de données : On appelle migration de données, toute opération de transport de données entre environnements informatiques différents. Cette opération nécessite une transformation du modèle de données Source vers le modèle de données Cible.

Capture : Prise d’empreinte des données de production Source.

Déchargement : Extraction des données Source du SGBD ou mise à plat. Cette opération peut nécessiter la réalisation de programmes pour certains types de SGBD réseau ou hiérarchiques.

Transfert : Transfert des données entre machines. Par exemple entre la machine Source et la machine Cible. Cette opération peut être très longue en fonction de la volumétrie des données.

Conversion des données : Passage de la codification Source à la codification Cible. Exemple passage de EBCDIC à ASCII.

Filtrage : Traitement permettant de sélectionner les données à reprendre à partir de critères fonctionnels (Exemples : profondeur d’historique, typologie de contrat, etc)

Audits de données : (le plus souvent Source) de manière à fournir des informations sur les valeurs possibles. On parle alors de profilage des données (Profiling). Les audits peuvent également porter sur des vérifications de règles fonctionnelles (règles d’intégrité, de gestion, etc) de manière à anticiper les problèmes de qualité de données ou les règles de migration particulières à mettre en œuvre. On parlera alors d’Audits Fonctionnels.

Les Audits fonctionnels permettent d’identifier les données Sources à réhabiliter.

Fiabilisation de données ou réhabilitation (Data cleansing) : On appelle fiabilisation de données ou data cleansing la correction manuelle ou automatique des données. Cette fiabilisation de données ou data cleansing peut aussi être réalisée de manière spécifique et en dehors d’un projet de migration de données.

Enrichissement : Saisie d’informations non gérées dans la Source et nécessaires au fonctionnement de la Cible.

Bascule : Opération de transfert de la gestion supportée par la Source vers la Cible. Cette opération, effectuée le plus souvent en week-end, doit permettre d’assurer une continuité de service.

Plan de bascule : Description de toutes les opérations devant être effectuées pour transférer les données de la Source à la Cible. Le plan de bascule intègre les traitements à passer sur la Source avant la capture des données et également ceux à passer sur la Cible après le chargement des données.

Répétition ou Bascule à Blanc : Opération de répétition des opérations de bascule dans des conditions réelles de manière à roder le processus de bascule.

Ecarts fonctionnels : Fonctionnalités manquantes dans la Cible par rapport aux fonctionnalités de la Source et/ou aux besoins des utilisateurs.

Réduction des écarts fonctionnels : Développement des fonctionnalités manquantes. Cette opération peut être longue et modifier de manière substantielle le modèle de données Cible.

Maintenance règlementaire : Modification d’un système (Source ou Cible) rendue impérative par la modification de la législation.

Les recettes:

Plan de recette : Ensemble des opérations de vérifications nécessaires pour qualifier un système. Le plan de recette décrit les tests à effectuer ainsi que les cas fonctionnels sur lesquels ces tests seront effectués.

Recette statique : vérification des données migrées à travers l’applicatif cible chargé, en utilisant les fonctions TP de ce dernier. Par extension, on appelle parfois recette statique, la vérification des données migrées avant chargement.

Recette dynamique : Vérification du fonctionnement du système cible chargé des données migrées en exécutant des traitements selon un plan le plan de recette.

Mapping des données : Mise en correspondance des données Sources et Cibles. Définition pour chaque donnée Cible de la règle permettant de la construire à partir des données Sources. Les règles sont de complexités très variables, depuis un simple « move » (affectation) jusqu’à des algorithmes complexes. La difficulté de la migration est liée au nombre de règles complexes.

On parle de volumétrie pour deux types d’informations très différentes :

Volumétrie : Nombre d’enregistrements à migrer ou volume (en Go) occupé par les données à migrer. La volumétrie détermine les temps de traitements des programmes de migration, mais aussi influe sur la complexité. En effet, plus il y a d’occurrence dans une base, plus il y aura de règles de migration différentes.

Volumétrie : Nombre de données cible élémentaires (propriétés ou rubriques) à alimenter et nombre d’entités (Tables ou fichiers) les contenant. La charge de conception et de réalisation dépend de la volumétrie.

Fusion : Opération de fusion des données provenant de plusieurs entités de gestion pour n’en faire qu’une seule. Cette opération implique une harmonisation du paramétrage, du dédoublonnage, de la renumérotation…

Dédoublonnage : Suppression des doublons fonctionnels (exemple personnes physiques en n-uplet dans un système). Cette opération nécessite d’une part d’identifier les doubles de manière certaine mais également de rattacher toutes les informations les concernant à un seul dossier. Peut aussi faire partie d’une approche de fiabilisation de données ou data cleansing.

Multi-Migration : Migration successive vers une même cible. Dans le cas de multi-migration on s’efforcera de capitaliser pour rendre les projets de plus en plus économiques.

Volumétrie Echantillon : La liste des dossiers Source caractéristiques sur lesquels on souhaite rôder les règles de migration.

Volumétrie réelle : Totalité du périmètre Source éventuellement filtré.

Et pour finir:

Run : Exécution de la chaîne de migration. On parlera de Run ou de Migration échantillon ou en volumétrie réelle suivant le cas

Chargeur : Ensemble de programmes destinés à simplifier et sécuriser le chargement d’un système cible. Le chargeur ou Kit de migration contrôle les données qui lui sont présentées au travers des « pivots » et rejette les données qui ne satisfont pas les règles d’intégrité de la cible. Le chargeur permet aussi de limiter le nombre de données élémentaires à migrer en assurant les dénormalisations du modèle de données cible et la construction par traitement de certaines informations.

Rejets : Liste des données rejetées par le chargeur comme incohérentes ou non intègres.

Contexte des projets de Migration et Fiabilisation de données

Dans quels cas rencontre t-on un projet de migration et fiabilisation de données ?

Les projets de migration et fiabilisation de données (ou data cleansing) se rencontrent dans les cas suivants :

Mise en place d’un progiciel
Déploiement d’un nouvel applicatif
Rapprochement entre deux ou plusieurs entités de gestion qui décident d’harmoniser leurs systèmes d’informations et choisissent un système unique. Il sera souvent parfois nécessaire dans ce cas de procéder à des fusions.
Alimentation d’une base infocentre ou datawarehouse.
Etc…

Quel est l’enjeu de votre Projet de Migration et Fiabilisation de Données?

Votre projet de Migration et Fiabilisation de Données consiste à transporter vos données depuis votre ancien environnement vers votre nouveau système qui dispose d’un modèle de données et de règles de gestion totalement différentes.

Dans un délai et un budget limités, vous devez alimenter les nouvelles structures de données conformément à leurs règles d’intégrité propres.

Migrer vos données vers votre nouveau système ou un progiciel sans rupture de votre activité est un projet à part entière dont la complexité est souvent sous-estimée.

Le système source n’est souvent maîtrisé que par un petit nombre de « sachants » qui sont, la plus part du temps déjà des ressources critiques sur le projet de mise en œuvre de la solution cible,
La cible est mouvante en raison des adaptations apportées au modèle de données cible dans le cadre de la réduction des écarts fonctionnels,
Par conception, les nouveaux systèmes sont moins permissifs et nécessitent une haute qualité de données ainsi que des informations qui n’étaient pas peut être pas gérées ou mal gérées dans la source: Un coûteux chantier d’enrichissement et de fiabilisation des données, mobilisant fortement les maîtrises d’ouvrages est ainsi nécessaire.

Les éléments structurants d’une migration et fiabilisation de données

Les éléments structurants d’une migration de données avec ou sans data cleansing sont :

Nombre de données à alimenter. C’est-à-dire le nombre de tables et de colonnes du modèle de données Cible ou dans le cas d’un chargeur, le nombre de fichiers et de rubriques des pivots en entrée du chargeur.
Complexité des règles de gestion
Volumétrie : Nombre de dossiers par typologie et espace disque occupé par les données Sources
Planning de déploiement de la nouvelle application.
Disponibilité des « sachants » source et cible

Apprécier la complexité d’une migration n’est pas chose facile. Les données descriptives sont les plus simples à reprendre.

Certains facteurs rendent mécaniquement plus complexe le projet. Notamment :

La durée de vie des données de gestion : Au fil du temps, les règles de gestion changent, ne serait-ce qu’en raison de la modification des contraintes réglementaires. Ainsi, des données anciennes auront été créées dans la source, avec des règles de gestion différentes de celles correspondant à des données plus récentes. Par exemple, des données Retraite seront utiles plus de 40 ans alors que des données relatives à des remboursements médicaux pourront être écartées du périmètre après 26 mois (validité d’une feuille de soin). Ainsi plus les données s’étirent dans le temps, plus il y aura de cas particuliers à traiter.
Le nombre de données calculées ou entrant dans des calculs : Les données calculées par le système source et stockées dans celui-ci devront être cohérentes avec les règles de calcul implémentées sur la cible. Par exemple, dans un système de gestion de crédits, les tableaux d’amortissement devront être semblables sur la cible, de manière à ne pas léser ni le prêteur, ni l’emprunteur. Même si les différences peuvent paraître négligeables, elles ont des conséquences importantes :
- Un delta de 1 centime sur une échéance mensuelle d’un prêt sur 15 ans peut totaliser 1,80€, ce qui sur un portefeuille de 500 000 prêts peut représenter 900 000 €.
- Ce centime d’écart générera des questions d’un certain nombre de clients qui devront être gérées par les chargés de clientèle.
Le nombre de dates qui pilotent des processus de gestion et dont la cohérence globale devra être respectée.
Les données détournées. Dans les systèmes anciens, il n’est pas rare que des zones diverses voire des « mémo » soient utilisées pour palier à des manques fonctionnels. Un nouveau système plus complet intégrera vraisemblablement les fonctions manquantes et les données devront être récupérées à partir d’informations non structurées.

Le contexte des Projets de Migration et fiabilisation de Données:

Les projets de migration de données avec data cleansing sont intégrés dans un programme plus global comprenant :

La fabrication ou la mise à niveau du système Cible
La maintenance de la source
Les chantiers de fiabilisation ou d’enrichissement des données.
La conduite du changement

Ces filières impactent fortement le projet de migration de données, notamment les travaux sur le système cible qui touchent le modèle de données et les règles de gestion.

Il convient de mettre en place un process industriel et agile pour prendre en compte rapidement et efficacement les modifications dictées par les chantiers connexes à la migration.

Schéma de Macro Planning d’une Migration:

Projet de Migration de Données - Data Migration: Schéma d'un Planning-Type pour réussir une bonne migration de données! - Voir aussi Fiabilisation de données Data Cleansing

Reprise manuelle ou par programme ?

Cette question doit être posée pour chaque système et chaque typologie de données à reprendre.

Le choix dépend principalement des critères suivants :

Volumétrie des données à reprendre : Au-delà de 500 occurrences, il est souvent plus économique de réaliser une reprise automatique
Délais disponible pour la reprise manuelle : Il est nécessaire de disposer d’une fenêtre de temps suffisante pour saisir les données.
Complexité des règles de reprise à mettre en œuvre relativement à la volumétrie en jeu.
Criticité des données : La reprise manuelle est moins fiable qu’une reprise automatique et il est plus difficile de tracer les opérations.
Confidentialité des informations à reprendre.

Comment réussir une Migration de Données?

Le process de migration

Les grandes étapes d’un projet de reprise de données sont :

Cadrage	Définition du périmètre cible et source Planning
Lotissement	Découpage du projet en lots fonctionnels Ordonnancement des lots
Audit de données	Profiling et analyse des données sources candidates à la migration.
Spécifications générales	Définition de la stratégie de migration par lot Définition des conditions de création des occurrences cibles Identification des données sources nécessaires pour alimenter un lot
Spécifications détaillées	Mapping des données
Réalisation	Réalisation des chaînes de migration
Recette statique	Chargement de l’application cible et utilisation des fonctions TP pour vérifier les données migrées.
Recette dynamique	Exécution de traitements sur la cible pour valider son bon fonctionnement
Répétitions et Bascule	Répétitions des opérations de bascules Bascule

Le projet comprend deux grandes phases :

1°) On réalisera une 1ere version de la chaîne de migration. Cette chaîne sera exécutée et les données cibles produites chargées dans l’applicatif.

2°) La phase dite « d’accompagnement à la recette » débute alors. Durant cette phase, on itérera sur les étapes 4 à 8, jusqu’à converger vers une qualité optimum.

Toutes les anomalies de données détectées doivent être corrigées le plus rapidement possibles pour ne pas retarder la poursuite des opérations de recette.

Les anomalies peuvent être causées par :

Cas des anomalies externe à la migration de données : Bug applicatif cible ou paramétrage incorrect
Pour ce qui est des anomalies de données sources qu’il convient de fiabiliser dans la source ou par des règles de migration particulières
Pour finir les anomalies de migration : Bug dans les programmes de migration ou règle de migration à modifier.

En pratique, on constate que les règles de migration sont amenées à être revues fréquemment. Il est nécessaire de mettre en place un process de suivi des demandes de modification et une organisation industrielle permettant d’implémenter ces modifications de manière très efficace.

Le processus étant par la force des choses itératif, il est judicieux de le prévoir comme tel dés le début du projet.

Les erreurs a ne pas commettre pour réussir sa Migration de Données

Sous-estimer la reprise des données : La reprise des données et un projet à part entière qu’il convient de ne pas négliger. On a toujours l’impression que l’on maîtrise et que l’on a le temps.

Nos meilleurs clients ont déjà fait une migration tout seul avant…

Partir trop tard : Le chantier de migration doit débuter en même temps que le projet de développement ou d’intégration.
- Sortir la migration de données du chemin critique
- Anticiper sur la fiabilisation des données
- Fournir aux développeurs travaillant sur le système cible des données de test exhaustives
- Favoriser l’implication des utilisateurs qui est meilleure s’ils retrouvent leurs données lors des phases de recette des applicatifs.
Ne pas anticiper la qualité des données source: Les nouveaux systèmes sont par conception beaucoup moins permissifs et ils nécessitent souvent des informations qui ne sont pas gérées dans la source. Ces informations manquantes ou non intègres peuvent bloquer la reprise et retarder notablement le démarrage avec une inflation très importante du coût global du projet.
Penser que l’on trouvera les bonnes règles de migration du premier coup : Il est coûteux de vouloir spécifier juste du premier coup : On passe beaucoup plus de temps à chercher à imaginer tous les cas alors qu’il est plus efficace et économique de traiter vite les cas les plus courants qui représentent 80 % du périmètre et itérer ensuite pour compléter les règles les plus complexes.
Estimer que l’effort de développement de la migration peut être lissé sur la durée du projet. La phase de développement de la première version doit être la plus concentrée possible de manière à permettre le début de la recette de l’application cible chargée des ses données. Ensuite, durant toute la phase de recette, on devra modifier entre 30% à 100% des règles spécifiées initialement. De la capacité à recycler vite ces modifications dépendra le respect du planning de démarrage.
Ne pas mobiliser les MOA.

Les bonnes pratiques pour la Migration et Fiabilisation de Données

« Mettre la cible au centre » : Il est indispensable de s’approprier la cible et ses règles de gestion. On cherchera à construire des données cibles intègres, respectant les concepts cibles et non à faire rentrer ses données sources.
Anticiper les problèmes de qualité de données : La fiabilisation et l’enrichissement des données sont sur le chemin critique du projet et il faut comprendre que le data cleansing est crucial.
Automatiser tout ce qui peut l’être : Les captures de données, les chargements, l’exécution de procédures de contrôles, etc… sont des opérations récurrentes qu’il convient d’automatiser pour alléger la charge et éviter les erreurs.
Partager les informations entre tous les acteurs du projet.

Comment optimiser les délais, les coûts et la qualité des données?

Les points centraux sont :

Le partage des informations entre tous les acteurs du projet notamment en ce qui concerne les règles fonctionnelles mises en œuvre. Des outils adéquats permettent de normaliser la gestion et le partage des informations.

La fluidité des développements et des modifications ainsi que la capacité à fournir des indicateurs permettant de mesurer la qualité de la migration.

Dans quel cas sous-traiter une Migration et Fiabilisation de Données?

Comme dans tout projet informatique, l’appel à la sous-traitance sera réservé aux situations suivantes :

Manque de disponibilité des ressources internes
Planning projet nécessitant une productivité accrue dans un délai court,
Manque de compétence des ressources internes,
Sécurisation du processus de migration,
Besoin d’outillage dédié.
Contraintes budgétaires

Les écueils sont nombreux dans un projet de migration de données et nombre d’options se révèlent de « fausses bonnes idées ». Se faire accompagner par un prestataire spécialisé est une option gagnante.

Sous-traiter la migration qui est un projet exceptionnel et « jetable » par excellence, permet de concentrer ses équipes internes sur l’appropriation de la cible.

Que faut-il pour outiller une Migration avec une Fiabilisation de Données?

Outiller une migration de données est maintenant entré dans les usages en raison des gains sur les coûts, délais et la qualité des données. En effet, les outils sont également un bon moyen de gérer les risques projet et ce n’est donc pas par hasard que tous les grands projets de migration depuis 20 ans ont été outillés.

Le développement d’outils de migration de données requière des savoir-faire rares et très peu d’outils existent. Les ETL, conçus pour l’alimentation de datawarehouse, sont parfois utilisés dans des projets de reprise de données.

Ces outils générant du SQL ont des performances inadaptées quand les volumétries en jeu sont importantes. Il est facile d’implémenter des règles simples, mais la mise en œuvre de règles complexes est beaucoup plus difficile.

Par ailleurs, la modification fréquente des règles est également coûteuse.

Nous préconisons donc l’usage d’une solution dédiée aux projets de migration de données.

Outiller une migration avec Move Solutions, d’autant plus avec du data cleansing

Très peu d’outils dédiés à la migration de données existent et les membres de nos équipes de R&D sont à l’origine de la plupart d’entre eux.

Nous avons pu mesurer l’avance technologique dont dispose notre solution Recode Data à l’occasion de benchmarks réalisés par nos clients lors de leurs appels d’offres.

Conclusion

Nous espérons vous avoir permis de mieux appréhender votre projet de migration de données.

Nos équipes sont à votre disposition pour vous présenter dans le détail la valeur ajoutée de nos offres et la puissance de notre technologie.

Nous nous engageons sur le prix et les délais de votre projet, sachant que MOVE Solutions travaille au forfait et rend des engagements sur les délais.

Pourquoi ne pas comparer ?