Annoncée pour avril 2014, la fin du support technique de Windows XP continue d’alimenter les réflexions des grandes entreprises. L’enjeu à court-terme pour les entreprises est donc de sécuriser le désengagement de Windows XP et le déploiement vers l’OS choisi. En voici les principaux leviers.
La plupart des entreprises ont démarré un projet de migration afin de gérer l’obsolescence des composants XP, tant au niveau du système d’exploitation que des outils fournis aux utilisateurs (navigateur internet, suite bureautique, etc.), mais aussi pour améliorer leur attractivité et l’image de leur DSI. Ce type de projet doit également être un levier de réduction du TCO (Total Cost of Ownership) du poste de travail.
Compte tenu des enjeux économiques et de support, il faut noter une forte volonté de réduire au maximum le nombre de postes fonctionnant sous Windows XP d’ici avril 2014. Néanmoins, il peut être envisageable qu’une partie du parc soit maintenue sous cet OS. Selon la quantité de postes restant à migrer après avril 2014, une négociation avec Microsoft peut en effet être envisagée afin de bénéficier d’une extension de support. Mais les risques induits ne sont pas à négliger : risques opérationnels dus à des applications potentiellement non compatibles, risques techniques dus à des pilotes matériels qui ne sont plus pris en charge, risques liés à la sécurité des postes, etc. Il est donc préférable de réduire au maximum le nombre de postes sous Windows XP, afin d’éviter notamment des coûts liés à une double administration d’OS.
Une industrialisation du processus de déploiement au service de la migration
L’industrialisation du processus de déploiement doit permettre d’optimiser au maximum la migration tout en la sécurisant. Pour cela, les choix d’architecture réalisés en amont devront être pensés de façon à minimiser les impacts éventuels sur la migration, tout en assurant la reprise des données. Il est en effet impératif d’assurer la sauvegarde de certaines données utilisateurs. Se baser sur les outils de sauvegarde existants ou sur les outillages de synchronisation de données pourra faciliter la démarche. Certaines entreprises font le choix de laisser la responsabilité à l’utilisateur. Il est alors chargé de récupérer et stocker ses données avant la migration de son poste, puis de les restaurer une fois la migration effectuée.
À moins d’un an de la fin de support XP, la stratégie de déploiement doit désormais être pensée de façon à optimiser les délais et les coûts. Plusieurs types de scénarios peuvent être considérés, d’une gestion manuelle à l’utilisation d’outils et de technologies d’automatisation. La migration « au fil de l’eau », basée sur le renouvellement du matériel, peut être un levier simple à mettre en place. Cette stratégie est généralement complétée par un projet de migration compte tenu des échéances.
Au vu des délais de moins en moins flexibles, il faudra si possible capitaliser au maximum sur les outils de télédistribution déjà implémentés au sein de l’entreprise. Pour les parcs informatiques importants, se baser sur les infrastructures existantes, permettra d’industrialiser le déploiement, tout en faisant baisser le TCO du poste de travail, notamment sur les aspects de gestion courante, comme la remasterisation et le renouvellement du poste.
L’industrialisation du déploiement se base également sur un inventaire détaillé des utilisateurs et des machines, la planification des rendez-vous avec les utilisateurs, le suivi du déploiement via des outils de reporting, le provisioning et la masterisation des postes. Il faudra veiller à définir le type de support apporté aux utilisateurs durant la migration, tout en mettant en place une véritable conduite du changement, à adapter aux profils plus ou moins technophiles, à leur localisation par plaque régionale pour un ajustement à la culture locale, à leur mobilité, à leur statut dans l’entreprise et de façon plus générale à la culture d’entreprise.
Piloter les inventaires, qualifications et remédiations applicatives
La gestion des applications et de leur compatibilité avec le futur système d’exploitation est un autre levier important pour sécuriser le désengagement de Windows XP et son déploiement.
En premier lieu, il est important d’identifier les applications critiques avec un fort impact business. La qualification de ces applications permettra de mettre en évidence et d’anticiper les éventuelles incompatibilités logicielles de façon proactive. Celles-ci devront alors faire l’objet d’une remédiation pour les adapter au système d’exploitation cible. Le déploiement devra être bloqué tant que ces incompatibilités n’auront pas été remédiées. En se basant sur le statut éditeur ou en réalisant des tests fonctionnels, plusieurs méthodes permettent d’évaluer la compatibilité des applications vers l’OS cible. Les applications web par exemple, devront généralement être redéveloppées, de même que les macros Excel et les développements VBA.
La virtualisation d’applications présente alors un intérêt fort en tant que solution de contournement. Cette technologie va permettre de supprimer les adhérences de l’application avec le système d’exploitation, en créant une bulle applicative où elle s’exécutera. Utiliser la virtualisation d’application pour faire de la remédiation reste toutefois un détournement de la solution et n’offre aucune garantie. D’un point de vue fonctionnel, la virtualisation peut effectivement permettre une montée de version de l’application, car indépendante de l’OS. Mais d’un point de vue technique, cela ne doit être envisagé qu’en tant que solution palliative court-terme. La virtualisation d’application, MED-V ou Citrix ne sont en aucun cas des solutions définitives. Pour faciliter l’étape de remédiation, il est ainsi conseillé de mettre à disposition des métiers des processus de remédiation standards, tout en industrialisant et en pilotant les travaux de ce chantier de packaging applicatif.
Idéalement, ces étapes permettront de participer à la rationalisation du portefeuille applicatif en éliminant notamment quelques logiciels non utilisés ou en doublons. La connaissance fine du parc applicatif étant généralement trop faible, il est illusoire de penser pouvoir traiter simultanément déploiement du poste de travail et rationalisation profonde du parc applicatif. Pour les contextes les plus matures, la gestion de portefeuille applicatif est légèrement enrichie et la mise en œuvre d’une solution de self-service est réalisée. Cette stratégie de shift-left visant à apporter un maximum d’autonomie à l’utilisateur sur les activités de gestion du poste à faible valeur-ajoutée, peut constituer un levier important de réduction du TCO des postes.
Il s’agit d’un chantier long et laborieux à anticiper, la meilleure solution étant de définir des processus récurrents, afin de suivre les mises à jour logicielles de façon optimale. Il faudra pour cela veiller à identifier les couches métier impactées et intégrer ces processus avec les plannings de migration, afin de lisser le déploiement selon les Métiers. Mais cela nécessite l’implémentation d’une vraie gouvernance et un bon niveau de maturité sur la gestion applicative et de leurs composants, ainsi que sur la gestion des licences.
Quoiqu’il en soit, lancer un projet de migration suscite bien des remises en question ! Elle permet de réviser les règles de sécurité déjà implémentées pour mieux les adapter au contexte de l’entreprise. Mais c’est aussi par exemple l’occasion d’adapter les services aux nouveaux usages, tout en réduisant le TCO des postes et en favorisant la flexibilité des services fournis aux utilisateurs, via par exemple des outils modernes de self-service du type application store. Un projet riche sur bien des plans donc.
