Instructions de validation du Magasin Teams

Le respect de ces instructions augmente les chances que votre application réussisse le processus de soumission au Microsoft Teams Store. Les directives spécifiques aux équipes complètent les politiques de certification du marché commercial Microsoft et sont mises à jour fréquemment pour refléter les nouvelles fonctionnalités, les commentaires des utilisateurs et les modifications des règles métier.

Remarque

• Certaines instructions peuvent ne pas être applicables à votre application. Par exemple, si votre application n’inclut pas de bot, vous pouvez ignorer les instructions liées aux bots.
• Nous avons recoupé ces directives avec les politiques de certification commerciale de Microsoft et ajouté les choses à faire et à ne pas faire avec des exemples de scénarios de réussite ou d'échec rencontrés dans notre processus de validation.
• Certaines instructions sont marquées comme Doit corriger. Si votre soumission d'application ne respecte pas ces directives obligatoires, vous recevrez un rapport d'échec de notre part avec des mesures pour atténuer. Votre soumission d’application passe la validation du Magasin Teams uniquement une fois que vous avez résolu les problèmes.
• D’autres recommandations sont marquées comme bonnes à corriger. Pour une expérience utilisateur idéale, nous vous recommandons de résoudre les problèmes. Toutefois, la publication de votre application n’est pas bloquée sur le Magasin Teams, si vous choisissez de ne pas résoudre les problèmes.

Proposition de valeur

Cette section est conforme à la politique de certification commerciale Microsoft numéro 1140.1 et fournit des conseils supplémentaires aux développeurs d’applications Microsoft Teams sur la proposition de valeur de leur offre.

Les applications doivent fournir de la valeur aux utilisateurs en leur permettant d’effectuer des workflows fonctionnels qui encouragent une utilisation répétée. Développez les sections suivantes pour en savoir plus sur la proposition de valeur :

Onglets

Les onglets doivent apporter une valeur au-delà de l'hébergement d'un site Web existant. [Doit corriger]

Bots de notification

Une notification fournit de la valeur dans Teams si :

1. La carte ou le texte affiché fournit des détails adéquats ne nécessitant aucune autre action de l'utilisateur.
2. La carte ou le texte publié fournit des informations d'aperçu adéquates pour qu'un utilisateur puisse prendre des mesures ou décider d'afficher plus de détails dans un lien s'ouvrant en dehors de Teams.

Les applications qui fournissent uniquement des notifications avec du contenu tel que Vous avez une nouvelle notification ou cliquez pour afficher, et qui exigent de l’utilisateur qu’il navigue en dehors de Teams pour tout le reste ne fournissent pas de valeur significative dans Teams.

Extensions de message

[Doit corriger]

Les applications qui consistent en une extension de messagerie basée sur la recherche offrent une valeur utilisateur en partageant des cartes qui permettent des conversations contextuelles sans changement de contexte.

Pour réussir la validation d’une application d’extension de message basée uniquement sur la recherche, les éléments suivants sont requis comme base de référence pour garantir que l’expérience utilisateur n’est pas interrompue. Une carte partagée via une extension de messagerie apporte de la valeur dans Teams si :

1. La carte publiée fournit des détails adéquats ne nécessitant aucune autre action de l'utilisateur.

2. La carte publiée fournit des informations d'aperçu adéquates pour qu'un utilisateur puisse prendre des mesures ou décider d'afficher plus de détails dans un lien s'ouvrant en dehors de Teams.

   

   

Déploiement de liens

Les applications de déploiement de liens uniquement n'apportent pas de valeur significative au sein des équipes. Envisagez de créer d’autres flux de travail dans votre application, si celle-ci prend uniquement en charge le déploiement de liens et n’a pas d’autres fonctionnalités.

Retour en haut

Nom de l'application

[Doit corriger]

Cette section est conforme à la stratégie de certification commerciale De Microsoft numéro 1140.1.1 et fournit des conseils supplémentaires aux développeurs sur le nommage de leurs applications.

Développer pour en savoir plus

Le nom d’une application joue un rôle essentiel dans la façon dont les utilisateurs la découvrent dans le Magasin Teams. Utilisez les instructions suivantes pour nommer une application :

• Le nom doit inclure des termes susceptibles d’intéresser vos utilisateurs. [Doit corriger]

• Préfixe ou suffixe des noms communs avec le nom du développeur. Par exemple, Tâches Contoso au lieu de Tâches. [Doit corriger]

• Ne doit pas utiliser Teams ou d’autres noms de produits Microsoft tels que Excel, PowerPoint, Word, OneDrive, SharePoint, OneNote, Azure, Surface et Xbox qui pourraient faussement indiquer la co-marque ou la co-vente. Pour plus d'informations sur le référencement des produits et services logiciels Microsoft, consultez Directives sur les marques et marques Microsoft. [Doit corriger]

• Ne doit pas copier le nom d’une application répertoriée dans le Magasin Teams ou une autre offre sur la place de marché commerciale. [Doit corriger]

• Ne doit pas contenir de termes vulgaires ou désobligeants. Le nom ne doit pas non plus inclure une langue non sensible à la race ou à la culture. [Doit corriger]

• Doit être unique. Si votre application (Contoso) est répertoriée dans le Magasin Teams et Microsoft AppSource et que vous souhaitez répertorier une autre application spécifique à une zone géographique telle que Contoso Mexique, votre soumission doit répondre aux critères suivants :

  • Appelez la fonctionnalité spécifique à la région de l'application dans le titre, les métadonnées, l'expérience de l'application de première réponse et les sections d'aide. Par exemple, le titre doit être Contoso Mexico. Le titre de l'application doit clairement différencier une application existante du même développeur pour éviter toute confusion chez l'utilisateur final. [Doit corriger]
  • Lorsque vous chargez le package d’application dans l’Espace partenaires, sélectionnez le bon marché où l’application est disponible dans la section Disponibilité . [Doit corriger]

• Le nom de l’application ne doit pas être associé à une fonctionnalité principale de Teams telle que Conversation, Contacts, Calendrier, Appels, Fichiers, Activité, Teams et Aide. Le nom de l’application ne se raccourcit pas à Conversation, Contacts, Calendrier, Appels, Fichiers, Activité, Teams et Aide lors de l’installation dans le volet de navigation de gauche. [Doit corriger]

• Si votre application fait partie d’un partenariat officiel avec Microsoft, le nom de votre application doit être en premier. Par exemple, le connecteur Contoso pour Microsoft Teams.

• Le nom de l’application ne doit pas avoir de référence à Microsoft ou aux produits Microsoft. N’utilisez pas Teams ou Microsoft dans le nom de l’application, sauf si votre application est en partenariat officiel avec Microsoft. Dans un tel instance, le nom de l’application doit figurer en premier avant toute référence à Microsoft. Par exemple, le connecteur Contoso pour Microsoft Teams. [Doit corriger]

• N’utilisez pas de parenthèses dans le nommage pour inclure des produits Microsoft. [Doit corriger]

• Le nom du développeur doit être le même dans le manifeste de l’application (précédemment appelé manifeste d’application Teams) et AppSource. [Doit corriger]

• Les manifestes d’application envoyés doivent être des manifestes de production. Par conséquent, le nom de l’application ne doit pas indiquer qu’elle est une application de préproduction. Par exemple, le nom de l’application ne doit pas contenir de mots tels que Beta, Dev, Preview et UAT. [Doit corriger]

• Le nom de l’application dans le manifeste de l’application et AppSource doit correspondre. [Doit corriger]

Conseil

La personnalisation de votre application sur le Teams Store et AppSource, y compris le nom de votre application, le nom du développeur, l’icône de l’application, les captures d’écran AppSource, la vidéo, la brève description et le site web, séparément ou pris ensemble, ne doivent pas emprunter l’identité d’une offre Microsoft officielle, sauf si votre application est une offre Microsoft 1P officielle.

Application en double

• Les applications du même développeur offrant les mêmes fonctionnalités doivent partager une liste d’applications, sauf si les exigences de conformité en matière de confidentialité imposent des listes d’applications distinctes ou une liste d’applications distinctes sont requises pour prendre en charge le cloud du secteur public. Vous devez intégrer votre logique métier et publier une seule liste. [Doit corriger]

  • Pour répondre aux exigences de prise en charge de plusieurs régions, vous devez intégrer votre logique métier et publier une seule description.

  

  • Pour répondre à plusieurs exigences de point de terminaison pour le déploiement local et sur le cloud, vous devez intégrer votre logique métier et publier une seule liste.

Convient à une utilisation dans l’espace de travail

[Doit corriger]

Cette section est conforme à la politique de certification commerciale de Microsoft numéro 1140.1.2, 100.8 et 100.10 et fournit des conseils supplémentaires aux développeurs sur la création d’applications appropriées à l’espace de travail.

Développer pour en savoir plus

Le contenu de l'application doit être adapté à la consommation générale sur le lieu de travail et respecter toutes les restrictions énumérées dans les politiques de certification du marché commercial. Le contenu lié à la religion, à la politique, aux jeux et aux divertissements prolongés est interdit. [Doit corriger]

Votre application doit permettre la collaboration de groupe, améliorer la productivité d'un individu, ou les deux. Les applications destinées à la socialisation et à l’esprit d’équipe doivent être collaboratives et conçues pour plusieurs participants. Les applications ne doivent pas nécessiter un investissement de temps substantiel de plus de 60 minutes par session ou affecter la productivité. [Doit corriger]

Les applications d’agrégation de contenu doivent disposer d’un mécanisme permettant aux utilisateurs de signaler un problème ou du contenu inapproprié à l’éditeur de l’application. [Doit corriger]

Plateformes et services similaires

[Doit corriger]

Cette section est conforme à la politique de certification commerciale de Microsoft numéro 1140.1.3.

Les applications doivent se concentrer sur l'expérience Teams et ne pas inclure les noms, icônes ou images d'autres plates-formes ou services de collaboration similaires basés sur le chat dans le contenu de l'application ou dans les métadonnées de l'application, à moins que l'application ne fournisse une interopérabilité spécifique.

Noms de fonctionnalité

Les noms des fonctionnalités d’application dans les boutons et autres textes de l’interface utilisateur ne doivent pas utiliser la terminologie réservée à Teams et à d’autres produits Microsoft. Par exemple, Démarrer une réunion, Passer un appel ou Démarrer une conversation sont des noms de fonctionnalités utilisés par Microsoft dans Microsoft Teams. Si nécessaire, incluez le nom de votre application pour clarifier la distinction, par exemple Démarrer la réunion Contoso.

Authentification

[Doit corriger]

Cette section est conforme à la politique de certification commerciale de Microsoft numéro 1140.1.4 et fournit des conseils aux développeurs sur l’authentification de leurs applications auprès de services externes.

Pour plus d'informations sur la mise en œuvre de l'authentification des applications, consultez l'authentification dans Teams.

Développer pour en savoir plus

Authentification avec des services externes

Si votre application authentifie les utilisateurs avec un service externe, suivez ces instructions :

• Expériences d’inscription, de connexion et de déconnexion :

  • Les applications qui dépendent de comptes ou de services externes doivent fournir une expérience de connexion, de déconnexion et d'inscription claire et simple. [Doit corriger]
  • Lorsque les utilisateurs se déconnectent, ils doivent se déconnecter uniquement de l'application et rester connectés à Teams. [Doit corriger]
  • Les applications qui dépendent de comptes ou de services externes doivent permettre aux nouveaux utilisateurs de s'inscrire ou de contacter l'éditeur de l'application pour en savoir plus sur les services et accéder aux services. La procédure à suivre doit être disponible dans le manifeste de l’application, la description longue d’AppSource et l’expérience de première exécution de l’application (message de bienvenue du bot, configuration de l’onglet ou page de configuration). [Doit corriger]
  • Les applications qui nécessitent que l’administrateur du locataire effectue une configuration unique doivent appeler la dépendance vis-à-vis de l’administrateur du locataire pour configurer l’application (avant qu’un autre utilisateur client puisse installer et utiliser l’application). La dépendance doit être appelée dans le manifeste de l’application, la description longue d’AppSource, tous les points de contact de l’expérience de première exécution (message d’accueil du bot, configuration d’onglet ou page de configuration), le texte d’aide jugé nécessaire dans le cadre de la réponse du bot, les extensions de composition ou le contenu d’onglet statique. [Doit corriger]

• Expériences de partage de contenu : les applications qui nécessitent une authentification auprès d'un service externe pour partager du contenu dans les canaux Teams doivent indiquer clairement dans la documentation d'aide (ou des ressources similaires) comment déconnecter ou annuler le partage de contenu si cette fonctionnalité est prise en charge sur le service externe. Cela ne signifie pas que la possibilité d’annuler le partage de contenu doit être présente dans votre application Teams.

L’audio

• Si l’objectif principal de l’application est d’écouter de la musique, elle doit prendre en charge au moins une étendue collaborative avec un workflow de bout en bout spécifique à l’application. Par exemple, le partage de playlist, la configuration ou l’épinglage de la playlist et l’écoute synchrone de la musique. [Doit corriger]

• Les applications publiées dans le but principal de permettre aux utilisateurs d’écouter de la musique dans Teams sont recommandées pour inclure une expérience de co-écoute collaborative. [Bon à corriger]

Sécurité

