Skip to main content

Cinq étapes pour préparer vos applications à Windows 8

Dans cet article :


Optimisation de votre projet d'analyse et de test d'applications

« Quel est notre prochain projet ? Tester nos applications afin de les préparer pour Windows 8 ? Aucun problème. Après tout, cela ne concerne que 950 applications... »

L'efficacité dont vous ferez preuve lors du traitement de la compatibilité de vos applications dans le cadre de votre projet de migration peut faire la différence entre un déploiement sans heurts et une avalanche d'appels passés au support technique, une nuée de reproches et de longues soirées de travail.

Lorsque les entreprises ont commencé à évaluer Windows Vista il y a quelques années, la compatibilité des applications est le problème qui a stoppé net certaines d'entre elles. Certaines applications importantes n'ont tout simplement pas été disponibles pour Windows Vista. Dans d'autres cas de figure, les organisations n'avaient ni le budget, ni l'envie d'acquérir une licence pour la nouvelle version conçue pour Windows Vista. Enfin, d'autres entreprises disposaient d'applications importantes personnalisées pour lesquelles les développeurs n'étaient plus présents ni disponibles pour résoudre les bogues de compatibilité.

Si vous avez l'intention de migrer vers Windows 8, vous trouverez le processus de compatibilité des applications bien plus simple qu'il ne l'était il y a quelques années. Si vous migrez depuis Windows Vista ou Windows 7, la plupart de vos applications fonctionneront bien avec Windows 8. Si vous migrez depuis Windows XP, vous verrez que la plupart des fournisseurs de logiciels indépendants ont mis à jour leurs applications de façon à ce qu'elles fonctionnent avec les systèmes d'exploitation Windows actuels. D'ailleurs, vous avez probablement choisi des versions compatibles lors du déroulement naturel des mises à jour de logiciels. C'est pourquoi, que la migration ait lieu depuis Windows XP, Windows Vista ou Windows 7, la situation est loin d'être aussi difficile qu'elle a pu l'être dans le passé.

Cela étant dit, la préparation d'un portefeuille d'applications pour la migration vers un nouveau système d'exploitation peut être un défi de taille. Toutefois, grâce à la mise en place de la séquence d'étapes appropriée et à la prise de décisions intelligentes en matière de gestion des risques afin de réduire l'étendue des tests, cette tâche devient nettement moins intimidante.

Retour au début


Pourquoi certaines applications connaissent-elles des défaillances dans Windows 8 ?

Quelles modifications apportées à Windows 8 sont responsables des défaillances rencontrées par certaines applications conçues pour des versions antérieures de Windows ? Pour répondre à cette question, les équipes d'ingénieurs responsables de Windows 8 n'ont pas épargné leurs efforts.

Les modifications apportées à Windows avaient pour but d'améliorer la sécurité, la fiabilité, les performances et la simplicité d'utilisation et, dans certains cas, de supprimer des composants hérités qui étaient tout simplement arrivés au terme de leur cycle de vie. Nous ne prendrons pas le temps de répertorier toutes ces modifications dans cet article, mais les plus significatives d'entre elles en matière de compatibilité d'applications incluent le contrôle de compte d'utilisateur/les comptes d'utilisateurs standard et les vérifications de versions.

Contrôle de compte d'utilisateur (UAC)/Comptes d'utilisateurs standard.

Depuis Windows XP SP2, la sécurité est un élément moteur de la plupart des investissements dans Windows. Mais en la matière, l'équipe d'ingénierie a compris les deux éléments suivants. En premier lieu, tous les investissements de sécurité au monde ne serviront à rien si chaque utilisateur, et chaque application, a la capacité de désactiver simplement ces fonctionnalités parce qu'il ou elle souhaite disposer des droits d'administrateur ! Deuxièmement, l'équipe ne cessait d'entendre les organisations dire qu'il était moins coûteux, nettement moins coûteux, de gérer les comptes d'utilisateurs standard. Mais elle ne pouvait pas simplement supprimer les droits d'administrateur et commencer à économiser de l'argent étant donné qu'un grand nombre d'applications ne fonctionnaient pas lorsqu'elle procédait ainsi.

