When we kicked off the website redesign in March 2025, the goal, as we said in other articles, was to refresh our identity and produce a new accessible, eco-designed site. But above all, it is part of a history: this is the third redesign.
We had a first site when the agency was founded, late 2012, early 2013, which lasted until late 2014, early 2015. Then we had a site we’d built in-house, based on templates, in HTML, CSS and maybe a touch of JS back then. It lasted four or five years, and we launched the next redesign in 2020. That time, we chose to get outside help, from people we know in Bordeaux: a designer we respect, a developer we know does good work, a great team. We figured that outsourcing would bring a breath of fresh air, an outside perspective, things we struggle to do ourselves when we try to push ourselves forward: when you renovate your own home, it’s hard to step back, there’s emotion involved, discussions and decisions that aren’t easy to make. We carried out that work and got a result that, quite honestly, we were not at all unhappy with. But with maybe the feeling that we had somewhat lost control of the project. That’s not a bad thing, it’s what we ask of our clients: that they delegate part of the decision-making, even if the final result doesn’t look exactly like what they had in mind at the start, but like the best compromise between the creative vision we’ve built with them and their constraints.
This time, we own the design end to end
For this new site, we didn’t want to do things that way. We wanted to own the design entirely, apply our skills end to end: a real needs-gathering process with clients, former clients, prospects we interview about the site and their vision of it, a real research process that turns this feedback into specifications. Out of these specifications come the user journeys, the site structure, wireframes, then a whole body of work on how our identity evolves and on the UI design, all of it done responsibly.
The project starts in early spring 2025, in March. Summer goes by, and we slowly reach autumn 2025. Everything takes a long time, because it’s an internal project, because we obviously have other projects for clients, and because it’s harder to move internal projects forward, clearly.
An earthquake in autumn 2025
In autumn 2025, just as we’re starting to have a first version, there’s an earthquake in the field of AI, generative AI and LLMs: Anthropic releases its latest model, Claude Opus, version 4.5. We discover that LLMs have an ability to understand a need and turn it into reliable workflows that is, quite simply, a bit staggering. There’s a before and after compared to the other models, and it’s incredible.
We’ve been running tests with AI for a long time, since the first GPT playground, in summer 2022. We figured we’d gradually look at what we could do on mockups and front-end integration, because handoff with developers is a major issue, for them, for us, for our clients: handovers are always painful, we’re no exception, we work on it a lot, we’ve trained for it, but it’s still complicated. So we test regularly: could we smooth this out, or even take more initiative and position ourselves on the front end? The few attempts we’d made had been terribly unsuccessful. As soon as we had mockups for the new site, we ran tests again and it didn’t work. So, from autumn 2025 to early winter 2026, these new models arrive, we run tests again, and this time it works. We test AI to build PowerPoint templates, it works, HTML mockups, it works, InDesign templates, it works too!
The seed is planted. We’ve wanted to try this for so long, so what if the best client were us? We want a concrete, tangible project: we don’t want to claim we know how to do things, we want to show it. It would be our showcase, the thing we most want to show we’re proud of, the one where we planned to put ourselves to the test: accessibility, eco-design, experience, usability, design, performance, Opquast, everything really. Don’t we have a golden use case right in front of us?
WordPress, Astro and the back-office question
The really big technical obstacle is that we’re on WordPress, and the reason we’re on it is that the whole team produces content, puts it online and needs to be autonomous for that. Doing front-end dev on WordPress, honestly, doesn’t appeal to us much. It’s built on PHP/MySQL, it’s not at all something that seems trivial to us. But at that same time, we read an article by the creator of Yoast SEO, the search optimization plugin that’s hugely well known in the CMS community: he had just moved his own site over to a framework called Astro. This framework produces static pages, with no PHP or database on every visit, assembled from reusable components. In our minds, it also opens up the possibility of creating a back-office, whose form would still need defining, that would keep giving the team the ability to contribute to the site and create their own content.
Six months of pottery
So we dive into integrating the mockups in Astro. The mockups, we designed them as usual in Figma. As we mentioned, the team is trained in front-end dev and design systems, so the logic of tokenization, naming, variables, auto-layout, all of that was built into the design, with many iterations on which we sometimes nitpicked. We still notice that it isn’t perfect in that respect. It’s a period when the Figma MCP isn’t fully available yet, so we have to tinker: there’s a small piece of MCP, Figma offers a web MCP and a desktop MCP that don’t quite have the same features, and the API is available on the side. Technical details, but sand in gears that are already hard enough to keep running smoothly. Fairly quickly, we still manage to produce a first page with a satisfying result, without it being quite perfect.
We don’t need to go into the details, but what’s certain is that it was extremely long, because it’s back-and-forth work. It’s pottery: you rough it out, you have clay at the start, then you have to refine, refine, refine until it ends up looking like something. To do this work, we tried to structure things as much as possible. We built a harness with skills that fetch the information in Figma and translate it into a language Claude can fully use. We added a systematic verification process that compares the implementation to the original mockup. Vision capabilities aren’t enough, because they’re too full of approximations. So we also wrote algorithms to overlay the planned mockups and the implemented ones and mathematically calculate the offset. We’re really in a mindset where we try to push pixel perfect as far as possible.
Once we started having pages, we needed an internal acceptance testing process. It involves a person in charge of integration, which is admittedly done by Claude, but who steers that integration, and the UI team, in charge of a 100% homegrown process. We developed a small Chrome plugin that allows very fine-grained acceptance testing of the mockups, with a dashboard to track things page by page. It’s a developer’s approach, quite simply: we take ownership of what it is, and we fully adapt it to our profession, our process, our way of working.
We also set up a quality process on every page. Before any page is submitted for acceptance testing, agents check the Opquast criteria and the RGESN, calculate the EcoIndex, look at WCAG and check the RGAA. All of this is done automatically. There’s a lot of room for improvement, it’s very fallible, open to criticism, no doubt about it, but we put this process in place to make sure we’re already thinking about it, that we make the effort and that, when things aren’t right, because a lot of things come up, even automatically, we fix them.
In the end, the project lasted almost six months, infinitely longer than if we’d worked with a dev agency, without the slightest doubt. But that’s also the cost of upskilling, of testing and of forming a firm view on the subject. We ran into situations countless times where we fix a problem on the right and the AI creates another one on the left, for no reason at all, then we fix the problem on the left and it breaks on the right, for no reason either. It led us to change our practices a lot, and the harnesses we put in place to manage surgical edits, to stop degrading things, to stop unravelling on one side while we knit on the other.
What this changes for front-end integration
That’s what now gives us the conviction that the front-end integration profession, if it doesn’t disappear, is still somewhat under threat: if in 2026, with AIs that keep progressing, we’re able to do this kind of thing, a lot of things will become possible for a lot of people, and the vibe coding trend certainly doesn’t prove us wrong. Of course, two months after settling on a final publishable version, we still discover almost every day things that aren’t quite right, bugs, approximations to fix, mistakes we’d missed. With a dev agency, we clearly wouldn’t have had all this work after the fact, we’d have had a much better quality delivery, that’s the price we’re still paying.
But it also allowed us to build a conviction about the work that needs to start on our own research and design output, and about the way our own profession is directly affected by AI. In the short term, it’s even under threat, and in the medium and long term, it’s going to change, profoundly. The time it takes for everyone to fully grasp the situation as it stands today and for organizations to let these new practices, armed with these new tools, settle in. But that will be the subject of another article.
The illustrations in this article were generated by AI (see our AI use statement).
