Outil gratuit
Avec quoi ce site est-il construit ?
On lit ce que le site publie de lui-même : ses en-têtes de réponse, sa balise generator, les chemins de ses fichiers, le nom de ses cookies. Chaque ligne du résultat porte la preuve qui l'a déclenchée — et ce qu'on ne peut pas voir, on le dit.
Pourquoi regarder ça avant de reprendre un site
Reprendre un site sans savoir ce qu'il y a dessous, c'est accepter une dette qu'on n'a pas chiffrée. Un WordPress dont la version est publiée depuis deux ans, une boutique sur une plateforme qu'il faudra migrer, un cadre applicatif que personne dans l'équipe ne connaît : chacun de ces constats change le devis. Et une fois le site à votre charge, ce qui compte n'est plus ce qu'il utilise mais ce qui va se casser — le domaine, le certificat, les enregistrements DNS, la réputation d'envoi.
Comment la détection fonctionne
Une requête ordinaire, la même qu'un navigateur, sur la page d'accueil. On lit ensuite quatre sources : les en-têtes de la réponse, la balise generator du HTML, les chemins des fichiers appelés par la page, et le nom des cookies posés. Chaque correspondance est affichée avec le morceau exact qui l'a déclenchée. Aucun script n'est exécuté, aucune faille n'est testée, aucune adresse n'est devinée : ce qui n'est pas publié n'est pas détecté, et c'est dit.
La réponse, à la loupe
Le site ne cache rien, il le publie
Il n'y a aucune enquête là-dedans : les en-têtes et les premières lignes du document annoncent le serveur, le langage et le CMS. Cliquez une ligne surlignée pour voir ce qu'elle livre, puis regardez la même page une fois les bavardages coupés.
HTTP/1.1 200 OK
content-type: text/html; charset=UTF-8
<!doctype html>
Indices lisibles sans rien forcer : 5
Cliquez une ligne surlignée pour voir ce qu'elle livre.
Réponse d'exemple, sur un nom de domaine réservé aux démonstrations.
Le périmètre de la mesure
Le silence n'est pas un verdict.
« Rien de détecté » signifie « aucun marqueur connu dans ce qui a été servi », pas « ce site n'utilise rien ».
- 4sources lues dans la réponse
- 1page lue : l'accueil
- 0script exécuté
Lire le résultat
Chaque ligne porte un nom, une preuve et parfois une version. La preuve est là pour que vous jugiez vous-même : un outil de détection qui n'affiche pas ce qui l'a fait décider demande une confiance qu'il n'a pas méritée.
- Une technologie et sa preuve
- Le nom vient d'une table de marqueurs, la preuve du site lui-même : un en-tête, une balise, un chemin de fichier, un nom de cookie. Un marqueur dans un en-tête propre à une plateforme est le plus fiable ; un chemin d'actif l'est presque autant, parce qu'il faudrait le réécrire exprès.
- Une version affichée
- Le site publie un numéro de version. Ce n'est pas une faille, c'est un renseignement : quand une faille sort sur cette version, il n'y a plus rien à chercher. Une version de serveur se retire en une ligne de configuration, celle d'un CMS en retirant sa balise generator.
- Rien de détecté
- Le résultat le plus mal lu de cette page. Il signifie « aucun marqueur connu dans ce qui a été servi », pas « ce site n'utilise rien ». Un serveur qui a retiré ses en-têtes, un site derrière un cache, une page d'accueil purement statique : trois cas très courants où la bonne configuration produit un résultat vide.
- Pas de HTML
- L'adresse a répondu autre chose qu'une page — une redirection vers une application, un fichier, une réponse d'interface de programmation. Seuls les en-têtes ont pu être lus.
- Lecture après redirection
- L'adresse demandée renvoyait ailleurs, et c'est cette destination qui a été analysée. L'adresse réellement lue est affichée en bas du résultat : c'est celle qui compte, pas celle qu'on a tapée.
Les quatre façons de mal lire une détection
Un outil de détection ne se trompe pas souvent sur ce qu'il voit. C'est l'interprétation qui dérape.
Prendre l'absence de détection pour l'absence de technologie
Ce qui la provoque : Un résultat vide ressemble à un verdict. Il n'en est pas un : retirer l'en-tête « server » et la balise generator est une bonne pratique, et un site bien configuré se détecte mal par construction.
Le geste qui corrige : Lisez le résultat comme « ce que le site publie », jamais comme « ce que le site utilise ». Quand il faut savoir, il faut demander à celui qui l'a fait.
Croire la balise generator sur parole
Ce qui la provoque : C'est une déclaration du site sur lui-même. Un thème peut en laisser une périmée, un plugin peut la réécrire, et rien n'oblige personne à la tenir à jour.
Le geste qui corrige : Croisez-la avec une deuxième source : un chemin d'actif, un en-tête propre à la plateforme, un nom de cookie. C'est pour ça que cet outil affiche la provenance de chaque ligne.
Confondre l'hébergeur et le réseau de diffusion
Ce qui la provoque : Un site derrière un réseau de diffusion ne montre plus que les en-têtes de ce réseau. Cloudflare devant un serveur ne dit rien du serveur.
Le geste qui corrige : Lisez « réseau de diffusion » comme ce qui est devant, pas comme ce qui héberge. Pour savoir où le site est réellement servi, il faut regarder la zone DNS, et souvent demander.
Laisser la version du CMS publiée
Ce qui la provoque : C'est le réglage par défaut : la plupart des systèmes de gestion de contenu inscrivent leur version dans la balise generator, et leurs fichiers de base la portent dans un paramètre d'adresse.
Le geste qui corrige : Retirez la balise, et sachez que le numéro peut rester ailleurs — cet outil le montre justement pour ça. Mais l'essentiel n'est pas de cacher la version : c'est de la tenir à jour, parce qu'un attaquant qui automatise ne lit pas les balises, il essaie.
Où l'on regarde, et ce que chaque source peut dire
Quatre sources, quatre degrés de fiabilité. La colonne de droite est la raison pour laquelle aucune ne suffit seule.
| Source | Exemple | Ce qu'elle prouve | Sa limite |
|---|---|---|---|
| En-tête server | server: nginx/1.24.0 | Le logiciel serveur qui a répondu, et sa version quand il la publie. | Souvent retiré ou remplacé, et masqué par un réseau de diffusion placé devant. |
| En-tête x-powered-by | x-powered-by: PHP/8.2.12 | Le langage ou le cadre applicatif, et sa version quand elle est publiée. | Désactivable en une ligne de configuration. Son absence ne prouve rien. |
| En-tête propre à une plateforme | cf-ray, x-drupal-cache, x-shopify-stage | La preuve la plus solide : ces en-têtes sont posés par la plateforme et n'existent pas ailleurs. | Ne concerne que les plateformes qui en posent un. |
| Balise generator | meta name="generator" content="WordPress 6.5.2" | Ce que le site déclare de lui-même, avec sa version dans le cas le plus fréquent. | Déclarative : elle peut être périmée, réécrite ou retirée. |
| Chemin d'un fichier appelé | /wp-content/, /_next/static/, cdn.shopify.com | Presque aussi solide qu'un en-tête de plateforme : il faudrait réécrire toute l'arborescence pour le faire mentir. | Absent des pages très légères, ou déplacé sur un domaine d'actifs séparé. |
| Paramètre de version d'un actif | /wp-includes/js/…?ver=6.5.2 | La version du noyau, quand elle est laissée dans le paramètre. Elle survit souvent au retrait de la balise generator. | Modifiable, et parfois figée à une valeur qui ne veut plus rien dire. |
| Nom d'un cookie de session | PHPSESSID, laravel_session, ASP.NET_SessionId | Le langage ou le cadre applicatif : ce sont leurs noms par défaut. | Renommables. On lit le nom, jamais le contenu. |
Ce que cet outil ne sait pas voir
La liste compte autant que la précédente. Un outil de détection qui ne publie pas ses angles morts laisse croire que son silence est un verdict.
| Ce qu'on ne voit pas | Pourquoi |
|---|---|
| Les bibliothèques compilées dans un fichier unique | Un outil de construction moderne fusionne et minifie tout. Le nom de la bibliothèque disparaît du fichier livré : il n'y a plus rien à reconnaître. |
| Les cadres CSS comme Tailwind ou Bootstrap | Compilés, ils ne laissent que des noms de classes — qui peuvent avoir été recopiés à la main. Détecter sur cette base produirait des faux, et un faux vaut moins qu'un vide. |
| Ce qui n'apparaît qu'après exécution des scripts | Cet outil n'exécute aucun JavaScript. Une bibliothèque chargée par un script après l'affichage reste invisible. |
| Le reste du site | Seule la page d'accueil est lue. Une boutique sur un sous-domaine, un blog dans un sous-dossier, un espace client sur une autre plateforme : rien de tout cela n'apparaît. |
| La base de données, le système, les versions internes | Rien de tout cela ne voyage dans une réponse HTTP. Un outil qui l'affiche le devine. |
| Ce que le serveur a délibérément caché | En-têtes retirés, balise generator supprimée, actifs renommés : c'est une bonne pratique, et elle marche aussi contre nous. |
Aucun contrôle de vulnérabilité n'est effectué : l'outil fait une requête ordinaire, lit la réponse, et s'arrête là.
Questions fréquentes
Comment savoir si un site est fait avec WordPress ?
Trois marqueurs le disent, et cet outil les cherche tous les trois : la balise generator quand elle n'a pas été retirée, les chemins « /wp-content/ » et « /wp-includes/ » dans les fichiers appelés par la page, et le paramètre de version sur les fichiers du noyau. Quand aucun n'apparaît, le site peut quand même être sous WordPress — il a simplement été nettoyé.
Peut-on connaître la version exacte du CMS ?
Seulement si le site la publie. C'est le cas par défaut pour beaucoup d'entre eux, dans la balise generator et dans le paramètre de version des fichiers de base. Cet outil affiche cette version quand il la lit, et n'en propose aucune quand elle est absente.
Faut-il cacher la version de son serveur et de son CMS ?
Le retrait est une bonne hygiène : il supprime un renseignement gratuit. Mais il ne protège pas — un attaquant qui automatise n'interroge pas les balises, il essaie les failles connues sur tout le monde. La mise à jour protège, le masquage ne fait que retirer un panneau indicateur.
Pourquoi l'outil ne détecte-t-il pas React, Vue ou Tailwind ?
Parce qu'ils ne laissent pas de marqueur fiable dans une page servie : les outils de construction les fusionnent et les minifient. Nous préférons ne rien afficher plutôt que d'annoncer une technologie sur une coïncidence de nom de classe. Les cadres qui laissent une empreinte sans ambiguïté — un chemin d'actifs propre, un attribut de balisage — sont détectés.
Pourquoi le résultat change-t-il d'un contrôle à l'autre ?
Un réseau de diffusion peut répondre depuis un cache pour une requête et depuis le serveur pour la suivante, avec des en-têtes différents. Certains sites servent aussi des pages différentes selon la provenance de la requête. La preuve affichée sous chaque ligne permet de voir exactement ce qui a changé.
Est-ce que ce contrôle est intrusif ?
Non. L'outil fait une requête ordinaire sur la page d'accueil, exactement comme un navigateur, et lit ce que le serveur lui envoie. Il n'essaie aucune adresse cachée, ne teste aucune faille, n'envoie aucun formulaire et ne lit le contenu d'aucun cookie.
Les preuves, telles quelles
Six marqueurs, et ce que chacun vaut
Chaque ligne du résultat porte le morceau exact qui l'a déclenchée. Les voici avec leur limite : c'est elle qui explique pourquoi aucun ne suffit seul.
server- Le logiciel serveur qui a répondu, et sa version quand il la publie. Souvent retiré, et masqué par un réseau de diffusion placé devant.
x-powered-by- Le langage ou le cadre applicatif, avec sa version. Désactivable en une ligne de configuration : son absence ne prouve rien.
cf-ray- Un en-tête propre à une plateforme — la preuve la plus solide, parce que ces en-têtes n'existent nulle part ailleurs.
generator- La balise par laquelle le site se déclare, avec sa version dans le cas le plus fréquent. Déclarative : elle peut être périmée, réécrite ou retirée.
/wp-content/- Un chemin de fichier appelé par la page. Presque aussi solide qu'un en-tête de plateforme : il faudrait réécrire toute l'arborescence pour le faire mentir.
PHPSESSID- Le nom d'un cookie de session, celui du langage par défaut. Renommable. On lit le nom, jamais le contenu.
L'interprétation qui dérape
Ce qu'on en conclut, ce que le résultat dit
Un outil de détection ne se trompe pas souvent sur ce qu'il voit. C'est la lecture qui dérape, et toujours aux quatre mêmes endroits.
Ce qu'on en conclut
Ce que le résultat dit
Rien n'est détecté : ce site n'utilise rien de connu.
Retirer l'en-tête server et la balise generator est une bonne pratique. Un site bien configuré se détecte mal par construction.
La balise annonce une version, c'est donc celle qui est installée.
C'est une déclaration du site sur lui-même. Un thème peut en laisser une périmée, un plugin peut la réécrire, et rien n'oblige personne à la tenir à jour.
Les en-têtes nomment un réseau de diffusion, c'est donc l'hébergeur.
Un réseau de diffusion ne montre que ses propres en-têtes : il est devant, il n'héberge pas. Pour savoir où le site est servi, il faut regarder la zone DNS.
Le résultat a changé depuis hier : l'outil est instable.
Un réseau de diffusion peut répondre depuis un cache pour une requête et depuis le serveur pour la suivante, avec des en-têtes différents.
Vingt contrôles, sans inscription
- Vérifier l'expiration de cinquante domaines d'un coup
- À qui appartient ce domaine, et depuis quand ?
- Où mène vraiment cette adresse ?
- Cette adresse est-elle ouverte aux robots ?
- Où en est la propagation DNS de mon domaine ?
- Générateur d'enregistrement SPF
- Quelle est la réputation de ce domaine ?
- Les en-têtes de sécurité de ce site
- Le bilan complet d'un domaine
- Quand expire ce nom de domaine ?
- Ce certificat SSL est-il valide ?
- Vos e-mails sont-ils authentifiés ?
- Ce domaine est-il sur une liste noire ?
- Quels serveurs reçoivent les e-mails de ce domaine ?
- Quels serveurs de noms répondent pour ce domaine ?
- Quels enregistrements TXT porte ce domaine ?
- Vers quoi pointe cet alias ?