Partager via

  • Article

Guide de compatibilité des applications Office 2010

 

S’applique à : Office 2010

Dernière rubrique modifiée : 2017-01-17

Le processus de test et de correction de compatibilité des applications pour les déploiements de Microsoft Office 2010 identifie les problèmes de compatibilité et vous aide à élaborer des plans pour les corriger. Ces informations sont utiles principalement aux professionnels de l’informatique chargés d’évaluer et de limiter les problèmes de compatibilité des applications. Les développeurs effectuant une mise à niveau des applications Office pourront également trouver ces informations utiles. Après avoir mené à bien le processus décrit dans cet article, les administrateurs et développeurs auront une meilleure connaissance des compléments et applications qui interagissent avec Office et de la procédure à suivre pour les migrer vers Office 2010.

Cet article ne traite pas de la compatibilité, de la conversion ou de la migration de documents. Pour plus d’informations sur la conversion de fichiers Office hérités et l’utilisation du mode de compatibilité, voir Compatibilité des documents pour Office 2010.

Dans cet article :

  • Présentation de la compatibilité des applications dans Office 2010

  • Processus d’évaluation et de correction de compatibilité des applications

  • Planifier les tests de compatibilité

  • Évaluer l’environnement

  • Tester et résoudre les problèmes de compatibilité

Présentation de la compatibilité des applications dans Office 2010

De nombreux développeurs et utilisateurs expérimentés ont écrit du code pour étendre Office depuis la première apparition des produits Office. Office ayant au fil du temps évolué et subi des modifications de fonctionnalités, des suppressions de fonctionnalités et des modifications de formats de fichiers, il est fort possible que d’anciens compléments et personnalisations ne fonctionnent plus correctement en cas d’utilisation avec Office 2010. On ne sera pas surpris d’apprendre que les aspects liés à la compatibilité des applications peuvent constituer un réel défi pour les organisations ayant des fichiers Office datant d’une dizaine d’années ou plus.

Office 2010 offre de nombreuses améliorations de produits et autres modifications susceptibles d’affecter la compatibilité avec les fichiers, macros, compléments et solutions Microsoft Visual Studio existants. La liste suivante décrit certaines de ces modifications.

  • Fonctionnalités supprimées   Les compléments et applications peuvent subir des blocages lorsqu’elles dépendent de fonctionnalités (et de leurs modèles objet correspondants) qui ont été supprimées d’Office 2010.

  • Modifications de fonctionnalités   Les fonctionnalités mises à jour et leurs modèles objet peuvent provoquer un fonctionnement inattendu des compléments et applications. Ces modifications sont parfois évidentes, mais parfois elles ne peuvent être découvertes qu’à l’issue de tests rigoureux.

  • Incompatibilités 64 bits   Office 2010 est disponible dans des versions 32 bits et 64 bits. La version 64 bits est destinée aux utilisateurs ayant besoin de davantage de capacité mémoire lorsqu’ils travaillent avec des feuilles de calcul Microsoft Excel ou des projets Microsoft Project complexes. Si vous prévoyez de déployer la version 64 bits d’Office, sachez que les contrôles ActiveX, compléments et solutions Visual Basic pour Applications (VBA) créés pour fonctionner sur des ordinateurs clients 32 bits sont susceptibles de ne pas fonctionner avec les versions 64 bits d’Office 2010.

Il existe plusieurs outils et solutions pour évaluer et résoudre les problèmes de compatibilité des applications dans Office 2010. Pour les administrateurs informatiques, le nouvel outil OEAT (Office Environment Assessment Tool) peut aider à identifier les compléments et applications qui interagissent avec Office. Les développeurs peuvent effectuer des tests supplémentaires à l’aide du nouvel outil Microsoft Office 2010 Code Compatibility Inspector afin d’identifier le code potentiellement incompatible dans les projets VBA ou le code Visual Studio. Dans les cas où les applications ne peuvent pas être corrigées, les administrateurs peuvent recourir à des solutions telles que les services Bureau à distance (Services Terminal Server), les installations parallèles et la nouvelle version de Microsoft Application Virtualization (App-V) afin de conserver l’ancien environnement Office compatible aux côtés d’Office 2010.

Les sections suivantes décrivent brièvement les outils d’évaluation de compatibilité des applications Office 2010.

Office Environment Assessment Tool (OEAT)   L’outil OEAT est un nouvel outil d’analyse pour Office 2010 qui identifie les compléments installés sur les ordinateurs des utilisateurs. Il recueille et fournit des informations sur les compléments pour Microsoft Office 97, Microsoft Office 2000, Microsoft Office XP, Microsoft Office 2003 et Microsoft Office System 2007. Il compare également la liste des compléments tiers découverts à une liste de compléments compatibles suivis par le Programme de visibilité de compatibilité des applications.

Pour télécharger l’outil OEAT, voir Outil Office 2010 : Office Environment Assessment Tool (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0x40C) (éventuellement en anglais).

Programme de visibilité de compatibilité des applications   Ce nouveau programme effectue le suivi des éditeurs de logiciels indépendants qui certifient que leurs produits sont compatibles avec Office 2010. Les éditeurs de logiciels indépendants soumettent des informations concernant leurs produits par le biais d’un portail spécial et Microsoft publie cette liste dans le Centre de ressources de compatibility pour Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0x40C). L’outil OEAT utilise également cette liste pour mettre en avant les compléments compatibles connus dans le rapport de synthèse.

