Effets Shader avec l'IA : Comment j'ai créé de la magie 3JS en 4 minutes

Effets Shader avec l'IA : Comment j'ai créé de la magie 3JS en 4 minutes

Six heures. C'est le temps que j'ai passé à fixer du code GLSL la première fois que j'ai essayé d'ajouter un effet de distortion au survol sur la page galerie d'un client.

Pas six heures à construire toute la page. Six heures sur une seule animation de survol qui durait exactement 0,4 seconde quand la souris de l'utilisateur passait sur une image.

Le vertex shader allait bien. Le fragment shader fonctionnait isolément. Mais passer correctement les variables uniform ? Normaliser les coordonnées de la souris ? Gérer le redimensionnement du canvas sur différentes tailles de viewport ? Je me heurtais sans cesse à des murs dont j'ignorais l'existence — et chaque réponse sur Stack Overflow était soit vieille de trois ans, soit basée sur une version complètement différente de Three.js, soit partait du principe que je savais déjà des choses que je ne maîtrisais clairement pas.

J'ai livré la page sans l'effet shader. Juste une banale transition CSS d'opacité. Le client n'a rien remarqué. Mais moi oui — parce que j'avais passé six heures à échouer sur quelque chose que j'avais vu des développeurs créatifs juniors exécuter sans effort sur des sites primés, et l'écart entre ce que je pouvais imaginer et ce que je pouvais construire me touchait personnellement.

C'était il y a environ 14 mois.

La semaine dernière, j'ai appliqué cinq effets shader de survol différents — wobble, wave, aberration chromatique, distortion et un split RGB — sur une page galerie complète et j'ai livré le tout en moins de 45 minutes. Un seul effet, de zéro à l'aperçu fonctionnel ? Quatre minutes.

La différence, ce n'est pas que j'ai enfin maîtrisé le GLSL. Je suis toujours incapable d'écrire un shader de displacement de zéro sans ouvrir la documentation. La différence, c'est que j'ai construit un skill Claude Code qui le fait pour moi — et surtout, qui le fait correctement, avec un nettoyage propre, la gestion du viewport et la couverture des cas limites réels.

Cet écart que je viens de créer — « comment ça marche exactement ? » — c'est ce qu'on va combler ici. Mais d'abord, tu dois comprendre pourquoi le conseil « apprends les shaders correctement » est le mauvais conseil pour la plupart des développeurs front-end.

