Pourquoi Windows affiche « Windows a protégé votre PC »

SmartScreen, signature de code, certificats EV/OV, distribution MSIX/Store : une mise au point du point de vue terrain

Lorsqu’on développe et distribue une application Windows, ce message est souvent le premier mur auquel on se heurte.

Windows a protégé votre PC
Microsoft Defender SmartScreen a empêché le démarrage d’une application non reconnue.

Face à cet avertissement, les utilisateurs s’inquiètent. Les développeurs aussi se posent des questions : « Ce n’est pas un virus, alors pourquoi est-il bloqué ? », « J’ai signé le code, alors pourquoi l’avertissement apparaît-il encore ? »

Cet article fait le point sur l’avertissement SmartScreen lors de la distribution d’applications Windows, sous l’angle de la signature de code, des certificats EV/OV, de MSIX, du Microsoft Store, de ClickOnce et de la distribution interne.

1. Cet article en une phrase

La signature de code est nécessaire pour distribuer une application Windows.
Mais la signature de code n’est pas une formule magique qui fait toujours disparaître l’avertissement SmartScreen.

Ce qui compte, c’est de distinguer trois angles.

Voici un repère de décision approximatif.

2. SmartScreen ne se limite pas à un « verdict antivirus »

Quand l’avertissement SmartScreen apparaît, les utilisateurs se demandent : « Cette application est-elle dangereuse ? »

Mais SmartScreen ne se contente pas de vérifier simplement s’il s’agit d’un virus. Selon les explications de Microsoft, pour les fichiers téléchargés, il examine principalement les informations de réputation suivantes.

Le point important ici est qu’un fichier tout juste créé n’a encore aucune réputation.

Même si l’application est légitime de votre point de vue, du point de vue de Windows, c’est « un fichier vu pour la première fois ». Même signé, l’avertissement SmartScreen peut apparaître tant que la réputation du hachage du fichier ou de l’éditeur n’est pas suffisante.

Autrement dit, l’avertissement SmartScreen est plus facile à comprendre formulé ainsi :

Cela ne signifie pas que le fichier a été déclaré comme un logiciel malveillant.
Cela signifie en revanche que Windows ne le juge pas encore suffisamment digne de confiance.

Sans comprendre cette nuance, on tombe dans des malentendus du type « je l’ai signé mais ça ne change rien » ou « j’ai acheté un certificat EV mais rien n’a changé ».

3. Ce que garantit réellement la signature de code

La signature de code garantit essentiellement deux choses.

1. Que le fichier a été signé par l’éditeur affiché
2. Que le fichier n’a pas été altéré depuis sa signature

À l’inverse, elle ne garantit pas directement les points suivants :

• Que l’application est absolument sûre
• Que l’application ne contient aucun bogue
• Que l’avertissement SmartScreen n’apparaîtra jamais
• Que la politique de l’entreprise l’autorisera systématiquement

Malgré cela, la signature de code est quasiment indispensable.

Sans signature, l’utilisateur ne peut pas identifier l’éditeur. Dans un environnement d’entreprise, un fichier non signé peut être bloqué par App Control, l’EDR, Defender, un proxy ou une passerelle de messagerie. Pour une mise à jour automatique, la signature devient également essentielle pour vérifier l’authenticité des fichiers de mise à jour.

Autrement dit, la signature de code ne sert pas seulement à « faire disparaître l’avertissement » : elle constitue le socle de la distribution, des mises à jour, des audits et de l’adoption en entreprise.

4. « Un certificat EV supprime l’avertissement dès le premier lancement » est une idée reçue dépassée

Il était autrefois largement admis qu’un certificat de signature de code EV bénéficiait d’un traitement favorable auprès de SmartScreen.

Mais aujourd’hui, acheter un certificat EV dans le seul but d’éviter SmartScreen est, au minimum, une décision risquée. Selon la documentation actuelle de Microsoft, le comportement par lequel un certificat EV évitait automatiquement l’avertissement SmartScreen au premier téléchargement a disparu. Un fichier signé avec un certificat EV doit désormais être considéré, tout comme avec un certificat OV, comme devant accumuler sa réputation.

