WebView2 est-il le bon successeur du mode IE ? — La contrainte ActiveX et une conception de migration réaliste

Dans un article précédent, « Comment prolonger la durée de vie d’un système web interne dépendant du mode IE, et comment en sortir », j’ai écrit que le mode IE n’est qu’une mesure de survie à durée limitée, et qu’il fallait concevoir sa sortie en parallèle. Lorsque nous recevons des demandes de conseil sur cette « sortie », WebView2 revient très fréquemment sur la table. « Nous voulons afficher notre système web interne dans une application dédiée. » « Nous voulons construire uniquement un écran d’une application de bureau avec des technologies web. » « On m’a dit qu’Electron était lourd, existe-t-il une alternative ? » — dans chacun de ces cas, WebView2 s’impose comme une option.

WebView2 comporte cependant des particularités qu’il faut connaître avant de l’adopter : comment distribuer le runtime, où placer le dossier de données utilisateur, comment faire dialoguer le côté natif et le côté web. Et surtout, il existe une contrainte qui touche au cœur même de tout plan de migration : ActiveX, qui fonctionnait sous le mode IE, ne fonctionne pas dans WebView2. Cet article fait le tour de l’architecture de base de WebView2, de sa distribution, de sa conception, de sa sécurité, et de la manière dont il s’articule concrètement avec une sortie du mode IE.

1. L’essentiel d’abord

• WebView2 est un contrôle qui intègre Microsoft Edge, basé sur Chromium, dans une application Windows. Utilisable depuis WinForms, WPF, WinUI ou Win32 C++, il convient bien à l’ajout d’« un peu d’UI web » à une application de bureau existante.¹
• En règle générale, utilisez le runtime Evergreen (le runtime partagé à mise à jour automatique). Il est intégré en standard à Windows 11, mais la recommandation officielle est de ne pas présumer qu’« il doit déjà être là » et d’intégrer dans l’installateur une vérification de présence et un bootstrap.²
• Pour les environnements hors ligne ou les usines/lignes de production qui veulent figer une configuration validée, il existe Fixed Version (le runtime embarqué avec l’application), mais l’ensemble embarqué dépasse alors 250 Mo et vous devenez responsable de la diffusion des mises à jour de sécurité. Ne le choisissez pas à la légère.³
• Le premier piège classique est le dossier de données utilisateur (UDF). Par défaut, il est créé juste à côté de l’exe, ce qui fait échouer le démarrage d’une application installée sous Program Files. Faites de la spécification explicite d’un emplacement sous %LOCALAPPDATA% une pratique systématique.⁴
• Pour l’intégration native ↔ web, basez-vous par défaut sur l’échange de messages via PostWebMessageAsJson / WebMessageReceived, et réservez AddHostObjectToScript (l’exposition d’un objet COM) au contenu réellement digne de confiance.¹
• ActiveX ne fonctionne pas à l’intérieur de WebView2. Pour une page dépendante du mode IE qui utilise ActiveX, il est impossible de se contenter de « basculer sur WebView2 » : il faut concevoir le déplacement vers le côté natif du traitement qu’assurait ActiveX. C’est là le cœur même de tout plan de sortie du mode IE.⁵

2. L’architecture de base de WebView2

WebView2 se compose de deux éléments : le « SDK » (l’API que l’on intègre à l’application) et le « runtime » (l’environnement d’exécution basé sur Edge, installé sur le poste client). C’est la même logique que le runtime Visual C++ ou le runtime .NET : l’application se construit en référençant le paquet NuGet Microsoft.Web.WebView2, et à l’exécution, elle utilise le runtime présent sur le poste client.³

La prise en charge des plateformes est large : on peut l’utiliser depuis WinForms et WPF en .NET Framework 4.6.2+ / .NET Core 3.1+, depuis WinUI, ou depuis Win32 C++. Pouvoir convertir un seul écran d’une application métier WinForms existante vers WebView2 — une approche incrémentale — constitue un avantage majeur par rapport à un changement complet de framework (comme avec Electron). Pour le choix du framework d’UI lui-même, voir également « WinForms / WPF / WinUI — tableau de décision ».

