Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Migration de données
  3. Étude initiale
Extrait - Migration de données D'un Système d'Information à l'autre : la démarche complète (2e édition)
Extraits du livre
Migration de données D'un Système d'Information à l'autre : la démarche complète (2e édition) Revenir à la page d'achat du livre

Étude initiale

L’importance d’un bon démarrage

L’étude initiale (appelée également phase de cadrage) doit permettre de préciser les éléments suivants :

  • le périmètre du projet ;

  • la démarche utilisée ;

  • l’équipe projet ;

  • les intervenants ;

  • les environnements techniques ;

  • les comités ;

  • les charges ;

  • le planning ;

  • l’organisation des livrables ;

  • les outils mis en place pour gérer les différentes phases du projet.

Tous ces éléments sont essentiels pour bien lancer un projet de migration de données.

Cela semble être une évidence, mais la mise en pratique est souvent difficile car :

  • Le périmètre du projet n’est pas toujours très bien défini.

    Les grands domaines de données à reprendre sont connus, mais cela ne suffit pas pour définir le budget.

  • La démarche d’un tel projet n’est pas habituelle.

    Les entreprises savent mener des projets de développement d’applications, mais les opérations de migration sont suffisamment peu fréquentes au sein d’une même entreprise, pour qu’elles mettent en place une méthodologie et des outils réutilisables par la suite.

  • L’équipe projet n’est pas constituée.

    En effet, le chef de projet initialise le projet et ne connaît pas encore les ressources...

Le périmètre du projet

Il est essentiel dès le lancement du projet de migration des données, de préciser le périmètre des données reprises.

C’est à partir de cette validation que l’on peut déterminer la charge et le planning, ainsi que les ressources nécessaires pour mener à bien le projet.

On s’attachera à construire des schémas qui pourront être repris lors des réunions de présentation du projet, en interne pour les membres de l’équipe projet et en externe auprès de tous les intervenants, partenaires et décideurs.

Images/ADP02-01.PNG

Un premier schéma général permet de visualiser le contexte du système source et celui du système cible.

On y fait apparaître :

  • les machines sur lesquelles sont exploitées les données ;

  • le type de SGBD ;

  • toutes les informations permettant de situer le contexte (le nom des bases, des applications...).

On recense ensuite l’ensemble des tables cible, en précisant :

  • à quel lot se rattache la table (le lotissement fonctionnel aura été effectué au préalable) ;

  • si la table est alimentée par un programme de migration ou si elle est chargée par un autre processus.

    Par exemple, on peut envisager de charger des données du système cible en exécutant un programme d’interface...

La démarche

La démarche se décompose en plusieurs phases :

Images/ADP02-05.PNG

Ces trois phases sont détaillées par la suite dans des chapitres spécifiques.

L’objectif de la phase de cadrage est de définir la méthodologie qui sera utilisée, en définissant les grands axes.

Les spécifications des règles de migration

Pour réaliser correctement les spécifications des règles de migration, il est nécessaire d’associer trois profils :

Images/ADP02-06.PNG
  • Un expert MOE (maîtrise d’œuvre) du système source qui a la connaissance informatique du système source.

  • Un expert MOE du système cible qui a la connaissance informatique du système cible.

  • Un expert métier.

Ces trois ressources seront pilotées par un animateur dont le rôle est :

  • d’animer et cadencer les réunions de spécification des règles de migration ;

  • de recueillir les besoins ;

  • de spécifier et rédiger les règles de migration suivant les indications de la MOA (maîtrise d’ouvrage) et de la MOE.

L’objectif de cette phase est de définir les règles d’alimentation des données du système cible à partir des données du système source.

On a vu plus haut qu’il faut lotir le projet, ce qui permet de démarrer rapidement un premier lot de spécifications, puis ensuite de paralléliser les lots.

La réalisation des programmes de migration

Dans cette phase, on choisira les technologies qui vont être utilisées pour la réalisation des programmes de migration, à savoir :

  • le matériel (gros système ou serveur) ;

  • le logiciel (COBOL, ETL, SQL, Java ou autres...).

On va également définir si les ressources affectées à ces tâches seront :

  • internes à l’entreprise ;

  • externes en régie, c’est-à-dire ressources individuelles de sociétés de services informatiques, mises à disposition du chef de projet ;

  • externes intervenant en mode forfait, c’est-à-dire pilotées par une société externe avec un engagement de résultats.

