Trois ans que cette clé USB Ventoy trainait dans mon tiroir, prête à dépanner n’importe quel PC en galère. Un firmware d’ordinateur portable a suffi à la rendre aveugle : plus aucun signe de vie après l’écran du logo constructeur, juste un curseur clignotant dans le vide. Le coupable n’était ni la clé, ni l’image ISO, mais la mise à jour UEFI que Windows avait installée la veille au soir sans me demander mon avis.
Ce genre de panne n’a rien d’un hasard isolé. Sur le forum communautaire d’Ubuntu, un utilisateur raconte exactement le même scénario : une notification de mise à jour du firmware UEFI, un redémarrage, et plus rien. Il avait reçu une notification indiquant que le firmware UEFI nécessitait une mise à jour, avait cliqué pour l’installer, puis avait reçu une autre notification demandant un redémarrage. Le système a figé au moment de démarrer. Ce qui change entre l’ancien et le nouveau firmware, c’est souvent bien plus qu’un simple numéro de version : c’est toute la table des périphériques de démarrage, les variables NVRAM, et parfois les clés de confiance Secure Boot qui sont réinitialisées ou renouvelées.
À retenir
- Un flash firmware réinitialise silencieusement l’ordre de démarrage et peut réactiver des protections que vous aviez désactivées
- 2026 marque le grand chantier de renouvellement des certificats Secure Boot Microsoft datant de 2011 — un changement qui affecte aussi Linux
- Trois paramètres UEFI à vérifier avant de réinstaller quoi que ce soit : Secure Boot, ordre de démarrage, et mode SATA/RAID
Ce que le firmware fait vraiment à votre séquence de boot
Un flash de BIOS ou d’UEFI ne se contente pas de corriger deux ou trois bugs discrets. Il peut remettre à zéro l’ordre de démarrage stocké dans la mémoire de la carte mère, effacer les entrées de boot personnalisées, ou modifier des réglages critiques comme le mode SATA. Un atelier de dépannage a documenté un cas concret en juillet 2026 : après un reset du BIOS, « vous avez réinitialisé le BIOS (Restore Defaults), remplacé la pile CMOS, ou mis à jour le firmware de votre PC… et au redémarrage, plus rien ». Dans l’immense majorité des cas, précise l’article, ce n’est ni le disque ni le système qui est en cause, mais une entrée de démarrage effacée dans la mémoire de la carte mère.
Une clé USB Linux souffre doublement de ce nettoyage. D’abord parce qu’elle dépend elle-même d’une entrée EFI (le fameux fichier bootx64.efi ou grubx64.efi) que le firmware peut ne plus détecter en priorité après reset. Ensuite parce que si votre BIOS a réactivé le Secure Boot par défaut, comme le font beaucoup de fabricants après un flash, le chargeur de démarrage shim doit être reconnu par une chaîne de confiance cryptographique intacte, faute de quoi l’UEFI refuse tout simplement de l’exécuter.
2026, l’année où Secure Boot change de dents
Le timing n’est pas anodin. Cette année marque justement le grand chantier de renouvellement des certificats Secure Boot, en place depuis 2011. Le CERT-FR a publié une alerte claire sur le sujet : quatre certificats de Microsoft, qui datent de 2011, ont une date d’expiration proche, trois expirant en juin 2026 et un en octobre 2026. Et surtout, ce n’est pas qu’une affaire Windows : ce besoin d’installation des nouveaux certificats concerne avant tout les systèmes Windows, mais aussi certains systèmes Linux qui démarrent en UEFI Secure Boot.
Concrètement, un shim signé avec l’ancienne autorité de certification qui n’aurait pas reçu la mise à jour de la liste de révocation (la fameuse dbx) peut se retrouver rejeté par un firmware fraîchement mis à jour, ou inversement, un firmware ancien peut ne plus faire confiance à un shim trop récent.
Microsoft a tenu à rassurer sur l’ampleur du phénomène. Sur son blog technique, l’entreprise confirme que les PC ne cesseront pas de démarrer après les échéances des 24 et 27 juin 2026, contrairement à certaines interprétations apparues ces derniers mois. Ce que la transition change surtout, c’est la capacité à recevoir de nouvelles mises à jour de sécurité du processus de boot, pas la capacité de démarrer tout court. Reste que certains constructeurs publient également des mises à jour du firmware UEFI en parallèle de ce chantier, et ce sont précisément ces flashs constructeur qui peuvent, en cascade, dérégler l’ordre de démarrage ou réactiver des protections que vous aviez sciemment désactivées pour faire tourner votre distribution préférée.
Remettre la clé sur les rails
Le réflexe qui sauve, avant même de rouvrir le boîtier ou de réinstaller quoi que ce soit, c’est de rentrer dans le menu UEFI (F2, Suppr ou F12 selon les marques) et de vérifier trois choses dans l’ordre. D’abord l’état du Secure Boot, qu’un flash a pu réactiver silencieusement. Ensuite l’ordre de démarrage, où la clé USB a pu être reléguée en dernière position voire disparaître de la liste. Enfin le mode de contrôleur de stockage, RAID contre AHCI, qui peut lui aussi revenir à sa valeur d’usine et masquer le disque interne comme la clé externe.
Si la clé reste invisible malgré tout, inutile de s’acharner sur le même support : régénérez-la avec l’outil officiel de votre distribution, l’image et le shim embarqués auront peut-être eux-mêmes été mis à jour entre-temps pour suivre la nouvelle chaîne de certificats. Et si le PC concerné a un système déjà installé qui refuse de booter après le flash, l’outil Boot-Repair reste la référence pour reconstruire une entrée EFI proprement, à condition de ne pas utiliser une version plus ancienne que 4ppa2088.
Un détail à garder en tête pour la suite : avec le renouvellement des certificats Secure Boot qui s’étale jusqu’en octobre 2026, mieux vaut désormais tester sa clé de secours tous les deux ou trois mois plutôt que de la laisser dormir trois ans dans un tiroir. Les images ISO des distributions majeures intègrent progressivement les nouvelles signatures, mais une clé gravée avant ce chantier peut très bien se retrouver du mauvais côté de la chaîne de confiance le jour où vous en aurez le plus besoin.
Sources : malekal.com | cert.ssi.gouv.fr