Microsoft suspend sans préavis les comptes développeurs de VeraCrypt et WireGuard
Microsoft suspend sans préavis les comptes développeurs de VeraCrypt et WireGuard :
des millions d'utilisateurs Windows face à un risque de blocage système dès juillet 2026
En résiliation silencieuse deux comptes développeurs critiques pour la chaîne d'approvisionnement logicielle de Windows, Microsoft a mis en péril la capacité de mise à jour de deux des outils de sécurité open source les plus utilisés au monde. L'affaire VeraCrypt/WireGuard expose crûment une dépendance structurelle que l'écosystème libre s'était longtemps refusé à regarder en face..
Fin mars 2026, les utilisateurs de VeraCrypt commençaient à s'inquiéter du silence prolongé de Mounir Idrassi, le développeur principal du logiciel. Basé au Japon, cet ingénieur maintient depuis des années VeraCrypt, l'héritier spirituel du légendaire TrueCrypt disparu en 2014, devenu la référence mondiale du chiffrement de disque sous licence libre. Sa disparition s'est finalement expliquée dans un message posté sur les forums SourceForge : Microsoft avait purement et simplement résilié le compte qu'il utilisait depuis des années pour signer les pilotes Windows et le chargeur d'amorçage de son logiciel.
« Je n'ai reçu aucun courriel de Microsoft, ni aucun avertissement préalable », a-t-il déclaré à 404 Media. La seule communication qu'il ait obtenue est un message lapidaire indiquant que son organisation « ne remplit pas actuellement les conditions requises pour passer la vérification » sans préciser lesquelles, et sans possibilité de recours. Idrassi a bien tenté de contacter le support Microsoft, mais n'a reçu en retour que des réponses automatisées qu'il soupçonne d'avoir été générées par une IA. « C'est frustrant, ils pourraient au moins expliquer ce qui ne va pas », a-t-il confié.
La conséquence est immédiate et brutale : les mises à jour Windows de VeraCrypt ne peuvent plus être publiées. Les versions Linux et macOS, elles, peuvent toujours être distribuées, mais Windows représente la plateforme majoritaire de ses utilisateurs.
VeraCrypt, héritier d'une longue histoire du chiffrement libre
Pour comprendre l'ampleur de ce qui est en jeu, il faut replacer VeraCrypt dans son contexte historique. En mai 2014, TrueCrypt, alors le standard incontesté du chiffrement de disque open source, avait cessé toute activité de manière aussi soudaine que mystérieuse. Ses développeurs, dont l'identité n'a jamais été pleinement établie, avaient publié un message énigmatique conseillant aux utilisateurs de migrer vers BitLocker, le concurrent propriétaire de Microsoft. La communauté avait alors unanimement soupçonné une pression des autorités, sans qu'aucune preuve concrète ne soit jamais apportée.
VeraCrypt était né de ces cendres. Mounir Idrassi avait repris le code source de TrueCrypt, corrigé les failles identifiées par deux audits de sécurité indépendants, et renforcé les algorithmes de chiffrement. Depuis, le logiciel est devenu la solution de référence pour qui souhaite chiffrer des partitions entières ou des volumes individuels sous Windows, Linux et macOS. Parmi ses fonctionnalités les plus remarquées figure la possibilité de créer un volume caché à l'intérieur d'un volume chiffré : si l'utilisateur est contraint de révéler son mot de passe, il peut divulguer un premier mot de passe donnant accès à des données anodines, tandis que les données réellement sensibles demeurent invisibles et indéchiffrables.
Ce profil d'utilisateurs (journalistes d'investigation, militants, lanceurs d'alerte, personnels médicaux ou juridiques soumis au secret professionnel, ainsi que toutes les entreprises soucieuses de protéger leur propriété intellectuelle) explique pourquoi une interruption des mises à jour de VeraCrypt n'est pas un simple désagrément technique. C'est un risque opérationnel pour des milliers de personnes dont la liberté ou la sécurité peut dépendre de la robustesse de leurs données chiffrées.
Une bombe à retardement pour les utilisateurs de VeraCrypt
Au-delà du blocage des mises à jour, la situation cache une menace encore plus grave pour les utilisateurs existants. Les appareils faisant tourner VeraCrypt pourraient bientôt ne plus démarrer : Microsoft va révoquer l'autorité de certification utilisée pour signer le chargeur d'amorçage de VeraCrypt, et une nouvelle signature basée sur une nouvelle autorité de certification Microsoft sera obligatoire pour les chargeurs d'amorçage à partir de juillet 2026. Or, sans accès au compte Partner Center, Idrassi est dans l'impossibilité d'effectuer cette mise à jour critique.
« Si le problème n'est pas résolu d'ici là, ce serait essentiellement une peine de mort pour VeraCrypt », a-t-il averti. Concrètement, des milliers d'utilisateurs qui ont activé le chiffrement intégral de leur disque système avec VeraCrypt risquent de se retrouver avec une machine qui refuse de s'allumer après la date fatidique. Pour un logiciel de sécurité conçu précisément pour protéger les données sensibles, l'ironie est cruelle.
WireGuard et Windscribe : l'incident n'est pas isolé
Si l'affaire VeraCrypt a d'abord semblé être un incident isolé, il est rapidement apparu qu'elle n'était que la partie visible d'un problème plus systémique. Jason Donenfeld, le créateur du protocole VPN open source WireGuard, a lui aussi découvert qu'il était bloqué en dehors de son compte développeur Microsoft, et se retrouve dans l'incapacité de signer des pilotes ou d'expédier des mises à jour pour les utilisateurs Windows. WireGuard n'est pas un projet obscur : c'est le protocole sur lequel s'appuient des services VPN commerciaux majeurs comme Proton VPN, Mullvad ou Tailscale, qui comptent plusieurs dizaines de millions d'utilisateurs.
« Aucun avertissement, aucune notification. Un jour, je me connecte pour publier une mise à jour, et boum, compte suspendu », a raconté Donenfeld. Il a tenté de passer par le processus de vérification d'identité mais malgré une confirmation de vérification réussie de la part du prestataire tiers mandaté par Microsoft, son accès est resté suspendu.
Windscribe, un autre fournisseur d'outils de confidentialité en ligne, a publié sur X qu'il avait été exclu du Partner Center après pourtant plus de huit ans de compte vérifié pour signer ses pilotes. « On essaie de résoudre ça depuis plus d'un mois, sans avancer. Le support est inexistant. Quelqu'un connaît un être humain doté d'un cerveau encore fonctionnel chez Microsoft ? »
Le programme de vérification des partenaires Windows : un coupable silencieux
La piste d'explication la plus solide est technique et administrative. Donenfeld a retrouvé une page sur le site de Microsoft indiquant que l'entreprise avait mené une « vérification obligatoire des comptes pour tous les partenaires du programme matériel Windows n'ayant pas complété leur vérification depuis avril 2024 ». Ce programme de vérification est depuis clos. Les développeurs qui n'ont pas soumis leurs documents dans les délais ont vu leurs comptes suspendus sans notification préalable, semble-t-il, ou du moins sans notification qui ait atteint ses destinataires.
Le programme Windows Hardware Program est le sésame indispensable pour tout développeur souhaitant distribuer des pilotes sur Windows. Cette infrastructure de signature de pilotes exige que les développeurs utilisent des comptes Partner Center vérifiés pour signer les pilotes au niveau du noyau. Sans signature valide, les systèmes Windows, en particulier ceux où le Secure Boot est activé, peuvent refuser de charger les pilotes ou déclencher des échecs au démarrage. Cette exigence existe pour de bonnes raisons de sécurité : les pilotes noyau accordent un accès quasi illimité au système d'exploitation, et sont régulièrement exploités par des acteurs malveillants.
Mais la manière dont Microsoft a géré (ou plutôt mal géré) cette transition met en lumière une faille béante dans la communication avec les développeurs tiers, en particulier ceux qui maintiennent des projets open source sans équipe dédiée aux relations avec les plateformes.
Secure Boot : bouclier de sécurité ou verrou commercial ?
L'affaire soulève une question plus profonde sur la nature même du Secure Boot et du contrôle que Microsoft exerce sur l'écosystème Windows. Introduit avec Windows 8 et l'avènement des firmwares UEFI, le Secure Boot a été présenté comme un rempart contre les bootkits, ces maliciels particulièrement redoutables qui s'installent avant le système d'exploitation et échappent aux antivirus classiques. Sur le principe, le mécanisme est solide : seuls les chargeurs d'amorçage signés par des autorités de certification reconnues par le firmware peuvent s'exécuter au démarrage.
Mais le corollaire de cette architecture est que Microsoft occupe, de facto, une position de gardien souverain de la chaîne de démarrage de l'écosystème PC sous Windows. Toute organisation souhaitant distribuer un logiciel qui intervient au niveau du chargeur d'amorçage ou des pilotes noyau doit obtenir et maintenir la bénédiction de Redmond. Pour les grandes entreprises disposant d'équipes juridiques et de relations institutionnelles avec Microsoft, ce processus est gérable. Pour un développeur indépendant comme Idrassi, ou même pour une équipe de taille réduite comme celle de WireGuard, c'est une dépendance existentielle à un processus administratif opaque et peu documenté.
Des voix s'élèvent dans la communauté pour rappeler qu'il existe des alternatives : un utilisateur peut théoriquement enrôler sa propre clé de signature dans le firmware UEFI de sa machine et signer lui-même ses logiciels, contournant ainsi la chaîne d'autorité de Microsoft. Mais cette solution, techniquement accessible aux professionnels avertis, est hors de portée de l'utilisateur moyen et inapplicable à grande échelle pour la distribution d'un logiciel grand public. Par ailleurs, de nombreuses entreprises imposent le Secure Boot en configuration verrouillée sur leurs flottes de machines, empêchant toute modification des clés UEFI.
La fragilité structurelle de la chaîne logicielle open source
Cette affaire dépasse largement le cas de deux logiciels. Elle pose une question de fond sur la dépendance des projets open source à l'égard des grandes plateformes propriétaires. Microsoft oblige les développeurs à créer un compte pour signer leurs logiciels sur Windows, puis se réserve le droit de fermer cet accès, affectant potentiellement des millions d'utilisateurs finaux qui n'ont rien à voir avec la décision. La chaîne d'approvisionnement logicielle est un angle mort de la sécurité informatique depuis que l'attaque SolarWinds, en 2020, puis la faille Log4Shell, en 2021, ont montré à quel point des projets critiques pouvaient être compromis ou rendus inopérants en un seul point de défaillance. Ici, ce point de défaillance n'est pas une vulnérabilité technique mais une décision administrative opaque prise par une entreprise privée, sans transparence, sans recours, et avec un support client réduit à des automates.
Les signatures existantes liées aux comptes révoqués devraient expirer dès la fin juin 2026. Une fois expirées, les systèmes qui dépendent de ces pilotes pourraient connaître des pannes ou nécessiter des contournements manuels, exposant potentiellement les utilisateurs à des risques de sécurité ou à des interruptions opérationnelles. Côté communautaire, les réactions sur les forums spécialisés ont été vives. Certains y voient un signe supplémentaire que les projets libres critiques ne devraient pas confier leur capacité de distribution à des plateformes fermées. D'autres s'interrogent sur des motivations plus sombres.
Ce que les utilisateurs peuvent faire dès maintenant
Face à l'incertitude, plusieurs précautions s'imposent pour les utilisateurs de VeraCrypt sous Windows. La première est de ne pas mettre à jour précipitamment en espérant qu'une version corrigée arrivera à temps : la version actuellement installée continue de fonctionner normalement jusqu'à l'échéance de juillet 2026. La seconde est de surveiller de près les annonces officielles sur les forums SourceForge et le dépôt GitHub de VeraCrypt, où Idrassi communique directement.
Pour les utilisateurs qui ont chiffré leur partition système, le risque de blocage au démarrage est réel. Une sauvegarde complète du disque via un outil externe, avant l'échéance, est fortement recommandée. Les utilisateurs qui n'ont chiffré que des volumes de données (et non la partition système) sont moins exposés à court terme, les pilotes concernés par l'expiration des certificats étant principalement ceux liés au chargeur d'amorçage.
Pour WireGuard, la situation est différente : les signatures actuelles des pilotes restent valides pour les versions déjà installées, et l'urgence concerne davantage la capacité de Donenfeld à livrer des correctifs de sécurité futurs. Comme il l'a lui-même résumé : si une vulnérabilité critique était découverte dans WireGuard aujourd'hui, les utilisateurs Windows seraient totalement exposés dans l'attente d'une résolution.
Une réaction tardive, mais une résolution en cours
La pression médiatique et la viralité des posts sur X ont finalement contraint Microsoft à sortir du silence. Le vice-président de Microsoft Scott Hanselman est intervenu publiquement sur X pour expliquer que les comptes avaient été automatiquement suspendus dans le cadre du programme de vérification obligatoire du Windows Hardware Program, et que Microsoft envoyait des courriels à ce sujet depuis octobre 2025. Il a qualifié la situation de « simple formalité administrative » et indiqué que des corrections étaient en cours.
Selon la documentation publiée par Microsoft le 1er octobre dernier, le processus de vérification avait débuté le 16 octobre et déclenchait une suspension automatique du Windows Hardware Program pour les partenaires n'ayant pas complété la procédure dans les 30 jours. « La vérification des comptes pour le programme matériel Windows est désormais terminée. Les comptes qui n'ont pas complété avec succès la vérification et qui ont reçu un statut de vérification rejeté ont été suspendus du programme matériel Windows, et les soumissions de ces comptes ne sont plus autorisées », précise une mise à jour du 30 mars.
Hanselman a personnellement contacté Jason Donenfeld et Mounir Idrassi, et a indiqué que les problèmes étaient « en cours de résolution ». Ce dénouement, aussi soulageant soit-il, ne résout pas le problème de fond : pourquoi des développeurs de projets aussi visibles et critiques n'ont-ils pas reçu de notifications efficaces pendant des mois ? MemTest86, l'outil de diagnostic mémoire vénérable lui aussi utilisé par des millions de techniciens, figurait également parmi les projets affectés. L'intervention d'un vice-président ne devrait pas être le seul mécanisme de déblocage disponible pour des mainteneurs de logiciels libres critiques.
Sources : SourceForge, entretien avec le développeur principal de VeraCrypt, WindScribe
Et vous ?
La dépendance des logiciels open source critiques à l'infrastructure de signature Microsoft est-elle un risque systémique sous-estimé ? Que se passerait-il si le même scénario touchait simultanément une dizaine de projets de sécurité ?
Voir aussi :
Répondre avec citation
Partager