Ces trois types d’affectations sont les plus courants.

Il existe d’autres configurations d’équipe qui mixent les trois.

Le choix de telle ou telle formule dépend de plusieurs critères :

  • Interne : l’entreprise doit avoir du personnel compétent et disponible.

    Souvent, les salariés de l’entreprise sont affectés sur d’autres projets en cours, ou bien n’ont pas les compétences nécessaires.

    Les technologies évoluant tellement vite, il est difficile pour une entreprise d’avoir des collaborateurs formés sur les nouveaux langages et matériels.

  • Externe en régie : il faut dans...

La Certification Statique

La Certification Statique est une étape de contrôles, en aval du process de migration.

Elle est systématiquement négligée au démarrage du projet car elle semble bien lointaine, étant donné que beaucoup d’autres opérations sont à mener avant d’y arriver.

On verra, dans le chapitre Spécifications, qu’elle doit être préparée très en amont du process, dès l’étape de spécifications.

En effet, c’est lorsque l’on spécifie les règles de migration, que l’on est le plus à même de définir en parallèle les contrôles qu’il faudra exécuter par la suite.

Ces contrôles sont deux types :

  • Contrôles quantitatifs (ou contrôles de masse), qui garantissent que l’ensemble du stock de données a bien été repris dans le nouveau système.

  • Contrôles qualitatifs (ou contrôles d’échantillon), qui permettent de vérifier que ces données ont été migrées correctement.

La démarche proposée se décompose en tâches nécessitant l’intervention de ressources que l’on peut classer en deux catégories :

  • l’équipe projet ;

  • les intervenants externes.

Les livrables

La notion de livrable est à définir dès le démarrage du projet.

Elle correspond aux éléments indispensables pour pouvoir démarrer une phase et devant être fournis en sortie de phase.

On se reportera au chapitre Les fiches de synthèse pour avoir une indication sur les principaux livrables généralement produits sur un projet de migration.

L’équipe projet

Dans l’équipe projet, on intègre les ressources suivantes :

Tâches

Ressources

Pilotage

Chef de projet

Spécifications

Analyste (animateur)

Expert système source (MOE)

Expert système cible (MOE)

Utilisateurs (MOA)

Réalisation

Développeurs

Spécialiste environnement de développement

Certification Statique

Animateur

Utilisateurs (MOA)

Développeurs outils de certification

Les intervenants

Les intervenants sont toutes les autres ressources dont le projet va avoir besoin pour sa réalisation.

Il s’agit essentiellement :

  • d’experts métier que l’on fait intervenir ponctuellement sur des sujets très spécifiques ;

  • des ressources exploitation sollicitées pour mettre en production les programmes de migration et pour exécuter les tâches de déchargement/rechargement, sur le système source et sur le système cible ;

  • des ingénieurs système, qui interviennent sur la problématique des temps de traitement de la chaîne de migration ;

  • des DBA (DataBase Administrator) qui gèrent les environnements techniques mis à disposition du projet ;

  • des développeurs qui vont réaliser divers outils nécessaires pour la reprise.

Les environnements techniques

Ce sujet est toujours compliqué à traiter car les besoins en matière d’environnements sont rarement bien définis en début de projet, du fait même que l’on ne maîtrise pas souvent tout le process de migration de données.

Le chapitre Environnements techniques qui aborde cette problématique détaille ces besoins.

Il faut néanmoins dès le début du projet consacrer du temps pour préciser les besoins et travailler avec les responsables techniques pour leur expliquer les attentes du projet et voir avec eux les réponses à apporter et les moyens à mettre en œuvre.

Notons juste que la migration de données nécessite de disposer de plusieurs environnements techniques stables, c’est-à-dire qui ne soient pas l’objet de modifications, soit au niveau des structures de données soit au niveau du contenu.

Ce sont en général des environnements de taille conséquente, car si la phase de développement et de tests s’effectue sur un volume réduit de données, la phase de Certification Statique s’effectue sur le volume réel.

Les comités

Les comités permettent de suivre le projet et d’effectuer un point d’avancement périodique avec les différents acteurs.

Quatre types de comités sont en général mis en place :

  • comité projet (hebdomadaire) ;

  • comité de pilotage (mensuel) ;

  • comité directeur (trimestriel) ;

  • autres comités.

1. Le comité projet (COPRO)

C’est le comité opérationnel qui assure un pilotage et un suivi au plus près du terrain.

