676 développeurs en colère : votre application n’était qu’une simple page web

Le 9 juillet 2026, le développeur britannique Dan Q a publié un article au titre provocateur : « Votre “application” aurait pu être une page web (et je l’ai réparée pour vous) ». Le billet a déclenché sur Hacker News une discussion enflammée entre 676 développeurs et 420 commentaires, perçant à jour la frontière ténue entre l’économie de l’App Store et le Web ouvert.

Tout a commencé par un détail de la vie quotidienne. L’enfant de Dan devait se produire au parc Disney, et la compagnie de voyage exigeait des parents l’installation d’une application mobile nommée « Travelbound » pour consulter le programme. Dan a regardé la taille de l’application — 43 Mo au téléchargement, gonflés à 124 Mo une fois installée. Développeur chevronné depuis dix ans, il a trouvé cela absurde : je veux juste voir un horaire, pourquoi télécharger une application plus lourde que Super Mario ?

Il a fait ce que les développeurs savent faire de mieux : de l’ingénierie inverse.

Ce qu’il y a vraiment dans une application de 124 Mo

▲ Voici l’application Travelbound de 124 Mo, dont la fonction consiste à afficher du texte, des images et des liens PDF. Source : le blog de Dan Q.

Dan a intercepté le trafic réseau de l’application à l’aide d’un outil de capture, révélant une vérité à la fois cocasse et navrante : la seule chose que fait cette application, c’est concaténer un nom d’utilisateur et un mot de passe dans une URL, récupérer des données depuis le serveur, puis les afficher à l’écran.

Concrètement, la logique derrière l’application ressemble à ceci :

https://travelbound.api.vamoos.com/api/itineraries/{nom d'utilisateur}-{mot de passe}

Le serveur renvoie un grand bloc de données au format JSON — listes d’étapes, informations d’hébergement, liens de téléchargement PDF, images associées. Or ce contenu était déjà formaté en HTML. En d’autres termes, le serveur de l’application produisait déjà des pages web ; il a simplement choisi de les enfermer dans une coquille de 124 Mo pour vous les montrer.

▲ Les données renvoyées par le serveur, où l’on voit que le programme existait déjà au format HTML. Source : le blog de Dan Q.

Que contenait donc ce 124 Mo pour faire gonfler à ce point un « lecteur de pages web » ? Dan a découvert que l’application n’ajoutait que deux fonctionnalités par rapport à une page web :

1. Suivre votre compte Google, en renvoyant vos données d’usage à la compagnie de voyage
2. Diffuser des publicités (euphémisme officiel : « inspiration de voyage »), vous incitant à acheter davantage de séjours

Dan est plus direct : ces deux éléments sont des « anti-fonctionnalités » — sans aucun bénéfice pour l’utilisateur, et au contraire bien des nuisances.

De 124 Mo à 0,05 Mo : une page web suffisait

Dan a passé une demi-journée à écrire un petit script Ruby qui récupère périodiquement les dernières données du serveur et génère automatiquement une version purement web. Résultat ?

• Version application : 124 Mo (suivi et publicités inclus)
• Version web : une page HTML de 0,05 Mo, plus quelques images optionnelles (35 Mo, que l’on peut choisir de ne pas télécharger)

La version web est protégée par un mot de passe et utilise les mêmes comptes que l’application d’origine. Elle n’a pas d’interface tape-à-l’œil, mais permet le copier-coller, l’impression, l’enregistrement sur mobile et l’ouverture sur n’importe quel appareil — précisément ce que l’application d’origine ne savait pas faire.

▲ La version web réalisée par Dan, débarrassée des publicités et du suivi, conservant toute l’information essentielle. Source : le blog de Dan Q.

Dan a conclu par une interrogation qui va droit au cœur :

« Certaines applications méritent effectivement d’être des applications. Travelbound ne fait partie d’aucune d’elles. Je ne parviens pas à comprendre comment nous en sommes arrivés là — les éditeurs de logiciels préfèrent se compliquer la vie (et la renchérir : publier sur l’App Store n’est pas donné !), rien que pour pousser du contenu HTML vers moins de monde, avec moins de fonctionnalités. »

