Retour d'expérience sur une migration SI/SIG

dim 01-07-2012 Francois-Nicolas ROBINNE

Informatique


	Niveau	Débutant
	Logiciels utilisés	Suite ESRI
	Plateforme	Windows

Il y a certains jalons dans le métier de géomaticien qui marquent durablement. Participer à sa première migration informatique d'ampleur en fait partie ! Ce n'est pas un tutoriel, mais plutôt un partage d'expérience dont j'aurais aimé profiter...

Nota : Devoir de réserve oblige, certains passages restent volontairement généralistes

Le contexte

Infogérance => Système informatique massivement externalisé, dont le SIG
Déménagement des serveurs physiques (homologation+production)
Renouvellement des plateformes (upgrade logiciels ESRI/Windows Server/SGBDR/Hyperviseur/VM)
Urbanisation définitive pour l'intégration du SIG d'entreprise (client léger+client lourd)
SIG basé exclusivement sur les solutions ESRI, passage d'ArcGIS 9.3.1 vers 10.0

"Quelques" problèmes identifiés

Période de réalisation non adaptée : clôture de l’exercice annuel, rendus de documents de gestion, fin des tests sur des applications en développement => Situation de rush, haut niveau de pression, travail en flux tendu (délais). Besoins énormes en SIG.
Phase de recette/homologation pas assez poussée => protocole de recette grossier.
ArcGIS n’a pas été testé complètement sous la nouvelle version de l'hyperviseur => Tous les problèmes détectés n'ont pas été corrigés avant passage en production.
Aucun diagnostic des outils complémentaires existants sur ArcGIS 9.3 (scripts, DLL) à porter vers la V10 (disparition du VB, passage aux add-in) => Disparition de certaines fonctionnalités.
Aucune simulation d'accès concurrents aux serveurs applicatifs => Pas de test de montée en charge.
Pas de période de recouvrement entre plateformes homologation/production => Impossible de revenir en arrière en cas de bug majeur.
Manque de tracé des paramétrages, erreurs et correctifs appliqués en recette => le souvenir n'est pas le meilleur outil qui soit...
Absence de mise en garde contre une potentielle instabilité du système => Défaut de communication auprès des utilisateurs finaux.
Manque d’étude préalable de certaines propositions techniques ‘sans problèmes’ qui s’avèrent impossible à mettre en œuvre une fois en situation => Obligation de rouvrir un sujet sensé être traité.

=> Certaines erreurs majeures ont duré près de 2 mois, d'autres mineures existent encore 6 mois après.

Réflexions et actions à mettre en oeuvre pour réussir une future migration

1) Réserver le temps de préparation nécessaire

Il n’y a jamais de bon moment pour migrer, sauf à cesser toute activité. Une migration informatique/géomatique est un projet en soi. La multiplication des acteurs et des composantes de la migration (logicielle, hardware, tout ou partie du SI…) ainsi que l’externalisation complexifient d’autant le processus et demande donc une planification très en amont, pour une durée de projet plus longue. Il faut donc dès le début :

Identifier un chef de projet et une équipe projet comprenant tous les acteurs internes et externes; Evaluer et bloquer le matériel nécessaire; Définir les responsabilités de chacun.
Consulter les services/équipes concernées par l’informatique pour identifier les périodes clés de leur activité, lorsque l’accès à l’informatique est crucial pour tenir les délais. Ces périodes sont à exclure, autant que possible, pour réaliser le gros du projet. Eviter absolument la migration durant un pic d’activité informatique (plusieurs services sur plusieurs projets avec délais tendus).
Définir une date de début et une date de fin pour inscrire le projet dans le temps. Une planification initiale, issue des plannings des différentes équipes, doit IMPERATIVEMENT exister avant de lancer toute opération technique !

=> En tant qu'administrateur SIG, vous avez votre mot à dire. Refusez le début des travaux tant qu'aucun planning ni équipe fixes ne sont définis et validés !

2) Encadrer fermement la période de recette/homologation

