Partager via

Sélection d’une API ou d’une technologie pour le développement de solutions pour Outlook

  • Article

Cet article décrit les API et technologies que vous pouvez utiliser pour étendre Outlook 2013 et Outlook 2016. Il vous aide à choisir l’API ou la technologie adaptée à votre scénario.

Microsoft prend en charge diverses API et des technologies qui étendent Outlook :

  • Nouveauté dans Office 2013 : la plateforme d'applications pour Office offre des possibilités d'extension des fonctionnalités Outlook dans les clients Outlook sur ordinateur de bureau, tablette et smartphone. La plateforme comprend une interface API JavaScript pour Office et un schéma pour les manifestes d'application.

  • Le modèle objet, l'assembly PIA (Primary Interop Assembly) d'Outlook correspondant et l'API de messagerie (MAPI) sont les API les plus couramment utilisées dans les solutions Outlook.

  • Les API auxiliaires complètent MAPI dans certains scénarios.

  • L'extensibilité du fournisseur Outlook Social Connector (OSC) et l'extensibilité de la barre météorologique sont utilisées dans des scénarios propres à leurs marchés ciblés.

Cet article explique les critères de sélection de la plateforme Compléments Office, du modèle objet, de l'assembly PIA et de MAPI. Compléments Office utilisent l'interface API JavaScript pour Office et n'appellent pas le modèle objet, et vice-versa. Les solutions qui utilisent d'autres API peuvent utiliser une ou plusieurs API. Par exemple, un complément COM écrit en C++ peut utiliser le modèle objet, MAPI et les API auxiliaires dans la même solution.

Pour profiter pleinement de cet article, vous devez connaître Outlook au niveau utilisateur et posséder des connaissances générales en matière de développement logiciel. Toutefois, il n'est pas nécessaire que vous maîtrisiez complètement toutes les fonctionnalités prises en charge par ces API ou technologies. L'article vous permet de répondre aux questions suivantes :

  • Si vous avez seulement une idée des objectifs de votre solution, du marché cible et des ressources disponibles, de quels autres critères devez-vous tenir compte pour choisir une API ?

  • Pourquoi envisageriez-vous d'utiliser les Compléments Office, et à quel moment choisiriez-vous de créer des applications au lieu de compléments ?

  • Si votre solution doit être exécutée sur des versions antérieures d'Outlook, notamment Outlook 2003, en quoi cela a-t-il une incidence sur le choix de votre API ?

  • Si votre solution doit itérer dans des dossiers Outlook qui contiennent des milliers d'éléments, et que vous devez pouvoir modifier ces derniers, quelle serait l'API la plus adaptée ?

  • Si votre solution dépend significativement de la logique métier Outlook et interagit avec d'autres applications Office, le modèle objet Outlook est-il le meilleur choix ?

  • Quels éléments le modèle objet et MAPI vous permettent-ils d'étendre dans Outlook ?

  • Si vous pouvez utiliser le modèle objet ou MAPI pour obtenir votre tâche, comment choisir l’API à utiliser ?

Déterminer les critères d’évaluation

Cette section décrit les critères que vous pouvez utiliser pour comparer la plateforme des Compléments Office, le modèle objet, l'assembly PIA et MAPI pour déterminer lequel correspond le mieux à vos besoins. Les différents critères peuvent avoir plus ou moins d'importance, en fonction de vos projets et des ressources disponibles.

Les tableaux de cette section définissent les critères d'évaluation dans les catégories suivantes :

  • Critères fonctionnels : décrit les opérations que vous pouvez et ne pouvez pas effectuer avec la technologie.

  • Critères de développement : décrit les outils de développement ou les informations nécessaires pour utiliser la technologie.

  • Critères de sécurité : décrit les problèmes de sécurité et d'autorisations liés à la technologie.

  • Critères de déploiement : décrit les méthodes de déploiement et de distribution recommandées pour la technologie.

Critères d'évaluation objectifs pour la plateforme des applications pour Office