a. Objectifs

  • Avancement détaillé du projet

  • Où en sont les différentes tâches en cours ?

  • Comment se présente l’avancement par rapport à la prévision ?

  • Quel rapport entre la charge consommée et la production ?

  • N’y a-t-il pas de surconsommation sur certaines tâches ?

  • Quel est le RAF (reste à faire) ?

  • Planning prévisionnel pour la période suivante

  • Tâches planifiées pour la semaine à venir.

  • Réajustement des affectations en fonction des priorités.

  • État des livrables

  • Où en est le planning de livraisons ?

  • Analyse des retards et des conséquences sur la suite du projet.

  • Problèmes rencontrés

  • Remontée des difficultés et alertes qui pourraient avoir une incidence sur le déroulement du projet.

  • Mise en place et suivi des actions en cours

  • Le comité identifie des actions à mener pour la bonne marche du projet.

    Elles sont initiées et suivies lors du comité.

b. Participants

L’équipe projet.

c. Périodicité...

Les charges

Ce chapitre présente une méthode d’estimation des charges pour un projet de migration de données.

C’est très certainement un des points les plus délicats dans la phase de cadrage, car toutes les métriques connues et utilisées sont en général destinées pour les projets de développements d’applications.

Or, nous avons expliqué que la démarche migration de données était spécifique.

De ce fait, toutes les méthodes d’estimation couramment utilisées ne peuvent pas être appliquées.

La méthode proposée ici a été éprouvée sur plusieurs projets.

Les différences observées entre le prévisionnel et le réalisé sont souvent dues à une mauvaise appréciation :

  • des difficultés qui vont être rencontrées sur le projet par la suite ;

  • de la capacité de l’entreprise à répondre aux besoins du projet dans des délais compatibles avec le planning du projet.

La méthode propose une démarche pour obtenir un calcul de base.

Il faut ensuite moduler le chiffrage (souvent à la hausse) en fonction de plusieurs critères que nous détaillons par la suite, en particulier les points sensibles qu’il faut appréhender pour obtenir un résultat le plus proche de la réalité.

1. Le calcul de base

Le calcul de base est assez simple. Il est fondé sur le principe suivant : 1 jour pour chaque rubrique cible migrée.

La difficulté réside bien entendu dans le calcul du nombre de rubriques.

Pour obtenir un calcul le plus juste possible, il faut partir du recensement des tables cible qui a été fait précédemment et préciser :

  • les rubriques (ou colonnes) qui les constituent ;

  • le format des données (alphanumérique, numérique) étendu ou packé ;

  • leur longueur ;

  • les clés assurant les liens entre tables, avec existence de contrôle d’intégrité ;

  • un top migration, qui indique si la table est migrée, c’est-à-dire si elle nécessite la spécification de règles de reprise de données source ;

  • le type de données (fonctionnelles ou techniques) ;

  • les cardinalités...

Le planning

Pour construire le planning, il faut partir du tableau des charges par étapes construit précédemment.

Si l’on part de l’exemple déjà présenté :

Spéc.

Real.

Certif.

Lot 1

123

123

56

Lot 2

186

186

85

Lot 3

103

103

47

  • On estime le temps nécessaire pour chaque lot, à chaque phase, en prenant de façon rapide 20 jours par mois et par personne ;

  • On positionne sur un calendrier par mois la façon d’enchaîner les différents travaux.

Ce qui pourrait donner en première approche :

M1

M2

M3

M4

M5

M6

M7

M8

M9

M10

M11

M12

M13

M14

Lot 1

Spéc.

Réalisation

Certif.

Lot 2

Spéc.

Réalisation

Certif.

Lot 3

Spéc.

Réalisation

Certif.

Bascule

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Cet exemple intègre plusieurs principes de planification :

  • Les différentes phases sont planifiées par lot ;

  • Pour un lot l’enchaînement des phases est en biseau, et non séquentiel ;

  • La phase de bascule est isolée car commune à tous les lots ;

    Elle est démarrée très en amont de la date de bascule, pour préparer le plan de Bascule (voir le détail dans le chapitre Bascule).

La répartition des charges par ressource

Une fois que les charges des différentes phases/lots ont été estimées et que la planification a été effectuée, il faut définir les ressources dont on a besoin et les affecter sur chaque tâche, dans le temps.

M1

M2

M3

M4

M5

M6

M7

M8

M9

M10

