Code 52 : signature du pilote non vérifiable

Windows refuse de démarrer un périphérique et affiche « Windows ne peut pas vérifier la signature numérique des pilotes requis pour ce périphérique ». Ce code 52 ne dit pas que le pilote est cassé : il dit que sa signature numérique ne tient pas debout aux yeux du système.

Points clés

• Le code 52 correspond au problème CM_PROB_UNSIGNED_DRIVER dans la liste officielle des messages du Gestionnaire de périphériques.
• Sur les versions 64 bits de Windows, la stratégie de signature en mode noyau impose une signature numérique valide pour qu’un pilote soit chargé.
• Depuis Windows 10 et Windows Server 2016, les pilotes en mode noyau doivent être signés via le tableau de bord matériel de Microsoft, avec un certificat à validation étendue.
• Depuis Windows 10 version 1507, les pilotes signés par ce tableau de bord le sont en SHA2. Les anciens binaires à double certificat issus d’une autorité tierce peuvent refuser de se charger.
• La bonne réponse est presque toujours un pilote récent et signé du constructeur, pas la désactivation de la vérification.

Ce que le code 52 mesure réellement

La signature de pilote associe une signature numérique à un paquet de pilote. Windows s’en sert à deux moments : à l’installation, pour vérifier l’intégrité du paquet et l’identité de l’éditeur, et au chargement, pour appliquer la stratégie de signature en mode noyau.

Un pilote peut donc être parfaitement fonctionnel et rester bloqué en code 52. Les cas typiques sont un paquet ancien dont la chaîne de certificats n’est plus acceptée, un fichier catalogue absent après une extraction manuelle, ou un binaire modifié après signature, ce qui invalide mécaniquement l’empreinte.

À noter pour les vieux matériels : dans la plupart des cas, un pilote non signé peut encore s’installer et se charger sur les versions 32 bits de Windows. La contrainte stricte concerne le 64 bits, donc l’immense majorité des postes en service.

Les causes qui reviennent

• Pilote trop ancien. Paquet signé à l’époque des certificats SHA1 ou des signatures croisées, plus acceptées au chargement.
• Paquet incomplet. Le fichier .cat qui porte les empreintes a été perdu lors d’une copie ou d’une extraction partielle.
• Fichier altéré. Téléchargement interrompu, archive réparée par un utilitaire, fichier .sys retouché : la signature ne correspond plus.
• Pilote hors catalogue officiel. Pilote de test, pilote communautaire, pilote repackagé par un site de téléchargement.
• Intégrité de la mémoire active. La protection de l’intégrité du code basée sur la virtualisation resserre les exigences de chargement des pilotes noyau.
• Pilote sur liste de blocage. Microsoft publie une liste de pilotes vulnérables bloqués, appliquée par le contrôle d’application.

Lire l’état de l’appareil avant d’agir

Ouvrez le menu Démarrer, recherchez « gestionnaire de périphériques » et sélectionnez le résultat. Cliquez avec le bouton droit sur l’appareil marqué, choisissez « Propriétés », puis lisez la zone « État du périphérique » : le message sur la signature numérique et le numéro de code s’y affichent. L’onglet « Détails » donne l’ID matériel du produit, et la valeur « Chemin d’accès à l’instance du périphérique » identifie l’appareil de façon unique.

Ces informations évitent une erreur classique, qui consiste à installer le pilote d’un modèle voisin. Sur un poste où plusieurs périphériques du même fabricant coexistent, seul l’ID matériel dit lequel est refusé.

Où télécharger un pilote signé

Deux ressources fiables existent, et une seule règle : le paquet doit venir de la chaîne officielle.

• Le site web du fabricant du composant. Recherchez la page d’assistance du produit, section pilotes, filtrez sur la version de Windows, puis lancez l’installation avec l’exécutable fourni.
• Windows Update. Dans les Paramètres, section Windows Update, ouvrez les options avancées puis les mises à jour facultatives : les pilotes proposés là sont signés.