C'est pourquoi, lors du développement de Windows Vista, l'équipe d'ingénierie s'est fixé pour objectif d'aider à résoudre les problèmes de compatibilité des applications et de permettre aux organisations de déployer leurs utilisateurs comme utilisateurs standard si elles le souhaitaient, tout en accordant des droits d'administrateur locaux uniquement aux personnes qui en avaient véritablement besoin pour travailler, par exemple les développeurs ou les administrateurs informatiques. Ces fonctionnalités étaient regroupées et nommées Contrôle de compte d'utilisateur (UAC). Malgré quelques correctifs automatiques de logiciels utiles, des correctifs manuels restaient nécessaires pour le processus, et le code de certaines applications devait encore être modifié.

Si vous exécutez Windows Vista ou Windows 7, vous avez probablement déjà surmonté cette difficulté et disposez désormais d'un portefeuille de logiciels capables d'être exécutés sans droits d'administrateur. Toutefois, pour le petit nombre d'organisations qui ont désactivé le contrôle de compte d'utilisateur et exécutaient les utilisateurs en tant qu'administrateurs, il est temps de revoir cette décision aujourd'hui, avant de migrer vers Windows 8, car cette fonctionnalité est un prérequis pour les applications immersives de style Windows 8. Il est fort probable que ceux d'entre vous qui migrent à partir de Windows XP ont la plupart de leurs utilisateurs comme administrateurs locaux et envisagent de réduire le nombre d'utilisateurs là où cette situation est présente.

Les applications écrites en attendant des droits d'administrateur sont parfois corrigées automatiquement, mais un grand nombre d'entre elles ont besoin d'être traitées manuellement, à l'aide des shims de compatibilité ajoutés dans le cadre du contrôle de compte d'utilisateur. Il reste encore des applications dont le code doit être modifié afin de rompre des dépendances très profondes sur les droits d'administrateur.

Vérifications de versions

Parmi toutes les modifications que nous avons apportées à Windows 8, le seul impact important de la compatibilité des applications est le changement du numéro de version. Et nous n'avons même pas modifié le numéro de version majeure, nous avons toujours une version majeure 6, ce qui est vrai depuis Windows Vista. Après avoir résolu toutes les vérifications de versions pour Windows XP, les développeurs ont écrit de nouvelles vérifications de versions pour Windows Vista. Après les avoir résolues, les développeurs ont écrit de nouvelles vérifications de versions pour Windows 7. Pour une raison que j'ignore, les développeurs ne parviennent pas à se départir de cette habitude. Il viendra certainement un jour où les développeurs vérifieront le « système d'exploitation x ou ultérieur » ; d'ici là, ce problème est relativement simple à résoudre grâce aux shims de compatibilité d'applications.

Retour au début


Cinq étapes pour gérer la préparation des applications pour Windows 8

À l'instar de la plupart des projets, un projet de préparation des applications devient nettement plus simple lorsque vous passez du temps à scinder le problème en tâches logiques et gérables.

Vous avez probablement l'habitude de voir la compatibilité des applications divisée en trois étapes principales : détection, analyse et test/correction. Nous souhaiterions toutefois ajouter deux étapes supplémentaires : virtualisation et orchestration.

Étape 1 : Détection d'application

La détection d'application constitue la première étape. Elle implique la création d'une liste d'applications que vous considérez comme des applications gérées et qui doivent donc être validées sur la nouvelle plateforme avant le déploiement.