Une intégration minimale ressemble au code ci-dessous (la même logique s’applique à WPF comme à WinForms).

var env = await CoreWebView2Environment.CreateAsync(
    browserExecutableFolder: null,   // Utiliser le runtime Evergreen
    userDataFolder: Path.Combine(
        Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
        "KomuraSoft", "MyApp", "WebView2"));
await webView.EnsureCoreWebView2Async(env);
webView.CoreWebView2.Navigate("https://internal.example.co.jp/app/");

Le point clé est que nous créons nous-mêmes CoreWebView2Environment plutôt que de nous fier aux valeurs par défaut. Les deux sections suivantes expliquent pourquoi.

La procédure de mise en place elle-même est simple ; pour WinForms / WPF, le déroulement est le suivant.

1. Ajouter Microsoft.Web.WebView2 au projet via NuGet (le contrôle WebView2 apparaît alors aussi dans la boîte à outils du concepteur)
2. Placer le contrôle sur le formulaire/la fenêtre
3. L’initialiser avec EnsureCoreWebView2Async, comme dans le code ci-dessus, puis appeler Navigate

Il y a ici un point d’attention au niveau de l’API qu’il faut absolument retenir dès le départ : webView.CoreWebView2 vaut null tant que l’initialisation n’est pas terminée. L’erreur classique consiste à essayer de s’abonner à un événement comme CoreWebView2.WebMessageReceived += ... dans le constructeur du formulaire et à obtenir une NullReferenceException ; la forme de base consiste à regrouper tout le traitement dépendant de l’initialisation « après l’await de EnsureCoreWebView2Async ». L’affectation à la propriété Source déclenche implicitement l’initialisation elle aussi, mais pour les applications qui doivent spécifier des paramètres d’environnement (comme l’emplacement de l’UDF), il est plus sûr de systématiser un appel explicite à EnsureCoreWebView2Async(env) en premier.

Par ailleurs, tous les événements de WebView2 se déclenchent sur le thread d’interface utilisateur. Si vous écrivez directement un traitement lourd (accès à un équipement, I/O de fichiers) dans WebMessageReceived, la réactivité du côté web se fige aussi par la même occasion ; faites donc passer le traitement côté natif par async/await. Les principes vus dans « Le thread d’interface utilisateur et async/await en WPF/WinForms » s’appliquent directement ici.

3. Distribution du runtime — Evergreen et Fixed Version

3.1 Evergreen (recommandé)

Evergreen est le modèle dans lequel toutes les applications WebView2 utilisent un unique runtime partagé installé sur le client, runtime qui se met à jour automatiquement. Microsoft le recommande explicitement, car les correctifs de sécurité s’appliquent automatiquement et la consommation disque reste faible.⁶

Trois points sont à surveiller en pratique.

• Mettez en place une vérification de présence. Le runtime est intégré en standard à Windows 11 et largement diffusé sur Windows 10 également, mais il reste des postes où il n’est pas présent. En .NET, on peut le vérifier avec CoreWebView2Environment.GetAvailableBrowserVersionString(), mais sur un environnement sans runtime installé, cet appel lui-même échoue avec une exception (WebView2RuntimeNotFoundException) ; enveloppez-le donc dans un try/catch, traitez « exception levée » comme « non installé », et intégrez à votre configuration l’exécution du bootstrapper (un petit installateur en ligne) ou de l’installateur autonome.²
• Concevez le suivi des mises à jour du runtime. Même lorsque le runtime est mis à jour, une application déjà en cours d’exécution continue d’utiliser l’ancienne version. Le schéma recommandé consiste à capter l’événement NewBrowserVersionAvailable et à mettre en place un parcours indiquant que « la mise à jour sera prise en compte au redémarrage ».²
• Alignez-vous sur la gouvernance de mise à jour interne à l’entreprise. La politique de mise à jour du navigateur Edge et celle du runtime WebView2 sont deux choses distinctes. Dans les environnements où la stratégie de groupe bloque les mises à jour du runtime, l’hypothèse d’Evergreen (la dernière version est présente) ne tient plus ; si vous utilisez des API récentes, ajoutez donc une détection de fonctionnalités.⁶