Parallèlement à la mise en place du planning et des équipes, il faut plancher sur les modalités de la migration, c'est à dire sur ce qu'il faut mettre en place pour atteindre l'objectif ultime de stabilité. Dans mon cas, la cinématique devait être préparée sur une plateforme dédiée aux tests, dite d'homologation. La phase de tests doit permettre d’identifier tous les problèmes, d’appliquer des correctifs et de tracer tous les ajustements et installations réalisés pour stabiliser cette plateforme et garantir ainsi un fonctionnement standard. Cela facilitera le montage de la plateforme de production. La migration finale ne doit pas avoir lieu tant que cette phase n’a pas été définitivement réalisée et validée !

Définir une période réservée exclusivement à ces tests. Faire appel à des personnels supplémentaires si nécessaire (et si possible...).
Mettre au point un protocole de recette pour chaque application migrée, chaque processus d’intégration, chaque solution d’architecture technique. Ce protocole doit refléter une utilisation en mode avancé.
S’assurer de la robustesse de l’architecture pour le déploiement des applications externalisées (caractéristiques, compatibilité, débit internet nécessaire, version de l'hyperviseur conseillée…).
Mettre au point des scénarios de migration. Il s’agit de définir la cinématique optimale pour le meilleur rapport « temps d’indisponibilité des outils/qualité de la migration » lors du montage de la plateforme de production.
Tracer les actions, erreurs, installations, solutions, corrections dans un fichier ou un utilitaire de tracking (Mantis Bug Tracker par exemple, un tableau Excel au pire).
Réaliser un document de Procédure Technique d’Installation (PTI), produit ultime de cette phase de recette. Idéalement, il est le résultat de la mise en commun des documents techniques produits par les différents acteurs/testeurs.
Provoquer un comité décisionnel de fin de recette pour la valider et accorder le passage à la phase de migration selon le meilleur scénario.

3) Migrer sereinement

Réserver un temps pour la migration en tant que telle. La préparation en amont et le respect du scénario retenu doivent permettre aux équipes d’agir posément.
L’ancienne plateforme, réputée stable, doit être conservée. Le recouvrement avec la nouvelle infrastructure consiste à maintenir l’ancienne plateforme jusqu’à stabilisation complète de la plateforme de production. Cette sécurité permet de revenir en arrière si la migration se déroule mal ou si l’exploitation à court terme est difficile voir impossible (plantages).
Les actions, problèmes et correctifs doivent être tracés et l’opération doit donner lieu à un compte-rendu détaillé, avec copies d’écran.

4) Assurer la période post-migration

Une équipe technique réduite doit être maintenue durant cette période. Elle doit concentrer les profils indispensables pour une intervention rapide, chez chaque acteur du projet.
Les utilisateurs doivent être mis à contribution pour participer à la montée en charge de la plateforme, l’ultime test. Ils doivent disposer d’un outil pour faire remonter les erreurs ou d’un guide pour déclarer leurs erreurs par mail (dire "ça ne marche pas" ne suffit pas, il faut décrire le cas, le comportement, donner des métriques).
Les erreurs, actions, correctifs doivent être tracés et la PTI mise à jour.
En cas de problème majeur ou d’intervention lourde pour rectifier un problème, les utilisateurs doivent être rebasculés sur l’ancienne plateforme ou une plateforme-relai (homologation dans mon cas) le temps de l'intervention.

Conclusion

Une migration est donc plus compliquée qu'elle n'en a l'air. Je pourrais résumer tout cela en disant que la réussite d'un tel projet dépend d'abord de l'organisation, qui prime sur le nombre et la qualité technique des intervenants. A l'opposé, la plus grande difficulté réside dans la gestion des multiples acteurs informatiques, tendance qui semble aller croissant avec l'externalisation des services et l'effervescence du Cloud Computing.

La donnée qui s'affiche sur l'écran de l'utilisateur final peut dépendre d'applications en chaîne fournies par N intervenants différents : l'infogérant, le fournisseur réseau, le fournisseur internet, le fournisseur de l'application web, le service informatique, le service SIG... Coordonner tout cela relève du vrai chemin de croix.

Je finirais par un avis personnel : d'une part éviter de migrer tous les niveaux du système, c'est à dire segmenter les opérations dans le temps pour éviter les problèmes en cascade (d'abord les serveurs, puis ArcGIS...etc); d'autre part, favoriser l'informatique interne tant que possible, car avoir la main sur son système est une forme de garantie de réactivité et de traçabilité.

N'hésitez pas à me contacter pour des précisions.

François-Nicolas ROBINNE