MC Skin Creator

MC Skin Creator est un éditeur de skins Minecraft dans le navigateur, en ligne sur mcskincreator.app. On compose un personnage en empilant des calques (peau, yeux, cheveux, vêtements…) pris dans un catalogue de plus de 500 éléments, on les recolore, on dessine au pixel et on voit le résultat en 3D animée, dans neuf décors (prairie, cerisiers, neige, jungle, canyon, lagon, grotte, marais, enfer…), avant de l’exporter en PNG, en GIF ou en planche de sprites. Plus de 120 modèles de départ permettent de partir d’un personnage existant. L’application associe un back-end Java 21 / Spring Boot 4 et un front Angular 21, livrés ensemble dans un seul jar exécutable construit par Maven. Interface en français, anglais et espagnol.

Un projet personnel, construit avec l’IA. MC Skin Creator a été développé de bout en bout avec l’assistance de l’IA (Claude / Claude Code) : c’est à la fois un produit en ligne et une expérience grandeur nature sur ce qu’on peut aujourd’hui construire, tester, déployer et promouvoir seul avec un assistant. Toutes les captures de cette page ont été prises dans le site lui-même, avec les modèles et les décors du catalogue.

Le produit en quelques chiffres

• 500+ éléments dans le catalogue, plus de 120 modèles de départ, 9 décors 3D, 3 langues.
• Un seul jar qui embarque le back-end, le front et la logique de rendu ; Docker en option.
• Environ 300 ms entre l’ouverture de la page et un éditeur prêt à l’emploi, grâce aux planches d’assets compressées.
• Tests à tous les étages et déploiement automatique à chaque fusion (voir plus bas).

Back-end — Java 21, Spring Boot 4

• Moteur de composition de textures en Java : recoloration de chaque élément par zones, réglages teinte / saturation / luminosité, empilement des calques, puis génération de la texture 64×64 et de sa vignette, recalculées et stockées à chaque enregistrement. Le moteur est publié comme bibliothèque indépendante (mcsc-engine, sans aucune dépendance) pour être réutilisée par le site et par un mod Minecraft. Un test compare les résultats octet par octet à l’implémentation de référence sur tout le catalogue (plus de 1 800 cas).
• API REST de stockage des skins (Spring MVC, Spring Data JPA, migrations Flyway, base H2) : brouillon enregistré automatiquement, skins nommés, texture et vignette servies en PNG. Client anonyme identifié par un UUID dans un en-tête, modèle prévu pour accueillir une table de comptes.
• API publique versionnée (/api/v1) : un contrat stable pour les clients tiers (le mod), avec une politique de rupture documentée et un test qui échoue si un champ publié disparaît ou change de nom.
• Validation et import : un projet mal formé est refusé en 400 au format problem details (RFC 9457), avec la liste de chaque écart et son chemin (par exemple layers[3].adj.hue). Import de skins PNG 64×64, 64×32 (déplié par symétrie) ou HD (réduits), chaque refus portant un code d’erreur traduit par le front.
• Résistance aux abus : limitation de débit par client et par adresse (429 avec Retry-After), corps de requête plafonnés et refusés avant lecture, quota par client, identifiants validés. Un audit m’a montré qu’une requête de 249 Ko pouvait arrêter la JVM : la correction et un test qui passe toutes les routes au crible (aucune entrée fabriquée ne doit provoquer de 5xx) en sont sortis.
• Catalogue et chargement rapide : fusion de plusieurs sources d’assets avec rechargement à chaud, recherche paginée dans les trois langues, tirages aléatoires rejouables par graine, crédits et licence pour chaque élément. Plus de 1 000 PNG sont regroupés en une planche compressée par catégorie, avec une empreinte du contenu dans l’URL pour le cache long.
• Profils, sécurité et référencement : deux profils Spring, dont un profil public qui ne sert que les éléments dont la licence autorise la publication (vérifié par un test). Filtre posant les en-têtes de sécurité (CSP stricte, sans script inline) et les règles de cache ; sitemap, robots.txt et image de partage Open Graph (1200×630) générés côté serveur.

Front-end — Angular 21, TypeScript

• Éditeur complet : bibliothèque par régions et catégories, pile de calques en glisser-déposer, inspecteur de couleurs, éditeur de pixels 2D, historique annuler / rétablir.
• Rendu 3D en WebGL sur mesure, sans bibliothèque 3D : dix animations reprises du jeu, vue à la première personne ajustée numériquement sur une capture du jeu, peinture directement sur le modèle 3D (sélection du texel par rendu hors écran).
• Architecture Angular : composants autonomes, état géré par signaux, détection de changement sans zone.js, boucle d’animation hors d’Angular. Couche de stockage abstraite : le même front fonctionne sur l’API Java ou sur le localStorage.
• Exports et mobile : encodeur GIF animé intégré au projet (quantification median-cut, compression LZW), interface adaptée au mobile (tiroirs, gestes tactiles, pincement à deux doigts dans l’éditeur de pixels).

