La mise à jour .NET de Microsoft a cassé l'impression. Voici la vraie leçon

WPF (Windows Presentation Foundation) est un framework développé par Microsoft pour créer des applications de bureau sous Windows, basé sur le .NET Framework. Les applications WPF courantes incluent des ERP Windows ainsi que des logiciels de comptabilité, de logistique, d'ingénierie, d'administration et d'autres applications métier. WPF est particulièrement présent dans les logiciels d'entreprise développés sur .NET Framework depuis de nombreuses années.

Les applications qui génèrent des rapports, des étiquettes, des factures ou d'autres documents à imprimer — en particulier les systèmes ERP, POS et de gestion d'entrepôt qui impriment via Windows — sont à vérifier en priorité. La mise à jour cumulative d'août 2026 du .NET Framework de Microsoft fait échouer certaines applications WPF lors de l'impression ou de la génération de fichiers PDF/XPS avec certaines polices, dont Calibri, comme The Register l'a rapporté en premier. Si votre équipe a déployé cette mise à jour et que des erreurs d'impression sont soudainement apparues, c'est probablement la cause.

Ce qui a réellement posé problème

Les mises à jour du .NET Framework du 11 août de Microsoft provoquent dans certaines applications WPF une System.IO.FileFormatException. Elle survient lors de l'impression ou de la génération de fichiers PDF/XPS et est liée à la manière dont certaines polices sont traitées, notamment Calibri, la police par défaut de Word depuis 2007. Le bogue affecte Windows 10, Windows 11 et toutes les versions prises en charge de Windows Server de 2012 à 2025, ce qui représente une large surface d'impact pour un problème de rendu des polices.

Le correctif proposé par Microsoft consiste en une bascule dans un fichier de configuration : Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection. Cette protection a été ajoutée dans la mise à jour d'août pour corriger une faille de sécurité. La désactiver pour résoudre les problèmes d'impression revient à annuler un correctif déployé volontairement quelques jours plus tôt. Microsoft le reconnaît dans ses recommandations : il s'agit d'une mesure temporaire qui réexpose les systèmes aux vulnérabilités que la mise à jour visait à corriger.

Microsoft indique que l'enquête est toujours en cours. Aucun calendrier n'a encore été annoncé pour un correctif définitif.

Ce que cela signifie si vous déployez les correctifs

Si vos utilisateurs rencontrent ce problème, activer la bascule de configuration de Microsoft (ci‑dessous) leur permettra d'imprimer à nouveau en désactivant la nouvelle protection du traitement des polices. Il s'agit d'un recul en matière de sécurité, selon Microsoft lui‑même, et cette mesure doit rester temporaire. Si vous choisissez cette option, consignez les machines concernées afin de retirer la bascule dès qu'un correctif définitif sera publié.

Solution rapide. Ajoutez ceci au fichier de configuration de l'application concernée, sous <runtime>. Il s'agit d'un paramètre par application et non à l'échelle de la machine : si l'application possède déjà une section <runtime>, ajoutez cette ligne à cette section plutôt que de remplacer le fichier :

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection=true"/>
  </runtime>
</configuration>

Il s'agit moins de ce bug ponctuel que de la place que l'impression occupe dans votre environnement. Chaque fois que l'impression dépend de la pile Windows complète (pilotes, spouleur d'impression, .NET, WPF, et tout ce qu'une application donnée peut utiliser), elle hérite de tous les risques liés aux correctifs de cette pile, qu'ils concernent l'impression ou non.

Construisez une solution d'impression indépendante de Windows

Ce bug se situe dans l'application WPF elle‑même, avant qu'une tâche d'impression n'atteigne quoi que ce soit en aval — ezeep inclus. Cela reste vrai, même après plus de 25 ans d'expérience dans l'impression d'entreprise. Ce cas s'inscrit dans un mouvement plus large de modifications de la pile d'impression Windows engagé par Microsoft depuis Windows Protected Print. C'est une raison de faire le point sur ce qui s'imprime au sein de votre organisation et sur la manière dont cela se fait, puis de réduire les dépendances au système Windows partout où l'application le permet.

Pour les applications WPF en particulier, ce bug montre exactement où se situe le risque. WPF intègre son propre pipeline d'impression (PrintDialog, FixedDocument, XpsDocument) qui rend le contenu et génère l'impression ou le PDF en une seule étape. C'est la voie de moindre résistance pour un développeur : aucune bibliothèque supplémentaire à ajouter, et cela fonctionne immédiatement. Et c'est précisément ce code qui s'est avéré défaillant.

Générer ce rendu avec une bibliothèque PDF distincte — qui n'interagit jamais avec le sous‑ensemble de polices ni le moteur de rendu propres à WPF — supprime la dépendance à ce code spécifique. Combinez cela avec l'API d'ezeep (ou son MCP server, pour les applications développées avec des outils de développement assistés par IA) pour gérer l'impression, et l'application cesse de dépendre de la pile d'impression Windows en général, et pas seulement de ce bug : les étiquettes d'entrepôt peuvent s'imprimer directement à partir d'événements de commande, les factures depuis un logiciel de comptabilité, et les rapports selon un calendrier, le tout sans utilisateur connecté ni boîte de dialogue d'impression.

Cela ne résoudra pas les problèmes des machines qui exécutent déjà la mise à jour défaillante. C'est un argument pour concevoir la prochaine version de l'application de sorte que le prochain bug de la pile d'impression Windows ne soit pas non plus votre problème.