Skip to main content

Mise en route de la compatibilité des applications dans un déploiement Windows

Cet article explique comment lancer le processus d'évaluation de l'impact de la compatibilité des applications dans votre projet de déploiement. Vous apprendrez à dresser un inventaire, classer les applications par ordre de priorité et identifier celles qui doivent être incluses dans une image de déploiement spécifique basée sur les rôles.

Dans cet article :


Mise en route de la compatibilité des applications dans un déploiement Windows

Si vous avez travaillé sur un projet de déploiement de système d'exploitation par le passé, vous vous souvenez peut-être de la compatibilité des applications comme étant la source des plus grands défis que vous avez rencontrés. Celle-ci peut demander l'effort le plus important, prendre le plus de temps et générer certains des problèmes les plus difficiles à résoudre. Si vous travaillez sur un projet de déploiement de système d'exploitation pour la première fois, vous avez peut-être entendu des histoires d'horreur sur la compatibilité des applications. Ou bien, vous n'avez peut-être rien entendu du tout et vous risquez d'être complètement surpris par l'ampleur de la tâche. Quelle que soit votre situation, avec une planification appropriée, le projet peut devenir beaucoup plus prévisible et gérable.

Gardez à l'esprit que la compatibilité des applications est avant tout une activité qui relève de la gestion des risques. Plus le pourcentage d'applications qui risquent d'échouer est élevé (statistiquement parlant), plus l'investissement dans des tests proactifs pour veiller à ce qu'une application critique ne soit pas l'une de ces applications est élevé. À mesure que ce pourcentage diminue, le nombre d'applications pour lesquelles des tests exhaustifs sont utiles diminue. Par conséquent, si vous migrez de Windows XP avec des utilisateurs qui sont essentiellement des administrateurs locaux, attendez-vous à un pourcentage raisonnable d'échecs potentiels de vos applications et prévoyez en conséquence d'investir davantage dans la gestion de ce risque. Si vous avez déjà migré vers Windows 7, vous devez vous attendre à ce que très peu d'applications risquent d'échouer et envisager d'investir moins puisque les risques sont moindres. (Bien entendu, comme toujours, vous devez faire confiance, mais vérifier.)

Cependant, la gestion des risques au niveau des applications commence par une compréhension précise des conséquences de ces risques, et cela signifie la compréhension de vos applications. Tout commence par la création et la mise à jour de votre portefeuille d'applications gérées. Si vous n'en avez pas, vous n'êtes certainement pas le seul, mais c'est le moment idéal pour en créer un. Dans le meilleur des cas, vous continuerez à actualiser cette liste à la fin du projet de déploiement pour améliorer votre agilité. Cette liste répertorie vos responsabilités dans le but de garantir le fonctionnement de votre environnement lorsque ce dernier change. Si vous émettez des polices d'assurance pour ces applications, la seule approche raisonnable consiste donc à comprendre le degré de risque à assurer !

Ce document vous aide à comprendre les étapes à suivre pour vous préparer aux tests et à l'évaluation de la compatibilité des applications durant un projet de déploiement de Windows 8. Dans de nombreux cas, cependant, les principes décrits ici sont universels et s'appliquent aux migrations de toutes les plateformes. Après avoir lu ceci, vous saurez par où commencer lors de l'évaluation de l'impact de la compatibilité des applications dans votre projet de déploiement et vous aurez une idée des compétences et des techniques spécifiques nécessaires pour démarrer et être plus efficace.

Retour au début


Présentation du défi de la compatibilité des applications

Au cœur du défi de la compatibilité des applications figure la loi des grands nombres. Les organisations peuvent posséder des dizaines de milliers, ou même des centaines de milliers d'ordinateurs de bureau. Chaque point de terminaison peut comptabiliser des dizaines d'applications installées et il est même possible que vous ignoriez (en particulier si les utilisateurs sont des administrateurs locaux). Ainsi, lorsque vous prenez en compte chacun de ces ordinateurs de bureau, il est possible que des centaines, des milliers, ou même des dizaines de milliers d'applications distinctes soient installées sur tous vos ordinateurs de bureau. Et cela ne concerne que les applications Windows ! Si vous comptabilisez les applications Web, vous devez alors prendre en compte chaque site unique au monde, car il est possible qu'un certain nombre d'applications provenant de divers emplacements à l'intérieur et à l'extérieur de votre organisation se soient introduites dans un flux de travail productif quelque part dans l'entreprise. Leur nombre commence réellement à exploser, et si vous ne faites pas attention, vous risquez de vous retrouver complètement paralysé par la peur à cause du nombre très important d'éléments mobiles impliqués !

