Conditions de certification des applications de bureau Windows

Version du document : 10

Date du document : 29 juillet 2015

Ce document contient les exigences techniques et les qualifications d’éligibilité qu’une application de bureau doit remplir pour participer au programme de certification des applications de bureau Windows 10.

Bienvenue !

La plateforme Windows prend en charge un vaste écosystème de produits et de partenaires. L’affichage du logo Windows sur votre produit représente une relation et un engagement partagé à la qualité entre Microsoft et votre entreprise. Les clients font confiance à la marque Windows sur votre produit, car il s’assure qu’il répond aux normes de compatibilité et fonctionne bien sur la plateforme Windows. La réussite de Windows certification des applications permet à votre application d’être présentée dans le Centre de compatibilité Windows et vous pouvez afficher le logo de certification sur votre site.

Le programme de certification des applications Windows est constitué de programmes et d’exigences techniques pour vous assurer que les applications tierces portant la marque Windows sont faciles à installer et fiables sur les PC exécutant Windows. Les clients apprécient la stabilité, la compatibilité, la fiabilité, les performances et la qualité dans les systèmes qu’ils achètent. Microsoft met l’accent sur ses investissements pour répondre à ces exigences pour les applications logicielles conçues pour s’exécuter sur la plateforme Windows pour les PC. Ces efforts incluent des tests de compatibilité pour assurer la cohérence de l’expérience, améliorer les performances et renforcer la sécurité sur les PC exécutant Windows logiciel. Les tests de compatibilité Microsoft ont été conçus en collaboration avec les partenaires du secteur et sont continuellement améliorés en réponse aux développements du secteur et à la demande des consommateurs.

Le Kit de certification des applications Windows est utilisé pour valider la conformité à ces exigences et remplace les versions précédentes du kit utilisées pour valider Windows 7, Windows 8 ou Windows 8.1. Le Kit de certification des applications Windows est l’un des composants inclus dans le Kit de développement logiciel (SDK) Windows pour Windows 10.

Éligibilité de l’application

Pour qu’une application soit éligible à Windows 10 certification d’application de bureau, elle doit respecter les critères suivants et toutes les exigences techniques répertoriées dans ce document.

  • Il doit s’agir d’une application autonome
  • Il doit s’exécuter sur un PC local Windows 10
  • Il peut s’agir d’un composant client d’une application Windows Server certifiée
  • Il doit s’agir d’un code et d’une fonctionnalité complètes
  • Il ne doit pas communiquer avec les applications Windows Store via des mécanismes locaux, notamment via des fichiers et des clés de Registre, sauf dans les scénarios d’entreprise pris en charge
  • Il ne doit pas compromettre ou compromettre la sécurité ou les fonctionnalités du système Windows
  • Elle doit avoir un nom unique et ne doit pas être déposée par d’autres
  • Tous les composants externes doivent être certifiés séparément ou conformes au Kit de certification des applications Windows
  • Il doit avoir une option de désactivation pour toutes les applications groupées

Si l’application de bureau est soumise à la catégorie des produits anti-virus et/ou anti-logiciels espions (c’est-à-dire anti-programme malveillant), elle doit se conformer aux directives de la plateforme ANTIMALWARE. Le CONTRAT DE LICENCE ET DE RÉFÉRENCEMENT DE l’API WINDOWS 10 ANTIMALWARE doit avoir été signé et appliqué avant la soumission. Le partenaire doit être membre ou avoir des chercheurs membres et en bonne position dans l’une des organisations répertoriées dans l’accord. Les fonctionnalités doivent être certifiées sur Windows 10 par l’une des organisations répertoriées dans le contrat. L’application doit avoir été testée au moins une fois au cours des 12 derniers mois, et certifiée pour la détection et le nettoyage.

1. Les applications sont compatibles et résilientes

Les moments où une application plante ou cesse de répondre provoquent beaucoup de frustration de l’utilisateur. Les applications sont censées être résilientes et stables et éliminer ces défaillances permettent de s’assurer que les logiciels sont plus prévisibles, maintenables, performants et dignes de confiance.