Depuis la version Office 2013, les développeurs peuvent utiliser la plateforme des Compléments Office afin d'étendre le contenu et les services web dans le contexte de clients riches et web Office. Une Complément Office est une page web développée à l'aide des technologies web courantes, hébergée dans une application cliente Office (telle qu'Outlook) et qui peut être exécutée en local ou dans le cloud. Parmi les quelques types d'Compléments Office, celui pris en charge par Outlook est nommé applications de messagerie. Si le modèle objet, l'assembly PIA et MAPI sont souvent utilisés pour automatiser Outlook au niveau de l'application, vous pouvez utiliser l'interface API JavaScript pour Office afin d'interagir à un niveau d'élément avec le contenu et les propriétés du message électronique, de la demande de réunion ou du rendez-vous. Vous pouvez publier des applications de messagerie dans l'Office Store ou un catalogue Exchange interne.

Les utilisateurs finals et les administrateurs peuvent installer des applications de messagerie sur une boîte aux lettres Exchange et les utiliser dans le client riche Outlook, ainsi que dans Outlook Web App. En tant que développeur, vous pouvez choisir de rendre votre application de messagerie disponible uniquement sur ordinateur de bureau, ou également sur tablette et smartphone. La figure 1 montre un exemple d'une application de messagerie YouTube, qui est décrite en détail dans l'article Exemple : Créer une application de messagerie pour visualiser des vidéos YouTube dans Outlook. Cette application de messagerie permet aux utilisateurs finals de sélectionner l'URL d'une vidéo YouTube et de regarder la vidéo dans Outlook ou Outlook Web App sur ordinateur de bureau ou tablette.

Figure 1. L’application de messagerie YouTube est active pour le message sélectionné, qui contient une URL vers une vidéo sur YouTube.com

Application de messagerie avec YouTube dans Outlook

Après avoir été installée, l'application de messagerie peut être utilisée dans la barre de l'application lorsque le contexte actuel correspond aux conditions d'activation spécifiées par cette dernière. Une application de messagerie vous permet d'indiquer des règles concernant l'élément actuellement sélectionné qui active une application de messagerie dans certaines conditions uniquement. Par exemple, l'application de messagerie YouTube, qui vous permet de lire une vidéo YouTube dans Outlook est utile uniquement lorsque l'élément Outlook sélectionné contient une URL vers une vidéo sur YouTube.com. Dans ce cas, vous devez indiquer que l'application doit être active uniquement lorsque le message sélectionné contient une URL de ce type.

Les tableaux suivants présentent les critères d'évaluation de la plateforme des Compléments Office.

Critères fonctionnels

Critères Prise en charge des applications de messagerie dans la plateforme des applications pour Office
Domaine d'application L'étendue d'activité d'une application de messagerie comporte pratiquement tout élément de message ou de rendez-vous pris en charge dans la boîte aux lettres Exchange sélectionnée par l'utilisateur et qui remplit les conditions d'activation. Les autorisations d'une application de messagerie déterminent son accès aux propriétés et entités spécifiques (telles qu'une adresse électronique ou un numéro de téléphone) existantes pour cet élément. Par exemple, une application de messagerie demandant l'autorisation boîte aux lettres en lecture-écriture peut lire et écrire toutes les propriétés de tout élément figurant dans la boîte aux lettres de l'utilisateur ; créer, lire et écrire dans tout dossier ou élément ; et envoyer un élément à partir de cette boîte aux lettres.
Objets principaux L'interface API JavaScript pour Office fournit quelques objets au niveau supérieur partagés par tous les types d'Compléments Office : Office, Context et AysncResult. Le prochain niveau dans l'API applicable et propre aux applications de messagerie comprend les objets Mailbox, Item et UserProfile, qui prennent en charge l'accès aux informations relatives à l'utilisateur et à l'élément actuellement sélectionnés dans la boîte aux lettres de l'utilisateur. Au niveau des données, les objets CustomProperties et RoamingSettings prennent en charge les propriétés persistantes configurées par l'application de messagerie pour l'élément sélectionné et pour la boîte aux lettres de l'utilisateur, respectivement. Les objets de niveau élément comprennent les objets Appointment et Message qui héritent de l'objet Item, ainsi que l'objet MeetingRequest qui hérite de l'objet Message. Ces objets représentent les types d'éléments Outlook qui prennent en charge les applications de messagerie : éléments de calendrier de rendez-vous et réunions, et éléments de message tels que les messages électroniques, les demandes de réunion, les réponses et les annulations. Au-delà de ce niveau dans l'API, il s'agit de propriétés de niveau élément (telles que Appointment.subject), ainsi que d'objets et de propriétés qui prennent en charge certains objets Entities connus (par exemple Contact, MeetingSuggestion, PhoneNumber et TaskSuggestion). Vue d'ensemble de l'architecture et des fonctionnalités des compléments Outlook pour obtenir un résumé des fonctionnalités prises en charge pour les applications de messagerie.
Modèle d'accès aux données L'interface API JavaScript pour Office représente les fonctionnalités suivantes sous la forme d'un ensemble hiérarchique d'objets : l'environnement d'exécution de l'application, la boîte aux lettres et le profil de l'utilisateur et les données relatives à un élément.
Modèles de thread Chaque application de messagerie s'exécute dans son propre processus distinct du processus Outlook.
Architectures d'application Dans Outlook, une application de messagerie est un ensemble de pages web HTML et JavaScript hébergées en tant que processus distinct dans un contrôle de navigateur web qui, à son tour, est hébergé dans un processus d'exécution d'application qui offre une séparation de la sécurité et des performances.
Utilisation à distance Les applications de messagerie utilisent l'interface API JavaScript pour Office pour accéder aux données relatives à l'utilisateur actuel, à la boîte aux lettres et à l'élément sélectionné stocké sur le serveur Exchange Server correspondant. Si elles disposent des autorisations appropriées et qu'elles utilisent la technique appropriée pour l'accès inter-domaines, les applications de messagerie peuvent également appeler les services web Exchange, ainsi que d'autres services web tiers pour étendre leurs fonctionnalités.
Transactions L'interface API JavaScript pour Office ne prend pas en charge les transactions.
Disponibilité L'interface API JavaScript pour Office est disponible pour les boîtes aux lettres sur Exchange Server 2013, à partir de la version Outlook 2013.

Critères de développement

Critères Prise en charge des applications de messagerie dans la plateforme des applications pour Office
Langages et outils Vous pouvez implémenter des applications de messagerie à l'aide de n'importe quelle technologie web courante, notamment HTML5, JavaScript, CSS3, XML et les API REST. Vous pouvez utiliser votre outil de développement web par défaut. Vous pouvez également utiliser Outils de développement Office 365 « Napa », Visual Studio 2012 ou une version ultérieure de ces outils et bénéficier de leurs avantages pour gagner du temps dans votre développement.
Implémentation managée Si nécessaire dans votre scénario, vous pouvez utiliser des pages .aspx managées pour implémenter du code sur le serveur pour vos applications de messagerie.
Peut contenir des scripts L'interface API JavaScript pour Office est directement utilisée dans les scripts.
Outils de test et de débogage Vous pouvez utiliser les outils de développement que vous préférez. Outils de développement Office 365 « Napa » et Visual Studio fournissent un environnement de développement intégré qui facilite le test et le débogage d'applications. Résoudre les problèmes d'activation des compléments Outlook et Exemple : Propriétés de débogage des éléments Outlook vous offrent une aide supplémentaire concernant la résolution des problèmes et le débogage des applications de messagerie.
Disponibilité des experts Il est assez aisé de trouver des programmeurs possédant le niveau requis d'expertise de développement web pour les Compléments Office. La plateforme est destinée aux développeurs professionnels et non professionnels.
Informations disponibles Des informations relatives au développement et à la publication d'Compléments Office sont disponibles sur la page Centre pour développeurs Office. La page Compléments Outlook contient de la documentation spécifique concernant les applications de messagerie.
Gestion des licences de développeur et de déploiement Reportez-vous à Gérer les licences de compléments pour Office et SharePoint pour plus d'informations sur l'infrastructure de gestion de licences d'application pour les Compléments Office.

Critères de sécurité

Critères Prise en charge des applications de messagerie dans la plateforme des applications pour Office
Autorisations attribuées au moment de la conception Aucune autorisation spéciale n'est requise pour développer des applications de messagerie.
Autorisations d'installation Par défaut, les utilisateurs finals et les administrateurs peuvent installer des applications de messagerie à faible niveau de confiance qui nécessitent l'autorisation élément restreint ou élément lu. Les administrateurs peuvent installer des applications de messagerie à niveau de confiance élevé qui nécessitent l'autorisation boîte aux lettres en lecture-écriture.
Autorisations d'exécution Les applications de messagerie nécessitent un niveau d'autorisation spécifique fondé sur un modèle d'autorisations à trois niveaux : élément restreint, élément lu et boîte aux lettres en lecture-écriture.
Fonctionnalités de sécurité intégrées Le runtime des compléments Office offre les avantages suivants pour empêcher une application d’endommager l’environnement de l’utilisateur final : isole le processus dans lequel l’application s’exécute. Ne nécessite pas de remplacements de .dll ou de .exe, ni de composants ActiveX. Facilite l'installation ou la désinstallation des applications par l'utilisateur final. L'administrateur et les utilisateurs finals contrôlent les applications de messagerie rendues disponibles et peuvent décider d'accorder l'autorisation demandée avant l'installation d'une application de messagerie. Dans le cas de clients riches, régit l'utilisation de la mémoire et de l'UC pour empêcher des attaques malveillantes par déni de service.
Fonctionnalités de surveillance de la sécurité Pour les applications de messagerie, les ressources suivantes sont surveillées : utilisation du cœur du processeur. Utilisation de la mémoire. Nombre d'incidents. Durée du blocage d'une application. Temps de réponse d'expression régulière. Nombre de réévaluations d'expressions régulières. Les administrateurs peuvent écraser les paramètres par défaut qui régissent l'utilisation des ressources.

