Outils populaires

Thème

Détecteur de CMS

Quel CMS utilise ce site ? Découvrez la plateforme, le thème, les plugins et toutes les technologies derrière n'importe quel site web, avec la ligne de code qui prouve chacune d'elles.

Plus de 7 600 technologies · les en-têtes, le HTML et le DNS du site · un vrai navigateur sur demande
7 660 technologies

Un domaine ou une URL complète avec un chemin. Nous ne publions jamais les sites que vous vérifiez.

Essayez
Ce que nous lisonsDNS · en-têtes · HTML · navigateur
Nous cherchonsPlateforme 1 773Plugins 600Code 718Marketing 2 293Commerce 659Chat 341Médias 467Serveur 212Réseau 465Autres 132
DNSNS · MX · TXT
En-têtesserveur · cookies · liens
<head>meta · scripts · feuilles de style
<body>balisage · scripts · commentaires
NavigateurJS · requêtes

Chaque technologie trouvée est épinglée à l'endroit où se trouve sa preuve : un enregistrement DNS, un en-tête de réponse, une ligne de la page, ou ce qu'un vrai navigateur a chargé.

Résultat du détecteur de CMS : techcrunch.com utilise WordPress, avec son thème, ses plugins et l'endroit de chaque preuveRésultat du détecteur de CMS : techcrunch.com utilise WordPress, avec son thème, ses plugins et l'endroit de chaque preuveN'importe quel siteUn domaine ou une URL complète avec un chemin : la page est lue en direct, jamais tirée d'une ancienne exploration.La réponseLa plateforme, sa version (pour WordPress, comparée à la dernière version publiée) et le thème.Où nous l'avons trouvéChaque technologie épinglée là où se trouve sa preuve : le DNS, un en-tête, une ligne de la page, le navigateur.La preuveLe signal sélectionné tel que le site l'a envoyé : une ligne d'en-tête, une balise ou un chemin de fichier ; parcourez-les tous avec ‹ ›.
Un résultat : la plateforme et sa version, le thème, et la bande qui épingle chaque technologie là où se trouve sa preuve. Sélectionnez un numéro pour voir ce que montre chaque partie.

Comment fonctionne un détecteur de CMS ?

Il demande la page au site une seule fois, en s'identifiant sous son propre nom, puis cherche les marques que laisse chaque plateforme : dans les en-têtes de la réponse, les cookies, le code HTML et les chemins de ses fichiers.

Certaines marques sont posées par la plateforme elle-même et sont difficiles à falsifier ou à supprimer : WordPress annonce son API REST dans un en-tête Link, Shopify dépose un cookie _shopify_essential. D'autres sont écrites dans la page et peuvent être supprimées ou copiées : une balise generator, un nom de classe, un commentaire.

Une marque que n'importe qui peut copier n'est donc qu'un indice, alors que deux marques indépendantes, ou une marque que seule la plateforme elle-même pose, forment une preuve. Chaque réponse ci-dessus montre les marques sur lesquelles elle repose, citées telles que nous les avons trouvées, et le degré de certitude qu'elles nous donnent : Confirmé, Probable ou Possible.

En plus de la page, nous lisons les enregistrements DNS du domaine et, sur un site WordPress, au plus deux autres fichiers du même hôte : le style.css du thème et l'index /wp-json/ vers lequel pointe la page. Un vrai navigateur n'intervient que si vous le demandez.

Une réponse, huit marques · nalgene.com, 24 octobre 2026
  1. HTTP/2 200 · 23 en-têtes
  2. 1ligne 3server: cloudflare
  3. 2ligne 7link: <https://nalgene.com/wp-json/>; rel="https://api.w.org/"
  4. 3ligne 8link: <https://nalgene.com/wp-json/wp/v2/pages/87>; rel="alternate"; title="JSON"; type="application/json"
  5. 4ligne 15set-cookie: __cf_bm=BZFgzmA1kpRQ…; HttpOnly; Secure
  6. HTML · 464 Ko
  7. 5octet 1 085<!-- This site is optimized with the Yoast SEO Premium plugin v28.0 (Yoast SEO v28.6) -->
  8. 6octet 8 283<link rel='stylesheet' href='…/wp-content/themes/nalgene-twentytwenty/style.css?ver=9260242'>
  9. 7octet 52 255<meta name="generator" content="WP Rocket 3.23.5.1">
  10. 8octet 432 563<script src="…/wp-includes/js/wp-util.min.js?ver=7.1.3"></script>
  1. 1En-têteCloudflare sert le siteConfirmé
  2. 2En-têteL'API REST de WordPress : posée par WordPress lui-mêmeConfirmé
  3. 3En-têteL'adresse REST propre à la page : encore le cœur de WordPressConfirmé
  4. 4CookieCloudflare Bot ManagementConfirmé
  5. 5CommentaireYoast SEO et sa versionProbable
  6. 6Chemin de fichierLe dossier du thème, puis l'en-tête de son style.cssConfirmé
  7. 7Meta generatorWP Rocket : auto-déclaré, facile à retirerProbable
  8. 8?ver=WordPress 7.1.3 sur son propre script du cœurProbable