C'est pour cette raison que vous devez être pragmatique. Et que vous proposez une police d'assurance. Comme l'environnement et le monde changent, vous assurez le fait que certains des logiciels utilisés continueront de s'exécuter. Mais ce n'est pas vraiment juste d'étendre votre assurance à toute application que l'utilisateur réussit à installer, ou à tout site Web que l'utilisateur parvient à trouver et auquel il arrive à accéder, sans tenir compte de la qualité et de la durabilité. Au lieu de cela, vous devez définir quelques catégories. Pour quel logiciel allez-vous garantir un fonctionnement immédiat, quel que soit le changement ? Le coût de la garantie de ce logiciel est plus élevé, car vous devez exécuter un processus de vérification structuré, mais ce dernier est indispensable pour la plupart de vos applications critiques.

Ensuite, pour quel logiciel allez-vous garantir un bon fonctionnement, et en cas d'échec, vous vous en chargez et vous le réparez ? Un échec engendre toujours un coût, mais vous ne payez finalement que pour ces applications qui échouent, et non pour tout (même lorsque la majorité d'entre elles fonctionne probablement). Puis, nous avons ces applications pour lesquelles vous ne proposez aucune garantie, les utilisateurs sont libres de les utiliser, mais si elles échouent, ils doivent se débrouiller seuls. Enfin, vous avez la catégorie des applications que vous préférez vraiment que les utilisateurs n'utilisent pas du tout, et vous prendrez, en fait, les mesures nécessaires pour les empêcher de les utiliser.

présentation des mesures

Dès que vous commencez à appliquer cet environnement, votre façon de voir les choses commence à changer. Vous serez peut-être prêt à assurer une version d'une application, mais êtes-vous prêt à assurer toutes les versions qu'un utilisateur exécute, avec le contrat de niveau de service le plus élevé ? Dans la plupart des cas, la réponse est non. Voici ce qu'il est conseillé d'exécuter : un processus qui détermine les applications dans lesquelles vous devez investir davantage, effectuer cet investissement pour gérer votre risque et migrer ensuite vers la plateforme plus récente.

Le risque que vous espérez gérer est celui de l'arrêt de l'activité suite à un échec d'application. La plupart des applications que vous exécutez seront compatibles avec Windows 8 (en particulier si vous exécutez déjà Windows 7). Certaines, cependant, pourront présenter un certain nombre de problèmes, dont la gravité est variable, allant d'une application « mal présentée » à une option de menu qui ne fonctionne pas du tout ou à un blocage de l'application.

Alors, par où commencer ? Nos clients les plus performants utilisent cette approche :

  1. Détectez les applications auxquelles vous choisissez de vous intéresser : commencez par les applications que vous gérez déjà de façon centralisée et ajoutez toutes les applications supplémentaires que ne gérez pas encore de cette façon.
  2. Rationalisez les applications pour garantir que la taille du portefeuille d'applications gérées ne se développe au point de devenir ingérable, et pour organiser par catégorie et par ordre de priorité afin de mener à bien votre projet de compatibilité des applications.
  3. Testez les applications pour valider que les fonctionnalités métier requises continuent de fonctionner correctement sur la nouvelle plateforme.
  4. Résolvez tous les problèmes que vous rencontrez, y compris l'utilisation des fonctionnalités de compatibilité intégrées de la plateforme, la modification d'une stratégie pour permettre le comportement d'échec ou le remplacement d'une application, et même parfois le retrait de l'application.

Cet article s'intéresse particulièrement aux deux premières étapes : la détection et la rationalisation. À la fin de ce processus, vous pouvez générer votre projet et planifier de le faire avancer, il est donc très important de bien exécuter ces étapes.

Retour au début


Détection des applications