Pourquoi en sommes-nous arrivés là ? L’économie d’Apple

La perplexité de Dan cache une question plus vaste : pourquoi, alors que le Web suffirait, les développeurs s’obstinent-ils à packager en applications ?

Dans les 676 interventions de Hacker News, le commentaire le plus plébiscité va droit au but — Apple et Google ont dépensé des milliards de dollars pour remodeler le modèle mental des gens, au point qu’ils en sont venus à croire que “faire quelque chose sur son téléphone = utiliser une application”.

Sonnez : quand un utilisateur lambda déballe son nouveau téléphone, que voit-il sur l’écran d’accueil ? Des rangées d’icônes d’applications. Pour trouver quelque chose ? Il ouvre l’« App Store ». Pour utiliser un service ? « Il y a une appli ? »

Cette croyance que « l’application est tout » ne relève pas du naturel. Elle est le fruit de quinze années d’investissements colossaux de la part des deux géants de la tech.

La motivation sous-jacente, c’est l’argent — plus précisément, la fameuse « taxe Apple ».

La taxe Apple : l’économie d’une commission de 30 %

Toute application ou tout contenu numérique vendu via l’App Store d’Apple est frappé d’une commission de 15 % à 30 %. En 2024, l’App Store à lui seul a généré pour Apple plus de 85 milliards de dollars de revenus (selon les divulgations officielles d’Apple et les données financières rendues publiques lors du procès l’opposant à Epic Games). Dans toute l’industrie internet, on ne trouve guère de « péage » aussi lucratif.

Et le Web ? Le Web est ouvert. Quiconque publie une page n’a rien à payer à Apple, n’a pas à passer par sa validation, et l’utilisateur l’ouvre directement dans son navigateur. Si un service existe sous forme de page web, Apple ne touche pas un centime.

Cela explique pourquoi Apple, sur iOS, a sciemment rendu les applications web « peu pratiques » :

• Tous les navigateurs sur iPhone doivent utiliser le moteur WebKit d’Apple — même Chrome ou Firefox ne sont sur iPhone que des Safari au déguisement différent. En juin 2026, des ingénieurs de Microsoft ont publié un banc d’essai montrant que, si le moteur Chromium pouvait tourner sur iOS, les performances de navigation pourraient dépasser Safari de 28,6 %.
• Les applications web (PWA) sur iOS ne peuvent pas utiliser Face ID, ne synchronisent pas en arrière-plan et leurs notifications push sont sérieusement limitées — autant de points de vente clés pour bien des applications.
• Safari accuse des mois, voire des années de retard sur Chrome dans le support des standards web — vouloir utiliser une technologie nouvelle ? Il faudra d’abord attendre qu’Apple suive.

En Europe, le Digital Markets Act (DMA) tente de dénouer la situation en imposant à Apple d’ouvrir les restrictions sur les moteurs de navigateur. Mais la réponse d’Apple a été qualifiée par un juge américain de « conformité malveillante » — elle modifie les règles en apparence, tout en dressant une série d’obstacles techniques empêchant les concurrents d’accéder réellement au marché.

Quel est l’effet final de tout cela ? Les développeurs ont été « obligés » de monter à bord de l’App Store, et les utilisateurs « habitués » à ne reconnaître que les icônes d’applications.

L’autre face de la controverse : certains cas se prêtent mieux à une application

À ce stade, l’auteur tient à préciser : ce n’est pas un réquisitoire contre les applications. Dans la discussion HN, bon nombre de développeurs ont souligné les situations où une application surpasse une page web :

Un développeur, OkayPhysicist, a raconté son expérience : au sein de son entreprise, il avait conçu un outil de notes de frais et de documents adapté au mobile, en version web. Résultat ? Ses collègues le harcelaient de questions : « Comment on met le site sur le téléphone ? », « Comment on ouvre le site sur mobile ? », « Tu peux en faire une appli ? »