1.1 Votre application ne doit pas dépendre des modes de compatibilité Windows, du message AppHelp et ou d’autres correctifs de compatibilité
1.2 Votre application doit avoir un manifeste de compatibilité et utiliser les GUID appropriés pour les versions prises en charge de Windows
1.3 Votre application doit prendre en charge les ppp à l’aide du manifeste d’assembly de l’application plutôt qu’en appelant SetProcessDPIAware
1.4 Votre application ne doit pas prendre de dépendance sur le runtime VB6
1.5 Votre application ne doit pas charger de DLL arbitraires pour intercepter les appels d’API Win32 à l’aide de HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.

2. Les applications doivent respecter les bonnes pratiques de sécurité Windows

L’utilisation de Windows meilleures pratiques de sécurité permet d’éviter d’exposer Windows surfaces d’attaque. Les surfaces d’attaque sont les points d’entrée qu’un attaquant malveillant pourrait utiliser pour exploiter le système d’exploitation en tirant parti des vulnérabilités dans le logiciel cible. L’une des vulnérabilités de sécurité les plus graves est l’élévation de privilèges.

Notez que les tests 2.1 2.6 s’appliquent uniquement aux applications de bureau testées sur Windows 7, Windows 8 ou Windows 8.1.

2.1 Votre application doit utiliser des listes de contrôle d’accès fortes et appropriées pour sécuriser les fichiers exécutables
2.2 Votre application doit utiliser des listes de contrôle d’accès fortes et appropriées pour sécuriser les répertoires
2.3 Votre application doit utiliser des listes de contrôle d’accès fortes et appropriées pour sécuriser les clés de Registre
2.4 Votre application doit utiliser des listes de contrôle d’accès fortes et appropriées pour sécuriser les répertoires qui contiennent des objets
2.5 Votre application doit réduire l’accès non administrateur aux services vulnérables à la falsification
2.6 Votre application doit empêcher les services avec des redémarrages rapides de redémarrer plus de deux fois toutes les 24 heures

Remarque : L’accès doit uniquement être accordé aux entités qui en ont besoin.

Le programme de certification des applications Windows vérifie que Windows surfaces d’attaque ne sont pas exposées en vérifiant que les listes de contrôle d’accès et les services sont implémentées de manière à ne pas mettre le système Windows à risque.

3. Les applications prennent en charge les fonctionnalités de sécurité Windows

Le système d’exploitation Windows dispose de nombreuses fonctionnalités qui prennent en charge la sécurité et la confidentialité du système. Les applications doivent prendre en charge ces fonctionnalités pour maintenir l’intégrité du système d’exploitation. Les applications compilées de manière incorrecte peuvent entraîner des dépassements de mémoire tampon qui peuvent, à leur tour, provoquer un déni de service ou autoriser l’exécution de code malveillant.

3.1 Votre application ne doit pas utiliser AllowPartiallyTrustedCallersAttribute (APTCA) pour garantir un accès sécurisé aux assemblys avec nom fort
3.2 Votre application doit être compilée à l’aide de l’indicateur /SafeSEH pour garantir la gestion des exceptions sécurisées
3.3 Votre application doit être compilée à l’aide de l’indicateur /NXCOMPAT pour empêcher l’exécution des données
3.4 Votre application doit être compilée à l’aide de l’indicateur /DYNAMICBASE pour la randomisation de la disposition de l’espace d’adressage (ASLR)
3.5 Votre application ne doit pas lire/écrire les sections PE partagées

4. Les applications doivent respecter les messages du gestionnaire de redémarrage du système

Lorsque les utilisateurs lancent l’arrêt, ils ont généralement un fort désir de voir l’arrêt réussir; ils sont peut-être pressés de quitter le bureau et veulent simplement que leurs ordinateurs soient désactivés. Les applications doivent respecter ce désir en ne bloquant pas l’arrêt. Bien que dans la plupart des cas, un arrêt ne soit pas critique, les applications doivent être préparées pour la possibilité d’un arrêt critique.

