Télécharger les sites web qui utilisent core-js

À propos de core-js

Presque personne ne décide d’installer core-js. En tant que bibliothèque de polyfills modulaire, elle arrive à l’intérieur d’un bundle JavaScript, entraînée comme dépendance transitive d’un préréglage de transpileur ou d’un modèle de départ de framework, et la personne responsable du site n’en aura souvent jamais entendu parler. Qui analyse le web à la recherche de core-js ne mesure donc pas une adoption au sens habituel d’une préférence ou d’un achat. Ce que l’analyse mesure, c’est le résidu des circuits de compilation, et une fois ce cadrage accepté, les données deviennent plus utiles plutôt que moins.

Un polyfill existe pour que les fonctionnalités récentes du langage continuent de fonctionner sur des moteurs plus anciens. Un site qui embarque core-js est un site dont la chaîne d’outils a été configurée, à un moment donné, pour prendre en charge des navigateurs que ses visiteurs ont peut-être abandonnés depuis longtemps, et une telle configuration est rarement revue. Le poids du front end, les budgets de vitesse d’affichage et le lent délitement des sites non maintenus découlent tous du même fait. Publiée pour la première fois en 2014 et distribuée sous licence MIT, la bibliothèque a survécu à plusieurs générations de politiques de prise en charge des navigateurs, ce qui explique qu’un bundle servi aujourd’hui puisse encore transporter des correctifs de compatibilité pour des moteurs que presque personne n’utilise.

L’échelle donne au phénomène sa forme. En octobre 2026 nous détectons core-js sur 6 146 481 sites, dont 2 890 140 se trouvent aux États-Unis, et l’ensemble penche fortement vers .com. La géographie dit ici peu de chose sur le lieu où la bibliothèque est écrite et beaucoup sur les endroits où se concentre un développement web commercial et fortement outillé en frameworks, car le code voyage avec l’outillage que les agences et les équipes produit adoptent comme standard.

La détection procède par inférence et elle sous-estime. Les empreintes survivent inégalement à la minification, les bundlers renomment et élaguent, et une compilation qui n’intègre qu’une poignée de polyfills peut ne laisser absolument rien de reconnaissable derrière elle. Notre fiche pour cette entrée ne porte par ailleurs aucune répartition de versions exploitable, si bien que le dataset peut vous dire où la bibliothèque est présente mais pas quelle version est servie. Qui prévoit des travaux dépendant d’une version précise doit traiter la liste comme un ensemble de candidats et vérifier sur les sites qui comptent.

Les personnes qui nous demandent cette liste se répartissent en quelques groupes. Les équipes sécurité et chaîne d’approvisionnement veulent la portée d’un paquet largement considéré comme fiable dont la base de mainteneurs est étroite, car c’est la portée qui rend une dépendance intéressante à attaquer. Les fournisseurs de performance veulent les sites qui embarquent du code de compatibilité hérité dont ils n’ont plus besoin. Les mainteneurs de frameworks et de navigateurs veulent des preuves avant d’abandonner la prise en charge de quelque chose d’ancien. Vérifier un seul domaine ne répond à aucune de ces questions, et vérifier un seul domaine est de toute façon facile, puisque les outils de développement d’un navigateur le font en un instant.

Ce qu’une liste téléchargeable ajoute, c’est la requête inverse. Au lieu de demander ce qu’un site connu fait tourner, vous demandez quels sites d’un pays donné, sous un suffixe donné, sur une plateforme de commerce donnée ou derrière un réseau de diffusion donné portent eux aussi cette dépendance, et vous récupérez la population entière sous forme de lignes que vous pouvez joindre à vos propres données de comptes. Reconstruire cela à partir de requêtes domaine par domaine suppose d’explorer vous-même l’espace de noms enregistré, ce qui est précisément le travail que nous avons déjà fait.