Cette section est conforme à la politique de certification commerciale de Microsoft numéro 1140.3.

Retour en haut

Informations financières

[Doit corriger]

Cette section est conforme à la politique de certification commerciale de Microsoft numéro 1140.3.1 et fournit des conseils sur la transmission d’informations financières au sein de l’interface Teams et informe les développeurs des scénarios de paiement restreint sur la version mobile (Android et iOS) de leur application Teams.

Développer pour en savoir plus

Les applications ne doivent pas demander aux utilisateurs d’effectuer des paiements dans l’interface Teams et de transmettre des informations financières aux utilisateurs via une interface de bot. [Doit corriger]

Vous pouvez fournir un lien vers des services de paiement externes sécurisés uniquement si vous le divulguez dans vos conditions d'utilisation, votre politique de confidentialité, votre page de profil ou votre site Web avant que l'utilisateur n'accepte d'utiliser l'application. [Doit corriger]

Ne facilitez pas les paiements via une application pour des biens ou des services interdits par la Police générale numéro 100.10 Contenu inapproprié. [Doit corriger]

Les applications qui s’exécutent sur la version iOS ou Android de Teams doivent respecter les instructions suivantes :

• Les applications ne doivent pas inclure d’achats dans l’application, d’offres d’essai ou d’interface utilisateur qui visent à faire passer des versions payantes ou des magasins en ligne pour acheter d’autres contenus, applications ou compléments. [Doit corriger]

  

  

• Si votre application nécessite un compte, les utilisateurs peuvent créer un compte gratuitement. L’utilisation du terme compte gratuit ou gratuit est interdite. [Doit corriger]

• Vous pouvez déterminer si un compte est actif indéfiniment ou pour une durée limitée. Lorsque le compte expire, l’application ne doit pas afficher l’interface utilisateur, le texte ou les liens indiquant la nécessité de payer. [Doit corriger]

• La politique de confidentialité et les conditions d'utilisation de votre application doivent être exemptes d'interface utilisateur ou de liens liés au commerce. [Doit corriger]

Bots

[Doit corriger]

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.3.2.

Développer pour en savoir plus

Pour les applications qui utilisent Microsoft Azure Bot Service (par exemple, les bots et les extensions de messagerie), vous devez respecter toutes les conditions définies dans les Conditions d’utilisation des services en ligne Microsoft.

Les robots doivent toujours demander la permission de télécharger un fichier et afficher un message de confirmation.

Domaines externes

[Doit corriger]

Cette section est conforme à la stratégie de la Place de marché commerciale Microsoft numéro 1140.3.3 et fournit des conseils aux développeurs sur l’utilisation de domaines restreints dans la propriété manifeste de l’application validDomains .

Développer pour en savoir plus

N’incluez pas de domaines en dehors du contrôle de votre organization (y compris les caractères génériques) et les services de tunneling dans les configurations de domaine de votre application. Les exceptions suivantes comprennent :

• Si votre application repose sur SharePoint, vous pouvez inclure le site racine SharePoint associé en tant que domaine valide à l’aide de la propriété de contexte {teamSiteDomain}. [Doit corriger]

• N’utilisez pas de domaines de niveau supérieur tels que .com, .in et .org comme domaine valide. [Doit corriger]

• N’utilisez pas .onmicrosoft.com ou comme domaine valide où onmicrosoft n’est pas sous votre contrôle. Toutefois, vous pouvez utiliser yoursite.com comme domaine valide où votre site est sous votre contrôle, même si le domaine inclut un caractère générique. [Doit corriger]

• Si votre application est une application PowerApp basée sur Microsoft Power Platform, vous devez inclure apps.powerapps.com en tant que domaine valide pour permettre à votre application d’être accessible et fonctionnelle dans Teams.

• Les domaines externes déclarés pour votre soumission ne doivent pas contenir d’URL. Par exemple, www ou https. [Doit corriger]

• Si votre application utilise la carte OAuthCard d’Azure Bot Service, vous devez inclure token.botframework.com comme domaine valide, sinon le bouton Se connecter ne fonctionnera pas. Vous ne devez pas déclarer .botframework.com car les caractères génériques ne sont pas autorisés avec ce nom de domaine. [Doit corriger]

• Les URL OpenAPI doivent être sous le contrôle du partenaire.

• Les domaines externes suivants ne sont pas autorisés : [Doit corriger]

  • *.azurewebsites.net
  • *.azureedge.com
  • *.microsoft.com
  • *.microsoftonline.com
  • *.onmicrosoft.com
  • go.microsoft.com
  • teams.microsoft.com

Lorsque vous utilisez des caractères génériques (*), les règles suivantes s’appliquent :

• Si un segment de sous-domaine inclut un caractère générique, il doit s’agir du seul caractère du segment.
• Tout segment précédant un segment générique doit également être un segment générique.

Par exemple, *.*.domain.com est valide, mais foo.*.myteam.domain.com n’est pas valide.

Contenu sensible

[Doit corriger]

Votre application ne doit pas publier de données sensibles, telles que les carte de crédit, les détails de paiement financier, l’intégrité, le suivi des contacts ou d’autres informations d’identification personnelle (PII) à un public qui n’est pas destiné à afficher le contenu.

L'application doit avertir les utilisateurs avant de télécharger des fichiers ou des exécutables (.exe) sur la machine ou l'environnement de l'utilisateur.

Fonctionnalités et performances générales

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.4.

• L’aide à suivre est obligatoire pour les administrateurs et les utilisateurs existants. Vous pouvez ajouter des instructions sur l’avenir sous forme de liens hypertexte pour vous inscrire, commencer, nous contacter, des liens d’aide ou un e-mail.
• L’appel de dépendances ou de limitations de compte sous la fonctionnalité de l’application n’est pas obligatoire, mais il est obligatoire de l’ajouter à la fois dans la description longue du manifeste de l’application et dans la liste des applications AppSource.
• Vous devez appeler toute dépendance vis-à-vis des administrateurs de locataire pour les nouveaux utilisateurs. S’il n’existe aucune dépendance, il est obligatoire de fournir une inscription, de nous contacter, d’un lien de démarrage ou d’un e-mail.

Retour en haut

Lancement des fonctionnalités externes

[Doit corriger]

Les applications ne doivent pas exclure les utilisateurs de Teams pour les scénarios utilisateur principaux. Le contenu et les interactions de l’application doivent se produire dans les fonctionnalités de Teams, telles que les bots, les cartes adaptatives, les onglets et les boîtes de dialogue (appelées modules de tâche dans TeamsJS v1.x).

Remarque

Pour rediriger les utilisateurs de votre application Teams vers son expérience native via un lien profond avec un protocole tel que , ou , lancez le lien profond dans une nouvelle fenêtre en appelant la window.open méthode ou en utilisant une balise d’ancrage avec target="_blank".webex:mailto:tel:

Développer pour en savoir plus

• Liez les utilisateurs au sein de l'application Teams et non à un site ou une application externe. Pour les scénarios qui nécessitent une fonctionnalité externe, votre application doit obtenir une autorisation utilisateur explicite pour lancer la fonctionnalité. [Doit corriger]

• Le texte de l'interface utilisateur du bouton qui lance la fonctionnalité externe doit inclure du contenu pour indiquer que l'utilisateur est retiré de l'instance Teams. Par exemple, incluez du texte tel que Par ici vers Contoso.com ou Afficher dans Contoso.com. [Doit corriger]

• Icône Ajouter une fenêtre contextuelle pour informer les utilisateurs qu’ils sont en cours de navigation en dehors de Teams. Vous pouvez utiliser l’icône contextuelle à droite du lien. [Doit corriger]

• Si vous ne parvenez pas à ajouter une icône contextuelle , vous pouvez implémenter l’une des options suivantes pour informer l’utilisateur qu’il est en cours de navigation en dehors de Teams : [Doit corriger]

  • Ajoutez une note dans carte adaptative qui indique que lorsque les utilisateurs sélectionnent Obtenir de l’aide à l’aide de cette application, l’utilisateur est en dehors de Teams.
  • Boîtes de dialogue Ajouter des interstitiels.

Compatibilité

[Doit corriger]

Les applications doivent être entièrement fonctionnelles sur les dernières versions des systèmes d'exploitation et des navigateurs suivants :

• Microsoft Windows
• macOS
• Microsoft Edge
• Google Chrome
• iOS
• Android

Votre application doit afficher un message d'échec normal sur les navigateurs et systèmes d'exploitation non pris en charge.

Temps de réponse

[Doit corriger]

Les applications Teams doivent répondre dans un délai raisonnable ou afficher un indicateur de chargement ou de saisie, un message ou un avertissement.

• Les onglets doivent répondre dans les deux secondes ou afficher un message de chargement ou un avertissement. [Doit corriger]
• Les bots doivent répondre aux commandes de l’utilisateur dans un délai de deux secondes ou afficher un indicateur de saisie. [Doit corriger]
• Les extensions de messagerie doivent répondre aux commandes de l'utilisateur dans les deux secondes. [Doit corriger]
• Les notifications doivent s'afficher dans les deux secondes suivant l'action de l'utilisateur. [Doit corriger]

Applications optimisées par l’intelligence artificielle

Explorez les ressources conçues pour vous aider à utiliser des pratiques d’intelligence artificielle (IA) responsables à chaque étape de l’innovation, par exemple Microsoft RAI Toolkit et HAX Toolkit Project.

Cette section est conforme à la stratégie de la Place de marché commerciale Microsoft pour les applications avec contenu généré par l’IA et à la stratégie de place de marché commerciale Microsoft pour les applications utilisant des fonctionnalités de reconnaissance faciale.

Applications avec du contenu généré par l’IA

• L’application ne doit pas générer, contenir ou fournir l’accès à du contenu généré par l’IA inapproprié, nuisible ou offensant, conformément aux stratégies de la place de marché commerciale existantes décrites dans la version 100.10. [Doit corriger]

  • Envisagez d’utiliser l’un des éléments suivants :
    • Utilisez la bibliothèque IA Teams, l’interface centrée sur Teams pour les modèles de langage commun basés sur GPT et les moteurs d’intention utilisateur. [Bon à corriger]
    • Utilisation de hooks de modération, qui peuvent être utilisés pour réguler les réponses des bots via l’API de modération. [Bon à corriger]
    • Ajoutez la fonctionnalité de balayage des conversations, qui vous permet de surveiller les conversations et d’intervenir en cas de déraillement des conversations. [Bon à corriger]

• L’application doit fournir des mécanismes permettant aux utilisateurs de l’application de signaler le contenu inapproprié, nuisible ou offensant au développeur par l’un des mécanismes suivants : [Doit corriger]

  • Description de l’application, y compris l’ID de messagerie ou le lien vers le portail pour journaliser le problème.
  • Dans le mécanisme de l’application pour journaliser le problème avec une référence spécifique au contenu inapproprié.

• Vous devez prendre des mesures en temps opportun pour répondre aux préoccupations signalées. [Doit corriger]

• L’application doit décrire clairement les fonctionnalités d’IA avant que le client n’acquiert l’offre conformément à la stratégie 100.1.3 et inviter l’utilisateur à examiner les informations dans le cadre des fonctionnalités de l’application. [Doit corriger].

  

Applications utilisant des fonctionnalités de reconnaissance faciale

Remarque

Les applications de cette catégorie peuvent faire l’objet d’un examen supplémentaire pour leur conformité aux principes de l’IA responsable de Microsoft.

• L’application ne doit pas autoriser l’utilisation des fonctionnalités de reconnaissance faciale pour identifier une personne devant être utilisée par ou pour un service de police dans le États-Unis. [Doit corriger]
• Pour les applications utilisant des technologies de reconnaissance faciale ou d’inférence émotionnelle, vous devez fournir une étiquette ou une indication de chacune de ces fonctionnalités dans la description de l’application. [Doit corriger]
  • Les applications qui utilisent des expressions faciales ou des mouvements du visage pour déduire des états émotionnels, tels que la colère, le dégoût, le bonheur, la tristesse, la surprise, la peur, ou d’autres termes couramment utilisés pour décrire l’état émotionnel d’une personne peuvent être limitées en fonction de la révision.
  • L’utilisation d’expressions faciales et de mouvements pour détecter et classer uniquement des éléments faciaux individuels, tels que des sourires ou des sourcils levés, est autorisée. La distinction clé est entre la détection d’expressions faciales ou de mouvements comme signaux visuels et l’inférence d’un état émotionnel.

Package d’application et description du Store Teams

[Doit corriger]

Les packages d’application doivent être correctement formatés et inclure toutes les informations et composants requis.

Conseil

• Vous devez vous assurer que les comptes de test ou l’environnement de test fournis sont valides à perpétuité, c’est-à-dire jusqu’à ce que l’application soit en ligne sur la place de marché commerciale.

• Vous devez inclure les instructions de test détaillées suivantes pour valider la soumission de votre application :

  • Étapes pour configurer les comptes de test d'application au cas où l'application dépendrait de comptes externes pour l'authentification.
  • Résumé du comportement attendu de l'application pour les workflows de base au sein des équipes.
  • Décrivez clairement les limitations, conditions ou exceptions aux fonctionnalités, fonctionnalités et livrables dans la description longue de l’application et les documents connexes.
  • Mettre l'accent sur toutes les considérations pour les testeurs lors de la validation de la soumission de votre application.
  • Préremplir les comptes de test avec des données factices pour faciliter le test.
  • Si vous fournissez vos comptes de test, veillez à activer l’intégration tierce.