Quatre des 23 en-têtes de réponse de nalgene.com et quatre lignes de sa page de 464 Ko. La balise generator de WordPress est absente (elle peut être désactivée), mais l'en-tête REST, les chemins de fichiers et la version sur les scripts du cœur désignent toujours WordPress 7.1.3.

CMS, créateur de site, CMS headless ou framework ?

Tous servent à faire des sites web, mais seuls certains laissent leur nom dans la page. L'endroit où vit le contenu décide de ce qu'un détecteur peut voir.

Un CMS classique comme WordPress stocke le contenu et génère lui-même chaque page : ses marques sont donc partout. Un créateur de site comme Wix héberge aussi le site, et ce sont les hôtes de ses fichiers qui le trahissent.

Un CMS headless comme Contentful ne fait que stocker le contenu ; un front-end distinct, souvent Next.js, génère la page, si bien qu'on voit au mieux l'hôte d'images du CMS. Un générateur de site statique comme Hugo produit du HTML brut à l'avance et laisse, au mieux, une balise generator sur la page d'accueil.

Où vit le contenu, et ce qui arrive dans la page
CMS classiqueWordPress
  1. Contenu + thème
  2. rendu par WordPress
  3. sur son propre serveur
  4. La page

Ce que montre la page

/wp-content/rel="https://api.w.org/"<meta name="generator">

Le détecteur ditWordPressConfirmé

Créateur de siteWix
  1. Contenu
  2. rendu par Wix
  3. hébergé par Wix
  4. La page

Ce que montre la page

static.wixstatic.com/mediax-wix-request-idserver: Pepyaka

Le détecteur ditWixConfirmé

CMS headlessContentful + Next.js
  1. Contenu dans Contentful
  2. récupéré via une API
  3. rendu par Next.js
  4. La page

Ce que montre la page

/_next/static/images.ctfassets.net

Le détecteur ditAucun CMS dans la pagePossible

Générateur de site statiqueHugo
  1. Fichiers Markdown
  2. compilés en HTML une fois
  3. servis comme fichiers statiques
  4. La page

Ce que montre la page

<meta name="generator" content="Hugo …">page d'accueil seulement

Le détecteur ditHugoProbable

Ce que chaque type de système laisse dans le HTML que reçoit un visiteur. W3Techs compte les quatre comme des CMS dans son étude ; un détecteur ne peut nommer que ceux qui laissent une marque.

Comment trouver le thème et les plugins WordPress d'un site ?

Lisez les noms de dossiers dans les chemins des fichiers de la page. Un détecteur de thème WordPress prend le dossier du thème dans /wp-content/themes/<name>/, puis ouvre le style.css de ce thème, dont l'en-tête donne le nom du thème, son auteur, sa version et, pour un thème enfant, son thème parent.

Cet en-tête est la carte d'identité du thème, défini dans le manuel des thèmes WordPress. Un thème enfant ajoute Template: avec le dossier de son parent, si bien qu'une page peut montrer deux thèmes : nalgene.com utilise son propre Nalgene Twenty Twenty sur Genesis 3.5.0.

Les plugins apparaissent de la même façon, sous forme de dossiers /wp-content/plugins/<name>/, souvent avec un numéro ?ver=. Ce numéro n'est la version du plugin que s'il correspond à une version publiée : les scripts de WooCommerce sur nalgene.com portent 11.2.1, le Stable tag de son readme sur WordPress.org, alors que le fichier d'un autre plugin porte un horodatage.

Seuls les plugins qui ajoutent quelque chose à la page sont visibles. Les sauvegardes, les outils de sécurité ou un formulaire sur la page de contact ne laissent rien dans le HTML de la page d'accueil : aucun détecteur ne peut donc lister tous les plugins d'un site.