M11

M12

M13

M14

Lot 1

Spécifications

R1

20

20

20

R2

21

21

21

Réalisation

R3

20

20

20

R4

21

21

21

Certification

R5

15

15

R6

15

11

Lot 2

Spécifications

R7

18

18

18

18

R1

19

19

19

R2

19

19

19

Réalisation

R3

16

16

16

16

R4

16

16

16

16

R8

16

16

16

10

Certification

R5

15

15

15

R6

15

15

10

R1, R2..., R8 correspondent aux ressources.

Dans ce tableau, on détermine le nombre de jours de chaque ressource pour chacune des tâches.

Il est conseillé de compléter cette planification de ressources par un tableau d’activités hors projet, dans lequel pour chaque ressource on détermine le nombre de jours consacrés aux travaux menés hors projet ou les congés.

M1

M2

M3

M4

M5

M6

M7

M8

M9

M10

M11

M12

M13

M14

Nb. de jours dans le mois

20

20

20

22

21

20

22

18

23

20

21

19

20

20

Activités hors projet

R1

0

0

0

3

2

1

R2

0

0

0

3

2

1

R3

0

2

1

4

2

5

4

R4

0

2

0

4

2

5

4

R5

7

3

6

4

5

R6

7

7

6

4

10

    

On totalise le nombre de jours affectés à chaque ressource (tâches projet + activités hors projet) et on le compare mois par mois au nombre de jours du mois.

Ce contrôle permet de s’assurer que les affectations sont cohérentes et tient compte des indisponibilités des ressources.

Ces tableaux peuvent servir :

  • à indiquer à chaque ressource son affectation sur le projet et ses charges ;

  • à effectuer un suivi par la suite, afin de vérifier les décalages entre la charge planifiée et le temps passé par chaque ressource.

Si un collaborateur passe moins de temps que prévu sur une tâche, cela aura forcément une incidence sur l’avancement du projet.

Il est conseillé d’effectuer une première affectation de ressource intuitive, puis de contrôler le nombre de jours et de réajuster en cas de conflit.

La structuration des livrables et des documents

Dans la phase de cadrage, il faut structurer les livrables et autres documents produits.

Cette opération facilite :

  • la communication ;

  • le suivi des livrables.

Une première étape consiste à recenser tous les types de documents qui vont être produits, et de mettre en place une normalisation de codification des documents.

En général, il existe une norme de documentation dans l’entreprise qui facilite cette mise en place.

Pour ceux qui se trouveraient dans un contexte où il n’y a pas de norme, on peut présenter les quelques éléments de normalisation couramment utilisés.

Pour les livrables : répertoire projet/LIV/TypeLIV/NOM NOMn.xy, où :

  • TypeLIV = codification des livrables (sur 2 ou 3 caractères).

  • NOM = nom du livrable (ce nom peut être normalisé avec les premiers caractères correspondant au lot.

  • n = n° incrémenté de 0 à 9.

  • xy = n° de version.

x correspond à l’indice d’édition.

y correspond à l’indice de révision.

La première version d’un document démarre à 1.0.

L’indice d’édition est incrémenté de 1 (avec mise à zéro de l’indice de révision) lors d’opérations telles que :

  • modification de la table des matières ;

  • modification entraînant la réédition d’un nombre important...

Les outils pour démarrer le projet

Un certain nombre d’outils sont nécessaires pour gérer correctement le projet.

Il faut les définir et les implémenter dès le début du projet.

Plusieurs outils ont été développés sous Access, correspondant à chaque phase du projet.

Les fonctionnalités présentées ci-après sont illustrées par quelques exemples extraits de ces outils.

Elles peuvent être également mises en œuvre, indépendamment les unes des autres, sous d’autre logiciels, comme Word ou Excel.

Pour la partie spécifications des règles, plusieurs fonctionnalités ont été intégrées dans un même outil :

  • Catalogue des données cible ;

  • Catalogue des données source ;

  • Spécification détaillée des règles

  • Suivi de l’avancement de la migration de données.

Ce choix présente de nombreux avantages :

  • centralisation à un seul endroit des différentes fonctionnalités, au lieu de disposer, comme c’est souvent le cas, de dictionnaires de données sous des formats différents et stockés de manière disparate ;

  • accessibilité simplifiée pour tous types d’utilisateurs, aussi bien informaticiens qu’utilisateurs ;

  • simplification de communication des informations...