Critères de déploiement

Critères Prise en charge des applications de messagerie dans la plateforme des applications pour Office
Exigences en matière de plateforme de serveur La boîte aux lettres de l'utilisateur pour laquelle une application de messagerie est installée doit se trouver sur Exchange Server 2013 ou une version ultérieure.
Exigences en matière de plateforme cliente Outlook 2013 et Internet Explorer 9, ou une version ultérieure de ces applications, doivent être installés sur l'ordinateur local pour qu'une application de messagerie puisse s'exécuter sur le client riche Outlook.
Méthodes de déploiement Vous pouvez publier des applications de messagerie dans l'Office Store ou un catalogue Exchange qui met l'application à disposition des utilisateurs sur ce serveur Exchange Server. Les administrateurs ou utilisateurs peuvent ensuite choisir d'installer une application de messagerie à partir de l'Office Store ou d'un catalogue Exchange, en utilisant le centre d'administration Exchange ou en exécutant les cmdlets Windows PowerShell distantes. Vous pouvez accéder au centre d'administration Exchange à partir du mode Backstage d'Outlook ou d'Outlook Web App, ou en vous connectant directement au centre d'administration Exchange pour votre boîte aux lettres. Pour plus d'informations, voir Déployer et installer des compléments Outlook à des fins de test.
Remarques relatives au déploiement Après avoir installé une application de messagerie sur Outlook ou Outlook Web App, celle-ci est disponible pour cette boîte aux lettres sur les deux clients Outlook.

Critères d'évaluation objectifs pour le modèle objet et l'assembly PIA

Les solutions qui sont exécutées sur l'ordinateur client peuvent utiliser le modèle objet ou l'assembly PIA d'Outlook pour accéder à des éléments Outlook par programmation, tels que les contacts, messages, éléments de calendrier, demandes de réunion et tâches. Contrairement à MAPI, le modèle objet ou l'assembly PIA d'Outlook peut fournir des notifications d'événements concernant des modifications apportées à l'interface utilisateur d'Outlook, telles que la modification du dossier actuel ou l'affichage d'un inspecteur Outlook.

Remarque

[!REMARQUE] Outlook doit être installé et configuré sur l'ordinateur client sur lequel est exécutée l'application pour qu'une solution puisse accéder à des données stockées dans une boîte aux lettres Microsoft Exchange ou un fichier (.pst) de dossiers personnels. > Le modèle objet et l’assembly PIA Outlook prennent en charge les mêmes fonctionnalités pour étendre Outlook. L'assembly PIA définit les interfaces gérées qui correspondent au modèle objet COM et avec lesquelles une solution gérée peut interagir. Dans les discussions restantes de cette section, la plupart des critères fonctionnels, de sécurité et de déploiement s'appliquent de la même façon au modèle objet et à l'assembly PIA. Pour plus d’informations sur la façon dont l’assembly PIA facilite l’interopérabilité entre COM et .NET Framework, consultez Présentation de l’interopérabilité entre COM et .NET et Architecture de l’assembly PIA Outlook.

Les tableaux suivants présentent les critères d'évaluation pour le modèle objet Outlook et un assembly PIA.

Critères fonctionnels

Critères Modèle objet Outlook ou assembly PIA
Domaine d'application En règle générale, les compléments ou applications autonomes qui utilisent l'objet modèle ou l'assembly PIA d'Outlook gèrent des messages propres à un utilisateur, personnalisent l'interface utilisateur Outlook, ou créent des types d'éléments personnalisés pour des solutions spécialisées, telles que des solutions de gestion de la relation client (CRM) qui s'intègrent à Outlook. Le modèle objet ou l'assembly PIA d'Outlook est parfois utilisé pour le traitement de messages dans un processus de flux de travail informel, surtout lorsque le développement d'applications sur le serveur Microsoft Exchange Server n'est pas autorisé. Contrairement aux clients basés sur le navigateur, l'opération en mode mis en cache permet aux solutions Outlook de fonctionner lorsque l'utilisateur est hors ligne ou déconnecté du réseau d'entreprise.
Objets principaux L'objet de niveau supérieur dans le modèle objet et l'assembly PIA d'Outlook est l'objet Application d'Outlook. Les objets Explorers, Conversation, Inspectors, Views, NavigationPane, SolutionsModule, FormRegion et les objets liés représentent des éléments de l'interface utilisateur Outlook. Les objets NameSpace, Stores, Folders, Accounts, AccountSelector, AddressEntries, ExchangeUser et objets liés prennent en charge l'extension de sessions, profils, comptes d'utilisateur, banques de messages et dossiers Outlook. Au niveau des données, un nombre d'objets de niveau élément, tels que MailItem, AppointmentItem, ContactItem et TaskItem représentent les types d'éléments Outlook intégrés. Les objets PropertyAccessor, Table, Search, ItemProperties, UserDefinedProperties, Attachments, Categories, Recipients, RecurrencePattern, Reminders, Rules et objets liés prennent en charge la personnalisation et la manipulation d'objets de niveau élément.
Modèle d'accès aux données Le modèle objet et l'assembly PIA d'Outlook représentent toutes les données sous la forme d'un ensemble hiérarchique d'objets et de collections.
Modèles de thread Tous les appels vers le modèle objet et l'assembly PIA d'Outlook s'exécutent sur le thread principal au premier plan d'Outlook. Le modèle de thread unique pris en charge par le modèle objet Outlook est un thread unique cloisonné (STA). L'appel d'un modèle objet ou de l'assembly PIA d'Outlook à partir d'un thread d'arrière-plan n'est pas pris en charge et peut être à l'origine d'erreurs et de résultats inattendus dans votre solution.
Architectures d'application En général, les compléments COM et autres applications Office utilisent le modèle objet Outlook pour étendre Outlook. Les solutions gérées peuvent utiliser l'assembly PIA d'Outlook et la couche d'interopérabilité COM de Visual Studio et .NET Framework pour accéder au modèle objet Outlook. Visual Studio fournit des modèles, ainsi que des bibliothèques de classes et des manifestes supplémentaires pour faciliter les personnalisations de documents et d'applications Office. Pour plus d'informations sur l'utilisation de Visual Studio dans le but de développer des compléments pour Outlook, voir Architecture of Application-Level Add-Ins et Outlook Solutions. Le modèle objet Outlook prend également en charge les macros Visual Basic pour Applications (VBA) macros et Windows Scripting Host (WSH), mais ne prend pas en charge les applications de service Windows.
Utilisation à distance Le modèle objet et l'assembly PIA d'Outlook peuvent être uniquement utilisés sur un ordinateur sur lequel Outlook est installé. Le modèle objet Outlook peut être utilisé pour accéder à des informations stockées dans Exchange disponibles dans l'application Outlook.
Transactions Le modèle objet et l'assembly PIA d'Outlook ne prennent pas en charge les transactions.
Disponibilité Le modèle objet Outlook est actuellement disponible dans toutes les versions d'Outlook. L'assembly PIA est disponible dans les versions d'Outlook depuis Outlook 2003. Des extensions et des améliorations ont été apportées à chaque nouvelle version d’Outlook.