4.1 Votre application doit gérer les arrêts critiques de manière appropriée
Dans un arrêt critique, les applications qui retournent FALSE à WM_QUERYENDSESSION sont envoyées WM_ENDSESSION et fermées, tandis que celles qui expirent en réponse à WM_QUERYENDSESSION seront arrêtées.

4.2 Une application GUI doit retourner TRUE immédiatement en préparation d’un redémarrage
WM\_QUERYENDSESSION avec LPARAM = ENDSESSION\_CLOSEAPP(0x1). Les applications console peuvent appeler SetConsoleCtrlHandler pour spécifier la fonction qui gère les notifications d’arrêt. Les applications de service peuvent appeler RegisterServiceCtrlHandlerEx pour spécifier la fonction qui recevra des notifications d’arrêt.
4.3 Votre application doit retourner 0 dans les 30 secondes et arrêter
WM\_ENDSESSION avec LPARAM = ENDSESSION\_CLOSEAPP(0x1). Au minimum, l’application doit se préparer en enregistrant toutes les données utilisateur et en indiquant les informations nécessaires après un redémarrage.
4.4 Les applications console qui reçoivent la notification CTRL\_C\_EVENT doivent s’arrêter immédiatement 4.5 Pilotes ne doivent pas bloquer un événement d’arrêt système
Remarque : les applications qui doivent bloquer l’arrêt en raison d’une opération qui ne peut pas être interrompue doivent expliquer la raison à l’utilisateur. Utilisez ShutdownBlockReasonCreate pour inscrire une chaîne qui explique la raison de l’utilisateur. Une fois l’opération terminée, l’application doit appeler ShutdownBlockReasonDestroy pour indiquer que le système peut être arrêté.

5. Les applications doivent prendre en charge une installation réversible et propre

Une installation propre et réversible permet aux utilisateurs de gérer correctement (déployer et supprimer) des applications sur leurs systèmes.

5.1 Votre application doit implémenter correctement une installation réversible et propre
Si l’installation échoue, l’application doit pouvoir la restaurer et restaurer l’ordinateur à son état précédent.

5.2 Votre application ne doit jamais forcer l’utilisateur à redémarrer l’ordinateur immédiatement
Le redémarrage de l’ordinateur ne doit jamais être la seule option à la fin d’une installation, d’une désinstallation ou d’une mise à jour. Les utilisateurs doivent avoir la possibilité de redémarrer ultérieurement.
5.3 Votre application ne doit jamais dépendre des noms de fichiers courts 8.3 (SFN) 5.4 Votre application ne doit jamais bloquer l’installation sans assistance/désinstallation 5.5 Votre programme d’installation d’application doit créer les entrées de Registre appropriées pour permettre la détection et les désinstallations réussies
Windows outils d’inventaire et les outils de télémétrie nécessitent des informations complètes sur les applications installées. Si vous utilisez un programme d’installation basé sur MSI, MSI crée automatiquement les entrées de Registre ci-dessous. Si vous n’utilisez pas de programme d’installation MSI, le module d’installation doit créer les entrées de Registre suivantes lors de l’installation :
  • DisplayName
  • Emplacement de l’installation
  • Serveur de publication
  • UninstallString
  • VersionMajor ou MajorVersion
  • VersionMinor ou MinorVersion
5.6 L’application doit supprimer toutes ses entrées de l’ajout/suppression de programmes lors de la désinstallation

6. Les applications doivent signer numériquement des fichiers et des pilotes

Une signature numérique Authenticode permet aux utilisateurs de s’assurer que le logiciel est authentique. Il permet également de détecter si un fichier a été falsifié, par exemple s’il a été infecté par un virus. L’application de la signature de code en mode noyau est une fonctionnalité Windows appelée intégrité du code (CI), qui améliore la sécurité du système d’exploitation en vérifiant l’intégrité d’un fichier chaque fois que l’image du fichier est chargée en mémoire. CI détecte si le code malveillant a modifié un fichier binaire système. Génère également un événement de journal de diagnostic et d’audit système lorsque la signature d’un module de noyau ne parvient pas à vérifier correctement.

