Comment reconnaître les technologies d’un site web

Quand un site me plaît, j’aime comprendre comment il a été construit. Le CMS, les bibliothèques JavaScript, le fournisseur d’analytique ou le serveur laissent souvent des indices visibles.

Aucun outil ne voit tout. Un proxy, un CDN, une compilation ou une configuration volontairement discrète peut masquer la technologie réelle. Le résultat reste donc une estimation.

Commencer avec Wappalyzer

Wappalyzer analyse une URL et recherche des signatures connues dans le HTML, les scripts, les cookies et les en-têtes. Il peut reconnaître un CMS, un framework, une solution e-commerce, un outil d’analytique ou un service publicitaire.

L’extension de navigateur est pratique pour une vérification rapide. Le service en ligne évite d’installer une extension si tu n’en as besoin qu’une fois.

Comparer avec BuiltWith

BuiltWith fournit une seconde lecture. Il classe les technologies détectées par catégories et conserve parfois des informations historiques.

Quand les deux services donnent le même résultat, la confiance augmente. Quand ils se contredisent, je reviens aux données du navigateur.

Lire les en-têtes sans extension

Une commande suffit pour afficher les en-têtes publics et suivre les redirections :

1curl --head --location https://example.com

Un en-tête server peut identifier Nginx, Apache ou un CDN. Il peut aussi décrire seulement le proxy placé devant l’application. Je le traite comme un indice, pas comme une preuve.

Vérifier dans Chrome DevTools

Ouvre les outils de développement de Chrome, puis regarde :

1. Network pour les domaines appelés, les fichiers JavaScript et les en-têtes HTTP.
2. Sources pour les noms de paquets, les commentaires et les sources maps publiques.
3. Application pour les cookies, le stockage local et les service workers.
4. Le code HTML pour les balises meta, les classes et les chemins de fichiers.

Quelques indices sont faciles à reconnaître :

1/wp-content/          WordPress probable
2/_next/static/        Next.js probable
3data-reactroot        React sur certains anciens rendus
4server: nginx         Nginx annoncé par le serveur

Le mot important est « probable ». Un chemin peut être imité, un en-tête supprimé et une bibliothèque incluse sans être au cœur du projet.

Ce que ces outils ne doivent pas devenir

Cette analyse sert à apprendre, préparer une migration, étudier la compatibilité d’un service ou comprendre un marché. Elle ne donne pas l’autorisation de tester des failles.

Je garde une règle simple : plusieurs indices, plusieurs outils et aucune certitude lorsque le serveur ne l’expose pas. C’est plus utile qu’une liste impressionnante mais fausse.