Une paire de thèmes et 15 dossiers de plugins · nalgene.com, 24 octobre 2026

Thème

Dans la page

/wp-content/themes/nalgene-twentytwenty/style.css?ver=9260242/wp-content/themes/genesis/lib/js/skip-links.min.js?ver=3.5.0class="… wp-child-theme-nalgene-twentytwenty …"

Thème enfantNalgene Twenty Twenty

  1. /wp-content/themes/nalgene-twentytwenty/style.css
  2. Theme Name: Nalgene Twenty TwentyNom
  3. Author: Scout DigitalAuteur
  4. Version: 9260242Version · un numéro de build
  5. Template: genesisDossier parent
/wp-content/themes/genesis/style.css

Thème parentGenesis 3.5.0 · StudioPress

  1. Theme Name: GenesisNom
  2. Author: StudioPressAuteur
  3. Version: 3.5.0Version

Plugins

  • /plugins/woocommerce/?ver=11.2.1

    WooCommerce 11.2.1 : le Stable tag de son readme sur WordPress.org

  • /plugins/woocommerce/…/jquery-blockui/?ver=2.7.0-wc.11.2.1

    Une bibliothèque fournie avec WooCommerce (jQuery BlockUI 2.7.0), marquée avec la version de WooCommerce

  • /plugins/elasticpress/?ver=1792138636

    Un horodatage (16 octobre 2026), pas la version d'ElasticPress

  • + 13 autres dossiers de pluginsinstagram-feed-prowoo-discount-ruleswoo-discount-rules-prowoo-variation-swatcheswoocommerce-back-in-stock-notificationswp-rocketsimple-cloudflare-turnstilekount-fraud-preventiondatalayer-for-woocommerceaddify-advanced-split-ordernalgene-customizervital-theme-modificationsvital-message-bar-master

Les plugins qui n'ajoutent rien à la page : invisibles pour tout détecteur

Le style.css du thème enfant désigne Genesis comme parent (Template: genesis), et l'en-tête de Genesis donne sa version, 3.5.0. Sur les trois valeurs ?ver=, l'une est la version du plugin, une autre celle d'une bibliothèque fournie, la dernière un horodatage.

Comment savoir quel thème Shopify utilise une boutique ?

Cherchez Shopify.theme dans le code source de la page. Toutes les boutiques Shopify que nous avons vérifiées contiennent cet objet, et un détecteur de thème Shopify le lit : le nom du thème dans cette boutique, le thème sur lequel il repose avec sa version, son numéro dans le Theme Store et s'il s'agit du thème publié.

Le nom est celui que le marchand a donné à sa copie, il peut donc en dire peu : la boutique du musée LACMA appelle son thème « Updated copy of Kingdom ». schema_name et schema_version désignent le thème sous-jacent, Kingdom 4.3.1, et theme_store_id est son numéro dans le Theme Store de Shopify.

Les grandes marques utilisent souvent leur propre thème : celui d'allbirds.com repose sur allbirds-theme 1.231.12, sans numéro du Theme Store. La plateforme elle-même est confirmée par les autres marques de Shopify, comme son en-tête powered-by: Shopify et le cookie _shopify_essential.

Shopify.theme, décortiqué · allbirds.com, 24 octobre 2026
  1. Shopify.theme = {
  2. 1"name": "[DNAM Theme July 2026]",
  3. 2"id": 130450260048,
  4. 3"schema_name": "allbirds-theme",
  5. "schema_version": "1.231.12",
  6. 4"theme_store_id": null,
  7. 5"role": "main"
  8. }
  1. 1Le nom que le marchand a donné à cette copie du thème
  2. 2L'identifiant du thème dans cette boutique
  3. 3Le thème sur lequel il repose, et la version de ce thème
  4. 4Son numéro dans le Theme Store de Shopify : aucun ici
  5. 5main : le thème publié que voient les clients

Trois boutiques, trois types de thème

BoutiqueNom dans la boutiqueRepose surTheme Store
allbirds.comThème maison[DNAM Theme July 2026]allbirds-theme 1.231.12aucun
theme-dawn-demo.myshopify.comBoutique de démo de ShopifyDawnDawn 15.0.0#887
thelacmastore.orgBoutique de muséeUpdated copy of KingdomKingdom 4.3.1#725
Shopify ne documente pas l'objet Shopify.theme : nous le lisons donc tel qu'observé sur ces boutiques (la démo de Dawn porte Dawn 15.0.0, numéro 887 du Theme Store). Ses valeurs de role sont celles de Shopify : main est le thème publié.