Retour en haut

Manifeste d'application

[Doit corriger]

Le manifeste de l’application définit la configuration de votre application.

• Votre manifeste d’application doit être conforme à un schéma de manifeste d’application publié publiquement. Pour plus d’informations, consultez Informations de référence sur le manifeste d’application. N’envoyez pas votre application à l’aide d’une préversion du manifeste de l’application.
• Si votre application inclut un bot ou une extension de messagerie, les détails du manifeste de l'application doivent être cohérents avec les métadonnées de Bot Framework, notamment le nom du bot, le logo, le lien vers la politique de confidentialité et le lien vers les conditions d'utilisation.
• Si votre application utilise Microsoft Entra ID pour l’authentification, incluez l’ID d’application (client) Microsoft Entra dans le manifeste de l’application. Pour plus d’informations, consultez la référence du manifeste de l’application.

Utilisations du schéma de manifeste d’application le plus récent

• Si votre application utilise l’authentification unique (SSO), vous devez déclarer Microsoft Entra ID dans le manifeste de l’application pour l’authentification utilisateur. [Doit corriger]

• Vous devez utiliser un schéma de manifeste d’application publié publiquement. Vous pouvez mettre à jour votre package d’application pour utiliser une version publique du schéma de manifeste d’application 1.10 ou version ultérieure. [Doit corriger]

• Lorsque vous envoyez une mise à jour d’application, augmentez uniquement le numéro de version de l’application. L’ID d’application de l’application mise à jour doit correspondre à l’ID d’application de l’application publiée. [Doit corriger]

• La présence de fichiers supplémentaires dans le package d’application n’est pas acceptable. [Doit corriger]

• Le numéro de version doit être le même dans le schéma du fichier manifeste d’application et dans le schéma du manifeste d’application de langages supplémentaires. [Doit corriger]

• Vous devez utiliser le schéma de manifeste d’application version 1.5 ou ultérieure pour localiser votre application. Pour utiliser le schéma d’application version 1.5 ou ultérieure dans votre fichier manifest.json, mettez à jour l’attribut $schema vers la version 1.5 ou ultérieure. Mettez à jour la manifestVersion propriété vers $schema la version (1.5 dans ce cas). [Doit corriger]

• Lorsque vous ajoutez, mettez à jour ou supprimez une fonctionnalité existante, ajoutez ou supprimez un manifeste d’application ou des métadonnées de l’Espace partenaires, vous devez augmenter le numéro de version de l’application et soumettre le nouveau manifeste d’application dans votre compte Espace partenaires pour validation. [Doit corriger]

• La chaîne de version doit suivre la norme SemVer (Semantic Versioning Specification) (MAJOR. MINEUR. PATCH). [Doit corriger]

• Si votre application nécessite que les administrateurs passent en revue les autorisations et accordent leur consentement dans le Centre d’administration Teams, vous devez déclarer webapplicationinfo dans le manifeste de l’application. Si webapplicationinfo n’est pas déclaré dans le manifeste de l’application, la page Autorisations de votre application dans le Centre d’administration Teams s’affiche sous la forme ... [Doit corriger]

• Dans le cadre de la certification d’application Teams, vous devez soumettre une version de production du manifeste de l’application. [Doit corriger]

• Nous vous recommandons de déclarer l’ID du programme Microsoft Cloud Partner (ID CCP), anciennement appelé Microsoft Partner Network (ID MPN) dans le manifeste de l’application. L’ID CCP permet d’identifier le organization partenaire qui génère l’application. [Bon à corriger]

• Les étendues et/ou le contexte déclarés dans le manifeste de l’application doivent être visibles dans l’application. [Doit corriger]

Icônes d’application

[Doit corriger]

Les icônes sont l’un des éléments main que les utilisateurs voient quand ils naviguent dans le Magasin Teams.

Développer pour en savoir plus

Vos icônes doivent communiquer la marque et l'objectif de votre application tout en respectant les exigences suivantes :

• La couleur et l’icône de contour de l’application envoyées dans la description de l’application doivent correspondre. [Doit corriger]

  

  

• Votre package d’application doit inclure deux versions .png de votre icône d’application : une icône de couleur et une icône de contour. [Doit corriger]

• L’icône de place de marché chargée dans le cadre de la description de la Place de marché de l’application dans votre compte Espace partenaires doit correspondre à l’icône de couleur fournie dans votre package d’application. [Doit corriger]

• La version couleur de votre icône doit être de 192x192 pixels. Votre symbole d'icône peut être de n'importe quelle couleur, mais il doit être placé sur un fond carré uni ou entièrement transparent. [Doit corriger]

• La version simplifiée de votre icône s'affiche dans les scénarios suivants :

  • Lorsque votre application est utilisée et hébergée dans la barre d'applications sur le côté gauche de Teams.
  • Lorsqu’un utilisateur épingle l’extension de message de votre application.

• Le contour doit être de 32x32 pixels et peut être blanc avec un fond transparent ou transparent avec un fond blanc. L’icône ne doit pas avoir de remplissage supplémentaire autour du symbole. [Doit corriger]

• Votre package d'application doit inclure des icônes correctement dimensionnées et formatées. Les icônes doivent correspondre aux informations contenues dans les métadonnées de description du Magasin Teams. [Doit corriger]

Pour plus d'informations, consultez les instructions relatives aux icônes.

Descriptions de l’application

Vous devez avoir une description courte et longue pour votre application. La description de l’application permet d’améliorer la détectabilité de votre application dans le Magasin Teams. Les descriptions dans la configuration de votre application et dans l’Espace partenaires doivent être identiques.

Développer pour en savoir plus

Les descriptions ne doivent pas déroger directement ou par le biais d’une suggestion à une autre marque (appartenant à Microsoft ou autrement). Assurez-vous que votre description n’inclut pas de revendications qui ne peuvent pas être justifiées. Par exemple, Augmentation garantie de 200 % de l'efficacité.

• La description de l’application ne doit pas contenir d’informations marketing comparatives. Par exemple, n’utilisez pas de logos ou de marques commerciales concurrents dans le référencement de l’offre, y compris des étiquettes ou d’autres métadonnées qui font référence à des offres ou des places de marché concurrentes. [Doit corriger]

  

• Lien hypertexte : coordonnées, prise en main, aide ou inscription dans la description de l’application. [Bon à corriger]

  

  

• La description de l’application doit identifier l’audience prévue, expliquer brièvement et clairement sa valeur unique et distincte, identifier les produits Microsoft pris en charge et les autres logiciels, et inclure les conditions préalables ou requises pour son utilisation. Vous devez décrire clairement les limitations, conditions ou exceptions aux fonctionnalités, fonctionnalités et livrables décrites dans la description et les documents connexes avant que le client acquière votre offre. Les fonctionnalités que vous déclarez doivent être liées aux fonctions principales et à la description de votre offre. [Doit corriger]

• Si vous mettez à jour le nom de votre application, remplacez l’ancien nom de l’application par le nouveau nom de l’application dans les métadonnées de l’offre dans le manifeste de l’application, AppSource et le cas échéant. [Doit corriger]

• Les limitations et les dépendances de compte doivent être appelées dans les manifestes Description de l’application, AppSource et Espace partenaires. Par exemple :

  • Compte d’entreprise
  • Abonnement payant
  • Une autre licence ou un autre compte
  • Langue
  • Numérotation du réseau téléphonique commuté public (RTC)
  • Dépendance régionale
  • Délai de réservation pour les traducteurs ou les agents en direct
  • Fonctionnalité basée sur les rôles
  • Dépendance à l’application native

  

  

• Si votre application est prise en charge pour des régions ou des emplacements géographiques spécifiques, vous devez appeler cette dépendance de région spécifique dans la description de l’application dans le manifeste de l’application, l’Espace partenaires et AppSource pour cette offre.

• Si vous avez besoin de référencer Teams, écrivez la première référence dans la liste des applications en tant que Microsoft Teams. Les références ultérieures peuvent être raccourcies à Teams. [Doit corriger]

  

  

Description courte

Une brève description doit être un résumé concis de votre application qui met en évidence sa proposition de valeur et s’adresse à votre public cible.

À faire :

• Votre description courte doit tenir sur une seule phrase.
• Mettez les informations les plus importantes en premier.
• Incluez des mots clés que les clients sont susceptibles de rechercher.
• Utilisez efficacement la limite de caractères disponible. Par exemple, ne répétez pas le nom de votre application.

À ne pas faire :

[Bon à corriger]

Utilisez le mot application dans la description courte.

Description longue

La description longue doit fournir une narration attrayante qui met en évidence la proposition de valeur de votre application, l’audience principale et le secteur cible. Bien que la description puisse contenir jusqu’à 4 000 caractères, nous vous recommandons d’avoir une description concise d’environ 1 000 caractères.

À faire :

• Utilisez Markdown pour mettre en forme votre description.

• Utilisez la voix active et parlez directement aux utilisateurs. Par exemple, Vous pouvez....

• Répertoriez les principaux avantages pour mettre en évidence les avantages de l’utilisation de votre application. Ajoutez jusqu’à trois avantages.

• Ajoutez la proposition de valeur clé de votre application dans Teams.

• Répertoriez les fonctionnalités à l’aide de points à puces pour faciliter l’examen de la description.

• Décrivez clairement les limitations, caractéristiques, conditions ou exceptions à la fonctionnalité et les livrables dans la liste et les documents connexes avant que l'utilisateur n'installe votre application. Les capacités des équipes doivent être liées aux fonctions de base décrites dans la liste.

• Vérifiez que la description de l’application correspond à la fonctionnalité disponible dans l’application Teams. Toute référence à des flux de travail en dehors de l'application Teams doit être limitée et distinctement appelée à partir de la fonctionnalité de l'application Teams.

• Incluez un lien d’aide ou de support.

• Faites référence à Microsoft 365 au lieu d’Office 365.

• Utilisez le langage suivant pour décrire le fonctionnement de l’application avec Teams (ou Microsoft 365) :

  • « ... fonctionne avec Microsoft Teams. »
  • « ... fonctionner avec Microsoft Teams. »
  • « ... dans Microsoft Teams. »
  • « ... pour Microsoft Teams. »
  • « ... intégré à Microsoft Teams. »
  • ... conçu pour...
  • ... développé pour...
  • .. conçu pour...

À ne pas faire

[Doit corriger]

• Supérieure à 500 mots.

• Abrégez Microsoft en tant que MS ou MSFT.

  

  

• Indiquez que l’application est une offre de Microsoft, y compris à l’aide de slogans ou d’accroches Microsoft.

  

  

• Utilisez la langue suivante, sauf si vous êtes un partenaire Microsoft certifié :

  • « ... certifié pour ... »
  • « ... optimisé par ... »

• Inclure les fautes de frappe, les erreurs grammaticales.

• Mettez inutilement en majuscules l’intégralité du manifeste d’application ou de la description longue ou du contenu de l’application AppSource.

  

  

• Incluez des liens vers AppSource.

  

• Faire des réclamations non vérifiées. Par exemple, meilleur, premier et classé, à moins que cela ne vienne avec la source de la réclamation.

• Comparez votre offre avec d’autres offres du marché.

Pour obtenir des conseils sur la création d’une description courte et longue précise, concise et informative, consultez check-list pour écrire des descriptions d’application.

Captures d’écran

Les captures d’écran fournissent un aperçu visuel évident de votre application pour compléter le nom, l’icône et les descriptions de votre application.

Développer pour en savoir plus

N'oubliez pas ce qui suit :

• Vous pouvez avoir jusqu’à cinq captures d’écran par référencement.
• Les types de fichiers pris en charge sont PNG, JPEG et GIF.
• Les dimensions doivent être de 1366x768 pixels.
• Taille maximale de 1 024 Ko.

À faire :

• Concentrez-vous sur les fonctionnalités de votre application. Par exemple, comment les utilisateurs peuvent communiquer avec votre bot.

• Incluez du contenu qui représente précisément votre application.

• Utilisez le texte judicieusement.

• Cadrez les captures d'écran avec une couleur qui reflète votre marque et incluez du contenu marketing.

• Utilisez des captures d’écran haute résolution qui sont nettes et contiennent du texte lisible et clairement lisible. [Doit corriger]

• Au moins une capture d’écran doit représenter les fonctionnalités de votre application sur les appareils mobiles. [Doit corriger]

  

• Vous pouvez avoir jusqu’à cinq captures d’écran par référencement. Vous devez disposer d’un minimum de trois captures d’écran et d’un maximum de cinq captures d’écran dans votre liste d’applications. [Doit corriger]

• Utilisez des maquettes qui représentent avec précision l’interface utilisateur réelle de l’application pour le bénéfice des utilisateurs finaux. Les captures d’écran doivent représenter avec précision l’interface utilisateur réelle de l’application ou les scénarios relatifs à l’application. [Doit corriger]

  

  

• Doit représenter les fonctionnalités de l’application ou l’intégration à Teams. [Doit corriger]

  

• Les captures d’écran fournies ne doivent pas faire référence incorrectement à Microsoft Teams en tant que MS, MSFT ou MS Teams. [Doit corriger]