6.1 Tous les fichiers exécutables (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) doivent être signés avec un certificat Authenticode
6.2 Tous les pilotes en mode noyau installés par l’application doivent avoir une signature Microsoft obtenue via le programme de certification matérielle Windows. Tous les pilotes de filtre du système de fichiers doivent être signés par Microsoft.
6.3 Exceptions et exceptions
Les dérogations ne seront considérées que pour les redistribuables tiers non signés, à l’exclusion des pilotes. Une preuve de communication demandant une version signée du ou des redistribuables est requise pour que cette exemption soit accordée.

7. Les applications ne bloquent pas l’installation ou le lancement de l’application en fonction d’une vérification de version du système d’exploitation

Il est important que les clients ne soient pas bloqués artificiellement à l’installation ou à l’exécution de leur application lorsqu’il n’existe aucune limitation technique. En général, si les applications ont été écrites pour Windows Vista ou versions ultérieures de Windows, elles ne doivent pas avoir à vérifier la version du système d’exploitation.

7.1 Votre application ne doit pas effectuer de vérifications de version pour l’égalité
Si vous avez besoin d’une fonctionnalité spécifique, vérifiez si la fonctionnalité elle-même est disponible. Si vous avez besoin de Windows 7, vérifiez Windows 7 ou version ultérieure (>= 6.2). De cette façon, votre code de détection continuera de fonctionner sur les versions futures de Windows. Les programmes d’installation de pilotes et les modules de désinstallation ne doivent jamais vérifier la version du système d’exploitation.

7.2 Les exceptions et les dérogations seront prises en compte pour les applications répondant aux critères ci-dessous :
  • Les applications fournies en tant que package qui s’exécutent également sur Windows 7, Windows 8 et Windows 8.1, doivent vérifier la version du système d’exploitation pour déterminer les composants à installer sur un système d’exploitation donné.
  • Applications qui vérifient uniquement la version minimale du système d’exploitation (pendant l’installation uniquement, pas au moment de l’exécution) en utilisant uniquement les appels d’API approuvés, et qui répertorient correctement la configuration requise de version minimale dans le manifeste de l’application.
  • Applications de sécurité (antivirus, pare-feu, etc.), utilitaires système (par exemple, défragmentation, sauvegardes et outils de diagnostic) qui vérifient la version du système d’exploitation en utilisant uniquement les appels d’API approuvés.

8. Les applications ne chargent pas les services ou les pilotes en mode sans échec

Coffre mode permet aux utilisateurs de diagnostiquer et de résoudre les problèmes de Windows. Les pilotes et services ne doivent pas être configurés pour charger en mode sans échec, sauf s’ils sont nécessaires pour les opérations système de base de telles que les pilotes de périphérique de stockage ou à des fins de diagnostic et de récupération, telles que les scanneurs anti-virus,. Par défaut, lorsque Windows est en mode sans échec, il démarre uniquement les pilotes et services préinstallés avec Windows.

  • 8.1 Exceptions et exceptions
    Les pilotes et les services qui doivent être démarrés en mode sans échec nécessitent une exemption. La demande de dérogation doit inclure chaque pilote ou service applicable écrit dans les clés de Registre SafeBoot et décrire les raisons techniques pour lesquelles l’application ou le service doit s’exécuter en mode sans échec. Le programme d’installation de l’application doit inscrire tous ces pilotes et services à l’aide de ces clés de Registre :
    - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network

Note: Vous devez tester ces pilotes et services pour vous assurer qu’ils fonctionnent en mode sans échec sans aucune erreur.

9. Les applications doivent suivre les instructions de contrôle de compte d’utilisateur