Cela ne veut pas dire que le certificat EV n’a plus aucun intérêt.

• Une vérification d’identité plus stricte est valorisée dans les achats en entreprise
• L’audit de sécurité d’un partenaire commercial exige un certificat EV
• Vous possédez déjà un certificat EV et souhaitez continuer à l’utiliser

Si vous avez de telles raisons, il est légitime de l’utiliser.

En revanche, nous déconseillons d’acheter un certificat EV pour ce seul objectif :

Acheter un certificat EV parce qu’on veut que l’avertissement SmartScreen disparaisse dès le premier lancement

Si c’est votre objectif, il vaut mieux d’abord revoir le canal de distribution, la méthode de signature, la communication envers les premiers utilisateurs, la fréquence des mises à jour, et la possibilité de passer par le Store.

5. Les options de signature

Voici un panorama des options de signature et de distribution qui reviennent couramment dans la distribution d’applications Windows.

Microsoft Store / MSIX

Pour une distribution grand public, la première option à envisager est le Microsoft Store.

La combinaison de MSIX et de la distribution via le Store est particulièrement avantageuse en matière de gestion des certificats et d’avertissements SmartScreen. Un paquet MSIX soumis au Store est resigné par Microsoft, ce qui réduit aussi la charge que représente, pour le développeur, l’achat et le renouvellement individuels des certificats.

Cela dit, toutes les applications Windows ne se prêtent pas à MSIX.

• Utilisation intensive des services Windows
• Pilote requis
• Présence d’une extension shell (shell extension)
• Anciens enregistrements COM ou ressources ActiveX
• Modifications système complexes nécessaires à l’installation

Dans ces cas, un MSI ou un installateur traditionnel peut être plus naturel que MSIX.

Azure Artifact Signing

Azure Artifact Signing est un service de signature de code dans le cloud proposé par Microsoft. Il s’appelait auparavant Trusted Signing.

Son atout est de ne pas nécessiter de jeton USB physique et de s’intégrer facilement au CI/CD. C’est une option de signature solide pour la distribution hors Store, mais elle est soumise à des conditions de région et de compte.

Selon la documentation de Microsoft en 2026, les organisations éligibles se trouvent aux États-Unis, au Canada, dans l’UE et au Royaume-Uni, et les développeurs individuels éligibles aux États-Unis et au Canada. Si vous êtes une entreprise ou un particulier au Japon, vérifiez impérativement les conditions d’éligibilité. Si le service n’est pas utilisable, le certificat de signature de code OV traditionnel devient le candidat réaliste.

Par ailleurs, signer avec Azure Artifact Signing n’accorde pas instantanément la confiance de SmartScreen. Comme pour un certificat OV, la réputation s’accumule en fonction de l’historique de distribution.

Certificat de signature de code OV

Pour les développeurs et entreprises japonais qui distribuent une application Windows hors Store, le certificat de signature de code OV reste aujourd’hui un choix réaliste.

Avec un certificat OV, le nom de l’éditeur s’affiche à l’utilisateur. C’est clairement préférable à l’absence de signature. Cependant, l’avertissement SmartScreen peut encore apparaître pour une nouvelle application ou un nouveau fichier.

Voici les points à garder à l’esprit avec un certificat OV :

• Utiliser le nom d’éditeur de façon continue
• Signer à chaque fois en tant que même éditeur
• Ne pas modifier le fichier après la signature
• Ajouter un horodatage
• Vérifier non seulement l’EXE, mais aussi les DLL, le MSI et l’updater
• Préparer un plan de migration pour le renouvellement du certificat

Certificat auto-signé

Un certificat auto-signé est pratique pour le développement et les tests.

Mais il ne peut, en principe, pas être utilisé pour une distribution publique. Du point de vue du Windows de l’utilisateur, ce certificat n’est pas approuvé.

