# Quelle technologie utilise ce site, et est-elle encore à jour (/fr/blog/what-technology-is-this-website-using) Vous voulez savoir avec quoi un site est construit. Le site d'un concurrent, celui d'un prestataire que vous êtes sur le point de référencer, ou le vôtre après le passage de trois agences et d'un tag manager. La réponse rapide : collez l'URL dans l'[analyseur de technologies](/tools/tech-checker) gratuit. Il liste les bibliothèques et frameworks JavaScript que la page utilise, la version de chacun, si cette version est à jour, et les CVE connues qui la touchent. La réponse longue dépend de la raison de votre question. Savoir qu'une page utilise jQuery relève de l'anecdote. Savoir qu'elle utilise jQuery 1.12.4, d'une branche arrêtée depuis des années et touchée par quatre CVE publiées, est un constat. Cet article couvre les deux : comment voir ce qu'un site utilise, et comment savoir si quelque chose mérite votre attention. ## Comment savoir quelle technologie utilise un site [#comment-savoir-quelle-technologie-utilise-un-site] Tout ce qu'un navigateur télécharge est visible de l'extérieur. Cela couvre plus qu'on ne le pense : * Les bibliothèques et frameworks JavaScript : jQuery, React, Vue, Angular, Lodash, Bootstrap, et les bibliothèques intégrées aux widgets tiers. * Les services tiers : analytics, tag managers, widgets de chat, SDK de paiement, outils d'A/B testing. * La plateforme : un CMS comme WordPress ou Shopify se voit souvent dans les chemins des ressources et dans le balisage. * Une partie du côté serveur : des headers de réponse comme `Server` ou `X-Powered-By` peuvent nommer le serveur web ou le langage, quand le site ne les a pas retirés. Ce que vous ne pouvez pas voir, c'est tout ce que le navigateur ne reçoit jamais : le code côté serveur, les bases de données, les services internes et le processus de build exact. Un outil qui prétend lire tout cela à partir d'une URL devine. Il existe quatre façons de collecter la partie visible, de la plus manuelle à la plus automatique. ## Vérifier à la main dans le navigateur [#vérifier-à-la-main-dans-le-navigateur] Pour une page et quelques minutes, les outils de développement du navigateur répondent à la plupart des questions. 1. **Affichez le code source de la page.** Les balises de script, les liens de feuilles de style et les balises meta generator nomment souvent la plateforme directement, par exemple un chemin `wp-content` pour WordPress. 2. **Ouvrez le panneau Réseau**, filtrez sur **JS** et rechargez. Chaque URL de script apparaît. Un nom de fichier versionné ou un chemin de CDN comme `jquery-3.7.1.min.js` donne la bibliothèque et sa version. 3. **Lisez les headers de réponse** du document principal dans le même panneau. Un header `Server: nginx/1.18.0` ou `X-Powered-By: PHP/7.4` nomme un logiciel et sa version. Ces bannières sont en elles-mêmes une divulgation d'informations, détaillée dans [Headers de divulgation d'informations](/fr/docs/web-security/security-headers/information-disclosure-headers). 4. **Interrogez la bibliothèque elle-même** dans la console. La plupart des bibliothèques courantes exposent leur version sur leur objet global : ```js jQuery.fn.jquery // "3.7.1" angular.version // AngularJS only, { full: "1.8.3", ... } ``` La méthode manuelle a deux angles morts. Une bibliothèque intégrée à un autre fichier, comme le `widget.js` d'un éditeur, n'a pas de nom de fichier parlant. Et la console ne répond que pour la copie qui possède la variable globale : une page qui charge deux copies de jQuery ne vous en montre qu'une. Le [guide sur les versions de jQuery](/fr/blog/vulnerable-jquery-version) détaille ce cas. ## Extensions de navigateur et sites de recherche [#extensions-de-navigateur-et-sites-de-recherche] Les outils que l'on trouve en premier répondent largement à la question « avec quoi ce site est-il construit ». * **[Wappalyzer](https://www.wappalyzer.com/)** est une extension pour Chrome, Firefox, Edge et Safari qui montre la pile technique de la page ouverte. Une offre gratuite couvre un quota mensuel de recherches, et les offres payantes ajoutent des données d'entreprise et des listes de prospects. * **[BuiltWith](https://builtwith.com/)** recherche un domaine sur son site et renvoie un profil technologique, appuyé sur des années de données d'adoption. Son métier est la génération de prospects et les données de marché. * **[WhatRuns](https://www.whatruns.com/)** est une extension gratuite du même esprit, qui peut vous prévenir quand un site que vous suivez ajoute ou retire une technologie. Ils excellent sur la question de l'étendue : le CMS, l'hébergeur, la pile analytics et marketing. Ils ne sont pas conçus pour la question de sécurité. Aucun ne vous dit si la version utilisée par une page est obsolète, en fin de vie, ou touchée par une CVE publiée. ## Outils de développement qui détectent les versions vulnérables [#outils-de-développement-qui-détectent-les-versions-vulnérables] [Retire.js](https://github.com/RetireJS/retire.js) est la réponse open source historique à la question de sécurité. Son scanner en ligne de commande compare des fichiers JavaScript à une base de versions vulnérables connues et peut écrire le résultat sous forme de nomenclature logicielle (SBOM) CycloneDX. Il analyse des fichiers que vous avez déjà, comme une sortie de build ou des scripts téléchargés ; un scanner de site headless distinct couvre les pages en ligne. Son extension Chrome n'est pas publiée sur le Chrome Web Store et son extension Firefox est dépréciée : la ligne de commande est la voie maintenue. Lighthouse couvrait aussi ce besoin, avec un audit qui signalait les bibliothèques front-end touchées par des vulnérabilités connues. Cet audit a été retiré dans Lighthouse 10 : un rapport Lighthouse propre ne dit donc rien des CVE de vos bibliothèques. Ce sont deux outils de développeur. Ils conviennent à un pipeline ou à un terminal, pas à un coup d'œil rapide sur une URL par quelqu'un qui n'utilise pas Node.js. ## Vérifier versions, fin de vie et CVE connues depuis une URL [#vérifier-versions-fin-de-vie-et-cve-connues-depuis-une-url] L'[analyseur de technologies](/tools/tech-checker) répond à cette question de sécurité à partir d'une URL. Saisissez l'adresse d'une page : il affiche une ligne par technologie : * **Version.** La version utilisée, ou un tiret quand aucune version n'a pu être lue. * **Statut de la version.** À jour, obsolète, dormante (le projet n'a rien publié depuis longtemps) ou en fin de vie (la branche ne reçoit plus de correctifs). * **Dernière de la branche.** La version la plus récente de la même branche, pour connaître la plus petite mise à jour utile. * **Sévérité maximale.** La vulnérabilité connue la plus grave qui touche cette version. Dépliez une ligne pour voir où la technologie a été détectée et chaque vulnérabilité connue : son identifiant CVE, sa sévérité, un court résumé, la version qui la corrige et les liens vers les avis de sécurité. Deux points à garder en tête en lisant un résultat : * **Une CVE listée ne prouve pas que le site est exploitable.** Elle signifie que la version détectée tombe dans une plage qu'un avis public déclare touchée. L'exploitabilité dépend de l'usage que la page fait de la bibliothèque, et certains éditeurs corrigent une faille sans changer le numéro de version. * **La fin de vie compte même sans CVE.** Une branche qui ne reçoit plus de correctifs gardera la prochaine vulnérabilité pour toujours. C'est souvent le signal le plus précoce et le plus discret. L'analyseur est gratuit et ne demande aucun compte. Les résultats ne sont pas conservés : exportez ce que vous voulez garder. N'analysez que les sites qui vous appartiennent ou que vous êtes autorisé à évaluer ; l'analyseur lit les mêmes ressources publiques qu'un navigateur télécharge, et rien d'autre. ## Quel outil répond à quelle question [#quel-outil-répond-à-quelle-question] | | Analyseur de technologies CentralCSP | Wappalyzer | BuiltWith | Retire.js | | ------------------------------ | ---------------------------------------------------------- | ------------------------------------- | --------------------- | ------------------------------------------------------------ | | **Point de départ** | Une URL | La page ouverte dans votre navigateur | Un domaine | Des fichiers locaux, ou un scanner de site headless distinct | | **Nomme les technologies** | Oui, centré sur les bibliothèques et frameworks JavaScript | Oui | Oui | Bibliothèques JavaScript uniquement | | **Versions des bibliothèques** | Oui | Parfois | Pas sa priorité | Oui | | **CVE connues par version** | Oui | Non | Non | Oui | | **Statut de fin de vie** | Oui | Non | Non | Non | | **Export SBOM** | CycloneDX, CSV, PDF | Non | Non | CycloneDX | | **Gratuit** | Oui, sans compte | Une offre gratuite | Une recherche de base | Oui, open source | Choisissez selon la question. Pour « quel CMS et quelle pile marketing utilise cette entreprise », un site de recherche répond plus vite. Pour « une bibliothèque de cette page est-elle obsolète ou vulnérable », il faut des versions comparées aux avis de sécurité, ce que font Retire.js et l'analyseur de technologies. ## Exporter le SBOM d'un site web [#exporter-le-sbom-dun-site-web] Une liste à l'écran suffit pour un coup d'œil. Une revue fournisseur, un questionnaire de sécurité ou un audit demandent un fichier. L'analyseur de technologies exporte le même résultat de trois façons : * **JSON CycloneDX 1.6**, le format SBOM standard, avec chaque technologie comme composant et chaque vulnérabilité connue rattachée au composant qu'elle touche. Les outils de sécurité et de conformité le lisent directement. * **CSV**, une ligne par technologie et par vulnérabilité, pour un tableur ou un ticket. * **PDF**, un rapport daté dans la même mise en page que nos rapports de scan, pour un relecteur qui veut un document. Un SBOM daté des scripts chargés par une page de paiement est une preuve utile quand vous travaillez les exigences de PCI DSS v4 sur les scripts, que CentralCSP vous aide à respecter ; la [page PCI DSS](/platform/pci-dss) explique comment. ## Quand une analyse ponctuelle ne suffit pas [#quand-une-analyse-ponctuelle-ne-suffit-pas] Une analyse lit une page, une fois. Votre site a d'autres pages, et l'ensemble des scripts change à chaque déploiement et à chaque publication du tag manager. La bibliothèque à jour le lundi peut avoir une CVE le vendredi. Une couverture continue demande que le navigateur signale ce qu'il exécute. Le hash reporting de la politique de sécurité du contenu (CSP) le fait, et [Technologies](/fr/docs/platform/features/technologies) dans CentralCSP transforme ces reports en inventaire vivant de chaque version de bibliothèque chargée par vos visiteurs, avec des alertes quand un nouvel avis de sécurité touche l'une d'elles. [Comment détecter les bibliothèques JavaScript vulnérables sur un site en production](/fr/blog/detect-vulnerable-javascript-libraries) explique le mécanisme, et la [page chaîne d'approvisionnement](/platform/supply-chain) en fait le tour. Pour l'essayer sur votre site, [commencez gratuitement avec CentralCSP](/register). ## FAQ [#faq] ### Puis-je analyser les technologies d'un site qui ne m'appartient pas ? [#puis-je-analyser-les-technologies-dun-site-qui-ne-mappartient-pas-] Les technologies qu'une page charge sont publiques : le navigateur de chaque visiteur les télécharge. Les lire est passif, c'est ce que fait n'importe quel navigateur. Ne lancez des vérifications de sécurité que sur des sites qui vous appartiennent ou que vous êtes autorisé à évaluer, et considérez ce que vous trouvez sur le site d'un autre comme une information à lui transmettre. ### Un site peut-il cacher les technologies qu'il utilise ? [#un-site-peut-il-cacher-les-technologies-quil-utilise-] En partie. Un site peut retirer les bannières de version de ses headers, renommer ses fichiers et regrouper ses bibliothèques dans un seul fichier, ce qui met en échec les vérifications par nom de fichier et par header. Les bibliothèques s'exécutent toujours dans le navigateur : elles restent en général identifiables, mais pas toujours avec leur version. ### Pourquoi une technologie s'affiche-t-elle sans version ? [#pourquoi-une-technologie-saffiche-t-elle-sans-version-] Certains fichiers n'exposent aucune version, et certains services, comme un CDN ou un tag manager, n'ont pas de version applicable à la page. L'analyseur liste alors la technologie sans version. ### L'analyseur de technologies est-il une alternative à Wappalyzer ? [#lanalyseur-de-technologies-est-il-une-alternative-à-wappalyzer-] Pour la question de sécurité, oui. Wappalyzer et BuiltWith disent quelles technologies un site utilise, sur un large catalogue. L'analyseur de technologies se concentre sur les bibliothèques et frameworks JavaScript et ajoute ce dont une revue de sécurité a besoin : le statut de la version, la fin de vie, les CVE connues avec leur version corrigée, et un export SBOM. ## Articles liés [#articles-liés] * [Comment détecter les bibliothèques JavaScript vulnérables sur un site en production](/fr/blog/detect-vulnerable-javascript-libraries) * [Quelles versions de jQuery sont vulnérables, et comment trouver celle que votre site charge](/fr/blog/vulnerable-jquery-version) * [Construire un inventaire de scripts avec le hash reporting CSP](/fr/blog/script-inventory) * [À quoi sert un détecteur de technologies, des notes de sécurité aux scans PCI](/fr/blog/technology-checker-use-cases) * [Failles Next.js en 2026, la RCE AVIF et la version à installer](/fr/blog/nextjs-vulnerabilities-2026) * [Failles WordPress en 2026, CVE-2026-87902, wp2shell et la version sûre par branche](/fr/blog/wordpress-vulnerabilities-2026) ## Sources [#sources] * [Extensions de navigateur Wappalyzer](https://www.wappalyzer.com/apps/) * [BuiltWith](https://builtwith.com/) * [WhatRuns](https://www.whatruns.com/) * [Retire.js](https://github.com/RetireJS/retire.js) * [Notes de version de Lighthouse v10.0.0](https://github.com/GoogleChrome/lighthouse/releases/tag/v10.0.0) * [Spécification CycloneDX](https://cyclonedx.org/specification/overview/) * [NVD, CVE-2020-11022](https://nvd.nist.gov/vuln/detail/CVE-2020-11022)