Comme nous l’indiquions récemment, Apple a décidé de faire sauter la possibilité d’installer des applications web (PWA) dans iOS avec la mise à jour 17.4 en Europe.
Selon Apple, cette décision a été prise pour deux raisons : elle est peu utilisée et il aurait été trop complexe de la préserver avec les changements envisagés. iOS 17.4 permet en effet aux éditeurs d’intégrer leur propre moteur de rendu dans leurs navigateurs. Pour Apple, remettre en place la même infrastructure pour ces moteurs que pour Safari réclamerait trop de temps vis-à-vis du bénéfice.
Cette suppression n’est pas passée inaperçue. La Commission européenne a confirmé au Financial Times qu’elle se penchait sur la question. Elle a envoyé une série de questions à des développeurs pour recueillir leur avis sur le sujet. Apple aussi a reçu des questions, sans que l’on sache lesquelles.
Faisons remarquer qu’Apple est responsable en partie du peu d’utilisation fait des PWA sur iOS. Les notifications et leurs badges sur les icônes des PWA ne sont arrivés en effet qu’avec iOS 16.4.
Rappelons également que sans PWA, certains services ne peuvent plus fonctionner sur iOS, dont les services de jeux en streaming GeForce Now et Xbox Game Pass.
Commentaires (73)
#1
Ceci expliquant en partie cela.
#1.1
#2
Ca va être dur pour l'UE d'imposer à Apple de rétablir les PWA sachant que c'est officiellement encore [en draft]:(https://www.w3.org/TR/appmanifest) et que c'est loin d'être massivement utilisé. Et puis il faut bien avouer que PWA c'est une arnaque technico-commerciale de Google visant à faire passer des pages web pour des apps natives.
#2.1
J'ai le cas de clients qui ont besoin/envie d'une application pour leurs utilisateurs, mais qui n'ont pas le budget pour une appli native, ou qui ont des besoins qui vont à l'encontre des conditions des Stores (exemple : ils ont des services qu'ils peuvent mettre en place via de la configuration côté serveur. Comme une appli sur iOS doit pouvoir gérer TOUT le fonctionnel, et que le fonctionnel est ici géré côté serveur, on est bloqués).
Ils ont juste besoin d'une icône sur l'écran d'accueil et de la gestion des notifications : c'est justement ce à quoi servent les PWA.
Ici, on est bien dans un enfermement d'Apple.
#2.2
Historique des modifications :
Posté le 28/02/2024 à 10h37
Invoquer des raisons comme "pas le budget" ou "aller à l'encontre des conditions des Stores" ca montre bien que PWA n'est pas un réponse à un problème technique. C'est une réponse à un problème commercial.
#2.3
#2.4
#2.5
#2.6
Techniquement, ça permet :
- une maintenance simplifiée par rapport à une application native
- des mises à jour maîtrisées (c'est fait côté serveur, pas client)
- une compatibilité avec Android et (avant) iOS, et les navigateurs, pour le MÊME CODE
- une installation bien plus simple que ce qu'on voit sur les sites actuels avec "utilisez plutôt l'application" => lien vers l'appli sur le Store => installation => reprise de la navigation au début mais depuis l'application cette fois-ci : une PWA, on clique sur le bouton "installer" affiché sur la page et c'est tout
Bref, c'est pas la panacée non plus car on reste limités par les fonctionnalités prises en charge par les PWA et les navigateurs qui la font tourner, mais pour beaucoup de cas, ça peut être suffisant.
Si iOS avait pris en charge ce type d'application depuis le début des PWA, on en aurait probablement partout.
#2.7
Par contre, pour le "pas le budget", j'ai l'impression que tu n'as pas en tête la différence de prix qu'il peut y avoir entre la mise en place et la maintenance d'une application native pour Android/iOS (même avec un framework type Ionic), et la même chose avec une PWA.
Cette différence de prix est très importante pour des PME ou des groupes plus ou moins gros mais qui n'ont pas un grand budget.
Et encore, c'est sans parler du fait que parfois les PWA répondent mieux au besoin du client que l'application native.
#2.8
Mais d'un point de vue strictement technique, Apple peut affirmer qu'un éditeur peut proposer à ses clients les mêmes fonctions avec ou sans PWA.
On est tous d'accord que ce n'est pas "fair-play" de la part d'Apple de vire PWA. Mais c'est bien joué stratégiquement: ca permet a Apple de respecter le DMA tout en verrouillant davantage sa plateforme.
#2.9
Si tu veux ajouter une fonctionnalité à l'application native, il FAUT la mettre à jour. Mais surtout, pour qu'une application native puisse gérer toutes les fonctionnalités fournies par le serveur, il faut qu'elle intègre TOUTES les fonctionnalités du serveur. Or, il est inenvisageable de gérer côté client toute la diversité fonctionnelle des plugins qu'on peut ajouter à des serveurs comme Nextcloud ou Wordpress, par exemple.
Tu pourrais me rétorquer que c'est possible, même si très compliqué, mais alors je te répondrais qu'il est possible de faire ton propre iOS qui gère les PWA, et là on tomberait dans l'absurde ou la mauvaise fois. 😉
Historique des modifications :
Posté le 29/02/2024 à 23h17
Non, une application native ne peut pas faire tout ce sue fait une PWA, pour la simple et bonne raison qu'une PWA est gérée côté serveur, là où une application native est gérée côté client.
Si tu veux ajouter une fonctionnalité à l'application native, il FAUT la mettre à jour. Mais surtout, pour qu'une application nztive puisse gérer toutes les fonctionnalités fournies par le serveur, il faut qu'elle intègre TOUTES les fonctionnalités du serveur. Or, il est inenvisageable de gérer côté client toute la diversité fonctionnelle des plugins qu'on peut ajouter à des serveurs comme Nextcloud ou Wordpress, par exemple.
Tu pourrais me rétorquer que c'est possible, même si très compliqué, mais alors je te répondrais qu'il est possible de faire ton propre iOS qui gère les PWA, et là on tomberait dans l'absurde ou la mauvaise fois. 😉
#2.10
Bien sur que ca serait absurde et de mauvaise foi de la part d'Apple de dire que c'est possible sans PWA.
Tout comme ca serait absurde et de mauvaise foi de la part des développeurs de dire que c'est impossible dans une application native.
Mais je parlais juste d'arguments sur le plan légal pour contrer/conforter la décision d'Apple.
#2.11
Tu parles bien ici d'implémenter toutes les fonctionnalités de toutes les extensions d'un outils type Nextcloud, par exemple ?
La seule solution viable que j'y voit est d'intégrerune webview dans l'appli... Mais à ce moment là, ce n'est plus vraiment l'appli native qui "gère", mais plutôt le navigateur qui tourne en son sein.
Après, d'un point de vue légal, je ne sais pas du tout ce que ça peut donner. J'espère juste qu'Apple va se prendre une grosse claque et devoor accepter les PWA de nouveau pour éviter de verrouiller entièrement ses utilisateurs sur l'App Store.
#2.12
https://www.macrumors.com/2024/03/01/apple-walks-back-decision-to-disable-eu-web-apps/
Historique des modifications :
Posté le 02/03/2024 à 13h20
Apple désamorce (un peu) la situation des PWA avec l'Europe. Bon, ca oblige a voir un navigateur webkit et de ne pas upgrader en IOS 17.4
https://www.macrumors.com/2024/03/01/apple-walks-back-decision-to-disable-eu-web-apps/
#2.13
De ce que je comprends, même en 17.4, ça devrait fonctionner.
En gros, j'ai l'impression que Apple fait machine arrière toute. 🎉
#3
#3.1
C’est juste qu’il faut que le dev fasse de la gestion de cache, etc. Parce que ça peut très bien fonctionner hors ligne une PWA !
Je vais être dégoûté quand elles vont disparaître de mon téléphone…
Historique des modifications :
Posté le 28/02/2024 à 09h37
Perso j’utilise plusieurs PWA que j’ai développe pour accéder à mes services (perso). C’est transparent par rapport à un app normale !
C’est juste qu’il faut que le dev fasse de la gestion de cache, etc. Parce que ça peut très bien fonctionner hors ligne une PWA !
Posté le 28/02/2024 à 09h37
Perso j’utilise plusieurs PWA que je développe pour accéder à mes services (perso). C’est transparent par rapport à un app normale !
C’est juste qu’il faut que le dev fasse de la gestion de cache, etc. Parce que ça peut très bien fonctionner hors ligne une PWA !
#3.2
Ça revient au même que de dire que PHP c'est nul parce que plein de développeurs codent avec leurs pieds...
#3.3
#4
#4.1
https://open-web-advocacy.org/apple-attempts-killing-webapps/
#4.2
#4.3
#5
#5.1
Pas d'une PWA qui s'installe, qui a son stockage en local et qui peut s'exécuter hors-ligne.
Citation:
.
#5.2
#6
#6.1
Mais je parierais que c'est souvent du js :)
Donc le code js est "en clair" autant qu'il l'est dans une web-app traditionnelle, ou dans une appli électron.
Et comme c'est écrit avec des outils/frameworks, c'est de mon point de vue de vieux con peu lisible.
Historique des modifications :
Posté le 28/02/2024 à 12h04
En théorie, rien n'empêche que le code soit du wasm et pas du js.
Mais je parierais que c'est souvent du js :)
Donc le code js est "en clair" autant qu'il l'est dans une web-app traditionnelle, ou dans une appli électron.
Et cu que c'est écrit avec des outils/frameworks, c'est de mon point de vue peu lisible.
#6.2
#7
De nombreux services s'arrêtent, pour de multiples raisons (fermeture de la société, pas rentable, etc.). On l'a vu ces dernières années, les opérateurs qui se lancent dans la domotique et qui arrêtent par exemple. Sony qui a vendu explicitement sa PS3 avec l'option OtherOS qui a ensuite été annulé unilatéralement, etc. Je n'ai pas souvenir que dans ces cas là, que la commission européenne soit intervenue.
Je ne dis pas ça pour défendre Apple (j'aime pas leurs produits et ne les utilise pas :p). Je m'étonne juste que parce que c'est Apple qui arrête un service, on se penche sur son cas (surtout pour un service pas indispensable). Non parce que bon, une personne qui a équipé sa maison avec Orange se retrouve avec plein d'objets rendus inutilisables à cause de l'arrêt du service, cela n'a pas vraiment ému la commission européenne...
A quel point la commission européenne peut-elle obliger une entreprise à faire évoluer un produit plutôt que de l'arrêter ? Que l'Europe puisse obliger une entreprise à se mettre en conformité avec la réglementation, c'est normal. Mais cette mise en conformité ne passe pas forcément par une évolution, cela peut être un arrêt du service.
Vous avez 4h xD
#7.1
La Commission est donc en droit de vérifier si en faisant cela, Apple ne contourne pas le DMA.
On verra bien ce qu'elle dira à la fin.
#7.3
position dominanteposition de contrôleur d'accès ne pipe le jeu en imposant des conditions inéquitables (je simplifie, mais je ne suis pas très loin non plus).En retirant les PWA, tout le monde est mis à la même enseigne. Apple n'a pas plus d'avantage que les autres.
C'est "juste" les utilisateurs qui perdent une fonctionnalité. Une fonctionnalité non indispensable / non essentielle (et peu utilisée d'après Apple).
#7.5
Si Apple décidait d'ouvrir vraiment leurs systèmes aux apps tierces sans contrôle ni contrepartie, la disparition des Webapps serait moins choquante. Ce n'est pas le cas ici.
Et pour rebondir sur ton point plus haut, j'ai du mal à voir en quoi maintenir les webapps est une contrainte quelconque pour Apple, d'autant plus qu'elles restent parfaitement supportées en dehors du territoire européen.
Sauf si un détail m'échappe, ça s'apparente complètement à une pratique anticoncurrentielle (de plus, s'agissant d'Apple).
Les ordinateurs personnels font tourner n'importe quelle application sans devoir payer l'éditeur de l'OS, pourquoi diable devrait-il en être autrement sur un mobile ?
C'est pas comme si Apple perdait de l'argent sur la vente de ses devices vendus à prix d'or.
A ce prix, je veux pouvoir être libre d'installer ce que je veux sans leur contrôle et leur "sécurité".
#7.6
Je me limitais aux apps WPA. J'aurais du le préciser
Si j'ai bien compris :
- la question ne se pose pas en dehors du territoire européen, car il ne sera pas possible d'utiliser un autre moteur de rendu (cela sera obligatoirement WebKit)
- je pense que le problème que rencontre Apple, c'est que le moteur de rendu doit faire partie intégrante du coeur de son système d'exploitation (un peu comme le composant WebView en C#). Autrement dit : proposer un moteur alternatif revient à autoriser du code externe au coeur même de l'OS. Ce que refuse Apple d'un point de vue sécurité (et ça, je le comprends). L'autre solution serait de modifier le coeur de l'OS pour que le moteur de rendu ne soit plus au coeur du système. Ce qui nécessite une profonde réécriture de certaines parties, et le travail à accomplir pour cela est bien trop important par rapport à ce qui est demandé. Il est donc plus simple (et moins coûteux) de retirer une fonctionnalité afin de se conformer à la réglementation.
Bien évidemment, je peux me tromper, c'est juste comme ça que j'ai interprété leur communication (et en 30 ans de dev, je sais que ce qui semble parfois simple est en réalité complexe techniquement et inversement !)
Ca existe : ça s'appelle Android (oki oki, je sors :p)
#7.7
Je ne suis pas un spécialiste, mais si un autre moteur de rendu est géré dans un autre contexte comme celui d'une app, en quoi est-ce difficile de faire un autre type d'appel du même moteur de rendu en enlevant les barres du navigateur pour faire une PWA ?
Et pourquoi enlever si vite cette feature, alors que les moteurs de rendus alternatifs sont loin d'être prêts et opérationnels ?
Tout ceci me semble tout de même cousu de fil blanc...
#7.8
L'objectif d'Apple n'est pas de supporter toutes les solutions du monde, c'est une entreprise commerciale avant tout :)
#7.9
Je trouve qu'ils ne justifient pas ce qu'ils affirment.
J'avais abordé le sujet dans un article précédent, je recopie ce que j'avais dit :
Mais je peux me tromper, je n'ai pas d'iPhone et ne connais pas le code d'Apple. Par contre, je sais qu'ils ont tout ce qu'il faut pour isoler le contexte d'une app (pas web app) d'une autre, donc je pense qu'ils pipeautent.
Historique des modifications :
Posté le 28/02/2024 à 16h15
Voilà la justification d'Apple. Cliquer sur "Why don’t users in the EU have access to Home Screen web apps?" pour la lire.
Je trouve qu'ils ne justifient pas ce qu'ils affirment.
J'avais abordé le sujet dans un article précédent, je recopie ce que j'avais dit :
Mais je peux me tromper, je n'ai pas d'iPhone et ne connais pas le code d'Apple. Par contre, je sais qu'ils ont tout ce qu'il faut pour isoler le contexte d'une app (pas web app) d'une autre, donc je pense qu'ils pipeautent.
#7.10
Si on regarde un peu plus loin d'ailleurs, quand on lit les justifications publiques d'Apple sur son opposition à l'ouverture du store sur toutes les procédures passées et en cours, l'énergie et la mauvaise foi déployée est très cohérente avec des arrangements potentiels avec la réalité technique sur les PWA.
J'ai un iPhone, j'en suis très content, mais je ne peux m'empêcher de ressentir une forme de dégout des pratiques d'Apple, et ce depuis une bonne décennie.
L'intérêt du client est passé loin derrière l'intérêt de l'actionnaire, et ça ne serait pas un problème en soi s'il existait des alternatives. Ce n'est pas le cas, et Apple n'est pas étranger à cet état de fait.
Il est plus que temps que le régulateur sévisse (je dirais même qu'il est un peu tard).
C'est aussi valable pour d'autres acteurs hégémoniques tech dans d'autres contextes, mais c'est un autre sujet.
#7.11
Contexte de base : tu es un opérateur réseau, et pour des raisons de sécurité, toutes les IP de tes clients sont en IPv6, chacune munie d'une adresse IP publique.
Pour des raisons d'interopérabilité, compatibilité, (rajouter toute mention utile comme inutile), on t'impose de supporter l'IPv4, avec les mêmes "droits" ou "fonctionnalités". Sauf que voilà, ton architecture a été conçue autour de l'IPv6, pour profiter pleinement de toutes les possibilités offertes. En devant supporter l'IPv4, tu es :
1) obligé de mettre à jour toute une partie de ton infra
2) pour proposer les mêmes "droits" et "fonctionalités" quel que soit le protocole utilisé, tu décides de retirer les adresses IPv6 publiques (car tu ne peux pas fournir une IPv4 publique à tout le monde pour cause de pénurie), et tu vas donc restreindre les possibilités d'auto-hébergement (en même temps, ça concerne tellement peu de monde que ce n'est pas grave).
D'un point de vue du néophyte, ben c'est facile, l'IPv4 et l'IPv6 sont deux protocoles réseaux, je ne vois pas le problème.
D'un point de vue du connaisseur, c'est loin d'être aussi évident que ça car il voit toutes les implications que cela entraine. Le NAT n'a rien à voir entre l'IPv4 et l'IPv6. Il n'y a plus le souci de pénurie d'adresse, la gestion des MTU est différente, etc.
#7.12
- L'adaptation au changement est inhérent à toute entreprise, et c'est son quotidien - littéralement.
En permanence, nous devons nous adapter à des contraintes extérieures, et composer avec.
L'aléa peut venir des clients, des fournisseurs, des collaborateurs, de l'état, du propriétaire, des conjonctures économiques, de la banque, des taux directeurs, de l'actionnaire, de l'environnement, du matériel, de nouvelles normes, de la faute à pas de chance...
Avoir une contrainte de plus à gérer dans le contexte d'une boite comme Apple sur cette question de la régulation et des PWAs, bon, arrêtons de tourner autour du pot, c'est complètement mineur et gérable.
Le fond du refus n'est pas technique, et comme je le disais ailleurs, toute leur attitude autour du thème montre bien que le fond est économique et (anti-) concurrentiel.
- Ensuite, nous ne sommes pas un acteur hégémonique sur les telcos - personne ne l'est vraiment d'ailleurs, en mettant Orange de côté dans certains contextes (dont le GCBLO qui a fait parler de lui récemment par exemple).
Nous devons nous adapter ou mourir, car d'autres vont s'adapter et survivre.
Autrement dit, l'environnement au sens large contraint nos actions, et nous devons coller aux circonstances.
Nous avons déjà eu plein de questionnements autour de ces thèmes réseau, et les problèmes que nous rencontrons sont de diverses natures. Peu importe leur origine, notre job est de les régler, ou les gérer à minima.
Dans le cas d'Apple, c'est très différent.
C'est un cas rare où l'acteur a suffisamment de poids pour contraindre lui, à l'envi et à son seul profit l'ensemble des acteurs de sa sphère d'activité, qui est devenue indispensable aujourd'hui, et sans aucun contre-pouvoir. Grâce à sa position acquise de haute lutte et avec une dose certaine de travail, d'intelligence et de chance, Apple tord le bras à tous les acteurs qui se développent dans son sillage, dont les éditeurs d'apps.
C'est la stratégie du "tu vas faire quoi ?".
Apple considère qu'il fournit la plateforme aux devs, et qu'une partie de la valeur de leur travail leur revient, et que s'ils ne sont pas contents, ils n'ont qu'à mourir.
Tout le monde ferme sa gueule du coup, perd ses 20% de marge qui font la différence entre la vie et la survie (coucou Spotify), et il ne s'est rien passé de majeur pendant 10 ans.
Du point de vue d'Apple et des actionnaires, c'est un move rationnel.
Du point de vue général, à quel moment c'est normal de prendre 20% de la valeur de l'ensemble des services du service software portable mondial, quand il n'y a pas de plateforme alternative, que le matériel est déjà chèrement vendu, et que la valeur d'intermédiation du Store est nulle (c'est un serveur de fichiers quoi) ?
- Allons au bout de la projection, et développons le thème de la concurrence déloyale dans un autre domaine.
Imaginons qu'un acteur, Cerberus Industries, à force de travail, d'intelligence et de chance, développe un procédé de culture révolutionnaire de tous les légumes qui divise leur coût de production par trois.
Il prend le monde agricole de vitesse, tue rapidement la concurrence sur quelques années, et devient incontournable sur le marché.
Tant qu'il en reste là, c'est de la compétition commerciale, et dans le sens de l'intérêt général, ça se défend.
Bon, c'est bien la merde pour les agriculteurs, mais mettons qu'ils ont été parfaitement recasés, et qu'on a crevé toutes les roues de leurs tracteurs en même temps, préventivement comme dirait José Garcia.
Fort de sa position, Cerberus quadruple les prix.
Protestations générales, la filiale historique est morte, la concurrence est impossible, et Cerberus de nous dire, dans une douce ironie, "qu'on n'a qu'à manger des pommes".
Sans régulateur, et par ruse, l'intérêt général se retrouve annihilé au profit d'un intérêt particulier.
Une organisation n'a d'intérêt pour ses clients que si elle rend un service dans des conditions équitables.
Si les conditions sont déséquilibrées dans des proportions qui atteignent directement l'intérêt général, quel est l'intérêt pour la collectivité de maintenir l'acteur dans sa position ?
Une entreprise, même privée, même géniale, se doit d'être globalement au service de son environnement, tout comme une cellule dans un organisme, ou a minima de ne pas trop le dégrader.
Dans ce dernier cas, si la cellule devient nocive, l'organisme se défend, et ce n'est pas seulement normal.
C'est vital.
Historique des modifications :
Posté le 28/02/2024 à 19h38
Jouons !
- L'adaptation au changement est inhérent à toute entreprise, et c'est son quotidien - littéralement.
En permanence, nous devons nous adapter à des contraintes extérieures, et composer avec.
L'aléa peut venir des clients, des fournisseurs, des collaborateurs, de l'état, du propriétaire, des conjonctures économiques, de la banque, des taux directeurs, de l'actionnaire, de l'environnement, du matériel, de nouvelles normes, de la faute à pas de chance...
Avoir une contrainte de plus à gérer dans le contexte d'une boite comme Apple sur cette question de la régulation et des PWAs, bon, arrêtons de tourner autour du pot, c'est complètement mineur et gérable.
Le fond du refus n'est pas technique, et comme je le disais ailleurs, toute leur attitude autour du thème montre bien que le fond est économique et (anti-) concurrentiel.
- Ensuite, nous ne sommes pas un acteur hégémonique sur les telcos - personne ne l'est vraiment d'ailleurs, en mettant Orange de côté dans certains contextes (dont le GCBLO qui a fait parler de lui récemment par exemple).
Nous devons nous adapter ou mourir, car d'autres vont s'adapter et survivre.
Autrement dit, l'environnement au sens large contraint nos actions, et nous devons coller aux circonstances.
Nous avons déjà eu plein de questionnements autour de ces thèmes réseau, et les problèmes que nous rencontrons sont de diverses natures. Peu importe leur origine, notre job est de les régler, ou les gérer à minima.
Dans le cas d'Apple, c'est très différent.
C'est un cas rare où l'acteur a suffisamment de poids pour contraindre lui, à l'envi et à son seul profit l'ensemble des acteurs de sa sphère d'activité, qui est devenue indispensable aujourd'hui, et sans aucun contre-pouvoir. Grâce à sa position acquise de haute lutte et avec une dose certaine de travail, d'intelligence et de chance, Apple tord le bras à tous les acteurs qui se développent dans son sillage, dont les éditeurs d'apps.
C'est la stratégie du "tu vas faire quoi ?".
Apple considère qu'il fournit la plateforme aux devs, et qu'une partie de la valeur de leur travail leur revient, et que s'ils ne sont pas contents, ils n'ont qu'à mourir.
Tout le monde ferme sa gueule du coup, perd ses 20% de marge qui font la différence entre la vie et la survie (coucou Spotify), et il ne s'est rien passé de majeur pendant 10 ans.
Du point de vue d'Apple et des actionnaires, c'est un move rationnel.
Du point de vue général, à quel moment c'est normal de prendre 20% de la valeur de l'ensemble des services du service software portable mondial, quand il n'y a pas de plateforme alternative, que le matériel est déjà chèrement vendu, et que la valeur d'intermédiation de Store est nulle (c'est un serveur de fichiers quoi) ?
- Allons au bout de la projection, et développons le thème de la concurrence déloyale dans un autre domaine.
Imaginons qu'un acteur, Cerberus Industries, à force de travail, d'intelligence et de chance, développe un procédé de culture révolutionnaire de tous les légumes qui divise leur coût de production par trois.
Il prend le monde agricole de vitesse, tue rapidement la concurrence sur quelques années, et devient incontournable sur le marché.
Tant qu'il en reste là, c'est de la compétition commerciale, et dans le sens de l'intérêt général, ça se défend.
Bon, c'est bien la merde pour les agriculteurs, mais mettons qu'ils ont été parfaitement recasés, et qu'on a crevé toutes les roues de leurs tracteurs en même temps, préventivement comme dirait José Garcia.
Fort de leur position, Cerberus quadruple les prix.
Protestations générales, la filiale historique est morte, la concurrence est impossible, et Cerberus de nous dire, dans une douce ironie, "qu'on n'a qu'à manger des pommes".
Sans régulateur, et par ruse, l'intérêt général se retrouve annihilé au profit d'un intérêt particulier.
Une organisation n'a d'intérêt pour ses clients que si elle rend un service dans des conditions équitables.
Si les conditions sont déséquilibrées dans des proportions qui atteignent directement l'intérêt général, quel est l'intérêt pour la collectivité de maintenir l'acteur dans sa position ?
Une entreprise, même privée, même géniale, se doit d'être globalement au service de son environnement, tout comme une cellule dans un organisme, ou a minima de ne pas trop le dégrader.
Dans ce dernier cas, si la cellule devient nocive, l'organisme se défend, et ce n'est pas seulement normal.
C'est vital.
#7.13
Un petit Quake III Arena ça me détendrait bien. Je suis partant :)
(désolé pour l'apparté)
J'avoue ne pas trop comprendre ton message. D'un côté, tu précises ne pas être un expert (d'un point de vue technique dans le dev j'entends), mais là, tu affirmes sans autre considération que le choix d'Apple est purement commercial et non technique, et enchaine sur des considérations purement commerciales. Du coup, je m'interroge.
Je ne cherche pas à défendre Apple (comme déjà dit, je ne suis pas trop fan de leur politique). Mais le dev étant mon domaine de compétence depuis de nombreuses années, les arguments "techniques" qu'ils avancent sont tout à fait plausibles.
Ce qui parait simple (d'un point de vue utilisateur) peut parfois être compliqué (d'un point de vue technique) et inversement.
#7.14
Je ne doute pas que le dev pour permettre à un autre moteur de rendu web de fonctionner sous iOS soit du travail, certainement très conséquent dans l'absolu.
J'ai plus de doutes sur le sujet web apps, qui semble être une vue dans un autre contexte du travail initial qu'une réelle restructuration du code, mais c'est là un uneducated guess, tu as raison.
Un des problèmes de cette affaire est là d'ailleurs, pas grand monde crédible et libre de s'exprimer sur le sujet ne sait vraiment, sauf la communication officielle d'Apple, qui est tout sauf impartiale sur le sujet.
Ce que je soutiens rapidement dans mon message, c'est qu'à l'échelle d'Apple, je suis convaincu que c'est une évolution technique soutenable, et qu'Apple est de mauvaise foi.
Pour deux raisons.
La première, c'est qu'Apple a fait d'iOS sa vache à lait depuis 10 ans, je ne doute pas qu'ils soient très habiles à le faire évoluer. Et ils en ont largement les moyens financiers.
Que les gars parlent de mettre de l'IA locale à toutes les sauces dans iOS 18 d'un côté et ne soient pas capables de faire évoluer leur plateforme de façon "sécurisée" pour une vue d'un moteur de rendu web qui aurait droit de cité sur le système dans l'absolu me fait un peu tiquer.
La seconde est inhérente à la position d'Apple sur le sujet.
Je suis allé parcourir la page d'explication d'Apple que Fred42 a communiqué plus haut
https://developer.apple.com/support/dma-and-apps-in-the-eu#ios-app-eu
Apple ne parle QUE de sécurité pour justifier l'impossible adaptation des Home Screens Apps - et sans que personne ne puisse vérifier d'ailleurs.
J'ai beaucoup de mal avec cet argument, il est employé ad nauseam par Apple pour empêcher l'ouverture de la plateforme à d'autres sources que l'App Store depuis des années, App Store dont le processus de validation officiel est très loin d'être sécurisé lui-même.
Nous avons des ordinateurs depuis des décennies qui tournent sur des systèmes très comparables, et je n'entends pas grand monde se plaindre du fait que Mac OS ne serait pas assez sécurisé.
La sécurité est un argument trop souvent dévoyé pour faire passer toutes sortes de salades à bien des occasions.
Pour souligner l'hypothèse d'une nécessité de protéger leur position, il ne faut pas oublier non plus qu'Apple fait également la chasse aux jailbreaks, aux tentatives de rétro engineering d'iMessage, et à toute tentative d'utiliser librement leur matériel légalement acheté, alors que ce n'est pas une menace pour la sécurité du parc installé qui resterait massivement en version Vanilla.
On peut aussi parler des conditions pour l'apparition des Store alternatifs, où les problèmes ne sont pas techniques apparemment (et on pourrait penser que c'est autrement plus compliqué qu'intégrer un moteur de rendu web), mais bien commerciaux avec des conditions financières complètement délirantes et visiblement injustifiées.
Je veux bien avoir un doute raisonnable, et je ne suis pas fermé à étudier de nouvelles informations inédites et documentées sur le sujet des PWAs, mais mon intuition me hurle que dans cette affaire, qu'Apple nous balade menu.
Une nouvelle fois.
My 50 cents.
Historique des modifications :
Posté le 28/02/2024 à 22h23
Désolé, j'ai pris ta tentative de parler des telcos comme une forme d'ouverture générale du sujet, et je m'en suis peut-être trop éloigné du coup.
Je ne doute pas que le dev pour permettre à un autre moteur de rendu web de fonctionner sous iOS soit du travail, certainement très conséquent dans l'absolu.
J'ai plus de doutes sur le sujet web apps, qui semble être une vue dans un autre contexte du travail initial qu'une réelle restructuration du code, mais c'est là un uneducated guess, tu as raison.
Un des problèmes de cette affaire est là d'ailleurs, pas grand monde crédible et libre de s'exprimer sur le sujet ne sait vraiment, sauf la communication officielle d'Apple, qui est tout sauf impartiale sur le sujet.
Ce que je soutiens rapidement dans mon message, c'est qu'à l'échelle d'Apple, je suis convaincu que c'est une évolution technique soutenable, et qu'Apple est de mauvaise foi.
Pour deux raisons.
La première, c'est qu'Apple a fait d'iOS sa vache à lait depuis 10 ans, je ne doute pas qu'ils soient très habiles à le faire évoluer. Et ils en ont largement les moyens financiers.
Que les gars parlent de mettre de l'IA locale à toutes les sauces dans iOS 18 d'un côté et ne soient pas capables de faire évoluer leur plateforme de façon "sécurisée" pour une vue d'un moteur de rendu web qui aurait droit de cité sur le système dans l'absolu me fait un peu tiquer.
La seconde est inhérente à la position d'Apple sur le sujet.
Je suis allé parcourir la page d'explication d'Apple que Fred42 a communiqué plus haut
https://developer.apple.com/support/dma-and-apps-in-the-eu#ios-app-eu
Apple ne parle QUE de sécurité pour justifier l'impossible adaptation des Home Screens Apps - et sans que personne ne puisse vérifier d'ailleurs.
J'ai beaucoup de mal avec cet argument, il est employé ad nauseam par Apple pour empêcher l'ouverture de la plateforme à d'autres sources que l'App Store depuis des années, App Store dont le processus de validation officiel est très loin d'être sécurisé lui-même.
Nous avons des ordinateurs depuis des décennies qui tournent sur des systèmes très comparables, et je n'entends pas grand monde se plaindre du fait que Mac OS ne serait pas assez sécurisé.
La sécurité est un argument massivement dévoyé pour faire passer toutes sortes de salades à bien des occasions.
Pour souligner l'hypothèse d'une nécessité de protéger leur position, il ne faut pas oublier non plus qu'Apple fait également la chasse aux jailbreaks, aux tentatives de rétro engineering d'iMessage, et à toute tentative d'utiliser librement leur matériel légalement acheté, alors que ce n'est pas une menace pour la sécurité du parc installé qui resterait massivement en version Vanilla.
On peut aussi parler des conditions pour l'apparition des Store alternatifs, où les problèmes ne sont pas techniques apparemment (et on pourrait penser que c'est autrement plus compliqué qu'intégrer un moteur de rendu), mais bien commerciaux avec des conditions financières complètement délirantes et visiblement injustifiées.
Je veux bien avoir un doute raisonnable, et je ne suis pas fermé à étudier de nouvelles informations inédites et documentées sur le sujet des PWAs, mais mon intuition me hurle que dans cette affaire, qu'Apple nous balade menu.
Une nouvelle fois.
My 50 cents.
Posté le 28/02/2024 à 22h34
Désolé, j'ai pris ta tentative de parler des telcos comme une forme d'ouverture générale du sujet, et je m'en suis peut-être trop éloigné du coup.
Je ne doute pas que le dev pour permettre à un autre moteur de rendu web de fonctionner sous iOS soit du travail, certainement très conséquent dans l'absolu.
J'ai plus de doutes sur le sujet web apps, qui semble être une vue dans un autre contexte du travail initial qu'une réelle restructuration du code, mais c'est là un uneducated guess, tu as raison.
Un des problèmes de cette affaire est là d'ailleurs, pas grand monde crédible et libre de s'exprimer sur le sujet ne sait vraiment, sauf la communication officielle d'Apple, qui est tout sauf impartiale sur le sujet.
Ce que je soutiens rapidement dans mon message, c'est qu'à l'échelle d'Apple, je suis convaincu que c'est une évolution technique soutenable, et qu'Apple est de mauvaise foi.
Pour deux raisons.
La première, c'est qu'Apple a fait d'iOS sa vache à lait depuis 10 ans, je ne doute pas qu'ils soient très habiles à le faire évoluer. Et ils en ont largement les moyens financiers.
Que les gars parlent de mettre de l'IA locale à toutes les sauces dans iOS 18 d'un côté et ne soient pas capables de faire évoluer leur plateforme de façon "sécurisée" pour une vue d'un moteur de rendu web qui aurait droit de cité sur le système dans l'absolu me fait un peu tiquer.
La seconde est inhérente à la position d'Apple sur le sujet.
Je suis allé parcourir la page d'explication d'Apple que Fred42 a communiqué plus haut
https://developer.apple.com/support/dma-and-apps-in-the-eu#ios-app-eu
Apple ne parle QUE de sécurité pour justifier l'impossible adaptation des Home Screens Apps - et sans que personne ne puisse vérifier d'ailleurs.
J'ai beaucoup de mal avec cet argument, il est employé ad nauseam par Apple pour empêcher l'ouverture de la plateforme à d'autres sources que l'App Store depuis des années, App Store dont le processus de validation officiel est très loin d'être sécurisé lui-même.
Nous avons des ordinateurs depuis des décennies qui tournent sur des systèmes très comparables, et je n'entends pas grand monde se plaindre du fait que Mac OS ne serait pas assez sécurisé.
La sécurité est un argument trop souvent dévoyé pour faire passer toutes sortes de salades à bien des occasions.
Pour souligner l'hypothèse d'une nécessité de protéger leur position, il ne faut pas oublier non plus qu'Apple fait également la chasse aux jailbreaks, aux tentatives de rétro engineering d'iMessage, et à toute tentative d'utiliser librement leur matériel légalement acheté, alors que ce n'est pas une menace pour la sécurité du parc installé qui resterait massivement en version Vanilla.
On peut aussi parler des conditions pour l'apparition des Store alternatifs, où les problèmes ne sont pas techniques apparemment (et on pourrait penser que c'est autrement plus compliqué qu'intégrer un moteur de rendu), mais bien commerciaux avec des conditions financières complètement délirantes et visiblement injustifiées.
Je veux bien avoir un doute raisonnable, et je ne suis pas fermé à étudier de nouvelles informations inédites et documentées sur le sujet des PWAs, mais mon intuition me hurle que dans cette affaire, qu'Apple nous balade menu.
Une nouvelle fois.
My 50 cents.
#7.15
Simplement, concernant les PWA, j'avoue que je reste plutôt sceptique sur l'argument purement marketing. Tu rappelles, et à juste titre, toutes les manœuvres réalisées pour décourager les stores alternatifs, les moteurs de rendu pour les navigateurs et autres joyeuseries liées au DMA.
Cela me semble tellement dérisoire de rajouter une petite touche sur les PWA à la vue de toutes les autres énormités qu'ils ont mis en place. Cela me semble vraiment ridicule. Bien sûr, je peux tout à fait me tromper. Mais pour le coup, l'argument technique me parait beaucoup plus plausible que l'argument marketing (bien que l'un n'empêche pas l'autre, je l'admet).
L'argument sécuritaire d'Apple, c'est qu'en l'état, il n'est pas possible de garantir une isolation de chaque PWA. A priori, aujourd'hui c'est fait par le moteur même. Changer de moteur implique donc que la séparation ne soit plus garantie. Autrement dit, en changeant de moteur de rendu (et toujours en l'état actuel des choses) les applications auront accès aux données des autres applications. Ce qui n'est pas forcément souhaitable.
Est-ce qu'Apple à les reins suffisamment solides pour faire les modifications, je pense pouvoir affirmer sans trop me tromper que oui. Maintenant, est-ce qu'elle a l'obligation de le faire ? Non. Est-ce que légalement, on peut l'obliger à le faire ? Je ne suis pas certains non plus. On peut l'obliger à respecter un cadre réglementaire (comme le DMA), mais il ne me semble pas possible de lui dire comment le faire (si un juriste passe par là pour confirmer). Si pour respecter le DMA, Apple souhaite retirer une fonctionnalité, cela me parait difficile de l'y contraindre, à moins que le support des PWA soit inclus directement dans le DMA (ce dont je doute fortement).
Par contre, une fonctionnalité prévue par contrat qui serait retirée (par ex. désactivation complète du NFC), là, je pense qu'il serait possible d'agir. Mais ce serait par "rupture de contrat" et non pas dans le cadre d'un nouveau cadre. Et ce serait à chaque utilisateur d'agir, pas à l'Europe.
#7.17
En appliquant le principe du rasoir d'Ockham, et sachant qu'Apple a déjà été mesquin à de multiples reprises par le passé (les exemples sont nombreux, qu'on parle de chiffonnette, de propriété intellectuelle sur le symbole de la pomme, de la politique de validation des apps, du ghosting des journaux Mac un peu trop indépendants, de tout ce qui s'approche de près ou de loin à leurs intérêts.....), sachant le contexte de cette décision, toute leur attitude depuis toujours autour du sujet de l'ouverture d'iOS, et sachant aussi qu'ils ont des ressources devs conséquentes, moi je mise tout sur l'enfumage.
C'est pas vindicatif, c'est juste de la logique.
#7.18
Avec le rasoir d'Ockahm (dont je suis un fervent utilisateur ^^) j'arrive à la conclusion que ce n'est pas pour des raisons marketing, mais technique : PWA est peu utilisée, PWA ne rapporte rien (pas de commission), le support de moteur de rendu aurait un coût de dev plus ou moins conséquent, c'est loin d'être indispensable => poubelle.
C'est peut-être aussi ma vision de chef d'entreprise qui veut ça. Et comme je le disais dans un autre commentaire, les deux visions ne sont pas forcément contradictoire. Il peut s'agir des deux !
Après, pour le reste, je suis entièrement d'accord avec toi (sauf que moi je n'ai pas d'iPhone :p). Apple sait faire preuve de beaucoup d'imagination pour mettre des bâtons dans les roues. Elle nous l'a montré à mainte reprises par le passé. Mais là, c'est tellement "easy" comme méthode (pour l'abandon du PWA hein) que je me dis que cela ne leur ressemble pas ! Il nous ont habitué à "mieux" (le mieux est ironique hein !!!)
#7.19
L’avenir nous éclairera peut être un jour sur cette décision d’Apple.
Tiens, d’ailleurs, pierre de plus dans mon jardin, en serrant la vis sur les pwas, ils ferment la dernière possibilité de ne pas passer par leur store (les stores alternatifs étants en pratique insoutenables avec leurs nouvelles propositions).
Je trouve ça mesquin enough, moi !
#7.21
Tel est pris qui croyait prendre. Bien joué. Et c'est de bonne guerre
Je n'avais pas vu ça sous cet angle. Je l'avoue. En même temps, je n'ai pas une formidable expérience avec les PWAs. J'ai des comportements "agaçants" :
- tu le lances, il freeze, obliger de le fermer complètement et de le rouvrir
- parfois, quand je le lance, il se ferme direct. Obligé de le rouvrir
- sans compter les limitations d'API
PS : après vérification, les limitations sont moins vrai aujourd'hui qu'à une époque pas si lointaine. De nombreuses API sont maintenant disponibles. Donc à moins d'avoir besoin des contacts, des SMS, du NFC, de faire des Widgets ou autre truc un peu plus poussé d'un point de vue intégration avec le téléphone, c'est a priori utilisable.
[edit]
Après, niveau API, il faut faire attention au support par les navigateurs. Certains sont très en avance (Chrome) par rapport à d'autres (Safari).
Historique des modifications :
Posté le 29/02/2024 à 18h34
Tel est pris qui croyait prendre. Bien joué. Et c'est de bonne guerre
Je n'avais pas vu ça sous cet angle. Je l'avoue. En même temps, je n'ai pas une formidable expérience avec les PWAs. J'ai des comportements "agaçants" :
- tu le lances, il freeze, obliger de le fermer complètement et de le rouvrir
- parfois, quand je le lance, il se ferme direct. Obligé de le rouvrir
- sans compter les limitations d'API
PS : après vérification, les limitations sont moins vrai aujourd'hui qu'à une époque pas si lointaine. De nombreuses API sont maintenant disponibles. Donc à moins d'avoir besoin des contacts, des SMS, du NFC, de faire des Widgets ou autre truc un peu plus poussé d'un point de vue intégration avec le téléphone, c'est a priori utilisable.
#7.22
Tiens donc.
#7.23
À cette fin, les web apps ajoutées à l’écran d’accueil reposeront toujours sur WebKit et uniquement sur lui.
Voilà pourquoi ils ont changé d'avis sans que ça leur coûte. Ils font comme avant avec leur moteur de rendu web.
Cela me semble non conforme au DMA. Le 7 de l'article 5 du DMA que j'avais cité ici interdisant d'imposer un navigateur internet.
Édit : correction du lien
Historique des modifications :
Posté le 01/03/2024 à 17h41
On y lit :
À cette fin, les web apps ajoutées à l’écran d’accueil reposeront toujours sur WebKit et uniquement sur lui.
Voilà pourquoi ils ont changé d'avis sans que ça leur coûte. Ils font comme avant avec leur moteur de rendu web.
Cela me semble non conforme au DMA. Le 7 de l'article 5 du DMA que j'avais cité ici interdisant d'imposer un navigateur internet.
#7.24
Je vois...
Je vois....
Je vois qu'ils sont plus exposés sur l'ouverture des apps en général que sur les moteurs de rendu web en particulier dans cette affaire.
Ils ont dû tenter le truc discret pour avoir une petite compensation mesquine à l'ouverture potentielle du Store à d'autres acteurs, qu'ils savent inévitable, et pas forcément selon leurs termes.
C'était le moment d'avoir une approche ferme, quitte à ouvrir leur position au fil des négos.
Vu que ça commençait à se voir cette histoire des PWAs, leurs avocats ont dû leur dire de ne pas risquer de voir cette limitation se retourner contre eux.
C'est somme toute assez mineur pour eux, comparativement au reste du dossier.
My 50 euros (vous n'iriez pas voir un voyant à 50 cents, ne faites pas cette tête).
#7.27
Mais ce n'est pas une négo, c'est plus proche d'un procès. La Commission a ici un pouvoir de sanction et la crédibilité des DSA et DMA en dépend et je n'ai pas l'impression que Thierry Breton soit prêt à la négociation.
Les contrôleurs d'accès (pour le DMA) et les plateformes (pour le DSA) n'ont pas intérêt à jouer au plus fin.
Ils pourront faire traîner et contester auprès de la CJUE, mais ils risquent bien de perdre au final.
#7.25
Le DMA mentionné explicitement l'usage d'un moteur de rendu au sein d'un navigateur internet, car cela viendrait influer grandement impacter les possibilités et les performances des navigateurs.
Une PWA n'est pas un navigateur. C'est une application. Elle repose sur un moteur de rendu pour son fonctionnement, mais cela reste une application et l'éditeur n'est pas contraint à ce choix. Il peut utiliser des alternatives, notamment en développant une application native.
En bref, c'est un beau casse tête, juridiquement parlant.
#7.26
Une PWA s'appuie sur un navigateur (et pas le seul moteur de rendu) si j'en crois l'article en anglais de Wikipédia.
Et ici, Apple impose à la fois aux utilisateurs et aux entreprises utilisatrices d'utiliser son navigateur WEB pour les PWA.
Je ne vois pas comment cela peut être conforme au DMA.
Si une entreprise choisit de faire une PWA et pas une application native ni une application en techno web qui embarque son propre moteur de rendu, Apple ne doit pas lui imposer Safari/Webkit.
#7.28
Une application n'est pas nécessairement un PWA. Le développeur à le choix, et dans ce sens, Apple n'impose pas de moteur de rendu (ou de navigateur) pour le développement d'une application.
L'utilisateur a le choix aussi. Il peut utiliser ou pas l'application. Ou utiliser une alternative.
Dans le cas du navigateur, l'utilisateur se retrouvait, avant le DMA, à utiliser quoi qu'il arrive Webkit.
Pour résumer :
- le développeur n'est pas contraint à utiliser Webkit
- l'utilisateur n'est pas contraint par le choix du contrôleur d'accès (ici Apple), mais par le choix des développeurs.
Apple n'exige pas/plus des utilisateurs d'application d'utiliser Webkit.
Apple n'exige pas/plus des éditeurs qu'ils utilisent Webkit pour développer une application.
Les développeurs sont libres de faire du PWA ou du natif.
Dans le cas d'une application PWA, alors Webkit sera utilisé.
On peut trouver ça limite (et je trouve que cela l'est), mais juridiquement parlant, je ne pense pas qu'on puisse qualifier cela d'exigence dans la mesure où des alternatives existes. Et si ce n'est pas une exigence, ce n'est pas contraire au DMA.
Après, ce n'est que mon interprétation. Attendons de voir l'analyse que fera la commission européenne à ce sujet. C'est son analyse qui fera foi, pas nos avis respectifs !
#7.29
Avant le DMA, on pouvait dire ; les développeurs ont le choix de ne pas développer des application natives sur iOS et de ne pas utiliser le store d'Apple ; c'est le choix des développeurs de développer sur iOS qui les obligent à utiliser le store d'Apple.
Mais l'UE a décidé que ce genre d'arguments (que certains ici défend(ai)ent) n'étaient pas acceptable.
Elle a donc décidé qu'il fallait obliger les contrôleurs d'accès à autoriser les stores alternatifs, les services de paiement alternatifs, l'accès au NFC pour les paiements et les navigateurs alternatifs.
Là, Apple, dans un cas particulier ne donne pas le choix du navigateur ni au développeur ni à l'utilisateur.
C'est d'autant plus dommageable que les PWA sur Safari étaient ou sont toujours moins complètes que sur Chrome (par exemple).
#7.30
Une PWA ne peut pas faire tout ce que fais une application native, une application native peut faire tout ce que fait une PWA, sans compter qu'Apple à un droit de vie ou de mort d'une application sur l'Apple Store. Pour un certain nombre d'applications, l'application native était la seule solution. Notons également que les PWA sont disponibles depuis 2018 seulement (et avec encore moins de droit à l'époque par rapport à aujourd'hui) par rapport aux applications natives qui ont débarqués en 2008 (10 ans d'écart).
Là où je veux en venir, c'est que mon interprétation ou la tienne du "jargon juridique" (sans aucun sens péjoratif ici) n'a pas de valeur. Seule compte celle des autorités (ici l'Europe).
On peut prendre l'exemple des paywall pour les cookies, où, pour beaucoup, cela enfreint le caractère libre du consentement (qui est, pour rappel, un des 4 critères pour que le consentement soit valide). Pourtant, cela a été validé, dans une certaine mesure, par les CNILs.
L'extrait que tu cites du DMA est très intéressant, mais sa compréhension dépend de l'interprétation de certains termes, interprétation d'un point de vue juridique, pas d'un point de vue technique, notamment sur la notion de "navigateur internet" (et pour savoir si on considère qu'une PWA utilise un navigateur ou un moteur de rendu) et sur la notion "d'exigence" en présence d'alternative.
Que les choses soient claires. Je ne cherche pas à dire que tu as tord et moi raison sur le fait que cela enfreigne potentiellement le DMA (on s'en fout, et ce sont les autorités qui trancheront à ce sujet). Je cherchais juste à montrer que la conformité au DMA dépend de l'interprétation juridique que l'on fait des termes, afin de répondre à ton interrogation de savoir comment cela pourrait être conforme au DMA ;)
#7.31
Et pour les paywall de coockies, on verra ce qui va sortir de l'affaire Méta et ses abonnements payants.
Tu dis que les CNILs les ont validé dans une certaine mesure, tu as des exemples ?
La seule chose que j'ai en tête à ce sujet, mais c'est peut-être que j'en ai raté ou oublié, c'est la décision de notre Conseil d'État qui a dit à la CNIL qu'elle ne pouvait pas dire dans ses recommandations (soft law) que les coockies walls étaient interdits parce que ça dépendait entre autre des offres des concurrents. Par exemple, Marmiton pouvait mettre un cookie wall si les recettes restaient accessibles sur d'autres sites.
Et la CNIL française a donc modifié son discours général sur ce sujet puisque la décision du Conseil d'État s'imposait à elle. Cela n'empêchera pas forcément de prendre des décisions contre les cookies wall dans des affaires précises.
#7.32
Et puis, pourquoi qu'on gueule sinon
De ce que j'ai retenu, le conseil d'état a surtout rappelé à la CNIL qu'elle ne pouvait pas interdire quelque chose par principe, car cela sortait de ses attributions.
La CNIL a ensuite revu un peu sa copie, et donner des consignes / critères d'évaluation pour déterminer la "conformité" des cookie-walls. On peut retrouver tout cela sur sa page dédiée au cookie-walls, notamment avec la notion de "tarif raisonnable", tout en rappelant que le paywall n'est pas "interdit par principe".
Pour finir, l'affaire Meta ne concernera au final que... Meta. La CNIL rappelle en effet que la détermination d'un tarif raisonnable dépend d'une analyse au cas par cas ;)
#7.33
#7.16
A l'époque Jobs, Apple était une boite d'enflure, mais qui essayait de garder un semblant de bon copain en dosant ce qui rentre et ce qui sort pour que les gens soient content tout en s'en mettant plein les poches. C'est "fair".
Maintenant à l'époque Cooks, c'est fini, c'est juste devenu une boite de raclure. Le premier prix est à 1000€, l'OS est toujours aussi fermé, Apple garde le contrôle sur absolument tout, dès que tu veux sortir de l'écosystème apple, c'est la merde: filtre photo et angle de rotation en metadata spécifique apple, pas d'accès en mode fichier à travers l'usb, ou alors juste les photos dans des dossiers nommé n'importe comment, toujours pas possible en 2024 de mettre un simple icône en bas de l'écran, l'arrivé enfin de l'usb-c après des années à se gaver sur les royalties lightning, et maintenant la fin des PWA...
D'ailleurs, comment ils savent que les PWA ne sont pas utilisées? Je croyais que le respect de la vie privée était leur priorité.
Plus globalement, Apple et Google ne payent pas (ou très peu) d’impôt et n'apportent donc aucune richesse à la France/Europe. On s'adapte et joue a peu prêt avec les même arguments que Apple envers Spotify. Si Apple n'est pas content, ils ont cas arrêter de vendre en Europe. Ca nous poussera à être créatif.
A titre plus perso, j'ai toujours alterné entre iOS et Android depuis que ca existe, mais je pense que c'est fini pour moi. Android a su s'améliorer en prenant ce qu'il y avait de bon dans iOS (principalement: gestion fine des permissions, patch de sécu de l'OS sur au moins 5 ans). Alors qu'iOS n'a fait que verrouiller de plus en plus. Android n'est pas aussi "lisse", autant optimisé et aussi bien intégré qu'iOS, mais tant pis.
#7.20
Même si ça ne concerne pas qu'Apple, c'est extrêmement dérangeant.
Edit : ce sont toutefois les champions en valeur manifestement, loin devant tout le monde.
https://en.wikipedia.org/wiki/Ireland_as_a_tax_haven
J'aimerais pouvoir avoir la force (rouge) d'abandonner iOS.
Peut-être au prochain renouvellement, que j'espère le plus tardif possible.
S'il y a bien un aspect positif qu'il faut leur reconnaitre, c'est qu'un iPhone dure.
Historique des modifications :
Posté le 29/02/2024 à 18h07
Tu soulignes un point crucial sur la contribution à l'impôt oui !
Même si ça ne concerne pas qu'Apple, c'est extrêmement dérangeant.
J'aimerais pouvoir avoir la force (rouge) d'abandonner iOS.
Peut-être au prochain renouvellement, que j'espère le plus tardif possible.
S'il y a bien un aspect positif qu'il faut leur reconnaitre, c'est qu'un iPhone dure.
#7.2
#7.4
#8
#8.1
Je dis ça de mémoire et j'ai la flemme de chercher la confirmation.
#9
#9.1
#9.2
#10
#10.1
#11
#11.1