Les dépôts de drivers génériques, les archives repackagées et les utilitaires de recherche automatique sortent de cette chaîne. Un install lancé depuis un paquet reconditionné produit exactement le message qui vous amène ici.

Solution 1 : récupérer un pilote signé récent

C’est la seule correction propre. Identifiez le modèle exact du composant dans l’onglet « Détails » des propriétés de l’appareil, valeur « ID matériel », puis cherchez ce pilote sur le site du fabricant du composant. Évitez les portails d’agrégation, qui redistribuent souvent des paquets reconditionnés dont la signature ne survit pas au reconditionnement.

Windows Update propose aussi des pilotes signés pour beaucoup de périphériques courants. La méthode complète figure dans notre guide pour mettre à jour les pilotes sous Windows 11 sans logiciel tiers.

Solution 2 : réinstaller le paquet au complet

Si vous avez installé le pilote en pointant un fichier .inf extrait à la main, refaites l’opération avec l’installeur complet du constructeur. Le .inf seul ne transporte pas le catalogue de signatures.

1. Gestionnaire de périphériques, clic droit sur l’appareil, « Désinstaller l’appareil », en cochant la suppression du pilote si la case apparaît.
2. Redémarrage.
3. Exécution de l’installeur téléchargé chez le fabricant, en tant qu’administrateur.

Solution 3 : purger l’ancien paquet du magasin de pilotes

Windows conserve les paquets installés dans son magasin de pilotes et peut réappliquer le paquet fautif tout seul. L’outil pnputil, fourni avec Windows, sert à le retirer.

1. Invite de commandes en tant qu’administrateur.
2. pnputil /enum-drivers pour lister les paquets tiers et repérer le nom publié, de la forme oem24.inf.
3. pnputil /delete-driver oem24.inf /uninstall pour le supprimer.
4. Redémarrage, puis installation du paquet signé.

Solution 4 : vérifier l’intégrité de la mémoire

La protection de l’intégrité du code basée sur la virtualisation, connue sous le nom d’intégrité de la mémoire ou HVCI, contrôle le code noyau autorisé à se charger. Un pilote ancien peut passer le contrôle classique et rester refusé dans ce mode. Le réglage se trouve dans la Sécurité Windows, section « Sécurité de l’appareil », puis « Isolation du noyau ».

Désactiver cette protection pour faire fonctionner un pilote abaisse le niveau de sécurité du poste. Traitez la manipulation comme un test de diagnostic, réactivez la protection ensuite et remplacez le pilote ou le matériel.

Solution 5 : le mode signature de test, pour une machine de test

Par défaut, Windows ne charge pas les pilotes en mode noyau signés pour test. L’option de configuration de démarrage TESTSIGNING lève cette règle, et son usage documenté est le développement de pilotes, pas la production.

Trois éléments à connaître avant d’y toucher, tous documentés par Microsoft :

• La commande s’exécute depuis une invite de commandes avec élévation, sous la forme Bcdedit.exe -set TESTSIGNING ON, et le redémarrage est obligatoire pour qu’elle prenne effet.
• Si la commande répond que la valeur est protégée par la stratégie de démarrage sécurisé, il faut désactiver le démarrage sécurisé dans le BIOS. BitLocker peut également empêcher la modification.
• Une fois le mode actif, Windows affiche en permanence un filigrane « Mode test » dans le coin inférieur droit du bureau. Chaque image de pilote doit malgré tout porter une signature numérique, mais le certificat n’a plus besoin de venir d’une autorité racine approuvée.

Depuis Windows 10 version 1507, avec l’intégrité de la mémoire activée, le binaire doit être signé avec un certificat de test auto-créé : un binaire réellement non signé n’est pas pris en charge. Pour revenir en arrière : Bcdedit.exe -set TESTSIGNING OFF puis redémarrage. Les conséquences d’une modification du démarrage sécurisé sont détaillées dans notre article sur le message Secure Boot Violation.

Après correction : contrôler l’état du périphérique

