Manifeste des compléments Office

  • Article

Chaque complément Office a un manifeste. Il existe deux types de manifestes :

  • Manifeste de complément uniquement : il s’agit du seul type de manifeste actuellement pris en charge pour les compléments non-Outlook. Son format est XML. Ce type de manifeste ne peut pas être utilisé pour une application qui combine un complément avec un autre type d’extension de la plateforme Microsoft 365.
  • Manifeste unifié pour Microsoft 365 : il s’agit d’une version développée du manifeste au format JSON qui a été utilisée pendant des années comme manifeste pour les applications Teams. Les compléments qui utilisent ce manifeste peuvent être combinés avec d’autres types d’extensions de la plateforme Microsoft 365 dans une application unique qui peut être installée en tant qu’unité.

Remarque

Les compléments Office qui utilisent le manifeste unifié pour Microsoft 365 sont directement pris en charge dans Office sur le web, dans la nouvelle version d’Outlook sur Windows et dans Office sur Windows connecté à un abonnement Microsoft 365, version 2304 (build 16320.00000) ou ultérieure.

Lorsque le package d’application qui contient le manifeste unifié est déployé dans AppSource ou dans le Centre d’administration Microsoft 365 , si le manifeste a une propriété « alternateIcons » valide, un manifeste de complément uniquement est généré à partir du manifeste unifié et stocké. Ce manifeste de complément uniquement permet d’installer le complément sur les plateformes qui ne prennent pas directement en charge le manifeste unifié, notamment Office sur Mac, Office sur mobile, les versions d’abonnement d’Office sur Windows antérieures à 2304 (build 16320.00000) et les versions perpétuelles d’Office sur Windows.

Le reste de cet article s’applique aux deux types de manifeste.

Conseil

Le fichier manifeste d’un complément Office décrit la façon dont votre complément doit être activé lorsqu’un utilisateur final l’installe et l’utilise avec des documents et des applications Office.

Un fichier manifeste permet à un complément Office d’effectuer les opérations suivantes :

  • Se décrire en fournissant un ID, une version, une description, un nom d’affichage et un paramètre régional par défaut.

  • Précisez les images utilisées pour l'image de marque du complément et l'iconographie utilisée pour commandes complémentaires dans le ruban d'application de l'Office.

  • Spécifier comment le complément s’intègre à Office, y compris les interfaces utilisateur personnalisées, telles que les boutons du ruban créés par le complément.

  • Spécifier les dimensions par défaut demandées pour des compléments de contenu, et la hauteur demandée pour des compléments Outlook.

  • Déclarer les autorisations que le Complément Office nécessite, par exemple la lecture du document ou l’écriture dans celui-ci.

Remarque

Si vous prévoyez de publier votre complément sur AppSource et de le rendre disponible dans l’expérience Office, assurez-vous que vous respectez les politiques de certification du marché commercial.  Par exemple, pour réussir la validation, votre complément doit fonctionner sur toutes les plateformes qui prennent en charge les méthodes que vous définissez (pour en savoir plus, consultez la section 1120.3 et la page relative à la disponibilité et à l’application des compléments Office).

Configuration requise pour l’hébergement

Tous les URI d’image, tels que ceux utilisés pour les commandes de complément, doivent prendre en charge la mise en cache en production. Le serveur hébergeant l’image ne doit pas retourner d’en-tête Cache-Control spécifiant no-cache, no-storeou des options similaires dans la réponse HTTP. Toutefois, lorsque vous développez le complément et apportez des modifications aux fichiers image, la mise en cache peut vous empêcher de voir vos modifications. Il est donc conseillé d’utiliser Cache-Control des en-têtes dans le développement.

Toutes les URL des fichiers de code ou de contenu dans le complément doivent être sécurisées par SSL (HTTPS). Bien qu’elle ne soit pas obligatoire dans tous les scénarios de complément, l’utilisation d’un point de terminaison HTTPS pour votre complément est fortement recommandée. Les compléments qui ne sont pas sécurisés par SSL (HTTPS) génèrent des erreurs et avertissements qui signalent un contenu non sécurisé durant l’utilisation. Si vous envisagez d’exécuter votre complément dans Office sur le web ou de le publier sur AppSource, il doit être sécurisé par SSL. Si votre complément accède aux services et données externes, il doit être sécurisé par SSL pour protéger les données en transit. Les certificats auto-signés peuvent être utilisés pour le développement et les tests, tant que le certificat est approuvé sur l’ordinateur local.

Bonnes pratiques pour l’envoi dans AppSource

Vérifiez que l’ID du complément est un GUID valide et unique. Vous trouverez des outils de génération de GUID sur Internet pour vous aider à créer un GUID unique.

Les compléments soumis à AppSource doivent également inclure une URL de support dans le manifeste. Pour plus d’informations, reportez-vous à Stratégies de validation pour les applications et les compléments envoyés à AppSource.

Spécifier les domaines que vous souhaitez ouvrir dans la fenêtre de complément

Lors de l’exécution dans Office sur le web ou dans outlook sur Windows, vous pouvez accéder à n’importe quelle URL dans votre volet Office. Toutefois, sur les plateformes de bureau, si votre complément tente d’accéder à une URL dans un domaine autre que le domaine qui héberge la page de démarrage (comme spécifié dans le fichier manifeste), cette URL s’ouvre dans une nouvelle fenêtre de navigateur en dehors du volet de complément de l’application Office.

Pour remplacer ce comportement (office de bureau), spécifiez chaque domaine que vous souhaitez ouvrir dans la fenêtre de complément du manifeste. Si le complément tente d’accéder à une URL située dans un domaine figurant dans cette liste, il s’ouvre dans le volet Office d’Office sur le web et de la version de bureau d’Office. S’il tente d’accéder à une URL qui ne figure pas dans la liste, dans la version de bureau d’Office, cette URL s’ouvre dans une nouvelle fenêtre de navigateur (en dehors du volet de complément).

Remarque

Il existe deux exceptions à ce comportement.

  • Il s’applique uniquement au volet racine du complément. S’il existe un iframe incorporé dans la page du complément, l’iframe peut être dirigé vers n’importe quelle URL, qu’elle soit ou non répertoriée dans le manifeste, même dans office de bureau.
  • Lorsqu’une boîte de dialogue est ouverte avec l’API displayDialogAsync , l’URL transmise à la méthode doit se trouver dans le même domaine que le complément, mais la boîte de dialogue peut ensuite être dirigée vers n’importe quelle URL, qu’elle soit ou non répertoriée dans le manifeste, même dans office de bureau.

Spécifier les domaines à partir desquels les appels d’API Office.js sont effectués

Votre complément peut effectuer Office.js appels d’API à partir du domaine du complément référencé dans le fichier manifeste. Si vous avez d’autres iframes dans votre complément qui doivent accéder à Office.js API, ajoutez le domaine de cette URL source au fichier manifeste. Si un iframe dont la source n’est pas répertoriée dans le manifeste tente d’effectuer un appel d’API Office.js, le complément reçoit une erreur d’autorisation refusée.

Voir aussi