Wine 11.16 est sorti le vendredi vingt et un août 2026, et la nouveauté principale est le décodage vidéo accéléré par le matériel via VA-API. Les applications Windows exécutées sous Wine peuvent désormais confier le décodage vidéo Direct3D au GPU au lieu d'y consommer du processeur, ce qui compte pour tout ce qui lit de la vidéo dans un préfixe Wine. L'implémentation actuelle couvre H.264 et rien d'autre, donc H.265 et les codecs plus récents restent sur le chemin logiciel. À côté, Wine Mono passe à une version compatible ARM64 pour Apple Silicon et Linux ARM natif, la gestion des exceptions s'améliore sur ARM64EC, et 35 bogues connus se referment.
The short answer
Wine 11.16 est sorti le vendredi vingt et un août 2026. Un backend VA-API confie désormais le décodage vidéo Direct3D au GPU plutôt qu'au processeur, mais seulement pour H.264 dans cette version. Wine Mono passe à une version compatible ARM64 couvrant Apple Silicon et Linux ARM natif, la gestion des exceptions ARM64EC s'améliore, et 35 bogues se referment dont des échecs de lancement du client Steam et une régression WineWayland. C'est une version de développement sur la route vers Wine 12.0.
La lecture vidéo dans un préfixe Wine a toujours eu un côté légèrement absurde : un GPU inactif avec un bloc de décodage dédié, pendant qu'une application Windows décode du H.264 en logiciel sur le processeur parce que rien ne reliait les deux. Wine 11.16 les relie.
Le chemin de décodage, enfin
Le nouveau backend route les demandes de décodage vidéo Direct3D de Wine vers l'API d'accélération vidéo, l'interface standard sous Linux pour confier le décodage au matériel à fonction fixe du GPU. Quand une application Windows demande à Direct3D de décoder un flux, ce travail peut désormais atterrir sur le bloc de décodage au lieu des cœurs généralistes.
Le gain est réel et n'a rien de subtil sur du matériel modeste. Le décodage H.264 logiciel en 1080p représente une fraction notable d'un cœur, et à des résolutions ou des cadences plus élevées il devient la raison pour laquelle la lecture saccade. Le déporter vers du silicium à fonction fixe le rend presque gratuit et, sur un portable, réduit sensiblement la consommation.
La limite est énoncée clairement dans la version : le code, sous sa forme actuelle, ne prend en charge que le décodage H.264, pas H.265 ni les autres solutions. Tout le reste conserve le chemin logiciel et ne change pas.
C'est un point de départ sensé plutôt qu'une déception. H.264 bénéficie d'un décodage matériel sur pratiquement toutes les générations de GPU et tous les fournisseurs encore en service, ce qui en fait le codec que l'on implémente une fois et que l'on teste partout. Les codecs supplémentaires sont de la plomberie additionnelle à travers la même interface, pas une refonte.
Une exigence pratique : cela ne fonctionne que si l'hôte dispose d'un pilote VA-API opérationnel pour le GPU. Sur la plupart des systèmes il est déjà installé avec mesa ou le pilote média d'Intel, mais il vaut mieux le confirmer avec vainfo avant de conclure que le problème vient de Wine.
ARM64 continue d'avancer
Le travail ARM64 de cette version se décompose en deux volets, incrémentaux tous les deux, et à noter si vous utilisez Wine sur Apple Silicon ou sur du Linux ARM natif.
Wine Mono, qui fournit les API du framework .NET de Microsoft aux applications Windows sous Wine, passe à une version compatible ARM64. Auparavant, une application .NET Framework sur un hôte ARM devait passer par le chemin d'émulation x86 pour y accéder, ce qui est aussi rapide que cela en a l'air. Mono ARM64 natif retire une couche.
Par ailleurs, la gestion des exceptions s'améliore sur ARM64EC. C'est l'ABI de Microsoft qui permet à du code ARM64 natif et à du code x64 émulé de vivre dans un même processus Windows, et la gestion des exceptions à travers cette frontière est l'une des parties véritablement difficiles de son implémentation. Wine 11.15 avait fait avancer la prise en charge d'ARM64EC et 11.16 poursuit le même fil.
Aucun des deux n'est un chantier achevé. Ce sont plutôt les progrès réguliers qui finissent par faire de Wine sur ARM une évidence plutôt qu'une expérimentation.
La liste de bogues, et un mot sur les versions de développement
Trente-cinq bogues connus se referment. On y trouve des problèmes de lancement du client Steam, une régression du pilote WineWayland, un souci de curseur dans Star Citizen, des plantages d'applications WPF en x86, et des corrections touchant Adobe Creative Cloud, SteelSeries GG, Total Commander, Command and Conquer 3, Silhouette Studio, un logiciel Siemens Automation, regedit et quelques jeux anciens.
La régression WineWayland rappelle utilement ce qu'est une version de développement. Wine 11.16 se situe sur la route vers Wine 12.0 stable, et les versions de développement arrivent toutes les deux semaines avec du code qui n'a pas connu de période de stabilisation. Les régressions y apparaissent, sont signalées, et sont corrigées dans la suivante. Ce cycle est précisément l'intérêt de la chose.
Le conseil de mise à jour se scinde donc nettement. Si Wine exécute aujourd'hui l'application qui vous importe et que le nouveau chemin de décodage ne vous intéresse pas, restez où vous êtes. Si vous voulez le décodage VA-API, ou si vous travaillez sur ARM64, prenez la version de développement, et faites-le dans un préfixe séparé pour qu'une régression vous coûte un répertoire et non une installation qui fonctionnait.
Sources et pour aller plus loin
- Wine 11.16 sort avec le décodage matériel VA-API et une meilleure prise en charge ARM64, Phoronix, 21 août 2026
- Wine 11.16 ajoute le décodage vidéo matériel VA-API et Mono 11.3, Linuxiac, 21 août 2026
- Wine 11.16 apporte de nouvelles améliorations ARM64, GamingOnLinux, août 2026
Questions fréquentes
Que fait concrètement le backend VA-API ?
Il relie le chemin de décodage vidéo Direct3D de Wine à l'API d'accélération vidéo, l'interface standard sous Linux pour confier le décodage au GPU. Auparavant, une application Windows demandant à Direct3D de décoder un flux voyait ce travail effectué en logiciel sur le processeur. Avec 11.16, la demande peut être routée vers le bloc de décodage à fonction fixe du GPU. L'effet pratique est une consommation processeur plus faible pendant la lecture et, sur du matériel contraint, une lecture qui tient la cadence là où elle saccadait. Cela suppose un pilote VA-API fonctionnel pour votre GPU sur l'hôte, ce que fournissent en général les paquets mesa ou intel-media-driver.
Pourquoi seulement H.264 et pas H.265 ou AV1 ?
L'implémentation de cette version ne couvre que le décodage H.264. H.265, VP9, AV1 et les autres passent toujours par le chemin logiciel, donc une application Wine décodant ces codecs ne verra aucun changement de consommation processeur. C'est normal pour une première version d'un backend de décodage : H.264 est le codec le plus largement pris en charge par les blocs de décodage matériel toutes générations et tous fournisseurs confondus, ce qui en fait le point de départ raisonnable et le plus facile à tester largement. Les codecs supplémentaires relèvent de la même plomberie à étendre, pas d'une limite de conception.
Qu'est-ce qui change pour les utilisateurs ARM64 ?
Deux choses. Wine Mono, le moteur qui fournit les API du framework .NET de Microsoft aux applications Windows sous Wine, passe à une version compatible ARM64, ce qui couvre à la fois Apple Silicon et les systèmes Linux ARM natifs. C'est important car les applications .NET Framework devaient auparavant emprunter le chemin d'émulation x86 sur un hôte ARM. Par ailleurs, la gestion des exceptions s'améliore sur ARM64EC, l'ABI de Microsoft qui permet à du code ARM64 natif et à du code x64 émulé de cohabiter dans un même processus Windows. Les deux sont des étapes du travail ARM64 en cours dans Wine, pas des chantiers achevés.
Wine 11.16 est-il utilisable en production ?
Wine 11.16 est une version de développement sur la route vers Wine 12.0 stable, pas une version stable. Les versions de développement sortent toutes les deux semaines et embarquent du code qui n'a pas connu de période de stabilisation, ce qui explique précisément que des régressions comme le bogue du pilote WineWayland corrigé ici y apparaissent. Si vous utilisez Wine pour une application précise qui fonctionne aujourd'hui, rien ne justifie de quitter la branche stable. Si vous voulez le décodage VA-API, ou si vous testez ARM64, c'est là que cela se trouve, et garder un préfixe séparé pour cela est une assurance peu coûteuse.
Quelles applications sont corrigées dans cette version ?
Trente-cinq bogues connus se referment. Parmi ceux qui sont nommés : des problèmes de lancement du client Steam, une régression du pilote WineWayland, un souci de curseur dans Star Citizen, des plantages d'applications WPF en x86, ainsi que des corrections touchant Adobe Creative Cloud, SteelSeries GG, Total Commander, Command and Conquer 3, Silhouette Studio, un logiciel Siemens Automation, regedit et une série de jeux plus anciens. Comme toujours avec les compteurs de bogues Wine, refermé signifie que le symptôme précis signalé est résolu, pas que l'application est prise en charge de bout en bout.