3.2 Fixed Version (usage limité)

Fixed Version consiste à embarquer une version spécifique du runtime avec l’application. Comme cela permet de figer une configuration dont le fonctionnement a été validé, c’est un choix raisonnable pour des équipements de production hors ligne ou des environnements soumis à une gestion des changements stricte. Cependant,

• les binaires embarqués dépassent 250 Mo, ce qui alourdit d’autant le livrable²
• le runtime ne se mettant pas à jour automatiquement, vous devenez responsable de la diffusion des correctifs de vulnérabilité du moteur de navigateur via vos propres versions
• négliger les mises à jour laisse perdurer dans l’entreprise « une application métier embarquant un vieux Chromium »

autant de coûts lourds. Ne choisissez cette option que si le contenu affiché est entièrement fermé et géré en interne, et que vous disposez d’un dispositif capable d’intégrer les mises à jour du runtime dans votre cycle de publication.

4. Le premier piège — le dossier de données utilisateur

WebView2 enregistre les cookies, le cache et les autorisations, entre autres, dans le dossier de données utilisateur (UDF). Si vous n’en précisez pas l’emplacement, il tente de le créer à l’emplacement par défaut (dans la plupart des configurations, juste à côté de l’exe), ce qui fait qu’une application installée sous Program Files échoue à y écrire et se heurte à une erreur d’initialisation. Cela fonctionne sur le poste de développement (exécution en débogage, dossier accessible en écriture) mais cesse de fonctionner dès l’installation — un bug classique qui « ne se révèle qu’une fois le logiciel distribué ».⁴

La parade est simple : comme dans l’exemple de code précédent, indiquez toujours explicitement un dossier dédié à l’application sous %LOCALAPPDATA%. Pensez également à intégrer les points suivants à votre conception :

• séparer l’UDF par utilisateur et par application (ne pas le partager entre plusieurs applications)
• ne pas le placer sur un lecteur réseau (cela provoque ralentissements, corruptions et pertes de données)⁴
• décider à l’avance de la procédure de suppression de l’UDF, lors de la désinstallation ou via une fonction « effacer les informations de connexion » (si les opérateurs ignorent que c’est là que subsistent les cookies et les données de site, cela peut être oublié lors, par exemple, du nettoyage du poste d’un salarié qui part)

Considérez ceci comme la version WebView2 du principe « ne pas écrire à côté de l’exe » présenté dans « Où stocker les données locales d’une application Windows métier — tableau de décision ».

5. Concevoir l’intégration native ↔ web

Ce qui fait de WebView2 bien plus qu’« un simple cadre de navigateur », c’est l’intégration bidirectionnelle entre le code natif et le contenu web. Il existe principalement deux mécanismes pour cela.¹

5.1 Les messages web (l’approche par défaut)

Le côté natif envoie du JSON via PostWebMessageAsJson, et le côté web le reçoit via window.chrome.webview.addEventListener("message", ...). Dans l’autre sens, ce sont window.chrome.webview.postMessage(...) et l’événement WebMessageReceived. C’est un couplage faible, et l’on peut inspecter en un seul endroit toutes les opérations exposées ; faites-en donc en priorité votre mécanisme d’intégration par défaut.

// Natif → Web
webView.CoreWebView2.PostWebMessageAsJson(
    JsonSerializer.Serialize(new { type = "deviceStatus", connected = true }));

// Web → Natif
webView.CoreWebView2.WebMessageReceived += (s, e) =>
{
    // Ignorer les messages ne provenant pas de l'origine attendue (par ex. après une navigation vers un site externe)
    if (!e.Source.StartsWith("https://internal.example.co.jp/", StringComparison.Ordinal))
        return;

    AppMessage? msg;
    try { msg = JsonSerializer.Deserialize<AppMessage>(e.WebMessageAsJson); }
    catch (JsonException) { msg = null; }
    if (msg?.Type is null)
        return;  // Rejeter ici les messages mal formés (journaliser si nécessaire)

    // N'exécuter que les opérations autorisées pour chaque type
};