À mesure que vous continuez à faire évoluer vos capacités de gestion des licences logicielles, la définition de priorités pour les applications est la dimension qui a l'impact le plus important sur un projet de compatibilité des applications. Idéalement, vous devez être capable de placer vos applications dans l'une de ces catégories (vous pouvez les nommer différemment, mais le comportement induit par ces catégories est ce qui compte) :

  • Applications gérées : ces applications sont considérées comme essentielles pour une entreprise. Elle requièrent donc des tests proactifs permettant de gérer le risque lorsque l'environnement est modifié, ainsi que des tests supplémentaires pour les migrations à risques plus élevés. Vous devez détecter toutes les applications gérées avant de commencer la migration.
  • Applications prises en charge : ces applications sont importantes pour l'entreprise, mais leur cas peut être traité lors de la phase pilote. Vous pouvez savoir que la plupart de ces applications prises en charge sont présentes, mais il n'est pas essentiel de les avoir toutes détectées avant de commencer un pilote.
  • Applications non prises en charge : ces applications ne sont pas prises en charge par le service informatique et vous n'avez donc pas besoin de savoir qu'elles sont là. Vous ne vous mettrez pas en quatre pour les supprimer, mais les utilisateurs sont responsables de leur propre prise en charge de ces applications.
  • Applications interdites : vous chercherez activement à supprimer ces applications de l'environnement. De nouvelles technologies, par exemple AppLocker, vous permettent d'interdire ces applications. Bien que vous ayez besoin de connaître la présence de ces applications pour appliquer une interdiction, vous n'avez pas besoin de les détecter lors du projet de compatibilité des applications.

Si vous êtes relativement évolué dans vos capacités de gestion des licences logicielles, vous pourrez peut-être vous contenter d'interroger votre base de données d'applications pour retourner la liste des applications gérées. Toutefois, de nombreuses organisations ne sont pas en mesure d'effectuer ce type de requête à l'heure actuelle. Elles doivent donc commencer le processus de détection en créant manuellement une liste d'applications gérées.

Dans certains cas, il peut être judicieux de commencer le processus de détection par un inventaire des applications. Vous pouvez ainsi vous assurer que vous avez détecté tout ce qui doit être géré. Dans d'autres cas, il est plus logique de créer cette liste manuellement en se contenant de poser la question. Cela vaut particulièrement pour les plateformes dont la liste d'applications est tellement importante que l'optimisation de l'inventaire est impossible, par exemple lorsqu'il s'agit d'URL Web pour lesquelles l'inventaire de toutes les URL visitées peut souvent atteindre des dizaines, voire des centaines de millions. Il n'est pas indispensable de détecter chaque application que chacun a installée ou utilisée, rien ne vous oblige à remuer ciel et terre. Il est toutefois important de détecter toutes (ou presque toutes) les applications qui doivent être gérées. Ne vous inquiétez pas si quelques-unes vous ont échappé cette fois, cela arrive. Mais veillez à vous faire une note de ces applications pour la prochaine fois.

Une fois que vous avez décidé qu'il était judicieux de dresser un inventaire, il existe fort heureusement un certain nombre d'outils destinés à faciliter l'automatisation du processus. Vous pouvez également utiliser le Microsoft Application Compatibility Toolkit (ACT), qui est disponible en téléchargement gratuit. Mais si vous utilisez déjà un autre mécanisme d'inventaire (tel que Microsoft System Center Configuration Manager ou Microsoft Asset Inventory Service), vous pouvez vous servir de cette possibilité comme point de départ.

Pour rendre la liste d'applications gérées utile, vous devez idéalement capturer plus que le nom de l'application. Des informations telles que l'utilisateur d'une application, son rôle et l'importance de cette application pour lui peuvent être très utiles pour cette migration et les activités en cours de gestion des licences logicielles.

Le processus de détection présente l'avantage d'identifier les applications largement utilisées que vous ne gérez peut-être pas à l'heure actuelle. Il est préférable de garder un œil sur ces applications afin de vous assurer qu'elles sont gérées correctement, que leur version est approuvée et qu'elles disposent des mises à jour logicielles requises.

Étape 2 : Analyse de vos applications