Pourquoi un détecteur affiche-t-il « non trouvé » ?

Généralement parce que la page qu'il a lue ne porte pas les marques du CMS, et non parce qu'il n'y a aucun CMS. Quatre cas couvrent l'essentiel.

Nous nommons le cas quand nous pouvons le voir : un contrôle anti-bot à la place du site, un framework sans marque de CMS, des marques que le propriétaire du site a désactivées, ou une page qui tourne sur un autre système que le reste du site.

Et parfois, il n'y en a vraiment aucun : W3Techs ne trouve aucun CMS qu'il reconnaît sur 32,1 % des sites web ; un détecteur qui ne trouve rien sur environ un site sur trois fonctionne donc normalement.

Quatre vraies raisons, observées les 23 et 24 octobre 2026
Bloqué par la protection anti-bot

drupal.org

3 Ko · pas le site

Fastly a répondu par une page « Client Challenge » de 3 Ko au lieu du site : aucun balisage Drupal à lire. Nous indiquons « bloqué » et proposons une analyse dans un navigateur.

Un front-end sans marque de CMS

openai.com

framework · CMS possible

Next.js sur Vercel. Les textes peuvent venir d'un CMS headless ; seul l'hôte d'images de Contentful le suggère, la réponse reste donc « Possible ».

Marques désactivées

nalgene.com

generator retiré · toujours Confirmé

Pas de balise generator WordPress, mais l'en-tête REST Link, les chemins /wp-content/ et ?ver=7.1.3 désignent toujours WordPress. Masquer toutes les marques est rarement complet.

Un autre système sur une autre page

ghost.org

/ = Hugo · /blog/ = Ghost

La page d'accueil de ghost.org est construite avec Hugo ; son /blog/ tourne sous Ghost 6.73. Nous vérifions une URL : collez la page qui vous intéresse, y compris une section boutique ou blog.

La bande de chaque carte est le même type de lecture que celle de l'outil, en miniature : où se trouvaient les marques, et ce qui manquait.

Que trouve une analyse dans un navigateur qu'une vérification normale manque ?

Tout ce qui arrive après le HTML : les balises ajoutées par un gestionnaire de balises, les pixels de mesure d'audience et de publicité, les outils de chat et de consentement, et les scripts qui n'existent qu'une fois JavaScript exécuté. Sur allbirds.com, un vrai Chrome a trouvé 15 technologies que la lecture du HTML de la page avait manquées.

Une vérification normale lit ce qu'envoie le serveur. Elle est rapide et montre la plateforme, le thème et l'essentiel des technologies du site. Une analyse dans un navigateur charge la page dans Chrome pendant quelques secondes, laisse ses scripts s'exécuter et lit ce qu'ils chargent.

Lors de notre test sur cinq sites, le navigateur n'a jamais perdu une technologie trouvée par la lecture côté serveur, et il en a ajouté entre 2 (Wikipedia) et 27 (TechCrunch). Les sites gérés via un gestionnaire de balises y gagnent le plus ; une simple page de wiki change à peine.

Lecture côté serveur et vrai navigateur · cinq sites, 24 octobre 2026
  • allbirds.com10+15389 requêtes · 8,1 s
  • bbc.com14+19201 requêtes · 6,3 s
  • nextjs.org6+883 requêtes · 3,6 s
  • techcrunch.com17+27237 requêtes · 6,8 s
  • wikipedia.org7+240 requêtes · 3,8 s
  • Dans le HTML
  • Seulement dans un navigateur

Trouvé seulement dans un navigateur sur allbirds.com

Mesure d'audience et marketing

  • Google Analytics
  • Facebook Pixel
  • Microsoft Clarity
  • OneTrust
  • Attentive
  • Impact
  • DoubleClick Floodlight

Frameworks et bibliothèques

  • Vue.js
  • GSAP
  • Framer Motion
  • core-js
  • Datadog
  • Goober

Polices

  • Google Font API

Commerce

  • Shop Pay
Un chargement par site dans Chrome depuis l'Inde (chargement plus 3 secondes), comparé avec les mêmes règles que le HTML ; les chiffres varient selon les bandeaux de consentement, la région et le moment. Certaines trouvailles propres au navigateur laissent une trace qu'une règle plus complète pourrait lire : le script de préchargement de Shop Pay figure dans le HTML d'allbirds.com.

