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 directives sont marquées comme Correction obligatoire. 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 ne passera la validation du Magasin Teams qu’une fois que vous avez résolu les problèmes.
  • D'autres directives sont marquées comme Correction obligatoire. Pour une expérience utilisateur idéale, nous vous suggérons de résoudre les problèmes. Toutefois, la publication de votre application ne sera 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. [Correction obligatoire]

Le graphique montre un exemple d’application avec un workflow précieux pour canaliser les membres au sein d’une équipe.

Le graphique montre un exemple d’application avec un site web entier dans un I-frame sans aucune option d’arrière-plan.


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.

Capture d’écran montrant un exemple de bit de notification uniquement avec des informations insuffisantes dans la préversion.


Extensions de message

[Correction obligatoire]

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.

    validation-search-base-messaging-ext-adequete-info

    validation-search-base-messaging-ext-inadequete-info


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 au début

Nom de l'application

[Correction obligatoire]

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. [Correction obligatoire]

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

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]
    • 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é . [Correction obligatoire]
  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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

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. [Correction obligatoire]

    • 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.

    Capture d’écran montrant le scénario passé d’exigence de région effectué avec la logique.

    • 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

[Correction obligatoire]

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. [Correction obligatoire]

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é. [Correction obligatoire]

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. [Correction obligatoire]

Capture d’écran montrant le scénario passé de l’application d’agrégation de contenu pour signaler des problèmes.

Plateformes et services similaires

[Correction obligatoire]

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

[Correction obligatoire]

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. [Correction obligatoire]
    • Lorsque les utilisateurs se déconnectent, ils doivent se déconnecter uniquement de l'application et rester connectés à Teams. [Correction obligatoire]
    • 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). [Correction obligatoire]
    • 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. [Correction obligatoire]
  • 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. [Correction obligatoire]

  • 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. [Correctif suggéré]

Sécurité

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

Retour au début

Informations financières

[Correction obligatoire]

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. [Correction obligatoire]

validation-financial-info

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. [Correction obligatoire]

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é. [Correction obligatoire]

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. [Correctif obligatoire]

    validation-financial-info-in-app-purchase

    validation-online-store

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

Bots

[Correction obligatoire]

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.

validation-bot-confirmation

Domaines externes

[Correction obligatoire]

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}. [Correction obligatoire]

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

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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

  • Les domaines externes suivants ne sont pas autorisés : [Correctif obligatoire]

    • *.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

[Correction obligatoire]

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 au début

Lancement des fonctionnalités externes

[Correction obligatoire]

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é. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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 : [Correctif obligatoire]

    • 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é

[Correction obligatoire]

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

[Correction obligatoire]

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. [Correction obligatoire]
  • Les bots doivent répondre aux commandes de l’utilisateur dans un délai de deux secondes ou afficher un indicateur de saisie. [Correction obligatoire]
  • Les extensions de messagerie doivent répondre aux commandes de l'utilisateur dans les deux secondes. [Correction obligatoire]
  • Les notifications doivent s'afficher dans les deux secondes suivant l'action de l'utilisateur. [Correction obligatoire]

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. [Correction obligatoire]

    • 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. [Correctif suggéré]
      • 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. [Correctif suggéré]
      • Ajoutez la fonctionnalité de balayage des conversations, qui vous permet de surveiller les conversations et d’intervenir en cas de déraillement des conversations. [Correctif suggéré]
  • L’application doit fournir des mécanismes permettant aux utilisateurs de l’application de signaler du contenu inapproprié, nuisible ou offensant au développeur par l’un des mécanismes suivants : [Correctif obligatoire]

    • 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. [Correction obligatoire]

  • 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. [Correctif obligatoire].

    Capture d’écran montrant la description de la fonctionnalité Ia.

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. [Correction obligatoire]
  • 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. [Correction obligatoire]
    • 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

[Correction obligatoire]

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. Désactivez également l’authentification à deux facteurs ou multifacteur.

Retour au début

Manifeste d'application

[Correction obligatoire]

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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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

  • 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. [Correction obligatoire]

  • 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). [Correction obligatoire]

  • 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. [Correction obligatoire]

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

  • 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 ... [Correctif obligatoire]

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

  • Nous vous recommandons de déclarer l’ID MPN (Microsoft Partner Network) dans le manifeste de l’application. L’ID MPN permet d’identifier le organization partenaire qui génère l’application. [Correctif suggéré]

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

Icônes d’application

[Correction obligatoire]

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. [Correction obligatoire]

    Capture d’écran montrant l’icône de couleur et l’icône de plan sont identiques.

    Capture d’écran montrant l’icône de couleur et l’icône de plan ne sont pas identiques.

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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.