• Si votre application Teams est extensible sur les clients Microsoft 365 (Microsoft 365, Outlook et Microsoft Teams), les captures d’écran fournies doivent représenter les fonctionnalités de l’application dans d’autres clients Microsoft 365. [Doit corriger]

  

• Vous devez fournir des légendes dans vos captures d’écran pour permettre à l’utilisateur de comprendre clairement la fonctionnalité de l’application. [Doit corriger]

  

• Si votre application prend en charge les onglets en tant que fonctionnalité, les captures d’écran présentant l’application dans le contexte d’un onglet Teams, dans la liste des applications, doivent contenir le chrome de Team. [Doit corriger]

  

À ne pas faire

• Incluez des maquettes qui reflètent de manière inexacte l’interface utilisateur réelle de votre application, telles que l’affichage de votre application utilisée en dehors de Teams.

  

Vidéos

Une vidéo dans la liste de votre application est l’un des moyens les plus efficaces de communiquer pourquoi les utilisateurs doivent utiliser votre application. Vous pouvez ajouter votre URL vidéo YouTube ou Vimeo qui fournit la valeur de votre application. En outre, nous vous recommandons d’ajouter une vidéo qui fournit la démonstration ou la procédure pas à pas de scénario de votre application. [Bon à corriger]

Si vous choisissez d’envoyer une vidéo dans le cadre de votre liste d’applications dans votre compte Espace partenaires, vérifiez que vous répondez aux critères suivants :

• La vidéo doit être courte, claire, attrayante et de bonne qualité.

• La vidéo doit montrer comment configurer et utiliser l’application.

• La vidéo doit être sous une forme narrative.

• La durée de la vidéo doit être comprise entre 60 et 90 secondes pour une vidéo de valeur et la durée recommandée pour une vidéo pas à pas est de 3 à 5 minutes. [Bon à corriger]

• Vous devez désactiver les publicités à partir des paramètres de votre compte YouTube ou Vimeo avant d’envoyer le lien vidéo dans la liste de l’application. [Doit corriger]

• La vidéo doit mettre en évidence les fonctionnalités et l’intégration de votre application dans Teams. [Doit corriger]

• La vidéo doit être disponible en tant que lien fonctionnel. [Doit corriger]

• La vidéo doit être au format https://www.youtube.com/watch?v=:id ou https://youtu.be/:id pour YouTube et https://vimeo.com/:id pour Vimeo.

  

• La vidéo peut être exposée à la première position des captures d’écran ou des vidéos du carrousel dans les détails de l’application (Teams Store et centre Administration) et les pages AppSource. [Bon à corriger]

• La vidéo sur la démonstration ou la procédure pas à pas de scénario doit avoir pour but d’éduquer les utilisateurs et non de promouvoir votre application.

Pour plus d’informations sur les critères de création d’une vidéo de valeur d’application ou de vidéo pas à pas, consultez la liste de contrôle pour créer une vidéo.

Déclaration de confidentialité

[Doit corriger]

La politique de confidentialité peut être spécifique à votre application Teams ou à une stratégie globale pour tous vos services.

• Si vous utilisez un modèle de politique de confidentialité générique, vous devez ajouter une référence aux services, applications, ou plateformes dans le cadre de votre politique de confidentialité. Vous n’avez pas besoin de spécifier votre application Teams dans l’étendue, si vous incluez une référence aux services, applications et plateformes. Le processus de validation de l’application interprète ces références pour inclure votre application Teams avec vos autres services ou sites web.
• Doit inclure la façon dont vous traitez le stockage, la rétention et la suppression des données utilisateur. Vous devez décrire les contrôles de sécurité pour la protection des données.
• Doit inclure vos informations de contact.
• Ne doit pas inclure d'URL cassées ou à des fins de bêta ou de transfert.
• Ne doit pas inclure de liens vers AppSource.
• Ne doit pas exiger d'authentification pour accéder à la politique de confidentialité.
• Ne doit pas inclure d'interface utilisateur de commerce ou de liens de magasin.
• Doit avoir le même lien dans le manifeste de l’application et AppSource.

Conditions d’utilisation

[Doit corriger]

Utilisez les directives suivantes pour rédiger les conditions d'utilisation :

• Doit être spécifique et applicable à votre offre.
• Doit être hébergé sur votre propre domaine.
• Doit avoir un lien sécurisé (HTTPS).
• L'accès aux Conditions d'utilisation ne doit pas nécessiter d'authentification.
• Doit avoir le même lien dans le manifeste de l’application et AppSource.

Liens vers le support technique

[Doit corriger]

Les URL de support de votre application ne doivent pas nécessiter d’authentification. Par exemple, les utilisateurs doivent être autorisés à vous contacter sans se connecter.

Développer pour en savoir plus

Les URL d'assistance doivent inclure vos coordonnées ou une voie à suivre pour que les utilisateurs créent un ticket d'assistance. Par exemple, si votre URL d'assistance est hébergée sur GitHub, la page GitHub doit être votre propriété et doit inclure vos coordonnées ou une voie à suivre pour que les utilisateurs créent un ticket d'assistance.

Localisation

[Doit corriger]

• Si votre application prend en charge la localisation, votre package d’application doit inclure un fichier avec des traductions linguistiques qui s’affichent en fonction du paramètre de langue Teams. Le fichier doit être conforme au schéma de localisation Teams. Pour plus d'informations, consultez Schéma de localisation Teams. [Doit corriger]

• Le contenu des métadonnées d’application doit être identique dans et dans en-us les autres langues de localisation. [Doit corriger]

• Les langues prises en charge doivent être affichées dans la description de l’application AppSource. Par exemple, cette application est disponible en X (X= langue localisée). [Doit corriger]

• Si les paramètres client de l’utilisateur ne correspondent à aucune de vos langues supplémentaires, la langue par défaut est utilisée comme langue de secours finale. Mettez à jour la localizationInfo propriété avec la langue par défaut correcte prise en charge par votre application. [Doit corriger]

• Mettez à jour la localizationInfo propriété avec la langue par défaut appropriée prise en charge par votre application ou ajoutez du contenu localisé pour le manifeste de l’application et la description longue et courte de l’Espace partenaires. [Doit corriger]

Applications liées à l'offre SaaS

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.5. Si vous créez une application Teams liée à une offre SaaS (Software as a Service), assurez-vous qu’elle respecte ces instructions.

Généralités

• Les ISV doivent prendre en charge la possibilité pour plusieurs utilisateurs (abonnés) d'un même locataire de gérer leur propre abonnement et d'attribuer des licences aux utilisateurs du locataire.
• L'offre doit répondre à toutes les exigences techniques des applications Teams liées à une offre SaaS.
• Les applications Teams liées à l'offre SaaS doivent répondre à toutes les exigences définies dans 1000 Software as a Service (SaaS).
• subscriptionOffer les détails mentionnés dans le fichier manifeste de l’application doivent être corrects. Dans le manifeste de votre application, ajoutez ou mettez à jour le nœud subscriptionOffer avec la valeur publisherId.offerId. Par exemple, si votre ID d'éditeur est contoso1234 et que votre ID d'offre est offer01, la valeur que vous spécifiez dans le manifeste de votre application doit être contoso1234.offer01.
• L’offre SaaS liée à l’application Teams doit être en ligne dans AppSource et les offres en préversion ne sont pas acceptées pour l’approbation du Magasin Teams.

Métadonnées de l’offre

• Les métadonnées de l’offre doivent correspondre dans le manifeste de l’application, la liste des applications Teams dans AppSource et l’offre SaaS dans AppSource.
• L'application Teams et l'offre SaaS doivent provenir du même éditeur ou développeur. L’offre SaaS référencée dans le manifeste de l’application doit appartenir au même éditeur que l’application Teams est soumise à la place de marché commerciale.
• Comme votre offre envoyée est une application Teams liée à l’offre SaaS, vous devez sélectionner Achats supplémentaires comme Oui, mon produit nécessite l’achat d’un service ou propose des achats dans l’application supplémentaires dans la section Configuration des produits de l’Espace partenaires de votre description de l’offre.
• Les descriptions des forfaits et les détails des prix doivent fournir suffisamment d'informations pour que les utilisateurs comprennent clairement les listes d'offres.
• Toutes les limitations, dépendances vis-à-vis de services supplémentaires et exceptions aux fonctionnalités proposées doivent être indiquées avec précision dans les descriptions de plan.
• Les applications Teams liées à l'offre SaaS sont conçues pour prendre en charge les licences attribuées sur une base nommée, par utilisateur. Parfois, l'offre SaaS est construite avec d'autres méthodes ou a des flux d'achat spécialisés. Vous devez clairement mentionner dans les métadonnées de l'application et les détails du plan d'abonnement sur la méthode et les flux d'achat.
• L'offre SaaS doit fournir des messages et des conseils à tous les utilisateurs dans tous les états applicables du flux d'achat.

Page d’accueil de l’offre SaaS et gestion des licences

• Fournir une introduction aux abonnés sur la façon d'utiliser le produit.

• Autoriser l'abonné à attribuer des licences.

• Fournissez différentes façons de prendre en charge les problèmes, tels que faq, base de connaissances et e-mail.

• Validez les utilisateurs pour vous assurer qu'ils n'ont pas déjà une licence attribuée par un autre utilisateur.

• Notifier les utilisateurs après l'attribution de la licence.

• Guidez les utilisateurs sur la façon d’ajouter l’application à Teams et de commencer par le biais d’un bot de conversation ou d’un e-mail Teams.

• Si une application SaaS utilise la gestion des licences Microsoft, après la confirmation de l’abonnement à l’application sur la page d’accueil de l’éditeur de logiciels indépendant, l’utilisateur doit être redirigé vers la gestion des licences Microsoft dans Teams pour éviter une impasse et permettre à l’utilisateur de gérer les licences dans Teams.

Facilité d’utilisation et fonctionnalités

• Une fois l'achat et l'attribution des licences réussis, vous devez fournir les éléments suivants :
  • Accès aux utilisateurs pour les fonctionnalités du plan souscrit.
  • Valeur ajoutée et avantages significatifs du plan d'abonnement pour les utilisateurs.
  • À partir de votre application Teams, fournissez un lien vers la page d'accueil de l'application SaaS pour que les abonnés puissent gérer les licences à l'avenir.

Configurer et tester l’application SaaS

Si la configuration de votre application à des fins de test est complexe, fournissez un document fonctionnel de bout en bout, des étapes de configuration de l’offre SaaS liées et des instructions pour la gestion des licences et des utilisateurs dans le cadre de vos Notes pour la certification.

Conseil

Vous pouvez ajouter une vidéo sur le fonctionnement de votre application et de la gestion des licences pour aider l'équipe à effectuer les tests.

Retour en haut

Onglets

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.4.2. Si votre application inclut un onglet, vérifiez qu’elle respecte ces instructions.

Conseil

Pour plus d'informations sur la création d'une expérience d'application de haute qualité, consultez les directives de conception de l'onglet Teams.

              

                             

Configuration

• La configuration de l’onglet ne doit pas arrêter un nouvel utilisateur. Fournissez un message sur la façon d’effectuer l’action ou le flux de travail. [Doit corriger]

  

• L’utilisateur ne doit pas quitter l’expérience de configuration d’onglet dans Teams pour créer du contenu en dehors de Teams, puis revenir à Teams pour l’épingler. L'écran de configuration de l'onglet doit expliquer la valeur de la configuration et comment configurer. [Doit corriger]

  

• L’écran de configuration des onglets ne doit pas incorporer un site web entier. Gardez votre expérience de configuration concentrée. Par exemple, si vous créez une application de gestion de projet qui permet aux utilisateurs de configurer un projet dans un canal, gardez l'écran de configuration de l'onglet concentré pour permettre à l'utilisateur de sélectionner un projet dans votre application à configurer dans le canal. [Doit corriger]

  

  

• Les applications qui obligent les utilisateurs à entrer une URL lors de la configuration d’un onglet doivent :

  • Fournissez un guide approprié pour l’avenir pour que l’utilisateur acquière ou génère l’URL. [Doit corriger]

  • Recherchez l’URL pertinente ou appropriée pour les fonctionnalités de l’application conformément à la description de l’application. [Doit corriger]

    

    

• Créez un lien hypertexte vers les informations de contact dans l’écran de configuration au lieu d’un texte brut pour aider les utilisateurs à vous contacter pour connaître les exigences de support. [Doit corriger]

• Pour une expérience utilisateur de première exécution transparente, nous vous recommandons de créer un lien hypertexte sur votre URL de support ou votre adresse e-mail dans l’écran de configuration. [Bon à corriger]

Affichage

• La zone d’écran de connexion ne doit pas utiliser de logos volumineux. [Doit corriger]

  

• Le contenu peut être simplifié en le décomposant sur plusieurs onglets.

  

• Les onglets ne doivent pas avoir d'en-tête en double. Supprimez les logos dupliqués de l’I-frame, car l’infrastructure d’onglets affiche déjà l’icône et le nom de l’application. [Bon à corriger]

  

  

Navigation

Voici les directives de navigation :