Un site peut-il cacher son CMS ?

En partie. Un CMS auto-hébergé permet à son propriétaire de désactiver la balise generator et de renommer un chemin ou deux, mais la plateforme continue de façonner la page ; les plateformes hébergées comme Shopify et Wix ne peuvent pas du tout cacher leurs marques.

Le camouflage est rarement complet. L'extrait de code courant pour WordPress retire la balise generator de la page, mais pas du flux RSS ; renommer /wp-json/ conserve le lien rel="https://api.w.org/", et déplacer wp-content laisse encore un dossier /themes/ et des numéros ?ver= dans la page.

C'est pourquoi « non trouvé » ne signifie jamais « pas de CMS » : une page propre peut tout de même tourner sur n'importe lequel d'entre eux. Quand un site se cache bien, notre réponse descend à Probable ou Possible et montre les marques qui subsistent.

Désactiver une marque, et ce qui reste visible
  • Balise generator de WordPress<meta name="generator" content="WordPress 7.1.3">Désactivée avecremove_action( 'wp_head', 'wp_generator' )Ce qui reste visibleLa ligne generator du flux RSS<generator>https://wordpress.org/?v=7.1.3</generator>
  • Chemin REST de WordPress/wp-json/Désactivée avecadd_filter( 'rest_url_prefix', … )Ce qui reste visibleLa relation du lienrel="https://api.w.org/"
  • Le dossier wp-content/wp-content/Désactivée avecWP_CONTENT_DIR · WP_CONTENT_URLCe qui reste visibleLe dossier themes qu'il contient, et les numéros ?ver=…/themes/<name>/?ver=
  • En-tête de Next.jsx-powered-by: Next.jsDésactivée avecpoweredByHeader: falseCe qui reste visibleSes chemins de fichiers/_next/static/
  • Balise generator de Hugo<meta name="generator" content="Hugo …">Désactivée avecdisableHugoGeneratorInject = trueCe qui reste visibleRien : un site statique ne fait tourner aucun CMS
  • Version de Joomla<meta name="generator" content="Joomla! …">Désactivée avecMetaVersionDésactivé par défautCe qui reste visibleLa balise generator, sans versionJoomla! - Open Source Content Management
  • Shopify{{ content_for_header }}Désactivée avecImpossible à désactiverCe qui reste visibleSes scripts et cookies sur chaque page_shopify_essentialpowered-by: Shopify
  • Wixstatic.wixstatic.com/mediaDésactivée avecImpossible à désactiverCe qui reste visibleSon hôte de médiasstatic.wixstatic.com/media
Chaque interrupteur est un réglage propre à la plateforme, tiré de sa documentation ou de son code source. Les systèmes auto-hébergés peuvent se faire discrets ; les plateformes hébergées imposent leurs propres scripts et hôtes de fichiers.

Pourquoi une version de CMS exposée est-elle importante ?

Parce que les anciennes versions comportent des failles déjà publiques. Le guide de durcissement de WordPress lui-même indique que les anciennes versions ne reçoivent plus de mises à jour de sécurité et que, une fois un correctif publié, la manière d'exploiter la faille est presque certainement publique.

Un numéro de version ne prouve pas pour autant qu'un site soit exposé. Seul WordPress 7.1 est officiellement pris en charge, et pourtant, le 6 octobre 2026, WordPress a publié une nouvelle version sur chaque branche jusqu'à la 4.7 : un site en 6.9.10 a donc la dernière version de sa branche.

C'est pourquoi nous montrons la version que porte une page, ne la marquons « dernière » que si elle correspond à la version la plus récente de WordPress.org et ne disons jamais qu'un site est vulnérable. Drupal n'affiche que sa version majeure, ce qui suffit à repérer une version ancienne : Drupal 7 a perdu son support de sécurité le 5 janvier 2025.