Critères de développement

Critères Modèle objet Outlook ou assembly PIA
Langages et outils Vous pouvez implémenter des applications de modèle objet Outlook à l'aide d'un langage COM ou compatible avec Automation, tel que Visual Basic ou C#, ainsi que des langages autres que COM, tels que native C ou C++. Les Outils de développement Microsoft Office dans Microsoft Visual Studio 2010 sont les outils préférés pour le développement de compléments gérés pour Outlook 2010 et Outlook 2007. Les outils Microsoft Visual Studio 2005 Tools pour Microsoft Office System sont les outils préférés pour Outlook 2003. Vous pouvez également utiliser Outils de développement Office dans Visual Studio 2010 pour créer des solutions pour les versions 32 bits et 64 bits d'Outlook. Lors de la création d'une solution dans Outils de développement Office dans Visual Studio 2010 ou dans Microsoft Visual Studio Tools pour Microsoft Office System, l'indication de l'option N'importe quelle UC pour la plateforme cible permet d'avoir des solutions gérées fonctionnant pour les versions 32 bits et 64 bits d'Outlook 2010.
Implémentation managée L’assembly PIA Outlook permet d’utiliser le modèle objet Outlook dans un environnement de code managé, qui est pris en charge par un ensemble complet de bibliothèques de classes et de technologies de prise en charge qui répondent à de nombreuses limitations des compléments VBA et COM. L’assembly PIA est un wrapper COM qui agit comme un pont entre les environnements managés et COM. Pour plus d’informations, voir Why Use the Outlook PIA.
Peut contenir des scripts Le modèle objet Outlook peut être utilisé dans des scripts.
Outils de test et de débogage Aucun outil de débogage spécial n'est nécessaire pour utiliser le modèle objet ou l'assembly PIA d'Outlook. En revanche, vous pouvez utiliser Visual Studio pour fournir un environnement de développement intégré qui facilite le test et le débogage d'applications.
Disponibilité des experts Il est assez aisé de trouver des développeurs qui peuvent développer des applications à l'aide du modèle objet ou de l'assembly PIA d'Outlook. Ces derniers sont conçus pour des compléments créés à l'aide d'outils de développement disponibles à grande échelle, tels que Visual Studio. Ces outils fournissent des environnements au moment de la conception qui simplifient le processus de développement.
Informations disponibles Des informations relatives à la programmation à l'aide du modèle objet Outlook sont disponibles dans des ressources Microsoft et tierces. Pour plus d'informations sur le modèle objet Outlook, voir Référence pour le développeur Outlook 2010. Pour plus d'informations sur l'assembly PIA d'Outlook, voir Référence pour l'assembly PIA (Primary Interop Assembly) d'Outlook 2010. Pour des exemples de solutions Outlook gérées développées à l'aide des outils de développement Office dans Visual Studio, voir Outlook pour les développeurs.
Gestion des licences de développeur et de déploiement Reportez-vous au contrat de licence de vos abonnements Exchange et Microsoft Developer Network (MSDN) pour déterminer si des licences supplémentaires sont nécessaires pour l'utilisation d'Outlook et du modèle objet Outlook dans vos applications.

Critères de sécurité

Critères Modèle objet Outlook ou assembly PIA
Autorisations attribuées au moment de la conception Aucune autorisation spéciale n'est nécessaire pour développer des applications à l'aide du modèle objet ou de l'assembly PIA d'Outlook.
Autorisations d'installation Aucune autorisation spéciale n'est nécessaire pour installer des applications qui utilisent le modèle objet ou l'assembly PIA d'Outlook. Toutefois, les droits d'administrateur local sont requis pour installer Office et Outlook.
Autorisations d'exécution Aucune autorisation spéciale n'est nécessaire pour exécuter des applications qui utilisent le modèle objet ou l'assembly PIA d'Outlook.
Fonctionnalités de sécurité intégrées Le modèle objet et l'assembly PIA d'Outlook communiquent avec Exchange à l'aide de MAPI et avec Active Directory à l'aide des interfaces ADSI (Active Directory Service Interfaces). Le contexte de sécurité actuel de l'utilisateur exécutant l'application est utilisé pour déterminer les ressources auxquelles le code peut accéder. Par défaut, l'accès total est accordé aux compléments pour tous les objets, propriétés et méthodes dans le modèle objet ou l'assembly PIA d'Outlook. Les administrateurs informatiques peuvent choisir les compléments et objets pouvant accéder au modèle objet ou à l'assembly PIA d'Outlook. Ces derniers empêchent du code exécuté hors du processus Outlook d'accéder aux objets et méthodes sécurisés.
Fonctionnalités de surveillance de la sécurité Outlook surveille les métriques suivantes d’un complément pour déterminer s’il doit désactiver le complément : Commutateur dossier d’arrêt de démarrage Élément ouvert Fréquence d’appel Les administrateurs peuvent utiliser la stratégie de groupe pour remplacer les paramètres utilisateur et contrôler les compléments qui s’exécutent sur les ordinateurs de l’utilisateur. Pour plus d'informations, voir Critères de performances pour maintenir les compléments activés.

Critères de déploiement

Critères Modèle objet Outlook ou assembly PIA
Exigences en matière de plateforme de serveur Le modèle objet et l'assembly PIA d'Outlook sont des technologies côté client.
Exigences en matière de plateforme cliente Les applications qui utilisent le modèle objet et l'assembly PIA d'Outlook pour accéder à des données Exchange requièrent l'installation d'Outlook sur l'ordinateur local.
Méthodes de déploiement Les applications qui utilisent le modèle objet et l'assembly PIA d'Outlook sont distribuées à l'aide d'un logiciel d'installation d'application standard.
Remarques relatives au déploiement Outlook ne devant pas être installé sur Exchange Server, les applications qui utilisent le modèle objet ou l'assembly PIA d'Outlook ne peuvent pas être exécutées sur Exchange Server.

Critères d'évaluation objectifs pour MAPI

Vous pouvez utiliser MAPI pour accéder à des éléments et dossiers dans des banques publiques et privées, ainsi que pour accéder aux propriétés stockées avec chaque élément. Toutes les versions d'Outlook utilisent l'interface MAPI. Vous pouvez créer des clients qui utilisent MAPI, ainsi que des serveurs MAPI et des programmes de traitement de formulaires MAPI. Les informations contenues dans cette section s'appliquent uniquement aux applications clientes MAPI.

Remarque

MAPI est un mécanisme évolué servant à accéder aux informations dans Exchange ou dans un fichier de dossiers personnels (.pst), et MAPI fournit des possibilités qui ne sont pas disponibles dans d’autres API. Cependant, MAPI ne fonctionne pas bien à l’extérieur d’un intranet, maintient une connexion ouverte pendant toute la durée de la session MAPI et peut être difficile à apprendre. MAPI ne met pas en vigueur la logique métier Outlook, vous devez être particulièrement attentif pour garantir que la logique métier d’Outlook est maintenue.