La « détection des applications » était appelée avant « inventaire des applications ». le passage à l'utilisation de l'expression « détection des applications » est tout à fait intentionnel. Nous avons remarqué que le terme « inventaire » poussait les clients à croire qu'ils devaient trouver absolument tout ce qui s'exécutait dans l'environnement et intégrer cette liste complète dans le processus de rationalisation. Et vous savez quoi ? Vous pouvez vous en sortir pour les applications Windows installées. (Personnellement, le plus grand inventaire d'applications Windows installées que nous connaissons comptabilise 130 000 applications. C'est trop grand, pour sûr, mais cette grande taille ne rend pas la rationalisation impossible.) Cependant, en général, une migration de la plateforme vers une nouvelle version de Windows inclut également une nouvelle version d'Internet Explorer. Quelle est la longueur de la liste des URL uniques accédées par tous dans une organisation ? Très longue ! Pendant la migration, de nombreux clients mettent également à niveau la version de Microsoft Office qu'ils utilisent (Chris Jackson explique les calculs pour obtenir un inventaire complet et une rationalisation complète de documents Office dans son article de TechNet Magazine «  Microsoft Office : Les calculs de la compatibilité Office. » En fait, comme vous pouvez le constater, il n'est donc pas souvent indiqué de tout trouver. En même temps, vous voulez détecter les éléments qui représentent des risques réels pour l'entreprise pendant la migration !

Le processus de détection dépend de plusieurs facteurs, y compris les facteurs suivants :

Environnement géré ou non géré : Il est beaucoup plus facile d'exécuter la détection sur les environnements gérés, car vous contrôlez généralement les applications installées sur les ordinateurs gérés et, par conséquent, vous les connaissez déjà. Vous commencez avec une liste d'applications prises en charge et approuvées ainsi que les informations sur le nombre d'ordinateurs de bureau sur lesquels elles sont installées (et peut-être même leur fréquence d'utilisation). Un environnement non géré est plus complexe, car vous commencez souvent le projet sans connaître les applications en cours d'utilisation, surtout celles que les utilisateurs ont installées (et parfois même créées) eux-mêmes. La plupart des organisations se situent quelque part au milieu : elles disposent de quelques applications gérées et prises en charge de façon centralisée et d'un nombre d'applications traitées comme exceptions (et beaucoup ne les connaissent même pas).

Informatique centralisée ou autonome : Les organisations qui disposent d'une infrastructure informatique centralisée sont avantagées lors de la détection des applications, car les services impliqués se connaissent et sont en contact. Les infrastructures informatiques décentralisées offrent davantage de souplesse au niveau local, mais l'exécution de la détection requiert davantage de coordination lorsque vous consolidez les informations et la stratégie en franchissant les barrières de l'organisation, du centre de coûts et des sites géographiques.

Outils d'inventaire managés disponibles : Les organisations avec un environnement géré possèdent souvent un outil de gestion des ressources logicielles, tel que Microsoft Asset Inventory Service (outil disponible via Microsoft Desktop Optimization Pack pour Software Assurance) ou Microsoft System Center Configuration Manager. Cet outil peut déjà contenir la liste des logiciels qui est gérée activement. Certains clients choisissent de conserver une liste distincte de logiciels gérés et pris en charge, tels que Microsoft SharePoint ou Microsoft Excel. Ceux qui ne connaissent pas actuellement les logiciels en cours d'exécution ou qui craignent que l'inventaire de logiciels gérés puisse être incomplet se tournent souvent vers des outils supplémentaires pour créer ou compléter cette liste. Une façon simple de dresser un inventaire est tout simplement d'interroger les unités d'exploitation ; mais dans certaines organisations, une enquête sur le terrain avant d'interroger peut augmenter considérablement la mise en conformité des unités d'exploitation. C'est pour cette raison même que Microsoft Application Compatibility Toolkit fournit un outil de collecte d'inventaire pour les applications Windows installées (et des compléments Web).

Portée : Le nombre d'ordinateurs au sein d'une organisation est certainement un facteur lors de la détection des applications, mais ce n'est pas le seul. Le nombre de rôles uniques détermine également la variabilité des logiciels utilisés et peut augmenter la charge de travail requise pour vous aider à garantir que toutes les fonctionnalités métier fonctionneront après la migration. Avec des utilisateurs très autonomes capables d'installer leurs propres logiciels, il peut y avoir des différences sensibles au sein d'un rôle. Le fait de déterminer laquelle de ces différences est essentielle pour l'organisation, par rapport au fait de déterminer celles qui ajoutent simplement une complexité inutile, peut représenter un véritable défi.

Exécution de la détection manuelle