Les outils que je me suis construits

Un projet de cette taille demande de fabriquer beaucoup de choses en plus du produit : un logo, des visuels, des vidéos, un catalogue propre. Plutôt que de sortir du projet pour chacune, j’ai demandé à l’IA de construire les outils dont j’avais besoin, dans le projet même. Ils réutilisent le vrai catalogue et le vrai moteur de rendu : ce qu’ils produisent est donc toujours fidèle au produit.

/logo — le logo est fabriqué par le site

Une page compose une tête de skin avec des éléments du catalogue, en laisse la moitié en papier quadrillé, y pose un crayon en 3D et exporte le tout en PNG (256, 512 ou 1024 px). Projection perspective ou orthographique, grille tracée par le shader, rendu suréchantillonné pour des arêtes propres. Le logo que vous voyez sur le site n’a pas été dessiné dans un logiciel graphique : il a été composé avec l’application elle-même.

/banniere — le marketing en un clic

Une page génère les visuels de chaque réseau : bannière X (1500×500), panorama Instagram en trois posts, couverture TikTok, bannière YouTube (2560×1440) et photo de profil. Chaque format connaît sa zone sûre (ce que le réseau rogne) et un test vérifie qu’aucun élément essentiel n’en sort. Un personnage d’exemple s’habille couche par couche, et le décor n’est tiré que parmi les modèles qui n’exigent aucune attribution.

/video — des vidéos d’annonce à la volée

Dix secondes de motion design en musique autour d’un modèle ou d’une tenue, en 9:16, 1:1 ou 16:9, exportées en MP4 avec leurs légendes prêtes à copier pour chaque réseau. Tout est calculé dans le navigateur : cinq plans montés sur un tempo de 120 BPM, une musique synthétisée note par note (neuf styles, aucun fichier audio, donc aucun droit à payer), un encodeur MP4 et un encodeur AAC écrits pour l’occasion. Un exemple de résultat est visible dans la section Vidéos plus bas, publié sur la chaîne YouTube du projet.

Et aussi

• L’atelier de découpage des skins. Les modèles de départ viennent de skins existants découpés automatiquement en éléments du catalogue, avec une vérification au pixel près que la pile de calques redonne la texture d’origine. Des outils dédiés repèrent les zones, proposent un brouillon de découpage, rendent des planches de contrôle sous quatre angles et essaient chaque vêtement sur d’autres peaux.
• La page /doublons. Deux skins différents portent souvent le même œil de quatre texels : cet outil regroupe les éléments qui se ramènent l’un à l’autre par une simple recoloration, fait tourner chaque famille en 3D pour juger, et écrit la consigne de fusion.
• Une console d’administration (Java / Angular) qui pilote ces outils depuis une interface, et un lot d’import avec fiche de licence pour chaque skin repéré.

Comment j’ai construit ce projet avec l’IA

C’est la partie qui m’intéresse autant que le produit. Avec un assistant comme Claude Code, le goulot d’étranglement n’est plus d’écrire du code, mais de décider quoi construire et de vérifier que c’est juste. Concrètement :

1. Je cadre et je décide. Direction artistique, choix d’architecture (un seul jar, un moteur partagé, un profil public), règles du jeu (licences, noms, limites) : c’est moi qui les pose, et je les consigne dans un fichier d’instructions du dépôt que l’IA relit à chaque session. Ce fichier est devenu une vraie documentation d’architecture, avec les pièges déjà payés.
2. L’IA implémente, en petites étapes vérifiables. Une branche par tâche, des commits courts, et surtout des tests écrits en même temps : la confiance vient des tests et pas du fait que « ça a l’air de marcher ».
3. Je relis et je teste à l’œil ce qui ne se calcule pas. Le rendu, la justesse d’une animation, la lisibilité d’une vignette : l’IA a produit des outils (planches de contrôle, essayage, comparaison d’écrans avant/après) pour que je puisse voir le résultat plutôt que le supposer.
4. Chaque défaut trouvé devient une règle ou un test. Un bug livré est documenté avec sa cause, puis verrouillé par un test qui ne doit plus jamais échouer pour cette raison. Le projet apprend de ses erreurs.
5. L’IA fabrique aussi ses propres outils. Logo, bannières, vidéos, découpage des skins, détection de doublons, console d’administration : à chaque fois qu’une tâche répétitive apparaissait, elle est devenue un outil.