Les tableaux suivants présentent les critères d'évaluation pour MAPI.

Critères fonctionnels

Critères MAPI
Domaine d'application Les applications clientes qui utilisent MAPI accèdent à des informations de boîte aux lettres d'utilisateur ou de dossier public stockées dans Exchange, ainsi qu'à des informations d'annuaire d'utilisateurs stockées dans Active Directory. Ces applications sont généralement des clients de messagerie, tels qu'Outlook, et des applications qui nécessitent un traitement du courrier électronique complexe.
Objets principaux Les objets MAPI sont tous obtenus par le biais de l'interface IMAPISession : IUnknown. L'objet Session permet au client d'accéder à des objets permettant de travailler avec des profils, des statuts et une administration de fournisseur de services de messagerie, des tableaux de banque de messages et des carnets d'adresses MAPI. Le tableau de la banque de messages contient des objets pour la banque de messages, les dossiers, les messages, les pièces jointes et les destinataires. Les tableaux de carnet d'adresses contiennent des objets pour les utilisateurs de messagerie et les listes de distribution.
Modèle d'accès aux données MAPI représente les messages et les utilisateurs sous la forme d'un ensemble hiérarchique d'objets.
Modèles de thread Il n'existe aucune interdiction de thread spécifique. Toutefois, les applications qui utilisent un modèle de thread libre doivent éviter de partager des objets MAPI dans les threads en raison des coûts élevés liés au marshaling de l'objet. L'interface MAPI et les fournisseurs de service MAPI utilisent un modèle de thread libre.
Architectures d'application Les applications clientes MAPI sont généralement des applications clientes basées sur les formulaires Windows. Toutefois, vous pouvez utiliser MAPI pour écrire des applications multiniveaux.
Utilisation à distance MAPI utilise des appels de procédure distante (RPC) pour communiquer avec Exchange Server. Généralement, le passage des RPC via les pare-feu Internet est intentionnellement bloqué.
Transactions MAPI ne prend pas en charge les transactions.
Disponibilité Un stub MAPI est actuellement livré avec toutes les versions de Windows. Office installe son propre sous-système MAPI lors de l'installation d'Outlook. Aucune modification de l’interface MAPI n’est prévue pour le moment.

Critères de développement

Critères MAPI
Langages et outils Vous pouvez accéder directement à MAPI à l'aide du langage C ou C++. Les autres langages pouvant accéder à la convention d'appel C/C++ peuvent être en mesure d'accéder à MAPI. L'utilisation de langages managés, tels que Visual Basic ou C#, n'est pas prise en charge. Vous devez compiler des solutions MAPI distinctes pour les versions 32 bits et 64 bits d'Outlook.
Implémentation managée MAPI est un composant non managé. L'utilisation de MAPI n'est pas prise en charge dans le cadre de la couche d'interopérabilité COM de Visual Studio et .NET Framework.
Peut contenir des scripts MAPI ne peut pas être utilisé directement dans des scripts.
Outils de test et de débogage Aucun outil de débogage spécial n'est nécessaire pour déboguer des applications qui utilisent l'interface MAPI. En revanche, vous pouvez utiliser MFCMAPI. MFCMAPI utilise MAPI pour fournir un accès aux banques MAPI par le biais d'une interface utilisateur graphique, et facilite l'analyse de problèmes lors de l'extension d'Outlook à l'aide de MAPI.
Disponibilité des experts Il peut être difficile de trouver des programmeurs MAPI experts, et la formation à la technologie peut être longue. En plus des communautés Microsoft, seul un petit nombre de sites web tiers de haute qualité fournissent des informations utiles sur le développement de MAPI.
Informations disponibles De la documentation Microsoft et de tiers décrivant la programmation MAPI est disponible.
Gestion des licences de développeur et de déploiement Aucune licence spéciale n'est nécessaire pour développer des applications qui utilisent l'interface MAPI.

Critères de sécurité

Critères MAPI
Autorisations attribuées au moment de la conception Le développeur doit avoir des autorisations d’accès aux données dans la banque Exchange. Exchange stocke des informations de liste d’utilisateurs et de distribution dans Active Directory, afin que les développeurs qui créent des applications clientes MAPI accédant à ces informations doivent avoir la possibilité d’extraire et de définir ces informations.
Autorisations d'installation En règle générale, pour l'installation d'applications basées sur MAPI, l'utilisateur doit être un administrateur local ou disposer des droits requis pour l'installation de logiciels.
Autorisations d'exécution En règle générale, l'exécution d'une application basée sur MAPI nécessite uniquement que l'utilisateur dispose des autorisations suffisantes pour accéder aux données sur une banque Exchange ou un fichier (.pst) de dossiers personnels.
Fonctionnalités de sécurité intégrées Les profils MAPI peuvent être protégés par mot de passe sur la plupart des plateformes.

Critères de déploiement

Critères MAPI
Exigences en matière de plateforme de serveur Le serveur Exchange Server sur lequel les données utilisateur sont stockées pour les utilisateurs de l'application cliente MAPI doivent être correctement configurées pour permettre aux clients MAPI d'y accéder.
Exigences en matière de plateforme cliente Le programme d'installation de l'application cliente doit vérifier que la version correcte de MAPI est disponible sur l'ordinateur, et que l'interface est correctement configurée à l'aide du fichier Mapisvc.inf.
Méthodes de déploiement Les applications qui utilisent MAPI peuvent être déployées sur des ordinateurs client à l'aide de technologies de distribution de logiciels standard.
Remarques relatives au déploiement Le programme d'installation doit vérifier que la version correcte de MAPI est disponible.

Facteurs de décision pour la plateforme des applications pour Office

Les Compléments Office utilisant des technologies web, elles sont les plus adaptées pour assurer la connexion à des services dans le cloud ou en local et fournir les services dans le contexte du client riche et du client web. En demandant les autorisations appropriées, les applications de messagerie permettent également la lecture, l'écriture ou l'envoi d'éléments dans une boîte aux lettres.

