COMMENT ORGANISER UNE MIGRATION EN ENTREPRISE ?

Ca y est vous en êtes maintenant convaincu : la migration apportera beaucoup à votre entreprise, ou alors vous êtes résigné et vous vous lancez....

Reste maintenant à ne rien rater des bouleversements à venir...

NB : les remarques "Mon expérience" parlent d'une expérience professionnelle ou j'ai conçu et géré la migration d'un parc de 1500 PC et d'une autre plus modeste en environnement NT4.

Avant de migrer tout parc informatique, il convient bien sur de connaître les serveurs, les PC, les applications ainsi que les programmes utilisés.

Serveurs : mettre à jour ou remplacer ?
Les technologies utilisées dans les serveurs évoluent très vite, afin de mettre au point des configurations fiables, administrables et puissantes les constructeurs mettent au point des solutions technologiques souvent propriétaires, le risque lors de la mise à jour est donc une méconnaissance de celles-ci par la nouvelle version. Sous réserve donc de la compatibilité logicielle, on peut garder un serveur, mais il faudra probablement l'upgrader car toute nouvelle version nécessite plus de disque dur et surtout plus de mémoire (exception : Windows Server 2003 par rapport à Windows 2000 est relativement identique).

PC, stations de travail :
Ce qui est valable pour les serveurs l'est aussi pour les PC, il convient à mon avis de distinguer deux cas suivant l'homogénéité du parc :
Si le parc micro est homogène : alors il est facile de tester la compatibilité en réalisant des simulations : dans ce cas vérifier l'existence de drivers, vérifier aussi les éventuelles extensions nécessaire pour rendre les PC "utilisables" sous Windows XP. Comme d'habitude une attention toute particulière doit être apportée aux portables, véritables niches à nouveautés.

Si le parc micro n'est pas homogène (modèles, marques différents) alors attention aux coûts (et pertes de temps) engendrés par la recherche de pilotes pour chaque configuration. Ce genre de parc est probablement l'occasion d'essayer de renouveler en favorisant l'homogénéité de celui-ci.

Mon expérience :
Attention aux coûts cachés : l'économie d'une nouvelle machine peut être facilement occultée par les coûts d'installation (si tous les pilotes existent, l'installation sera sûrement beaucoup plus rapide que si une partie du matériel doit être remplacée ou "approximée" par des drivers génériques".
Mes expériences m'ont permis de mesurer les difficultés rencontrées pour migrer un parc hétérogène : les coûts sont rapidement prohibitifs : chaque PC doit être traité individuellement (pas de clonage possible non plus) et il convient d'envisager un scénario du type renouvellement de parc. A l'inverse un parc homogène (cela ne signifie pas un modèle ou une marque mais simplement un nombre fini de ceux-ci et de nombre suffisamment élevé pour justifier la préparation d'une image pour chaque modèle.

Parc logiciel :

Avant de s'engager dans une migration il convient d'inventorier l'ensemble des applications utilisées dans l'entreprise. Il convient aussi de noter les développement réalisés avec celles-ci 

Par exemple :  Excel 2000, fonctionne sous Windows 2000 / XP, mais peut-on garantir qu'un développement réalisé dans Windows 2000 par exemple et faisant appel à des fonctions extérieures (gestion de fichiers, communication, ...) va de nouveau fonctionner sous Windows XP ? Dans le cas inverse, peut on l'abandonner ce programme ou quel sera le coût de l'adaptation de celui-ci (cas typique : le cas du super programme réalisé par un stagiaire, mais sans aucune documentation...). 

Mon expérience :
Au risque de me répéter lister les applications est un bon début, mais il convient d'identifier les usages, les macros, programmes, batch et autres développement "maison" sont à tester impérativement...

Attention aussi à certaines applications s'appuyant sur un protocole réseau spécifique : NetBios par exemple.

Utilisateurs :

Partie souvent négligée et génératrice de coûts : la formation.
Et pourtant : la formation est le seul et unique moyen de rentabiliser les investissements d'une mise à jour.. En effet quel est l'intérêt de migrer l'utilisateur vers un nouvel environnement de travail sans lui expliquer les nouveautés ?

Mon expérience :

Pour résumer, il ne faut jamais négliger l'utilisateur avant, pendant et après la migration c'est avec lui que sera rentabilisé l'investissement, pas contre lui : 
"les problèmes techniques trouvent toujours une solution, les problèmes humains sont beaucoup plus long à résoudre..."

Comme dit plus haut, pas de bon système sans utilisateur compétent. La formation est très importante, son coût est très vite dépassé par le coût engendré par l'inefficacité, la recherche d'information auprès du support ou des collègues.

