Desktop, web et mobile : tensions et convergences#

Les sections précédentes ont retracé comment le web est devenu la plateforme dominante pour les interfaces utilisateur, portée par des frameworks de plus en plus sophistiqués. Mais le web n’est pas la seule plateforme. Les applications desktop natives continuent d’exister pour les cas qui exigent des performances maximales ou un accès direct au matériel (éditeurs vidéo, jeux, outils de développement). Les applications mobiles, apparues avec l’iPhone en 2007 et l’Android Market en 2008, ont créé un nouvel écosystème avec ses propres langages (Swift pour iOS, Kotlin pour Android), ses propres conventions d’interface, et ses propres canaux de distribution (les app stores). Le résultat est un paysage fragmenté où un même service doit souvent exister sous plusieurs formes : un site web, une application iOS, une application Android, parfois une application desktop. Cette fragmentation relance, à une échelle bien plus grande, la tension qu’on a identifiée dans la section historique à propos des toolkits desktop : faut-il écrire du code natif pour chaque plateforme, au prix de la duplication, ou chercher une solution universelle, au prix de compromis sur l’expérience utilisateur ?

Le desktop natif : puissance et friction#

Une application desktop native est compilée pour un système d’exploitation spécifique et s’exécute directement sur la machine de l’utilisateur. Elle a un accès complet aux ressources du système : le système de fichiers, le GPU, les périphériques USB, les notifications du système, la mémoire. C’est pourquoi les logiciels les plus exigeants restent natifs : Adobe Photoshop, les IDE comme IntelliJ ou Visual Studio, les jeux vidéo, les outils de montage vidéo. La performance est maximale parce qu’il n’y a pas de couche d’abstraction entre l’application et le matériel. Mais cette puissance a un coût opérationnel : chaque mise à jour doit être téléchargée et installée par l’utilisateur, les bugs doivent être diagnostiqués sur une multitude de configurations matérielles et logicielles, et la distribution passe par des installateurs, des gestionnaires de paquets ou des app stores selon la plateforme. C’est exactement le problème de déploiement que le web a résolu en rendant chaque visite un accès à la dernière version.

Le mobile : deux écosystèmes, deux mondes#

L’arrivée de l’iPhone en 2007 et d’Android en 2008 a créé une nouvelle catégorie d’interfaces avec ses propres contraintes. Un téléphone n’est pas un ordinateur de bureau : l’écran est petit, l’interaction se fait au doigt plutôt qu’à la souris, la connexion réseau est intermittente, et la batterie est limitée. Ces contraintes ont poussé Apple et Google à développer des environnements de développement spécifiques, avec leurs propres langages (Objective-C puis Swift pour iOS, Java puis Kotlin pour Android), leurs propres toolkits d’interface (UIKit puis SwiftUI pour iOS, Android SDK puis Jetpack Compose pour Android), et leurs propres conventions de design (les Human Interface Guidelines d’Apple, le Material Design de Google). Mais la différence la plus structurante avec le desktop est le modèle de distribution : les app stores. Apple et Google contrôlent l’accès à leurs plateformes via un processus de validation et prélèvent une commission sur les ventes (typiquement 30%). Ce modèle centralisé garantit une certaine qualité et sécurité pour l’utilisateur, mais il crée une dépendance forte pour le développeur : son application peut être refusée, retirée ou soumise à des règles changeantes. C’est un contraste frappant avec le web, où n’importe qui peut publier un site sans demander la permission à personne.

Le responsive design#

Avant même que les frameworks cross-platform ne tentent d’unifier le développement mobile et web, le web a dû s’adapter à la diversité des écrans. Un site conçu pour un moniteur de bureau de 1920 pixels de large est illisible sur un téléphone de 375 pixels. En 2010, Ethan Marcotte publie un article fondateur dans A List Apart où il introduit le terme responsive web design : l’idée que la mise en page d’un site devrait s’adapter dynamiquement à la taille de l’écran plutôt que d’exister en versions séparées (un site “desktop” et un site “mobile”). La technique repose sur les media queries CSS, qui permettent d’appliquer des règles de style différentes selon les caractéristiques de l’écran (largeur, orientation, résolution). Un menu horizontal peut devenir un menu hamburger sur mobile, une grille de trois colonnes peut se replier en une seule colonne, les tailles de police peuvent s’ajuster. Le responsive design est devenu une pratique standard, au point que Google pénalise dans ses résultats de recherche les sites qui ne sont pas adaptés au mobile. Mais adapter la mise en page ne suffit pas toujours : sur un petit écran, il faut parfois repenser l’interaction elle-même, pas seulement la disposition des éléments.

Les frameworks cross-platform#

