Japon : Apple doit lever l’interdiction des moteurs de navigateur d’ici décembre
(open-web-advocacy.org)- Le gouvernement japonais a récemment adopté la loi sur les smartphones, qui interdit directement à Apple d’interdire les moteurs de navigateur tiers sur iOS
- Jusqu’ici, l’imposition du moteur WebKit bloquait de fait la concurrence entre navigateurs sur iOS et affaiblissait la compétitivité des web apps
- Les nouvelles lignes directrices précisent qu’Apple ne peut pas non plus imposer des obstacles techniquement ou commercialement irréalistes
- Elles exigent également que l’accès aux API de l’OS pour les navigateurs soit garanti à un niveau fonctionnellement équivalent, sans dégradation discriminatoire des performances
- Avec l’entrée en vigueur de cette loi au Japon, un cadre réglementaire se met en place avec l’UE et le Royaume-Uni pour rétablir la concurrence entre navigateurs, et 2026 pourrait marquer un tournant
Japon : Apple sommé de lever l’interdiction des moteurs de navigateur
Le Japon a récemment adopté officiellement la « loi sur la promotion de la concurrence dans les logiciels pour smartphones », qui interdit directement la politique de longue date d’Apple consistant à bloquer les moteurs de navigateur tiers sur iOS.
État actuel de l’interdiction des moteurs de navigateur
- Jusqu’à présent, Apple n’autorisait que le moteur WebKit, ce qui avait pour effet d’exclure sur iOS tous les principaux moteurs de navigateur de Firefox, Chrome, Edge, Opera, Brave, Vivaldi, etc.
- Cela bloquait en pratique la concurrence entre navigateurs et empêchait les web apps d’utiliser les API ou les performances nécessaires pour rivaliser à armes égales avec les applications natives
Cadre légal japonais et lignes directrices
- Cette loi a été élaborée sur la base d’un rapport du Bureau de la concurrence des marchés numériques, en intégrant aussi les conseils d’Open Web Advocacy
- Les lignes directrices de la loi sur la concurrence dans les logiciels mobiles (MSCA) ont récemment été publiées, clarifiant concrètement l’interprétation et les modalités d’application de la loi
Interdiction d’entraver les moteurs de navigateur alternatifs
- Les lignes directrices interdisent explicitement tout acte visant à entraver ou compromettre l’introduction de moteurs de navigateur tiers
- Cela inclut l’imposition de contraintes techniques excessives aux éditeurs d’applications, de charges de coûts, ou de mesures éloignant les utilisateurs des navigateurs alternatifs
- Pour déterminer s’il y a entrave, il ne s’agit pas seulement des cas où le fournisseur interdit clairement une solution, mais aussi des situations où la possibilité réelle d’adoption devient nettement improbable
- Cette disposition signifie que, même si Apple l’autorise de façon purement nominale, il ne sera pas acceptable que l’usage soit en pratique impossible ou commercialement dénué de sens
Équivalence fonctionnelle dans l’accès aux API de l’OS
- La MSCA prévoit que l’accès aux API de l’OS doit être garanti de manière fonctionnellement équivalente
- La fourniture d’API alternatives est autorisée, mais si elles offrent des performances sensiblement inférieures en pratique, elles ne seront pas considérées comme fonctionnellement équivalentes
- Autrement dit, même si l’approche technique diffère, les navigateurs tiers doivent bénéficier du même niveau de performance et d’accessibilité que celui dont profitent Apple et les autres fournisseurs désignés
Obligation d’un écran de choix du navigateur (Choice Screen)
- La loi impose la mise à disposition d’un écran de choix (Choice Screen) pour les navigateurs (et d’autres logiciels)
- Les consignes sont plus strictes que dans l’UE : l’écran de choix doit s’afficher immédiatement « juste après la première activation »
- Lors de la configuration initiale du smartphone ou au premier lancement de l’application concernée, l’utilisateur doit être amené à choisir un logiciel spécifique
Évolutions à venir
- La loi sur la concurrence dans les logiciels mobiles doit entrer en vigueur en décembre 2025
- Le Japon rejoint l’UE et le Royaume-Uni parmi les juridictions où Apple devra autoriser les moteurs de navigateur tiers
- Le Japon devrait préparer son application en s’appuyant sur l’expérience réglementaire européenne et britannique
- Comme l’ont montré les cas de l’UE et du Royaume-Uni, l’application effective devrait rester un processus long et complexe
Conclusion et implications
- Au Japon, dans l’UE et au Royaume-Uni, le rétablissement d’une véritable concurrence entre navigateurs sur iOS progresse avec l’obligation imposée à Apple de prendre en charge les moteurs de navigateur tiers
- 2026 pourrait devenir un tournant dans la structure du marché des navigateurs
- L’issue dépendra en fin de compte de la volonté des régulateurs de faire appliquer ces règles et des efforts réels d’Apple pour s’y conformer
- Le rôle du gouvernement japonais et des organisations concernées, engagés de longue date pour améliorer l’environnement concurrentiel des navigateurs et des web apps, est mis en avant
7 commentaires
Hum... je trouve dommage que ce ne soit plus le cas, parce que lorsque toutes les fonctions de navigation passent par une bibliothèque de base, si le système bloque une URL donnée, on bénéficie d’une cohérence appréciable, impossible à contourner, dans les fonctions de navigation intégrées de toutes les applications.
La percée des navigateurs IA est attendue
Du point de vue des développeurs, cela va sans doute augmenter le nombre d’environnements à prendre en compte, haha...
Il faut désormais développer conformément aux standards du Web. Et éviter d’utiliser activement des fonctionnalités qui n’existent pas.
Il y en a peut-être beaucoup en apparence, mais au final ce ne sont que les moteurs de Firefox et de Chromium, non ?
Rien qu’à voir la liste des moteurs mentionnés dans l’état des interdictions, ça donne déjà le vertige @_@
Avis Hacker News
Tout le monde parle de Chrome, mais moi j’ai désactivé Chrome sur Android et j’utilise Firefox. Avec uBlock Origin sur Firefox mobile, l’expérience se rapproche beaucoup de celle du web sur desktop. Pas seulement pour bloquer les pubs : on peut aussi bloquer à la volée les éléments dont je me fiche avec des règles RegEx comme
:has-text. Chrome ne permet même plus ça sur desktop. J’en suis presque à envisager de basculer complètement vers Android comme appareil principal. Cela dit, la commodité de pouvoir répondre directement aux messages depuis le MacBook grâce à iMessage est tellement énorme que j’ai du mal à décrocher. À part ça, Android est globalement bien meilleur. Et je préfère même ne pas commencer à parler du clavier iOS ou de SiriLa combinaison FF + uBO, c’est l’application killer qui m’a fait rester sur Android. Si Apple avait autorisé ça, je serais passé chez eux depuis longtemps. Tu as déjà envisagé messages.google.com ? Il faut l’appli Messages de Google (pas Samsung Messages), et ça permet d’utiliser SMS et RCS sur desktop, donc c’est un très bon substitut à iMessage
L’extension consent-o-matic sur Firefox mobile est aussi vraiment utile. Elle clique automatiquement sur presque toutes les bannières cookies, donc on n’a pas à s’en occuper une par une sur mobile, c’est bien plus confortable
J’utilise aussi https://messages.google.com pour me créer un environnement façon iMessage sur desktop avec Android. Peut-être que ça conviendrait aussi à ton usage ? Je n’utilise pas iMessage, donc il est possible que je rate quelque chose
Si tu peux te contenter de SMS au lieu d’iMessage, KDE Connect permet un très bon système de messagerie desktop avec Android (sur Linux, Windows et MacOS ; il y a quelques différences de fonctionnalités selon la plateforme, mais le SMS est pris en charge partout). https://kdeconnect.kde.org/
On dirait que le Japon a retenu la leçon des cas de « conformité de façade » qu’Apple a montrés dans l’UE. Si Apple repart sur ce genre de tactique, j’espère qu’ils prendront aussi au Japon une vraie amende qui fasse réellement mal. À mon avis, ce n’est pas une question de « si », mais de « quand »
J’imagine même une interdiction de vente et d’importation ; je me demande combien de temps Apple devrait garder ses Apple Store fermés avant de plier
Moi, j’aime bien le walled garden qui m’empêche de faire des bêtises tout seul. Je suis aussi reconnaissant à Apple de ne pas balancer ma localisation à tout va ou de me protéger d’un obscure Monarch qui me traquerait, ce qui réduit mes inquiétudes sur la vie privée. (+4500 upvotes) Sur Reddit, j’ai toujours trouvé suspect que des titres anti-Apple prennent +30k upvotes alors que les commentaires pro-Apple sont bien moins nombreux en comparaison. Je me suis parfois dit qu’une équipe marketing ou une troll farm faisait de la gestion de réputation
Si ce mouvement législatif mondial débouche sur un écosystème applicatif iOS plus ouvert, ce serait vraiment une excellente nouvelle. BrowserEngineKit n’est qu’un mince wrapper autour de XPC et du système d’extensions iOS. Si XPC était une API ouverte, et si Apple autorisait le JIT dans des sous-processus isolés sans exiger son approbation, ce serait bien plus agréable à développer. Par exemple, une appli de messagerie pourrait avoir un sous-processus séparé pour traiter des entrées non fiables (iMessage le fait déjà), on pourrait isoler les composants instables d’une appli pour améliorer l’ergonomie et la récupération après crash, les émulateurs de systèmes rétro seraient beaucoup plus rapides, l’usage de WASM sur iOS deviendrait possible, et les navigateurs auraient pu utiliser XPC sans API spécialisée. Le problème, c’est que si tout cela devient possible, il devient aussi facile de charger dans les applis du code tournant à vitesse native après la revue App Store, et comme tout le monde le sait, si ce monde-là arrive, ce sera soi-disant la catastrophe
Si cette « catastrophe » arrive, j’aimerais bien regarder les gens paniquer sur des sites comme MacRumors. Il est difficile de croire naïvement qu’Apple ne soutient pas, pour son propre intérêt économique, des sites qui poussent certains récits sur Internet. Par exemple, l’idée absurde selon laquelle la liberté d’utiliser son téléphone comme on veut menacerait la sécurité et la vie privée de tout le monde est répétée en boucle
Cela transférerait une très grande partie de la charge de la protection anti-malware au niveau de la sandbox des applis. En réalité, même aujourd’hui, la sandbox n’est qu’une couche parmi plusieurs défenses : notarisation, permissions, revue d’applis, etc. Moi aussi, je suis pour que les utilisateurs puissent installer les applis qu’ils veulent, mais il faut alors reconnaître qu’un iPhone ordinaire serait plus facilement exposé aux malwares, comme Android. Derrière cette politique d’Apple, il n’y a pas seulement une volonté monopolistique ; il y a aussi de vraies questions de sécurité, même si la motivation principale reste probablement le profit
Un navigateur est déjà en soi une sorte d’App Store : en pratique, on y exécute constamment des applis sans revue d’Apple. Dans ce contexte, j’ai du mal à comprendre pourquoi Apple et ses fans insistent autant sur la sécurité de l’App Store
Autoriser le JIT, ce n’est pas seulement permettre une émulation plus rapide : on gagne aussi en efficacité en évitant de tout faire tourner dans un interpréteur, ce qui peut améliorer l’autonomie et limiter la chauffe du téléphone quand on fait tourner des jeux de 2008
(Avis sans intérêt omis)
Si on interprète largement la « possibilité de blocage », alors, par exemple, « appliquer un verrouillage régional pour que les moteurs de navigateur alternatifs ne puissent être distribués qu’aux comptes Apple japonais » pourrait aussi être considéré comme un empêchement de facto de l’existence même de navigateurs alternatifs. Dans un cas pareil, la cible serait trop réduite pour que Mozilla ait une raison de porter Firefox sur iOS. C’est peu probable, mais cela pourrait peut-être être un petit point de départ pour le libre choix du navigateur à l’échelle mondiale
Restreindre par région pour n’autoriser les moteurs de navigateur alternatifs qu’à certains comptes, c’est justement l’une des choses qu’Apple fait dans l’UE
De ce que je sais, Gecko (le moteur de Firefox) a déjà été porté sur iOS
La part de marché est déjà faible à la base, donc je doute qu’ils fassent le portage juste pour gratter une toute petite fraction supplémentaire
Mozilla est de toute façon une organisation habituée aux petites parts de marché. Cette situation ne serait pas très différente, et cela pourrait même être l’occasion de distribuer une version de QA via les utilisateurs avant l’ouverture complète du marché
Après l’UE et le Royaume-Uni, le Japon met lui aussi un terme à l’interdiction des moteurs de navigateur alternatifs sur iOS. Ce sont trois gros marchés, donc je me demande si cela crée enfin une incitation suffisante pour que Chrome ou Firefox investissent dans des versions iOS avec leur propre moteur (autrement dit, des navigateurs basés sur Blink et Gecko). On a longtemps entendu dire que le développement prenait du retard pour cette raison
Sur le même site, j’ai vu qu’Apple continue malgré tout à mettre toutes sortes de bâtons dans les roues aux grands éditeurs de navigateurs pour les empêcher de lancer leur propre moteur blog associé
Pour le Royaume-Uni, j’ai cru comprendre que le gouvernement appliquait mollement les lois concernées, comme le Digital Markets Act 2024
Dans la culture japonaise, ce genre de changement ne suscitera probablement pas un grand intérêt. Il suffit de voir l’usage de Linux au Japon : une petite minorité très passionnée continuera à l’utiliser quoi qu’il arrive, mais le grand public prend simplement ce qui est pratique. Les gens n’aiment pas trop bidouiller le système ou les réglages
Certains pensent aussi que c’est simplement parce qu’Apple a rendu la vie tellement difficile aux développeurs de navigateurs que personne n’a réussi à franchir cette barrière
Je me demande si, pour Firefox, il ne serait pas plus réaliste et plus simple de basculer vers Blink et de coopérer avec Google pour créer un moteur alternatif sur iOS
Je me demande si ce changement est vraiment une bonne chose. N’est-ce pas simplement un moyen de faire encore grimper la part de Chromium sur le marché ?
Safari n’est pas structurellement un bon navigateur. Les intérêts d’Apple l’amènent à affaiblir volontairement la plateforme web. La vraie concurrence, ce n’est pas de forcer les gens à utiliser un navigateur qui ne tient pas la route, c’est de construire un navigateur vraiment bon que les utilisateurs choisissent d’eux-mêmes
C’est vrai. Au fond, Safari était le dernier rempart qui empêchait le web sur iOS de devenir du « All Chrome Everywhere »
Les gouvernements peuvent aussi s’attaquer aux monopoles de marché wiki sur le procès du DOJ américain contre Google
Exactement, c’est bien ce qui rend la question compliquée. D’un côté, il faut absolument forcer Apple à ouvrir davantage iOS, mais de l’autre, cela renforce au final la domination de Chrome
Le gros avantage, c’est qu’on pourrait enfin utiliser un vrai Firefox sur iOS. Et c’est un changement positif. Cela réduit l’influence injustifiée d’Apple quand l’entreprise affaiblit les standards du web pour ses propres intérêts (par exemple en freinant la prise en charge de SPIR-V dans WebGPU)
(Narrateur) Un an plus tard, au Japon, la part de marché de Chrome a atteint 100 %, et tous les sites web sont conçus exclusivement pour ce navigateur
Le Japon entretient une relation particulière avec Apple. Par exemple, la fonction de billetterie basée sur FeliCa (le système NFC japonais) est intégrée à tous les iPhone, ce qui permet même aux utilisateurs iOS du monde entier de vivre bien plus facilement au Japon. Plus étonnant encore, pour utiliser concrètement ces titres, aucune appli n’est nécessaire : Apple Pay suffit. Cette tendance réduit progressivement l’avantage propre aux applis natives (même si elles ont encore des atouts spécifiques), mais en même temps, il devient difficile de réfuter l’idée qu’Apple ne fait que déplacer son rôle de « gatekeeper » vers d’autres domaines
La prise en charge du réseau FeliCa s’explique surtout par le fait que les technologies japonaises de transport mobile et de paiement étaient déjà bien établies avant l’iPhone. Il existait déjà Mobile Suica et Osaifu-Keitai, donc Apple devait sérieusement s’aligner pour rester compétitif. Cela a commencé avec des iPhone SKU spécifiques au Japon avant d’être étendu au niveau mondial. Même aujourd’hui, le marché du paiement mobile n’est pas monopolistique au Japon. Quand Apple subit une pression concurrentielle, des évolutions se produisent, comme l’ajout de l’Express Transit pour Suica. Et des applis de paiement par QR code japonaises comme PayPay sont encore plus répandues que les paiements par carte bancaire
La part de marché d’iOS au Japon est même plus élevée qu’aux États-Unis (59 %), au Royaume-Uni (47 %) ou en Europe (34 %) : elle atteint 64 % source Statcounter
FeliCa, c’est une question de licences de brevets. Apple semble avoir obtenu quelque part un contrat avantageux. Même les Google Pixel ont tous la puce, mais sur les modèles non japonais, la fonctionnalité est bloquée côté logiciel (on peut la débloquer avec le root)
On voit bien la puissance du « pouvoir de faire ». Quand un pays y arrive, d’autres pays qui disaient depuis vingt ans que c’était impossible se mettent à changer en se disant : « nous aussi, on peut le faire, on ne va pas rester à la traîne »
Il faut bien supposer que Google se prépare depuis longtemps à sortir le « vrai » Chrome sur iOS. Ils ont sûrement commencé à le développer bien avant pour pouvoir le lancer immédiatement au moment d’un changement législatif, non ?
Google est en train de porter Blink (le moteur de Chrome sur iOS), avec des progrès progressifs. Il y a un suivi ouvert sur le bug tracker de Chromium lien de suivi. Probablement qu’à cause du verrouillage régional d’Apple (EU geofencing) et des nombreuses limitations de BrowserEngineKit, ils n’y ont pas encore consacré toutes les ressources nécessaires pour un vrai service en production
Février 2023 : « Google commence à faire tourner Chrome sur iOS avec le moteur Blink au lieu d’Apple WebKit » article associé
(Blink est le moteur de rendu web de Chrome.) Dans la documentation officielle expliquant comment builder Chromium/Chrome pour iOS, il est indiqué que la « blink web platform » est expérimentale et réservée à l’analyse. Il est précisé que les cibles
content_shelletchromesont utiles à cet effet. documentation officielle de build