Voici comment le côté web (JavaScript) le reçoit. Aucune bibliothèque spéciale n’est nécessaire : il suffit d’utiliser l’objet window.chrome.webview injecté par WebView2.

// Recevoir un message provenant du natif
window.chrome.webview.addEventListener("message", (e) => {
    if (e.data.type === "deviceStatus") {
        updateStatusBadge(e.data.connected);
    }
});

// Envoyer une requête vers le natif
document.getElementById("print-label").addEventListener("click", () => {
    window.chrome.webview.postMessage({ type: "printLabel", copies: 2 });
});

Côté réception, comme dans le code ci-dessus, vérifiez d’abord e.Source (l’URI de la page qui a envoyé le message), puis appliquez systématiquement la règle suivante : « valider le type du message par rapport à une liste blanche, et ignorer tout ce qui est inattendu en le journalisant ». Le côté web peut basculer vers un site externe à cause d’un seul lien ou d’une seule redirection, alors ne faites pas l’impasse sur la vérification de l’origine sous prétexte que « ce qui s’affiche en ce moment doit forcément être notre propre page ». À l’inverse, côté web également, prévoir un repli pour le cas où window.chrome.webview n’existe pas (lorsque la page est ouverte dans un navigateur ordinaire) permet de déboguer la partie UI web indépendamment dans un navigateur, ce qui améliore l’efficacité du développement.

5.2 Exposer des objets hôtes (puissant, mais à usage limité)

AddHostObjectToScript permet d’appeler directement un objet .NET/COM depuis JavaScript. Sous le capot, il s’agit du mécanisme COM, et il est amusant de voir la technologie COM, que nous manions depuis longtemps, encore bien vivante à cet endroit — mais confier directement un objet natif au contenu web signifie aussi que l’impact est d’autant plus important si cette page venait à être compromise. Réservez l’exposition au contenu que vous gérez vous-même, et limitez au strict nécessaire les méthodes exposées. Le principe est de ne jamais l’enregistrer sur un WebView susceptible d’afficher une page non fiable.

5.3 Charger du contenu local

Lorsque vous embarquez du HTML/JS dans l’application pour l’afficher, la pratique standard consiste à mapper un dossier à un nom d’hôte virtuel avec SetVirtualHostNameToFolderMapping, plutôt qu’une lecture directe via file://. Le contenu obtient ainsi une origine du type https://appassets.example/, ce qui permet d’utiliser normalement les API web qui présupposent une origine, comme localStorage, et de spécifier également le niveau d’autorisation d’accès cross-origin. Utilisez pour le nom d’hôte un domaine réservé qui ne peut pas exister réellement (comme .example), et commencez par le niveau d’accès minimal nécessaire (DenyCors en premier lieu).⁷

6. Sortir du mode IE avec WebView2 — ActiveX ne fonctionne pas

C’est la section la plus importante de cet article. Le mode IE parvient à survivre parce qu’un véritable IE11 (le moteur Trident) tourne à l’intérieur d’Edge, et que les contrôles ActiveX et les Browser Helper Objects fonctionnent exactement comme avant.⁵ WebView2, en revanche, est basé sur Chromium et ne dispose d’aucun mécanisme pour héberger ActiveX. Autrement dit,

« Basculer un système interne fonctionnant sous le mode IE vers une coquille construite avec WebView2 » ne fonctionne que pour les écrans qui ne dépendent pas d’ActiveX.

Il faut construire le plan de migration autour de cette contrainte. Un ordre de migration réaliste se présente ainsi :

