Une application web s’exécute dans un navigateur via une URL, sans installation : le code tourne côté serveur et dans la page, pas sur le disque de l’utilisateur. Une application classique, elle, s’installe localement et s’exécute directement sur le système d’exploitation ciblé. Cette distinction simple entraîne des conséquences concrètes sur l’installation, l’accès au matériel, la performance brute et le coût de maintenance dans le temps.
En bref:
- La compatibilité des fonctionnalités matérielles critiques est souvent supérieure aux applications natives, notamment pour l’accès à l’USB, au GPU et aux capteurs spécialisés.
- La maintenance d’une application web centralisée coûte généralement moins cher et est plus rapide à déployer que celle d’une application native multiplateforme.
- La performance dans le navigateur s’est améliorée grâce à WebAssembly, mais le traitement intensif ou lourd reste mieux géré par une solution native.
- Le choix de l’architecture doit se baser sur le matériel nécessaire, la complexité de maintenance et le budget, plutôt que sur la tendance technologique ou la préférence de l’équipe de développement.
- La compatibilité navigateur, la stabilité des fonctionnalités hors ligne, et la disponibilité des API matérielles doivent être testées minutieusement avant de valider une solution web ou native.
Table des matières
- Web, site, PWA, natif : qui est quoi exactement
- Architecture, sécurité, performance : ce que change le bac à sable du navigateur
- PWA, Electron, Tauri : ce que ces technologies permettent vraiment aujourd’hui
- Forces et faiblesses de chaque approche, sans détour
- La checklist pour trancher entre web, PWA, hybride ou natif
- Développement, déploiement, coût total : ce que cela change en interne
- Ce que nos projets nous ont appris sur le terrain
- Vers une convergence, mais pas une disparition des choix
- Besoin d’un diagnostic technique avant de trancher ?
- Questions fréquentes
- Sources
Web, site, PWA, natif : qui est quoi exactement
Avant d’aller plus loin, il faut clarifier le vocabulaire, parce que la confusion entre ces termes coûte cher en réunion de cahier des charges. Une application web repose sur un front qui s’exécute dans le navigateur et communique avec un backend hébergé sur un serveur : Gmail, Google Docs ou Trello en sont des exemples reconnus. Elle ne nécessite ni téléchargement ni exécutable, contrairement à une application native ou de bureau qui doit être installée sur un système d’exploitation spécifique, via un store ou un fichier .exe, .dmg ou .deb.
Entre les deux, plusieurs nuances méritent d’être posées clairement :
- Un site web statique affiche du contenu, sans logique applicative complexe (une brochure en ligne, par exemple).
- Une application web interactive gère des états, des sessions et des données en temps réel, comme un tableau de bord SaaS.
- Une PWA (Progressive Web App) est une application web qui adopte des technologies lui permettant de se comporter comme une application installée : icône sur l’écran d’accueil, notifications, fonctionnement hors ligne partiel.
- Une application native cible un système précis (Windows, macOS, iOS, Android) et profite d’un accès direct aux ressources matérielles.
Cette hiérarchie n’est pas qu’un exercice de style. Elle conditionne directement le choix d’architecture qu’une équipe technique devra défendre devant une direction qui, elle, ne retient souvent que le mot “application” sans en saisir les implications.
Architecture, sécurité, performance : ce que change le bac à sable du navigateur
Le vrai clivage technique se joue dans l’environnement d’exécution. Une application web tourne dans la sandbox du navigateur, un espace volontairement cloisonné qui limite ce que le code peut faire sur la machine. Une application native, elle, s’exécute comme un processus du système, avec un accès direct à la mémoire, au système de fichiers et aux périphériques. Cette isolation du navigateur protège l’utilisateur, mais elle brise aussi l’illusion que le web peut tout faire : pour des environnements traitant des données sensibles, l’option native reste souvent privilégiée pour la souveraineté des données et l’isolation.
Côté performance, l’écart s’est resserré ces dernières années grâce à WebAssembly, qui permet d’exécuter du code compilé quasiment à vitesse native dans le navigateur. Mais pour les tâches vraiment lourdes, édition vidéo, calcul scientifique, rendu 3D temps réel, la latence réseau et les limites de la sandbox imposent souvent de déporter le calcul vers des modules natifs.
L’accès au matériel reste le point le plus fragile du web moderne :
- WebUSB et WebBluetooth existent, mais leur disponibilité varie fortement d’un navigateur à l’autre, avec un support souvent incomplet ou absent sur Safari.
- La File System Access API permet de lire et d’écrire des fichiers locaux, dans un périmètre restreint par le navigateur.
- L’accès GPU bas niveau reste beaucoup plus direct et performant côté natif.
Le point à retenir : les service workers permettent aux PWAs de gérer le cache, la synchronisation en arrière-plan et les notifications push, ce qui rapproche sérieusement l’expérience web d’une application installée, sans jamais l’égaler totalement sur l’accès matériel brut.
PWA, Electron, Tauri : ce que ces technologies permettent vraiment aujourd’hui
Une PWA s’appuie sur des technologies web classiques tout en offrant une expérience proche du natif : installation sur l’écran d’accueil, fonctionnement hors ligne, exécution en arrière-plan. Trois éléments rendent cela possible :
- Le service worker, un script qui s’exécute séparément de la page et intercepte les requêtes réseau pour servir du contenu en cache.
- Le manifest, un fichier qui décrit l’icône, le nom et le comportement d’installation de l’application.
- Les API de synchronisation en arrière-plan, qui autorisent des tentatives limitées d’envoi de données même quand l’utilisateur a quitté l’application.
Ces briques ouvrent de vraies possibilités : mode hors ligne, notifications, installation sans passage par un store. Mais il faut rester honnête sur leurs limites : les navigateurs peuvent arrêter et reprendre les service workers à leur gré, et rien ne garantit qu’une tâche en arrière-plan s’exécute au moment prévu.
Conseil de pro : avant de promettre un mode hors ligne complet à un client, testez le comportement réel du service worker sur Safari iOS, qui applique des restrictions plus strictes que Chrome ou Edge.
Quand le web pur ne suffit pas sans basculer vers du natif complet, les frameworks hybrides prennent le relais. Electron embarque Chromium dans chaque application, ce qui peut fortement augmenter la taille du binaire final, tandis que Tauri s’appuie sur la webview native du système et produit des exécutables nettement plus légers. La contrepartie de Tauri : des tests plus fins sont nécessaires pour garantir un rendu cohérent entre Windows, macOS et Linux, puisque chaque webview native a ses propres particularités.
Forces et faiblesses de chaque approche, sans détour
Mettre les deux modèles côte à côte évite les choix par habitude ou par mode.
- Web : distribution instantanée. Un lien suffit, sans passage par un store ni validation externe.
- Web : maintenance centralisée. Un correctif déployé côté serveur atteint tous les utilisateurs sans action de leur part, contre des cycles de mise à jour plus lents côté natif.
- Web : dépendance au navigateur. Une fonctionnalité qui marche sur Chrome peut être absente sur Safari, ce qui oblige à tester chaque combinaison.
- Natif : accès matériel complet. GPU, capteurs, périphériques USB, tout est accessible sans négociation avec une sandbox.
- Natif : fonctionnement hors ligne total, sans dépendre d’un service worker qui peut être interrompu par le système.
- Natif : coût de déploiement plus lourd. Chaque plateforme (Windows, macOS, Linux, iOS, Android) impose souvent son propre pipeline de build et de validation.
Aucune de ces deux colonnes n’est universellement la bonne réponse : le bon choix dépend du cas d’usage, pas d’une préférence technologique.
La checklist pour trancher entre web, PWA, hybride ou natif
Plutôt que de se fier à une intuition ou à la dernière technologie à la mode, une décision d’architecture mérite une grille simple, posée en amont du devis.
- Le matériel est-il critique ? Si l’application doit piloter une caméra, un scanner USB ou exploiter intensivement le GPU, le natif s’impose presque systématiquement.
- La maintenance multiplateforme pèse-t-elle lourd ? Si vous devez couvrir Windows, macOS et le web avec une équipe réduite, une base de code web unique réduit nettement la charge.
- Quel budget, quel délai, quelle sensibilité des données ? Une PWA coûte généralement moins cher à produire et à faire évoluer qu’une application native multiplateforme, mais les environnements manipulant des données sensibles gagnent souvent à privilégier l’isolation native, notamment au regard du RGPD.
Un modèle de décision simple fonctionne bien : commencez par la question du matériel, puis celle de la maintenance, puis celle du coût. Dès qu’une réponse pointe fermement vers le natif, les deux questions suivantes deviennent secondaires. Ce raisonnement, nous le détaillons aussi dans notre comparatif entre application métier sur mesure et logiciel standard, utile pour les dirigeants qui hésitent entre acheter une solution existante et faire développer la leur.
Conseil de pro : ne laissez jamais le choix d’architecture à la seule préférence technique de l’équipe de développement : faites-le valider par les besoins réels de l’utilisateur final, pas par ce qui est le plus confortable à coder.
Développement, déploiement, coût total : ce que cela change en interne
Le choix d’architecture ne se limite pas à une question de code : il redessine tout le cycle de vie du produit. Une application web permet généralement d’aller du prototype à la production plus vite, avec une seule base de code à tester et un déploiement continu côté serveur. Une application native impose des cycles de validation plus longs, surtout sur mobile, où chaque mise à jour passe par la revue d’un store.
- La mise à jour côté web est transparente pour l’utilisateur : un déploiement serveur, et tout le monde bascule sur la nouvelle version.
- Côté natif, chaque mise à jour transite par un store (avec ses délais de validation) ou par un installateur que l’utilisateur doit lancer lui-même.
- L’hébergement d’une application web repose sur des briques devenues standards : CDN pour les contenus statiques, API cloud pour la logique métier, bases de données managées pour la scalabilité.
- Côté équipe, une application web mobilise des compétences front et back classiques, alors qu’une application native multiplateforme exige souvent des profils spécialisés par système, ce qui pèse sur le recrutement et le support.
C’est précisément ce terrain, celui de la maintenance et de l’hébergement dans la durée, que couvre notre page sur la maintenance de site internet, pensée pour sécuriser une application web après sa mise en ligne plutôt que de la laisser vieillir sans surveillance.
Ce que nos projets nous ont appris sur le terrain
Depuis 2008, nous avons livré des centaines de projets web et accompagné des dirigeants qui arrivaient avec la même question : web ou natif ? Pour un client ayant besoin d’une plateforme de gestion interne accessible à plusieurs équipes, nous avons conçu une application SaaS de gestion d’agence, où le web s’imposait naturellement : accès multi-utilisateurs, mises à jour centralisées, aucun poste à équiper individuellement.
Notre checklist interne avant de livrer une PWA ou de recommander du natif tient en quelques points :
- Vérifier le support réel des fonctionnalités critiques sur chaque navigateur ciblé, pas seulement sur Chrome.
- Tester le comportement hors ligne dans des conditions réseau dégradées, pas uniquement en coupant le wifi.
- Évaluer dès le départ si une fonctionnalité matérielle future rendra le web insuffisant.
D’autres projets de ce type sont visibles parmi nos réalisations d’applications web.
Vers une convergence, mais pas une disparition des choix
WebAssembly, les API matérielles et les PWA réduisent l’écart entre web et natif, sans l’effacer. La confidentialité des données pèsera de plus en plus dans l’arbitrage, surtout avec l’essor des fonctionnalités d’intelligence artificielle embarquées, qui posent la question de ce qui s’exécute localement contre ce qui transite par un serveur. Au fond, la bonne décision ne se trouve jamais dans la technologie elle-même, mais dans un audit honnête du risque métier et des usages réels.
— David
Besoin d’un diagnostic technique avant de trancher ?
Le bon choix entre application web, PWA ou solution native dépend de votre matériel, de votre budget et de vos contraintes de sécurité, pas d’une tendance. Un bon diagnostic avant de coder quoi que ce soit inclut la stratégie, le design et le développement technique traités de façon cohérente, afin d’éviter les allers-retours entre différents prestataires. Nous accompagnons aussi bien la création de site internet que des projets plus complexes intégrant de l’intelligence artificielle, avec un hébergement et une maintenance pensés pour durer. Pour des besoins métier connexes comme la domiciliation d’entreprise, des partenaires comme Adryo complètent utilement une architecture web. Parlons de votre projet et demandez un diagnostic technique via notre page contact.
Questions fréquentes
C’est quoi une application web ?
Une application web est un programme qui s’exécute dans un navigateur, sans installation locale, accessible via une URL. Son interface tourne dans la page tandis que la logique et les données sont souvent gérées par un serveur distant.
Quelle est la différence entre un site web et une application ?
Un site web présente surtout du contenu statique à consulter, comme une vitrine en ligne. Une application web gère des états, des interactions et des données en temps réel, à l’image d’un tableau de bord ou d’un outil de gestion.
Quelle est la différence entre une application web et une application mobile ?
Une application web s’exécute dans un navigateur et fonctionne sur n’importe quel appareil disposant de ce navigateur. Une application mobile native est développée pour un système d’exploitation spécifique (iOS ou Android) et doit être installée depuis un store, ce qui lui donne un accès plus direct au matériel du téléphone.
Quels sont les différents types d’applications ?
On distingue principalement les applications web, les applications natives et les applications hybrides qui combinent les deux approches, notamment via des frameworks comme Electron ou Tauri. Les progressive web apps forment une catégorie à part, construite sur des technologies web mais capable de fonctionner hors ligne et de s’installer comme une application classique.
Sources
- Webapplications vs. Native Apps — AWS compare
- Offline and background operation — MDN
- Web‑App oder native App 2025? Sicherheit, Datenschutz & KI im Fokus — Ubuntu‑User
- User‑Interface‑Design – nativ oder webbasiert? — Computerwoche