Certaines applications Windows s’exécutent dans le contexte de sécurité d’un compte d’administrateur, et les applications demandent souvent des droits d’utilisateur excessifs et des privilèges de Windows. Le contrôle de l’accès aux ressources permet aux utilisateurs de contrôler leurs systèmes et de les protéger contre les modifications indésirables. Une modification indésirable peut être malveillante, telle qu’un rootkit prenant le contrôle de l’ordinateur, ou être le résultat d’une action effectuée par des personnes qui ont des privilèges limités.. La règle la plus importante pour contrôler l’accès aux ressources consiste à fournir la quantité minimale d’accès au contexte utilisateur standard nécessaire pour qu’un utilisateur effectue ses tâches nécessaires. Les instructions de contrôle de compte d’utilisateur (UAC) suivantes fournissent à une application les autorisations nécessaires lorsqu’elles sont nécessaires par l’application, sans laisser le système constamment exposé aux risques de sécurité. La plupart des applications n’ont pas besoin de privilèges d’administrateur au moment de l’exécution et doivent être juste en cours d’exécution en tant qu’utilisateur standard.

9.1 Votre application doit avoir un manifeste qui définit les niveaux d’exécution et indique au système d’exploitation les privilèges requis par l’application afin d’exécuter
Le marquage du manifeste de l’application s’applique uniquement aux EXEs, et non aux DLL. Cela est dû au fait que L’UAC n’inspecte pas les DLL pendant la création du processus. Il vaut également la peine de noter que les règles UAC ne s’appliquent pas à services Microsoft. Le manifeste peut être incorporé ou externe.
Pour créer un manifeste, créez un fichier portant le nom <app_name>.exe.manifest et stockez-le dans le même répertoire que l’EXE. Notez que tout manifeste externe est ignoré si l’application a un manifeste interne. Par exemple :
<requestedExecutionLevel level=""asInvoker | | le plus élevéavailable requireAdministrator" » uiAccess=""true|false"""/>

9.2 Le processus principal de votre application doit être exécuté en tant qu’utilisateur standard (asInvoker).
Toutes les fonctionnalités administratives doivent être déplacées dans un processus distinct qui s’exécute avec des privilèges d’administration. Les applications accessibles par l’utilisateur, telles que celles accessibles par le biais du groupe de programmes dans le menu Démarrer, et l’élévation doit être signée Authenticode.
9.3 Exceptions et exceptions
Une exemption est requise pour les applications qui exécutent leur processus principal avec des privilèges élevés (exigerAdministrator ou highestAvailable). Le processus principal est identifié comme point d’entrée de l’utilisateur vers l’application. Les dérogations seront prises en compte pour les scénarios suivants :
  • Outils d’administration ou système avec niveau d’exécution défini sur highestAvailable et/ou exigerAdministrator
  • Seule l’application d’infrastructure d’accessibilité ou d’automatisation de l’interface utilisateur définit l’indicateur uiAccess sur true pour contourner l’isolation des privilèges d’interface utilisateur (UIPI). Pour démarrer correctement l’utilisation de l’application, cet indicateur doit être signé Authenticode et doit résider dans un emplacement protégé dans le système de fichiers, à savoir Program Files.

10. Les applications doivent être installées sur les dossiers appropriés par défaut

Les utilisateurs doivent avoir une expérience cohérente et sécurisée avec l’emplacement d’installation par défaut des fichiers, tout en conservant l’option d’installation d’une application à l’emplacement de leur choix. Il est également nécessaire de stocker les données d’application à l’emplacement approprié pour permettre à plusieurs personnes d’utiliser le même ordinateur sans endommager ou remplacer les données et les paramètres des autres. Windows fournit des emplacements spécifiques dans le système de fichiers pour stocker des programmes et des composants logiciels, des données d’application partagées et des données d’application spécifiques à un utilisateur

10.1 Votre application doit être installée dans le dossier Program Files par défaut
Pour les applications 32 bits et 64 bits natives dans %ProgramFiles%, et %ProgramFiles(x86)% pour les applications 32 bits s’exécutant sur x64. Les données utilisateur ou les données d’application ne doivent jamais être stockées dans cet emplacement en raison des autorisations de sécurité configurées pour ce dossier.