Pourquoi les shaders restent hors de portée (et pourquoi ce n'est pas ta faute)

Voilà le truc avec les shaders dans le développement front-end : l'écart de connaissances, ce n'est pas une courbe d'apprentissage. C'est une paroi rocheuse.

L'animation CSS ? Tu apprends en pratiquant — tu casses des trucs, tu les répares, tu les livres. Grid et flex ? Un après-midi concentré débloque l'essentiel de ce dont tu as besoin. Même les patterns JavaScript complexes comme le debouncing, le scroll virtuel ou la gestion d'état avancée — tu peux les faire fonctionner avec de la patience et une bonne documentation.

Les shaders sont différents d'une manière que la plupart des tutoriels n'admettront pas.

GLSL (OpenGL Shading Language) est un langage proche du C qui tourne directement sur le GPU, traitant les sommets et les fragments en parallèle avec une tolérance quasi nulle pour la compréhension floue du « à peu près suffisant » avec laquelle tu peux t'en sortir en JavaScript. Tu ne peux pas faire de console.log à l'intérieur d'un shader. Le débogage, c'est de la devinette visuelle — tu changes une variable, tu recompiles, tu plisses les yeux sur le résultat, tu recommences. Three.js ajoute une couche d'abstraction qui rend parfois l'intégration des shaders plus difficile à comprendre, pas plus facile.

Le vrai parcours d'apprentissage pour écrire des shaders personnalisés prêts pour la production à partir de zéro ressemble à peu près à ça :

1. Comprendre correctement l'algèbre linéaire — matrices, produits scalaires, coordonnées homogènes
2. Apprendre comment fonctionne le pipeline de rendu WebGL au niveau du GPU
3. Maîtriser la syntaxe GLSL et les contraintes des programmes de shaders (pas de boucles dynamiques, pas de récursion, typage strict)
4. Comprendre le ShaderMaterial de Three.js et comment les uniforms, attributes et varyings circulent à travers
5. Résoudre la normalisation des coordonnées souris, les maths en espace viewport et la gestion de l'uniform temporel
6. Déboguer les résultats en changeant une variable à la fois jusqu'à ce que quelque chose ressemble davantage à ce que tu voulais

Ce n'est pas un week-end. C'est des mois d'étude concentrée si tu pars de zéro. Et voici ce que la plupart des tutoriels ne diront pas directement : la majorité de ces connaissances ne se transfèrent pas proprement au reste de ton travail. C'est de la spécialisation profonde — précieuse si tu construis une agence créative ou si tu fais de l'art génératif à temps plein. Pour tous les autres qui travaillent sur un full stack, livrent des produits et gèrent des relations clients, le retour sur investissement en temps est franchement discutable.

La vraie douleur, ce n'est pas que les shaders soient difficiles. C'est que les shaders sont difficiles par rapport à la fréquence à laquelle tu en as besoin.

Mais — et c'est la partie qui compte — ils rendent incroyablement bien. Un effet d'aberration chromatique bien exécuté au survol sur une galerie peut faire la différence entre un site qui donne l'impression d'un produit premium et un qui fait template. Le delta visuel est énorme. La complexité d'implémentation aussi.

Et si tu pouvais obtenir le delta visuel sans la complexité ?

Ce qu'est réellement un skill Claude Code

Avant d'entrer dans l'implémentation du shader, je dois t'expliquer ce que signifie un « skill » dans Claude Code en pratique — parce que ce n'est pas ce que la plupart des gens imaginent quand ils entendent « génération de code par IA ».

Quand les développeurs imaginent l'IA qui écrit du code, ils visualisent un chatbot qui génère quelque chose que tu copies-colles dans ton projet et que tu passes ensuite une heure à adapter manuellement. Ce modèle fonctionne pour le boilerplate. Il échoue pour les tâches complexes et contextuelles comme l'intégration de shaders, où la sortie correcte dépend fortement de la structure de ton projet.

Un skill Claude Code, c'est différent. Vois-le comme un jeu d'instructions versionné et réutilisable qui :

• Dispose d'un contexte persistant — il sait quelles structures de projet il attend, quelles options sont disponibles et comment les générations précédentes ont échoué
• Lit d'abord ta base de code — avant d'écrire une seule ligne, un skill bien construit scanne ton projet pour comprendre ce qui existe, quels patterns sont utilisés et ce qui doit changer
• Applique les modifications chirurgicalement — il ne modifie que ce qui doit l'être, en s'intégrant à tes patterns existants plutôt qu'en les écrasant
• Accepte des paramètres configurables — type de shader, intensité, style d'animation sont passés comme des options structurées plutôt que des descriptions en prose

Le skill de shader que j'ai construit — appelons-le apply-shader-hover — fonctionne exactement comme ça. Quand il est invoqué sur un projet, il :

• Scanne le fichier HTML que je spécifie pour trouver les éléments image à l'intérieur de conteneurs de type galerie
• Identifie si le projet utilise du JavaScript vanilla, un bundler comme Vite, ou un framework
• Génère la configuration Three.js appropriée (initialisation du canvas, renderer WebGL, scène, caméra)
• Écrit le code source GLSL spécifique pour l'effet sélectionné
• Injecte les écouteurs d'événements souris avec une normalisation correcte des coordonnées
• Ajoute un ResizeObserver pour maintenir les dimensions du canvas correctement
• Câble le tout avec un pattern d'initialisation qui ne fuit pas en mémoire

Ce dernier point est plus important qu'il n'en a l'air. Le code WebGL généré par l'IA échoue fréquemment à libérer proprement les ressources du renderer, à retirer les écouteurs d'événements ou à gérer le démontage des composants. Mon skill a appris ces modes de défaillance par des tests itératifs en conditions réelles et les traite explicitement.

Mais les options de shader elles-mêmes sont là où ça devient intéressant. Voici ce qui distingue réellement chacune — pas seulement visuellement, mais au niveau du code.

Les quatre effets shader : ce qui se passe réellement sous le capot

Distortion — La déformation fluide

Le shader de distortion déforme la géométrie de l'image autour de la position de la souris, créant un effet de bulle qui donne l'impression que l'image repousse ton curseur.

Le mécanisme principal est une fonction de déplacement dans le fragment shader qui échantillonne la texture à une coordonnée UV légèrement décalée — le décalage étant calculé en fonction de la distance par rapport à la position normalisée de la souris. En intensité « medium », le décalage maximum est d'environ 0,08 unités UV. En « strong », on parle de 0,15+, ce qui commence à donner un rendu presque liquide.

Les uniforms clés qui pilotent l'effet :

• u_mouse — position normalisée 0.0–1.0 de la souris dans l'espace écran
• u_time — temps écoulé pour une animation fluide d'entrée/sortie au survol
• u_intensity — multiplicateur scalaire auquel l'option CLI correspond (0,04 pour subtil, 0,08 medium, 0,15 strong)

Celui-ci fonctionne magnifiquement sur les galeries à thème sombre avec de la photographie à fort contraste. Sur des mises en page plus claires et plus corporate, il peut sembler trop appuyé — le paramètre de style d'animation aide à l'ajuster, mais l'effet sous-jacent a une forte personnalité.

Wave — L'ondulation élégante

Wave est plus subtil que distortion et fonctionne mieux quand tu veux que le survol donne une impression de sophistication plutôt que de drame. Au lieu de déformer autour du curseur, il crée un motif d'ondulation qui irradie depuis le point d'interaction.

Le détail d'ingénierie intéressant ici, c'est le paramètre de style d'animation. « Snappy » utilise une courbe de décroissance exponentielle — l'effet atteint sa pleine intensité presque immédiatement et retombe vite, comme si on pressait du verre. « Languid » utilise une courbe plus lente avec un léger dépassement, de sorte que la vague continue juste au-delà de l'événement déclencheur avant de se stabiliser, comme de l'eau. « Smooth » utilise une simple interpolation cosinusoïdale entre les états.

Ça ressemble à des détails d'implémentation jusqu'à ce que tu les voies côte à côte. La variante snappy donne un rendu numérique et précis. La variante languid donne un rendu organique et physique. Pour un portfolio photographique, ce choix façonne l'expérience entière.

Aberration chromatique — Celui qui provoque des réactions

C'est systématiquement l'effet qui arrête les gens en plein défilement. L'aberration chromatique simule le frangeage de couleurs d'un objectif qui ne focalise pas toutes les longueurs d'onde au même point focal — une légère séparation des canaux rouge, vert et bleu, surtout vers les bords.

Dans le fragment shader, tu échantillonnes la texture trois fois :

• Canal rouge : texture2D(u_texture, uv + offset)
• Canal vert : texture2D(u_texture, uv) — pas de décalage, c'est l'ancre
• Canal bleu : texture2D(u_texture, uv - offset)

La direction du décalage est dynamique — elle suit le vecteur de mouvement de la souris, de sorte que l'aberration « traîne » quand tu te déplaces sur l'image, ce qui donne l'impression d'un comportement de lentille physiquement réaliste.

En intensité « strong » avec une animation « snappy » sur une galerie sombre avec de la photographie à fort contraste, cet effet est presque agressif — dans le bon sens. Un de mes clients a reçu une demande non sollicitée d'un prospect qui mentionnait spécifiquement « les effets d'image trop cool » sur son site. Ça venait de ce shader. Sur une mise en page plus claire et conservatrice, les mêmes réglages auraient fait surchargé. Le jugement de design, c'est le tien. L'implémentation, c'est celle du skill.

Wobble — Celui qui vit dans le vertex shader

Wobble est le plus ludique des quatre, et techniquement le plus distinct — il opère dans le vertex shader plutôt que dans le fragment shader. Au lieu de manipuler la façon dont les pixels sont colorés, il manipule la géométrie elle-même.

Une distortion sinusoïdale se propage à travers le plan de l'image depuis le point d'entrée de la souris et s'amortit en environ 0,8 seconde, créant une oscillation semblable à de la gelée. Le résultat visuel, c'est comme si tu appuyais sur une image en caoutchouc tendue sur un cadre rigide. Génial pour les cartes produit, les images d'avatar, tout ce qui a besoin de physicalité dans une interface autrement plate.

Celui-ci nécessite la configuration la plus minutieuse — si le canvas Three.js n'est pas configuré avec une gestion correcte du pixelRatio, le wobble apparaît dentelé sur les écrans retina. Le skill gère ça explicitement. Si tu adaptes le code de sortie manuellement plutôt que d'utiliser le skill tel quel, c'est le premier endroit à vérifier quand le résultat a l'air bizarre.

Construire le skill : le vrai processus, pas la version démo

Je veux être honnête sur un point : ce skill n'est pas arrivé tout formé d'une seule session de prompts. Il a fallu 8 à 10 itérations pour atteindre le niveau de qualité où je le déploierais sur un projet client sans revoir chaque ligne.

La première version était d'une naïveté embarrassante. J'ai demandé à Claude Code de « créer un skill qui applique des effets de shader Three.js au survol sur les images de galerie ». Ce qui est revenu était du code syntaxiquement correct qui ne tournait pas — parce qu'il supposait qu'un bundler de modules était disponible alors que le projet cible utilisait du JavaScript vanilla avec des balises script.

L'itération 2 a corrigé la détection d'environnement mais plantait quand les éléments image étaient imbriqués dans des structures de wrapper de galerie complexes plutôt que d'être des enfants directs.

L'itération 3 gérait l'imbrication mais loupait les images implémentées en CSS background-image plutôt qu'en éléments <img> — ce qu'une portion significative des implémentations de galerie utilise pour des raisons de contrôle du ratio d'aspect.

Chaque échec est devenu une partie de la base de connaissances du skill. J'ai ajouté des exemples documentés de chaque pattern : « voici une galerie qui utilise des background images, voici ce que le skill devrait faire différemment. » Le skill a accumulé des connaissances contextuelles à partir d'échecs réels plutôt que d'hypothèses théoriques.

Le point d'inflexion a été quand j'ai commencé à ajouter ce que j'appelle la « documentation des modes de défaillance » — pas seulement décrire ce que le skill doit faire quand tout fonctionne, mais documenter explicitement ce qu'il doit faire quand les choses tournent mal. Que se passe-t-il si Three.js n'est pas disponible sur la page ? Que se passe-t-il si le sélecteur cible ne trouve aucun élément ? Et si le navigateur ne supporte pas WebGL ?

Un skill qui gère les échecs gracieusement est infiniment plus fiable sur de vrais projets qu'un qui ne fonctionne que dans des conditions de démo propres. C'est un principe à garder en tête quand tu construiras les tiens.

Le workflow concret : de l'invocation à l'aperçu

Voici exactement à quoi ressemble le workflow actuel — la version de production, pas une démo simplifiée.

Étape 1 : Invoquer depuis l'intérieur du projet

Depuis le répertoire du projet dans Claude Code :

/apply-shader-hover

Le skill pose immédiatement deux questions :

1. Quel fichier contient la galerie ? (Je fournis le chemin)
2. Quel effet shader ? (distortion / wave / chromatic / wobble)

Étape 2 : Configurer les paramètres

Après avoir choisi le type de shader, le skill présente les options pertinentes. Pour l'aberration chromatique :

Intensity: subtle | medium | strong
Animation style: smooth | snappy | languid
Apply to: all gallery images | specific selector

Je sélectionne « strong » + « snappy » + « all gallery images. » L'interaction entière — y compris ma saisie — prend environ 20 secondes.

Étape 3 : Lecture du contexte de la base de code

Avant de générer le moindre code, le skill lit :

• Le fichier HTML cible (structure des images, includes JavaScript existants)
• Le CSS du projet (contexte de dimensionnement et positionnement des éléments)
• Toute utilisation existante de Three.js (pour éviter une initialisation dupliquée du renderer)

Cette passe de contexte est ce qui fait que la sortie s'intègre plutôt que de simplement coexister avec le projet.

Étape 4 : Génération et injection

Le skill génère :

• L'initialisation Three.js (renderer, scène, caméra, élément canvas avec le pixelRatio correct)
• Les chaînes source GLSL pour les vertex et fragment shaders
• La gestion des uniforms et la boucle de mise à jour
• Les écouteurs d'événements souris avec normalisation des coordonnées en espace viewport
• L'intégration du ResizeObserver
• Le nettoyage/libération au déchargement de la page

La sortie atterrit dans un nouveau fichier shader-hover.js (ou équivalent), avec une seule balise script ajoutée au HTML. Pas éparpillée dans les fichiers existants.

Étape 5 : Revue

La génération elle-même prend 2 à 3 minutes. La revue et les ajustements éventuels prennent encore 5 à 10. Je vérifie : le ciblage correct des sélecteurs, le z-index et le positionnement du canvas, tout cas limite spécifique au projet que le skill aurait manqué. Les corrections à ce stade sont presque toujours mineures.

Voilà le workflow. Le code en dessous est véritablement complexe. La couche d'interaction ne l'est pas. Et cette asymétrie — une interface simple par-dessus une implémentation complexe — c'est exactement ce qu'un skill bien construit doit fournir.

L'avis honnête : ce que ça change vraiment (et ce que ça ne change pas)

La plupart des contenus sur les outils IA que j'ai vus passent sous silence les cas d'échec et montrent des démos qui fonctionnent parfaitement une fois, dans des conditions idéales, puis déclarent que le futur est arrivé. Ce cadrage est inutile.

Voici ce qui a réellement changé dans mon travail.

Ce qui s'est véritablement amélioré :

Le plus grand changement, ce ne sont pas les gains de temps — c'est l'accès. L'effet d'aberration chromatique que j'ai décrit ? Je ne l'aurais jamais proposé à un client avant que ce skill existe. Le coût d'implémentation le rendait irréaliste pour la plupart des projets. Maintenant je peux le proposer comme un différenciateur parce que le coût d'implémentation est essentiellement nul. L'éventail de ce que je peux offrir s'est élargi sans une demande correspondante sur mon expertise.

Concrètement : une implémentation de shader qui m'aurait pris 6 heures ou plus (si je l'avais tentée) prend maintenant moins de 45 minutes revue incluse. Les 4 minutes de génération et les 10 à 15 minutes de revue laissent 25 à 30 minutes pour des choses que moi seul peux faire — décider si l'effet a sa place dans ce contexte, tester sur des tailles d'appareils réels, m'assurer qu'il sert l'expérience globale.