Le problème tient aux habitudes. Pour la plupart des utilisateurs, « application » est un concept compréhensible, tandis que « page web » demeure abstrait. Leur faire saisir une URL dans la barre d’adresse est moins naturel que de leur faire taper une icône colorée.

Le point soulevé par un autre développeur est tout aussi valable : si vous utilisez un service une dizaine de fois par jour, une véritable application native est bien plus commode que de jongler entre les onglets du navigateur. WeChat, Alipay, les cartes — dans ces cas d’usage à haute fréquence, les avantages de l’application (réactivité, animations fluides, fonctionnalités hors ligne) sont bien réels.

Certains cas demeurent difficilement couverts par les technologies web :

• Jeux gourmands en performance : nécessitant l’accélération GPU et un rendu 3D complexe
• Applications AR/VR : nécessitant un accès profond aux caméras et capteurs
• Montage audio/vidéo pro : nécessitant un traitement en temps réel et des codecs matériels
• Services nécessitant une exécution continue en arrière-plan : suivi sportif, navigation

Ce sont là les frontières légitimes du Web. L’auteur ne prétend pas que tout doive devenir une page web, mais ne croit pas non plus que tout mérite de devenir une application.

Le fond du problème : pas un débat technique, un débat de pouvoir

Cette querelle « applications vs pages web » est fondamentalement une lutte pour décider qui contrôle les logiciels que vous pouvez utiliser.

Dans le monde du Web ouvert, une simple URL suffit à publier un service, et le navigateur tient lieu d’« App Store ». Personne ne censure votre contenu, personne ne prélève vos revenus, personne ne décide si votre produit a le droit d’être « référencé ».

Dans le monde de l’App Store, Apple et Google sont les gardiens. Ils décident quoi valider (500 modérateurs pour 2 millions d’applications), ils fixent la commission (15 % à 30 %), ils choisissent quelles fonctions du téléphone votre application peut utiliser. Les utilisateurs obtiennent certes une certaine « sécurité » — du moins en théorie, ce qui est sur l’App Store a été modéré — mais au prix de leur libre choix.

Voilà la raison profonde pour laquelle l’article de Dan a mis 676 personnes hors de leurs gonds : tout le système est conçu ainsi — une page web qui aurait dû peser 0,05 Mo a été transformée de force en une application de 124 Mo. L’application de voyage en elle-même n’était pas mauvaise, mais le système l’a contrainte à une voie pesante.

Épilogue : quel est votre choix ?

L’histoire de Dan a une fin chaleureuse. Il a partagé sa version web avec les autres parents de l’équipe, qui ont découvert pour la première fois qu’on pouvait voir le programme sans installer cette application encombrante. Quand sa fille chantait et dansait sur la scène de Disney, son téléphone comptait un « traqueur » de 124 Mo de moins.

Pour nous, simples utilisateurs, la leçon est simple : la prochaine fois qu’on vous demandera de télécharger une application pour consulter un contenu, demandez-vous : ne pourrait-on pas en faire une page web ?

Car bien souvent, la réponse est oui.

---

Liens de référence :

• Dan Q : votre « application » aurait pu être une page web (et je l’ai réparée)
• Discussion Hacker News : 676 commentaires sur le débat approfondi applications vs Web
• Banc d’essai des ingénieurs Microsoft : les navigateurs iOS retardés de 28,6 % à cause des restrictions WebKit
• Rapport sur la controverse DMA UE et les restrictions du moteur WebKit d’Apple
• Limites des PWA sur iOS et état actuel du support de Safari (guide complet 2026)
• Évolution de la commission de 30 % d’Apple : suites du procès antitrust Epic Games
• Controverse sur la modération de l’App Store : la réalité des 500 modérateurs et des 2 millions d’applications
• Organisations de défense du Web ouvert : l’impact anticoncurrentiel des restrictions sur les moteurs de navigateur d’Apple