Une fois le pilote signé installé, revenez dans les propriétés de l’appareil et vérifiez que la zone d’état affiche « Ce périphérique fonctionne correctement ». Si le poste redémarre et que le message revient, l’ancien paquet est encore dans le magasin de pilotes : reprenez l’étape pnputil avant toute autre action.

• Contrôlez que l’option TESTSIGNING est bien sur OFF si vous l’avez utilisée en test, et que le filigrane a disparu.
• Réactivez l’intégrité de la mémoire dans les paramètres de sécurité Windows si vous l’aviez coupée.
• Remettez le démarrage sécurisé en service dans le BIOS, il fait partie des ressources de protection du démarrage.
• Sélectionnez dans l’Observateur d’événements le journal Système pour vérifier qu’aucun échec de chargement ne subsiste.

Sur un poste géré par un service informatique, la marche à suivre est différente : le contrôle d’application peut refuser le pilote par stratégie, et aucune manipulation locale ne passera outre. C’est alors au service qui gère le parc de valider le paquet.

Ce qu’il ne faut pas faire

Les recettes qui circulent proposent de neutraliser durablement la vérification de signature. Un poste dans cet état accepte n’importe quel code en mode noyau, c’est-à-dire au niveau de privilège le plus élevé du système. Microsoft maintient d’ailleurs une liste de pilotes vulnérables bloqués parce qu’ils servaient de porte d’entrée à des attaques, alors qu’ils étaient signés. Laisser tomber la vérification par confort revient à ouvrir cette porte volontairement.

Autre fausse piste : un utilitaire de mise à jour automatique de pilotes. Il pioche dans des dépôts de paquets reconditionnés, exactement la catégorie qui déclenche le code 52.

Quand ce n’est pas la signature

Vérifiez le code affiché avant de vous lancer. Le code 39 désigne un pilote corrompu ou manquant, le code 28 un pilote jamais installé, le code 19 une entrée de registre invalide, le code 31 un échec de chargement signalé par le système. Aucun de ces cas ne se règle avec une histoire de certificat.

Si le poste plante en plus d’afficher le code, recoupez avec l’Observateur d’événements pour savoir quel fichier .sys tente de se charger, et avec le guide des écrans bleus par code d’arrêt si un arrêt brutal suit le branchement.

Questions fréquentes

Peut-on installer un pilote non signé sur Windows 11 ?

Pas en respectant la stratégie de signature en mode noyau des versions 64 bits, qui exige une signature valide pour le chargement. Les contournements existent mais dégradent la sécurité du poste.

Le code 52 vient-il d’une mise à jour de Windows ?

Il apparaît souvent après une mise à niveau, parce que la nouvelle version applique des exigences de signature plus récentes à un pilote resté en place depuis des années.

Un vieux périphérique sans pilote signé est-il perdu ?

Sur un poste 64 bits moderne, il faut soit un pilote générique de classe fourni par Windows, soit un remplacement du matériel. Le mode signature de test n’est pas une solution durable.

Le registre garde-t-il une trace du pilote refusé ?

Oui, la clé du service pilote reste en place tant que le paquet n’est pas retiré du magasin de pilotes. Une raison de plus de passer par pnputil plutôt que de supprimer des fichiers à la main.

Comment savoir quel fichier pose problème ?

Le journal %SystemRoot%\Inf\setupapi.dev.log retrace les installations d’appareils et nomme les fichiers traités, ce qui permet d’isoler le binaire refusé.

Le filigrane « Mode test » disparaît-il tout seul ?

Non. Il reste affiché aussi longtemps que l’option TESTSIGNING est active, et disparaît après l’avoir remise sur OFF suivi d’un redémarrage.

_{Photo d’en-tête : disquette de pilotes d’un périphérique d’entrée, par Frettie, CC BY 3.0, via Wikimedia Commons. La photo illustre un support de pilote historique, sans lien avec un cas précis de code 52.
Sources : Messages d’erreur du Gestionnaire de périphériques, Signature du pilote et Activer le chargement des pilotes signés test, Microsoft Learn ; Protection de l’intégrité du code basée sur la virtualisation ; Règles de blocage de pilotes recommandées par Microsoft ; pnputil.}