Les raisons fréquentes pour lesquelles les applications de messagerie représentent un meilleur choix que les compléments pour les développeurs sont indiquées ci-dessous :

  • Vous pouvez utiliser votre connaissance des technologies web (HTML, JavaScript et CSS) et leurs avantages existants. Pour les utilisateurs avancés et les nouveaux développeurs, XML, HTML et JavaScript nécessitent une durée de démarrage moins importante que les API de base COM, notamment le modèle objet et MAPI.

  • Vous pouvez utiliser un modèle de déploiement web simple pour mettre à jour votre application de messagerie (notamment les services web utilisés par l'application) sur votre serveur web sans aucune installation complexe sur le client Outlook. En fait, toute mise à jour de l'application de messagerie, à l'exception du manifeste de l'application, ne nécessite pas de mise à jour sur le client Office. Vous pouvez facilement mettre à jour le code ou l'interface utilisateur de l'application de messagerie sur le serveur web. Cela présente un avantage significatif sur la surcharge administrative entraînée par la mise à jour de compléments.

  • Vous pouvez utiliser une plateforme de développement web courante pour les applications de messagerie pouvant être itinérantes dans le client riche Outlook et Outlook Web App sur ordinateur de bureau, tablette et smartphone. En revanche, les compléments utilisent le modèle objet pour le client riche Outlook, et par conséquent, peuvent uniquement s'exécuter sur ce client riche sur un facteur de forme de bureau.

  • Vous pouvez profiter des délais rapides de création et de publication d'applications via l'Office Store.

  • En raison du modèle d'autorisations à trois niveaux, les utilisateurs et administrateurs perçoivent mieux la sécurité et la confidentialité dans des applications de messagerie que dans des compléments, qui disposent d'un accès total au contenu de chaque compte dans le profil utilisateur. Cet élément favorise à son tour la consommation d'applications par les utilisateurs.

  • En fonction de vos scénarios, vous pouvez bénéficier de fonctionnalités propres aux applications de messagerie qui ne sont pas prises en charge par les compléments :

    • Vous pouvez configurer une application de messagerie de façon à ce qu'elle ne s'active que dans certains contextes (par exemple, Outlook affiche l'application dans la barre de l'application uniquement si la classe du message de rendez-vous sélectionné par l'utilisateur est IPM.Appointment.Contoso, ou si le corps d'un courrier électronique contient un numéro de suivi de package ou un identificateur client).

    • Vous pouvez activer une application de messagerie si le message sélectionné contient certaines entités connues, telles qu'une adresse, un contact, une adresse électronique ou une suggestion de réunion ou de tâche.

    • Vous pouvez tirer parti de l'authentification par jetons d'identité, ainsi que des services web Exchange.

Toutefois, les fonctionnalités suivantes sont propres aux compléments et peuvent en faire un choix plus approprié que les applications de messagerie dans certaines circonstances :

  • Vous pouvez utiliser des compléments pour étendre ou automatiser Outlook au niveau d'une application, car le modèle objet et l'assembly PIA disposent d'une intégration étendue avec les fonctionnalités Outlook (comme tous les types d'éléments, l'interface utilisateur, les sessions et les règles). Au niveau de l'élément, les compléments peuvent interagir avec un élément en mode lecture ou composition. Avec les applications de messagerie, vous ne pouvez pas automatiser Outlook au niveau de l'application, et vous pouvez étendre les fonctionnalités d'Outlook uniquement dans le contexte du mode lecture des éléments pris en charge (messages et rendez-vous) dans la boîte aux lettres de l'utilisateur.

  • Vous pouvez spécifier une logique métier personnalisée pour un nouveau type d'élément.

  • Vous pouvez modifier et ajouter des commandes personnalisées dans le ruban et le mode Backstage.

  • Vous pouvez afficher une page de formulaire ou une zone de formulaire personnalisée.

  • Vous pouvez détecter des événements, tels que l'envoi d'un élément ou la modification des propriétés d'un élément.

  • Vous pouvez utiliser des compléments sur Outlook 2013 et Exchange Server 2013, ainsi que sur les versions antérieures d'Outlook et d'Exchange. En revanche, les applications de messagerie fonctionnent avec Outlook et Exchange à partir d’Outlook 2013 et Exchange Server 2013, mais pas avec les versions antérieures.

Pour plus d'informations sur les scénarios pris en charge par le modèle objet et l'assembly PIA, voir la section suivante, Facteurs de décision pour le modèle objet ou l'assembly PIA. Pour obtenir une comparaison de la plateforme des Compléments Office avec d'autres technologies d'extensibilité pour Office, voir Arrière-plan des applications pour Office et SharePoint.

Facteurs de décision pour le modèle objet ou l’assembly PIA

Principaux scénarios de base pris en charge par le modèle d’objet Outlook ou PIA

En règle générale, utilisez le modèle objet ou l’assembly PIA si votre solution personnalise l’interface utilisateur Outlook ou dépend de la logique métier d’Outlook. Ce qui suit présente les principaux scénarios de référence dans lesquels les solutions Outlook utilisent le modèle objet ou l’assembly PIA.

Scénarios pris en charge par le modèle d’objet ou PIA depuis Outlook 2007

En plus des scénarios de référence, si votre solution Outlook prend en charge l’un des scénarios indiqués dans la liste suivante, et que vous prévoyez d’exécuter votre solution sur Outlook 2007 ou version ultérieure, mais pas sur des versions antérieures, vous pouvez également utiliser le modèle objet ou l’assembly PIA. Cette section indique les principaux objets ou membres que vous pouvez utiliser dans le modèle objet Outlook pour étendre chaque scénario (à l’exception de l’interface IDTExtensibility2 dans le modèle objet Automation de Visual Studio, et l’interface IRibbonExtensibility dans le modèle objet Office, que vous pouvez intégrer au modèle objet Outlook).

Scénarios pris en charge par le modèle d’objet ou PIA depuis Outlook 2010

Si vous prévoyez d’exécuter votre solution Outlook sur Outlook 2010, et non sur les versions antérieures, vous pouvez choisir d’utiliser le modèle objet ou l’assembly PIA pour prendre en charge les scénarios indiqués à la prochaine section. Cette section indique les objets ou membres principaux que vous pouvez utiliser dans le modèle objet Outlook pour étendre chaque scénario (à l’exception des interfaces IRibbonControl, IRibbonExtensibility et IRibbonUI qui se trouvent dans le modèle objet Office, que vous pouvez intégrer au modèle objet Outlook).

Scénarios pris en charge par le modèle d’objet ou PIA depuis Outlook 2013

Si vous prévoyez d’exécuter votre solution sur Outlook 2013, et non sur les versions antérieures, vous pouvez utiliser le modèle objet ou l’assembly PIA afin qu’il prenne en charge les scénarios indiqués dans les ressources suivantes.

Facteurs de décision pour MAPI

En règle générale, vous utilisez MAPI pour accéder aux données sur un serveur basé sur MAPI, tel que le serveur Microsoft Exchange, ainsi que pour effectuer des tâches comme les suivantes :

  • Créer un fournisseur de services personnalisé, tel qu'un fournisseur de carnets d'adresses, de transports ou de banques.

  • Créer un processus de récepteur.

  • Créer ou manipuler un profil.

  • Exécuter une application en tant que service Windows NT.

  • Exécuter des tâches sur un thread d'arrière-plan. Par exemple, l'énumération de nombreux éléments dans un dossier et la modification des propriétés des éléments dans un thread d'arrière-plan peuvent optimiser les performances.

Pour plus d'informations et d'exemples de code, voir Référence MAPI Outlook et MFCMAPI.

En outre, si votre solution est exécutée sur une version antérieure à Outlook 2007, et que des scénarios comme le suivant s'appliquent à votre solution, vous devez utiliser MAPI pour étendre ces scénarios.

  • Définir et obtenir des propriétés de niveau élément intégrées qui ne sont pas exposées dans le modèle objet.
  • Gérer des comptes, pièces jointes, listes de distribution Exchange, utilisateurs Exchange ou banques.
  • Stocker des données privées pour des solutions.
  • Gérer une banque de messages pour un compte.

Depuis Outlook 2007, le modèle objet prend en charge une gamme de fonctionnalités que les développeurs, avant cette version, devaient résoudre via MAPI ou d'autres API, telles que Microsoft Collaboration Data Objects (CDO) 1.2.1 et les extensions du client Microsoft Exchange. Par conséquent, si l'un des scénarios de la liste précédente s'applique à votre solution, mais que votre solution est exécutée sur Outlook 2007 ou Outlook 2010, vous pouvez et devez utiliser le modèle objet ou l'assembly PIA d'Outlook pour prendre en charge ces scénarios. Pour plus d'informations sur les améliorations d'Outlook 2007 qui unifient les technologies de développement Outlook, voir What's New for Developers in Outlook 2007 (Part 1 of 2).

Facteurs de décision pour les API auxiliaires

Les API auxiliaires Outlook peuvent s'intégrer à la logique métier Outlook ou MAPI dans certains scénarios dans lesquels le modèle objet ou MAPI ne fournit pas de solution. Utilisez les API auxiliaires Outlook dans les scénarios suivants :

  • Gestion de compte : gérez des informations de compte, manipulez des comptes, envoyez des notifications sur les modifications apportées à un compte et protégez les comptes du courrier indésirable.
  • Dégradation de données : incluez dans un wrapper un objet dans un format de caractères préféré plutôt que de l'exposer dans son format natif.
  • Redéfinition des calendriers et de la prise en charge du fuseau horaire : redéfinissez les calendriers Outlook pour qu'ils prennent en charge l'heure d'été.
  • Disponibilité : indiquez des informations de disponibilité sur des calendriers.
  • Images des contacts : déterminez l'affichage de l'image d'un contact dans Outlook.
  • Devise de l'élément : déterminez si un élément Outlook comporte des modifications non enregistrées.
  • Catégorisation d'un article : catégorisez un élément Outlook après son envoi.

Pour plus d'informations sur les API auxiliaires, voir la section Ressources supplémentaires : API auxiliaires.

Automatisation d'Outlook par solutions in-process par rapport à des solutions hors processus

Remarque

La discussion portant sur l'automatisation d'Outlook dans cette section et la suivante ne relève pas des Compléments Office, qui sont prévues pour étendre les fonctionnalités de l'application cliente ou web Office, et non pour l'automatiser.

Outlook prend en charge l'automatisation à l'aide de compléments exécutés dans le même processus de premier plan, et par des solutions autonomes exécutées dans leur propre processus distinct en dehors du processus Outlook. En règle générale, pour automatiser Outlook, utilisez un complément pour interagir avec Outlook via le modèle objet, l'assembly PIA ou MAPI, et dans des scénarios moins courants, via une API auxiliaire (telle que HrProcessConvActionForSentItem). Utilisez une solution hors processus uniquement lorsque cela est nécessaire (par exemple, lors de l'écriture d'une application cliente MAPI qui utilise le fichier Tzmovelib.dll pour redéfinir des calendriers Outlook pour les clients, ou lors de l'énumération de nombreux éléments dans un dossier et de la modification des propriétés des éléments dans un thread d'arrière-plan pour optimiser les performances).

Les compléments sont la solution recommandée pour automatiser Outlook, car Outlook approuve uniquement l’objet Application passé au complément pendant l’événement OnConnection(Object, ext_ConnectMode, Object, Array) du complément. Vous pouvez éviter l’affichage d’avertissements de sécurité du module de protection du modèle objet en dérivant tous les objets, toutes les propriétés et toutes les méthodes à partir de cet objet Application. Si le complément crée une instance de l’objet Application, Outlook n’approuve pas cet objet, même si le complément figure dans la liste des compléments approuvés. Les objets, propriétés et méthodes dérivés d’un tel objet Application ne sont pas approuvés et les propriétés et méthodes bloquées appellent des avertissements de sécurité. Pour plus d’informations sur la protection du modèle objet, voir Security Behavior of the Outlook Object Model.

Automatisation d'Outlook par des solutions gérées par rapport à des solutions non gérées

Outlook prend en charge l'automatisation par des compléments et des applications autonomes, écrites dans des langages managés ou non managés. C# et Visual Basic sont les langages managés les plus couramment utilisés. Les outils C++ et Delphi sont plus courants dans le développement non managé. L'expertise disponible est un élément à prendre en compte lors du choix entre développement managé et non managé.

Si votre solution utilise uniquement le modèle objet, vous pouvez envisager de développer une solution gérée à l'aide de l'assembly PIA ou des outils de développement Office dans Visual Studio. Ces derniers fournissent des modèles de projet et des concepteurs visuels qui simplifient la création d'interfaces utilisateur personnalisées et le développement de solutions Office.

En revanche, Microsoft ne prend pas en charge MAPI dans du code managé car MAPI a été développé avant .NET Framework et que Microsoft ne fournit pas de wrappers managés pour MAPI. Si vous utilisez MAPI, vous devez développer une solution non gérée. Pour plus d'informations, voir Règles de prise en charge pour le développement de messagerie côté client .

API et technologies ciblées

Outlook Social Connector (OSC) et la barre météorologique prennent en charge l'extension de scénarios très spécifiques dans Outlook.

Extensibilité du fournisseur Outlook Social Connector (OSC)

L'extensibilité du fournisseur Outlook Social Connector (OSC) prend en charge le développement d'un fournisseur pour un réseau social qui permet aux utilisateurs d'afficher, dans Outlook ou autres applications clients Office, des mises à jour concernant les amis et activités sur ce réseau social. La figure 6 présente l'OSC qui affiche dans le volet Contacts les activités d'une personne sur des sites de réseaux sociaux.

Figure 6. OSC affichant des données de réseau social dans le volet Contacts

Volet Outlook Social Connector

OSC dans Outlook permet aux utilisateurs d'afficher, dans le volet Contacts, un regroupement de courriers électroniques, pièces jointes et demandes de réunion d'une personne dans Outlook. Dans un environnement organisationnel, les utilisateurs qui collaborent sur un site SharePoint peuvent voir des mises à jour de documents et d'autres activités de site de cette personne sur le site SharePoint. L'extensibilité du fournisseur Outlook Social Connector prend en charge le développement d'un fournisseur pour OSC afin de synchroniser et d'exposer des mises à jour de réseau social dans Outlook. Les fournisseurs d'OSC courants (tels que Facebook et LinkedIn) sont installés par défaut avec Outlook. En fonction des sites de réseau social auquel un utilisateur Outlook est connecté, l’utilisateur peut voir, dans le volet Contacts, des mises à jour, telles que des photos, statuts et activités sur les réseaux sociaux correspondants.

Extensibilité de la barre météorologique

À partir de la version Outlook 2013, la barre météorologique permet aux développeurs de connecter un service web de météorologie tiers dans la barre météorologique, afin d'indiquer des données de conditions météorologiques pour un emplacement choisi par l'utilisateur. La barre météorologique dans Outlook affiche les conditions et prévisions météorologiques pour un emplacement géographique. Un utilisateur peut choisir un ou plusieurs emplacements, et visualiser facilement les données météorologiques dans la barre météorologique dans le module de calendrier. La figure 7 présente la barre météorologique affichant une prévision sur trois jours pour New York, NY.

Figure 7. Barre météorologique dans Outlook

Barre météo affichant les prévisions pour New York

Par défaut, Outlook utilise les données météorologiques fournies par MSN Météo. La barre météorologique prend en charge des services web de données météorologiques tiers qui suivent un protocole défini pour communiquer avec Outlook. Tant que le service de données météorologiques tiers prend en charge ce protocole, les utilisateurs peuvent le choisir afin d'obtenir des données météorologiques dans la barre météorologique.

Voir la section Ressources supplémentaires : références principales, ressources et exemples de code pour plus d'informations sur l'utilisation de l'extensibilité du fournisseur OSC et l'extensibilité de la barre météorologique.

Conclusion

Pour déterminer l'API ou la technologie la mieux adaptée à votre solution, vous devez d'abord définir les objectifs de votre solution :

  • Les versions d'Outlook que votre solution va prendre en charge.

  • Les scénarios de priorité élevée de votre solution. Est-ce que votre solution interagit principalement avec le contenu et les propriétés d'élément de message ou de rendez-vous ? Ou est-ce que votre solution automatise Outlook au niveau de l'application ? Si tel est le cas, est-ce que ces scénarios impliquent l'énumération, le filtrage ou la modification de dossiers contenant de nombreux éléments Outlook ?

Tout d'abord, vérifiez si la prise en charge de l'application de messagerie dans la plateforme des Compléments Office répond à vos besoins. Voir la section Critères fonctionnels de Critères d'évaluation objectifs pour la plateforme des applications pour Office afin de déterminer si les objets et fonctionnalités principaux prennent en charge vos scénarios. Voir la section Facteurs de décision pour la plateforme des applications pour Office afin de vérifier si les applications de messagerie constituent un meilleur choix que les compléments pour vos scénarios. En général, développez votre solution en tant qu'application, si possible, pour bénéficier de la prise en charge de la plateforme dans les clients Outlook sur différents facteurs de forme.

Si vos scénarios exigent que vous étendiez au-delà des éléments de message ou de rendez-vous, ou que vous automatisiez Outlook au niveau de l'application, essayez de faire correspondre vos scénarios avec ceux présentés dans la section Facteurs de décision pour le modèle objet ou l'assembly PIA. Si le modèle objet (ou l'assembly PIA) de vos versions Outlook cible prend en charge vos scénarios, et que votre solution ne manipule pas de dossiers contenant un grand nombre d'éléments, vous devez implémenter votre solution en tant que complément, dans un langage managé ou non managé.

Si le modèle objet (ou l'assembly PIA) de la version Outlook cible ne prend pas en charge certains de vos scénarios, vérifiez si les scénarios dans la section Facteurs de décision pour MAPI ou Facteurs de décision pour les API auxiliaires répondent à vos besoins. Si MAPI répond à vos besoins, vous devez implémenter votre solution en code non managé. Si une API auxiliaire résout l'un de vos scénarios, vous pouvez utiliser du code managé ou non managé.

Si votre solution utilise l'interface MAPI, vous devez l'implémenter dans du code non managé, tel que C++. Sinon, la décision d'utiliser du code managé ou non managé pour créer la solution dépend en général de vos ressources disponibles et de leur expertise. Quant à la décision d'implémenter la solution en tant que complément ou application autonome, choisissez un complément afin d'éviter que l'utilisateur n'appelle constamment la protection du modèle objet Outlook, à moins que la manipulation de dossiers contenant de nombreux éléments soit nécessaire dans votre scénario. Dans le dernier scénario, l'implémentation de la solution en vue d'une exécution en tant que thread d'arrière-plan peut optimiser les performances d'Outlook.

Si vos scénarios ne comprennent pas l'affichage d'informations ou de mises à jour de réseau social dans Outlook, vous devez utiliser l'extensibilité du fournisseur OSC afin de créer une DLL visible par COM. Vous pouvez faire cela dans un langage managé ou non managé.

Si vous souhaitez connecter un service de données météorologiques tiers à la barre météorologique, vous pouvez suivre le protocole défini par l'extensibilité de la barre météorologique et indiquer les services web appropriés. Vous pouvez créer ces services web dans un langage managé.

Après avoir choisi les API ou technologies à utiliser dans votre solution, vous pouvez consulter la documentation et les exemples de code supplémentaires dans la section Ressources supplémentaires : références principales, ressources et exemples de code pour plus d'informations.

Vue d'ensemble de la plateforme des compléments pour Office fournit une bonne introduction sur les Compléments Office, notamment l'architecture et le cycle de vie de développement.

Consultez l’article Compléments Outlook pour une feuille de route détaillée des ressources concernant le développement d’applications de courrier.

Voir aussi : modèle objet et PIA

Les ressources suivantes fournissent plus d’informations sur l’utilisation du modèle objet et de l’assembly PIA.

Comptes : plusieurs comptes dans le profil

Carnet d’adresses et utilisateurs Exchange

Pièces jointes

Pièces jointes : sélection dans l'inspecteur

Automatisation d’Outlook

Catégories

Contacts : vérifiez l'adresse et le nom complet

Conversations

Événements

Explorateur : réponse incluse

Éléments : propriétés, champs et formulaires de base

Éléments : personnalisation des propriétés

Éléments : énumération, filtrage et tri

Éléments : indiquer en tant que tâches

Consultez les propriétés suivantes liées aux tâches dans certains objets d'élément, tel que l'objet MailItem :

Éléments : sélection dans l'explorateur

Divers : cartes de visite, règles et vues d’entreprise

Sécurité

Partage

Solutions : dossiers propres à la solution

Solutions : stockage de données

Interface utilisateur : personnalisation des zones de formulaire

Interface utilisateur : personnalisation depuis Outlook 2007

Interface utilisateur : personnalisation depuis Outlook 2010

Interface utilisateur : dossiers propres aux solutions

Voir aussi : API auxiliaires

Les ressources suivantes fournissent plus d'informations sur les API auxiliaires d'Outlook.

Gestion des comptes

Catégorisation des éléments

Photos des contacts

Dégradation des données

Informations de disponibilité

Devise de l’élément

Relocaliser les calendriers

Voir aussi : exemples de code, ressources et références principales

Les ressources suivantes fournissent plus d'informations sur les références principales, les ressources et les exemples de code d'Outlook.

Références et ressources principales

Exemples de code