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 , that is 12 days ago
Lowest of the eight pages, per category
- Performance
- 89
- 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 | 91 | 100 | 96 | 100 |
| /fr | 91 | 100 | 96 | 100 |
| /fr/contact | 94 | 100 | 96 | 100 |
| /fr/coulisses | 93 | 100 | 96 | 100 |
| /fr/events | 91 | 100 | 96 | 100 |
| /fr/faq | 92 | 100 | 96 | 100 |
| /fr/image | 92 | 100 | 96 | 100 |
| /fr/journal | 93 | 100 | 96 | 100 |
| /fr/recrutement | 94 | 100 | 96 | 100 |
| /fr/social | 89 | 100 | 96 | 100 |
| /fr/web | 94 | 100 | 96 | 100 |
Tests
- unit tests, across 37 files
- 481
- end-to-end journeys
- 167
- 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.
Change log
What changed, and when
The major passes only, not every edit. The most recent one sits at the top with its age, because a page about rigour should say when it was last touched.
Last pass , that is 13 days ago
The vocabulary, and the journal in English
A pass on content rather than on the machinery.
- A glossary of 78 trade terms, including what each word does not mean.
- The nine journal articles translated and published in English.
- Every case study now points back to the poles it demonstrates.
- Two tests that locked in the absence of English articles were reversed, not deleted.
Work already done finally reaches the visitor
None of this was left to do: it was done, and nobody could see it.
- Subtitles published on all four showreel pieces, the site's last WCAG level A gap.
- A collapsible transcript under each video, rendered server-side, so an engine can read it.
- Two case studies published, and the section finally announced in the navigation.
- Fifty-one commits deployed at once.
A full audit, and its first half
Twenty-seven findings, four of them critical, all saying the same thing.
- The journal made reachable: it existed, and no link on the site led to it.
- A visible breadcrumb on deep pages, and a complete one in the markup.
- The forms' anti-bot check deferred to the visitor's first interaction.
- Performance budgets per page profile, and a framework that no longer announces itself in the headers.
The control chain takes its present shape
This is the pass that produced most of the guardrails described above.
- Structured data validated in continuous integration, the equivalent of the rich results test.
- WCAG 2.2 locked in, including minimum touch target size.
- Visual regression on five pages, compared pixel by pixel.
- The automation scripts themselves analysed, for correctness and for security.
- A stylesheet split removed after measurement: it improved the score and degraded the page.
The foundations
The first pass, the one that laid down what this page describes.
- The content Studio taken out of the public application: thirty-three vulnerabilities down to five.
- Content pages moved to static rendering, served from a cache.
- An automated accessibility audit on every deployment.
- A tool that hunts dead code, and the first files actually removed.
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 →