Behind the scenes
What we holdourselves to.
A portfolio site proves very little about the people who built it. So here is how this one is built: the checks it has to pass before going live, what they measure, and what we learned along the way.
Guardrails
What blocks a deployment
Every change goes through the same sequence before it reaches the site. It runs on its own, in about ten minutes, and any one of these steps failing stops the deployment. Nothing goes live because someone judged it good enough.
01
Vulnerable dependencies
Every external library is checked against the public vulnerability database. A high or critical advisory stops everything, and the list of tolerated exceptions is empty. It is the check that protects your visitors' data, not our comfort.
02
Types and dead code
The compiler verifies that every value is what the code believes it to be, which removes a whole family of bugs before they exist. A second tool hunts files, exports and libraries nobody uses any more: a site that carries dead weight becomes slow and hard to change.
Tests
Several hundred small checks on the logic (form validation, spam filtering, rate limiting), plus full journeys played out in two browsers, as a visitor would. If a link, a form or a page stops working, the deployment stops with it.
04
Visual regression
The first screen of five pages is compared pixel by pixel against a reference image. It is the only net that catches a page that still works but looks wrong: a block shifted by 200 pixels, a gradient gone missing.
05
Performance and accessibility
Eight pages are audited on loading speed, accessibility, best practices and search readiness, with a floor per category. Any waiver is written down with the measurement that justifies it.
06
The automation audits itself
The scripts that run all of the above are themselves analysed by two tools, one for correctness and one for security. An automated pipeline has access to the site: leaving it unchecked would make it the weakest link.
Measurements
The numbers
None of these are typed by hand. A script reads the audit reports, runs the tests and counts what it finds, then writes a dated record that this page simply displays.
Measured on
Lowest of the eight pages, per category
- Performance
- 88
- Accessibility
- 100
- Best practices
- SEO
- 100
We show the lowest score, not the average. An average would let a weaker page hide behind the others.
Page by page
| URL | Performance | Accessibility | Best practices | SEO |
|---|---|---|---|---|
| /en | 94 | 100 | 96 | 100 |
| /fr | 91 | 100 | 96 | 100 |
| /fr/contact | 93 | 100 | 96 | 100 |
| /fr/coulisses | 92 | 100 | 96 | 100 |
| /fr/events | 91 | 100 | 96 | 100 |
| /fr/faq | 92 | 100 | 96 | 100 |
| /fr/image | 92 | 100 | 96 | 100 |
| /fr/journal | 96 | 100 | 96 | 100 |
| /fr/recrutement | 93 | 100 | 96 | 100 |
| /fr/social | 88 | 100 | 96 | 100 |
| /fr/web | 93 | 100 | 96 | 100 |
Tests
- unit tests, across 35 files
- 467
- end-to-end journeys
- 151
- visual comparisons
- production dependencies
- 9
Nine libraries reach your browser, and that is deliberate. Every dependency is an attack surface, a weight to download and a future migration. Whatever could be written in thirty lines was written.
Logbook
What the audits taught us
An audit tool gives an opinion, not a verdict. Here are four cases where the tool was wrong, or right in a way nobody expected. Each one changed something in how this site is built.
An estimated saving is not a measurement
An audit reported 13.8 KB to be saved on a browser compatibility block. We weighed it: 630 bytes once compressed, a factor of 22. These savings are modelled from byte counts and converted into milliseconds by a formula, not observed. The block stayed.
A change that improved the score and hurt the page
Splitting the stylesheet per page improved the render blocking indicator. Measured on the same machine, back to back, it delayed both the first visible content and the largest image. We removed it and wrote down the numbers, so nobody tries it again in six months.
A check that quietly stopped checking
One scanning tool dropped 10 of 28 pages from its report when it failed to record them, rather than failing. Replayed on their own, those pages scored 93 to 98: the tool was competing with itself. A check able to stop verifying without saying so is worse than no check, so that one became a diagnostic and never a gate.
Watching the home page watches nothing
Pages are pre-generated and served from a cache: they keep answering identically even if the content system has been unreachable for three weeks. The most likely failure of this site is content quietly freezing, which no ordinary monitor would see. So there is a dedicated endpoint that actually queries the content system.
Honest reading
How to read these numbers
They are solid, and they have a scope. Saying where it ends is part of the job.
- A performance score is measured on one machine, at one moment, over a simulated network. It shows a trend and catches regressions, which is exactly what we ask of it.
- An automated accessibility audit catches roughly a third of real problems. The other two thirds need someone trying the page with a keyboard and a screen reader, which is a separate pass.
- The record carries the date it was taken. The site may have moved since, which is why the date is shown next to the numbers rather than hidden.
- None of this says whether the site is beautiful or whether it tells the right story. Those are decided elsewhere, and they matter just as much.
The same rigour on your project?
That is what the Web pole does. Tell us what you need to build.
Talk about your project →