Face au coût de maintenir des bases de code séparées pour iOS et Android, l’industrie a cherché des moyens d’écrire le code une seule fois et de le déployer sur les deux plateformes. Plusieurs stratégies ont émergé, chacune avec ses compromis. React Native (Facebook, 2015) reprend le modèle de composants de React, mais au lieu de cibler le DOM du navigateur, il cible les composants natifs de chaque plateforme : un <View> React Native devient un UIView sur iOS et un android.view.View sur Android. Le développeur écrit du JavaScript (ou TypeScript), mais l’interface rendue est véritablement native, ce qui garantit des performances et une apparence proches d’une application développée en Swift ou Kotlin. Flutter (Google, 2018) prend une approche encore plus radicale : plutôt que d’utiliser les composants natifs de chaque plateforme, Flutter dessine tout lui-même sur un canvas, pixel par pixel, à l’aide de son propre moteur de rendu (Skia, puis Impeller). Le résultat est un contrôle total sur l’apparence et un comportement parfaitement identique sur iOS et Android, au prix d’une rupture avec les conventions visuelles natives de chaque plateforme. Flutter utilise Dart, un langage développé par Google, ce qui représente un investissement d’apprentissage supplémentaire. D’autres solutions existent : .NET MAUI (Microsoft) cible à la fois le mobile et le desktop depuis C#, et Kotlin Multiplatform (JetBrains) permet de partager la logique métier entre plateformes tout en gardant des interfaces natives. Aucune de ces approches n’a “gagné” : le choix dépend des priorités du projet (fidélité native, productivité, écosystème existant).

Les Progressive Web Apps (PWA)#

Plutôt que d’utiliser un framework pour cibler les plateformes natives, les Progressive Web Apps (PWA) prennent le chemin inverse : faire en sorte qu’un site web se comporte comme une application native. Le concept, formalisé par Google en 2015, repose sur quelques technologies clés. Les service workers sont des scripts JavaScript qui s’exécutent en arrière-plan, indépendamment de la page, et qui peuvent intercepter les requêtes réseau pour servir du contenu depuis un cache local, ce qui rend l’application utilisable hors-ligne. Un manifeste (un fichier JSON) décrit l’application (son nom, son icône, ses couleurs) et permet au navigateur de proposer à l’utilisateur de l’“installer” sur son écran d’accueil, comme une application native. Le résultat est une application web qui peut envoyer des notifications, fonctionner sans connexion, et se lancer depuis l’écran d’accueil, sans passer par un app store. Twitter, Starbucks et Pinterest ont tous publié des PWA qui, pour beaucoup d’usages, remplacent avantageusement leurs applications natives. Mais les PWA restent limitées par ce que le navigateur autorise : l’accès au Bluetooth, aux capteurs, au système de fichiers est restreint ou absent selon la plateforme. Apple, en particulier, a longtemps freiné l’adoption des PWA sur iOS, préférant garder le contrôle de la distribution via l’App Store.

Electron, Tauri et WebAssembly : le brouillage des frontières#

La convergence entre le web et le natif ne se limite pas au mobile. Sur le desktop, Electron (GitHub, 2014) permet de construire des applications desktop en utilisant les technologies web (HTML, CSS, JavaScript). Le principe est simple : Electron embarque un navigateur Chromium complet à l’intérieur de l’application, ce qui donne au code web un accès aux APIs du système d’exploitation (fichiers, notifications, menus natifs). Visual Studio Code, Slack, Discord et Figma (dans sa version desktop) sont tous construits avec Electron. L’avantage est évident pour les équipes qui maîtrisent déjà le développement web : elles peuvent réutiliser leur code et leurs compétences pour le desktop. Le reproche récurrent est la consommation de ressources : chaque application Electron embarque sa propre copie de Chromium, ce qui se traduit par une empreinte mémoire importante. Tauri (2022) propose une alternative plus légère : au lieu d’embarquer Chromium, Tauri utilise le composant WebView natif de chaque système d’exploitation (WebKit sur macOS, WebView2 sur Windows), ce qui réduit considérablement la taille et la consommation mémoire des applications. Le backend de Tauri est écrit en Rust, ce qui apporte des garanties supplémentaires de performance et de sécurité.

WebAssembly (WASM) pousse le brouillage encore plus loin. C’est un format binaire, standardisé par le W3C en 2017, qui permet d’exécuter du code compilé (C, C++, Rust, Go) dans le navigateur, à des vitesses proches du natif. WebAssembly ne remplace pas JavaScript : il le complète pour les tâches intensives en calcul. Figma l’utilise pour son moteur de rendu, Google Earth pour sa visualisation 3D, et des outils comme AutoCAD ou Photoshop ont pu être portés sur le web grâce à lui. L’existence de WebAssembly signifie que le navigateur n’est plus limité à JavaScript : il devient un environnement d’exécution généraliste, capable de faire tourner du code écrit dans pratiquement n’importe quel langage. La frontière entre “application web” et “application native” devient de plus en plus floue.

La tension fondamentale#

Le panorama des plateformes d’interfaces utilisateur est traversé par une tension qui n’a jamais été résolue, seulement déplacée. D’un côté, la promesse du “write once, run everywhere” : une seule base de code, un seul langage, un seul effort de développement pour atteindre tous les utilisateurs. C’est la promesse de Java dans les années 1990, du web responsive dans les années 2010, de Flutter et React Native aujourd’hui. De l’autre, la réalité que chaque plateforme a ses conventions, ses contraintes et ses utilisateurs qui s’attendent à une expérience native : les gestes iOS ne sont pas les gestes Android, un menu macOS ne fonctionne pas comme un menu Windows, et une application web ne peut pas accéder aux mêmes ressources qu’une application native. Chaque solution “universelle” finit par buter sur ces différences, et chaque solution “native” finit par buter sur le coût de la duplication. Le web, grâce à son universalité et à la puissance croissante du navigateur (WebAssembly, service workers, APIs système), est probablement la plateforme la mieux positionnée pour absorber de plus en plus de cas d’usage. Mais la convergence totale reste un horizon, pas une destination atteinte.