Ce qui nécessite encore un vrai jugement :

Le skill sait comment appliquer un shader d'aberration chromatique forte à chaque image d'une galerie. Il ne sait pas si un shader d'aberration chromatique forte devrait être sur cette galerie — si ça correspond à la marque, si ça sert le public, si le style photographique le supporte.

Ce choix reste le tien. L'IA gère la complexité mécanique. Les décisions de design restent humaines.

Là où ça tourne encore mal :

Les structures HTML non standard — des projets qui mélangent du JS vanilla avec des patterns modulaires, ou des configurations de chargement d'assets inhabituelles — confondent parfois la phase de lecture du contexte. Ces cas sont devenus plus rares par itération mais n'ont pas disparu.

Il y a aussi une catégorie d'erreurs qui viennent de configurations de projet ambiguës : un projet qui a l'air d'utiliser un bundler mais ne le fait pas en réalité, ou un où Three.js est chargé conditionnellement. Le skill gère ces cas mieux qu'avant, mais un rapide passage en revue avant de déployer sur un projet client vaut toujours le coup.

La prédiction sur laquelle je m'engage :

Les cas d'échec vont se réduire significativement au cours des 12 à 18 prochains mois à mesure que les skills s'amélioreront dans la lecture de contextes de projets complexes. Actuellement, le skill fonctionne de manière fiable sur environ 80 à 85 % des structures de projets standard sans correction manuelle. Ce chiffre se dirige vers 95 %+.