Dans un monde idéal, les unités d'exploitation devraient s'adresser à vous. Après tout, ce sont elles qui vous demandent d'assurer ces applications contre les échecs dans un environnement informatique en rapide mutation. N'est-il donc pas logique qu'elles vous disent au moins ce qu'elles souhaitent assurer ? Pourtant, il est fort probable que cela ne se passe pas comme ça (pas encore), vous avez donc du travail.

Pour les toutes petites organisations, il serait plus utile de parler aux utilisateurs individuellement et de passer peut-être un peu de temps à examiner leur menu Démarrer pour voir ce qu'ils ont installé, puis de déterminer les applications qui sont critiques et celles qui sont « juste présentes ».

Pour la plupart des organisations, il est toutefois absolument irréalisable de rendre visite à chaque utilisateur. Dans cette situation, l'approche courante utilisée consiste à choisir un représentant de chaque service ou du rôle de création de rapports sur les logiciels requis pour s'acquitter de cette tâche. Ce rôle porte plusieurs noms, par exemple, Coordinateur technique du service, mais il doit s'agir de quelqu'un qui comprend non seulement le métier, mais aussi les logiciels qui le pilote. À cette fin, collaborez avec cette personne (ou ces personnes) afin de dresser la liste des applications requises.

Une fois cette liste terminée, vous devrez peut-être également envisager d'élaborer des processus formels visant à ajouter, examiner les applications et à les retirer de la liste principale, et d'élaborer ces processus pour qu'ils ne suscitent autant que possible aucun désaccord afin d'encourager la participation de l'entreprise à vos efforts de gestion des ressources logicielles.

Automatisation du processus de détection

Comme la détection des applications impliquent la correspondance des logiciels avec la valeur commerciale, il s'agit d'un processus qui ne peut généralement pas être complètement automatisé. Toutefois, dans de nombreux environnements, les utilisateurs professionnels et les coordinateurs de services ne connaissent peut-être pas tout ce qui pilote l'entreprise. Si vous faites vos premiers pas vers les pratiques de gestion des ressources logicielles au sein de votre organisation, la gestion du risque d'oublis témoigne donc d'un partenariat solide entre l'organisation et les technologies.

Si vous disposez d'un environnement géré, vous pourrez peut-être obtenir une liste actualisée des applications installées pour l'entreprise et pour chaque service. Cette liste peut servir d'excellent point de départ pour ces conversations.

Cependant, si votre portefeuille d'applications n'est pas géré de façon centralisée, vous rechercherez peut-être les outils qui pourront vous aider à dresser cette liste et faciliter cette conversation. De nombreux clients choisissent de recourir à Application Compatibility Toolkit (ACT), qui fournit cette fonctionnalité en téléchargement gratuit depuis le site Web de Microsoft. L'outil Application Compatibility Manager (parmi les autres outils utiles pour le dépannage et la correction des applications) peut collecter l'inventaire des applications à partir d'un sous-ensemble de votre organisation ou de l'ensemble de votre organisation.

Retour au début


Rationalisation des applications

À mesure que vous collaborez avec l'entreprise pour déterminer les applications à classer comme applications gérées ou applications prises en charge (les applications gérées sont précisément soumises à des tests de régression avant la modification ; ce n'est pas le cas des applications prises en charge, mais elles bénéficient du support technique si elles échouent dans le nouvel environnement), vous devrez prendre certaines décisions importantes pour répartir les applications entre les listes.

Le premier examen de vos applications détectées est relativement simple :

Version de l'application : votre organisation possède plusieurs versions d'une application, y compris les versions obsolètes et non prises en charge. Une fois encore, alors que, dans certains cas, certaines organisations prennent en charge plusieurs versions, la plupart n'en gère activement qu'une seule, en général une version récente, sinon, la version la plus actuelle. En ne choisissant qu'une seule version standard, vous pourrez peut-être également réduire vos coûts de support technique.

Redondance des applications : votre organisation possède plusieurs applications qui effectuent la même tâche, dans certains cas, la plupart des organisations pourront choisir d'en prendre en charge plusieurs, mais de n'en gérer activement qu'une seule. En ne choisissant qu'une application standard, vous pourrez peut-être non seulement réduire vos coûts par licence grâce aux réductions pour gros volumes, mais aussi réduire vos coûts de support technique en ne conservant qu'un seul contrat de support technique.