Combien d'applications prenez-vous en charge actuellement qui ont été remplacées ou qui n'ont plus les faveurs des employés de votre entreprise ? Si vous êtes comme la plupart des organisations, cela représente un bon nombre de vos applications, voire la plupart d'entre elles. Une fois que vous avez terminé la détection d'application et que disposez d'un bon état des lieux, l'étape suivante consiste à nettoyer votre liste d'applications gérées et à les filtrer avant d'entreprendre le processus long et coûteux des tests de régression. Certaines applications doivent être rétrogradées dans les applications prises en charge et ne seront pas testées proactivement, tandis que d'autres peuvent être promues et faire l'objet d'une surveillance accrue lors de la migration.

Définissez des objectifs appropriés pour votre portefeuille d'applications. Combien d'applications au total souhaitez-vous gérer et combien d'applications êtes-vous capable de prendre en charge ? À quel stade une application doit-elle passer au statut géré ?

Une fois vos objectifs définis, il est temps de déterminer les éléments facilement identifiables et de restreindre l'ensemble des applications qui requièrent des tests :

  • Éliminez les applications redondantes ou inutilisées. Vous découvrirez sans aucun doute que vous possédez plusieurs applications qui effectuent les mêmes tâches. Le moment est propice pour normaliser une application unique par fonction et éliminer les applications devenues obsolètes. Il est conseillé ici d'essayer de mapper les dépendances des applications, car vous pourriez avoir besoin de prendre en charge une version héritée d'une application pour maintenir la prise en charge d'une autre application par le fournisseur de logiciels indépendant. Bien entendu, supprimez celles qui sont rarement ou jamais utilisées. Vous faciliterez ainsi les tests et pourrez peut-être effectuer des économies en matière de licences.
  • Supprimez plusieurs versions d'une même application et normalisez la version la plus récente. Dans presque tous les cas, la version la plus récente fonctionne le mieux et représente la version la plus sécurisée et fiable. De nouveau, prenez garde aux dépendances entre les applications.
  • Collectez des informations auprès des utilisateurs professionnels pour affecter des priorités aux applications stratégiques pour l'entreprise et déterminez quels services utilisent quelles applications. Cela sera utile lorsque vous séquencerez votre processus de test, pour lequel il est préférable d'aligner le planning des tests sur le déploiement intermédiaire de la nouvelle image du bureau.

Étape 3 : Évaluation des incompatibilités et des options d'atténuation

L'étape suivante consiste à déterminer lesquelles parmi vos applications gérées fonctionnent correctement sur Windows 8. Il est important de définir votre processus en vue de ces tests.

Si une application requiert une prise en charge par un fournisseur, veillez à ce que la première étape consiste à rechercher l'état actuel de la prise en charge. Vous n'avez probablement pas envie de consacrer le reste du processus à une application que vous ne souhaiterez jamais exécuter. Si vous avez besoin d'une prise en charge, mais que la version actuellement utilisée n'est pas prise en charge, l'étape suivante consiste à obtenir une version mise à jour qui est prise en charge. Certaines personnes choisissent également de rechercher la prise en charge du fournisseur, y compris sur des applications pour lesquelles la prise en charge n'est pas nécessaire. Si ces applications sont couramment utilisées, vous pouvez généralement trouver un nombre suffisant de déclarations de prise en charge pour que cette activité en vaille la peine. En effet, une déclaration de prise en charge est un bon indicateur du bon fonctionnement, ou non, de l'application.

Certains clients choisissent de demander au personnel technique d'effectuer le test de détection de fumée, de réaliser une analyse statique à l'aide des outils de compatibilité, ou bien les deux. Ces tests techniques peuvent être très utiles pour déterminer la compatibilité des packages et des applications.

L'arbitre final de la compatibilité est toujours le test d'acceptation des utilisateurs (UAT). L'utilisateur est le facteur le plus important lorsqu'il s'agit de déterminer l'absence de bogues ayant un impact sur les scénarios utilisateur. Le travail effectué avant UAT est, à de nombreux égards, conçu pour simplifier le processus d'UAT pour l'utilisateur, qui est généralement un volontaire dont la coopération n'est pas garantie.

