Comment fonctionne le détecteur de RevealTheme

Lorsque vous saisissez une URL dans l'un de nos détecteurs, beaucoup de choses se produisent dans les deux secondes qui précèdent l'affichage des résultats. Voici la présentation technique pour les curieux, y compris les limites que nous ne pouvons pas résoudre par l'ingénierie.

Étape 1 : Récupérer le HTML public

Lorsque vous envoyez une URL, notre serveur récupère la page web publique de cette URL à l'aide d'un User-Agent de navigateur standard. C'est le même HTML que votre navigateur recevrait si vous visitiez le site directement. Nous ne contournons aucun mur payant, n'extrayons aucun contenu protégé par identification et n'utilisons aucune authentification.

La récupération utilise un délai d'expiration de 20 secondes. Nous suivons jusqu'à 10 redirections (ce qui couvre les redirections HTTP → HTTPS, www → sans-www et les redirections par pays). Si le site renvoie une réponse 4xx ou 5xx, ou ne répond pas dans la fenêtre du délai d'expiration, nous renvoyons une erreur claire « impossible d'accéder » plutôt que de deviner.

Étape 2 : Détecter la plateforme

Avant de tenter d'identifier un thème précis, nous vérifions quel CMS fait tourner le site. Nous recherchons les empreintes des 7 plateformes prises en charge — WordPress, Shopify, Magento, Joomla, Drupal, Moodle et PrestaShop — et choisissons la correspondance la plus forte.

Si vous envoyez une URL Shopify à notre détecteur WordPress (ou inversement), nous vous le signalons et établissons un lien vers le bon détecteur. Sans devinette, sans faux positifs.

Étape 3 : Détection du thème

Pour WordPress en particulier, les références au thème apparaissent généralement dans le HTML de la page dans des chemins comme wp-content/themes/NOM_DU_THEME/style.css. Nous extrayons chacune de ces références où qu'elle se trouve dans le document : balises link, balises script, JavaScript en ligne, blocs JSON-LD et même le contenu textuel. Cela permet de détecter des thèmes que des sites très optimisés ont masqués aux outils de détection standard.

Pour chaque thème détecté, nous tentons de récupérer le fichier style.css du thème. L'en-tête de ce fichier contient le nom officiel du thème, l'auteur, la version, l'URI et la description, directement du développeur du thème. C'est la source des riches informations sur le thème que nous affichons à côté du résultat de la détection.

Étape 4 : Détection des plugins

La détection des plugins utilise deux approches parallèles. D'abord, nous extrayons tout chemin de fichier correspondant à wp-content/plugins/NOM_DU_PLUGIN/. Ensuite, nous exécutons des dizaines de vérifications basées sur des signatures : nous recherchons des structures HTML spécifiques, des noms de classes CSS, des variables JavaScript en ligne et des en-têtes de réponse HTTP qui identifient de manière unique des plugins populaires comme Elementor, Yoast SEO, WPForms, WooCommerce, Wordfence et bien d'autres.

La conception à double approche détecte les plugins qui masquent leurs chemins de fichiers (par mise en cache ou regroupement de ressources) mais qui laissent tout de même des signatures distinctives. Pour chaque plugin détecté, nous le recherchons dans le répertoire des plugins de WordPress.org afin d'enrichir le résultat avec le nom officiel du plugin, la description, l'auteur et les captures d'écran.

Étape 5 : Recherches d'hébergement + DNS

Pour identifier l'hébergeur, nous effectuons une recherche DNS sur le domaine et inspectons l'adresse IP, l'ASN et le DNS inverse. Nous recoupons cela avec une base de données de plages d'IP connues de fournisseurs d'hébergement afin d'identifier le fournisseur. La précision est élevée pour les principaux hébergeurs (AWS, Cloudflare, Hostinger, SiteGround, etc.) et moindre pour les fournisseurs de niche.

Ce que nous ne pouvons pas faire

Quelques cas où la détection ne fonctionnera pas, aussi bon que soit notre code :

Défi anti-bots de Cloudflare. Les sites dotés d'une protection anti-bots stricte de Cloudflare (l'écran « Vérification de sécurité en cours... ») bloquent notre récupérateur comme ils bloqueraient n'importe quelle requête automatisée. Il n'existe aucun moyen propre de le contourner.
Thèmes fortement personnalisés. Si un thème a été modifié au point que chaque référence au nom d'origine du thème a été supprimée du HTML, nous n'avons rien à détecter.
Mise en cache agressive avec chemins de ressources réécrits. Des plugins comme LiteSpeed Cache, WP Rocket et le Rocket Loader de Cloudflare réécrivent parfois les URL des ressources pour masquer la source. Notre détection basée sur les signatures en repère la plupart, mais pas toutes.
Sites en exportation statique. Un site WordPress qui a été exporté en HTML statique perd la plupart des signatures d'exécution qui rendent la détection possible.

Ce que nous ne faisons pas

On nous l'a demandé. Les réponses sont non :

Nous ne stockons pas les URL que vous envoyez
Nous n'enregistrons pas les adresses IP à des fins marketing
Nous ne partageons pas les données de détection avec les fournisseurs
Nous ne contournons pas l'authentification, le robots.txt ni d'autres contrôles d'accès
Nous n'exécutons pas le détecteur sur des IP internes/privées (127.0.0.1, 10.x.x.x, etc.) pour des raisons de sécurité

Les détails complets sur la confidentialité figurent dans notre politique de confidentialité.

Accès à l'API

Nous ne proposons pas d'API publique pour le moment, mais un accès programmatique limité est disponible sur demande pour les agences et les chercheurs. Écrivez à hello@revealtheme.com en précisant votre cas d'usage et le volume de requêtes prévu.

Pourquoi ce n'est pas open source ?

Les règles de détection sont le cœur du produit, et nous les mettons à jour fréquemment à mesure que les thèmes et plugins évoluent. En ouvrir le code ralentirait notre cadence de mise à jour. Cela dit, nous publions des articles détaillés sur les techniques de détection sur notre blog : recherchez « détection » pour les trouver.

Prêt à l'essayer ?

Utilisez le détecteur correspondant au site que vous souhaitez inspecter :