• Les onglets ne doivent pas fournir de navigation qui est en conflit avec la navigation principale de Teams. Si vous fournissez une navigation de gauche dans votre onglet, elle ne doit pas inclure uniquement des icônes ou des icônes avec du texte empilé. Il ne doit pas s’agir d’un rail réductible avec la possibilité d’afficher des icônes avec du texte empilé (imitant la barre de navigation Teams). Incluez des icônes avec en ligne de texte ou uniquement du texte, ou utilisez des menus hamburger au lieu du rail gauche de tabulation. [Doit corriger]

  Concevez votre application avec des composants Fluent UI de base et avancés.

  

  

• Si votre onglet a une barre d’outils sur le rail gauche sans aucun composant de navigation, la barre d’outils doit laisser un espacement de 20 pixels à partir de la navigation gauche de Teams. [Doit corriger]

  

• Les pages secondaires et tertiaires d’un onglet doivent être ouvertes dans une vue de niveau 2 (L2) et de niveau 3 (L3) dans la zone d’onglet main, qui est parcourue via des barres de navigation ou une navigation à gauche. Vous pouvez également utiliser les composants suivants pour faciliter la navigation dans un onglet :

  • Boutons Retour

  • En-têtes de page

  • Menus d’hamburger

    

• Les liens profonds dans les onglets ne doivent pas être liés à une page web externe, mais dans Teams. Par exemple, des boîtes de dialogue ou d’autres onglets. [Doit corriger]

  

• Les onglets ne doivent pas permettre aux utilisateurs de naviguer en dehors de Teams pour l’expérience principale de l’application. Les onglets peuvent rediriger en dehors des équipes pour les flux de travail non essentiels. Par exemple, pour créer un ticket d'assistance. [Doit corriger]

  

  

• Le défilement horizontal ne doit pas être présent dans un onglet de réunion. [Doit corriger]

• Les boîtes de dialogue en réunion utilisées dans votre application ne doivent pas autoriser le défilement horizontal. Utilisez les dialogues de réunion avec parcimonie et pour les scénarios légers et orientés tâches. Vous pouvez spécifier la largeur de l’I-frame de la boîte de dialogue de réunion dans la plage de taille prise en charge pour prendre en compte différents scénarios. [Doit corriger]

• Les boîtes de dialogue utilisées dans votre application ne doivent pas autoriser le défilement horizontal. Les boîtes de dialogue vous permettent de sélectionner différentes tailles pour rendre le contenu réactif sans avoir besoin d’un défilement horizontal. Si nécessaire, vous pouvez utiliser un stageview (un composant d’interface utilisateur plein écran pour exposer votre contenu web) pour terminer le flux de travail sans défilement horizontal. [Doit corriger]

• Le défilement horizontal présent dans l’onglet d’une conversation personnelle, d’un canal et d’un onglet détails de réunion dans n’importe quelle étendue n’est pas autorisé si l’intégralité du canevas d’onglet peut faire défiler, sauf si votre onglet utilise un canevas infini avec des éléments d’interface utilisateur fixes. [Doit corriger]

  

  

  

  

  

• L’utilisateur doit avoir la possibilité de passer à l’état de travail précédent. [Doit corriger]

  

  

• Le défilement horizontal dans les cartes adaptatives ne doit pas être présent dans Teams. [Doit corriger]

• Le rail inférieur utilisé pour la navigation dans les onglets ne doit pas entrer en conflit avec la navigation dans les applications mobiles natives Teams. [Doit corriger]

  

Utilisabilité

• Le contenu ne doit pas tronquer ou se chevaucher dans l’onglet. [Doit corriger]

  

• Les utilisateurs doivent être en mesure d’annuler leur dernière action dans l’onglet. [Doit corriger]

• Les onglets dans un contexte personnel peuvent agréger le contenu des instances partagées de l’application. Par exemple, une application de gestion de projet avec un onglet configurable qui permet aux membres du canal de commenter le projet sur des cartes Kanban, doit agréger ce contenu et s'afficher dans l'application personnelle. [Bon à corriger]

• Les onglets doivent répondre aux thèmes de Teams. Lorsqu’un utilisateur modifie le thème, le thème de l’application doit refléter la sélection. [Bon à corriger]

  

  

• Les onglets doivent utiliser des composants de style Teams tels que les polices Teams, les rampes de type, les palettes de couleurs, le système de grille, le mouvement, le ton de la voix, dans la mesure du possible. Pour plus d'informations, consultez les instructions de conception des onglets. [Bon à corriger]

  

• Si les fonctionnalités de votre application nécessitent des modifications dans les paramètres, incluez un onglet Paramètres . [Bon à corriger]

• Les onglets doivent suivre la conception de l’interaction Teams, telle que la navigation dans la page, la position et l’utilisation des dialogues, les hiérarchies d’informations. Pour plus d’informations, consultez Kit d’interface utilisateur Microsoft Teams Fluent. [Bon à corriger]

• Les expériences d'onglet doivent être entièrement réactives sur mobile (Android et iOS). [Doit corriger]

  Conseil

  • Incluez un bot personnel avec un onglet personnel.
  • Autorisez les utilisateurs à partager du contenu à partir de leur onglet personnel.

• Tab ne doit pas contenir d’éléments qui bloquent ou gênent complètement les flux de travail dans l’onglet. Par exemple, bot à l’intérieur d’un onglet qui ne peut pas être réduit. [Doit corriger]

  

• Tab ne doit pas avoir de fonctionnalité rompue. Votre offre doit être une solution logicielle utilisable et doit fournir les fonctionnalités, les fonctionnalités et les livrables décrits dans votre description et d’autres documents connexes. [Doit corriger]

• Si vos onglets contiennent un pied de page, veillez à supprimer de ce pied de page tous les liens qui ne sont pas liés aux fonctionnalités de l’application. [Doit corriger]

Sélection de l’étendue

• Le contenu de la page d’accueil des onglets configurables ne doit pas être limité à une utilisation individuelle et ne doit pas inclure de contenu personnel tel que Mes tâches ou Mon tableau de bord. [Doit corriger]

  

• Après l’expérience de configuration, la page d’accueil doit afficher une vue collaborative pour l’ensemble de l’équipe. [Doit corriger]

• Si votre application nécessite la fourniture d'une vue d'étendue personnelle pour que l'utilisateur améliore l'efficacité ou la productivité sur le lieu de travail, utilisez des vues filtrées, des liens profonds vers des applications personnelles ou accédez aux vues L2 ou L3 dans l'onglet configurable et gardez la page de destination contextuellement la même pour tous les utilisateurs. [Doit corriger]

• Le contenu de la page de destination des onglets configurables doit être contextuellement identique pour tous les membres de la chaîne. [Doit corriger]

  

• Les onglets configurables doivent avoir des fonctionnalités ciblées. [Doit corriger]

  

Retour en haut

Bots

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.4.3.

Si votre application inclut un bot, assurez-vous qu’il respecte ces instructions.

Conseil

Pour plus d'informations sur la création d'une expérience d'application de haute qualité, consultez les directives de conception de bot Teams.

Recommandations en matière de conception de bot

• Votre application Teams doit suivre les instructions de conception de bot Teams.

• Vous devez implémenter un dialogue pour éviter une réponse de bot multitour lorsque le flux de travail implique l’exécution de tâches répétitives par l’utilisateur. Par exemple, utilisez une boîte de dialogue pour capturer de façon répétitive le nom, la date de naissance, le lieu et la désignation au lieu d’utiliser des conversations multitours. [Doit corriger]

• Tous les liens, réponses ou workflows rompus dans votre application doivent être corrigés. [Doit corriger]

Commandes de bot

L’analyse de l’entrée utilisateur et la prévision de l’intention de l’utilisateur sont difficiles. Les commandes de bot fournissent aux utilisateurs un ensemble de mots ou de phrases que votre bot doit comprendre.

• Toutes les commandes prises en charge par votre bot doivent fonctionner correctement, y compris les commandes génériques telles que Hi, Hello et Help. [Doit corriger]

  

  

• Les commandes de bot ne doivent pas conduire un utilisateur à une impasse. Les commandes doivent toujours fournir un moyen d’aller de l’avant. [Doit corriger]

  

• Vous devez répertorier au moins une commande de bot valide dans la items.commands.title section du manifeste de l’application et ajouter une description appropriée qui donne de la clarté à l’utilisateur sur la commande du bot et son utilisation. Les commandes de bot répertoriées dans la commandLists section du manifeste de l’application sont des commandes préremplies dans le menu de commandes du bot et permettent au nouvel utilisateur d’interagir avec le bot. [Bon à corriger]

• La réponse du bot ne doit pas contenir d’images de produit Microsoft ou d’avatars officiels. Utilisez vos propres ressources dans votre application. L’utilisation d’images de produit Microsoft dans votre application n’est pas autorisée. Vous pouvez uniquement copier, modifier, distribuer, afficher, attribuer une licence ou vendre des images de produits Microsoft protégées par des droits d’auteur si vous disposez d’une autorisation explicite dans le cadre du Contrat de licence End-User (CLUF), des termes du contrat de licence qui accompagnent le contenu, ou dans les directives relatives à la marque et à la marque Microsoft. [Doit corriger]

• Les bots doivent répondre aux commandes utilisateur sans afficher d’indicateur de chargement continu. [Doit corriger]

• La réponse de la commande d’aide du bot ne doit pas rediriger l’utilisateur en dehors de Teams. La réponse de la commande d’aide du bot peut rediriger l’utilisateur vers un canevas dans l’application Teams ou fournir une réponse de progression dans une carte adaptative. [Doit corriger]

  

• Les bots doivent toujours fournir une réponse valide à une entrée utilisateur, même si l’entrée n’est pas pertinente ou incorrecte. [Doit corriger]

  

  

• Les caractères spéciaux tels que la barre oblique (/) ne doivent pas être préfixés aux commandes de bot. [Doit corriger]

  

• Les bots doivent fournir une réponse valide aux commandes utilisateur non valides. Les bots ne doivent pas arrêter l’utilisateur ou afficher une erreur si un utilisateur envoie une commande de bot non valide. [Doit corriger]

  

  

• Les fonctionnalités du bot doivent être pertinentes pour l’étendue dans laquelle le bot est installé et le bot doit fournir une valeur dans l’étendue installée. [Doit corriger]

• Les bots ne doivent pas contenir de commandes en double. [Doit corriger]

• Les bots ne doivent pas afficher d’indicateur de saisie après avoir répondu à la commande utilisateur, mais peuvent afficher un indicateur de saisie tout en répondant à la commande utilisateur. [Doit corriger]

• Les bots doivent fournir une réponse valide à la commande d’aide tapée en minuscules ou en majuscules, ce qui permet à l’utilisateur d’accéder au contenu d’aide lié à l’utilisation du bot. Les bots doivent fournir une réponse valide même lorsque l’utilisateur ne s’est pas connecté à l’application. [Doit corriger]

  

  

• Les bots doivent fournir une réponse valide à la commande d’aide .

  

• Les réponses des bots sur mobile doivent être réactives sans troncation des données qui entrave l’utilisation du bot de l’utilisateur final pour effectuer les workflows souhaités. [Doit corriger]

  

  

• Tous les liens d’un carte adaptatif de réponse de bot doivent être réactifs. Tout lien qui amène l’utilisateur en dehors de la plateforme Teams doit avoir un texte de redirection clair, tel que Afficher dans. ou Cette façon vers.., une icône contextuelle dans le bouton d’action de réponse du bot, ou avoir un texte de redirection approprié dans le corps du message de réponse du bot. [Doit corriger]

  

• Par nature, si votre bot ne répond pas ou ne prend pas en charge une commande utilisateur et s’il s’agit d’un bot unidirectionnel uniquement destiné à informer les utilisateurs. Vous devez définir isNotificationOnly sur true dans le manifeste de l’application. [Doit corriger]

  

  

• L’expérience utilisateur du bot ne doit pas être interrompue sur les plateformes mobiles. Votre bot doit être entièrement réactif sur mobile. [Doit corriger]

Conseil

Pour les bots personnels, incluez un onglet Aide qui décrit davantage ce que votre bot peut faire.

Expérience utilisateur de la première exécution du bot

• Un bot dans l’étendue personnelle doit toujours envoyer un message de bienvenue ou fournir des démarrages d’invite. [Doit corriger]

  Si vous utilisez des starters d’invite, vérifiez que les instructions suivantes sont respectées :

  Les démarrages d’invite aident les utilisateurs à démarrer une conversation avec votre bot. Pour activer les démarrages d’invite, la propriété dans le commands manifeste de l’application doit être définie.

  • Le bot doit fournir au moins une commande qui permet à l’utilisateur de connaître la proposition de valeur de l’application. [Doit corriger]
  • Les invites ou les commandes doivent être fonctionnelles et retourner des réponses. [Doit corriger]
  • La description de la commande doit être cohérente et communiquer clairement la valeur de la commande. [Doit corriger]
  • Les entrées d’invite ou les commandes doivent être pertinentes pour les fonctionnalités de l’application. [Doit corriger]
  • Le bot doit avoir au moins trois démarrages ou commandes d’invite uniques. [Bon à corriger]

  Si votre application envoie un message de bienvenue, vérifiez que les instructions suivantes sont respectées :

  • Si l’application a un flux de configuration complexe (nécessite une licence d’entreprise ou n’a pas de flux d’inscription intuitif), les bots de ces applications doivent toujours inclure des informations relatives à la configuration lors de l’envoi d’un message de bienvenue lors de la première exécution.

    Pour une expérience optimale, le message de bienvenue doit inclure la valeur offerte par le bot aux utilisateurs, qui ont installé le bot dans le canal, comment configurer le bot et décrire brièvement toutes les commandes de bot prises en charge. Vous pouvez afficher le message de bienvenue à l'aide d'une carte adaptative avec des boutons pour une meilleure convivialité. Pour plus d’informations, voir comment déclencher un message de bienvenue du bot. Pour les applications sans flux de configuration complexe, vous pouvez choisir de déclencher un message de bienvenue lors de la première exécution du bot. Cependant, si un message de bienvenue est déclenché, il doit suivre les instructions relatives aux messages de bienvenue.

    

    