Au cours de ce processus, vous découvrirez peut-être des applications ayant besoin d'être modifiées en vue de leur préparation à Windows 8, notamment si vous migrez à partir de Windows XP. À ce stade, plusieurs options s'offrent à vous :

  • Remplacez l'application non compatible par une nouvelle version. Il s'agit certainement de la méthode la plus fiable, mais malheureusement de la plus coûteuse aussi. Si l'application est stratégique pour votre entreprise ou essentielle à son fonctionnement, cette option vous est recommandée.
  • Créez des shims pour vos applications existantes. Les shims sont une fonctionnalité de la compatibilité des applications disponible depuis Windows 2000. Cette fonctionnalité vous permet de modifier les appels du système d'exploitation sous-jacent. Par exemple, grâce à certains shims, vous pouvez simuler une version plus ancienne du système d'exploitation, tandis que d'autres vous permettent de rediriger les lectures et écritures de fichiers vers d'autres emplacements. Vous connaîtrez une légère surcharge de gestion étant donné que vous devrez gérer une base de données de shims, mais cette approche est très efficace et peut résoudre de nombreux bogues de compatibilité. Il s'agit souvent de la voie la plus économique et cela peut être la seule option si le fournisseur de l'application n'est plus présent. Un dernier avertissement cependant : de nombreux fournisseurs ne prendront pas en charge les applications dotées de shims. Bien évidemment, si l'application est prise en charge, il vous suffit d'appeler le fournisseur et de demander une mise à jour, vous n'avez pas besoin de shims.
  • Utilisez une stratégie de groupe pour modifier le comportement offensant de l'application. La modification de la configuration du système à l'aide de la stratégie de groupe résout souvent les bogues de compatibilité, mais cette approche présente des inconvénients. Globalement, cette approche utilise une stratégie pour désactiver une fonctionnalité ou une fonction particulière qui entraîne l'instabilité de l'application. Malheureusement, dans de nombreux cas, ces fonctions impliquent la sécurité du système sous-jacent, si bien que la contrepartie est importante. De même, l'application doit posséder des paramètres de stratégie de groupe pour pouvoir être gérée.

Pour les applications personnalisées ou développées en interne, vous pouvez modifier le code. Cela n'est pas toujours possible mais, le cas échéant, des ressources exceptionnelles sont disponibles pour vous aider. Vous trouverez des guides sur la compatibilité des applications qui présentent les modifications apportées entre Windows XP et Windows Vista, entre Windows Vista et Windows 7, et entre Windows 7 et Windows 8. Ces ouvrages sont disponibles gratuitement et permettent aux développeurs de comprendre les modifications des systèmes d'exploitation afin de les aider à résoudre les bogues qui ont un impact sur la compatibilité.

Étape 4 : Préparation des options de déploiement du système d'exploitation et de distribution d'applications nouvelles

Le début d'un projet de migration du système d'exploitation est une opportunité parfaite pour repenser la manière dont vous conditionnez et distribuez les applications à vos utilisateurs finaux. Les technologies de virtualisation des applications ont connu des améliorations importantes et ouvert des options qui n'étaient peut-être pas disponibles la dernière fois que vous avez opté pour une norme de packaging. Réfléchissez à différents modèles de packaging et de distribution d'applications avant de commencer le processus de test. Vous découvrirez peut-être que les économies réalisées en termes de coûts de packaging, de test et de préparation font plus que compenser le coût d'implémentation d'un environnement virtualisé, tout en offrant un environnement d'application plus flexible et facile à gérer.

La virtualisation de votre portefeuille d'applications offre un grand nombre d'avantages pour la facilité de gestion et la flexibilité, mais l'un des atouts clés est la baisse des conflits entre applications. Ces conflits se manifestent lorsque vous devez exécuter deux versions de la même application simultanément, par exemple lorsque le support technique continue à prendre en charge plusieurs versions d'une application ou lorsque le service financier migre vers une nouvelle version de son logiciel de comptabilité, mais a besoin d'un accès à l'ancienne version pour clore l'exercice.