Pour afficher la liste actuelle d’éditeurs de logiciels indépendants qui participent à ce programme, voir Compatibilité pour Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0x40C).

Microsoft Office 2010 Code Compatibility Inspector (OCCI)   L’outil OCCI Microsoft Office 2010 compare le code source VBA, Visual Basic .NET et C# existant afin de détecter les appels d’API de modèle objet qui sont incompatibles avec Office 2010. Cet outil s’intègre à la fois à Microsoft Visual Basic pour Applications 7.0 (VBA 7) et Microsoft Visual Studio 2008 ou Microsoft Visual Studio 2010 et inclut un analyseur de base. Lorsqu’un outil d’inspection détecte du code incompatible avec Office 2010, il ajoute un commentaire au code afin que le développeur puisse le corriger ultérieurement. L’outil d’inspection analyse également le code à la recherche d’instructions Declare et de références à des DLL utilisées par des contrôles ActiveX qui doivent être mises à jour afin d’être compatibles avec Office 2010 64 bits.

Pour télécharger l’outil OCCI, voir Outil Office 2010 : Inspecteur de compatibilité (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=181874\&clcid=0x40C) (éventuellement en anglais).

Le tableau suivant décrit les types de personnalisations Office que de nombreuses organisations sont susceptibles de rencontrer et l’outil qui peut être utilisé pour évaluer chaque personnalisation. Certaines de ces personnalisations étant courantes pour les versions antérieures d’Office, les liens vers des informations supplémentaires pointent souvent vers de la documentation de développement pour Office 2003 et versions antérieures.

Type de personnalisation Description Outil d’évaluation

Compléments d’automation (.xll ou .wll)

Les compléments d’automation permettent aux développeurs d’incorporer les fonctionnalités d’une application Office 2010 existante dans des applications personnalisées. En guise d’exemple de complément d’automation Office, on pourrait citer une application de gestion de la relation client qui écrit les données de facturation des clients dans une feuille de calcul Microsoft Excel.

