Un développeur Blazor est presque toujours un développeur .NET qui a pris en charge le front. Les offres demandent C#, ASP.NET Core, Entity Framework Core et SQL Server, puis Blazor Server, Blazor WebAssembly ou les deux, souvent avec bUnit pour les tests. Les applications concernées sont surtout des outils de gestion internes et des portails métiers, avec beaucoup de formulaires et de grilles.
Depuis .NET 8, une même application mélange rendu statique, Blazor Server, WebAssembly et mode Auto, page par page. Un CV qui affiche trois ans de Blazor peut donc recouvrir des réalités très différentes. Demandez dans quel mode tournaient les applications et quels problèmes ce choix a causés : appels en double au prérendu, mémoire du serveur, déconnexions derrière un répartiteur de charge, secrets laissés dans le projet client. Un profil qui a livré en production en parle sans hésiter.
Le niveau en C# se vérifie à part. Un excellent développeur back-end peut ignorer le cycle de vie des composants, et l'inverse existe aussi. Le PDF associé propose 30 questions sur six axes, un cas de 20 minutes et une grille de notation de 1 à 4.
Ce qu'un développeur Blazor manipule au quotidien
Modes de rendu (.NET 8 et suivants)
Une Blazor Web App choisit, composant par composant, entre rendu statique côté serveur, Interactive Server, Interactive WebAssembly et Interactive Auto. Le prérendu est actif par défaut sur les modes interactifs. C'est le premier sujet à aborder : le mode retenu décide de l'architecture, de la charge du serveur et de la façon de gérer l'état.
Blazor Server et circuits SignalR
L'interface s'exécute sur le serveur et chaque utilisateur garde une connexion SignalR ouverte, appelée circuit. Le démarrage est rapide et le code accède directement aux services, mais chaque utilisateur consomme de la mémoire serveur. Derrière un répartiteur de charge, il faut une affinité de session ou Azure SignalR Service.
Blazor WebAssembly
Le runtime .NET et les DLL de l'application sont téléchargés dans le navigateur. L'application peut fonctionner hors ligne et décharge le serveur, mais le premier chargement est plus lourd et tout passe par une API. Rien de ce qui est dans le projet client n'est secret.
Composants Razor et cycle de vie
Les écrans sont faits de composants .razor qui mêlent HTML et C#. OnInitializedAsync, OnParametersSetAsync et OnAfterRenderAsync rythment leur vie, StateHasChanged relance un rendu. Beaucoup de bugs de production viennent d'un appel placé dans la mauvaise méthode.
Gestion d'état
Services scoped utilisés comme conteneurs d'état, valeurs en cascade, URL, stockage du navigateur. Pour le prérendu, PersistentComponentState et, depuis .NET 10, l'attribut [PersistentState] évitent de charger deux fois les mêmes données. Certaines équipes ajoutent Fluxor pour un état centralisé.
Interop JavaScript
Blazor appelle des bibliothèques JavaScript (graphiques, cartes, éditeurs) par IJSRuntime et des modules isolés, et JavaScript rappelle le C# par DotNetObjectReference. L'interop ne fonctionne pas pendant le prérendu et coûte un aller-retour réseau en Blazor Server.
Bibliothèques de composants
MudBlazor, Telerik UI for Blazor, Radzen, Syncfusion ou Fluent UI Blazor fournissent grilles, formulaires et graphiques. Microsoft livre aussi QuickGrid. Les offres citent rarement la bibliothèque, mais la personne doit savoir ce qu'elle coûte à mettre à jour.
Authentification et autorisation
AuthenticationStateProvider, AuthorizeView et [Authorize] côté composants, OpenID Connect avec Entra ID ou un autre fournisseur côté serveur. En WebAssembly, masquer un bouton ne protège rien : l'autorisation se contrôle dans l'API.
Tests avec bUnit et Playwright
bUnit rend un composant en mémoire, remplace ses services et simule l'interop JavaScript. Playwright teste les parcours dans un vrai navigateur. Plusieurs offres Blazor citent bUnit explicitement aux côtés de xUnit.
Le développeur Blazor travaille dans une équipe .NET qui a choisi de garder un seul langage du serveur à l'écran. Il écrit les composants, les services qu'ils appellent et souvent l'API derrière, avec Entity Framework Core et SQL Server ou Oracle. Les missions consistent à créer une application, à faire évoluer une application Blazor Server existante, ou à remplacer des écrans Web Forms ou WPF. Aucune certification Microsoft ne porte spécifiquement sur Blazor. Le niveau se juge sur les choix de rendu, la gestion de l'état et la tenue en production.
Les points techniques à valider chez un développeur Blazor
- Choix du mode de rendu
- Cycle de vie et rendu des composants
- Gestion d'état et prérendu
- Interop JavaScript
- Authentification et sécurité côté client
- Performance et tests bUnit
Cinq questions tirées de vrais problèmes Blazor
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
L'application est une Blazor Web App en mode Auto. Des utilisateurs disent qu'un formulaire ne réagit pas aux clics pendant les premières secondes. Que se passe-t-il ?
Une bonne réponseLa page est prérendue : le serveur envoie d'abord du HTML statique, puis le composant devient interactif quand le circuit SignalR est ouvert ou que le runtime WebAssembly est téléchargé. Entre les deux, les clics ne font rien. Correctifs possibles : désactiver les boutons tant que le composant n'est pas interactif, alléger le téléchargement WebAssembly, précharger les ressources avec ResourcePreloader depuis .NET 10, ou couper le prérendu sur ce formulaire.
Signal d'alerte« C'est le réseau » ou « il faut vider le cache », sans jamais parler de prérendu. Ou supprimer le prérendu de toute l'application sans mesurer ce que l'on perd au premier affichage.
Question 2 · confirmé
Chaque affichage d'une page déclenche deux appels identiques à l'API dans les logs. Pourquoi, et comment corrigez-vous ?
Une bonne réponseAvec le prérendu, OnInitializedAsync s'exécute une première fois sur le serveur pour produire le HTML, puis une seconde fois quand le composant devient interactif. La correction consiste à transmettre l'état du prérendu au rendu interactif avec PersistentComponentState, ou avec l'attribut [PersistentState] en .NET 10. Couper le prérendu sur ce composant ou mettre la réponse en cache sont des solutions acceptables si la personne explique ce qu'elles coûtent.
Signal d'alerteUn booléen dans le composant pour « ne charger qu'une fois », qui ne marche pas puisque ce sont deux instances différentes. Ou déplacer l'appel dans OnAfterRenderAsync sans voir que la page s'affiche d'abord vide.
Question 3 · senior
En Blazor Server, la mémoire du serveur monte avec le nombre d'utilisateurs connectés. Que regardez-vous ?
Une bonne réponseChaque utilisateur a un circuit qui garde en mémoire serveur l'état de ses composants et ses services scoped. On cherche les grosses listes gardées dans les composants, les abonnements à des événements jamais retirés, les composants qui ne libèrent rien dans Dispose. Un circuit déconnecté reste aussi gardé un temps (trois minutes et cent circuits au plus par défaut, réglables dans CircuitOptions). La personne cite un outil de mesure, par exemple dotnet-counters ou un dump mémoire.
Signal d'alerte« On ajoute de la RAM » ou « on passe en WebAssembly » sans chercher la cause. Aucune idée de ce qu'est un circuit.
Question 4 · confirmé
Vous devez intégrer une bibliothèque JavaScript de graphiques dans un composant. Comment faites-vous, et à quel moment du cycle de vie l'appelez-vous ?
Une bonne réponseUn module JavaScript isolé, importé avec IJSRuntime.InvokeAsync<IJSObjectReference>("import", ...), puis appelé dans OnAfterRenderAsync quand firstRender vaut true, parce que l'élément existe alors dans le DOM et que l'interop n'est pas disponible pendant le prérendu. L'élément est passé avec un ElementReference. Le composant implémente IAsyncDisposable pour libérer le module, et en Blazor Server il intercepte JSDisconnectedException quand le circuit est déjà fermé.
Signal d'alerteUn appel JavaScript dans OnInitializedAsync, qui échoue au prérendu. Une balise script dans le composant, ou un objet global window jamais nettoyé.
Question 5 · junior à confirmé
Dans une application Blazor WebAssembly, le bouton Supprimer est masqué aux utilisateurs qui n'ont pas le rôle admin. Est-ce suffisant ?
Une bonne réponseNon. Le code WebAssembly tourne dans le navigateur et ses DLL se téléchargent : l'utilisateur peut appeler l'API directement. AuthorizeView sert seulement à l'affichage. Le contrôle se fait dans l'API, avec [Authorize] et une policy sur le rôle. La personne ajoute qu'aucun secret ne doit se trouver dans le projet client, ni chaîne de connexion ni clé d'API.
Signal d'alerte« Oui, le bouton n'apparaît pas. » Ou une clé d'API rangée dans le appsettings.json du projet client.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recruter un développeur Blazor : vos questions
Un développeur .NET back-end peut-il devenir développeur Blazor rapidement ?
Il garde son C#, son injection de dépendances et son Entity Framework Core, ce qui fait gagner beaucoup de temps. Ce qui lui manque en général : le cycle de vie des composants, le prérendu, l'interop JavaScript et les bases du web côté navigateur (CSS, accessibilité, outils de développement). Vérifiez en entretien qu'il a déjà livré au moins un écran interactif, pas seulement lu la documentation.
Quelle différence avec un développeur front-end React ou Angular ?
Le développeur front-end JavaScript maîtrise TypeScript, l'outillage npm et un écosystème de composants beaucoup plus large. Le développeur Blazor reste dans .NET et partage le code et les modèles avec le back-end. Pour une application de gestion portée par une équipe .NET, Blazor évite de recruter deux profils. Pour un site public très travaillé visuellement, un développeur front-end JavaScript reste en général mieux armé.
Quel test technique proposer à un développeur Blazor ?
Un exercice court en entretien fonctionne mieux qu'un projet à rendre. Donnez un composant qui charge ses données deux fois, ou une liste lente à filtrer, et demandez à la personne de corriger en expliquant à voix haute. En une demi-heure, vous voyez si elle connaît le cycle de vie, le prérendu et les outils de diagnostic. Complétez par une question sur le mode de rendu de ses applications passées et sur les raisons de ce choix.
Faut-il exiger Blazor Server ou Blazor WebAssembly sur le CV ?
Exigez celui que votre application utilise, ou les deux si elle est en mode Auto. Les problèmes ne sont pas les mêmes : mémoire et connexions côté serveur d'un côté, taille du téléchargement et sécurité de l'API de l'autre. Un profil qui n'a connu que Blazor Server s'adapte à WebAssembly, à condition de comprendre que tout le code client est visible. Posez la question sur votre mode à vous.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