10.2 Votre application doit éviter de démarrer automatiquement au démarrage
Par exemple, votre application ne doit pas définir l’un des éléments suivants ;
  • Le Registre exécute les clés HKLM et, ou HKCU, sous Software\Microsoft\Windows\CurrentVersion
  • Le Registre exécute les clés HKLM et ou HKCU sous Software\Wow6432Node\Microsoft\windows\CurrentVersion
  • Démarrer le menu AllPrograms > STARTUP
10.3 Vos données d’application, qui doivent être partagées entre les utilisateurs sur l’ordinateur, doivent être stockées dans ProgramData 10.4 Vos données d’application exclusives à un utilisateur spécifique et qui ne doivent pas être partagées avec d’autres utilisateurs de l’ordinateur, doivent être stockées dans Users\\<username>\\AppData 10.5 Votre application ne doit jamais écrire directement dans le répertoire « Windows » et ou sous-répertoires.
Utilisez les méthodes appropriées pour installer des fichiers, tels que des polices ou des pilotes.
10.6 Votre application doit écrire des données utilisateur lors de la première exécution et non lors de l’installation dans les installations par machine
Lorsque l’application est installée, il n’existe aucun emplacement d’utilisateur correct dans lequel stocker des données. Tente par une application de modifier les comportements d’association par défaut au niveau de l’ordinateur après échec de l’installation. Au lieu de cela, les valeurs par défaut doivent être revendiquées au niveau d’un utilisateur, ce qui empêche plusieurs utilisateurs de remplacer les valeurs par défaut des autres.
10.7 Exceptions et dérogations
Une exemption est requise pour les applications qui écrivent dans les applications global assembly cache (GAC) .NET doivent conserver les dépendances d’assembly privées et les stocker dans le répertoire de l’application, sauf si le partage d’un assembly est explicitement requis.

11. Les applications doivent prendre en charge des sessions multi-utilisateurs

Windows utilisateurs doivent pouvoir exécuter des sessions simultanées sans conflit ou interruption.

11.1 Votre application doit s’assurer que lors de l’exécution dans plusieurs sessions localement ou à distance, la fonctionnalité normale de l’application n’est pas affectée de manière négative
11.2 Les paramètres et les fichiers de données de votre application ne doivent pas être conservés entre les utilisateurs
11.3 Une confidentialité et des préférences de l’utilisateur doit être isolée dans la session de l’utilisateur
11.4 Les instances de votre application doivent être isolées les unes des autres
Cela signifie que les données utilisateur d’une instance ne sont pas visibles par une autre instance de l’application. Le son d’une session utilisateur inactive ne doit pas être entendu dans une session utilisateur active. Dans les cas où plusieurs instances d’application utilisent des ressources partagées, l’application doit s’assurer qu’il n’y a pas de conflit.

11.5 Applications installées pour plusieurs utilisateurs doivent stocker des données dans les dossiers et emplacements de Registre appropriés
Reportez-vous aux exigences de l’UAC.
11.6 Les applications utilisateur doivent être en mesure d’s’exécuter dans plusieurs sessions utilisateur (basculement rapide de l’utilisateur) pour l’accès local et à distance 11.7 Votre application doit vérifier d’autres sessions de service terminal (TS) pour les instances existantes de l’application
Note: Si une application ne prend pas en charge plusieurs sessions utilisateur ou accès à distance, elle doit clairement l’indiquer lorsqu’elle est lancée à partir de ce type de session.

12. Les applications doivent prendre en charge les versions x64 de Windows

À mesure que le matériel 64 bits devient plus courant, les utilisateurs s’attendent à ce que les développeurs d’applications tirent parti des avantages de l’architecture 64 bits en migrant leurs applications vers des versions 64 bits, ou que les versions 32 bits de l’application s’exécutent bien sous les versions 64 bits de Windows.

