Stéphane Menguy, consultant en gestion de parc pour LM Gestion

Laurent Blondon, directeur de l'activité migration pour la SSII Sodifrance

Enquête Migration

Retour au sommaire

JDN Solutions : Quel est le facteur essentiel d'un projet de migration ?
Stéphane Menguy : Il vient toujours d'un besoin exprimé par le service client concerné. Le point essentiel dès lors, c'est d'avoir identifié ce besoin, savoir d'où on part et où on va. Les deux personnes les plus importantes sur la période d'avant-projet sont la DSI d'une part qui représente la partie technique, la direction financière d'autre part car c'est elle qui limite ou bloque la migration. Après seulement vient la direction générale. La première chose à faire alors revient à déterminer quel sera le nouveau produit, qu'est ce qu'il nécessite en terme d'infrastructure réseau ou matérielle, et qu'est ce qu'il apporte de plus. Même dans le cas d'une migration imposée, il faut s'interroger sur ce qu'apportera le produit en plus.

Laurent Blondon : Pour notre part nous avons développé une certaine expertise dans la migration d'applications historiques. Ce sont des applications qui ont dix à vingt ans d'existence et qui constituent le socle logiciel des grands comptes. Souvent alors, c'est une rupture technologique qui engendre la migration. Comme ces socles logiciels traitent beaucoup de données, entre 10 000 à 20 000 programmes généralement non documentés, ces migrations présentent une grande complexité. Dès lors le facteur essentiel, c'est la maîtrise de l'existant. Il faut amener cet ensemble vers la cible dans les délais convenus. Ces migrations n'ont pas d'intérêt du point de vue fonctionnel, il s'agit juste de remplacer un socle par un autre. Et il vaut mieux ne pas mélanger les genres.

Comment se déroule la migration de ce type de projet ?
LB : On procède de manière très automatisée. Après avoir terminé l'analyse des besoins et dressé la cartographie de l'existant, nous découpons le projet en lot puis chaque lot est ensuite réalisé en parallèle afin de terminer le projet dans des délais raisonnables. Tout ceci peut se faire de façon automatisée. L'étape suivante se déroule avec le client. Il faut alors définir les spécifications précises de la migration et lister les complexités. Le client se retrouve alors à choisir entre une migration simple où l'enjeu est de sortir de son ancienne technologie à tout prix ou bien une migration plus complexe qui donne lieu à une réévaluation du modèle de données.

Quel est le point déterminant qui va arbitrer entre migration et réécriture de code ?
LB : Le critère important, c'est le volume. Plus il est riche, plus la réécriture est risquée. A partir du moment où le volume diminue, l'optique refonte devient intéressante. Il faut avoir des iscussions avec les maîtrises d'ouvrages sur cette question. Si l'entreprise prend la décision de migrer mais qu'après il faut faire des évolutions majeures, ça ne se justifie pas, mieux vaut réécrire l'application. Il faut aussi se poser la question de l'après migration.

Comment et quand doit-on intégrer les utilisateurs ?
SM : Lors de l'étude préalable, il est envisageable de contacter les utilisateurs mais il vaut mieux ne pas trop le faire. L'idée, c'est de comprendre les problématiques auxquels ils sont confrontés. Si le processus de migration n'a pas été initié par les utilisateurs, les introduire dans la phase d'étude préalable complexifie le problème car ils veulent introduire de nouvelles choses. Il vaut mieux ne pas faire de promesses mais écouter leurs attentes.

Mais alors comment s'assurer de l'adoption de l'outil ?
SM: Je préfère toujours faire en sorte que les utilisateurs ai déjà testé le produit pour de faux. Chez les américains, ils font ça avec un laboratoire de déploiement presque aussi complexe que l'architecture cible. Pour les équipes de migration, l'enjeu est de se former et d'anticiper les problèmes avant l'heure. Intégrer des équipes de production peut se révéler intéressant dans ce cadre. Mais là encore, ça dépend de la taille de l'entreprise et de sa philosophie. En général, les équipes de production ont un rôle consultatif. Il n'est pas obligatoire de les intégrer de bout en bout dans le processus de migration mais de toute façon, il ne faut pas exclure la technique.

Comment un DSI doit il gérer ses relations entre ses différents partenaires ?
LB : Le premier problème en matière de communication va être de réussir à vendre le projet aux maîtrises d'ouvrage. Souvent lorsqu'il s'agit d'une simple migration, il n'y a pas de gain direct pour eux. Il est généralement possible de mettre en avant la valeur ajoutée business du projet qui peut être la conquête de nouveaux clients ou de nouveaux partenaires par exemple. Du fait de ce manque d'implication de la maîtrise d'ouvrage, il vaut mieux que les projets soient fait rapidement. Au niveau de la recette, il faudra montrer aux utilisateurs qu'il n'y a pas de régression fonctionnelle ou de régression en termes de performances. Leur implication dans la migration n'est nécessaire que pour établir les bons jeux de tests.

Bien gérer ses relations, est-ce l'essentiel ?
SM : La communication n'est pas forcément l'élément clé d'une migration réussie. L'essentiel, c'est qu'il y ait au moins une personne qui voit le processus de bout en bout. Cette personne doit être capable de choisir un produit, de l'installer, de savoir quels vont être les plus gros problèmes et comment les éviter mais aussi savoir remplacer ce quoi doit l'être. Avant tout, il faut que ça marche ce qui signifie mettre l'accent sur la technique. Après, que tout le monde soit content, ce n'est pas l'essentiel. A la direction financière de dire si le projet de migration est possible ou non. La direction générale, elle, ce qui l'intéresse c'est combien ça va coûter et combien de temps ça va prendre. Au directeur informatique de bien planifier sa migration et de prévenir les personnes concernées à chaque étape du projet.

Dans quelle mesure vaut-il mieux repartir de zéro plutôt que de migrer ?
SM : C'est très variable. Quand il s'agit de développement d'applications, il est parfois plus sain de repartir de zéro mais ça coûte plus cher. L'équipe part sur de nouvelles technologies, dispose de plus de souplesse et bien souvent elle préfère cela à la reprise d'un ancien code. De plus, il y a rarement de la documentation disponible sur l'ancien code. En matière de migration de système d'exploitation, deux solutions existent. La première consiste à changer de machine en même temps que d'OS. Il est plus facile de déterminer quels seront les services à installer. Avec une mise à jour sans remplacement de machines, si un problème survient longtemps après sur une application quelconque, on ne saura jamais si cela vient ou non de la migration.

Enquête Migration

Retour au sommaire

Quels sont les problèmes majeurs rencontrés lors de ce type de projet ?
SM : Le problème le plus récurrent, c'est la perte de données ou la fonction qui ne marche plus. Pour éviter cela, il faut bien tracer les procédures à migrer au niveau du laboratoire de tests qui doit se faire le plus en amont possible.