Télécharger les sites web qui utilisent autoComplete.js

À propos de autoComplete.js

Les bibliothèques front-end vieillissent en public. Un site fige une version, la met en ligne, et le fichier reste là sans être touché aussi longtemps que vit la page, ce qui explique pourquoi l’étalement des versions dans la nature en dit plus sur la façon dont les sites sont maintenus que sur la façon dont une bibliothèque est développée. autoComplete.js illustre bien ce schéma.

La bibliothèque est un composant JavaScript sans dépendances, destiné aux champs de recherche à la frappe, publié sous licence Apache 2.0 et paru pour la première fois en 2019. Il n’y a aucune entreprise derrière et aucun service hébergé auquel s’abonner, si bien qu’elle est adoptée comme le sont d’habitude les petits composants open source, par un développeur qui résout un problème précis sur une page précise. Personne au service achats n’approuve un widget d’autocomplétion.

En octobre 2026 nous détectons autoComplete.js sur 341 sites, et sur l’ensemble de ces installations nous relevons 15 versions distinctes, 10.2.7 étant la valeur la plus souvent rapportée par les sites qui en exposent une. L’étalement est la partie intéressante. Un composant tout juste adopté se regrouperait sur les versions récentes, et un composant abandonné dériverait entièrement vers les anciennes. Un étalement large doté d’un centre de gravité net décrit une bibliothèque activement utilisée, activement publiée, et installée aussi sur quantité de pages qui ne seront plus jamais mises à jour.

Une donnée de version de ce genre relève de l’inférence et demande à être maniée avec précaution. Nous lisons la version dans un chemin de ressource, dans le contenu du fichier ou dans un commentaire laissé dans le paquet, et une chaîne de build qui concatène et minifie tout dans un seul fichier efface tout cela. Les sites qui n’exposent aucune version du tout sont comptés dans le total des sites mais n’alimentent en rien la répartition des versions, si bien que la distribution décrit les sites qui parlent d’eux-mêmes plutôt que la population entière.

Même avec cette réserve, le champ de version est ce qui transforme une liste de domaines en quelque chose d’exploitable. Un chercheur en sécurité qui suit une faille divulguée dans un composant JavaScript a besoin du sous-ensemble des sites qui font tourner les versions concernées, pas du parc installé complet. Un mainteneur qui juge si une rupture de compatibilité est sans danger a besoin de savoir quelle part du parc installé reste sur d’anciennes versions majeures. Une agence qui chiffre le travail d’un programme de modernisation a besoin de la même chose sur son propre portefeuille de clients.

Rien de tout cela ne survit à un traitement domaine par domaine. Une requête vous dit quelle version charge un seul site, ce qui convient quand vous connaissez déjà le site. Les questions qui valent la peine d’être posées ici sont des questions de population. Comment les sites se répartissent entre les lignes de version, si les anciennes se concentrent dans certains pays ou certains hébergements, avec quels frameworks et quels systèmes de gestion de contenu la bibliothèque est d’ordinaire associée, et comment la distribution se déplace d’un instantané à l’autre à mesure que les sites sont reconstruits. Le dataset de la catégorie JavaScript libraries porte le domaine, la version détectée lorsqu’un site en expose une, la date de dernière confirmation de la détection et le reste de la stack trouvée sur la même page.