La dernière version de chaque branche de WordPress · au 24 octobre 2026
Part des sites WordPress (W3Techs)
  • Version 7
    • 7.1.3 dernière · la seule branche prise en charge
    • 7.0.7
    66,9 %
  • Version 6
    • 6.9.10
    • 6.8.11
    • 6.7.10
    • 6.6.10
    • 6.5.13
    • 6.4.13
    • 6.3.13
    • 6.2.14
    • 6.1.15
    • 6.0.17
    26,3 %
  • Version 5
    • 5.9.19
    • 5.8.18
    • 5.7.20
    • 5.6.22
    • 5.5.23
    • 5.4.24
    • 5.3.26
    • 5.2.29
    • 5.1.27
    • 5.0.30
    4,7 %
  • Version 4
    • 4.9.34
    • 4.8.33
    • 4.7.38
    • 4.6.30
    • 4.5.33
    • 4.4.34
    • 4.3.35
    • 4.2.39
    • 4.1.42
    • 4.0.38
    2,0 %
  • Version 3
    • 3.9.40
    • 3.8.41
    • 3.7.41
    • 3.6 et antérieures
    0,2 %
  • Publiée le 6 octobre 2026
  • Dernière version en juillet 2025
  • Dernière version le 30 novembre 2022
  • Aucune version depuis 2013
Chaque branche de la 4.7 à la 7.1 a reçu une version le 6 octobre 2026, les plus anciennes sous forme de rétroportages de courtoisie ; seule la 7.1 est officiellement maintenue. À côté de chaque version majeure : sa part parmi les sites WordPress dont W3Techs peut voir la version (23 octobre 2026).

Est-ce un vérificateur de vulnérabilités de site web ?

Un vérificateur passif. Pour chaque version exacte qu'un site montre dans ses en-têtes, dans sa page ou lors d'une analyse dans un navigateur, il liste les avis de sécurité publiés qui la concernent, dont des CVE, d'OSV.dev ou, pour une bibliothèque JavaScript repérée par son fichier, de Retire.js ; le support de la branche selon endoflife.date ; et nos propres alertes, comme PHP2Shell. Il n'envoie jamais de sondes ni de requêtes d'attaque.

Un numéro de version a ses limites. Le paquet d'une distribution Linux peut contenir des correctifs rétroportés sous un ancien numéro, un avis peut supposer une fonctionnalité que le site n'utilise pas, et beaucoup de sites masquent leurs versions. La réponse liste donc des faits sur une version (« 36 avis publiés concernent Next.js 14.1.0 ») et ne dit jamais qu'un site est vulnérable.

Derrière Cloudflare, l'en-tête Server indique « cloudflare », ce qui masque la version du serveur web lui-même, mais les autres en-têtes du site passent : une version de PHP dans X-Powered-By reste visible. Pour tester sérieusement votre propre site, utilisez un scanner de vulnérabilités que vous avez l'autorisation de lancer contre lui.

D'une version à trois réponses · trois cas réels, 24 octobre 2026

  1. 1Le serveur de développement d'une app Flaskflask-app.example

    Ce qu'envoie le siteServer: Werkzeug/2.0.1 Python/3.8.10

    Werkzeug2.0.1Avis publiés · OSV.dev11 avis2 élevésSupport de la version · endoflife.date–absent de cette sourceNotre alerte–absent de cette source
    Python3.8.10Avis publiés · OSV.dev–absent de cette sourceSupport de la version · endoflife.dateTerminé le 7 oct. 2024Notre alerte–absent de cette source

  2. 2PHP derrière Cloudflareshop.example

    Ce qu'envoie le siteServer: cloudflareVersion du serveur web : masquée par CloudflareX-Powered-By: PHP/7.4.33

    PHP7.4.33Avis publiés · OSV.dev–absent de cette sourceSupport de la version · endoflife.dateTerminé le 28 nov. 2022Notre alertePotentiellement vulnérablePHP2Shell · aucune version corrigée du projet PHP pour la 7.4

  3. 3Next.js, vu lors d'une analyse dans un navigateurapp.exampletrouvé lors d'une analyse dans un navigateur

    Ce qu'envoie le sitewindow.next.version → "14.1.0"

    Next.js14.1.0Avis publiés · OSV.dev36 avis4 critiquesSupport de la version · endoflife.dateTerminé le 26 oct. 2025dernière : 14.2.35Notre alerte–absent de cette source
Chaque version telle qu'un en-tête, une page ou une analyse dans un navigateur la montre, vérifiée le jour du contrôle : les avis d'OSV.dev (une faille listée par deux bases n'est comptée qu'une fois), les dates de support d'endoflife.date et nos propres alertes. Un tiret signifie que cette source ne couvre pas le produit. Les hôtes sont inventés ; les cas et les réponses sont réels.

Comment se compare-t-il à BuiltWith, Wappalyzer et WhatCMS ?

