Télécharger les sites web qui utilisent Blazor

À propos de Blazor

La plupart des frameworks de navigateur vous disent ce qu’une équipe de développement a préféré. Blazor vous dit ce qu’une organisation possédait déjà.

Microsoft a livré Blazor en 2018 et l’a publié sous licence MIT. L’argument de vente était ciblé et efficace : écrire ses composants d’interface en C#, le langage dans lequel le backend est déjà écrit, et se passer entièrement de la chaîne d’outils JavaScript. Deux moteurs d’exécution très différents tiennent cette promesse. Le premier compile un moteur d’exécution .NET vers WebAssembly et exécute le code des composants dans le navigateur. Le second garde les composants sur le serveur et pousse les mises à jour d’interface dans une connexion persistante, ne laissant au client guère plus qu’une surface de rendu. Vus de l’extérieur, les deux se ressemblent assez pour qu’un robot d’exploration ne puisse pas toujours les séparer, et nos fiches ne s’y essaient pas.

Ce qui doit intéresser un chercheur n’est pas le framework lui-même. Derrière presque chaque page Blazor se trouvent une application ASP.NET Core, une équipe C#, un abonnement Visual Studio et Azure, et souvent SQL Server en dessous. Personne n’adopte Blazor par effet de mode. L’adoption suit un engagement déjà pris envers la plateforme Microsoft, ce qui explique que le framework se concentre dans les portails d’entreprise, les tableaux de bord de la logistique et de l’assurance, les fournisseurs industriels, les back-offices de la santé et les sites de produits interentreprises plutôt que dans l’édition ou la vente au détail grand public.

En octobre 2026 nous détectons Blazor sur 4 106 sites. Le chiffre est honnête sur ce qu’un robot d’exploration peut atteindre et muet sur l’endroit où le framework réside vraiment. Les applications hébergées côté serveur se tiennent derrière une authentification, sur des sous-domaines applicatifs et à l’intérieur d’intranets qu’aucune exploration publique ne touche jamais, alors que la page d’accueil marketing de la même entreprise est souvent un gabarit statique sans la moindre trace de .NET dessus. Le décompte se lit au mieux comme un plancher visible plutôt que comme une population.

Une requête domaine par domaine indique si une entreprise a choisi Blazor. Une liste répond à des questions qu’une requête ne peut pas atteindre : jusqu’où la stack web Microsoft s’est diffusée au-delà des comptes qu’un fournisseur vend déjà, dans quels secteurs elle s’est installée, comment la population Blazor recoupe les sites ASP.NET plus anciens qui sont candidats à une réécriture, et si l’empreinte croît sur les marchés où vous prévoyez de recruter ou de vendre. Les éditeurs de composants, les entreprises d’observabilité et de suivi des erreurs, les sociétés de développement sous contrat et les recruteurs techniques achètent tous la même liste de domaines et y lisent des choses différentes.

Dans le dataset, chaque domaine Blazor arrive avec le reste de la stack détectée sur le même hôte, de sorte que le framework peut être croisé en une seule passe avec les signaux de serveur web, de CDN, d’analytique, de paiement et de gestionnaire de balises. Un seul site qui fait tourner le framework est rarement intéressant en soi. La population, réduite aux hôtes qui font aussi tourner le produit d’un concurrent, forme une liste de prospects exploitable, et le même fichier relu un trimestre plus tard montre dans quelle direction l’empreinte se déplace.