Importance des applications : votre organisation possède des applications qui ne sont pas utiles pour les tâches quotidiennes au sein de votre organisation. Cela est souvent dû aux modifications apportées à la stratégie d'organisation, à la suite de quoi ces applications n'ont jamais été supprimées. La plupart des organisations retirent simplement ces applications, et ne choisissent, qu'occasionnellement et dans de rares cas, de les prendre en charge (même si elles ne les gèrent pas activement).

Pas une application : si vous commencez votre processus de rationalisation à partir d'une liste générée automatiquement, vous vous rendrez compte que la plupart des « applications » détectées ne sont pas des applications du tout, tout au moins, des applications qui vous intéressent. De nombreux packages de pilotes de logiciels laissent des preuves d'installation dans des emplacements parcourus par la plupart des outils d'inventaire, tels que la liste Ajout/suppression de programmes. Vous devrez les supprimer de votre liste avant de commencer vos conversations. Vous pourrez également identifier les applications auxquelles vous ne vous intéresserez jamais et celles qui sont sans intérêt pour les personnes de l'entreprise avec lesquelles vous rationalisez.

Une fois ces éléments évidents supprimés de la liste, vous êtes prêt maintenant à engager des conversations productives avec l'entreprise. Au cours de ces conversations, vous voulez valider que la liste est terminée et vérifier que vous appliquez suffisamment de gestion des risques à ces applications en intégrant le caractère critique de chaque application. Bien que la terminologie individuelle puisse varier, voici certains niveaux de priorité couramment utilisés à prendre en considération :

Critique pour l'entreprise : niveau correspondant aux applications qui bloquent complètement un service, un rôle, ou même toute votre organisation en cas d'échec. Il s'agit d'un niveau très élevé à atteindre, et seules quelques applications de chaque client appartiennent à cette catégorie ! Les applications critiques pour l'entreprise sont souvent associées à des contrats de niveau de service (SLA, Service Level Agreements) qui stipulent que le personnel du support technique doit réagir à un échec en moins de 15 minutes. Les applications critiques pour l'entreprise appartiennent toujours à la catégorie « gérées » et requièrent des tests structurés avant une migration.

Priorité élevée : niveau correspondant aux applications ayant un rôle très important dans un service ou une organisation. L'échec d'une application de priorité élevée peut désorganiser un service ou une seule fonction de l'organisation. En cas d'échec d'une application de priorité élevée, l'organisation peut poursuivre son activité. Toutefois, un ou plusieurs services peuvent être sérieusement affectés. Un contrat de niveau de service classique pour une application de priorité élevée se définit en heures. Les applications de priorité élevée appartiennent toujours à la catégorie « gérées » et requièrent des tests structurés avant une migration.

Important : niveau correspondant à une application importante utilisée fréquemment mais qui ne risque pas d'entraîner une interruption d'activité en cas d'échec. Les contrats de niveau de service des applications importantes se définissent généralement en jours. Les applications importantes appartiennent généralement à la catégorie « prises en charge » et se fient davantage aux tests organiques et aux tests pilotes qu'aux tests formels, sauf dans des cas exceptionnels.

Optionnel : niveau correspondant aux applications approuvées dont l'utilisation est limitée et qui ne sont pas directement liées à une fonction essentielle de l'entreprise. En règle générale, les applications appartenant à cette catégorie ne sont pas couvertes par un contrat de niveau de service. En outre, le support technique est assuré « au mieux ». Les applications optionnelles appartiennent, pour la plupart, à la catégorie « prises en charge » et se fient aux tests organiques et aux tests pilotes plutôt qu'aux tests formels pour identifier les échecs.

L'affectation de niveaux de priorité aux applications est souvent un processus subjectif qui peut faire l'objet d'une réévaluation périodique. Nous encourageons les pratiques formelles de gestion des ressources logicielles, qui désignent une équipe ou une commission chargée de surveiller le portefeuille d'applications même entre les déploiements de systèmes d'exploitation.

L'amélioration de vos compétences en matière de gestion des ressources logicielles peut avoir également d'autres avantages. Par exemple, de nombreux clients pensent qu'il sont plus à même d'optimiser leurs coûts de licence et de réduire les risques de pénalités en cas d'exécution de logiciels sans licence. Ils pensent également qu'ils peuvent optimiser leurs investissements existants et en faire plus avec ce qu'ils ont déjà.