1. Inventaire : classez les pages dépendantes du mode IE en « écrans utilisant une technologie propre à IE comme ActiveX » et « écrans simplement construits à l’ancienne » (l’inventaire par liste de sites décrit dans l’article sur le mode IE s’applique directement).
2. Écrans sans dépendance spécifique à IE : modernisez-les pour les navigateurs actuels, puis affichez-les dans Edge lui-même, ou intégrez-les dans une coquille WebView2 si vous souhaitez les intégrer à une application de poste métier.
3. Écrans dépendants d’ActiveX : redéfinissez l’architecture pour déplacer vers le côté natif (l’application hôte de WebView2) les fonctions qu’assurait ActiveX (communication série, accès aux fichiers, pilotage d’équipements dédiés, etc.) et les invoquer via des messages web. Imaginez cela comme le fait de retourner « ActiveX dans le navigateur » en « UI web dans l’application, plus traitement côté natif ».
4. La décision de conserver, d’encapsuler ou de remplacer ActiveX lui-même peut s’appuyer directement sur les critères du « Tableau de décision — conserver, encapsuler ou remplacer ActiveX/OCX ».

C’est précisément cette refonte du point 3 qui constitue la charge de travail réelle de l’adoption de WebView2, et il faut, dès la phase de planification, ajuster les attentes en conséquence : ce n’est pas aussi simple que « installer WebView2 permet de sortir du mode IE ». Inversement, une fois la conception qui déplace les fonctions d’ActiveX vers l’application hôte achevée, on obtient le meilleur des deux mondes : une UI plus facile à développer et à maintenir en interne avec des technologies web, et une distribution que l’on garde sous contrôle en tant qu’application de bureau.

7. Les questions d’implémentation systématiquement posées pour un système interne

Dès que l’on envisage d’adopter WebView2, certaines questions reviennent systématiquement du côté métier. En voici un tour d’horizon préventif.

7.1 Impression et rapports

L’exigence « avec IE, le bouton d’impression produisait le document » peut être satisfaite dans WebView2 via deux mécanismes.

• Imprimer l’écran tel quel : faire apparaître la boîte de dialogue d’impression avec CoreWebView2.ShowPrintUI(), ou imprimer sans intervention avec PrintAsync. C’est équivalent à l’impression d’un navigateur, si bien que les règles CSS d’impression (@media print) s’appliquent telles quelles.
• Générer un PDF : PrintToPdfAsync permet d’enregistrer la page actuellement affichée dans un fichier PDF. Pour un flux métier du type « enregistrer le document en PDF et le déposer dans un dossier partagé », cette option est plus adaptée, car le côté natif peut contrôler le nom de fichier et l’emplacement d’enregistrement.¹

Pour les documents qui exigent un alignement au pixel près, comme les formulaires en liasse autocopiante, envisagez aussi de vous rapprocher plutôt d’une sortie de rapport côté natif (les méthodes présentées dans « Comment construire une sortie de rapport Excel ») plutôt que de chercher à tout obtenir avec l’impression web.

7.2 Téléchargement et envoi de fichiers

Par défaut, le téléchargement fonctionne déjà comme dans un navigateur, mais pour une application métier, la pratique standard consiste à intervenir via l’événement DownloadStarting. Cela permet de fixer l’emplacement d’enregistrement, d’autoriser ou de refuser selon l’extension, ou de supprimer l’UI de téléchargement par défaut pour la remplacer par une notification côté application.¹ L’envoi de fichiers (<input type="file">) ouvre la boîte de dialogue de sélection de fichiers de l’OS sans implémentation particulière.

7.3 Authentification et SSO

Si le système web interne utilise l’authentification Windows intégrée (NTLM/Kerberos), cela passe globalement de la même façon dans WebView2 que dans un navigateur. Pour les anciens systèmes utilisant l’authentification de base (Basic), on peut fournir les identifiants via l’événement BasicAuthenticationRequested et se passer entièrement d’un écran de connexion — mais l’endroit où stocker ces identifiants relève précisément du sujet traité dans l’article sur DPAPI. Si vous souhaitez faire passer le SSO Microsoft Entra ID (l’ex-Azure AD) par les informations de connexion de l’OS, envisagez d’activer l’option d’environnement AllowSingleSignOnUsingOSPrimaryAccount.