12.1 Votre application doit prendre en charge en mode natif 64 bits ou, au minimum, des applications Windows 32 bits doivent s’exécuter en toute transparence sur des systèmes 64 bits pour maintenir la compatibilité avec les versions 64 bits de Windows
12.2 Votre application et ses programmes d’installation ne doivent pas contenir de code 16 bits ou s’appuyer sur n’importe quel composant 16 bits
12.3 La configuration de votre application doit détecter et installer les pilotes et composants appropriés pour l’architecture 64 bits
12.4 Tous les plug-ins shell doivent s’exécuter sur des versions 64 bits de Windows
12.5 Application s’exécutant sous l’émulateur WoW64 ne doit pas tenter de subvertir ou de contourner les mécanismes de virtualisation Wow64
S’il existe des scénarios spécifiques où les applications doivent détecter s’ils s’exécutent sous l’émulateur WoW64, ils doivent le faire en appelant IsWow64Process.

Conclusion

À mesure que ces exigences évoluent, nous notons les modifications apportées à l’historique des révisions ci-dessous. Les exigences stables sont essentielles pour faire votre meilleur travail. Nous nous efforcerons donc de garantir que les modifications que nous faisons sont durables et continuent de protéger et d’améliorer vos applications.

Merci encore de vous joindre à notre engagement à offrir de grandes expériences client.

Historique des révisions

Date Version Description de la révision Lien vers le document
20c 2011 1.0 Brouillon initial du document pour la préversion.
26 janvier 2012 1.1 Mise à jour vers la section 2. 1.1
31 mai 2012 1,2 Ajout des résultats de test récapitulatives 1.2
29 juin 2012 3.0 Windows 8 document final 3.0
18 juin 2013 3.1 document Windows 8.1 3.1
20 février 2014 3.2 Mise à jour interne
18 mars 2014 3.3 Mise à jour Windows 8.1 1 3.3
29 juillet 2015 10 mise à jour de Windows 10 10

En savoir plus sur la certification des applications de bureau