Le graphique montre un exemple de description d’application appropriée dans l’application Teams.

Le graphique montre un scénario d’échec d’une description d’application inadéquate.



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. [Correction obligatoire]

    Le graphique montre un exemple d’informations marketing comparatives dans la description de l’application.

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

    Le graphique montre un exemple de détails de contact hypertexte dans les descriptions de l’application.

    Le graphique montre un exemple de détails de contact qui ne sont pas liés dans les descriptions de l’application.

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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

    Le graphique montre un exemple de limitations décrites dans la description de l’application.

    Le graphique montre un exemple de limitations non indiquées dans les descriptions d’application.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de référence correcte à Teams dans la description de l’application.

    Le graphique montre un exemple de référence incorrecte à Teams dans la description de l’application.

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 :

[Correctif suggéré]

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

[Correction obligatoire]

  • Supérieure à 500 mots.

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

    Le graphique montre un exemple d’abréviation de Microsoft en MS ou MSFT pour la première fois dans la description de l’application.

    Le graphique montre un exemple de non-abréviation de Microsoft en MS ou MSFT pour la première fois dans la description de l’application.

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

    Le graphique montre un exemple montrant comment ne pas indiquer l’offre Microsoft dans la description de l’application.

    Graphique montrant un exemple de la façon d’écrire une description d’application sans utiliser de slogans et de slogans 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.

    Le graphique montre un exemple de description longue de l’application sans erreur.

    Le graphique montre un exemple de description longue de l’application avec fautes de frappe et erreurs.

  • Incluez des liens vers AppSource.

    Le graphique montre un exemple de scénario d’échec avec des liens vers AppSource dans la description longue de l’application.

  • 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. [Correction obligatoire]

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

    Capture d’écran montrant le scénario de réussite de la fonctionnalité d’application sur les appareils mobiles.

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

    Capture d’écran montrant le scénario d’échec du contenu supplémentaire utilisé dans la capture d’écran.

    Capture d’écran montrant le scénario d’échec de la capture d’écran de l’interface utilisateur réelle de l’application.

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

    Capture d’écran montrant le scénario d’échec de la fonctionnalité ou de l’intégration de l’application.

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

  • 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. [Correction obligatoire]

    Capture d’écran montrant le scénario passé de la fonctionnalité d’application Teams dans les clients MS 365.

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

    Capture d’écran montrant le scénario passé de l’attention de l’utilisateur pour les fonctionnalités de l’application.

  • 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. [Correction obligatoire]

    Capture d’écran montrant le scénario passé de capture d’écran de la fonctionnalité d’onglet.

À 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.

    Capture d’écran montrant le scénario d’échec de fonctionnalités d’application non liées dans 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. [Correctif suggéré]

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. [Correctif suggéré]

  • 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. [Correction obligatoire]

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

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

  • La vidéo doit être au format https://www.example.com/123456789.

    Capture d’écran montrant le scénario d’échec de la vidéo envoyée dans le cadre de la liste des applications dans l’Espace partenaires.

  • 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. [Correctif suggéré]

  • 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é

[Correction obligatoire]

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

[Correction obligatoire]

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.

[Correction obligatoire]

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.

validation-support-links-auth

Localisation