Un certificat auto-signé peut être utilisé dans des environnements comme ceux-ci :

• Le PC local du développeur
• L’environnement de test du testeur
• Des postes internes où un certificat de confiance peut être distribué via Intune ou la GPO
• Un environnement isolé où la configuration des postes est entièrement maîtrisée

Même en utilisant un certificat auto-signé, il faut gérer « quand le retirer », « qui l’a ajouté aux certificats de confiance » et « s’il risque de se retrouver mélangé à l’environnement de production ».

6. Que faut-il signer en pratique ?

« J’ai signé l’EXE, donc c’est terminé » n’est pas la bonne approche.

Dans la distribution d’applications Windows, il faut passer en revue l’ensemble des cibles de signature.

Avec SignTool, dans le Windows SDK actuel, les options /fd et /td sont importantes à préciser. On spécifie typiquement SHA256.

signtool sign /fd SHA256 /tr <timestamp-server-url> /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

Le point clé est de signer le livrable final.

Réécrire l’EXE après la signature, remplacer un fichier à l’intérieur d’un ZIP, ou modifier un fichier intégré après la création de l’installateur, peut casser la signature ou faire diverger le résultat de la vérification par rapport à ce qui est attendu.

Dans le pipeline de build, fixez cet ordre :

Build
  ↓
Collecte des fichiers dépendants
  ↓
Création de l'installateur / du paquet
  ↓
Signature
  ↓
Vérification de la signature
  ↓
Enregistrement du hachage
  ↓
Distribution

7. Réflexion par mode de distribution

Installateur MSI / EXE

Lorsqu’on distribue via un installateur MSI ou EXE, il faut impérativement signer le fichier que l’utilisateur exécute en premier.

Il faut en outre réexaminer comme cibles de signature les EXE et DLL déployés après l’installation. Même si seul l’installateur est signé, un updater ou un helper déployé ensuite mais non signé peut être bloqué dans un environnement d’entreprise.

Les points à considérer sont globalement fixés :

• Signer l’installateur lui-même
• Signer aussi les EXE/DLL qu’il contient
• Séparer les traitements nécessitant une élévation UAC
• Auditer séparément l’updater et les service helpers
• Stabiliser l’URL de la page de téléchargement
• Communiquer le nom de l’éditeur aux premiers utilisateurs

MSIX

MSIX est une méthode offrant une forte cohérence au niveau du paquet.

Si la distribution via le Store est possible, la gestion devient nettement plus simple du côté de l’avertissement SmartScreen et de la gestion des certificats. En revanche, pour le sideloading interne ou la distribution hors Store, il faut concevoir avec soin la signature du paquet MSIX et la confiance du certificat.

Voici les points à noter :

• L’auto-signature convient pour le développement et les tests
• Utiliser une méthode de signature publiquement approuvée pour la distribution en production
• Faire correspondre le Publisher de l’appxmanifest et le Subject du certificat
• Anticiper la possibilité d’un avertissement SmartScreen pour une distribution hors Store
• Vérifier à l’avance qu’il n’existe pas d’intégration OS peu adaptée à MSIX

ClickOnce

ClickOnce est pratique pour distribuer aux utilisateurs standard une application métier .NET (WinForms/WPF, etc.).

Cependant, ce n’est pas parce qu’on utilise ClickOnce que le problème SmartScreen disparaît. Le chemin par lequel l’utilisateur télécharge et lance l’application, la signature du manifeste, la source de distribution et les modifications de fichiers lors des mises à jour entrent tous en jeu.

Voici ce qu’il faut vérifier avec ClickOnce :

• La signature du manifeste d’application et du manifeste de déploiement
• La gestion de l’URL de la source de distribution ou du dossier partagé
• Le traitement du changement de certificat lors des mises à jour
• Si le proxy interne ou Defender risque de bloquer l’installation
• L’information des utilisateurs lors de la première installation

