Télécharger les sites web qui utilisent Strapi

À propos de Strapi

La première chose à comprendre au sujet de Strapi dans un recensement technologique, c’est que le produit est bâti pour rester invisible. Un système de contenu headless fonctionne comme un backend. Les rédacteurs travaillent dans un panneau d’administration, le contenu sort par une API, et ce qui affiche le site public est une application distincte qui peut être écrite dans n’importe quel framework. Rien n’oblige une interface à annoncer ce qui l’alimente, si bien qu’un recensement fondé sur la détection lit un système headless à travers ses effets de bord plutôt qu’à travers une signature que la plateforme imprimerait sur la page.

En pratique nous identifions Strapi à partir des traces qu’une installation laisse quand elle n’est pas entièrement découplée. Des fichiers médias servis depuis le chemin de téléversement du backend, une route d’API exposée sur un sous-domaine, un panneau d’administration accessible à un emplacement par défaut, un point d’accès de prévisualisation ou d’extension resté ouvert. Chacun de ces éléments constitue une preuve réelle. Aucun n’est garanti d’exister, et une instance déployée avec soin derrière une compilation statique et un CDN peut ne rien laisser du tout. Tout chiffre attaché à un produit headless doit se lire dans cette lumière, et le nôtre est un plancher plutôt qu’une taille de marché.

Une fois la réserve posée clairement, la population reste digne d’intérêt. En octobre 2026 nous voyons Strapi sur 466 sites. Le produit vient de Strapi Solutions, porte la licence Open Source, est écrit en JavaScript et date de 2015, ce qui le range parmi les systèmes apparus au moment où les équipes ont commencé à séparer la publication de la présentation par défaut plutôt qu’à titre d’expérience. Un site qui le fait tourner vous apprend plusieurs choses à la fois. Une équipe de développement ou une agence est dans la boucle, parce qu’une stack headless n’est pas ce qu’un responsable marketing installe un vendredi après-midi. Le modèle de contenu a été conçu plutôt qu’hérité d’un thème. Et l’organisation a choisi un backend de contenu qu’elle peut faire tourner sur ses propres serveurs ou sur le cloud infogéré du fournisseur, ce qui relève autant d’une position d’achat que d’un choix technique.

C’est ce profil qui rend l’export commercialement utile. Les fournisseurs d’hébergement et de plateformes veulent les installations auto-hébergées, parce que l’auto-hébergement est justement l’état qu’une offre de cloud infogéré vient convertir. Les fournisseurs de composants et d’API veulent les interfaces rattachées à ces backends, ce qui n’apparaît qu’en croisant la liste avec les détections de frameworks dans le même fichier. Les agences et les chercheurs en sécurité veulent les sites où un panneau d’administration ou une API se trouve à un chemin par défaut, puisque c’est à la fois un créneau commercial et une trouvaille. Une requête domaine par domaine ne répond à aucune de ces questions, parce que chacune porte sur un ensemble et non sur un domaine.