L'opinion impopulaire :

Certains développeurs entendent ce genre de workflow et pensent que ça représente une perte d'artisanat — remplacer de vraies compétences par une dépendance à l'IA. J'ai entendu cet argument appliqué à chaque abstraction dans l'histoire du développement web. jQuery qui abstrait le DOM. Webpack qui abstrait le bundling de modules. TypeScript qui abstrait la sécurité de typage en JavaScript.

Les développeurs qui ont construit leur expertise par-dessus ces abstractions sont ceux qui ont avancé. Savoir quand un effet d'aberration chromatique a sa place dans un design, comment le configurer pour un impact maximum, comment l'adapter à différents contextes — c'est de la vraie expertise qui vaut la peine d'être développée. Le fait que tu n'aies pas à écrire le GLSL à la main ne rend pas ces décisions moins précieuses. Ça les rend plus accessibles aux personnes qui les possèdent.

Construis ta propre version : l'approche que je recommanderais

Si tu veux une version de ce skill dans ta propre configuration Claude Code, voici l'approche que je prendrais maintenant — pas l'approche que j'ai réellement suivie, qui m'a fait perdre du temps.

Ne commence pas par prompter à partir de zéro. Trouve la meilleure implémentation existante d'effet shader Three.js que tu puisses — quelque chose qui fonctionne vraiment en production, gère correctement les cas limites et a été testé sur de vrais appareils. Utilise ça comme exemple fondateur dans la base de connaissances de ton skill.