La force de ClickOnce est d’être « facile à distribuer », mais sans concevoir aussi la confiance de l’éditeur et le canal de distribution, cela se bloque sur le terrain.

Distribution xcopy / ZIP

Une distribution qui consiste juste à « déposer un dossier » ou « extraire un ZIP » est simple.

Elle peut être efficace en environnement isolé ou pour des outils internes. Mais pour une distribution web au grand public, c’est aussi la méthode la plus exposée à SmartScreen, à Defender et au Mark of the Web.

Si vous optez pour une distribution xcopy, voici ce qu’il faut absolument respecter :

• Signer les EXE/DLL
• Ne pas se fier au seul ZIP : vérifier les fichiers qu’il contient
• Fixer la source de distribution
• Indiquer clairement la version, le hachage et l’historique des mises à jour
• Si une mise à jour automatique est ajoutée après coup, y inclure la vérification de la signature

Plutôt que « c’est simple parce qu’on ne construit pas d’installateur », il faut considérer que « l’on assume soi-même les responsabilités que porterait un installateur ».

Updater maison

Un updater maison est pratique, mais il constitue à lui seul une frontière de sécurité.

L’updater récupère de nouveaux fichiers et remplace les fichiers existants. Il fonctionne parfois avec les privilèges administrateur. S’il est compromis, il est plus dangereux que l’application elle-même.

Vérifiez au minimum les points suivants :

• Signer les métadonnées de mise à jour
• Inclure dans les métadonnées la version, le hachage, la taille, le canal (channel) et la date d’expiration
• Vérifier le hachage et la signature après le téléchargement
• S’arrêter en mode fail-closed en cas d’échec de la vérification
• Prévoir une procédure de rollback
• Décider comment l’updater se met lui-même à jour
• Séparer la clé de signature de production de l’environnement de développement

Ce sujet est plus facile à comprendre en le mettant en parallèle avec notre article existant « Conception de la sécurité des mises à jour automatiques ».

8. Pour la distribution interne, SmartScreen seul ne suffit pas

Pour les applications internes, il existe une idée reçue fréquente :

C’est utilisé uniquement en interne, donc pas besoin de signer

C’est dangereux.

Dans un environnement interne, plusieurs mécanismes entrent en jeu, pas seulement SmartScreen.

En particulier dans un environnement utilisant App Control for Business, la question n’est pas seulement « est-ce signé », mais aussi « cet éditeur est-il autorisé », « est-ce passé par un managed installer » et « le hachage ou le chemin sont-ils autorisés ».

Le guide de déploiement de Microsoft présente lui aussi l’approche consistant à d’abord déployer les changements de politique App Control en mode audit, à vérifier que les événements de blocage correspondent aux attentes, puis à étendre progressivement au mode d’application forcée.

Pour une distribution interne, il est réaliste de concevoir dans cet ordre :

1. Segmenter les postes ciblés
   - Développeurs
   - Testeurs
   - Certains services
   - Toute l'entreprise

2. Décider le canal de distribution
   - Intune
   - GPO + partage de fichiers
   - Portail interne
   - VDI / RemoteApp
   - Distribution manuelle en environnement isolé

3. Décider les règles de confiance
   - Règles d'éditeur
   - Distribution des certificats
   - Managed installer
   - Autorisation par hachage
   - Autorisation par chemin

4. Vérifier en mode audit
   - Ce qui est bloqué
   - Quelles DLL ou quels helpers ont été oubliés
   - Si les mises à jour sont traitées comme des fichiers différents

5. Déployer par étapes
   - Distribuer à petite échelle
   - Observer les journaux
   - Ajuster les règles d'autorisation
   - Étendre

L’essentiel de la distribution interne n’est pas d’éviter SmartScreen, mais de rendre le canal de distribution explicable pour Windows.

9. Idées reçues courantes et façon de voir correcte

10. Comment informer les utilisateurs lors d’une sortie initiale