[Correction obligatoire]

  • 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. [Correction obligatoire]

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

  • 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). [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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érales
  • 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 au début

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. [Correction obligatoire]

    Le graphique montre un exemple d’onglet avec un point mort lors de l’installation.

  • 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. [Correction obligatoire]

    validation-tabs-set-up-profile-name

  • 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. [Correction obligatoire]

    validation-tabs-setup-configuration-exp

    validation-tabs-set-up-configuration-screen

  • 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. [Correction obligatoire]

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

      Capture d’écran montrant un exemple de configuration d’onglet avec un moyen pour l’utilisateur de générer une URL.

      Capture d’écran montrant un exemple de configuration d’onglet sans moyen pour l’utilisateur de générer une URL.

  • 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. [Correction obligatoire]

  • 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. [Correctif suggéré]


Affichage
  • La zone d’écran de connexion ne doit pas utiliser de logos volumineux. [Correction obligatoire]

    validation-views-app-login

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

    val-views-multiple-tabs

  • 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. [Correctif suggéré]

    Le graphique montre un exemple d’onglet sans en-têtes et logos dupliqués.

    Le graphique montre un exemple d’onglet avec des en-têtes et des logos en double.


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. [Correction obligatoire]

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

    Le graphique montre un exemple de navigation dans un onglet qui n’est pas en conflit avec la navigation principale de Teams.

    Le graphique montre un exemple de rail de navigation gauche qui est en conflit avec la navigation principale de Teams.

  • 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. [Correction obligatoire]

    validation-nav-spacing-between-toolbar

  • 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

      Capture d’écran montrant un exemple de boîte de dialogue en réunion avec plusieurs niveaux de navigation.

  • 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. [Correction obligatoire]

    validation-nav-view-button-not-linked-static-tab

  • 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. [Correction obligatoire]

    validation-nav-core-workflow-within-configuration

    validation-nav-core-workflow-redirects-outside

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

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

    Le graphique montre des exemples de tous les scénarios dans les appareils mobiles où le défilement horizontal est autorisé.

    Le graphique montre un exemple de défilement horizontal dans le tableau Kanban.

    Le graphique montre un exemple d’affichage liste avec de nombreux composants.

    Le graphique montre un exemple de défilement horizontal dans un tableau blanc avec une zone de dessin infinie et un tableau fixe.

    Le graphique montre un exemple de défilement horizontal en mode Liste.

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

     Capture d’écran montrant l’option de bouton Précédent disponible.

    Capture d’écran montrant un scénario d’échec où aucune option de bouton Précédent n’est disponible.

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

  • 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. [Correction obligatoire]

    Le graphique montre un exemple d’onglet qui est en conflit avec la navigation d’application mobile native Teams.


Utilisabilité
  • Le contenu ne doit pas tronquer ou se chevaucher dans l’onglet. [Correctif obligatoire]

    validation-usability-content-truncations

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

  • 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. [Correctif suggéré]

  • 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. [Correctif suggéré]

    Le graphique montre un exemple d’onglet réactif à un thème dans Teams.

    Le graphique montre un exemple d’onglet qui ne répond pas au thème dans Teams.

  • 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. [Correctif suggéré]

    Capture d’écran montrant un exemple d’onglet avec une police calibri au lieu de la police Teams native.

  • Si la fonctionnalité de votre application nécessite des modifications des paramètres, incluez un onglet Paramètres. [Correction suggérée]

  • 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. [Correctif suggéré]

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

    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. [Correction obligatoire]

    Le graphique montre un exemple d’onglet avec des éléments qui entravent les flux de travail dans l’onglet.

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]


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. [Correction obligatoire]

    Le graphique montre un exemple de contenu dans un onglet configurable avec une étendue personnelle telle que Mes tâches ou Mon tableau de bord.

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

  • 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. [Correction obligatoire]

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

    Le graphique montre un exemple de contenu dans la page d’accueil des onglets configurables selon le contexte de tous les membres.

  • Les onglets configurables doivent avoir des fonctionnalités ciblées. [Correction obligatoire]

    onglet validation-usability-configurable-nested-tab


Retour au début

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, le dob, le lieu et la désignation au lieu d’utiliser des conversations multitours. [Correction obligatoire]

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


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. [Correction obligatoire]

    Le graphique montre un exemple de bot répondant à des commandes génériques.

    Le graphique montre un exemple de bot sans réponse aux commandes génériques.

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

    validation-bot-commands-dead-end

  • 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. [Correctif suggéré]

  • 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. [Correction obligatoire]

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

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de réponse de bot redirigeant l’utilisateur en dehors de Teams.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de réponse valide pour une commande de bot incorrecte.

    Le graphique montre un exemple de réponse non valide pour une commande de bot incorrecte.

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

    Le graphique montre un exemple de scénario d’échec dans lequel des caractères spéciaux sont préfixés à des commandes de bot.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de bot fournissant un moyen d’aller de l’avant pour une commande non valide.

    Le graphique montre un exemple de scénario d’échec où un bot envoie une même réponse pour une commande valide et non valide.

  • 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. [Correction obligatoire]

  • Les bots ne doivent pas contenir de commandes en double. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de bot ne fournissant pas de réponse valide pour une commande en minuscules ou en majuscules.

    Le graphique montre un exemple de bot sans réponse valide lorsque l’utilisateur ne s’est pas connecté à l’application.

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

    Le graphique montre un exemple de bot envoyant 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. [Correction obligatoire]

    Le graphique montre un exemple de message de bot sans troncation sur mobile.

    Le graphique montre un exemple de message de bot tronqué sur un appareil mobile.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de bouton d’action de réponse de bot avec une redirection.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de propriété de notification uniquement définie sur true dans le manifeste de l’application.

    Le graphique montre un exemple de bot de notification uniquement ne répondant pas au message d’un utilisateur.

  • 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. [Correction obligatoire]