BuiltWith répond à partir de son propre index du web, Wappalyzer propose des résultats vérifiés au cours des 30 derniers jours ou une lecture en direct qui coûte cinq recherches, et WhatCMS lit la page en direct mais affiche les recherches récentes sur sa page d'accueil. Vérificateur de CMS et des technologies d'un site web, ce détecteur lit la page que vous lui donnez, maintenant, et montre la ligne qui fonde chaque réponse.

Un index est utile pour l'historique : l'API de BuiltWith indique quand il a indexé un domaine pour la dernière fois. Une lecture en direct montre la page exacte que vous collez telle qu'elle est maintenant, y compris une boutique ou un blog dans un sous-dossier.

L'usage gratuit diffère aussi : Wappalyzer demande un compte pour 50 recherches par mois, les recherches sur un seul site sont gratuites chez BuiltWith, et l'offre API gratuite de WhatCMS comprend 500 détections par mois, avec des recherches privées à partir de 40 $ US par mois. Cette page ne demande aucun compte et ne publie rien.

Quatre façons de répondre à « avec quoi ce site est-il fait ? » · 24 octobre 2026

DNS RobotCette page

Répond à partir de
La page que vous collez, lue maintenant, avec la ligne derrière chaque réponse
Usage gratuit
Sans compte ; rien n'est publié
Bon à savoir
Une analyse dans un vrai navigateur, sur demande

BuiltWith

Répond à partir de
Son propre index du web, exploré comme par un moteur de recherche
Usage gratuit
Recherches sur un seul site
Bon à savoir
Son API indique quand il a indexé un domaine pour la dernière fois

Wappalyzer

Répond à partir de
Des résultats vérifiés dans les 30 jours, ou une lecture en direct
Usage gratuit
50 recherches par mois avec un compte
Bon à savoir
Un résultat en direct compte pour 5 recherches

WhatCMS

Répond à partir de
La page, récupérée quand vous la demandez
Usage gratuit
API : 500 détections par mois
Bon à savoir
Affiche les recherches récentes sur sa page d'accueil ; recherches privées à partir de 40 $ US par mois
Relevé sur les pages de chaque outil le 24 octobre 2026. Les offres changent ; vérifiez les leurs avant de choisir.

Détecteur de CMS : questions et réponses

Comment connaître le CMS d'un site web ?

Pour savoir quel CMS utilise un site, collez son adresse dans le détecteur de CMS ci-dessus. Il lit les en-têtes, les cookies et le HTML de la page ainsi que les enregistrements DNS du domaine, puis nomme la plateforme avec la ligne de code qui le prouve et notre degré de certitude. Vous pouvez aussi vérifier vous-même : affichez le code source de la page et cherchez generator, wp-content, Shopify.theme ou wixstatic.

Peut-on détecter le thème WordPress d'un site ?

Oui, quand la page charge un fichier du dossier du thème. Nous prenons le nom du dossier dans /wp-content/themes/<name>/ et lisons l'en-tête du style.css de ce thème : son nom, son auteur et sa version. Un thème enfant nomme son parent dans une ligne Template: : vous voyez donc les deux, comme Nalgene Twenty Twenty sur Genesis 3.5.0. Un hébergeur qui bloque les fichiers du thème ne laisse voir que le nom du dossier.

Peut-on savoir quel thème Shopify utilise une boutique ?

Oui. Les boutiques Shopify contiennent dans leur HTML un objet Shopify.theme avec le nom du thème dans cette boutique, le thème sur lequel il repose (schema_name) et sa version, son numéro dans le Theme Store et son rôle. Le nom peut être tout ce que le marchand a saisi, comme « Updated copy of Kingdom » : nous montrons donc aussi le thème sous-jacent. Le thème maison d'une marque, comme celui d'allbirds.com, n'a pas de numéro du Theme Store.

Peut-il trouver tous les plugins d'un site WordPress ?

Aucun détecteur ne le peut. Un plugin n'apparaît que s'il ajoute quelque chose à la page : un script ou une feuille de style sous /wp-content/plugins/<name>/, un commentaire ou un nom de classe. Les plugins qui agissent dans le tableau de bord ou sur d'autres pages, comme les sauvegardes, la sécurité ou un formulaire sur la page de contact, ne laissent aucune trace sur la page d'accueil. Vérifier la page où un plugin agit en trouve davantage.