Pour une nouvelle application, l’avertissement SmartScreen peut apparaître pendant les premières semaines et pour les premiers utilisateurs.

Dans ce cas, il n’est pas bon de se contenter de dire aux utilisateurs « exécutez-la même si un avertissement apparaît ». Une explication sûre doit inclure les informations à vérifier.

Voici les éléments à inclure dans les instructions :

• L’URL de téléchargement officielle
• Le nom de l’éditeur qui s’affichera
• Le nom du fichier
• Le numéro de version
• La date de sortie
• Le hachage SHA-256 si nécessaire
• La méthode pour vérifier que le fichier est bien signé
• La consigne de ne pas exécuter un fichier obtenu par un canal inconnu

Par exemple, pour un usage interne, des instructions comme celles-ci sont sûres :

Cette application est distribuée uniquement depuis la page suivante du portail interne.
Vérifiez que le nom d'éditeur affiché est bien « XX Corporation ».
N'exécutez pas les fichiers EXE transmis en pièce jointe d'e-mail ou par messagerie instantanée.
Si un avertissement SmartScreen apparaît, partagez votre écran avec le service informatique.

Pour le grand public, privilégiez la distribution via le Microsoft Store, ou placez sur la page de téléchargement une explication permettant de vérifier l’éditeur.

11. Arbre de décision

Pour choisir un mode de distribution, réfléchir dans cet ordre réduit les hésitations.

flowchart TD
    A[Distribuer une application Windows] --> B{Pour le grand public ?}
    B -->|Oui| C{Peut-elle aller sur le Microsoft Store ?}
    C -->|Oui| D[Privilégier Store / MSIX]
    C -->|Non| E[Signer avec un certificat OV ou Artifact Signing]
    B -->|Non, usage interne| F{Y a-t-il une gestion des postes ?}
    F -->|Intune/GPO disponible| G[Signature + distribution des certificats + audit App Control]
    F -->|Non géré| H[Source de distribution fixe + signature + information des utilisateurs]
    E --> I[Prévoir des avertissements SmartScreen initiaux]
    G --> J[Déploiement par étapes à partir du mode audit]
    H --> J

Voici comment résumer les premiers choix en pratique.

12. Liste de contrôle minimale

Points à vérifier avant de publier et de distribuer une application Windows.

Signature

• L’EXE est signé
• Les DLL sont signées
• Le MSI ou l’EXE de l’installateur est signé
• L’updater est signé
• Un horodatage est appliqué
• Le fichier n’a pas été modifié après la signature
• Vérifié avec signtool verify

Distribution

• L’URL de distribution officielle est définie
• Le nom de l’éditeur est affiché sur la page de téléchargement
• Le numéro de version et la date de sortie sont affichés
• La possibilité d’un avertissement SmartScreen initial est anticipée
• La possibilité de passer par le Microsoft Store a été étudiée
• Pour une distribution hors Store, un certificat OV ou Artifact Signing a été envisagé

Mises à jour

• Les fichiers de mise à jour sont également signés
• Pour un updater maison, les métadonnées sont signées
• Le hachage, la taille et la version sont vérifiés
• En cas d’échec, l’arrêt se fait en mode fail-closed
• Une procédure de rollback existe

Distribution interne

• La présence d’Intune / GPO / App Control a été vérifiée
• La méthode de distribution des certificats a été définie
• Les événements de blocage ont été examinés en mode audit
• Le déploiement se fait par étapes, service par service
• Il a été vérifié que les mises à jour ne sont pas rebloquées

13. Conclusion

Une application Windows n’est pas terminée une fois construite : les fichiers distribués doivent se présenter sous une « forme digne de confiance » aux yeux de Windows, des utilisateurs et de la politique de l’entreprise.

Voici les points à retenir :

