Colophon
Ce site est aussi une preuve. Voici comment il est fait, qui a écrit quoi, et ce que j'ai décidé moi-même.
La stack
Back
Java 21, Spring Boot 4.1, Maven, Liquibase pour le schéma, PostgreSQL 17.
Front
Angular 22 (composants standalone, signals), rendu côté serveur avec @angular/ssr, TypeScript, CSS natif sans framework.
Infra
Docker Compose, Caddy en frontal, GitHub Actions.
Le site se lit sans JavaScript. Le serveur envoie déjà le HTML complet.
Même famille de technos que mes projets perso (Oltre, Zotracker) et que mon travail chez Worldline : je ne change pas d'outils pour faire joli.
Une équipe d'agents, un chef d'équipe
Ce site est construit en développement agentique : j'écris les specs, je découpe le travail en tâches, des agents spécialisés codent, et je tranche et relis chaque modification. Comme une petite équipe, avec un budget à surveiller.
| Agent | Rôle | Modèle |
|---|---|---|
| tech-lead | Specs, ADR, arbitrages | Opus |
| designer | Direction artistique, DESIGN.md | Sonnet |
| backend-dev | Spring Boot, Liquibase, API | Sonnet |
| frontend-dev | Angular, SSR, accessibilité | Sonnet |
| code-reviewer | Revue avant fusion | Sonnet |
| qa-engineer | E2E, axe, Lighthouse | Sonnet |
| copywriter | Premiers jets de textes | Sonnet |
| devops | Docker, CI, déploiement | Haiku |
| content-researcher | Faits tirés de mes documents | Haiku |
Chaque rôle prend le modèle le moins coûteux qui tient la tâche : Opus pour le tech lead (specs, arbitrages), Sonnet pour la plupart des autres, Haiku pour le DevOps et la recherche de contenu.
Des skills guident les agents. Pour le design, Taste (contre le look générique) et Emil (les détails de finition et de mouvement).
Le cycle d'une feature : spec, design si besoin, back et front en parallèle, revue de code, QA, déploiement.
À chaque point de contrôle, une revue de code et une passe QA (E2E, accessibilité, performance). Leurs rapports sont dans docs/reviews/, défauts compris.
Règle commune : la plus petite modification qui résout vraiment le problème. Pas d'abstraction « au cas où ».
Oui, il y a un agent rédacteur. Non, il n'a pas écrit cette phrase sans que je la relise.
Qui a écrit quoi
Ce que j'ai décidé moi-même : le concept (le site suit mon Grand Trail d'Auvergne), tous les contenus et leur validation, les arbitrages d'architecture et de budget. Aucun texte ne part en ligne sans mon accord.
Ce que les agents ont fait : écrire le code, les tests et les premiers jets de textes, sur mes specs. Je relis, je corrige, je refuse parfois.
Les clips des projets
Les courtes vidéos de démonstration sont générées par script : Docker lance le projet, Playwright le pilote avec un faux curseur, ffmpeg encode le MP4. Données factices uniquement : aucune donnée Garmin ni aucun compte réels ne passent devant la caméra. Chaque clip pèse moins de 2,5 Mo, sans métadonnées, et ne se charge que lorsqu'il entre à l'écran.
Ce que la CI vérifie
À chaque push, GitHub Actions lance quatre jobs : le back (build et tests, ./mvnw verify), le front (lint, tests, build), les tests E2E Playwright sur la pile complète, et Lighthouse.
Les E2E incluent axe-core : zéro violation d'accessibilité, en clair et en sombre, en FR et en EN.
Les seuils Lighthouse mobile font échouer le build : 90 en performance, 95 en accessibilité, bonnes pratiques et SEO. Une PR rouge ne se fusionne pas.
190 tests au 21 octobre 2026 : 80 côté back, 81 côté front, 29 E2E.
Une fusion sur main déclenche le déploiement : GitHub Actions se connecte en SSH au serveur, récupère main et reconstruit les conteneurs. Docker Compose attend que chaque service soit sain avant de rendre la main. Pour revenir en arrière, une commande suffit.
La base est sauvegardée chaque nuit sur le serveur (7 jours gardés), et la restauration se teste sur une base jetable. Pas encore de copie hors du serveur : c'est la prochaine étape.
Tout est dans le dépôt
Le code sourceLes plans et listes de tâches (tasks/)Les décisions d'architecture (docs/adr/)