• Les messages d’accueil du bot dans les canaux et les conversations sont facultatifs lors de la première exécution, en particulier si le bot est disponible pour un usage personnel et effectue des actions similaires. Votre bot ne doit pas envoyer de messages de bienvenue aux utilisateurs individuellement (il s’agit d’un courrier indésirable). Le message doit également mentionner la personne qui a ajouté le bot.

  

  

• Le message de bienvenue ne doit pas arrêter l’utilisateur. Le message de bienvenue doit inclure la valeur offerte par le bot aux utilisateurs qui ont installé le bot dans le canal, comment configurer le bot et décrire brièvement toutes les commandes de bot prises en charge. Vous pouvez afficher le message de bienvenue à l'aide d'une carte adaptative avec des boutons pour une meilleure convivialité. [Doit corriger]

  

  

• Le bot installé dans une étendue de conversation de canal ou de groupe ne doit pas envoyer de message de bienvenue proactif à tous les membres de l’équipe dans la conversation 1:1. [Doit corriger]

  

• Le bot notification uniquement peut envoyer un message de bienvenue proactif dans un canal uniquement si le message contient des informations importantes pour permettre à un utilisateur de terminer la configuration du bot ou clarifie les scénarios de déclenchement des notifications. [Doit corriger]

• Le bot installé dans une étendue de conversation de canal ou de groupe ne doit pas envoyer de messages proactifs (pas seulement un message de bienvenue) qui ne sont pas pertinents pour tous les utilisateurs dans la conversation de canal ou de groupe, mais doit plutôt envoyer des messages proactifs à l’utilisateur sur une conversation 1:1. [Doit corriger]

• Le bot installé dans une étendue de conversation de canal ou de groupe ne doit pas permettre aux utilisateurs de démarrer des flux de travail individuels. Les bots doivent effectuer des workflows individuels dans une conversation 1:1 avec l’utilisateur. [Doit corriger]

• Le message de bienvenue du bot doit clairement indiquer les limitations liées à l’utilisation du bot dans l’étendue installée. [Doit corriger]

  

  

• Le message de bienvenue doit se déclencher automatiquement lors de l’installation de l’application dans une étendue personnelle. Si le bot n’envoie pas de message de bienvenue dans une étendue personnelle, l’utilisateur est conduit à un dead-end. Si l’application n’inclut pas de workflow de configuration complexe, il est facultatif pour le développeur de déclencher un message de bienvenue dans l’étendue de conversation du canal ou du groupe. [Doit corriger]

  

• Les messages de bienvenue ne doivent se déclencher qu’une seule fois lors de l’installation du bot. Les messages de bienvenue ne doivent pas se déclencher chaque fois que l’utilisateur appelle la commande d’aide. La réponse de la commande d’aide doit être axée pour inclure un moyen pour l’utilisateur d’accéder à l’aide liée au bot. [Doit corriger]

• Les messages de bienvenue ne doivent pas se déclencher avec chaque commande de bot. Il s’agit d’un courrier indésirable. [Doit corriger]

  

• Le contenu du message de bienvenue doit être lié au flux de travail du bot mentionné dans la description longue de l’application et dans l’étendue de l’installation. Le message de bienvenue doit inclure la valeur offerte par le bot aux utilisateurs qui ont installé le bot dans le canal, comment configurer le bot et décrire brièvement toutes les commandes de bot prises en charge. [Doit corriger]

• Le bot ne doit pas envoyer plusieurs messages de bienvenue lorsqu’il est déclenché lors de l’installation de l’application. [Doit corriger]

  

• Le nom de l’application dans le message de bienvenue doit correspondre au nom de l’application dans le manifeste de l’application. [Doit corriger]

  

• Le message de bienvenue ne doit pas afficher les noms des plateformes collaboratives basées sur les conversations concurrentes, sauf si l’application fournit une interopérabilité spécifique.

• Le message de bienvenue ne doit pas rediriger l’utilisateur vers une autre application Teams. Au lieu de cela, le message de bienvenue doit inciter l’utilisateur à effectuer sa première tâche et décrire brièvement toutes les commandes de bot prises en charge dans l’application. [Doit corriger]

• Le message de bienvenue ne doit pas contenir de liens vers une place de marché d’applications, y compris AppSource. [Doit corriger]

• Si votre application a un flux de travail de configuration complexe qui nécessite une installation dirigée par l’administrateur, n’a pas de flux d’inscription intuitif et facilement disponible, ou nécessite que les utilisateurs effectuent des étapes de configuration en dehors de l’expérience Teams et retournent, le bot doit envoyer un message de bienvenue proactif dans une étendue de conversation d’équipe ou de groupe après l’installation. [Doit corriger]

• Si votre bot envoie un message de bienvenue dans le canal, il ne doit pas l’envoyer individuellement aux utilisateurs (il est considéré comme un courrier indésirable). Le message de bienvenue doit également mention la personne qui a ajouté le bot. [Bon à corriger]

Conseil

Dans les messages de bienvenue aux utilisateurs individuels, une visite guidée du carrousel peut fournir un aperçu efficace de votre bot et de toutes les autres fonctionnalités de l'application pour encourager les utilisateurs à essayer les commandes du bot. Par exemple, Créer une tâche.

Spamming de messages de bot

Les bots ne doivent pas envoyer de courrier indésirable aux utilisateurs en envoyant plusieurs messages à court terme.

• Messages de bot dans les canaux et les conversations : ne pas envoyer de courrier indésirable aux utilisateurs en créant des publications distinctes. Créez un billet unique avec des réponses dans le même fil de discussion. [Doit corriger]

  

  

• Messages de bot dans les applications personnelles :

  • N’envoyez pas plusieurs messages en succession rapide. [Doit corriger]

    

  • Envoyez un message avec des informations complètes. [Doit corriger]

  • Évitez les conversations à plusieurs tours pour terminer un seul flux de travail répétitif. [Doit corriger]

  • Utilisez un formulaire (ou une boîte de dialogue) pour collecter toutes les entrées d’un utilisateur à la fois. [Doit corriger]

  • Les chatbots conversationnels basés sur la PNL peuvent utiliser une conversation à plusieurs tours pour rendre la discussion plus engageante et compléter un flux de travail.

    

    

• Messages de bienvenue : Ne répétez pas le même message de bienvenue à intervalles réguliers. Par exemple, lorsqu’un nouveau membre est ajouté à une équipe, n’envoyez pas de courrier indésirable aux autres membres avec un message de bienvenue. Envoyez un message personnel au nouveau membre. [Doit corriger]

  

Notifications de bot

Les notifications de bot doivent inclure du contenu pertinent pour l’étendue que vous définissez pour le bot (équipe, conversation ou personnel). [Doit corriger]

Bots et cartes adaptatives

Les cartes adaptatives sont une façon vivement recommandée d’afficher des messages de bot. Les cartes doivent être légères et ne comporter que six actions maximum. Pour afficher davantage de contenu, envisagez d’utiliser une boîte de dialogue ou un onglet.

Pour plus d'informations sur les cartes, consultez :

• Conception de cartes adaptatives
• Référence de cartes

L'expérience du bot doit être entièrement réactive sur mobile. Les réponses des bots doivent fournir une voie à suivre, le cas échéant. Le bot doit être réactif et échouer avec un message d'erreur gracieux pour les échecs. Les messages de bot envoyés dans la portée personnelle à la base de l'utilisateur sur des déclencheurs dans une portée collaborative doivent fournir des informations contextuelles (y compris l'origine du message).

Bots de notification uniquement

Les applications constituées de robots de notification uniquement fournissent une valeur utilisateur en déclenchant des notifications utilisateur en fonction de certains déclencheurs ou événements dans l'application principale ou le backend. Par exemple, un nouveau prospect ou un nouveau prospect est ajouté pour le suivi de l'équipe commerciale. Un bot de notification de haute qualité avertit les utilisateurs régulièrement sur certaines saisies semi-automatiques d’événements, telles que les saisies semi-automatiques de workflow ou les alertes.

Conseil

Afficher un aperçu des informations et fournir des actions utilisateur de base en ligne dans le carte publié afin que l’utilisateur n’ait pas à naviguer en dehors de Teams pour toutes les actions (quelle que soit la complexité).

Informations sur les métadonnées du bot

• Les informations du bot dans le manifeste de l’application (nom du bot, logo, lien de confidentialité et lien des conditions d’utilisation du service) doivent être cohérentes avec les métadonnées Bot Framework. [Doit corriger]

• Vérifiez que l’ID de bot dans le manifeste de l’application correspond à l’ID de bot dans la dernière version publiée de votre application dans le Magasin Teams. La modification des ID de bot dans une mise à jour d’application entraîne une perte permanente de tout l’historique des interactions utilisateur avec le bot pour les utilisateurs existants de votre application et démarre une nouvelle chaîne de conversation avec le nouvel ID de bot. [Doit corriger]

• Toute modification apportée au nom de l’application, aux métadonnées, au message d’accueil du bot ou aux réponses du bot doit être mise à jour avec un nouveau nom. [Doit corriger]

• Le nom de l’application dans le message de bienvenue ou les réponses du bot doivent correspondre au nom de l’application dans le manifeste de l’application. [Doit corriger]

Bot dans l’étendue collaborative

• L’installation du bot dans une étendue de conversation de canal ou de groupe pour obtenir la liste d’équipe pour l’envoi de notifications proactives pour les utilisateurs, car des conversations 1:1 pour des déclencheurs spécifiques à l’équipe n’est pas autorisée. Par exemple, l’application qui associe des personnes pour une réunion. [Doit corriger]

• Bot dans un canal ou une conversation de groupe utilisé uniquement pour obtenir les messages ou les publications pour envoyer des notifications proactives pour les utilisateurs, car les conversations 1:1 ne sont pas autorisées. [Doit corriger]

• Les bots installés dans l’étendue collaborative doivent fournir une valeur utilisateur dans l’étendue collaborative. [Doit corriger]

Retour en haut

Extensions de messages

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.4.4.

Si votre application inclut une extension de message, assurez-vous qu’elle respecte ces instructions.

Conseil

Pour plus d'informations sur la création d'une expérience d'application de haute qualité, consultez les instructions de conception d'extension de messagerie Teams.

Instructions de conception des extensions de messagerie

• Si votre application Teams utilise la fonctionnalité d’extension de messagerie, votre application doit suivre les instructions de conception de l’extension de messagerie.

  

• Les extensions de messagerie sont des raccourcis permettant d’insérer du contenu d’application ou agir sur un message sans quitter la conversation. Conservez votre extension de messagerie simple et affichez uniquement les composants nécessaires pour effectuer efficacement l’action. Le site web complet ne doit pas être encadré dans l’extension de messagerie. [Doit corriger]

• Les images d’aperçu dans les cartes adaptatives dans les extensions de messagerie doivent se charger correctement. [Doit corriger]

  

  

• Les carte de réponse d’extension de messagerie doivent inclure l’icône d’application pour éviter toute confusion de l’utilisateur final. [Doit corriger]

• Votre application ne doit pas avoir de fonctionnalités rompues. L’application ne doit pas empêcher l’utilisateur d’effectuer un flux de travail dans une extension de messagerie. [Doit corriger]

• Les extensions de messagerie doivent répondre ou fonctionner comme prévu dans les étendues de conversation de groupe et de canal. [Doit corriger]

• Vous devez inclure un moyen pour l’utilisateur de se connecter ou de se déconnecter de l’extension de messagerie. [Doit corriger]

• Les extensions de message qui utilisent des URL OpenAPI ne doivent pas fournir de redirection sur un appel d’API. Les appels d’API réels doivent être traités à partir du même domaine ou sous-domaine du domaine racine.

Commandes d’action pour les extensions de message basées sur une action

Les extensions de messagerie basées sur les actions doivent effectuer les opérations suivantes :

• Autorisez les utilisateurs à déclencher des actions sur un message sans effectuer d'étapes intermédiaires, telles que la connexion.

  

  

• Passez le contexte du message à l’état de travail suivant. [Doit corriger]

  

  

• Incorporez le nom de l'application hôte au lieu d'un verbe générique pour les commandes d'action déclenchées à partir d'un message de discussion, d'une publication de canal ou d'un appel à l'action dans les applications. Par exemple, utilisez Démarrer un Réunion Skype pour Démarrer une réunion, Charger un fichier dans DocuSign for Upload file. [Bon à corriger]

  

  

• L’appel d’une action de message doit permettre à l’utilisateur de terminer le flux de travail. Les erreurs, les réponses vides ou les indicateurs de chargement continu pour rendre l’action de message fonctionnelle ne doivent pas être présentes. [Doit corriger]

  

