Colophon
This site is also a proof. Here is how it is made, who wrote what, and what I decided myself.
The stack
Back
Java 21, Spring Boot 4.1, Maven, Liquibase for the schema, PostgreSQL 17.
Front
Angular 22 (standalone components, signals), server-side rendering with @angular/ssr, TypeScript, plain CSS with no framework.
Infra
Docker Compose, Caddy in front, GitHub Actions.
The site reads fine without JavaScript. The server already sends the full HTML.
Same tech family as my side projects (Oltre, Zotracker) and my work at Worldline: I did not swap tools just to look good.
A team of agents, one team lead
This site is built with agentic development: I write the specs, break the work into tasks, specialized agents write the code, and I make the calls and review every change. Like a small team, with a budget to watch.
| Agent | Role | Model |
|---|---|---|
| tech-lead | Specs, ADRs, trade-offs | Opus |
| designer | Art direction, DESIGN.md | Sonnet |
| backend-dev | Spring Boot, Liquibase, API | Sonnet |
| frontend-dev | Angular, SSR, accessibility | Sonnet |
| code-reviewer | Review before merge | Sonnet |
| qa-engineer | E2E, axe, Lighthouse | Sonnet |
| copywriter | First drafts of texts | Sonnet |
| devops | Docker, CI, deployment | Haiku |
| content-researcher | Facts taken from my documents | Haiku |
Each role gets the cheapest model that can handle the job: Opus for the tech lead (specs, trade-offs), Sonnet for most of the others, Haiku for DevOps and content research.
Skills guide the agents. For design, Taste (against the generic look) and Emil (polish and motion details).
The cycle of a feature: spec, design if needed, back and front in parallel, code review, QA, deployment.
At every checkpoint, a code review and a QA pass (E2E, accessibility, performance). Their reports are in docs/reviews/, flaws included.
Common rule: the smallest change that truly solves the problem. No "just in case" abstractions.
Yes, there is a copywriter agent. No, it did not write this sentence without my review.
Who wrote what
What I decided myself: the concept (the site follows my Grand Trail d'Auvergne), all the content and its sign-off, the architecture and budget trade-offs. No text goes live without my approval.
What the agents did: write the code, the tests and first drafts of texts, from my specs. I review, correct, and sometimes reject.
The project clips
The short demo videos are generated by script: Docker starts the project, Playwright drives it with a fake cursor, ffmpeg encodes the MP4. Fake data only: no real Garmin data or account ever goes in front of the camera. Each clip weighs under 2.5 MB, has no metadata, and only loads when it scrolls into view.
What the CI checks
On every push, GitHub Actions runs four jobs: back (build and tests, ./mvnw verify), front (lint, tests, build), Playwright E2E tests on the full stack, and Lighthouse.
The E2E tests include axe-core: zero accessibility violations, light and dark, in FR and EN.
The mobile Lighthouse thresholds fail the build: 90 for performance, 95 for accessibility, best practices and SEO. A red PR does not merge.
190 tests as of 21 October 2026: 80 on the back end, 81 on the front end, 29 E2E.
A merge to main triggers the deployment: GitHub Actions connects to the server over SSH, pulls main and rebuilds the containers. Docker Compose waits for every service to be healthy before returning. Rolling back takes one command.
The database is backed up every night on the server (7 days kept), and restores are tested on a throwaway database. No off-server copy yet: that is the next step.
It is all in the repo
The source codeThe plans and task lists (tasks/)The architecture decisions (docs/adr/)