Conseil

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


Messages de bienvenue du bot
  • Si l'application a un flux de configuration complexe (nécessite une licence d'entreprise ou manque d'un flux d'inscription intuitif), les robots de ces applications doivent toujours envoyer 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.

    Le graphique montre un exemple de bot envoyant un message de bienvenue quand le bot a un workflow de configuration complexe.

    Le graphique montre un exemple de bot qui n’envoie pas de message de bienvenue quand le bot a un workflow de configuration complexe.

  • 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.

    validation-bot-welcome-message-not-trigger

    validation-bot-wel-message-trigger

  • Les bots de notification uniquement doivent envoyer un message de bienvenue qui précise qu’il s’agit d’un bot de notification uniquement et que les utilisateurs ne pourront pas interagir avec le bot. [Correction obligatoire]

    Le graphique montre un exemple de bot envoyant un message de bienvenue indiquant qu’il s’agit d’un bot de notification uniquement.

  • 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é. [Correction obligatoire]

    Le graphique montre un exemple de scénario d’échec dans lequel le bot n’a aucun moyen d’aller de l’avant pour l’utilisateur dans un message de bienvenue.

    Le graphique montre un exemple de message de bienvenue du bot avec un moyen clair pour l’utilisateur d’effectuer la tâche.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de bot qui envoie un message de bienvenue proactif à tous les membres de l’équipe.

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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

    Le graphique montre un exemple de limitation d’application dans le message de bienvenue du bot.

    Le graphique montre un exemple de bot sans limitation d’application dans un message de bienvenue.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de bot qui n’envoie pas automatiquement un message de bienvenue dans une étendue personnelle.

  • 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. [Correction obligatoire]

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

    Le graphique montre un exemple de bot déclenchant un message de bienvenue pour n’importe quelle commande.

  • 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. [Correction obligatoire]

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

    Le graphique montre un exemple de bot déclenchant plusieurs messages de bienvenue lors de l’installation de l’application.

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

    Le graphique montre un exemple de nom d’application dans le message de bienvenue qui ne correspond pas au nom de l’application dans le manifeste de l’application.

  • 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. [Correction obligatoire]

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

  • 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. [Correction obligatoire]

  • 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. [Correctif suggéré]

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. [Correction obligatoire]

    validation-bot-message-spam-one-message

    validation-bot-message-spam-multiple-message

  • Messages de bot dans les applications personnelles :

    • N’envoyez pas plusieurs messages en succession rapide. [Correction obligatoire]

      Le graphique montre un exemple de bot envoyant plusieurs messages en succession rapide.

    • Envoyez un message avec des informations complètes. [Correction obligatoire]

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

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

    • 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.

      validation-bot-message-using-task-module

      Le graphique montre un exemple de bot utilisant des messages multitours pour terminer une conversation unique.

  • 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. [Correction obligatoire]


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). [Correction obligatoire]

validation-bot-notification-relevant

validation-bot-notification-not-relevant


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 :

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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]


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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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

Retour au début

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.

    Le graphique montre un exemple d’application qui ne répond pas aux instructions d’extension.

  • 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. [Correction obligatoire]

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

    Le graphique montre un exemple de chargement d’image d’aperçu dans un carte adaptatif.

    Le graphique montre un exemple d’image d’aperçu qui ne se charge pas dans un carte adaptatif.

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

  • 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. [Correction obligatoire]

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

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

  • 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.

    validation-messaging-extension-no-intermediate-steps

    validation-messaging-extension-intermediate-steps-available

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

    validation-messaging-extension-app-passes-messages

    validation-messaging-extension-app-doesnot-pass-messages

  • 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. [Correctif suggéré]

    Le graphique montre un exemple de nom d’application hôte pour une commande d’action.

    Le graphique montre un exemple de verbe générique pour une commande d’action.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple d’indicateur de chargement continu lorsqu’un bot appelle une commande d’action.

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

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

  • 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. [Correction obligatoire]

    • 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. [Correction obligatoire]


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

[Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correctif obligatoire]


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

    Le graphique montre un exemple d’extension de message avec texte d’aide pour que les utilisateurs puissent effectuer une recherche efficace.

    Le graphique montre un exemple d’extension de message sans texte d’aide pour que les utilisateurs puissent effectuer une recherche efficace.

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

    validation-search-commands-unclear-executable

Retour au début

Boîtes de dialogue

[Correction obligatoire]

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.

validation-task-module-displays-component