Identification des applications critiques pour l'entreprise

Certaines applications critiques pour l'entreprise sont faciles à identifier mais pas toutes. Si l'activité de votre organisation s'effectue au travers d'Internet, les applications de traitement de texte, de retouche d'images et de développement de pages Web peuvent être considérées comme critiques. La catégorisation d'une application comme critique pour l'entreprise varie également selon chaque rôle principal. Pour un centre d'appels, une application de contrôle de la stabilité des serveurs peut être considérée comme critique ; cependant, cela n'est pas le cas pour d'autres services.

Si votre entreprise dispose d'un plan de récupération d'urgence ou d'un plan de maintien de l'activité, les applications critiques doivent être déjà identifiées dans ces plans.

Certains critères permettant d'identifier les applications critiques pour l'entreprise sont les suivants :

  • L'application assure une fonction primordiale au sein de l'organisation (par exemple un logiciel de traitement de texte ou d'infographie pour une société d'édition).
  • L'organisation subira un impact financier très important en cas d'échec de l'application.
  • En cas d'échec de l'application pendant les heures creuses, une personne doit voir son récepteur de radiomessagerie sonner dans les minutes qui suivent.

Identification des applications de priorité élevée

Les applications de priorité élevée peuvent être faciles à identifier dans votre propre service, mais difficiles à identifier dans les autres services. Parfois, vous pouvez identifier une application de priorité élevée en fonction du pourcentage d'ordinateurs sur lesquels elle est installée ; toutefois, cela peut être trompeur. Par exemple, une application développée en interne pour contrôler la quantité de toner des imprimantes laser d'une société peut être déployée sur la totalité des ordinateurs et n'être utilisée (ou considérée comme essentielle) que par un petit nombre de personnes. Si votre entreprise dispose d'un plan de récupération d'urgence ou d'un plan de maintien de l'activité, les applications de priorité élevée sont peut-être déjà identifiées dans ces plans.

Certains critères permettant d'identifier les applications de priorité élevée pour l'entreprise sont les suivants :

  • L'application est utilisée par la majorité du personnel.
  • L'application est utilisée par un large pourcentage d'utilisateurs dans l'entreprise.
  • Sans l'application, il est difficile pour l'entreprise ou le service de fonctionner normalement.
  • Sans l'application, les opérations quotidiennes seraient affectées et un impact financier pourrait être observé.

Retour au début


Mappage des applications aux rôles

Le concept des rôles d'utilisateurs permet de déterminer un plan de déploiement optimal des systèmes d'exploitation. Les utilisateurs au sein d'un rôle donné ont tendance à utiliser le même logiciel au maximum. Le fait de pouvoir commencer le déploiement une fois la tâche de compatibilité des applications terminée uniquement pour ce rôle, plutôt que d'attendre que cette tâche soit accomplie sur tous les logiciels de votre organisation, peut non seulement maintenir le moral de l'équipe (qui dispose maintenant de mesures de réussite dont elle peut être fière), mais aussi encourager un réel apprentissage des rôles suivants qui n'auraient pas bénéficié du déploiement autrement.

Les rôles/équipes communément définis incluent :

  • Ressources humaines
  • Travailleur de l'information
  • Support technique
  • Marketing
  • Développeur
  • Direction

Naturellement, il existe des applications communes à tous les rôles. Il s'agit, par exemple, des applications de courrier électronique et antivirus.

Vous pouvez également classer les rôles de déploiement par ordre de priorité afin de réduire les efforts nécessaires aux tests de compatibilité des applications. Les configurations basées sur des rôles pour les opérations critiques doivent être testées de manière approfondie alors que celles basées sur des rôles de moindre priorité peuvent être testées plus rapidement, encourageant ainsi l'investissement habile dans la gestion des risques basée sur les risques réels plutôt qu'un élan vers la perfection coûteux et en fin de compte irréalisable.

Retour au début


Étapes suivantes

