Étude de cas
CWS. Piloter les guerres
de clan sur des faits
Projet personnel · Product · Design system · Développement full-stack
2026 · En production, bêta fermée sur ~50 clans
Comment transformer la mémoire approximative d'un chef de clan en décisions justes, acceptées de tous : qui aligner en guerre, qui progresse, qui décroche ?
En bref
L'essentiel en cinq lignes
Dans Clash of Clans, les chefs pilotent les guerres « à l'œil » : captures d'écran, mémoire, favoritisme involontaire. Aucun moyen objectif de savoir qui mérite sa place.
Une web-app qui synchronise les guerres via l'API officielle, calcule un classement de mérite, et propose un tableau de bord de roster pour les Ligues de Clans (CWL).
Seul aux commandes : cadrage, priorisation, UX, design system, full-stack et mise en production.
Déployé en bêta fermée sur ~50 clans. Le suivi des guerres est la fonctionnalité la plus utilisée et appréciée ; le module CWL est ma prochaine itération.
Je tiens la chaîne produit, design et front sans rupture.
Pour les non-initiés
Le jeu, en 30 secondes
Clash of Clans est un jeu mobile de stratégie. Des joueurs se regroupent en « clans » et s'affrontent lors de « guerres ». Voici la boucle, sans laquelle rien de ce qui suit n'a de sens.
Deux clans s'affrontent
Deux équipes de taille égale (souvent 15 ou 30 joueurs) s'opposent sur environ deux jours.
Chaque joueur attaque
Il dispose d'attaques pour tenter de détruire la base (le « village ») d'un adversaire.
On compte les étoiles
Chaque attaque rapporte 1 à 3 étoiles selon le pourcentage de destruction. 3 étoiles = base rasée.
Le clan le plus étoilé gagne
Le total d'étoiles départage les deux clans. Chaque joueur aligné compte dans le score.
Le dilemme du chef : un clan compte souvent plus de membres que de places en guerre. Le chef choisit qui aligner et qui laisser sur le banc. Aujourd'hui, ce choix se fait au ressenti. C'est exactement ce que CWS outille : décider sur des faits, pas sur la mémoire.
Le vocabulaire utile
Étoiles & pourcentage
Le score d'une attaque : de 0 à 3 étoiles, fonction du pourcentage de la base détruite.
Town Hall (TH)
L'hôtel de ville, soit le niveau et donc la puissance d'un village. On compare les joueurs à niveau égal.
Oubli
Un joueur qui n'utilise pas ses attaques. Des étoiles potentielles perdues pour tout le clan.
Roster (line-up)
La liste des joueurs sélectionnés pour une guerre. Plus de membres que de places, donc des arbitrages.
CWL (Ligue de Clans)
Compétition mensuelle où huit clans s'affrontent en plusieurs manches sur une semaine.
Classement de mérite
Le classement calculé par CWS pour mesurer qui contribue vraiment. À ne pas confondre avec le rang affiché en jeu.
Contexte & problème
Un problème de confiance
autant que de données.
Clash of Clans est un jeu mobile où les clans s'affrontent en « guerres ». À chaque guerre, le chef décide qui aligner et qui mettre sur le banc, sur du ressenti. On se souvient du raté de la semaine dernière, on oublie celui qui performe en silence, et les choix créent des tensions. Aucun historique objectif, aucune mesure de mérite partagée.
La vraie question produit n'était pas « comment afficher des stats » mais « comment produire une décision juste, acceptée de tous, à partir de données brutes que personne n'a envie de lire ».
Contrainte structurante : l'API officielle est en lecture seule. On observe les guerres, jamais on n'agit dessus. Le produit se pense donc comme un outil d'aide à la décision : il conseille, le chef applique en jeu.
La problématique
L'API est en lecture seule : le produit conseille, le chef applique.
Mon rôle
Décider, designer
et coder, sans traduction.
Projet mené seul, de bout en bout : product management (cadrage, proposition de valeur, roadmap, bêta & feedback), product design (modèle mental, écrans, design system, mobile-first), développement (front maison, back Flask/PostgreSQL, intégration API) jusqu'à la mise en production.
C'est le point que ce projet illustre : une même personne décide, designe et code. Les décisions produit ne sont jamais jetées par-dessus le mur d'une équipe technique. Elles sont prises en connaissant leur coût, et livrées.
Le produit
Quatre briques, une source de vérité
01
Suivi des guerres
La brique phare. Synchro automatique de chaque guerre, détail des attaques (étoiles, %, oublis), historique. Elle remplace les captures d'écran par une source de vérité partagée.
02
Classement de mérite
Un classement cumulatif qui récompense la régularité et la réussite, sans punir l'absence.
03
Roster CWL
Tableau de bord de conseil pour la compétition mensuelle (CWL) : roster recommandé, file d'attente, rotation automatique en cas d'échecs ou d'oublis.
04
Plateforme multi-clans
Recherche de clans, profils joueurs, comptes (favoris, liaison de son village) pour la personnalisation et l'administration.
Décisions produit clés
Quatre arbitrages qui ont défini le produit
1. Refondre le classement pour qu'il cesse de punir l'absence.
TensionLa v1 « repartait du classement précédent ». Un joueur absent une seule guerre était renvoyé en bas ; un seuil mal calibré finissait par exclure tout le monde. Produit décourageant, donc inutile.
ArbitrageL'absence n'impacte plus le classement (on valorise ce qu'on fait quand on joue). Une colonne « Réussite » = taux d'attaques à 3 étoiles, lisible sans explication. Et j'ai tranché une ambiguïté de vocabulaire qui bloquait le projet depuis des semaines (« Ranking » = position en jeu vs « Classement » = sortie de l'algo).
Ce que ça montreReconnaître qu'une mécanique logique sur le papier échoue à l'usage, remonter à la cause, reconcevoir autour de l'équité perçue. Nommer correctement a débloqué la conception.
2. Assumer un produit qui conseille plutôt qu'il impose (CWL).
TensionL'API étant en lecture seule, impossible d'imposer une composition d'équipe. La tentation : promettre une « gestion automatique du roster » intenable.
ArbitrageConcevoir explicitement un tableau de bord de conseil (roster recommandé, file d'attente, alertes en cas d'échecs ou d'oublis). Les chiffres sont calculés sur l'équipe réellement alignée, jamais sur la recommandation, pour ne pas les fausser.
Ce que ça montreTransformer une contrainte technique dure en posture produit claire, et itérer par l'usage. C'est aussi la fonctionnalité qui doit le plus progresser : sa complexité se révèle au contact des clans.
3. Un design system « néo-brutalisme arcade », mobile-first, après deux pivots.
TensionLe jeu se joue sur téléphone, dans une ambiance ludique. Une UI « dashboard SaaS » sobre aurait trahi le contexte.
ArbitrageTrois itérations (détaillées plus bas), validées sur une référence visuelle puis systématisées en tokens CSS et documentées dans une page /styleguide vivante. Navigation au pouce : onglets fixes en bas sur mobile, navbar en header au-delà d'un seuil précis.
Ce que ça montreItérer une direction artistique jusqu'à ce qu'elle serve l'usage, puis la rendre industrialisable. La jointure design et front.
4. Investir tôt dans une architecture « plateforme ».
TensionL'outil était au départ pour mon seul clan. Le rendre multi-clans coûte tout de suite pour un bénéfice futur.
ArbitrageReconstruire un schéma de données propre (clans, joueurs, guerres normalisés, URLs scopées par clan), ajouter comptes, favoris et liaison de village, avec une vraie hygiène de sécurité (argon2id, CSRF, rate-limiting). Données publiques en lecture, comptes pour la personnalisation.
Ce que ça montreDistinguer ce qui se bricole de ce qui se reconstruit, et absorber une dette maîtrisée au bon moment.
Conception & design
Une direction artistique qui sert l'usage
Le design system est maison et entièrement tokenisé (tokens.css) : composants stylés (score de guerre, ligne d'attaque, onglets, timeline, modale, pagination), avec une page /styleguide comme source de vérité. Cohérence design et code garantie : la même personne pose le token et l'utilise dans le composant.
Trois itérations de direction artistique
La DA n'est pas tombée juste du premier coup. Deux pivots ont été nécessaires avant de trouver une identité qui assume le contexte ludique sans sacrifier la lisibilité d'un tableau de guerre dense.
v1
Bleu corporate
Trop générique. Indistinct d'un énième dashboard SaaS, sans lien avec l'univers du jeu.
v2
War Room sombre & or
Trop classique, pas assez responsive. L'ambiance y gagnait, l'ergonomie mobile y perdait.
v3
Néo-brutalisme arcade
Surfaces claires, encre épaisse, ombres dures, effet tactile « push-down », typo ultra-grasse.
L'effet tactile « push-down »
Les composants interactifs s'enfoncent au contact, comme un bouton d'arcade. Une micro-interaction qui ancre l'identité ludique tout en confirmant l'action sur mobile.
Démo : cliquez le bouton ci-dessus.
Mobile-first assumé
Le jeu se vit sur téléphone, l'outil aussi.
- Navigation au pouce : onglets fixes en bas sur mobile
- Libellés explicites, états vides travaillés
- Accents de couleur pour hiérarchiser un tableau de guerre dense
- Micro-décisions d'ergonomie issues de l'usage réel
« Une même personne pose le token de design et l'utilise dans le composant. La cohérence n'est pas un process, c'est un point de vue. »
Réalisation technique
Du backend à la mise en production
Back
Python / Flask · PostgreSQL
Intégration
API officielle Clash of Clans, pipeline d'import partagé app + cron horaire.
Front
HTML / CSS / JS, design system maison, sans framework UI lourd.
Comptes & sécurité
Flask-Login, argon2id, CSRF, rate-limiting, e-mails transactionnels (confirmation, reset).
Production
VM Oracle Cloud (ARM), Nginx → Gunicorn → Flask, HTTPS via Cloudflare, domaine dédié, versioning et minification des assets.
Aller jusqu'au bout. Après un déploiement, le cache Cloudflare servait des fichiers obsolètes. Je l'ai réglé par un versioning automatique des assets : chaque déploiement génère une nouvelle URL, donc un cache invalidé. Ce genre de problème ne se voit qu'en opérant son produit en prod.
Résultats & apprentissages
Validé par l'usage réel
Résultats
~50
Clans en bêta fermée, en production réelle
N°1
Le suivi des guerres, fonctionnalité la plus utilisée et appréciée (cœur de valeur validé)
∞
Boucle de feedback riche : retours d'expérience, bugs, suggestions
Ce que j'ai appris
- Le module CWL doit progresser : sa complexité ne se révèle qu'au terrain, c'est ma prochaine grande itération.
- Nommer, c'est concevoir.
- L'équité perçue prime sur la pureté de l'algorithme.
- Opérer son produit change le design : cache, déploiements et sécurité façonnent l'expérience réelle.
Ce que ce projet dit de ma façon de travailler
Une même vision, de la stratégie au front, sans étape de traduction.
J'ai cadré le problème, arbitré la roadmap, conçu le design system, écrit le code et opéré le produit en prod. À chaque décision produit, je connaissais le coût technique ; à chaque écran, le design était livré, pas seulement dessiné.