L’accusation est sans appel : Google démantèlerait petit à petit la toile ouverte, non dans un coup unique, mais par une succession de décisions techniques, commerciales et de gouvernance qui,仔ensemble, dessinent une stratégie cohérente. La réflexion “Google is killing the open web” — publiée sur le blog d’Oblomov — reconstitue cette chronologie et la relie par un fil conducteur : la substitution progressive des standards ouverts et multi-fournisseurs par des mécanismes et APIs favorisant un écosystème plus centralisé, au service des intérêts publicitaires et de la collecte de données du géant de Mountain View.
Ce reportage approfondit cette thèse, contraste les étapes clés, apporte un contexte technique et recueille également les objections et nuances de ceux qui voient dans bon nombre de ces changements une évolution raisonnable de la plateforme web. Le résultat n’est pas un verdict hâtif, mais une radiographie réaliste d’un processus s’étendant sur plus d’une décennie, aujourd’hui déterminant la manière dont la web se développe, publie et est consommée.
Un point de départ nécessaire : standards, navigateurs et pouvoir de facto
La web est née comme un terrain d’standards ouverts (HTTP, HTML, CSS, DNS) gouvernés par des organismes tels que le W3C et l’IETF. La première “guerre des navigateurs” dans les années 90 a montré qu lorsqu’un acteur en position dominante étend la web avec ses propres technologies, cela entraîne fragmentation et dépendance. Chrome est apparu en 2008 dans un contexte nouveau : explosion du mobile, essor des services centralisés, affaiblissement d’Internet Explorer. Sur cette vague, Google a lancé un cycle d’innovation rapide (moteur V8, cycles de versions, APIs modernes), souvent via le WHATWG, un forum où les navigateurs — avec Google en tête — coordonnent l’évolution de HTML et consorts. Pour ses détracteurs, cela crée un pouvoir de facto qui éclipse le W3C et réduit les contrepoids. Pour ses défenseurs, c’est une façon d’éviter la paralysis et de faire avancer la web vers les usages des utilisateurs.
2013, année charnière : RSS, XMPP, MathML et le premier affrontement à XSLT/XML
La réflexion situe en 2013 le “tournant” :
- Fermeture de Google Reader. Il ne s’agissait pas seulement de supprimer un produit ; cela a affaibli la découverte de contenus via RSS/Atom, moteur des blogs, médias, puis podcasts. La version officielle évoque une baisse d’utilisation. En réalité, cela a déplacé le journalisme vers des algorithmes opaques dans des plateformes.
- Fin de la fédération XMPP dans Google Chat (Facebook a suivi avec Messenger en 2014). La messagerie interopérable s’est replie, laissant place à des “îlots fermés”.
- MathML a été retiré de Chrome. Dix ans plus tard, il est revenu grâce à un travail externe. Pour l’éducation et l’accessibilité, représenter mathématiques sans dépendre d’images ou JavaScript reste pertinent.
- Premier vrai combat contre XSLT/XML dans le navigateur. XSLT permet de transformer des documents (par exemple un flux RSS) en HTML sans JavaScript. Pour ses critiques, désinciter XSLT augmente la dépendance au JavaScript et côté serveur.
Une lecture réaliste. Aucun de ces faits seul ne “tue” la web ouverte. Ensemble, ils déplacent le centre de gravité : moins de standards de présentation des données côté client, plus de logique en JS et backend, davantage de contrôle dans des couches où Google domine.
2015, année d’AMP,
- AMP (Accelerated Mobile Pages). Promettant une vitesse accrue sur mobile. La critique soutient que le “miracle” était de charger moins de contenu inutile et de le mettre en cache dans des CDN tiers (Google en tête). Sa visibilité accrue dans les résultats de recherche a conduit de nombreux médias à dupliquer leurs efforts et à perdre une partie du contrôle.
- Abandon du
- SMIL dans la ligne de mire. Les animations déclaratives en SVG ont été reléguées. Depuis lors, la majorité des animations passent par CSS + JS, renforçant la logique côté client (et la dépendance aux toolchains JS).
Un bilan. AMP n’a plus le même éclat qu’en 2016, mais a laissé une inertie : la performance mobile s’est centrée autour des préférences de Google. La sortie de
2018–2020 : RSS quitte le navigateur et les URLs perdent leur rôle central
Firefox a supprimé le support natif de RSS (“Marques Live”), poussant à des extensions. Chrome n’a jamais vraiment été favorable aux flux. L’utilisateur moyen n’utilise plus RSS comme une fonctionnalité de premier rang dans le navigateur. Parallèlement, Chrome a testé masquer les URLs pour améliorer l’ergonomie. Les critiques y ont vu une étape supplémentaire pour que le site prime sur l’adresse, ce qui complique l’évaluation de l’origine et de l’authenticité.
2019–2023 : Manifest V3, intégrité du web et le cas JPEG XL
- Manifest V3 a modifié le modèle d’extensions de Chrome “pour des raisons de sécurité”. Pour la communauté et les développeurs, cela a limité les bloqueurs de publicités en restreignant certains mécanismes de filtrage. Google nie toute intention anti-adblock ; l’opinion publique y voit un avantage direct pour le secteur publicitaire.
- Web Environment Integrity (WEI). Présenté comme un outil anti-triche, beaucoup y ont vu un “DRM du navigateur” : le serveur demanderait si le client est “fiable”. La communauté a réagi et le projet s’est refroidi, mais l’idée a laissé une trace.
- JPEG XL. Nouveau format ouvert avec meilleure compression (avec ou sans perte), mode progressif, transparence et animation. Chrome l’a éliminé malgré des essais positifs. Les critiques le considèrent comme une opportunité manquée pour réduire les coûts de bande passante pour la toile entière. Google a invoqué un manque d’adoption et des bénéfices insuffisants face à AVIF/WebP.
2024–2025 : RSS exclu de Google News et nouvelle offensive contre XSLT
En 2024, Google a arrêté d’accepter feeds pour leur inclusion dans Google News. La découverte des médias et articles devient encore plus dépendante des moteurs internes.
En 2025, le débat rejaillit sur la suppression de XSLT dans le navigateur — cette fois via le WHATWG. Les détracteurs soulignent que depuis 2007 (XSLT 2.0) et 2017 (XSLT 3.0), des versions modernes existent, y compris avec JSON en entrée. La thèse est dérangeante : si une fonction n’est pas maintenue depuis longtemps, sa baisse d’usage devient une auto-realisation.
Pourquoi XSLT/XML et RSS importent (même si on ne les utilise pas)
- Présenter sans JS. XSLT est un modèle déclaratif : il transforme arbres de nœuds (XML/HTML/SVG) en autres arbres, avec validation structurelle implicite. Moins de surface d’attaque que la concaténation de chaînes.
- Coûts et simplicité. Un site peut fournir XML+XSLT (flux, sitemaps, catalogues, données tabulaires) et laisser le navigateur rendre. Moins de CPU côté serveur, moins de bytes si bien optimisé.
- Souveraineté et portabilité. RSS/Atom permet de s’abonner et de migrationner entre clients sans permission. C’est la force qui soutient podcasts et de nombreux flux fédérés.
- Accessibilité et sciences. MathML et TEI/XML dans l’humanités sont des exemples où le client devrait pouvoir visualiser sans outils lourds.
Tout cela peut se faire avec JavaScript. Mais la vraie question est : pourquoi supprimer des options ouvertes et matures qui diversifient la manière dont la web peut être construite ?
Les arguments de Google (et consort) et pourquoi ils ne persuadent pas tout le monde
- “Sécurité et coût de maintenance.” Maintenir des parsers XML/XSLT anciens coûte cher et peut entraîner des CVE. La réponse : si le problème vient d’implémentations obsolètes, mettez-les à jour (XSLT 3.0, librairies modernes) ou remplacez-les ; ne supprimez pas la fonction de la spécification.
- “Faible adoption.” Argument circulaire : plus on n’investit pas, moins on utilise. De plus, XSLT 1.0 n’a jamais migré à 2.0/3.0 sur les navigateurs, laissant de côté de nombreuses fonctionnalités.
- “Simplifier le code du navigateur.” Idée valable en principe, mais en pratique, la communauté ajoute chaque cycle de nouvelles APIs JS. Le vrai problème n’est pas “d’économiser” mais ce qui est sacrifié : souvent, ce sont les éléments assurant l’autonomie de l’utilisateur.
Une perspective globale : tout n’est pas Google, mais Google pèse lourd
Il serait injuste de faire de cette situation une fable du “méchant unique”. Apple limite les Web APIs sur iOS ; Mozilla a pris des décisions controversées (RSS, intégrations variées) ; Microsoft a pivoté vers Chromium et privilégie sa plateforme. La différence est d’échelle : avec la part de marché Chrome et sa position dans la recherche, ce qui décide Google devient une norme pour une grande partie du web. Par conséquent, même de “petits” changements font tâche d’huile.
“Tuer la web ouverte” ? Une lecture nuancée
Le réalisme consiste à admettre deux vérités en même temps :
- La plateforme web est plus puissante que jamais (graphiques, multimédia, typographie, WebGPU, PWAs, vie privée avancée dans des navigateurs alternatifs).
- Le contrôle effectif sur ce qui est priorisé ou rejeté se concentre. Lorsque des éléments comme XSLT,
Ce n’est pas une apocalypse. C’est une érosion constante qui rétrécit les chemins ne passant pas par JavaScript lourd, services centralisés ou APIs privilégiées par ceux qui pilotent le développement.
Ce que les utilisateurs, médias et développeurs peuvent faire (sans naïveté)
- Maintenir visibles les flux RSS/Atom. Si vous publiez, exposez-les. Si vous lisez, utilisez des lecteurs.
- Servir XML avec XSLT pour des cas précis (sitemaps “lisibles”, catalogues, documentation). Si le navigateur ne supporte pas, effectuez la transformation côté serveur ou déployez un polyfill (SaxonJS) en dégradation progressive.
- Respectez la vie privée et la pluralité. Tout ne doit pas s’exécuter côté client : pensez à les îlots (HTMX/Alpine), SSR, et rendus statiques. Moins de JS si ce n’est pas nécessaire.
- Extensions et navigateurs alternatifs. Diversifier l’écosystème réduit le pouvoir de contrôle.
- Participer aux issue trackers. La pression technique et respectueuse peut influencer les priorités (ça a déjà changé pour plusieurs API controversées).
- Se former et documenter. Renseigner sur ce que fait chaque technologie (XSLT, MathML, certificats clients, etc.) pour éviter que des décisions par défaut passent sans débat.
Ce qui nous attend : scénarios dans 12–24 mois
- XSLT dans le navigateur. Si sa suppression est confirmée, on assistera à plus de transformations server-side et à des polyfills ponctuels. Certaines communautés (humanités numériques, documentation technique) se tourneront peut-être vers leurs propres toolchains.
- Images. Sans JPEG XL, la croissance de AVIF/WebP va continuer. Certains secteurs réclameront de meilleurs outils et des profils stables pour éviter une “guerre des codecs” perpétuelle.
- Extensions. Manifest V3 reste la norme ; la pression maintiendra certaines capacités de filtrage mais le modèle de blocage au niveau du réseau pourrait migrer hors du navigateur (DNS/routers).
- Intégrité de l’environnement. La tentation de nouveaux “certificateurs” ne disparaîtra pas. L’enjeu sera de limiter la portée de la fraude et d’éviter que le navigateur devienne le policier de l’utilisateur.
Conclusion : préserver la diversité des chemins
Une web saine n’est pas celle qui adopte tout “de neuf” sans regarder derrière, mais celle qui additionne sans exclure des voies permettant autonomie et portabilité. RSS, XSLT, MathML ou certificats de client ne sont pas des reliques ; ce sont des alternatives qui rééquilibrent le pouvoir entre éditeurs, lecteurs et plateformes.
Quand un acteur aux leviers importants désactive ces options, le territoire web s’appauvrit. Ce n’est pas la fin de la web ouverte, mais elle devient moins ouverte et moins web. Et cela mérite un débat, une pression éclairée et, surtout, la construction d’alternatives.
Questions fréquentes (FAQ)
1) La pertinence de XSLT en 2025 : est-ce toujours d’actualité ?
Oui, dans des contextes où il est utile de séparer données et présentation, réduire le JavaScript et valider des structures (flux, sitemaps, catalogues, documentation). XSLT 3.0, en plus, gère JSON. Si le support natif disparaît, on peut rendre côté serveur ou utiliser des polyfills.
2) Pourquoi continuer à valoriser RSS alors que “plus personne ne l’utilise” ?
RSS/Atom maintiennent podcasts, syndiquent des milliers de sites (WordPress le propose par défaut) et redonnent du pouvoir au lecteur : choisir ses sources sans algorithmes. C’est une option d’engagement faible, ouverte. Si elle disparaît de l’écosystème, ce n’est pas par inutilité, mais par priorités.
3) Les arguments de Google sur la sécurité sont-ils convaincants ?
La sécurité est primordiale. La controverse porte sur la méthodologie: actualiser les implémentations et maintenir des standards versus retirer des fonctionnalités qui limitent la diversité. Le “coût de maintenance” existe, mais ce qui est conservé est autant une décision politique que technique.
4) Quelles alternatives face à la dépendance aux grandes plateformes ?
Il n’existe pas de solution miracle. Diversifier (navigateurs, hébergements, lecteurs RSS), minimiser le JS là où ce n’est pas indispensable, privilégier les standards (Web, DNS, emails interopérables), et documenter les bonnes pratiques. L’indépendance est progressive et accumulative, pas absolue.
Sources : wok.oblomov.eu et SEOcretos.
Chronologie critique de comment (et pourquoi) Google resserre la marge du web ouvert
L’accusation est sans appel : Google démantèlerait petit à petit la toile ouverte, non dans un coup unique, mais par une succession de décisions techniques, commerciales et de gouvernance qui,仔ensemble, dessinent une stratégie cohérente. La réflexion “Google is killing the open web” — publiée sur le blog d’Oblomov — reconstitue cette chronologie et la relie par un fil conducteur : la substitution progressive des standards ouverts et multi-fournisseurs par des mécanismes et APIs favorisant un écosystème plus centralisé, au service des intérêts publicitaires et de la collecte de données du géant de Mountain View.
Ce reportage approfondit cette thèse, contraste les étapes clés, apporte un contexte technique et recueille également les objections et nuances de ceux qui voient dans bon nombre de ces changements une évolution raisonnable de la plateforme web. Le résultat n’est pas un verdict hâtif, mais une radiographie réaliste d’un processus s’étendant sur plus d’une décennie, aujourd’hui déterminant la manière dont la web se développe, publie et est consommée.
Un point de départ nécessaire : standards, navigateurs et pouvoir de facto
La web est née comme un terrain d’standards ouverts (HTTP, HTML, CSS, DNS) gouvernés par des organismes tels que le W3C et l’IETF. La première “guerre des navigateurs” dans les années 90 a montré qu lorsqu’un acteur en position dominante étend la web avec ses propres technologies, cela entraîne fragmentation et dépendance. Chrome est apparu en 2008 dans un contexte nouveau : explosion du mobile, essor des services centralisés, affaiblissement d’Internet Explorer. Sur cette vague, Google a lancé un cycle d’innovation rapide (moteur V8, cycles de versions, APIs modernes), souvent via le WHATWG, un forum où les navigateurs — avec Google en tête — coordonnent l’évolution de HTML et consorts. Pour ses détracteurs, cela crée un pouvoir de facto qui éclipse le W3C et réduit les contrepoids. Pour ses défenseurs, c’est une façon d’éviter la paralysis et de faire avancer la web vers les usages des utilisateurs.
2013, année charnière : RSS, XMPP, MathML et le premier affrontement à XSLT/XML
La réflexion situe en 2013 le “tournant” :
Une lecture réaliste. Aucun de ces faits seul ne “tue” la web ouverte. Ensemble, ils déplacent le centre de gravité : moins de standards de présentation des données côté client, plus de logique en JS et backend, davantage de contrôle dans des couches où Google domine.
2015, année d’AMP,
Un bilan. AMP n’a plus le même éclat qu’en 2016, mais a laissé une inertie : la performance mobile s’est centrée autour des préférences de Google. La sortie de
2018–2020 : RSS quitte le navigateur et les URLs perdent leur rôle central
Firefox a supprimé le support natif de RSS (“Marques Live”), poussant à des extensions. Chrome n’a jamais vraiment été favorable aux flux. L’utilisateur moyen n’utilise plus RSS comme une fonctionnalité de premier rang dans le navigateur. Parallèlement, Chrome a testé masquer les URLs pour améliorer l’ergonomie. Les critiques y ont vu une étape supplémentaire pour que le site prime sur l’adresse, ce qui complique l’évaluation de l’origine et de l’authenticité.
2019–2023 : Manifest V3, intégrité du web et le cas JPEG XL
2024–2025 : RSS exclu de Google News et nouvelle offensive contre XSLT
En 2024, Google a arrêté d’accepter feeds pour leur inclusion dans Google News. La découverte des médias et articles devient encore plus dépendante des moteurs internes.
En 2025, le débat rejaillit sur la suppression de XSLT dans le navigateur — cette fois via le WHATWG. Les détracteurs soulignent que depuis 2007 (XSLT 2.0) et 2017 (XSLT 3.0), des versions modernes existent, y compris avec JSON en entrée. La thèse est dérangeante : si une fonction n’est pas maintenue depuis longtemps, sa baisse d’usage devient une auto-realisation.
Pourquoi XSLT/XML et RSS importent (même si on ne les utilise pas)
Tout cela peut se faire avec JavaScript. Mais la vraie question est : pourquoi supprimer des options ouvertes et matures qui diversifient la manière dont la web peut être construite ?
Les arguments de Google (et consort) et pourquoi ils ne persuadent pas tout le monde
Une perspective globale : tout n’est pas Google, mais Google pèse lourd
Il serait injuste de faire de cette situation une fable du “méchant unique”. Apple limite les Web APIs sur iOS ; Mozilla a pris des décisions controversées (RSS, intégrations variées) ; Microsoft a pivoté vers Chromium et privilégie sa plateforme. La différence est d’échelle : avec la part de marché Chrome et sa position dans la recherche, ce qui décide Google devient une norme pour une grande partie du web. Par conséquent, même de “petits” changements font tâche d’huile.
“Tuer la web ouverte” ? Une lecture nuancée
Le réalisme consiste à admettre deux vérités en même temps :
Ce n’est pas une apocalypse. C’est une érosion constante qui rétrécit les chemins ne passant pas par JavaScript lourd, services centralisés ou APIs privilégiées par ceux qui pilotent le développement.
Ce que les utilisateurs, médias et développeurs peuvent faire (sans naïveté)
Ce qui nous attend : scénarios dans 12–24 mois
Conclusion : préserver la diversité des chemins
Une web saine n’est pas celle qui adopte tout “de neuf” sans regarder derrière, mais celle qui additionne sans exclure des voies permettant autonomie et portabilité. RSS, XSLT, MathML ou certificats de client ne sont pas des reliques ; ce sont des alternatives qui rééquilibrent le pouvoir entre éditeurs, lecteurs et plateformes.
Quand un acteur aux leviers importants désactive ces options, le territoire web s’appauvrit. Ce n’est pas la fin de la web ouverte, mais elle devient moins ouverte et moins web. Et cela mérite un débat, une pression éclairée et, surtout, la construction d’alternatives.
Questions fréquentes (FAQ)
1) La pertinence de XSLT en 2025 : est-ce toujours d’actualité ?
Oui, dans des contextes où il est utile de séparer données et présentation, réduire le JavaScript et valider des structures (flux, sitemaps, catalogues, documentation). XSLT 3.0, en plus, gère JSON. Si le support natif disparaît, on peut rendre côté serveur ou utiliser des polyfills.
2) Pourquoi continuer à valoriser RSS alors que “plus personne ne l’utilise” ?
RSS/Atom maintiennent podcasts, syndiquent des milliers de sites (WordPress le propose par défaut) et redonnent du pouvoir au lecteur : choisir ses sources sans algorithmes. C’est une option d’engagement faible, ouverte. Si elle disparaît de l’écosystème, ce n’est pas par inutilité, mais par priorités.
3) Les arguments de Google sur la sécurité sont-ils convaincants ?
La sécurité est primordiale. La controverse porte sur la méthodologie: actualiser les implémentations et maintenir des standards versus retirer des fonctionnalités qui limitent la diversité. Le “coût de maintenance” existe, mais ce qui est conservé est autant une décision politique que technique.
4) Quelles alternatives face à la dépendance aux grandes plateformes ?
Il n’existe pas de solution miracle. Diversifier (navigateurs, hébergements, lecteurs RSS), minimiser le JS là où ce n’est pas indispensable, privilégier les standards (Web, DNS, emails interopérables), et documenter les bonnes pratiques. L’indépendance est progressive et accumulative, pas absolue.
Sources : wok.oblomov.eu et SEOcretos.
Info Cloud
le dernier
La fuite de VMware suscite l’intérêt pour Proxmox VE : la nouvelle référence en virtualisation d’entreprise ?
Cisco et NVIDIA soutiennent la « usine sûre d’IA » pour les agents d’entreprise avec une intégration de VAST Data
La Chine encourage l’adoption de l’IA parmi les PME par des bons de calcul et des subventions massives
Le Premier ministre de Taïwan rejette la possibilité que TSMC devienne une fondeuse américaine
La nouvelle économie de l’IA : plus de travail pour réparer ce que les machines font mal
Chronologie critique de comment (et pourquoi) Google resserre la marge du web ouvert