Chrome Enterprise

Isolated Web Apps : quand la PWA ne suffit plus aux applications métier critiques

Les Isolated Web Apps ajoutent au web un bundle signé, une identité cryptographique et des API à haute confiance pour certains usages métier sur ChromeOS.

26 août 20267 min

Les Progressive Web Apps ont déjà fait beaucoup pour rapprocher le web de l’application installée : fonctionnement hors ligne, notifications, intégration au système et déploiement sans passer par un store.

Pour la grande majorité des usages, ce modèle reste le bon. Mais certaines applications métier demandent davantage : une version du code vérifiable, un accès direct au réseau local, l’intégration de périphériques sensibles ou un contrôle poussé du contenu tiers.

C’est précisément le terrain des Isolated Web Apps, ou IWA. Porté par Chromium, ce modèle ajoute au web une identité cryptographique, un packaging signé et des API dites « à haute confiance ».

Il ne s’agit pas d’une PWA 2.0 appelée à remplacer toutes les autres. Il s’agit d’une nouvelle catégorie, encore principalement destinée aux environnements ChromeOS administrés.

État de la plateforme au 2 septembre 2026.

L’IWA n’est pas une PWA 2.0

Google le dit assez clairement dans sa documentation : il faut conserver le modèle de confiance le plus simple possible. Si une PWA répond au besoin, mieux vaut rester sur une PWA.

Une application web classique conserve trois avantages difficiles à battre : elle est accessible depuis une simple URL, fonctionne sur de nombreuses plateformes et peut être mise à jour immédiatement côté serveur.

L’IWA accepte de renoncer à une partie de cette souplesse pour obtenir autre chose : une application empaquetée, signée, versionnée, isolée du web ouvert et autorisée à utiliser des capacités plus sensibles.

Elle vise donc moins le site métier amélioré que l’application critique exploitée dans un contexte maîtrisé : kiosque, poste ChromeOS administré, terminal industriel, solution de navigation contrôlée ou remplacement de certains usages autrefois couverts par les Chrome Apps.

Du domaine HTTPS à une identité cryptographique

Une PWA est servie depuis une origine HTTPS. Lorsque le TLS, le domaine et la chaîne de déploiement sont correctement protégés, le transport est sécurisé. Le vrai sujet n’est donc pas que la PWA serait naturellement exposée à une attaque de type homme-du-milieu.

La différence se trouve dans la manière d’identifier et de distribuer l’application.

Dans une PWA, le navigateur exécute la version actuellement fournie par le serveur et ses éventuels CDN. Dans une IWA, les ressources applicatives sont regroupées dans un Signed Web Bundle, généralement un fichier .swbn, puis signées par l’éditeur.

L’identifiant de l’application est dérivé de sa clé publique. Elle utilise une origine spécifique de la forme isolated-app://<identifiant>, indépendante du DNS et des autorités de certification HTTPS.

Chromium peut ainsi vérifier qu’une version complète du bundle provient bien de la clé attendue et qu’elle n’a pas été modifiée. Le JavaScript exécutable doit rester dans le bundle et une politique de sécurité stricte limite fortement l’exécution dynamique de code distant.

Cette signature apporte une provenance et une intégrité vérifiables. Elle ne garantit pas que l’application ne contient aucun bug ou aucune vulnérabilité. La cryptographie fait beaucoup de choses, mais elle ne bénit pas le code.

Direct Sockets : quand le web se met à parler TCP et UDP

Sur le web classique, les communications passent principalement par des protocoles et des API de haut niveau comme HTTP, WebSocket ou WebRTC. Une page web ne peut pas ouvrir librement un socket TCP ou UDP brut vers n’importe quel équipement.

Direct Sockets change cette limite pour les IWA autorisées. Une application peut établir des connexions TCP ou UDP directes, recevoir des datagrammes et, selon le cas, écouter des connexions entrantes comme un serveur local.

Les usages envisagés sont très concrets : client SSH ou terminal distant, communication avec une imprimante locale, pilotage d’équipements IoT, échange avec des systèmes anciens ou diffusion synchronisée de contenus sur un réseau de kiosques.

Dans certaines architectures, cela peut éviter le recours à un agent natif ou à une passerelle locale. Cela ne rend pas automatiquement chaque protocole compatible : il faut toujours l’implémenter correctement et déclarer les permissions nécessaires dans le manifeste de l’IWA.

Controlled Frame : afficher du contenu tiers sans lâcher le volant

L’élément <iframe> sait isoler du contenu tiers, mais il respecte les politiques d’intégration définies par les sites. De nombreux services interdisent ainsi leur affichage dans une iframe à l’aide de X-Frame-Options ou d’une Content Security Policy.

Réservé aux IWA, <controlledframe> peut charger du contenu qui refuserait une iframe classique. L’application hôte peut gérer la navigation, isoler les cookies et le stockage dans des partitions distinctes, traiter les demandes de permission ou d’ouverture de fenêtre, injecter du code contrôlé et observer, bloquer ou modifier certaines requêtes réseau.

