Le poste existe dès qu'un produit affiche de la 3D dans le navigateur. Le développeur monte la scène avec Three.js, souvent dans une application React via React Three Fiber, écrit des shaders en GLSL, prépare les modèles glTF avec le graphiste et tient un budget de performance sur des appareils qu'il ne contrôle pas. Les offres changent de nom : développeur WebGL, front 3D, Three.js, ou poste full-stack avec Three.js parmi les outils.
Three.js apparaît sur beaucoup de CV après un tutoriel ou un projet personnel. Un profil qui a livré en production parle de draw calls, de textures KTX2, de dispose() et de perte de contexte WebGL. Il distingue une limite CPU d'une limite GPU et teste sur un vrai téléphone. Un profil venu du jeu vidéo connaît le rendu temps réel ; reste à voir s'il tient les contraintes du web, poids des fichiers et mémoire du navigateur en tête.
Préférez un problème réel aux définitions. Montrez une scène qui rame ou un modèle trop lourd et demandez ce que la personne mesurerait en premier. Parlez aussi de WebGPURenderer, qui repasse sur WebGL 2 quand WebGPU manque et dont les shaders s'écrivent en TSL. Le PDF ajoute un cas de 20 minutes sur un configurateur 3D.
Three.js, WebGPU, glTF : les outils du développeur 3D web
Three.js
La bibliothèque JavaScript la plus utilisée pour la 3D dans le navigateur. Elle fournit la scène, les caméras, les lumières, les matériaux et le renderer. Une nouvelle version sort environ chaque mois (numérotée r18x en 2026) et le code déprécié disparaît une dizaine de versions plus tard : demandez comment la personne gère les montées de version.
WebGL 2 et WebGPU
Les deux API graphiques du navigateur. WebGL 2 fonctionne partout. WebGPU, plus récent, est actif par défaut dans Chrome et Edge et arrive dans Safari, Firefox suit plus lentement. Dans Three.js, WebGPURenderer utilise WebGPU quand il est disponible et repasse sur WebGL 2 sinon.
Shaders GLSL et TSL
Les petits programmes exécutés par la carte graphique : le vertex shader place les sommets, le fragment shader calcule la couleur de chaque pixel. Avec WebGLRenderer, ils s'écrivent en GLSL. TSL, le langage de shaders de Three.js écrit en JavaScript, sert pour WebGPURenderer et compile vers WGSL ou GLSL.
React Three Fiber et drei
React Three Fiber décrit une scène Three.js sous forme de composants React ; sa version 9 accompagne React 19. drei apporte des composants prêts à l'emploi (contrôles de caméra, chargement de modèles, environnements). Un profil qui ne connaît que R3F doit quand même comprendre le Three.js qui tourne dessous.
glTF, Draco, meshopt et KTX2
glTF est le format standard des modèles 3D pour le web, en .gltf ou .glb. Draco et meshopt compressent la géométrie, KTX2 compresse les textures pour qu'elles restent compactes dans la mémoire de la carte graphique. Les outils gltf-transform et gltfpack préparent les fichiers avant la mise en ligne.
Mathématiques 3D
Vecteurs, matrices, quaternions, changements de repère. Elles servent tous les jours : placer la caméra, cliquer sur un objet, animer une rotation, écrire un shader. Pas besoin d'un niveau de chercheur, mais la personne doit savoir ce que fait une matrice de projection.
Outils de mesure
renderer.info donne le nombre de draw calls, de triangles et de textures en mémoire. Spector.js capture une image et montre chaque appel envoyé au GPU. Le profil de performance de Chrome montre le temps passé en JavaScript et le ramasse-miettes. Un développeur 3D qui ne mesure jamais optimise au hasard.
Babylon.js et Cesium
Deux alternatives que l'on croise dans les offres : Babylon.js, moteur 3D web plus complet que Three.js, et CesiumJS pour la cartographie 3D et les globes. Les notions de scène, de shaders et de performance GPU se transfèrent d'un outil à l'autre.
Le développeur Three.js travaille le plus souvent dans une équipe front, à côté d'un ou plusieurs graphistes 3D qui produisent les modèles sous Blender ou à partir de fichiers CAO. Selon le poste, il intègre la 3D dans une application React ou Vue existante, ou construit une expérience autonome très animée. Certaines offres demandent Babylon.js ou CesiumJS plutôt que Three.js : la scène, les shaders et la performance GPU restent les mêmes sujets. Un profil issu du jeu vidéo apporte le rendu temps réel, un profil front apporte l'intégration et l'outillage web. L'entretien vérifie ce qui manque à chacun.
Les savoir-faire 3D à contrôler pendant l'entretien
- Scène Three.js, rendu et gestion des ressources
- Shaders GLSL, TSL et WebGPU
- Performance GPU et draw calls
- Préparation et chargement des assets glTF
- Mathématiques 3D et interactions
- Intégration React Three Fiber et qualité
Scène lente, shader, modèle trop lourd : cinq questions techniques
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é
Une scène tourne à 60 images par seconde sur votre portable et à 20 sur un téléphone de milieu de gamme. Comment cherchez-vous la cause ?
Une bonne réponseIl mesure avant de corriger : renderer.info pour le nombre de draw calls, de triangles et de textures, Spector.js pour capturer une image, le profil de performance de Chrome pour le temps passé en JavaScript. Il cherche si la limite vient du CPU (trop d'objets, calcul des matrices) ou du GPU (résolution, fragment shader, ombres, post-traitement). Les corrections classiques suivent : plafonner le pixel ratio à 2, voire 1,5, regrouper les objets avec InstancedMesh ou BatchedMesh, réduire la taille des shadow maps et des textures. Il teste sur l'appareil réel.
Signal d'alerte« On baisse le nombre de polygones » sans avoir rien mesuré. Ignorer qu'un téléphone a souvent un devicePixelRatio de 3, donc neuf fois plus de pixels à calculer qu'à 1.
Question 2 · confirmé
Vous devez faire onduler une surface d'eau au fil du temps. Que faites-vous dans le vertex shader, et que laissez-vous au fragment shader ?
Une bonne réponseLe déplacement des sommets se fait dans le vertex shader, avec un uniform pour le temps et un maillage assez subdivisé. Il recalcule les normales, par dérivée de la fonction d'onde ou dans le fragment shader, sinon l'éclairage reste celui d'un plan. Couleur, reflets et effet Fresnel vont dans le fragment shader, qui tourne une fois par pixel et coûte donc plus cher. En Three.js, il cite ShaderMaterial, onBeforeCompile pour garder l'éclairage PBR, ou un positionNode en TSL.
Signal d'alerteModifier en JavaScript les positions du BufferGeometry à chaque image pour 100 000 sommets. Oublier les normales et ne pas comprendre pourquoi la lumière ne bouge pas.
Question 3 · confirmé
Un modèle glTF livré par le graphiste pèse 80 Mo. Comment le rendez-vous chargeable sur le web ?
Une bonne réponseIl inspecte d'abord le fichier (gltf-transform inspect) pour savoir ce qui pèse : géométrie ou textures. Ensuite : compression de la géométrie avec Draco ou meshopt, textures converties en KTX2 (Basis Universal), qui restent compressées dans la mémoire GPU, résolutions réduites, nœuds et animations inutiles supprimés, objets répétés instanciés, version simplifiée pour les vues lointaines. Côté Three.js, DRACOLoader, KTX2Loader et MeshoptDecoder. Il raisonne en poids téléchargé et en mémoire vidéo.
Signal d'alerte« On active la compression gzip du serveur » comme seule réponse, ou ne parler que du temps de téléchargement sans penser à la mémoire GPU.
Question 4 · confirmé
Les utilisateurs passent d'une scène 3D à l'autre sans recharger la page, et la mémoire grimpe à chaque changement. D'où vient la fuite ?
Une bonne réponseThree.js ne libère pas seul les ressources GPU : retirer un objet de la scène ne suffit pas. Il faut appeler dispose() sur les géométries, matériaux, textures et render targets, et suivre renderer.info.memory pour le vérifier. Autres causes : une boucle de rendu jamais arrêtée, des écouteurs d'événements et des contrôles non détruits, un renderer recréé à chaque fois sans renderer.dispose(), ce qui finit par dépasser le nombre de contextes WebGL autorisés par le navigateur.
Signal d'alerte« Le ramasse-miettes s'en occupe. » Aucune notion de dispose().
Question 5 · confirmé
Un objet tourne mal quand on combine trois rotations, puis se bloque sur un axe. Que se passe-t-il, et comment corrigez-vous ?
Une bonne réponseUn blocage de cardan (gimbal lock), propre aux angles d'Euler : deux axes finissent alignés et un degré de liberté disparaît. Il explique que l'ordre des rotations compte (la propriété order, 'XYZ' par défaut), passe aux quaternions pour composer et interpoler les orientations (slerp), et distingue rotation locale et rotation dans le repère du monde (rotateOnAxis, rotateOnWorldAxis). Pour un pivot décalé, il place l'objet dans un groupe parent.
Signal d'alerteAjuster les angles au hasard jusqu'à ce que le résultat semble correct, sans savoir que l'ordre des rotations change le résultat.
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 WebGL : les réponses courtes
Un développeur Babylon.js ou Unity peut-il reprendre un projet Three.js ?
Babylon.js vers Three.js, oui sans grande difficulté : les deux reposent sur WebGL et WebGPU, avec les mêmes notions de scène, de matériaux et de shaders. Three.js est plus bas niveau et demande davantage de code autour. Un profil Unity connaît le rendu temps réel mais travaille en C# dans un éditeur. Vérifiez sa pratique de JavaScript ou TypeScript, du poids des fichiers et de la mémoire du navigateur, qu'Unity gère à sa place.
Quel niveau de mathématiques exiger ?
Celui qui sert au quotidien : vecteurs, produits scalaire et vectoriel, matrices de transformation, quaternions, changements de repère. La personne doit expliquer pourquoi un objet tourne autour du mauvais point ou pourquoi un clic ne touche pas le bon objet. Pour des shaders avancés (bruit procédural, éclairage personnalisé), ajoutez l'interpolation et un peu de géométrie. Un niveau de recherche n'est pas nécessaire.
Quelle forme donner au test technique d'un développeur WebGL ?
Une scène fournie qui rame ou qui fuit en mémoire, à diagnostiquer pendant une heure en partageant l'écran. La personne ouvre les outils de mesure, formule une hypothèse et corrige. Un petit shader à écrire ou à modifier complète l'exercice pour un poste orienté rendu. Évitez de demander une démo complète à faire chez soi : elle mesure surtout le temps libre du candidat.
WebGPU est-il déjà un critère de recrutement ?
Pas comme condition d'entrée. WebGL 2 reste le socle qui fonctionne partout, et WebGPURenderer repasse sur WebGL 2 quand WebGPU manque. Pour un poste centré sur le rendu ou le calcul GPU (particules, simulations), la connaissance de TSL et des compute shaders devient un vrai plus. Demandez au minimum ce qui change pour les shaders existants quand on passe à WebGPURenderer.
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.