• Les commandes d’action en double ne doivent pas être présentes. [Doit corriger]

• Les actions de message doivent permettre à l’utilisateur d’effectuer le flux de travail comme prévu sans réponse non valide. [Doit corriger]

• Les applications avec uniquement l’extension de messagerie basée sur l’action doivent avoir l’état de fin suivant :

  • Publiez une action pertinente en tant que notification soit dans le contexte où l’extension de message est appelée, soit dans une conversation de bot 1:1 basée sur un scénario utilisateur. [Doit corriger]

  • Autoriser les utilisateurs à partager des cartes avec d’autres utilisateurs en fonction de l’action effectuée. Cela permet de s’assurer que les applications n’effectuent pas d’actions silencieuses. Par exemple, un ticket est créé sur la base d’un message dans un canal, mais l’application n’envoie pas de notification ou ne fournit pas de moyen de demander à l’utilisateur de partager les détails du ticket après la création du ticket. [Doit corriger]

Liens d’aperçu (déploiement de liens)

[Doit corriger]

• Si l’application a déclaré la supportsAnonymizedPayloads propriété dans le manifeste de l’application et que l’utilisateur n’a pas installé l’application, le lien de l’application doit se déployer et afficher la boîte de dialogue Ajouter une application une fois la carte sélectionnée. [Doit corriger]

• Les extensions de messagerie doivent prévisualiser les liens reconnus dans la zone de rédaction Teams. N'ajoutez pas de domaines hors de votre contrôle (qu'il s'agisse d'URL absolues ou de caractères génériques). Par exemple, yourapp.onmicrosoft.com est valide, mais *.onmicrosoft.com non valide. Les domaines de premier niveau sont également interdits. Par exemple : *.com ou *.org. [Doit corriger]

• Les applications doivent uniquement déclarer qui sont sous la propriété directe de l’éditeur de l’application dans la messageHandler section de déploiement de lien du manifeste de l’application. Il ne doit pas contenir *.botframework.com. [Correction obligatoire]

Commandes de recherche

• Les extensions de messagerie basées sur la recherche doivent fournir du texte qui aide les utilisateurs à rechercher efficacement. [Doit corriger]

  

  

• @mention les exécutables doivent être clairs, faciles à comprendre et lisibles.

  

Retour en haut

Boîtes de dialogue

[Doit corriger]

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.4.5.

Développer pour en savoir plus

Une boîte de dialogue (appelée module de tâche dans TeamsJS v1.x) doit inclure une icône et le nom court de l’application à laquelle elle est associée. Les boîtes de dialogue ne doivent pas incorporer une application entière et afficher uniquement les composants requis pour effectuer une action spécifique.

Pour plus d’informations, consultez Instructions de conception de boîte de dialogue Teams.

Conseil

Pour plus d'informations sur la création d'une expérience d'application de haute qualité, consultez les Directives de conception du module de tâche des équipes.

Retour en haut

Extensions de réunion

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.4.6.

Conseil

Pour plus d'informations sur la création d'une expérience d'application de haute qualité, consultez les directives de conception d'extension de réunion Teams.

Recommandations en matière de conception d’extension de réunion

• Vos applications Teams doivent suivre les instructions de conception de l’extension de réunion.

• Avec l’expérience de l’application en réunion, vous pouvez impliquer les participants pendant la réunion à l’aide des onglets de réunion, de la boîte de dialogue et de la fonctionnalité de partage en réunion à la phase. Si votre application prend en charge l’extension de réunion Teams, vous devez fournir une expérience de réunion réactive alignée sur l’expérience de réunion Teams. [Doit corriger]

• Les applications d’extensibilité de réunion doivent offrir une expérience de réunion réactive alignée sur l’expérience de réunion Teams. L’expérience en réunion est obligatoire pour une application Teams qui prend en charge l’extensibilité des réunions, mais les expériences avant et après la réunion ne sont pas obligatoires. [Doit corriger]

  • Avec l'expérience d'application de pré-réunion, les utilisateurs peuvent rechercher et ajouter des applications de réunion. Les utilisateurs peuvent également effectuer des tâches préalables à la réunion, telles que le développement d’un sondage pour interroger les participants à la réunion. Si votre application offre une expérience de pré-réunion, elle doit être pertinente pour le flux de travail de la réunion.

  • Avec l’expérience de l’application post-réunion, les utilisateurs peuvent afficher les résultats de la réunion, tels que les résultats d’une enquête de sondage ou des commentaires et d’autres contenus d’application. Si votre application offre une expérience post-réunion, elle doit être pertinente pour le flux de travail de la réunion.

  • Avec l'expérience de l'application en réunion, vous pouvez impliquer les participants à la réunion pendant la réunion et améliorer l'expérience de la réunion pour tous les participants. Les participants ne doivent pas être emmenés en dehors de la réunion Teams pour effectuer les flux de travail des utilisateurs principaux de votre application.

  

• Votre application doit offrir de la valeur au-delà de fournir uniquement des scènes personnalisées en mode Ensemble dans Teams. [Doit corriger]

• Vous devez déclarer groupChat en tant qu’étendue sous configurableTabs et meetingDetailsTab, meetingChatTabet meetingSidePanel en tant que propriété de contexte dans le manifeste de l’application pour activer votre application pour les réunions sur teams mobiles. [Doit corriger]

• Les canevas de réunion ne doivent pas être en impasse pour un participant à la réunion. Les canevas de réunion doivent afficher un message d’échec approprié pour les limitations de l’application, telles que la dépendance spécifique à une région. [Doit corriger]

• L’en-tête du canevas de réunion doit afficher le nom correct de l’application pour éviter d’embrouiller le participant à la réunion. [Doit corriger]

• Vous devez inclure une option permettant à l’utilisateur de se déconnecter ou de se déconnecter de l’extension de réunion. [Doit corriger]

• Les onglets de réunion sur les plateformes mobiles doivent inclure des flux de travail pertinents. Les pages vides ne doivent pas être présentes dans un onglet de réunion. [Doit corriger]

• La phase de réunion est un canevas de participation ciblé, intuitif et collaboratif. La phase de réunion ne doit pas incorporer l’expérience complète du site web. [Doit corriger]

• L’application ne doit pas afficher d’écran de chargement continu, d’erreur ou de fonctionnalité rompue qui arrête l’utilisateur ou bloque l’achèvement d’un flux de travail dans un scénario de réunion. [Doit corriger]

  

• L’application ne doit pas ouvrir une nouvelle instance Teams au démarrage d’une réunion. Les canevas de réunion sont une extension des fonctionnalités Teams qui favorisent la collaboration en temps réel et les nouvelles réunions doivent toujours s’ouvrir dans le instance Teams actif. [Doit corriger]

• Les applications de réunion doivent effectuer des flux de travail au sein de la plateforme Microsoft Teams sans rediriger vers les plateformes basées sur les conversations concurrentes. [Doit corriger]

  

• Si votre application prend en charge les vues basées sur les rôles et que certains flux de travail ne sont pas disponibles pour tous les participants, nous vous recommandons d’implémenter une messagerie appropriée pour les participants dans l’onglet et le panneau latéral indiquant que l’application est destinée à l’affichage de l’organisateur et fournir des détails sur la façon dont les participants reçoivent les notes de réunion, les éléments d’action et les ordres du jour de mise à jour. [Doit corriger]

  

Expérience avant et après la réunion

• Les écrans avant et après la réunion doivent respecter les directives générales de conception des onglets. Pour plus d'informations, consultez Directives de conception Teams. [Doit corriger]

• Les onglets doivent avoir une disposition organisée lors de l'affichage de plusieurs éléments. Par exemple, plus de 10 sondages ou enquêtes, voir exemple de mise en page. [Doit corriger]

• Votre application doit informer les utilisateurs lorsque les résultats d'une enquête ou d'un sondage sont exportés en indiquant, Résultats téléchargés avec succès. [Doit corriger]

  

Expérience en réunion

• Les applications doivent uniquement utiliser un thème foncé pendant les réunions. Pour plus d'informations, consultez Directives de conception Teams. [Doit corriger]

• Une info-bulle doit afficher le nom de l'application lorsque vous survolez l'icône de l'application pendant les réunions. [Doit corriger]

  

• Les extensions de messagerie doivent fonctionner de la même manière pendant les réunion qu’en dehors des réunions. [Doit corriger]

Onglets en réunion

• Doivent être réactifs. [Doit corriger]

• Doit maintenir le rembourrage et la taille des composants. [Doit corriger]

• Doit avoir un bouton de retour s'il y a plus d'une couche de navigation. [Doit corriger]

  

  

• Ne doit pas inclure plus d'un bouton de fermeture. Cela peut perturber les utilisateurs, car il existe déjà un bouton d’en-tête intégré pour ignorer l’onglet. [Doit corriger]

• Ne doit pas avoir de défilement horizontal. [Doit corriger]

  

  

Boîtes de dialogue en réunion

• Doit être utilisé avec parcimonie et pour des scénarios légers et axés sur les tâches. [Doit corriger]

• Doivent afficher le contenu dans une seule colonne et ne pas avoir plusieurs niveaux de navigation. [Doit corriger]

  

  

• Ne doit pas utiliser de boîtes de dialogue. [Doit corriger]

• Doivent s’aligner sur le centre de la phase de réunion. [Doit corriger]

  

• Doit être rejeté après qu'un utilisateur a sélectionné un bouton ou effectué une action. [Doit corriger]

• Mode Ensemble : veillez à prendre en compte les meilleures pratiques suivantes pour une expérience de création de scène : [Doit corriger]

  • Toutes les images sont au format .png.
  • Le package final avec toutes les images rassemblées ne doit pas dépasser une résolution de 1920 x 1080. La résolution est un nombre pair. Cette résolution est une exigence pour que les scènes soient affichées avec succès.
  • La taille maximale de la scène est de 10 Mo.
  • La taille maximale de chaque image est de 5 Mo. Une scène est une collection de plusieurs images. La limite est pour chaque image individuelle.
  • Sélectionnez Transparent selon vos besoins. Cette case à cocher est disponible sur le panneau de droite lorsqu'une image est sélectionnée. Les images qui se chevauchent doivent être marquées comme transparentes pour indiquer qu'elles se chevauchent dans la scène.

Étape de réunion partagée

Pour utiliser l’API shareAppContentToStage , vous devez déclarer les autorisations RSC correctes. Dans le manifeste de l’application, vous devez configurer la authorization propriété . Mettez à jour la name propriété en tant que MeetingStage.Write.Chat et type la propriété en tant que Delegated dans le resourceSpecific champ . [Doit corriger]

La fonctionnalité d'étape de réunion partagée ne peut être lancée que via l'application de bureau Teams. Cependant, l'expérience de consommation de l'étape de réunion partagée doit être utilisable et non interrompue lorsqu'elle est visualisée sur des appareils mobiles. [Doit corriger]

Retour en haut

Connector

1. Le nom du connecteur doit être identique au nom de l’application dans l’application et dans le manifeste de l’application.

   

2. L’utilisateur ne doit rencontrer aucune erreur lors de la configuration du connecteur.

   

Notifications

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.4.7.

Si votre application utilise les API de flux d’activité fournies par Microsoft Graph, vérifiez qu’elle respecte les instructions suivantes.

Conseil

Si vos applications prennent en charge les scénarios de notification où les notifications sont déclenchées après de longs intervalles, par exemple, après un jour ou un mois. Avant de soumettre pour révision, veillez à déclencher ces notifications en arrière-plan pour que nous puissions tester les notifications.

Instructions de conception de notification

• Vos applications Teams doivent suivre les instructions de conception des notifications de flux d’activité.

• Le flux de travail non pertinent, incorrect, ne répond pas ou rompu ne doit pas être présent une fois que l’utilisateur a sélectionné une notification dans le flux d’activité Teams. Les utilisateurs ne doivent pas être empêchés d’exécuter un flux de travail après avoir sélectionné une notification de flux d’activité. [Doit corriger]

• Incluez le nom de votre application dans la notification du flux d’activité pour permettre aux utilisateurs finaux de comprendre la source ou le déclencheur de la notification sans confusion. [Doit corriger]

• L’application doit déclencher des notifications pour tous les scénarios de notification mentionnés dans la description longue de l’application, l’expérience de première exécution de l’application et dans les scénarios déclarés sous activityTypes dans le manifeste de l’application. [Doit corriger]

• Les notifications doivent s’afficher dans les cinq secondes après l’action d’un utilisateur. [Doit corriger]

• Vous devez indiquer les limitations de notification (le cas échéant) dans la description longue de votre application ou dans l’expérience de première exécution de l’application. [Doit corriger]

Généralités

• Tous les déclencheurs de notification spécifiés dans la configuration de votre application doivent fonctionner. [Doit corriger]
• Les notifications doivent être localisées selon les langues de prise en charge configurées pour votre application. [Doit corriger]
• Les notifications doivent s’afficher dans les cinq secondes après l’action d’un utilisateur. [Doit corriger]
• Les notifications doivent être localisées selon les langues prises en charge pour toutes les plateformes où votre application est compatible. [Doit corriger]

Avatars

• L'avatar de notification doit correspondre à l'icône de couleur de votre application. [Doit corriger]
• Les notifications déclenchées par un utilisateur doivent inclure l'avatar de l'utilisateur. [Doit corriger]