• SmartScreen examine la réputation des fichiers et des éditeurs
• La signature de code est nécessaire, mais ne garantit pas l’absence totale d’avertissement
• Ne choisissez pas le certificat EV pour éviter SmartScreen instantanément
• Pour une distribution grand public, envisagez d’abord le Microsoft Store / MSIX
• Pour une distribution hors Store, utilisez un certificat OV ou Artifact Signing en prévoyant des avertissements initiaux
• Pour une distribution interne, regardez au-delà de SmartScreen, jusqu’à Intune, la GPO et App Control
• Concevez l’updater non comme une fonction de distribution, mais comme la frontière de sécurité du produit

En une phrase :

Distribuer une application Windows n’est pas une question de « comment la déposer », mais la conception de « comment amener Windows à lui faire confiance ».

Articles connexes

• Guide de choix d’une méthode de distribution d’applications Windows
• Introduction à ClickOnce : distribution, mises à jour et critères de choix
• Conception de la sécurité des mises à jour automatiques
• Liste de contrôle de sécurité minimale pour le développement d’applications Windows
• Où les privilèges administrateur Windows sont-ils nécessaires, ou non
• Limites et pratique des applications Windows en binaire unique

Liens de référence

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi le message « Windows a protégé votre PC » apparaît-il ?

Parce que Microsoft Defender SmartScreen n'a pas encore jugé ce fichier suffisamment fiable. SmartScreen ne se contente pas d'un simple verdict antivirus : il examine la réputation de l'éditeur, la réputation du hachage du fichier, la présence ou non d'une signature, ainsi que le canal de distribution. Un fichier tout juste créé est, du point de vue de Windows, « un fichier vu pour la première fois » ; même signé, il peut donc déclencher un avertissement tant que sa réputation ne s'est pas accumulée. Cela ne signifie pas que le fichier a été déclaré comme un logiciel malveillant, mais bien que Windows ne le juge pas encore suffisamment digne de confiance.

La signature de code fait-elle disparaître l'avertissement SmartScreen ?

Pas forcément. La signature de code garantit seulement deux choses : que le fichier a été signé par l'éditeur affiché, et qu'il n'a pas été modifié depuis la signature ; elle ne garantit pas l'absence totale d'avertissement. Même signé, un fichier peut encore déclencher un avertissement tant que sa réputation, ou celle de son éditeur, n'est pas suffisante. Cela dit, la signature de code reste quasiment indispensable comme fondation pour la distribution, les mises à jour, les audits et l'adoption en entreprise. Sans elle, un environnement d'entreprise peut bloquer le fichier via App Control, l'EDR ou Defender.

Un certificat EV supprime-t-il l'avertissement SmartScreen dès le premier téléchargement ?

C'est une idée reçue dépassée. Selon la documentation actuelle de Microsoft, le comportement qui faisait éviter automatiquement l'avertissement SmartScreen au premier téléchargement avec un certificat EV a disparu ; un fichier signé avec un certificat EV doit désormais être considéré, comme avec un certificat OV, comme devant accumuler sa réputation. Un certificat EV garde du sens lorsque des exigences d'achat en entreprise ou l'audit de sécurité d'un partenaire l'imposent, mais acheter un certificat EV dans le seul but d'éviter SmartScreen n'est pas recommandé. Dans ce cas, il vaut mieux d'abord revoir le canal de distribution, la méthode de signature et la possibilité de passer par le Store.

Comment distribuer une application pour réduire les avertissements SmartScreen ?

Pour une large diffusion auprès du grand public, commencez par envisager le Microsoft Store / MSIX. Un paquet MSIX soumis au Store est resigné par Microsoft, ce qui en fait le canal le plus stable du point de vue de SmartScreen. Si le Store n'est pas envisageable, signez avec un certificat OV ou via Azure Artifact Signing, en partant du principe que des avertissements initiaux peuvent apparaître, et communiquez aux utilisateurs l'URL de téléchargement officielle, le nom de l'éditeur, la version et le hachage. Pour une distribution interne, il faut concevoir, en plus de la signature, tout le canal de distribution, y compris Intune, la Stratégie de groupe (GPO) et App Control.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.