Étape 5 : Séquencement des efforts de test, de réalisation de pilote et de déploiement

Au cours de la première étape, nous avons évoqué la collecte d'informations supplémentaires sur vos applications afin de faciliter le processus par la suite. Pour utiliser pleinement ces données, vous pouvez notamment prendre en charge un processus de déploiement vous permettant de créer une dynamique et de connaître le succès ultérieurement au cours du processus.

Le déploiement par rôle est l'une des méthodologies de déploiement les plus réussies que nous ayons vues. Le déploiement a bien évidemment tendance à attendre la fin de la compatibilité des applications. Par conséquent, si vous pouvez identifier quelles applications sont utilisées par quels rôles, vous pourrez vous concentrer en premier lieu sur la compatibilité des applications utilisées dans le cadre de ce rôle, puis commencer à déployer pour ces personnes.

Mais quels rôles est-il préférable de choisir d'abord ? Ce choix est souvent fait en fonction du nombre d'applications utilisées par les personnes qui effectuent ce rôle (afin de toucher en premier les rôles avec un petit nombre d'applications et d'en tirer les premiers bénéfices), ou des rôles pour lesquels une défaillance est plus tolérable (afin de pouvoir travailler dans un environnement moins risqué pendant que vous continuez à apprendre).

Une fois que vous avez testé les applications d'un rôle donné, vous pouvez commencer les tests pilotes au sein de ce rôle. Au cours du processus, il est possible que vous rencontriez des problèmes d'applications supplémentaires provenant des applications prises en charge (les applications gérées ne posent généralement pas de problème, mais si tel devait être le cas, vous pourriez toujours mettre en place votre plan de secours), mais tant que le support technique a la capacité de prendre en charge ces applications, vous pouvez continuer à développer le pilote jusqu'à ce qu'il finisse par devenir un déploiement complet. Rôle par rôle, vous pouvez progresser au sein de l'organisation et travailler en étroite collaboration avec les responsables du déploiement de l'image du système d'exploitation dans un but de coordination et afin de poursuivre la création de la dynamique. En moins de temps qu'il ne faut pour le dire, vous aurez atteint toutes les licences ciblées pour le déploiement de Windows 8 !

Retour au début


Ressources complémentaires

La préparation de votre portefeuille d'applications pour une migration vers Windows 8 est une tâche de taille. Fort heureusement, un certain nombre d'outils et de nombreux conseils et instructions sont disponibles pour vous permettre d'optimiser le processus et d'en faciliter la gestion. Au cours de cet article, nous n'avons fait qu'effleurer le sujet. Si vous êtes prêt à l'approfondir et à mettre en place le processus, nous vous conseillons vivement de visiter la page de tâche principale de la compatibilité des applications Windows sur TechNet, de télécharger l' Application Compatibility Toolkit et de commencer à créer votre plan de projet.

Vous trouverez également des informations et des conseils utiles sur le Blog de Chris Jackson. Pour en savoir plus sur les technologies de virtualisation mentionnées ci-dessus, consultez également la zone de ressource Microsoft Desktop Optimization Pack.

Pour en savoir plus sur Windows 8 ou sur l'une des technologies de client Windows, consultez le TechCenter Windows 8, où vous trouverez les dernières informations, instructions et connexions de la communauté.

Retour au début

Tâches importantes

Ressources connexes

  • Kit de déploiement et d'évaluation Windows

    Documentation et outils gratuits (dont ACT) vous permettant d'évaluer et de réduire les problèmes de compatibilité des applications avant de déployer Windows 8.

  • Guide de compatibilité Windows 8

    Informations sur les modifications apportées aux systèmes d'exploitation Windows 8 et Windows Server 2012, ainsi que sur leurs nouvelles fonctionnalités.

  • Centre de compatibilité Windows 8

    Collection en ligne d'informations de compatibilité avec Windows 8 plus listes de pilotes de matériel compatibles avec Windows 8 et mises à jour logicielles.

Rester informé