Les cookies étant enregistrés dans l’UDF, l’état de connexion est conservé même après le redémarrage de l’application. Si vous souhaitez qu’une fonction de déconnexion efface la session de manière fiable, ajoutez une implémentation qui les supprime explicitement via CookieManager.

7.4 Débogage en développement

L’intérieur de WebView2 étant du Chromium, les DevTools de F12 restent utilisables tels quels pendant le développement (CoreWebView2Settings.AreDevToolsEnabled est activé par défaut). De plus, comme évoqué plus haut, si vous construisez le côté UI web pour qu’il « fonctionne aussi seul dans un navigateur », vous pouvez répartir le travail : développer et déboguer l’UI comme un développement web ordinaire, et ne vérifier l’intégration native que dans WebView2. Autrement dit, même une fois les actifs web enfermés dans l’application, l’expérience de développement reste celle du web.

8. Points clés de la conception de la sécurité

Une application WebView2 étant « une application avec un navigateur intégré », il faut la considérer avec un modèle de menace équivalent à celui d’un navigateur.

• Limiter le contenu affiché : dans NavigationStarting, vérifiez la destination par rapport à une liste blanche de domaines internes, et renvoyez toute URL inattendue vers le navigateur par défaut (traitez NewWindowRequested de la même façon).
• Restreindre les fonctionnalités qui franchissent une frontière de confiance : réduisez au minimum la portée des objets hôtes exposés et les opérations autorisées via les messages web. Il est également efficace de séparer un WebView susceptible d’afficher un site externe d’un WebView disposant d’une intégration native.
• Ajuster les fonctionnalités destinées aux utilisateurs selon l’environnement : CoreWebView2Settings permet de ne conserver que la part nécessaire de « comportement de navigateur ». Les restreindre sur les postes en kiosque ou sur le terrain réduit les incidents.
• Avec Fixed Version, assumer la responsabilité du plan de mise à jour : comme indiqué plus haut, la diffusion des correctifs de vulnérabilité devient la responsabilité de l’application.⁶

Voici les paramètres de CoreWebView2Settings les plus fréquemment ajustés. Il est recommandé d’inclure, dans la check-list précédant la publication, la décision à prendre pour la build de production.

Il ne s’agit pas tant, dans chaque cas, de dire que « désactiver rend sûr », mais plutôt d’outils permettant de « fermer toute entrée qui ne correspond pas aux opérations voulues par l’application ». Pour rehausser le niveau de sécurité des applications Windows en général, voir également « La check-list minimale de sécurité pour les applications Windows ».

9. Récapitulatif pour la décision d’adoption

Si vous avez « une application interne réservée à Windows et souhaitez une UI construite avec des technologies web », WebView2, plutôt qu’Electron, doit être votre choix par défaut. Le runtime pouvant être partagé avec l’OS, la distribution reste légère, et l’intégration avec des actifs .NET existants est directe.

10. Conclusion

WebView2 est une technologie qui permet d’intégrer, comme un composant, une UI web basée sur Chromium à une application Windows, et elle se prête bien à la modernisation des systèmes internes. Les points pratiques à retenir lors de l’adoption tiennent en trois éléments : vérifier la présence du runtime Evergreen et suivre ses mises à jour, spécifier explicitement le dossier de données utilisateur, et concevoir l’intégration en se basant par défaut sur les messages web. Et sur le plan de la planification, regarder en face la contrainte selon laquelle ActiveX ne fonctionne pas, et placer au centre de l’estimation de charge la refonte qui déplace les fonctionnalités d’ActiveX vers le côté natif.

Si, en gardant un œil sur l’échéance du mode IE, vous pensez qu’« il est temps d’envisager une sortie », le point de départ le plus solide consiste à commencer par l’inventaire du système concerné et la décomposition fonctionnelle de la partie dépendante d’ActiveX. Il y a, dans cette démarche, de nombreux points de jugement difficiles à trancher sans examiner la configuration réelle du système ; en cas de doute, n’hésitez pas à nous consulter.