Le processus décrit dans ce document doit permettre à votre entreprise d'aboutir à un catalogue d'applications, classé par ordre de priorité en termes de tests requis, de rôles d'utilisateurs spécifiques et de choix d'applications à déployer avec Windows 8. Ce catalogue contient les informations nécessaires pour passer aux étapes suivantes du processus. À l'aide des informations de votre catalogue d'applications, voici les étapes suivantes que vous devez effectuer :

  • Constitution de l'équipe : une fois que vous avez compris l'étendue du travail nécessaire pour votre organisation, vous devez constituer l'équipe chargée de prendre les décisions techniques et commerciales. La taille et l'étendue de cette équipe dépendent de la taille et de l'étendue de votre déploiement. Vous pouvez être simultanément le chef de projet, le responsable des tests et l'intermédiaire à contacter. Les grandes entreprises nécessitent une équipe plus formelle avec des rôles bien définis. Vous trouverez des conseils sur la constitution d'une équipe dans Microsoft Deployment Toolkit.
  • Création d'un plan de test : les applications gérées que vous testez formellement nécessitent un plan structuré pour l'exécution des tests. Quelle sera la quantité de travail nécessaire à l'équipe technique pour détecter les problèmes de compatibilité ? Comment allez-vous administrer les tests d'acceptation des utilisateurs ? Ces facteurs ont un impact considérable sur la vitesse et les coûts.
  • Création d'un environnement de test : les applications gérées requièrent un environnement dans lequel vous pouvez effectuer des tests de compatibilité des applications. Bien souvent, il s'agit du même environnement que celui utilisé pour tester les images de déploiement. Songez à utiliser des logiciels de virtualisation tels que Microsoft Hyper-V à la place d'ordinateurs dédiés pour l'essentiel des tests d'applications. Cela vous permettra de réduire les coûts matériels et simplifier les réinitialisations d'environnements pour la prochaine application.
  • Correction : Identifiez les applications qui présentent des problèmes de compatibilité et recherchez la solution de correction appropriée. Testez cette solution pour vous assurer que les problèmes sont effectivement corrigés. Application Compatibility Toolkit contient dans sa documentation des informations sur la correction des problèmes de compatibilité.
  • Pilotage : Déterminez les membres de votre groupe de test de déploiement pilote. Choisissez des personnes représentatives de chaque rôle majeur au sein de votre organisation afin d'obtenir des commentaires pertinents sur les applications, en particulier sur ces applications prises en charge (mais non gérées) et par conséquent, qui ne sont pas formellement testées avant le pilote. Tenez compte de la place de la direction dans le groupe pilote. Certains responsables de direction dont les compétences techniques sont élevées peuvent décider de dédier un ordinateur aux tests pilotes.
  • Validation des applications : comme les applications gérées sont validées tout au long des tests d'acceptation des utilisateurs, enregistrez chaque validation. Une fois que toutes les applications utilisées par un rôle sont certifiées, les déploiements pilotes peuvent commencer et être progressivement étendus tant que le déploiement n'est pas complètement terminé.
  • Déploiement : une fois que toutes les applications gérées sont certifiées, le processus devient alors mécanique. Continuez le déploiement tant que vous n'avez pas atteint tous les ordinateurs de l'organisation.

D'autres tâches peuvent être effectuées en fonction des besoins et de la politique interne de votre organisation. Les décisions prises en matière de priorité des applications et des tests peuvent être également affectées par la structure de votre organisation. Par exemple, vous pouvez ajouter une étape pour réévaluer la liste des applications à déployer avec le système d'exploitation afin de déterminer si de nouvelles applications doivent être incluses.

Ces tâches additionnelles sont traitées de manière plus approfondie dans d'autres documentations, par exemple celle de Microsoft Deployment Toolkit.

Retour au début

Tâches importantes

À propos de l'auteur

Photo de Chris JacksonChris Jackson, alias «  le superman de la compatibilité des applications », est conseiller en chef chez Microsoft et responsable technique de l'équipe d'intervention Windows Application Experience SWAT Team. Expert reconnu dans le domaine de la compatibilité des applications Windows, Chris a créé la documentation technique et les offres de formation et de service utilisées au sein et en dehors de Microsoft, exploitant avec savoir-faire sa longue expérience auprès de clients d'entreprise et d'éditeurs de logiciels indépendants.

Chris est l'auteur et le co-auteur de nombreux documents techniques et articles sur la compatibilité des applications, et contribue à l'élaboration de TechNet Magazine. Il est également conférencier vedette lors de conférences majeures du secteur informatique dans le monde entier, y compris TechEd, IT Forum et Microsoft Management Summit.

Ressources connexes

Rester informé