Il convient donc de préparer avec soin des formations, si possible spécifiques (les plus efficaces) avec un institut de formation. L'utilisation des formations "génériques" est souvent moins efficace car l'utilisateur y apprends des choses inutiles et ne travaille pas dans l'environnement qu'il va trouver en retournant sur son poste de travail... (on se souvient tous des cours sur Windows 3.1 ou on y apprends -parfaitement inutile par la suite - à utiliser PaintBrush ou Write...).

Le tableau suivant résume les besoins en formation (ne pas oublier les applications) pour les utilisateurs et informaticiens suivant l'évolution du système informatique de l'entreprise. 

Les "informaticiens", c'est à dire les développeurs, les administrateurs, les personnes faisant le support devront être solidement préparés à la migration. Il est très souhaitable que ceux-ci soient consultés dès le démarrage du projet, ceci leur permettra d'acquérir de l'expérience et d'apporter leur expérience sur l'existant. L'arrivée de compétences externes sera bien sur la bienvenue mais cela ne doit pas remplacer la formation des informaticiens existants...

Mon expérience :

Voici le "pack" minimum de bienvenue pour un utilisateur :
1 - Planifier les installations suffisamment à l'avance afin que chaque service ou chacun puisse organiser des formations
2 - Utiliser les ressources "locales" : pour chaque applicatif spécifique - souvent dans un même service - désigner un correspondant spécialiste.
3 - Déterminer les niveaux de formation nécessaire pour chacun : les instituts de formation disposent aujourd'hui tous de méthode afin d'évaluer la formation nécessaire pour chacun. 
4 - Former ou initier les utilisateurs avant la migration (ou pourquoi pas pendant si celle-ci immobilise le poste de travail de celui-ci)
5 - Laisser à chaque utilisateur une documentation succincte lui permettant de découvrir rapidement l'environnement dont il dispose.
6 - Les formation plus poussées seront plus efficaces après : l'utilisateur aura eu le temps de prendre connaissance de son nouvel environnement de travail et sera plus au fait de ce qu'il va approfondir.
7 - Utiliser Intranet pour donner accès à l'utilisateur à des documentations plus approfondies : détails techniques, méthode étape par étape pour réaliser une opération avancée, Foire Aux Questions, problèmes connus,...

Le nerf de la guerre ! Suivant la taille de l'entreprise, il peut s'agir d'une personne, de plusieurs personnes non dédiées à cette tache ou d'une équipe entière...
Cette équipe ne doit pas être uniquement composée d'informaticiens, il convient d'étudier tous les aspects de la migration : financier, formation, impact sur les applicatif, donc le business, ...

Il convient rapidement de faire des mises aux points régulières afin de synchroniser tout ce monde, une personne doit d'ailleurs se charger de leur synchronisation.

Coté financier, tous les coûts doivent être abordés : logiciel, matériel, prestations, formation, logistique (PC et serveurs de test, déplacements, ...).
Coté formation il convient de bien étudier les besoins de chacun.
Coté utilisateur, il convient de bien étudier les impacts et implications des utilisateurs et développeurs dans le projet.
Coté direction, il convient de bien mesurer les impacts de productivité et de rentabilité d'un tel projet.

Mon expérience :
Les réunions techniques ne suffisent pas, il est important de consulter des utilisateurs ou correspondants de chaque service avant de s'engager dans des choix techniques pouvant avoir de gros impacts par la suite sur les utilisateurs ou applicatif.

Les contraintes de temps peuvent différer suivant la taille de l'entreprise et la méthode de migration choisie (mise à jour de chaque poste de travail, clonage, remplacement de chaque poste de travail,...).
Il faut bien garder à l'esprit que durant la migration la cohabitation de deux environnements de travail complexifie énormément le travail des utilisateurs, gestionnaires réseau et support. Plus cette durée est courte moins les utilisateurs seront pénalisés et plus les coûts induits seront réduits.
Malheureusement sauf dans le cas d'une entreprise petite, il n'est pas possible de renouveler ou mettre à jour l'ensemble des postes de travail en quelques jours, il convient donc de planifier des mises à jour direction par direction ou service par service. Il convient de bien connaître les échanges entres entités afin d'essayer de migrer celles qui échangent le plus ensemble. 

Avant la migration, la maquette ("le master") du poste de travail migré doit être mis au point, il convient ensuite de mettre au point la méthode d'installation : 
_ la télédistribution : celle-ci parait à l'heure actuelle, relativement illusoire pour mettre à jour le système d'un PC : comment imaginer la réaction d'un utilisateur face à son PC en pleine mise à jour, seul face à son écran ?
_ la mise à jour : à l'aide de scripts d'installation et d'outils d'automatisation, on migre le poste de travail en essayant d'automatiser le plus possible les opérations standard puis la personnalisation de celui-ci (périphériques et applications spécifiques)
_ la masterisation ou clonage : on crée une image du poste de travail qu'on réplique ensuite sur tous les postes, on personnalise ensuite ceux-ci (paramètres réseau, périphériques et applications spécifiques), pour ce faire on utilise RIS ou des outils spécifiques (Norton Ghost est probablement le plus connu).
_ le remplacement : l'utilisateur change de poste de travail et récupère une machine neuve installée et personnalisée en atelier

