Glasck, c'est une plateforme de data esport pour League of Legends, pour le moment. Le projet existe parce qu'un pote avait envie de le faire. Il a commencé seul, et quelques mois plus tard, il m'en a parlé. L'idée me plaisait, la base de données existait déjà. J'ai rejoint avec un autre pote, on a attaqué le design ensemble, et ça s'est enchaîné.

On est quatre sur le projet. Trois développeurs — dont moi — et une quatrième personne qui gère le projet, le marketing et le légal. Côté dev, je gère l'infrastructure. Je bosse aussi sur le design avec l'équipe, et je gère la communication LinkedIn. Les décisions globales, l'évolution du projet, on les prend ensemble.

Mon approche

Dès le départ, je me suis fixé quelques principes.

User first. Chaque décision technique doit servir l'utilisateur, pas flatter l'ego du dev. ROI et tradeoffs : on a du temps limité, chaque choix a un coût. Si une solution à 80% fait le job et prend trois fois moins de temps, on la prend.

Tout ce que je mets en place doit être compréhensible par les autres. Pas de boîte noire que moi seul peux maintenir. Je refuse d'être un SPOF — un Single Point of Failure, le maillon unique dont l'absence bloque tout. Si je suis indisponible, le projet ne doit pas s'arrêter.

La stack — et pourquoi ces choix

Docker Compose en production sur un seul VPS. Pas de cluster, pas de Kubernetes. On est trois devs avec du temps limité — la complexité doit être proportionnelle à l'équipe. Avec Taskfile — un outil d'automatisation de tâches en ligne de commande — c'est déployable et upgradable en une seule commande. Tout le monde dans l'équipe l'utilise.

Traefik en reverse proxy plutôt que Nginx. Quand un nouveau service Docker démarre, Traefik le détecte tout seul grâce aux labels dans le Compose. Les certificats HTTPS se génèrent automatiquement via Let's Encrypt, le dashboard est intégré. Concrètement, ajouter un service exposé c'est trois lignes de config, pas un fichier Nginx à écrire et recharger.

# Extrait docker-compose — labels Traefik sur le frontend
labels:
  - "traefik.enable=true"
  - "traefik.http.routers.frontend.rule=Host(`glasck.gg`)"
  - "traefik.http.routers.frontend.tls.certresolver=letsencrypt"
  - "traefik.http.services.frontend.loadbalancer.server.port=3000"

Rate limiting à 50 req/s sur le front, 100 req/s sur le back. Sticky sessions pour la gestion des sessions utilisateur.

PostgreSQL avec PgBouncer pour le connection pooling — deux bases séparées, une pour les données, une pour l'authentification. Redis pour le cache avec une politique LRU et les commandes destructives désactivées en prod. C'est la stack initiale du projet, elle était en place avant mon arrivée. Je me suis adapté et je l'ai intégrée dans l'infrastructure Docker. Je ne gère pas encore les bases de données — c'est un axe de progression.

Le réseau Docker est segmenté en trois sous-réseaux isolés :

glasck-public-facing    → services exposés (Traefik, front)
glasck-internal-backend → backend + Redis, isolé d'internet
glasck-monitoring       → stack monitoring séparée

Un service compromis sur le réseau public n'a pas accès au backend ni au monitoring. C'est de la segmentation basique, mais ça limite la surface d'attaque.

Docker Swarm tourne en staging, mais le VPS est limité — répliquer fidèlement la stack de prod pour un staging fiable, c'est encore un chantier. Kubernetes, peut-être plus tard, si le trafic et l'équipe le justifient. Pour l'instant, pas de rolling updates automatiques — il y a du downtime au déploiement, mais il reste court et acceptable pour notre stade.

20 minutes après la mise en ligne, plus de site

Vingt minutes après la mise en ligne du site, le serveur crash. Des bots qui crawlent le site en masse, pas de rate limiting en place, pas de visibilité sur ce qui se passe. Le VPS tombe sous la charge. J'ai restreint l'accès via la configuration Traefik — ça a réglé le problème. Mais sans métriques, on a réagi au lieu d'anticiper.

Le premier OOM est arrivé un peu plus tard. Je ne l'ai même pas vu dans les logs. Je l'ai découvert en ouvrant le site — page blanche. Le conteneur avait crashé silencieusement. Il a fallu aller chercher à la main ce qui s'était passé, sans aucune vue sur la mémoire, sans historique. Combien de temps le site était down avant que je m'en rende compte ? Aucune idée.

Avant le monitoring, quand quelque chose cassait, j'allais directement sur le VPS. SSH, docker logs, conteneur par conteneur. Pas de dashboard, pas d'alertes. Tu découvres les problèmes au lieu de les anticiper.

