Télécharger les sites web qui utilisent Sentry

À propos de Sentry

Un traqueur d’erreurs est l’une des rares choses présentes sur une page qui décrivent l’équipe derrière un site plutôt que le site lui-même. Sentry est une plateforme de la catégorie Issue trackers, dont la première version remonte à 2010, écrite à l’origine en Python et publiée sous licence BSD par Functional Software Inc.. Quand nous la détectons, nous voyons un SDK client qu’un développeur a ajouté délibérément, relié à un projet, à un environnement et le plus souvent au système d’alerte de quelqu’un.

Personne n’instrumente une page vitrine avec du suivi d’erreurs. La présence du SDK suppose une application avec de vraies sessions utilisateur, un processus de publication et une personne dont le travail consiste notamment à lire une trace d’exécution le lundi matin. Pour qui vend à des organisations d’ingénierie, cette déduction qualifie une entreprise de façon plus nette que les effectifs ou les estimations de trafic, parce qu’elle sépare les entreprises qui exploitent du logiciel de celles qui ont simplement un site web.

En octobre 2026 nous détectons le SDK sur 124 451 sites, dont 84 462 aux États-Unis, et .com regroupe le plus gros bloc de suffixes. La concentration par pays est en partie réelle et en partie un artefact du lieu où les éditeurs de logiciels enregistrent leurs domaines publics, une mise en garde qui vaut pour presque toute technologie destinée aux développeurs et pour celle-ci en particulier.

C’est dans les données de version que la liste devient opérationnelle. Nous conservons 339 versions distinctes du SDK, et la chaîne que nous relevons le plus souvent est 5.4.3. La dispersion des versions d’un SDK navigateur est en soi un signal de maturité, car le bundle ne change que lorsque quelqu’un reconstruit et redéploie le front. Un site qui fait tourner un SDK plusieurs lignes majeures derrière la version courante vous dit que son circuit de publication front est resté silencieux longtemps, ce qui est utile à un fournisseur qui propose un remplacement, à un chercheur qui étudie la dérive des dépendances et à une équipe sécurité qui cartographie le code client obsolète.

Les limites de la détection méritent d’être dites franchement, car elles sont larges ici. Nous n’observons que le côté client. Les intégrations côté serveur, où réside une grande part de l’usage réel, ne laissent purement et simplement aucune trace dans la réponse d’une page, si bien que la population réelle de clients est nettement plus vaste que ce décompte. Les installations auto-hébergées qui font transiter les événements par le domaine du site lui-même sont tout aussi invisibles, et ce sont le plus souvent celles des entreprises soucieuses de sécurité qu’un chercheur aimerait le plus identifier. Prenez le chiffre pour un plancher d’adoption et pour un échantillon fiable des sites instrumentés côté client, pas pour une estimation de part de marché.

Une requête domaine par domaine indique si un site est instrumenté, ce qui est le mauvais sens pour la plupart des travaux de recherche. L’export retourne la question : une ligne par site détecté, avec le domaine, le pays, le suffixe, la version du SDK lorsqu’elle était exposée et la date de notre dernier passage. À partir de ce fichier, il devient possible de segmenter par version avant une campagne de sécurité, de dimensionner un marché avant de construire un produit concurrent, ou de mesurer la vitesse à laquelle une nouvelle ligne de SDK se propage sur des déploiements réels plutôt que sur des chiffres de téléchargement.