validation-task-module-embed-app

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 au début

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. [Correction obligatoire]

  • 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. [Correction obligatoire]

    • 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.

    Le graphique montre un exemple d’expérience en réunion redirigeant l’utilisateur en dehors de Teams pour l’exécution des fonctionnalités principales de l’application.

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

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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

  • 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. [Correctif obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

    Le graphique montre un exemple d’écran de chargement continu dans une application.

  • 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 actuellement actif. [Correction obligatoire]

  • 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. [Correction obligatoire]

    Le graphique montre un exemple d’application redirigeant vers une plateforme basée sur une conversation concurrente.

  • 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. [Correction obligatoire]

    Le graphique montre un exemple d’application sans solution pour les participants dans une vue basée sur les rôles.


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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

    Le graphique montre un exemple d’onglet qui ne suit pas les instructions de conception d’onglet.


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. [Correction obligatoire]

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

    validation-in-meeting-exp-display-app-names

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


Onglets en réunion
  • Doivent être réactifs. [Correction obligatoire]

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

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

    Le graphique montre un exemple de bouton Précédent présent.

    Le graphique montre un exemple de bouton Précédent non présent.

  • 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. [Correctif obligatoire]

  • Ne doit pas avoir de défilement horizontal. [Correction obligatoire]

    Le graphique montre un exemple d’onglet en réunion avec défilement vertical.

    Le graphique montre un exemple d’onglet en réunion avec défilement horizontal.


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. [Correction obligatoire]

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

    Le graphique montre un exemple de disposition à colonne unique pour la boîte de dialogue en réunion.

    Le graphique montre un exemple de disposition de plusieurs colonnes pour la boîte de dialogue en réunion.

  • Ne doit pas utiliser de boîtes de dialogue. [Correction obligatoire]

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

    Le graphique montre un exemple de boîte de dialogue en réunion qui ne s’aligne pas sur le centre de la phase de réunion.

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

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

    • 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 . [Correction obligatoire]

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. [Correction obligatoire]

Retour au début

Connector

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

    Capture d’écran montrant l’incompatibilité dans le nom de l’application entre l’application et le manifeste de l’application.

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

    Capture d’écran montrant une erreur lors de la configuration du connecteur par l’utilisateur.

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é. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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

  • 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. [Correction obligatoire]


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

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

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

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

Retour au début

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. [Correction obligatoire]

    Le graphique montre un exemple de badge bleu vérifié dans la boîte de dialogue de consentement Microsoft Entra.

  • 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. [Correctif suggéré]

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 au début

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. [Correction obligatoire]

Le graphique montre un exemple de scénario d’échec de la publicité dans Teams.

Retour au début

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 : [Correctif obligatoire]

  • 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 au début

Fonctionnalité de l’application

  • Les flux de travail ou le contenu de l’application doivent être liés à l’étendue. [Correction obligatoire]
  • 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. [Correction obligatoire]
  • 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. [Correction obligatoire]
  • 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. [Correction obligatoire]

Retour au début

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. [Correction obligatoire]

    Le graphique montre un exemple de complément mobile demandant un paiement.

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

  • 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. [Correction obligatoire]

    Le graphique montre un exemple de détails de tarification sur mobile.

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

    Le graphique montre un exemple de paiement de biens numériques sur mobile.

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

  • 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. [Correction obligatoire]

Retour au début

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. [Correction obligatoire]

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 . [Correction obligatoire]

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. [Correction obligatoire]

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. [Correction obligatoire]

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. [Correction obligatoire]

  • 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. [Correction obligatoire]

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. [Correction obligatoire]

  • 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. [Correction obligatoire]

Retour au début

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

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 Copilot. Par exemple, utilisez Contoso dans 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 Copilot. Par exemple, quels sont les tickets de haute priorité qui m’ont été attribués cette semaine dans Contoso.

    Capture d’écran montrant un scénario de réussite avec un exemple d’exemple d’invite pour l’utilisation de l’extension de message en tant que plug-in dans Copilot.

    Capture d’écran montrant un scénario d’échec sans exemple d’exemple d’invite d’utilisation de l’extension de message en tant que plug-in dans Copilot.

Qualité de la réponse

  • Les champs obligatoires dans Microsoft 365 Chat 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.

    Capture d’écran montrant un exemple d’application montrant Microsoft 365 Chat réponse de l’application contient l’aperçu et le contenu dans la même réponse.

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

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

    Capture d’écran montrant un exemple de titre d’informations, de champs utilisateur supplémentaires et de bouton d’action dans une réponse de carte adaptative.

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

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

  • Microsoft 365 Chat 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 Chat.

Retour au début

Étape suivante

Voir aussi