C'est après ces épisodes que j'ai construit la stack monitoring. J'aurais dû commencer par là.

Le monitoring — les yeux sur la prod

Le point de départ, ce sont les quatre Golden Signals : latence, trafic, erreurs, saturation. Si tu surveilles ces quatre métriques, tu captes la majorité des problèmes avant qu'ils deviennent critiques. C'est ce que tu regardes en premier, tous les jours.

Mais on ne s'est pas arrêtés là. On monitore chaque composant — métriques Redis (hit rate, mémoire, connexions), métriques Traefik (requêtes par seconde, codes HTTP, latence par route), métriques PostgreSQL (connexions actives, requêtes lentes), état de chaque conteneur Docker. Les Golden Signals donnent la vision globale. Le reste, c'est pour creuser quand quelque chose cloche.

L'architecture :

Services → Exporters → Prometheus (scrape 15s, rétention 15j)
                            ↓
                        Grafana (9 dashboards)

Conteneurs → Loki + Alloy (agrégation logs)

Alertmanager → Discord webhook + mail

UptimeRobot → monitoring externe (le site répond-il depuis l'extérieur ?)

Sept exporters : node-exporter pour la machine, cAdvisor pour les conteneurs, redis-exporter, deux postgres-exporter (un par base), uptimerobot-exporter, et les métriques built-in de Traefik.

Neuf dashboards Grafana — overview avec les Golden Signals, Docker, node, Redis, Traefik, PostgreSQL, API Fastify, Next.js frontend, et logs centralisés via Loki.

Huit règles d'alerte : ServiceDown (critique, seuil à 2 min pour éviter les faux positifs), HighCPU, HighMemory, DiskSpaceLow, ExternalDown. Les alertes partent sur Discord — c'est là où l'équipe est. Les mails, c'est pour ceux qui ne regardent pas Discord assez souvent.

Les traces, ce sera la prochaine étape. Pour l'instant, métriques et logs couvrent nos besoins.

Aujourd'hui, je vois tout. Un conteneur qui redémarre, une requête lente, un pic de trafic suspect — je le sais en temps réel.

L'anecdote qui résume tout

Après une mise à jour, le site ralentit. Les temps de réponse explosent sur le dashboard Grafana. Une requête côté applicatif se met en file d'attente et fait timeout sur toutes les autres — l'effet domino.

Le monitoring fait son job. Je vois les métriques de latence monter, les logs d'erreur remontent dans Loki, je sais exactement quel service est impacté. Mais je ne peux pas corriger — c'est du code applicatif, pas de l'infra.

Je redémarre le conteneur pour redonner un peu de uptime le temps que la requête survienne une deuxième fois. Pendant ce temps, j'envoie les logs et les métriques à mon pote développeur. Il identifie le problème et fix. Le service repart.

Cette situation m'a marqué. Voir le problème, le diagnostiquer, mais ne pas pouvoir le résoudre parce que c'est pas ton domaine — c'est frustrant. C'est une des raisons pour lesquelles je veux devenir un profil T-shaped : solide sur l'infra, mais capable de comprendre et intervenir sur le code quand il le faut.

Les erreurs utiles

Le monitoring dès le premier jour. Pas après le premier crash, pas après le premier OOM. Avant. C'est pas un luxe, c'est une fondation.

La sécurité pensée plus tôt. On n'a pas eu de problème, mais ce n'est pas une excuse. Durcir la config dès le départ, c'est toujours moins cher que de le faire après un incident.

Le CI/CD est prévu. Pour l'instant le déploiement manuel via Taskfile fait le job, mais à mesure que le projet grandit, ça ne tiendra pas.

Et maintenant

Glasck, c'est mon premier vrai projet en production. Pas un exercice, pas un projet d'école. Le site est là — glasck.gg. Il tourne, il a de vrais utilisateurs, de vraies sessions, du vrai trafic. C'est concret. Quand quelque chose casse, ce sont de vraies personnes qui sont impactées.

On continue de bosser dessus. Pas de pression, chacun avance avec le temps qu'il a — mais on a des objectifs clairs pour le site. Ça change la façon de réfléchir. Chaque décision technique devient un tradeoff entre ce qu'on veut faire, le temps disponible, et surtout ce que l'utilisateur attend. Est-ce que ça marche ? Est-ce que c'est fiable ? Est-ce que l'expérience est correcte ? C'est ça qui compte, pas la stack la plus impressionnante.

Le monitoring n'est pas un bonus. Travailler en équipe, c'est rendre son travail lisible par les autres. Gérer l'infra d'un vrai projet m'a montré tout ce qu'il me reste à apprendre. C'est pour ça que je continue.