Un skill n'est aussi bon que ses exemples. Une implémentation de shader excellente, testée en production, enseigne plus au skill que cinq extraits de tutoriels qui prennent des raccourcis.

Construis de manière incrémentale :

• Commence avec un type de shader appliqué à une structure de projet
• Teste-le sur 3 à 4 vrais projets (pas des démos avec du HTML propre)
• Documente chaque cas où la sortie nécessite une correction manuelle — ceux-ci deviennent tes exemples d'amélioration
• Ajoute le type de shader suivant
• Recommence

Ajoute la gestion des modes de défaillance tôt. Dis explicitement au skill quoi faire quand Three.js n'est pas disponible, quand le sélecteur ne trouve rien, quand WebGL n'est pas supporté, quand l'élément cible est à l'intérieur d'un conteneur scrollable. Les skills qui dégradent gracieusement sont ceux auxquels tu fais vraiment confiance.

Si tu arrives à ce qu'un type de shader se génère correctement et gère les échecs à travers trois structures de projet différentes, tu as déjà construit quelque chose de plus pratiquement utile que la plupart des exemples dans cet espace. Tout ce qui suit est de l'itération.

La page galerie que j'ai livrée la semaine dernière — l'aberration chromatique qui tourne au survol, les canaux RGB qui se séparent et se remettent en place quand la souris traverse chaque image — ressemblait au type de travail que j'avais l'habitude de classer dans la catégorie « à faire construire par quelqu'un d'autre ».

L'écart entre ce que tu peux imaginer et ce que tu peux construire se réduit quand les outils changent. Pas parce que tes limites techniques disparaissent. Parce que la complexité mécanique qui se trouvait entre l'idée et le résultat est gérée par quelque chose qui est réellement doué pour la complexité mécanique.

Ton défi pour les prochaines 48 heures : identifie un effet visuel que tu as admiré sur d'autres sites et toujours considéré comme trop complexe à implémenter. Construis une première version d'un skill autour de cet effet. Même une version brute. Teste-le sur un vrai projet et documente où il échoue.

L'effet que tu pensais nécessiter six heures et une expertise spécialisée est peut-être à quatre minutes de toi.

Travaillons ensemble

Tu cherches à construire des systèmes IA, automatiser des workflows ou faire monter en puissance ton infrastructure tech ? Je serais ravi de t'aider.

• Fiverr (builds sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io