Pourquoi dit-il qu'un site n'est pas sous WordPress alors que je sais qu'il l'est ?

Généralement parce que la page reçue ne montrait pas les marques de WordPress. Une protection anti-bot a pu répondre par une page de vérification au lieu du site (nous indiquons « bloqué »), le propriétaire a pu retirer la balise generator et déplacer wp-content, ou l'adresse fait tourner autre chose : la page d'accueil de ghost.org tourne sous Hugo, son blog sous Ghost. Vérifiez la page exacte ou lancez une analyse dans un navigateur.

Peut-il voir le CMS derrière Cloudflare ?

En général, oui. Cloudflare laisse passer les en-têtes et le HTML du site lui-même : l'en-tête REST de WordPress, ses chemins de fichiers et un en-tête X-Powered-By restent visibles ; seul l'en-tête Server devient « cloudflare », ce qui masque la version du serveur web. L'exception est le contrôle anti-bot : quand Cloudflare ou un autre pare-feu répond par une page de vérification au lieu du site, nous indiquons que la vérification a été bloquée, et une analyse dans un navigateur peut passer.

Pourquoi deux détecteurs de CMS donnent-ils des réponses différentes ?

Ils lisent des choses différentes à des moments différents. BuiltWith répond à partir de son index du web et les résultats en cache de Wappalyzer peuvent avoir jusqu'à 30 jours, alors qu'un outil en direct lit la page maintenant. Les outils peuvent aussi vérifier une autre page, appliquer d'autres règles ou recevoir un contrôle anti-bot au lieu du site. C'est pourquoi chacune de nos réponses montre la ligne sur laquelle elle repose.

Quelle est la fiabilité de ce détecteur de CMS ?

Chaque réponse porte ses preuves et l'une de trois étiquettes. Confirmé signifie deux signaux indépendants, ou un seul que seule cette plateforme produit, comme son propre en-tête, cookie ou chemin de fichier. Probable signifie un signal que n'importe qui pourrait copier ou retirer, comme une balise generator. Possible signifie un indice indirect, comme un hôte d'images. Une page bloquée ou vide est signalée comme telle, jamais comme « pas de CMS ».

Pourquoi la version du CMS n'apparaît-elle pas ?

Beaucoup de plateformes ne l'affichent pas. Joomla masque sa version par défaut, l'en-tête de Drupal ne donne que la version majeure et Ghost seulement la majeure et la mineure. WordPress affiche sa version exacte sauf si le propriétaire la retire, et les adresses de ses fichiers la portent souvent encore dans ?ver=. Nous ne montrons qu'une version réellement portée par un signal de la page, et nous disons où nous l'avons trouvée.

Peut-il vérifier si un site a des vulnérabilités connues (CVE) ?

Oui, passivement, pour les versions qu'un site affiche. Quand un en-tête, la page ou une analyse dans un navigateur indique une version exacte, comme Next.js 14.1.0, nous listons les avis qui la concernent selon OSV.dev (ou Retire.js, pour une bibliothèque JavaScript repérée par son fichier), si sa branche est encore maintenue (endoflife.date) et nos alertes, comme PHP2Shell. Nous n'envoyons aucune sonde et ne qualifions jamais un site de vulnérable : un correctif rétroporté n'apparaît pas dans un numéro de version.

Peut-il vérifier si un site est touché par PHP2Shell ?

Seulement d'après la version de PHP qu'il annonce. Si son en-tête X-Powered-By ou Server mentionne PHP, nous la comparons aux correctifs publiés par php.net le 21 octobre 2026 (8.5.12, 8.4.27, 8.3.36 et 8.2.35), comme le fait le php2shell-checker d'OpenAI : une version plus ancienne sur ces branches, ou tout PHP de 5.4 à 8.1, est « potentiellement vulnérable ». Le paquet d'une distribution peut contenir un correctif rétroporté, et un site qui masque sa version de PHP ne peut pas être vérifié ainsi.

Conservez-vous ou publiez-vous les sites que je vérifie ?

Nous ne les publions jamais : il n'existe aucune liste publique des recherches récentes. Un résultat est conservé peu de temps pour qu'une nouvelle vérification de la même page soit instantanée, puis il est supprimé. Le site vérifié voit une requête de notre serveur, jamais votre adresse IP : elle s'identifie comme le détecteur de CMS de DNS Robot, et une analyse dans un navigateur charge la page depuis le réseau de Cloudflare.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Outils associés