Il convient ensuite de déterminer une durée moyenne d'installation ou mise à jour de chaque poste, ceci permettra de déterminer les cadences de migration.

L'utilisateur ne pouvant pas travailler pendant ce temps, on peut choisir de l'envoyer en formation, ou de faire les installation la nuit ou le week end...

Le choix des plannings des utilisateurs à installer doit être déterminé par les direction utilisatrices, en fonction de leur propres contraintes : présence minimale dans un service, contraintes de production, impératifs de mise à jour d'un applicatif de manière synchronisée pour tous les utilisateurs,...

Mon expérience :
J'ai mis en oeuvre deux importantes migrations, l'une à base de mises à jour progressives, l'autre à base de clonage. Mon choix se porte vers le clonage : Il faut dans ce cas  que l'entreprise puisse profiter de la migration pour renouveler son parc informatique, ce qui offre aussi de gros avantages financiers et d'économie en terme de maintenance et de souplesse de gestion de parc.
Ce cas permet des installations rapides, donc des durées de cohabitation courtes de version différentes pour un même service : regroupement des formations, contraintes logicielles moins fortes, difficultés pour les utilisateurs moins importantes, ...
Par contre c'est cette méthode qui nécessite le plus de préparation et de synchronisme : on peut par exemple envisager des cycles sur une semaine s'il n'y a qu'une équipe : Lundi : recueil de données avec la direction concernée et planification des utilisateurs, Mardi et Mercredi : préparation des PC, Jeudi : utilisateurs en formation - installation des PC, Vendredi : recette des PC et applications par les utilisateurs...
S'il y'a plusieurs équipes ou de plus grosses équipes on peut multiplier par deux ou plus le nombre de cycles par semaine : une équipe sera alors chargée de la préparation, une équipe du clonage des PC, une équipe de la personnalisation des PC, une autre de la recette. Ceci demande de nombreuses réunions de synchronisation et d'échanges entre ces équipes.

Il convient de tester les solutions choisies,  les méthodes de migration et de formation sur un échantillon : le choix du service informatique lui même (si celui-ci est assez important) est assez intéressant car logiquement les utilisateurs de ce service étant en charge du support de tous les services, on devrait trouver un grand nombre d'application testées. 
Par contre, du fait même que les possesseurs de PC dans ce service ne sont pas des utilisateurs, les applicatif ne seront pas entièrement "validés" par le simple fait de pouvoir les lancer...

Un important débriefing est nécessaire après cette première étape : il doit permettre de valider l'ensemble des choix et d'apporter les corrections nécessaires. En cas d'important changements dans le master installé, il est peut-être souhaitable de re masteriser les PC de ce service après une courte durée, ceci aura aussi pour avantage de familiariser les informaticiens du service à la migration...

La migration peut commencer : il est désormais important de ne rien oublier : la planification est l'élément primordial. Les gains de productivité sont acquis en améliorant le recueil des données (applications / matériel) ainsi qu'en évaluant correctement les charges de travail... Si les formations et mises à jour d'applicatifs sont synchronisées avec la migration alors le moindre glissement dans les installations peut s'avérer très coûteux en immobilisation de matériel et de personnel : de nos jours un possesseur de PC en entreprise se trouve très vite improductif s'il ne peut y accéder ... ou accéder à ses applications.

Dans une grande entreprise, le rôle principal de l'équipe de migration est de migrer, installer (physiquement) les PC et les applicatif, puis de vérifier le fonctionnement général du poste de travail et des applicatif. Il doit s'arrêter la faute de retards...

C'est l'équipe de support qui prendra ensuite (après ou avec le ou les formateurs) le relais pour le support et le dépannage de ces configuration.

L'étape de validation du poste de travail par l'utilisateur (recette, prise en main) est donc primordiale. Il convient d'écrire aussi des procédures de recette pour chaque application, ces procédures doivent être écrites par les utilisateurs et ou développeurs de cette application. L'utilisation de check-list est très utile pour éviter les oublis. Les check-list de chaque PC installé seront gardées ou communiquées au support, ceci permet de connaître l'historique complet d'une configuration.

Bien organisée et renseignée l'équipe de migration doit être en mesure de savoir contacter tous les responsables d'applicatifs, ainsi que les responsables de l'exploitation du réseau et des serveurs.