Articles connexes

• Comment prolonger la durée de vie d’un système web interne dépendant du mode IE, et comment en sortir
• Faut-il conserver, encapsuler ou remplacer ActiveX/OCX ? — Tableau de décision
• Que sont COM, ActiveX et OCX ?
• WinForms / WPF / WinUI — comment choisir ? Tableau de décision

Domaines de conseil associés

KomuraSoft LLC assure le conseil sur la conception de sortie pour les systèmes internes dépendants du mode IE et d’ActiveX, la modernisation progressive à l’aide de WebView2, et l’intégration d’une UI web dans des applications Windows existantes.

• Valorisation et migration des actifs existants
• Remplacement d’applications Windows
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Les contrôles ActiveX fonctionnent-ils dans WebView2 ?

Non. Le mode IE fonctionne parce qu'un véritable IE11 (moteur Trident) tourne à l'intérieur d'Edge, ce qui permet à ActiveX de fonctionner tel quel, mais WebView2 est basé sur Chromium et ne dispose d'aucun mécanisme pour héberger ActiveX. Il n'est donc pas possible de se contenter de « basculer sur WebView2 » pour un écran dépendant d'ActiveX : il faut redéfinir l'architecture pour déplacer vers le côté natif (l'application hôte) les fonctions qu'assurait ActiveX — communication série, accès aux fichiers, pilotage d'équipements dédiés — et les invoquer via des messages web. C'est précisément cette refonte qui constitue la charge de travail réelle de l'adoption de WebView2.

Faut-il choisir le runtime WebView2 Evergreen ou Fixed Version ?

En règle générale, Evergreen (le runtime partagé à mise à jour automatique) : les correctifs de sécurité s'appliquent automatiquement et la consommation disque reste faible, ce qui explique la recommandation officielle claire en sa faveur. Il est intégré en standard à Windows 11, mais certains postes n'en disposent pas, d'où l'intérêt d'intégrer dans l'installateur une vérification de présence et une procédure de bootstrap. Fixed Version (le runtime embarqué avec l'application) fait dépasser 250 Mo à l'ensemble embarqué et vous rend responsable de la diffusion des correctifs de sécurité du moteur de navigateur via vos propres versions ; il ne doit donc être choisi que dans des cas limités, comme des équipements de production hors ligne ou des environnements soumis à une gestion des changements stricte.

Pourquoi mon application WebView2 ne démarre-t-elle pas une fois installée ?

Le premier piège classique est le problème du dossier de données utilisateur (UDF). WebView2 y enregistre les cookies, le cache et les autorisations, mais si vous n'en précisez pas l'emplacement, il tente par défaut d'en créer un juste à côté de l'exe, si bien qu'une application installée sous Program Files échoue à écrire et se heurte à une erreur d'initialisation. C'est le bug typique qui fonctionne sur le poste de développement mais cesse de fonctionner dès l'installation. La parade consiste à toujours indiquer explicitement, lors de la création de CoreWebView2Environment, un dossier dédié à l'application sous %LOCALAPPDATA%. Évitez également de le placer sur un lecteur réseau, ce qui provoque des ralentissements et des corruptions.

Comment le code natif et la page web communiquent-ils dans WebView2 ?

La base est une intégration faiblement couplée par messages web. Côté natif, on envoie du JSON via PostWebMessageAsJson, et côté web, on le reçoit via l'événement message de window.chrome.webview. Dans l'autre sens, ce sont postMessage et l'événement WebMessageReceived. Côté réception, il est important de vérifier l'URI d'origine avec e.Source, puis de valider le type du message par rapport à une liste blanche. Il existe aussi la méthode consistant à exposer directement un objet .NET/COM avec AddHostObjectToScript, mais comme l'impact est important si la page est compromise, il faut la réserver au contenu que vous gérez vous-même et réduire au strict minimum les méthodes exposées.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.