Les cas d’usage vont de l’affichage pédagogique ou de la signalétique numérique à des consoles agrégeant plusieurs portails, en passant par des solutions de navigation sécurisée.

C’est une capacité puissante, donc sensible. Une IWA utilisant Controlled Frame doit agir comme un véritable intermédiaire de confiance, pas comme un super-navigateur bricolé pour contourner les règles des sites tiers.

Un modèle de déploiement pensé pour l’entreprise

Le déploiement de production documenté par Google reste aujourd’hui limité à ChromeOS administré : à partir de ChromeOS 128 pour les utilisateurs et navigateurs, 134 pour les kiosques et 140 pour les sessions invitées gérées.

Dans la console d’administration, l’administrateur renseigne l’identifiant du bundle et l’URL de son manifeste de mise à jour. L’application peut ensuite être installée de force, épinglée sur l’étagère ChromeOS, lancée à la connexion ou bloquée.

La politique IsolatedWebAppInstallForceList permet également de choisir un canal de mise à jour et d’épingler une version précise. C’est utile pour stopper un déploiement problématique ou maintenir une version validée, avec la prudence habituelle : épingler une version inexistante peut surtout produire une application très stable dans son immobilité.

Depuis ChromeOS 143, une liste d’autorisation — ou allowlist — contrôle les clés de signature autorisées à installer et mettre à jour une IWA via la console d’administration. Une application non approuvée peut encore être testée en mode développeur, mais elle ne peut pas être déployée normalement sur une flotte.

Le bon flag de test est chrome://flags/#enable-isolated-web-app-dev-mode, puis l’installation s’effectue depuis chrome://web-app-internals.

Depuis ChromeOS 150, les IWA peuvent aussi gagner en modularité grâce aux Sub Apps. Par défaut, l’ajout d’une sous-application demande la confirmation de l’utilisateur ; une politique d’entreprise peut autoriser certains éditeurs à s’en passer.

Côté matériel, la Web Smart Card API permet aux IWA déclarant la permission de communiquer avec des lecteurs de cartes à puce. Sur ChromeOS, les politiques peuvent autoriser ou bloquer cette connexion, et éventuellement supprimer l’invite utilisateur pour des applications précisément identifiées.

En revanche, WebUSB, WebHID et Web Serial ne sont pas des privilèges exclusifs aux IWA : ce sont des API du web dotées de leurs propres modèles d’autorisation. L’IWA apporte surtout un cadre de distribution et de gouvernance plus strict autour des capacités sensibles.

Et Windows ? Pas encore en production

La documentation publique de Google indique toujours que les IWA sont prises en charge uniquement sur ChromeOS pour les déploiements administrés. L’extension à d’autres systèmes fait partie de la trajectoire annoncée, mais elle ne doit pas encore être présentée comme une capacité disponible.

PWA ou IWA : le choix en pratique

Critère	PWA	Isolated Web App
Accès	URL accessible, installation optionnelle	Installation d’un bundle signé
Identité	Origine HTTPS liée au domaine	Web Bundle ID dérivé de la clé publique
Mises à jour	Déploiement immédiat côté serveur	Versions via un manifeste de mise à jour
Code exécutable	Chargé depuis l’origine	JavaScript embarqué dans le bundle signé
Réseau	HTTP, WebSocket et WebRTC	TCP et UDP via Direct Sockets
Contenu tiers	iframe soumise aux règles du site	Controlled Frame avec stockage partitionné
Déploiement	Large diffusion et nombreuses plateformes	ChromeOS administré, application allowlistée
Bon cas d’usage	Applications web courantes	Applications métier à haute confiance

Pour la majorité des applications, la PWA conserve donc l’avantage. Elle reste plus simple à diffuser, plus souple à faire évoluer et nettement plus universelle.

L’IWA mérite d’être étudiée lorsque l’application vise une flotte ChromeOS administrée, qu’une version signée et explicitement versionnée est nécessaire, ou que Direct Sockets, Controlled Frame et la Smart Card API sont réellement structurants.

Une technologie prometteuse, mais encore encadrée

L’IWA ouvre une voie intéressante entre l’application web et le logiciel natif. Elle permet de conserver HTML, CSS et JavaScript tout en adoptant un modèle de distribution plus proche d’une application empaquetée.

Mais elle n’est ni un standard grand public établi, ni le successeur automatique de la PWA. Son périmètre reste ciblé, son déploiement passe par l’administration ChromeOS et l’allowlist, et certaines API continuent d’évoluer au rythme des versions de Chrome.

La bonne question n’est donc pas : « Devons-nous transformer nos PWA en IWA ? »

Elle est plutôt : « Avons-nous un besoin suffisamment critique pour accepter moins d’ouverture en échange de davantage de contrôle ? »

Pour les kiosques, l’industrie, les environnements régulés ou certaines migrations de Chrome Apps, la réponse peut être oui. Pour le reste, la PWA n’a pas dit son dernier mot — et c’est probablement une très bonne nouvelle.