Un autre élément notable est la charge réseau et applicative engendrée par une migration de parc : chaque Poste de travail migré va nécessiter d'importantes copies de fichiers sur le réseau ainsi que des tests pour valider les applicatif. Tout ceci peut engendrer de grosses charges réseau, qui peuvent affecter le réseau entier de l'entreprise. C'est pourquoi un maximum d'installations doivent être effectuées "hors site" dans le cas de clonage. Le réseau utilisé en "atelier" doit être correctement séparé des autres, ce service doit aller autant que possible chercher ses fichiers sur ses propres serveurs plutôt que sur les serveurs de production. Plus on saura préparer et intégrer un PC en atelier, plus les utilisateurs et le réseau seront ménagés. De plus ceci permet d'accélérer les cadences d'installation des PC.

Mon expérience :
J'ai installé -seul - en installant de nouveaux PC clonés un parc de 120 PC en environ deux semaines, ainsi que - en équipe de dix informaticiens environ - un parc de 240 personnes en un week-end : le vendredi les personnes travaillaient dans sur un site avec un PC et un applicatif, le lundi elles avaient déménagé, changé de PC, d'applicatif, mais retrouvé leur données bien sur.
Il convient de noter que dans ces deux cas les PC étaient tous identiques matériellement et très proches logiciellement, ce qui est un cas assez rare en entreprise.
L'expérience de mises à jour quasi individuelles et personnalisée de chaque poste de travail est probablement un peu moins perturbante pour l'utilisateur mais comme celle-ci s'étale plus dans le temps, elle l'est plus pour chaque service / direction (problèmes de cohabitation entre l'ancien et le nouvel environnement).

Durant les migrations, le support va être aussi mis à rude épreuve :

• l'exploitation réseau et serveurs va devoir redoubler d'attention et d'anticipation sur les charges générées ainsi que sur les droits qui devront probablement évoluer
• le support utilisateur va crouler sous les demandes d'aide 
• les responsables applicatifs devront faire face - tout en étant eux même peu familier de leur nouvel environnement - à un accroissement de réinstallations simultanées et aux demandes de l'équipe de migration

Les équipes de support doivent être sérieusement formées avant les utilisateurs et devront gérer le support de deux environnements pendant la migration de l'entreprise, ceci ajoute donc non seulement de la charge en terme d'appels, mais aussi en termes de complexité et de stress.

Ces équipes doivent être en contact permanents avec les équipes de migration, afin de corriger les incidents de migration au plus vite ainsi que de partager les connaissances. Le recours à  une solution de gestion et partage des connaissances fournira un gain de productivité, de fiabilité et de réactivité évidents.

Chaque changement dans les méthodes de migration et les masters installés doivent faire l'objet d'un archivage systématique et l'utilisation de numéros de série est très souhaitable. Ceci permettra au support de pouvoir dépanner efficacement les configurations et aussi d'éventuelles mises à niveau par télédistribution (à l'aide d'outils de diffusion ou tout simplement par batch à la connexion réseau par exemple....) .

Mon expérience :

La charge de support ne survient pas le lendemain du jour de migration, en effet l'utilisateur commence tout d'abord par se familiariser avec son nouvel environnement, les changements d'applicatifs, etc ... De plus le jour J + 1 est pris en charge par l'équipe de migration sur place. Par contre lorsque l'utilisateur commence véritablement à utiliser son PC et ses applicatifs, et que l'équipe de migration n'est plus sur place, le recours au support croit notablement. Contrairement à ce qu'on pourrait penser, il ne me semble pas intéressant de migrer les utilisateurs pendant des absences prolongées (congés, déplacements ou formations de plusieurs jours : lorsque celui-ci rentrera l'équipe de migration ne sera probablement plus la pour "recetter" le poste de travail et guider l'utilisateur pour ses premiers pas. 

Voici approximativement la courbe de charge de support que nous avons observé lors d'une migration : l'étalement de celle-ci dépends aussi du type de service installé.

Les services de production sont beaucoup plus rapides en montée en charge car  les applicatifs sont utilisés plus fréquemment et intensément. Il convient de noter que les services financiers ou comptables connaissent des montées de charge (habituelles, mais amplifiées) lors des fins de périodes : mois, trimestre, année : ce sont donc des périodes à éviter pour la migration et à prévoir en termes de support.

Lorsque des changements interviennent dans la solution installée, il est très souhaitable d'essayer de remettre à niveau les configurations déjà installées par exemple au moyen de batch qui s'exécuteront lorsque l'utilisateur se connecte, ceci permettre une cohérence dans l'état du parc installé.

De nombreux outils seront d'une aide précieuse pour toutes les étapes du processus de migration.

 Gestion de parc / inventaires :
Les outils de gestion de parc / inventaires, si il sont déjà utilisés dans l'entreprise seront d'un grand secours car il permettront une connaissance exhaustive du parc matériel et logiciel de l'entreprise. Par contre s'il n'en existe pas, peut-être est il trop tard pour en déployer un. Les coûts engendrés par le déploiement seraient difficiles à amortir...
Microsoft SMS

   Retour accueil