Pendant longtemps, la distinction semblait évidente : d'un côté les applications natives, installées sur le système d'exploitation, capables d'accéder aux ressources matérielles, de fonctionner hors ligne et d'offrir des performances dignes d'un logiciel professionnel ; de l'autre, les sites web, cantonnés à afficher des pages dans une fenêtre isolée, prisonniers d'un modèle réseau omniprésent et d'un bac à sable sécuritaire strict. Cette frontière, pourtant si nette dans l'imaginaire collectif des développeurs, est aujourd'hui en train de s'effacer à une vitesse que peu d'observateurs avaient anticipée. Les navigateurs modernes ne sont plus de simples lecteurs de documents hypertextes : ils sont devenus des plateformes d'exécution à part entière, capables d'héberger des logiciels de montage vidéo, des outils de conception graphique en 3D, des environnements de développement complets, ou encore des applications de traitement du signal en temps réel.
Ce basculement n'est pas le fruit d'une seule innovation décisive mais d'un empilement méthodique de nouvelles API standardisées, proposées par le W3C et les éditeurs de navigateurs, qui donnent progressivement aux développeurs web accès à des couches système autrefois réservées aux programmes installés localement. Comprendre ces API, leurs usages concrets et leurs implications — techniques, économiques et éthiques — est devenu une nécessité pour quiconque s'intéresse à l'évolution du web professionnel.
De simples fenêtres à de véritables systèmes d'exploitation légers
L'histoire des navigateurs est celle d'une conquête progressive de territoire. Dans les années 1990, Mosaic puis Netscape affichaient du texte enrichi et quelques images. Dans les années 2000, l'émergence de JavaScript a rendu les pages dynamiques. La décennie suivante a vu l'explosion des applications web monopage, avec des frameworks comme Angular, React ou Vue, qui ont permis de construire des interfaces complexes tout en restant dans le navigateur. Mais ces avancées restaient fondamentalement limitées par le bac à sable : pas d'accès au système de fichiers, pas de communication avec les périphériques USB ou Bluetooth, pas de calcul GPU, pas d'exécution de code natif à haute performance.
Aujourd'hui, ce paradigme est profondément remis en question. Chrome, Firefox, Safari et Edge implémentent désormais des dizaines d'API expérimentales ou stabilisées qui ouvrent des portes autrefois fermées. Les Progressive Web Apps (PWA) en sont l'illustration la plus connue du grand public, mais elles ne représentent que la surface visible d'un iceberg technologique beaucoup plus profond. Sous cette surface, des API comme WebAssembly, WebGPU, la File System Access API, Web Bluetooth, Web Serial ou encore l'Origin Private File System redessinent en profondeur ce qu'il est possible de faire dans un onglet de navigateur.
« Le navigateur est en train de devenir le système d'exploitation universel que certains appelaient de leurs vœux depuis les années 2000. Sauf que cette fois, les briques techniques sont là. » — extrait d'une conférence technique au Web Summit 2025
WebAssembly : la promesse de la performance native enfin tenue
Si l'on devait désigner une technologie comme le moteur principal de cette révolution silencieuse, ce serait sans doute WebAssembly, abrégé Wasm. Standardisé en 2019 et désormais supporté par tous les navigateurs majeurs, WebAssembly est un format binaire d'instructions qui s'exécute dans le navigateur à une vitesse proche de celle du code natif compilé. Contrairement à JavaScript, qui doit être interprété et optimisé à la volée par le moteur du navigateur, WebAssembly est conçu pour être décodé et exécuté de manière extrêmement rapide, avec une consommation mémoire prévisible et un modèle de sécurité robuste.
Les conséquences pratiques sont considérables. Des logiciels comme Figma ont utilisé WebAssembly pour porter leur moteur de rendu C++ directement dans le navigateur, offrant des performances comparables à celles d'une application desktop. Des outils de montage vidéo entièrement en ligne, des environnements de développement intégrés comme VS Code for the Web, des émulateurs de systèmes d'exploitation anciens, des moteurs de jeu complets : tous exploitent WebAssembly pour atteindre un niveau de performance que JavaScript seul ne pourrait jamais garantir.
Ce qui rend WebAssembly particulièrement stratégique, c'est sa neutralité vis-à-vis des langages de programmation. Il n'est pas lié à JavaScript : on peut compiler vers Wasm du code écrit en C, C++, Rust, Go, Python, ou encore AssemblyScript. Cela signifie que des années de code métier écrit dans des langages système peuvent être réutilisées directement sur le web, sans réécriture laborieuse. Pour les éditeurs de logiciels professionnels, c'est une ouverture économique majeure : porter une application sur le web ne nécessite plus de tout repenser, mais simplement de compiler vers une nouvelle cible.
Les développements en cours autour de WASI (WebAssembly System Interface) et des composants Wasm ouvrent même la voie à une portabilité universelle des modules logiciels, au-delà du seul navigateur, vers les environnements serverless, les appareils embarqués ou les services cloud. Le navigateur n'est alors plus qu'un hôte parmi d'autres pour un même binaire universel.
WebGPU : le calcul graphique et scientifique s'invite dans l'onglet
Si WebAssembly s'attaque aux performances de calcul général, WebGPU représente une révolution dans un domaine encore plus spécialisé : l'accès direct au processeur graphique depuis le navigateur. Son prédécesseur, WebGL, permettait déjà de faire du rendu 3D en ligne, mais il était fondé sur une API ancienne (OpenGL ES) qui ne tirait pas parti des capacités des GPU modernes. WebGPU, lui, est conçu dès le départ pour fonctionner avec les API graphiques de nouvelle génération — Vulkan, Metal, Direct3D 12 — et expose non seulement le rendu 3D mais aussi le compute shading, c'est-à-dire l'utilisation du GPU pour du calcul parallèle généraliste.
Les implications dépassent largement le domaine du jeu vidéo en ligne. Le compute shading est précisément ce qu'utilisent les frameworks d'apprentissage automatique comme TensorFlow ou PyTorch pour accélérer l'entraînement et l'inférence de modèles de deep learning. Avec WebGPU, il devient théoriquement possible de faire tourner des modèles de langage de taille modeste, des réseaux de neurones convolutifs pour la vision par ordinateur, ou des algorithmes de traitement du signal directement dans le navigateur, sans aucun appel à un serveur distant. Les premières démonstrations concrètes circulent déjà : des modèles de génération d'image en local, des assistants conversationnels légers qui s'exécutent entièrement côté client, des outils d'analyse d'image en temps réel exploitant la caméra de l'utilisateur.
Pour les développeurs web, WebGPU représente un défi technique sérieux : son API est bas niveau, verbeuse et exigeante. Elle s'adresse d'abord à des spécialistes du graphisme ou du machine learning. Mais des bibliothèques d'abstraction émergent rapidement pour rendre son usage accessible à un public plus large, de la même façon que Three.js a démocratisé WebGL en son temps.
File System Access API et stockage local : vers un web qui se souvient
L'une des limitations historiques les plus frustrantes des applications web était leur rapport au système de fichiers. Un site web ne pouvait pas lire un fichier sur le disque dur de l'utilisateur sans que celui-ci ne l'ait explicitement sélectionné via un champ de formulaire, et encore moins écrire directement dans un répertoire local. Cette contrainte, justifiée par d'évidentes raisons de sécurité, rendait impossible la création d'outils professionnels capables d'interagir naturellement avec les données de l'utilisateur.
La File System Access API, désormais disponible dans les navigateurs basés sur Chromium et en cours d'expérimentation ailleurs, change fondamentalement cette donne. Elle permet à une application web, après consentement explicite de l'utilisateur, d'obtenir un accès en lecture et en écriture à des fichiers ou des répertoires du système de fichiers local. L'utilisateur garde le contrôle total : il choisit quels dossiers partager, et peut révoquer cet accès à tout moment. Mais pour l'application, le résultat est spectaculaire : un éditeur de code en ligne peut travailler directement sur les fichiers du projet de l'utilisateur, un outil de montage audio peut lire et sauvegarder des fichiers WAV ou FLAC sans passer par des serveurs distants, une application de gestion documentaire peut synchroniser son état avec un dossier local.
Complémentaire à cette API, l'Origin Private File System (OPFS) offre à chaque application web un espace de stockage privé, isolé des autres origines, accessible avec des performances proches de celles du disque, y compris depuis des Web Workers pour ne pas bloquer l'interface utilisateur. SQLite compilé en WebAssembly, par exemple, utilise l'OPFS comme backend de stockage pour proposer une base de données relationnelle complète, persistante et haute performance entièrement dans le navigateur — sans serveur, sans réseau.
Web Bluetooth, Web USB et Web Serial : le navigateur se branche sur le monde physique
La frontière entre le web et le monde physique s'estompe elle aussi. Web Bluetooth, Web USB et Web Serial sont trois API qui permettent à une page web d'établir une communication directe avec des périphériques physiques — capteurs, microcontrôleurs, appareils médicaux, outils industriels — en passant par les protocoles Bluetooth Low Energy, USB ou les ports série.
Ces API ont déjà trouvé des usages concrets dans des domaines très variés. Les fabricants de matériel électronique grand public proposent des interfaces web pour configurer leurs appareils sans nécessiter l'installation de pilotes ou de logiciels propriétaires. Des plateformes d'enseignement de l'électronique, comme celles qui permettent de programmer des cartes Arduino ou des microcontrôleurs compatibles directement depuis le navigateur, ont totalement transformé l'expérience pédagogique : plus besoin d'installer un IDE, d'un driver USB spécifique ou d'une chaîne de compilation complexe. L'apprenant ouvre un onglet, branche sa carte, et code. Dans le domaine médical, des fabricants de glucomètres ou de tensiomètres connectés testent des interfaces web pour centraliser les données de leurs appareils sans application mobile dédiée.
Ces API soulèvent naturellement des questions de sécurité importantes — un accès direct au matériel depuis un site web mal intentionné représente un risque non négligeable. Les éditeurs de navigateurs ont répondu par un modèle de permission strict, basé sur le consentement explicite de l'utilisateur et limité aux origines sécurisées (HTTPS obligatoire). Mais le débat reste ouvert sur le niveau de granularité de ces permissions et sur la façon dont les utilisateurs non techniques peuvent vraiment évaluer les risques qu'ils acceptent.
Les enjeux de sécurité, de confidentialité et de gouvernance
L'élargissement des capacités du navigateur n'est pas sans soulever des questions fondamentales sur la sécurité et la vie privée. Chaque nouvelle API représente une surface d'attaque potentielle supplémentaire, et l'histoire du web est jalonnée d'exemples où des fonctionnalités bien intentionnées ont été détournées à des fins malveillantes.
Le cas du fingerprinting est emblématique. Des API comme WebGL, les API audio ou les informations sur les polices de caractères installées ont été exploitées pour construire des empreintes numériques uniques permettant de tracer les utilisateurs à travers le web, contournant ainsi les mécanismes traditionnels de blocage des cookies. À mesure que les API deviennent plus riches et plus expressives, le risque que des informations système très spécifiques — l'architecture GPU, les capacités matérielles exactes, les périphériques connectés — soient utilisées à des fins de profilage augmente proportionnellement.
Les navigateurs ont adopté des stratégies défensives variées : réduction de la précision des mesures de temps (pour contrer les attaques par canaux auxiliaires comme Spectre), opacification des informations matérielles, isolation renforcée des processus de rendu. Mais ces mesures créent parfois des tensions avec les cas d'usage légitimes qui nécessitent précisément ces informations.
La question de la gouvernance de ces standards est également cruciale. Le W3C et le WHATWG jouent un rôle central dans la définition de ces API, mais le processus de standardisation est fortement influencé par les grandes entreprises technologiques qui éditent les navigateurs dominants. Google, Microsoft, Apple et Mozilla ont des intérêts économiques parfois divergents, et certaines API avancent plus vite dans Chromium (qui alimente Chrome et Edge) que dans Firefox ou Safari. Cette fragmentation partielle du web platform complique le travail des développeurs et repose la vieille question de la neutralité du web.
Ce que cela change pour les développeurs et les entreprises
Pour les équipes de développement, cette évolution du web platform représente à la fois une opportunité et un défi. L'opportunité est évidente : des fonctionnalités autrefois réservées aux applications natives deviennent accessibles avec les outils et les langages du web, dans un environnement déployable instantanément, sans processus de validation d'app store, accessible depuis n'importe quel appareil disposant d'un navigateur. Le défi est tout aussi réel : la complexité des API croît plus vite que les compétences moyennes des équipes web, la fragmentation entre navigateurs reste un sujet de friction quotidien, et les enjeux de sécurité exigent une vigilance accrue.
Pour les entreprises qui publient des logiciels professionnels — et notamment les éditeurs de solutions métier en Île-de-France comme dans le reste de l'écosystème tech français — la question du web-first vs. native se pose désormais dans des termes entièrement nouveaux. Des outils comme Photopea (éditeur d'images en ligne), Excalidraw (tableau blanc collaboratif), Codeflow ou StackBlitz (environnements de développement dans le navigateur) démontrent que des applications auparavant impensables dans un contexte web sont non seulement possibles mais souvent préférables, notamment pour leur facilité de mise à jour, leur accessibilité multi-plateformes et leur absence de frictions à l'installation.
Les architectures logicielles évoluent en conséquence. Le modèle local-first — dans lequel les données vivent d'abord sur l'appareil de l'utilisateur et sont synchronisées de manière opportuniste avec un serveur — gagne en crédibilité à mesure que les capacités de stockage local et de traitement hors ligne des navigateurs s'améliorent. Des bibliothèques comme ElectricSQL, PowerSync ou les implémentations de CRDTs (Conflict-free Replicated Data Types) pour le web exploitent ces nouvelles fondations techniques pour proposer des applications résilientes, performantes et respectueuses de la souveraineté des données utilisateurs.
Vers un web de moins en moins identifiable comme tel
Il est tentant de conclure de tout cela que le web est en train de « gagner » la guerre contre les applications natives. La réalité est plus nuancée. Les applications natives conservent des avantages réels dans des domaines où la performance brute, l'accès système profond ou l'intégration matérielle extrêmement fine sont critiques. Les systèmes d'exploitation ont également renforcé leurs défenses contre les tentatives des navigateurs d'empiéter sur leurs prérogatives, et Apple en particulier maintient des restrictions significatives sur les capacités des navigateurs tiers sur iOS.
Ce que cette évolution révèle surtout, c'est que la catégorie « application web » est en train de perdre son sens restrictif. Il ne s'agit plus de savoir si une application peut être faite avec des technologies web, mais de choisir, pour chaque cas d'usage, la combinaison optimale de technologies — web, native, hybride — en fonction des contraintes de déploiement, de maintenance, de performance et d'expérience utilisateur.
Les développeurs web de 2026 se retrouvent à devoir maîtriser un spectre technologique beaucoup plus large que leurs prédécesseurs : HTML, CSS et JavaScript restent les fondations incontournables, mais WebAssembly, WebGPU, les Service Workers, les API de stockage avancées, les protocoles de communication bas niveau viennent s'y ajouter comme des compétences différenciantes. La bonne nouvelle, c'est que l'outillage pour apprivoiser cette complexité — frameworks d'abstraction, outils de compilation, documentation exhaustive — n'a jamais été aussi mature.
Le navigateur que vous utilisez pour lire cet article est, en ce moment même, une plateforme d'exécution capable de faire tourner des simulations physiques complexes, de traiter des flux vidéo en temps réel, de piloter des objets connectés et d'exécuter des modèles d'intelligence artificielle. Cette réalité, encore largement méconnue du grand public, est en train de redéfinir silencieusement les frontières de ce que nous appelons « le web » — et de rendre obsolète, pour de bon, la vieille distinction entre ce qui est en ligne et ce qui est installé.