Pour plus d’informations sur les compléments d’automation, voir Macros complémentaires COM et macros complémentaires d’automation dans Excel (https://go.microsoft.com/fwlink/?linkid=186622&clcid=0x40C).

OEAT

Complément COM (Windows .dll)

Introduits dans le cadre de Microsoft Office 2000, les compléments COM permettent aux développeurs d’utiliser le langage de programmation et l’environnement de leur choix lors de la création de solutions basées sur Office. Une fois écrit, le complément COM est compilé en tant que fichier .dll. Celui-ci peut ensuite être chargé par une ou plusieurs applications Office et peut interagir avec des modèles objet Office.

Pour plus d’informations sur les compléments COM, voir Qu’est-ce qu’un complément COM ? (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=186623&clcid=0x40C) (éventuellement en anglais).

OEAT

Compléments VBA au format Office 97–2003 (.dot, .wll, .xla, .xll, .ppa)

Compléments VBA au format Office 2007–2010 (.dotm, .xlam, .ppam)

La création des compléments modèles VBA s’effectue à l’aide de Microsoft Visual Basic pour Applications (VBA).

Pour plus d’informations sur les compléments VBA, voir Mise en route avec VBA dans Office 2010 (https://go.microsoft.com/fwlink/?linkid=186624&clcid=0x40C). Pour obtenir une clarification concernant les différences entre les modèles et les compléments Microsoft Word, voir Modèles de documents Word et compléments Word (modèles globaux) (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=186625&clcid=0x40C) (éventuellement en anglais).

OEAT et OCCI

Fichiers prenant en charge les macros VBA au format Office 2007–2010 (.docm, .xlsm, .pptm)

Ces fichiers contiennent du code de macro VBA mais ne sont pas enregistrés en tant que compléments.

L’outil OEAT détecte les fichiers Word et Excel prenant en charge les macros stockés dans le dossier Démarrage ou chargés comme modèles globaux. En revanche, il ne détecte pas les fichiers prenant en charge les macros stockés à d’autres emplacements, ni les fichiers PowerPoint prenant en charge les macros (quel que soit l’emplacement).

Pour plus d’informations sur les fichiers prenant en charge les macros, voir Formats de fichiers pris en charge dans Office 2010.

OEAT et OCCI

Compléments Office créés à l’aide de Visual Studio

Les compléments Office créés à l’aide de Visual Studio permettent aux organisations de personnaliser les applications Office afin d’ajouter des fonctionnalités spécifiques nécessaires à leurs processus métier.

Visual Studio prend en charge deux genres de solutions susceptibles d’être utilisées dans votre organisation :

  • Personnalisations au niveau du document   Ces personnalisations se composent d’un assembly associé à un document, un classeur ou un modèle unique dans Microsoft Word ou Microsoft Excel. Les fonctionnalités des personnalisations au niveau du document sont disponibles uniquement lorsque le document associé est ouvert. Ces personnalisations ne peuvent pas apporter de modifications à l’échelle de l’application, par exemple afficher un nouvel élément de menu ou onglet du Ruban lorsqu’un document est ouvert.

  • Compléments au niveau de l’application   Ces compléments se composent d’un assembly associé à une application Office. Le complément peut appeler le modèle objet afin d’automatiser et d’étendre l’application, et il peut utiliser toutes les classes du Microsoft .NET Framework.

L’outil OEAT peut être utilisé pour détecter uniquement les compléments au niveau de l’application.

Pour plus d’informations sur les compléments Office créés à l’aide de Visual Studio, voir Vue d’ensemble du développement des solutions Office (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=188380&clcid=0x40C) (éventuellement en anglais).

OEAT et OCCI

Processus d’évaluation et de correction de compatibilité des applications

La figure suivante illustre sous forme résumée le processus d’évaluation et de correction de compatibilité des applications. À chaque tâche définie sur cette figure correspond une section dans cet article.

Processus de compatibilité des applications

Notes

Ce guide ne traite pas de la compatibilité, de la conversion ou de la migration de documents. Pour plus d’informations sur la conversion de fichiers Office hérités et l’utilisation du mode de compatibilité, voir Compatibilité des documents pour Office 2010.

Planifier les tests de compatibilité

La planification de l’évaluation, de la correction et de la phase pilote des compléments et applications est une première étape importante du processus global de test de compatibilité des applications. Bien qu’il puisse être tentant de se fier à des résultats de tests de compatibilité d’Office System 2007 antérieurs, cela n’est pas recommandé et ne peut que retarder la réussite du déploiement.

Planifier l’évaluation

Les sections suivantes décrivent les tâches de planification qui vous aideront à préparer l’évaluation des compléments et applications dans votre organisation.

Créer un référentiel central pour la documentation d’évaluation et les résultats

Pour faciliter la gestion du processus d’évaluation et de correction, nous vous recommandons de créer un référentiel central des applications découvertes et de leur état. Une solution telle que Microsoft SharePoint Server 2010 peut faciliter le suivi du projet et aider tous les membres du projet à rester à jour.

Identifier les parties prenantes

Les parties prenantes sont les individus ou groupes qui approuvent ou allouent des ressources au projet. En identifiant les parties prenantes durant la phase initiale du projet, l’équipe de projet de compatibilité des applications est en mesure de communiquer et de valider les livrables du projet à tous les intervenants.

Le tableau suivant décrit les rôles typiques des parties prenantes dans un projet de compatibilité des applications.

Rôle Responsabilité

Propriétaire d’application

S’assurer que les processus métier exécutés à l’aide de la version précédente d’Office continuent sans interruption après la mise à niveau.

Sponsor de projet

Promouvoir le succès de la mise à niveau d’Office et assurer une publicité positive au sein de l’organisation.

Assigner des rôles aux participants au projet

Le tableau suivant décrit les rôles possibles (et leurs responsabilités respectives) qui doivent être remplis lors d’un projet de compatibilité d’applications.

Rôle Responsabilité

Responsable de projet

S’assurer du bon déroulement global du projet et gérer les ressources, métriques et risques globaux.

Testeur de validation de compatibilité

Suivre le plan de test et tester les composants Office afin de détecter les éventuels problèmes de compatibilité, notamment liés aux formats de fichiers, macros, compléments et automation Office.

Opérateur OEAT

Comprendre et effectuer l’installation et la configuration de l’outil OEAT.

Responsable de la correction

Effectuer les actions qui résolvent les problèmes de compatibilité liés aux personnalisations Office.

Testeur de régression

S’assurer que la correction exécutée sur un objet Office réussit. Ce rôle est souvent rempli par le Responsable de la correction.

Testeur d’acceptation des utilisateurs

Représentant d’une unité professionnelle affectée qui détermine que la correction d’une application a réussit et qu’elle n’interfère avec aucune autre personnalisation ou action. Il ne doit jamais s’agir de la personne qui effectue les tests de correction ou de régression.

Propriétaire ou analyste d’entreprise

Propriétaire du code et de la documentation des applications et compléments critiques pour l’unité professionnelle.

Responsable de groupe de déploiement

Propriétaire et responsable du respect du calendrier de l’ensemble du processus technique. Peut déléguer certaines activités d’administration et de rapport.

Groupe de packaging d’applications

Propriétaire du package d’installation Office 2010.

Équipe cliente (bureaux)

Propriétaire du déploiement du package Office 2010 par le biais de l’outil de gestion de configuration de l’organisation, tel que Systems Center Configuration Manager (SCCM).

Service d’assistance aux utilisateurs

Fournir un support technique fonctionnel pour Office aux testeurs et, à l’issue de la migration, aux utilisateurs.

Identifier et s’entretenir avec les unités professionnelles

L’étape suivante de planification de l’évaluation consiste à identifier les groupements de services ou d’unités professionnelles et de s’entretenir avec leurs représentants afin de bien comprendre dans quelle mesure l’ensemble actuel de compléments répond à leurs besoins professionnels. Connaître l’importance de chaque complément, sa fonction, pourquoi il a été créé, ce qu’il fait et qui l’a fait sont des éléments importants lorsqu’il s’agit de prendre une décision informée quant à la manière de corriger le complément et de résoudre les problèmes éventuels.

Il se peut que certains compléments Office aient été créés de manière informelle au sein de votre organisation. Par conséquent, un travail d’investigation peut s’avérer nécessaire pour identifier un propriétaire et le code source d’origine, s’il existe encore.

Vous pouvez vous servir du formulaire suivant comme modèle de questionnaire pour les entretiens.

Informations sur l’application

Unité professionnelle

Nom de l’application

Contact/propriétaire de l’application

ID d’application

Version

Priorité

Niveau

État de compatibilité Office 2010 s’il est connu (Succès, Échec)

Description du problème de compatibilité, si elle est disponible

Nombre d’utilisateurs

Version d’Office utilisée par l’application (XP, 2003, 2007, 2010, et ainsi de suite)

Décrire le genre d’utilisation (par exemple, exportation d’un document Office, complément d’une application Office, et ainsi de suite)

Composants de la suite Office utilisés par l’application

Word

Excel

Access

PowerPoint

Autre

Cette application utilise-t-elle des objets Office complexes tels que des graphiques, rapports de tableaux croisés dynamiques ou dessins ?

S’agit-il d’une application frontale ou de saisie des données ? Si oui, fournir des détails.

Quelles sont les langues prises en charge par l’application ?

Identifier les ordinateurs clients à analyser

Après avoir identifié les différentes unités professionnelles dont les ordinateurs clients doivent être analysés, vous pouvez commencé le processus d’identification d’un échantillon statistiquement représentatif d’ordinateurs clients pour chaque unité professionnelle. Il est inutile d’analyser tous les ordinateurs clients de votre organisation. Néanmoins, dans certains cas (selon la taille de l’organisation), l’analyse de l’environnement entier, d’un groupe entier ou d’une unité d’organisation entière peut s’avérer moins restrictive (ou plus facile) que la sélection d’ordinateurs clients spécifiques à analyser. Un échantillon statistiquement représentatif de 20 pour cent maximum doit fournir suffisamment d’informations pour évaluer et résoudre les problèmes de compatibilité dans votre environnement Office 2010.

Important

Microsoft .NET Framework 2.0 ou version ultérieure doit être installé sur tous les ordinateurs clients qui exécutent l’outil OEAT. Pour plus d’informations sur la configuration requise pour l’outil OEAT, voir Guide d’utilisation de l’outil OEAT (Office Environment Assessment Tool) pour Office 2010.

Si votre organisation ne dispose d’aucun inventaire des clients à jour, exécutez la boîte à outils Microsoft Assessment and Planning (MAP) pour générer un inventaire des clients et évaluer la préparation pour Office 2010. À partir de cet inventaire, vous pouvez collaborer avec les responsables des groupes professionnels afin de sélectionner un sous-ensemble d’ordinateurs clients devant être évalués avec l’outil OEAT. Pour plus d’informations sur la boîte à outils MAP, voir Boîte à outils Microsoft Assessment and Planning (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=149448\&clcid=0x40C) (éventuellement en anglais).

Planifier la correction

Les sections suivantes vous aideront à établir des critères de base afin de classer et corriger les applications incompatibles. Parvenir à un accord durant la phase préliminaire du processus de planification vous aidera à éviter tout désaccord ou autres retards une fois les résultats des tests et des évaluations disponibles.

Déterminer le mode de classement et d’affectation des priorités aux applications

Les entreprises développent, déploient et maintiennent une large gamme d’applications et de compléments basés sur Office qui peuvent tous avoir des valeurs sensiblement différentes pour l’organisation. Il est par conséquent important d’organiser les applications en classes ou niveaux en fonction de leur valeur pour l’entreprise. Une méthode simple consiste à classer une application comme critique ou non. Voici quelques autres catégories à prendre en considération :

  • Applications internes ou tierces

  • Applications spécifiques à un service

  • Solutions non gérées, telles que les modèles, compléments et macros créés par des utilisateurs finaux

  • Nombre d’utilisateurs de l’application

  • Utilisation de l’application par les cadres supérieurs

  • Durée de vie prévue de l’application

Le tableau suivant décrit la façon dont une organisation peut classer et affecter un ordre de priorité à différents genres de personnalisations Office.

Personnalisation Critique Non critique

Compléments d’automation

Analyse, test et correction OEAT proactifs

Réagir à l’utilisateur découvert

Compléments COM

Analyse, test et correction OEAT proactifs

Réagir à l’utilisateur découvert

Compléments VBA

Analyse, test et correction OEAT et OCCI proactifs

Réagir à l’utilisateur découvert

Pour affecter un ordre de priorité supplémentaire aux application critiques, vous pouvez les classer en Niveau 1, Niveau 2 ou Niveau 3. Voici un exemple de classification pour chaque niveau :

  • Niveau 1 : critique du point de vue des missions   Toute défaillance de ce genre d’application est dommageable à la continuité des activités de l’entreprise ou aux revenus de l’organisation. Toute application utilisée par les cadres supérieurs doit être considérée comme critique du point de vue des missions, quel que soit le nombre d’utilisateurs ou la priorité professionnelle de l’application. Ce niveau comprend également les applications utilisées par plus de 10 pour cent des utilisateurs de l’organisation.

  • Niveau 2 : critique du point de vue de l’entreprise   Ces applications sont critiques pour l’entreprise ou sont utilisées par au moins 10 pour cent des utilisateurs de l’organisation. Ce niveau peut également inclure les applications utilisées par 1 à 10 pour cent des utilisateurs de l’organisation et pouvant avoir un aspect prioritaire pour l’entreprise. Il ne s’agit pas d’applications critiques du point de vue des missions ou affectant les revenus de l’organisation. Néanmoins, elles peuvent indirectement entraîner une augmentation des dépenses ou une réduction des revenus en affectant la productivité.

  • Niveau 3 : applications métier   Ces applications ne sont pas critiques du point de vue des missions et peuvent affecter jusqu’à 10 employés ou 1 pour cent de l’organisation. Il s’agit en général d’outils qui aident à effectuer de petites tâches et qui ont un faible impact sur les activités de l’entreprise.

Identifier les stratégies de correction

Après avoir défini les critères de classification des applications, vous devez identifier les stratégies de correction potentielles. Bien que le travail de correction en lui-même soit difficile à planifier, vous pouvez établir des stratégies génériques facilitant la résolution des problèmes pour chaque genre de personnalisation. Le tableau suivant contient des suggestions de stratégies de correction basées sur le genre d’application et sa durée de vie prévue.

Type Stratégie potentielle

Application interne ayant une durée de vie limitée

Mettre l’application hors service et rechercher un nouveau processus.

Application interne ayant une durée de vie prolongée

Récrire ou retravailler le code en fonction du nouveau modèle objet.

Application tierce ayant une durée de vie limitée

Mettre l’application hors service et rechercher un nouveau processus.

Application tierce ayant une durée de vie prolongée

Contacter le fournisseur afin d’obtenir une mise à jour ou un produit de remplacement.

L’application ne fonctionne pas

Réinstaller l’application avec une nouvelle structure de répertoires ou créer un environnement virtuel pour l’application.

Durant la correction des applications, il se peut que leur priorité change par rapport à votre évaluation initiale. Il convient de mettre en place un processus strict pour les évaluations de correction afin d’autoriser uniquement le passage des applications à un niveau supérieur (et non à un niveau inférieur). Pour plus d’informations sur la façon dont Microsoft IT a catégorisé et affecté une priorité aux applications, voir Déploiement de Microsoft Office System 2007 (https://go.microsoft.com/fwlink/?linkid=178278\&clcid=0x40C).

Microsoft propose également des informations prescriptives sur TechNet concernant les problèmes connus qui se produisent lors de la migration de personnalisations Office. Pour plus d’informations, voir Modifications de produits et de fonctionnalités dans Office 2010. Certains partenaires de Microsoft proposent également des outils facilitant le processus de correction.

Planifier la phase pilote

L’équipe de projet doit également prendre en compte la phase pilote des compléments et applications. Plus spécifiquement, elle doit identifier les éléments suivants :

  • Quels sont les utilisateurs qui participeront à la phase pilote ?

  • Comment les utilisateurs de la phase pilote signaleront-ils les problèmes ?

  • Les employés du Service d’assistance participeront-ils à la phase pilote et, dans l’affirmative, comment seront-ils formés ?

  • Quand la phase pilote débutera-t-elle ? Par exemple, certaines organisations commencent les tests pilotes très tôt, durant la phase de planification, afin d’obtenir rapidement des commentaires à mesure du déroulement du processus.

Les ressources suivantes vous aideront à planifier la phase pilote. Elles ne sont pas spécifiques aux tests de compatibilité Office 2010, mais une grande partie des principes couverts dans ces ressources sont tout de même applicables.

Évaluer l’environnement

Durant la phase d’évaluation, vous devez dresser un inventaire des compléments et applications en exécutant l’outil OEAT sur un sous-ensemble d’ordinateurs clients statistiquement pertinent. Après avoir analysé les résultats et affecté un ordre de priorité aux applications, vous serez prêt à aborder la phase de test et de correction.

Exécuter l’outil OEAT

L’outil OEAT peut s’exécuter à partir d’un partage réseau ou être distribué aux utilisateurs. Il analyse les ordinateurs clients, puis enregistre les résultats des analyses à un emplacement désigné, généralement un partage réseau. Une fois les analyses terminées, vous pouvez utiliser l’outil OEAT pour compiler les résultats dans une feuille de calcul Microsoft Excel utilisable durant le processus de correction.

Vous pouvez déployer l’outil OEAT de l’une des manières suivantes, selon votre environnement :

  • Environnements Active Directory   Déployez l’outil OEAT à l’aide d’un script de connexion Active Directory. Lorsque les utilisateurs se connectent, l’outil OEAT s’exécute automatiquement et les résultats sont enregistrés à l’emplacement désigné.

  • Environnements gérés   Déployez l’outil OEAT au moyen d’une solution de gestion telle que Systems Management Server (SMS) ou System Center Configuration Manager (SCCM).

  • Environnements informatiques non gérés ou non centralisés   Créez un partage pour l’outil OEAT et fournissez des instructions aux utilisateurs quant à la manière d’exécuter une analyse manuellement.

Pour plus d’informations sur la façon de déployer et d’utiliser l’outil OEAT, voir Guide d’utilisation de l’outil OEAT (Office Environment Assessment Tool) pour Office 2010. Pour télécharger l’outil OEAT, voir Outil Office 2010 : Office Environment Assessment Tool (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0x40C) (éventuellement en anglais).

Examiner les résultats de l’outil OEAT

Une fois les analyses des ordinateurs clients terminées, utilisez l’option Compile results de l’outil OEAT pour créer une feuille de calcul récapitulant les résultats de tous les ordinateurs clients ayant été analysés. Cette feuille de calcul contient plusieurs feuilles, parmi lesquelles :

  • SummaryReport   Cette feuille de calcul contient des informations récapitulatives qui vous permettront de déterminer si vos ordinateurs clients analysés sont prêts pour Office 2010. Elle contient des données sur la quantité moyenne d’espace libre, les processeurs, les fabricants d’ordinateurs, les installations de Windows (y compris les niveaux de Service Pack) et les installations d’Office. Les données obtenues peuvent être intéressantes d’un point de vue de la gestion de configuration, dans le sens où les ordinateurs clients peuvent ne pas exécuter les versions d’Office ou de Windows auxquelles vous vous attendez.

  • MicrosoftOfficeAddins   Cette feuille de calcul contient une liste de tous les compléments fournis avec Office.

  • AddinsNotShippedWithOffice   Cette feuille de calcul contient une liste de tous les compléments non fournis avec Office. La plupart de vos décisions en matière d’évaluation et de planification dépendront des données de ce rapport. Vous pouvez trier la liste par application, afficher les dates de dernier accès ou de dernière modification et afficher le nombre d’ordinateurs clients sur lesquels le complément a été détecté. Vous pouvez également comparer les numéros de versions des mêmes compléments afin de déterminer si certains sous-ensembles d’ordinateurs clients sont obsolètes, ce qui pourrait traduire un problème au niveau des processus de gestion des configurations au sein de votre organisation.

Sous la feuille de calcul AddinsNotShippedWithOffice, commencez par la colonne Compatibility afin d’identifier l’état de compatibilité de chaque complément. L’outil OEAT génère les données de cette colonne en comparant les compléments découverts à la liste de compléments compatibles suivis par le programme « ISV Compatibility Program ». Les résultats d’état de compatibilité possibles sont les suivants :

  • UNKNOWN   Le complément ne figure pas actuellement dans la liste Microsoft des fournisseurs de compléments compatibles avec Office 2010. L’état de ce complément est par conséquent inconnu. Notez que cet état est susceptible de changer à mesure que de nouvelles données de fournisseurs sont mises à disposition de l’outil OEAT. Chaque fois que vous compilez la feuille de calcul, vous avez la possibilité de télécharger de nouvelles données de fournisseurs.

  • PARTIAL MATCH   L’outil OEAT indique cet état dans deux cas : lorsqu’il trouve une correspondance uniquement pour le nom du fournisseur ou lorsqu’il trouve une correspondance pour le nom du fournisseur et le nom du produit et que le numéro de version ne correspond pas. Utilisez le lien fourni dans la colonne URL pour consulter la liste des fournisseurs et vérifier les compléments compatibles proposés par ce fournisseur.

  • EXACT MATCH   Cet état est signalé lorsque le nom du fournisseur et du produit correspondent et que le numéro de version du complément est supérieur ou égal à celui de la version signalée par le fournisseur.

Important

La colonne Compatibility est absente si vous avez choisi de ne pas télécharger les données de compatibilité à l’invite dans la version finale de l’outil OEAT ou si vous utilisez la version bêta de l’outil OEAT. Vous pouvez télécharger la version finale de l’outil OEAT à partir du Centre de téléchargement Microsoft (éventuellement en anglais).

Finaliser les plans de correction

À ce stade, vous êtes prêt à mettre les résultats de l’outil OEAT en corrélation avec les critères de priorité que vous avez établis durant la phase de planification. Lors de la définition d’un planning pour ce travail, prévoyez suffisamment de temps pour étudier et affecter une priorité aux compléments qui n’ont pas été identifiés lors des entretiens avec les membres des unités professionnelles. Pour bien comprendre la portée des incompatibilités des compléments VBA et Visual Studio, l’équipe de développement peut exécuter l’outil OCCI durant cette phase afin d’identifier la quantité de code sous-jacent qui devra être modifiée.

Tester et résoudre les problèmes de compatibilité

Durant cette phase, votre équipe de développement et vous commencerez à tester les compléments et applications critiques du point de vue des missions et à haute priorité afin d’identifier les problèmes de compatibilité spécifiques au niveau d’Office 2010. Une fois les incompatibilités identifiées, l’équipe de développement commencera à corriger les compléments et applications incompatibles en fonction du travail que vous aurez effectué lors de la phase de planification.

Plusieurs applications et compléments étant corrigés en même temps, on ne peut pas supposer de manière certaine que ces corrections fonctionneront ensemble. Vous devez tester toutes les corrections ensemble, puis effectuer des tests pilotes dans un scénario de monde réel. Chaque étape est importante dans la validation des corrections, la stabilisation du déploiement global d’Office 2010 et la mise en œuvre d’une migration réussie.

Tester les compléments et applications

Les organigrammes suivants fournissent des instructions d’ordre général aux développeurs qui testent différents genres d’applications afin d’identifier les incompatibilités avec Office 2010. Pour obtenir une assistance supplémentaire, voir les ressources suivantes :

Tests d’applications généraux

L’organigramme suivant fournit une vue de haut niveau des tests d’applications. Les autres organigrammes de cette section décrivent le processus de test pour différents genres d’applications Office, telles que les compléments, les macros et les scripts, ainsi que le test d’automation Office.

Organigramme du test des applications

Test de complément Office

Organigramme du test des compléments Office

Test de macros et scripts

Organigramme du test des macros

Test d’automation Office

Organigramme du test automatique d’Office

Exécuter l’outil Office Code Compatibility Inspector

Dans le cadre du processus de test global, les développeurs peuvent exécuter l’outil OCCI pour rechercher les modifications ou désapprobations connues dans les membres de modèle objet. L’outil OCCI analyse également les instructions Declare VBA et les références à des DLL utilisées par des contrôles ActiveX qui doivent être mises à jour afin d’être compatibles avec Office 2010 64 bits. Lorsqu’il rencontre un problème de compatibilité potentiel, l’outil ajoute un commentaire dans le code afin d’attirer l’attention du développeur.

Chaque fois qu’une analyse de l’inspecteur est terminée, un rapport de synthèse et un rapport détaillé sur le projet sont fournis. Les éléments analysés sont les suivants :

  • Modifications   Toute modification syntaxique d’un membre de modèle objet est signalée. L’outil OCCI détecte l’utilisation de tout membre de modèle objet ayant changé depuis Office 97.

  • Désapprobations   Toute utilisation d’un membre de modèle objet désapprouvé est signalée. L’outil OCCI détecte l’utilisation de tout membre de modèle objet ayant été désapprouvé puis Office 97.

Pour plus d’informations sur l’utilisation de l’outil OCCI, voir le Guide d’utilisation de l’Inspecteur de compatibilité du code Microsoft Office. Pour obtenir les ressources de développement propres aux applications, notamment des détails sur les modifications apportées au modèle objet depuis les versions antérieures d’Office, voir Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=206197\&clcid=0x40C).

Corriger les compléments et applications

Il existe plusieurs manières d’aborder la correction d’une application ou d’un complément ayant un problème de compatibilité avec Office 2010. Les sections suivantes décrivent brièvement les options de correction.

Obtenir des mises à jour auprès des fournisseurs

Les rapports de l’outil OEAT fournissent des liens vers des compléments connus comme compatibles. Toutefois, certaines applications peuvent ne pas figurer sur cette liste. Dans ce cas, vous devez contacter directement le fournisseur. Soyez prêt à développer des solutions de contournement temporaires pour le cas où le complément mis à jour ne serait pas disponible à temps pour votre migration ou dans le cas où aucune mise à jour du complément ne serait prévue (ou si le fournisseur n’est plus en activité). Si aucune solution de contournement temporaire n’est disponible, optez pour la virtualisation ou l’installation en parallèle.

Mettre à jour les applications internes

Lorsque vous possédez le code source et que vous comprenez comment le complément ou l’application fonctionne, ou lorsque vous possédez la documentation et que l’équipe de développement d’origine est toujours active ou peut être consultée, les conditions idéales sont réunies pour mettre à jour une application interne. Le processus de mise à jour des applications internes est grandement simplifié grâce à l’outil OCCI, qui identifie les fonctions incompatibles dans le code source. L’équipe de développement devra tout de même implémenter elle-même les correctifs nécessaires, mais il lui sera beaucoup plus facile de localiser le code incompatible en faisant appel à l’outil OCCI.

Notes

Si la plateforme d’écriture de l’application interne est très ancienne (par exemple Visual Basic 6 ou version antérieure), nous vous recommandons de récrire entièrement l’outil à l’aide du .NET Framework.

Les instructions suivantes seront utiles aux développeurs qui doivent mettre à jour des applications internes.

Compléments créés à l’aide de Visual Studio

Les composants d’exécution pour Office 2010 ont été créés de sorte que les compléments, solutions de documents et solutions de feuilles de calcul .NET Outils Microsoft Visual Studio pour Applications et Visual Studio 2008 s’exécutent tous sur Office 2010 64 bits. Ces composants d’exécution sont installés avec Office 2010. Par conséquent, il est inutile pour les administrateurs d’inclure une installation distincte pour ce runtime. En revanche, certains éléments doivent être pris en compte.

Dans un projet Visual Studio, le code C# ou Visual Basic peut être compilé en langage MSIL (Microsoft Intermediate Language) lorsque l’option Any CPU est utilisée. Au moment de l’exécution, le MSIL est compilé Just in Time (JIT) selon la puce correcte, AMD ou Intel 32 bits ou 64 bits. Toutefois, cette technologie ne s’applique pas aux versions 1.0 et 1.1 du .NET Framework. Ces versions n’autorisent pas cette transformation 64 bits.

Vous devez même examiner le code .NET Framework 2.0 conforme, car tout appel à un appel de processus (p/invoke) dans votre code est natif (spécifique à l’architecture de processeur). Si vous essayez d’appeler des méthodes API natives à l’aide de p/invoke, votre solution VSTO risque de ne pas fonctionner correctement sur Office 2010 64 bits.

Des problèmes peuvent également survenir si le code effectue des appels délibérés à une API Win32 qui n’a pas exactement la même signature (nom de méthode, liste de paramètres et nom de DLL) qu’une API Win64. Ceci est valable pour toute solution, qu’il s’agisse d’une solution Office ou Windows.

Pour plus d’informations sur la façon de créer des solutions pour Office 2010 64 bits, voir Applications 64 bits pour Visual Studio 2005 (https://go.microsoft.com/fwlink/?linkid=178279\&clcid=0x40C) et Applications 64 bits pour Visual Studio 2010 (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=152431\&clcid=0x40C) (éventuellement en anglais) dans la bibliothèque technique MSDN.

Solutions et macros VBA

Les solutions et macros créées avec Visual Basic pour Applications (VBA) fonctionneront tant qu’elles interfacent avec le modèle objet Office 2010. Toutefois, il se peut que certains appels soient désapprouvés et ne fonctionnent plus. Si du code VBA utilise des appels d’API Windows, il est probable qu’il s’agisse de DLL 32 bits. Une solution simple consiste à mettre à jour le code de sorte que les instructions Declare utilisent le mot clé PtrSafe. Vous pouvez recourir à l’outil CCI pour identifier ces instructions Declare. Pour plus d’informations sur la compatibilité 64 bits VBA, voir Compatibilité entre les versions 32 bits et 64 bits d’Office 2010 (https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0x40C).

Contrôles ActiveX

Les contrôles ActiveX 32 bits natifs (vraisemblablement tous les contrôles compatibles avec Office System 2007 et les versions antérieures d’Office) ne sont pas pris en charge dans Office 2010 64 bits. La procédure de correction pour ces contrôles nécessite une recompilation (si le code source est disponible), l’obtention d’une mise à jour auprès du fournisseur ou le recours à une méthode de virtualisation. Là encore, pour plus d’informations sur la compatibilité 64 bits VBA, voir Compatibilité entre les versions 32 bits et 64 bits d’Office 2010 (https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0x40C).

Applications Outlook

Outlook 2010 applique un nouveau processus d’arrêt rapide pour les compléments. Le nouveau processus d’arrêt permet d’éviter les délais provoqués par les compléments qui ne libèrent pas les ressources lorsque l’utilisateur Outlook. Bien que cette modification puisse nuire à certains compléments existants, les fournisseurs de compléments et les administrateurs informatiques peuvent résoudre les problèmes résultants en rétablissant le processus standard d’arrêt des compléments dans Outlook. Pour plus d’informations sur le nouveau processus d’arrêt, voir Modifications de l’arrêt d’Outlook 2010 (https://go.microsoft.com/fwlink/?linkid=203255\&clcid=0x40C).

Les extensions de client Exchange ne sont pas chargées dans Outlook 2010. Certaines applications tierces telles que des solutions d’archivage ou de sécurité utilisent ces extensions et doivent être mises à jour pour Outlook 2010. Pour plus d’informations, voir Annonce de l’obsolescence des extensions de client Exchange (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=203888\&clcid=0x40C) (éventuellement en anglais).

Si vous installez Outlook 2010 64 bits, vous devez mettre à jour les applications MAPI, les compléments et les macros 32 bits d’Outlook vers la version 64 bits. Pour plus d’informations, voir Éditions 64 bits d’Office 2010, Génération d’applications MAPI sur des plateformes 32 bits et 64 bits (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=203889\&clcid=0x40C) (éventuellement en anglais) et Développement de solutions Outlook 2010 pour des systèmes 32 bits et 64 bits (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=208699\&clcid=0x40C) (éventuellement en anglais).

Utiliser des installations parallèles ou la virtualisation

En l’absence d’une solution de réécriture de code réalisable, des options supplémentaires peuvent vous aider à trouver une solution à un problème de compatibilité.

  • Si vous avez fait des demandes auprès de fournisseurs en vue d’obtenir des mises à jour de compléments et que ces mises à jour risquent d’être publiées au-delà de votre date de déploiement, vous pouvez choisir d’installer Office 2003 ou version antérieure en parallèle avec Office 2010 (ou simplement les applications spécifiques en attente de mise à jour, telles que Office Excel 2003).

    Notes

    Si vous effectuez une mise à niveau vers une version 64 bits d’Office 2010, vous ne pouvez pas avoir une installation parallèle d’Office System 2007 (ou version antérieure). Toutes les versions précédentes sont disponibles uniquement en versions 32 bits.

  • Si vous exécutez Windows 7, vous pouvez installer une installation parallèle d’Office 2003 (ou version antérieure) en mode de compatibilité Windows XP ou, si vous exécutez une version antérieure d’Office, vous pouvez l’installer dans un environnement informatique virtuel.

  • Utilisez App-V (anciennement appelé SoftGrid). Pour plus d’informations sur App-V, voir Microsoft Application Virtualization 4.6 (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=143973\&clcid=0x40C) (éventuellement en anglais).

  • Utilisez les services Windows Terminal Server et sélectionnez l’une des deux options suivantes :

Exécuter la phase pilote des compléments et applications corrigés

La phase pilote est la dernière étape majeure avant le déploiement d’Office 2010. Le pilote constitue l’ultime test pour les options de correction et l’équipe de projet se doit de rester impliquée tout au long de cette phase pilote d’Office 2010 afin d’identifier et de résoudre les éventuels problèmes. Durant la phase pilote, votre équipe de gestion de versions surveille un environnement contrôlé dans lequel les utilisateurs exécute leurs tâches professionnelles ordinaires à l’aide des nouvelles fonctionnalités, y compris les compléments et applications corrigés qui interagissent avec Office 2010. Ceci permet de vérifier que les corrections fonctionnent comme prévu et que les exigences professionnelles de l’organisation sont satisfaites.

Une approche itérative doit être adoptée afin de résoudre les problèmes éventuellement identifiés, de concevoir un nouveau scénario de test, d’effectuer les tests, puis de redéployer les applications mises à jour dans le pilote en vue d’un examen supplémentaire. Une attention particulière doit être apportée au fonctionnement de ces options, aux commentaires fournis par les utilisateurs et aux éventuels problèmes qui limitent la portée ou la fonctionnalité du complément ou de l’application corrigé(e).

Pour plus d’informations sur la façon de stabiliser et de piloter des applications, voir Stabiliser la fonction de gestion de service (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=115624\&clcid=0x40C) (éventuellement en anglais) dans Microsoft Operations Framework 4.0, dans la bibliothèque technique TechNet.