Condition requise Description
Compatibilité et résilience Les incidents & blocages sont une perturbation majeure des utilisateurs et provoquent de la frustration. Les applications sont censées être résilientes et stables, l’élimination de ces défaillances permet de s’assurer que les logiciels sont plus prévisibles, maintenables, performants et fiables.
Le point d’entrée d’application accessible par l’utilisateur doit être manifeste pour la compatibilité, ainsi que la déclaration du GUID approprié.
Les points d’entrée d’application accessibles aux utilisateurs doivent être manifestés pour la sensibilisation HIGH-DPI et que les API appropriées sont appelées pour prendre en charge HIGH-DPI.
Pour plus d’informations, consultez les pages suivantes :
Respecter les meilleures pratiques Sécurité Windows L’utilisation de Windows meilleures pratiques de sécurité permet d’éviter d’exposer Windows surfaces d’attaque. Les surfaces d’attaque sont les points d’entrée qu’un attaquant malveillant pourrait utiliser pour exploiter le système d’exploitation en tirant parti des vulnérabilités dans le logiciel cible. L’une des vulnérabilités de sécurité les plus graves est l’élévation de privilèges.
Pour plus d’informations, consultez les pages suivantes :
Prise en charge des fonctionnalités de Sécurité Windows Le système d’exploitation Windows a implémenté de nombreuses mesures pour prendre en charge la sécurité et la confidentialité du système. Les applications doivent prendre en charge ces mesures pour maintenir l’intégrité du système d’exploitation. Les applications compilées de manière incorrecte peuvent entraîner des dépassements de mémoire tampon qui, à leur tour, peuvent entraîner un déni de service ou exécuter du code malveillant. Pour plus d’informations, consultez la référence de l’outil BinScope.
Adhérer aux messages du Gestionnaire de redémarrage du système Lorsque les utilisateurs lancent l’arrêt, dans la grande majorité des cas, ils ont un fort désir de voir l’arrêt réussir; ils peuvent être pressés de quitter le bureau et de « juste vouloir » leurs ordinateurs de désactiver. Les applications doivent respecter ce désir en ne bloquant pas l’arrêt. Bien que dans la plupart des cas, un arrêt ne soit pas critique, les applications doivent être préparées pour la possibilité d’un arrêt critique.
Nettoyer l’installation réversible Une installation propre et réversible permet aux utilisateurs de gérer correctement (déployer et supprimer) des applications sur leurs systèmes. Pour plus d’informations, voir How to: Install Prerequisites with a ClickOnce Application.
Signer numériquement des fichiers et des pilotes Une signature numérique Authenticode permet aux utilisateurs de s’assurer que le logiciel est authentique. Il permet également de détecter si un fichier a été falsifié, par exemple, s’il a été infecté par un virus. L’application de la signature de code en mode noyau est une fonctionnalité Windows appelée intégrité du code (CI), qui améliore la sécurité du système d’exploitation en vérifiant l’intégrité d’un fichier chaque fois que l’image du fichier est chargée en mémoire. CI détecte si le code malveillant a modifié un fichier binaire système. Génère également un événement de journal de diagnostic et d’audit système lorsque la signature d’un module de noyau ne parvient pas à vérifier correctement.
Ne bloquez pas l’installation ou le lancement de l’application en fonction de la vérification de la version du système d’exploitation Il est important que les clients ne soient pas artificiellement empêchés d’installer ou d’exécuter leur application en l’absence de limitations techniques. En général, si les applications ont été écrites pour Windows Vista ou versions ultérieures, elles ne doivent pas avoir de raison de vérifier la version du système d’exploitation. Pour plus d’informations, consultez Gestion des versions du système d’exploitation.
Ne chargez pas les services et les pilotes en mode Coffre Coffre mode permet aux utilisateurs de diagnostiquer et de résoudre les problèmes de Windows. Sauf si nécessaire pour les opérations de base du système (par exemple, les pilotes de périphériques de stockage) ou à des fins de diagnostic et de récupération (par exemple, les scanneurs antivirus), les pilotes et les services ne doivent pas être configurés pour être chargés en mode sans échec. Par défaut, le mode sans échec ne démarre pas la plupart des pilotes et services qui ne sont pas préinstallés avec Windows. Ils doivent rester désactivés, sauf si le système les exige pour des opérations de base ou à des fins de diagnostic et de récupération.
Pour plus d’informations, consultez les pages suivantes :
Suivez les instructions de contrôle de compte d’utilisateur (UAC) Certaines Windows’application s’exécutent dans le contexte de sécurité d’un compte d’administrateur, et beaucoup nécessitent des droits d’utilisateur excessifs et des privilèges de Windows. Le contrôle de l’accès aux ressources permet aux utilisateurs de contrôler leurs systèmes contre les modifications indésirables (une modification indésirable peut être malveillante, telle qu’un rootkit qui prend furtivement la machine, ou une action de personnes disposant de privilèges limités, par exemple, un employé qui installe des logiciels interdits sur un ordinateur professionnel). La règle la plus importante pour contrôler l’accès aux ressources consiste à fournir le moins de contexte utilisateur standard d’accès nécessaire pour qu’un utilisateur effectue ses tâches nécessaires. Les instructions UAC suivantes fournissent aux applications les autorisations nécessaires si nécessaire, sans laisser le système constamment exposé aux risques de sécurité.
Pour plus d’informations, consultez les pages suivantes :
Installer dans les dossiers corrects par défaut Les utilisateurs doivent avoir une expérience cohérente et sécurisée avec l’emplacement d’installation par défaut des fichiers, tout en conservant l’option permettant d’installer une application à l’emplacement choisi. Il est également nécessaire de stocker des données d’application à l’emplacement approprié pour permettre à plusieurs personnes d’utiliser le même ordinateur sans endommager ni remplacer les données et les paramètres des autres. Pour plus d’informations, consultez résumé des exigences d’installation/désinstallation.
Prise en charge des sessions multi-utilisateurs Windows utilisateurs doivent pouvoir exécuter des sessions simultanées sans conflit ni interruption. Pour plus d’informations, consultez instructions de programmation des services Bureau à distance.
Prise en charge des versions x64 de Windows À mesure que le matériel 64 bits devient plus répandu, les utilisateurs s’attendent à ce que les développeurs d’applications tirent parti des avantages de l’architecture 64 bits en migrant leurs applications vers des versions 64 bits, ou que les versions 32 bits de l’application s’exécutent bien sous les versions 64 bits de Windows.

Voir aussi