Ce que ça change concrètement : le marketing d’un produit peut se faire en quelques minutes plutôt qu’en quelques jours. Les bannières de tous les réseaux, la couverture TikTok, une vidéo d’annonce avec sa musique et ses légendes : ce sont des choses qu’on obtient d’un clic parce que l’outil existe, et qu’on peut régénérer à chaque nouveau modèle ajouté au catalogue. Toutes les images de cette page en sont la preuve.

CI/CD — de la fusion à la production

Le déploiement est entièrement automatisé avec GitHub Actions (deploiement.yml) : fusionner dans main, c’est mettre en ligne, environ un quart d’heure plus tard.

• Flux Git : deux branches longues, develop (intégration) et main (publication). Chaque tâche vit sur une branche feature/… ou fix/… fusionnée avec trace dans develop ; rien n’est jamais commité directement sur main.
• Trois jobs lancés sur chaque push et chaque pull request : l’atelier (vérification de syntaxe de tout le JavaScript, une centaine de tests, régénération des assets et contrôle qu’elle ne change rien), le site (build Maven complet du front et du back, tests JUnit, tests Vitest, tests Playwright contre le jar réellement lancé) et, sur main uniquement et seulement si les deux premiers passent, la publication.
• Le jar vérifié est celui qui est déployé : le job de publication récupère l’artefact construit et testé, sans le reconstruire, et l’envoie par SSH sur un VPS OVH (Gravelines).
• Un serveur derrière Cloudflare, sans port web ouvert : le VPS n’accepte que SSH ; les visiteurs arrivent par un tunnel Cloudflare initié depuis le serveur (pas de certificat à renouveler, adresse du serveur absente du DNS). Le site tourne sous un service systemd dédié, avec un compte système sans privilèges.
• Un déploiement défensif : la clé stockée dans les secrets GitHub ne peut faire qu’une chose, publier une version (restrict,command=… : ni shell, ni transfert de port). Le serveur vérifie l’archive (aucun lien symbolique), déplace le lien current, redémarre le service et attend que l’API réponde ; sinon il revient tout seul à la version précédente. Trois versions sont conservées, la clé d’hôte du serveur est épinglée dans le workflow.
• Exploitation : base H2 sauvegardée chaque nuit (14 sauvegardes gardées, plus la copie quotidienne du disque chez l’hébergeur), en-têtes de sécurité et règles de cache posés par le serveur, limitation de débit à deux niveaux (application et Cloudflare), et une image Docker multi-étapes pour lancer le site sans installer Java ni Node.
• Dépendance interne maîtrisée : la bibliothèque mcsc-engine est publiée sur GitHub Packages avec une version figée (jamais de SNAPSHOT), parce que le moteur décide des octets d’un skin déjà enregistré ; la CI reçoit son droit de lecture par la permission packages: read.

Qualité — des tests à tous les étages

Aucun test ne remplace les autres : chaque étage vérifie ce que les autres ne voient pas.

• JUnit (back-end) : API et stockage sur base H2 en mémoire, validation des projets, règle de publication du profil public, contrat de l’API /api/v1, limitation de débit avec horloge injectée, et un test de résistance aux abus qui découvre lui-même les routes et les soumet toutes aux mêmes entrées piégées (corps trop lourd, bombe PNG, JSON de dix mille niveaux, identifiants mal formés) : il a trouvé deux erreurs 500 dès son premier passage.
• Tests de parité : le moteur de textures existe en trois versions (JavaScript de référence, TypeScript pour le navigateur, Java pour le serveur). Deux tests les comparent octet par octet sur le vrai catalogue (plus de 1 800 textures et 366 empreintes de modèles), ce qui permet d’affirmer qu’ils ne font qu’un.
• Vitest (front) : moteur TypeScript, animations (aucun bras ne traverse la tête à aucun moment du cycle), encodeurs GIF, MP4 et AAC (relus par un décodeur écrit pour les tests, structure des boîtes MP4 vérifiée), dictionnaires de traduction, référencement.
• Playwright (de bout en bout) : 42 tests contre le jar lancé — brouillon conservé après rechargement, isolation de deux clients, glisser-déposer d’un calque, dessin sur la texture, import, export, sérialisation qui ne perd aucune propriété.
• Tests de l’atelier : environ cent tests sans dépendance sur le catalogue lui-même — zones UV qui ne se chevauchent jamais, noms uniques dans les trois langues, longueur maximale des libellés, crédits présents pour chaque élément, aucune couleur sans effet.
• Contrôles de bout en bout des données : chaque modèle de départ est recomposé à partir des fichiers publiés et comparé au pixel près à sa texture d’origine.

Projet non officiel. Non approuvé par, ni associé à Mojang ou Microsoft. « Minecraft » est une marque déposée de Mojang Synergies AB.