Spamming

• Les applications ne doivent pas envoyer plus de 10 notifications par minute à un utilisateur. [Doit corriger]
• Les bots et le flux d’activité ne doivent pas déclencher de notifications en double. [Doit corriger]
• Les notifications doivent fournir une valeur ajoutée aux utilisateurs et ne pas être utilisées pour des événements triviaux ou non pertinents. [Doit corriger]

Navigation et disposition

• Les notifications doivent respecter la disposition et l’expérience de flux d’activités Teams. [Doit corriger]
• Lors de la sélection d'une notification, l'utilisateur doit être dirigé vers le contenu pertinent dans Teams. [Doit corriger]

Retour en haut

Programme de conformité d’Application Microsoft 365

Cette section est conforme à la politique de la Place de marché commerciale Microsoft numéro 1140.6.

Développer pour en savoir plus

Le Programme de conformité d’Application Microsoft 365 est destiné à aider les organisations à évaluer et à gérer les risques en évaluant les informations de sécurité et de conformité concernant votre application. Si vous publiez une application dans le Magasin Teams, vous devez effectuer les niveaux suivants du programme :

• Vérification de l’éditeur : permet aux administrateurs et aux utilisateurs finaux de comprendre l’authenticité des développeurs d’applications procédant à une intégration avec la Plateforme d'identités Microsoft. Lorsque vous avez terminé, un badge vérifié bleu s’affiche sur la boîte de dialogue de consentement Microsoft Entra et sur d’autres écrans. Pour plus d'informations, voir Marquer votre application comme vérifiée par l'éditeur. [Doit corriger]

  

• Attestation d’éditeur : processus dans lequel vous partagez des informations générales, de gestion des données et de sécurité et de conformité pour permettre aux clients potentiels de prendre des décisions informées sur l’utilisation de votre application. [Bon à corriger]

Pour une application qui n’est pas répertoriée précédemment, vous ne pouvez pas effectuer l’attestation du serveur de publication tant que l’application n’est pas disponible dans le Magasin Teams. Si vous mettez à jour une application déjà répertoriée, effectuez l’attestation publisher avant d’envoyer la dernière version de l’application.

Retour en haut

Publicité

Cette section est conforme à la stratégie du marché commercial de Microsoft, numéro 1140.7.

Les applications ne doivent pas afficher de publicité, y compris les publicités dynamiques, les bannières publicitaires et les annonces dans les messages. [Doit corriger]

Retour en haut

Applications basées sur des crypto-monnaies

Vous devez démontrer la conformité avec toutes les lois dans lesquelles votre application est distribuée, si votre application : [Doit corriger]

• Facilite les transactions ou les transmissions de crypto-monnaie au sein de l’application.

• Promeut le contenu lié aux crypto-monnaies.

• Permet aux utilisateurs de stocker ou d’accéder à leur crypto-monnaie stockée.

• Encourage ou permet aux utilisateurs d’effectuer une transaction ou une transmission basée sur une crypto-monnaie en dehors de la plateforme Teams.

• Encourage ou facilite l’exploration de jetons de crypto-monnaie.

• Facilite la participation des utilisateurs aux initialisations de pièces de monnaie.

• Récompense ou incite les utilisateurs avec des jetons de crypto-monnaie à effectuer une tâche.

Après une révision interne de Microsoft, si la démonstration de conformité est satisfaisante, Microsoft peut procéder à une certification supplémentaire de votre application. Si la démonstration de conformité n’est pas satisfaisante, Microsoft vous tient informé de la décision de ne pas procéder à la certification de votre application.

Retour en haut

Fonctionnalité de l’application

• Les flux de travail ou le contenu de l’application doivent être liés à l’étendue. [Doit corriger]
• Toutes les fonctionnalités de l’application doivent être fonctionnelles et fonctionner correctement comme décrit dans la description longue d’AppSource ou du manifeste d’application. [Doit corriger]
• Les applications doivent toujours avertir l’utilisateur avant de télécharger un fichier ou un exécutable sur l’environnement de l’utilisateur. Tout appel à l’action (CTA), textuel ou autre, qui indique clairement à l’utilisateur qu’un fichier ou un exécutable est téléchargé sur l’action de l’utilisateur est autorisé dans l’application. [Doit corriger]
• Les applications avec dépendance de région doivent avertir les utilisateurs avec un message d’échec approprié dans toutes les fonctionnalités applicables s’ils tentent de l’utiliser dans une région non prise en charge. [Doit corriger]

Retour en haut

Expérience mobile

• Les compléments mobiles doivent être gratuits. Il ne doit pas y avoir de contenu ou de lien dans l’application qui favorise l’upselling, les magasins en ligne ou d’autres demandes de paiement. Tous les comptes requis pour les applications ne doivent pas avoir de frais d’utilisation et, s’ils sont limités dans le temps, ne doivent pas inclure de contenu indiquant la nécessité de payer. [Doit corriger]

  

• L’utilisation du mot GRATUIT, ESSAI GRATUIT ou ESSAI GRATUIT est autorisée sur l’expérience de bureau ou d’application web sans aucune limitation ni considération.

• L’utilisation du mot FREE en tant que texte brut dans le contexte d’une version d’évaluation ou d’une mise à niveau d’application est autorisée sur mobile.

• L’utilisation du mot FREE dans le contexte d’une version d’évaluation ou d’une mise à niveau d’application avec un lien qui mène à une page d’accueil sans informations de paiement ou de tarification est autorisée sur mobile. Le texte brut pour signaler que l’application est PAYANTE est autorisé sur les appareils mobiles.

• L’utilisation du mot FREE en tant que texte brut dans le contexte d’une version d’évaluation ou d’une mise à niveau d’application et associée aux détails de tarification n’est pas autorisée sur mobile. [Doit corriger]

• L’utilisation du mot GRATUIT dans le contexte d’une version d’évaluation ou d’une mise à niveau d’application et associée à un lien qui mène à une page d’accueil avec des informations de tarification ou des détails de paiement sur mobile n’est pas autorisée. [Doit corriger]

• Les détails de tarification sur les appareils mobiles dans n’importe quel format, par exemple, image, texte ou lien ne sont pas autorisés. Cta tel que l’affichage des plans sur mobile n’est pas autorisé. Les informations sur les plans sans détails de tarification, mais avec un lien de contact ou un e-mail sur mobile ne sont pas autorisées. Tout texte avec des détails de contact liant ou faisant allusion à une mise à niveau payante n’est pas autorisé sur mobile. Paiements pour les biens physiques sont autorisés sur mobile. Par exemple, votre application peut autoriser le paiement pour réserver un taxi. [Doit corriger]

  

• Paiements pour les biens numériques dans l’application ne sont pas autorisés sur mobile. [Doit corriger]

  

• Les applications Teams doivent offrir une expérience mobile inter-appareils appropriée. [Doit corriger]

• Les fonctionnalités qui ne sont pas prises en charge sur les appareils mobiles ne doivent pas être sans fin d’utilisateur et doivent fournir un message d’échec approprié, le cas échéant. [Doit corriger]

Retour en haut

Applications étendues sur les clients Microsoft 365

Généralités

• Les applications destinées à étendre les applications Teams sur les clients Microsoft 365 doivent utiliser la version de schéma 1.13 ou ultérieure.

• L’URL de support de votre application doit contenir du contenu pertinent pour l’application Teams extensible sur les clients Microsoft 365 et ne doit pas appeler un seul client.

• Vous devez fournir une référence pertinente à l’application Teams extensible sur les clients Microsoft 365 dans la description de l’application.

• Si votre application Teams est extensible sur les clients Microsoft 365, le contenu fourni dans les messages de démarrage, de connexion, d’inscription, de déconnexion, de pages d’aide ou de progression de votre application doit appeler tous les clients.

Compatibilité

Les applications Teams extensibles sur les clients Microsoft 365 doivent être entièrement réactives et fonctionnelles sur les dernières versions des clients Microsoft Edge et Google Chrome. L’utilisateur doit être en mesure d’appeler et de continuer à utiliser des onglets personnels ou des extensions de message sur les éléments suivants :

• Outlook pour Windows et web.
• Microsoft 365 sur ordinateur de bureau, web et Android.
• Microsoft Teams sur le bureau et le web.
• Microsoft Teams sur Android et iOS.

Expérience mobile

Les utilisateurs doivent être en mesure de lancer l’application à partir du menu volant Actions dans le client Microsoft 365 sur mobile. Le nom de l’application doit être affiché correctement dans la barre d’action. [Doit corriger]

Menu volant Lancement de l’application à partir d’actions

Les utilisateurs doivent pouvoir lancer et basculer entre plusieurs onglets statiques dans le client Microsoft 365 sur mobile. Les onglets doivent se charger correctement. S’il existe plus de trois onglets statiques, les autres onglets doivent être visibles sous la section Plus . [Doit corriger]

Expérience multi-onglets

Si votre application utilise l’authentification unique, elle doit authentifier l’utilisateur correctement. L’authentification unique permet aux utilisateurs de se connecter à l’aide d’un ensemble d’informations d’identification à plusieurs systèmes logiciels indépendants. Les utilisateurs peuvent accéder à toutes les applications requises sans utiliser d’informations d’identification différentes pour s’authentifier. [Doit corriger]

Authentification d’application

L’application doit mettre fin au compte d’utilisateur instance lorsque l’utilisateur est basculé ou déconnecté dans le client Microsoft 365 sur mobile. [Doit corriger]

Expérience de basculement et de déconnexion de compte

• Les utilisateurs doivent pouvoir revenir à l’état de travail précédent. Si l’utilisateur se trouve sur la page racine, la navigation arrière doit mettre fin à l’application instance dans le client Microsoft 365 sur mobile. [Doit corriger]

• Les applications qui prennent en charge un lien profond vers un workflow doivent être en mesure de rediriger l’utilisateur vers l’expérience de page d’accueil appropriée. [Doit corriger]

Navigation par onglet

• L’indicateur de progression doit apparaître lorsque l’application se charge et s’ignorer automatiquement après le chargement de l’application. [Doit corriger]

• Un écran d’erreur doit s’afficher lorsqu’une application ne parvient pas à se charger dans les instances telles que le réseau incohérent ou défectueux, le délai d’attente ou l’échec de l’authentification, etc. [Doit corriger]

Retour en haut

Applications Teams extensibles en tant que plug-in pour Microsoft 365 Copilot

• Les packages d’application sont correctement mis en forme et adhèrent au schéma de manifeste version 1.13 ou ultérieure.
• L’application doit passer les vérifications de l’IA responsable.
• L’application doit répondre aux critères de compatibilité du plug-in.

Le plug-in ne doit pas manipuler le comportement LLM

Les brèves descriptions d’une application, d’un paramètre et d’une commande ne doivent pas inclure les éléments suivants :

1. Expressions d’instruction. Par exemple, si l’utilisateur dit X, ignorer, supprimer, réinitialiser, nouvelles instructions, répondre en gras ou ne rien imprimer.
2. Langage détaillé, fleuri ou marketing.
3. Des revendications superlatives telles que #1, étonnantes ou meilleures.
4. URL, emojis ou caractères masqués tels que des symboles hexadécimaux, binaires ou non conventionnels.
5. Fautes de grammaire et de ponctuation.

Sensibilisation des utilisateurs

La description longue d’une application doit clairement indiquer ce qui suit :

• Compatibilité de l’application avec Microsoft 365 Copilot. Par exemple, utilisez Contoso dans Microsoft 365 Copilot pour rechercher et résumer vos tâches.

• Fournissez au moins une invite indiquant comment les utilisateurs peuvent utiliser un plug-in d’extension de message dans Microsoft 365 Copilot. Par exemple, quels sont les tickets de haute priorité qui m’ont été attribués cette semaine dans Contoso.

  

  

Qualité de la réponse

• Les champs obligatoires dans Microsoft 365 Copilot réponse de carte adaptative doivent inclure le titre des informations et au moins deux champs utiles supplémentaires de votre choix, par exemple date de modification, auteur, status et indicateurs. L’aperçu et le contenu doivent faire partie d’une seule réponse.

  

• Les cartes adaptatives dans Microsoft 365 Copilot réponse doivent avoir au moins un bouton d’action.

• Les boutons d’action présents dans Microsoft 365 Copilot cartes adaptatives de réponse doivent être fonctionnels.

  

• Microsoft 365 Copilot devez répondre avec précision et ne pas afficher d’erreur lorsqu’un utilisateur vous invite avec un seul paramètre.

• Microsoft 365 Copilot devez répondre avec précision et ne pas afficher d’erreur lorsqu’un utilisateur vous invite à utiliser un paramètre multiple.

• Microsoft 365 Copilot devez répondre avec précision et ne pas afficher d’erreur lorsqu’un utilisateur vous invite à effectuer un suivi.

• L’extension de message doit contenir au moins deux paramètres pour améliorer l’expérience utilisateur dans Microsoft 365 Copilot.

Retour en haut

Étape suivante

Créer un compte d’Espace partenaires

Voir aussi

• Tester et déboguer votre application
• Préparer votre soumission dans le Store Teams
• Inclure une offre SaaS avec votre application Teams
• Stratégie et exécution de la croissance pour votre application
• Valider votre application dans le Portail des développeurs pour Teams