Quand on lance la refonte du site en mars 2025, l’objectif, comme on l’a dit dans d’autres articles, c’est de rafraîchir notre identité et de produire un nouveau site accessible et éco-conçu. Mais elle s’inscrit surtout dans une histoire : c’est la troisième refonte.
On a eu un premier site à la création de l’agence, fin 2012, début 2013, qui a duré jusqu’à fin 2014, début 2015. Ensuite, on a eu un site qu’on avait fait maison, sur la base de templates, en HTML, CSS et peut-être un poil de JS à l’époque. Il a duré quatre ou cinq ans, et on a lancé la refonte suivante en 2020. Cette fois, on a fait le choix de se faire accompagner, par des gens qu’on connaît à Bordeaux : un designer qu’on estime, un développeur dont on sait qu’il fait du bon boulot, une belle équipe. On se disait qu’en sous-traitant, ça apporterait un nouveau souffle, un regard extérieur, des choses qu’on a du mal à faire nous-mêmes quand on essaie de se faire progresser : quand on fait les travaux chez soi, c’est difficile de prendre du recul, il y a de l’affect, des discussions et des décisions pas faciles à prendre. On a mené ce travail et on a obtenu un résultat dont, très honnêtement, on n’était pas du tout mécontent. Mais avec peut-être le sentiment qu’on avait un peu perdu la main sur le projet. Ce n’est pas un mal, c’est ce qu’on demande à nos clients : qu’ils délèguent une partie de la décision, quitte à ce que le résultat final ne ressemble pas parfaitement à ce qu’ils avaient en tête au départ, mais au meilleur compromis entre la vision créative qu’on a construite avec eux et leurs contraintes.
Cette fois, on porte le design de bout en bout
Pour ce nouveau site, on n’avait pas envie de faire les choses de cette manière. On voulait porter le design intégralement, appliquer nos compétences de bout en bout : une vraie démarche d’expression du besoin avec des clients, d’anciens clients, des prospects qu’on interroge sur le site et sur leur vision du site, une vraie démarche de research qui transforme ces retours en spécifications. De ces spécifications sortent les parcours, l’arborescence, des wireframes, puis tout un travail sur l’évolution de notre identité et sur le design UI, le tout de façon responsable.
Le projet démarre début du printemps 2025, en mars. L’été passe, et on arrive doucement à l’automne 2025. Tout prend beaucoup de temps, parce que c’est un projet interne, qu’on a évidemment d’autres projets pour des clients, et que c’est plus difficile de faire avancer des projets internes, clairement.
Un tremblement de terre à l’automne 2025
À l’automne 2025, quand on commence à avoir une première version, il y a un tremblement de terre dans le domaine de l’IA, des IA génératives et des LLM : Anthropic sort son dernier modèle Claude Opus, la version 4.5. On découvre que les LLM ont une capacité à comprendre le besoin et à le transformer en workflows fiables qui est, tout bêtement, un peu sidérante. Il y a un avant-après par rapport aux autres modèles, qui est incroyable.
Ça fait longtemps qu’on fait des tests avec l’IA, depuis le premier playground de GPT, à l’été 2022. On se disait qu’on allait regarder progressivement ce qu’on pouvait faire sur le maquettage, l’intégration, parce que le handoff avec les développeurs est un point majeur, pour eux, pour nous, pour nos clients : les passages de relais sont toujours douloureux, on ne fait pas exception, on travaille beaucoup dessus, on s’est formés, mais ça reste compliqué. Alors on teste régulièrement : est-ce qu’on pourrait fluidifier ça, voire être encore plus force de proposition et se positionner sur la partie front ? Les quelques essais qu’on avait faits avaient été terriblement infructueux. Dès qu’on a eu des maquettes pour le nouveau site, on a refait des tests et ça n’a pas marché. Donc, de l’automne 2025 au début de l’hiver 2026, ces nouveaux modèles arrivent, on refait des tests, et là ça marche. On teste l’IA pour intégrer des templates PowerPoint, ça fonctionne, des maquettes HTML, ça fonctionne, des modèles InDesign, ça fonctionne aussi !
La graine est plantée. Depuis le temps qu’on a envie de tester, est-ce que le meilleur client ne serait pas nous ? On a envie d’un projet concret, tangible : on n’a pas envie de prétendre qu’on sait faire des choses, on a envie de le montrer. Ce serait notre vitrine, ce dont on veut montrer qu’on est le plus fier, sur lequel on a prévu de se mettre à l’épreuve : l’accessibilité, l’éco-conception, l’expérience, l’ergonomie, le design, la performance, Opquast, tout en fait. Est-ce qu’on n’a pas un cas d’usage en or sous la main ?
WordPress, Astro et la question du back-office
Le très gros frein technique, c’est qu’on est sous WordPress, et la raison pour laquelle on y est, c’est que toute l’équipe produit du contenu, le met en ligne et a besoin d’être autonome pour ça. Aller faire du dev front end sur Wordpress, honnêtement ça nous tente très moyennement. Ça s’articule avec du PHP/MySQL, c’est pas du tout un truc qui nous semble trivial. Mais à cette même période, on lit un article du créateur de Yoast SEO, ce plugin d’optimisation du référencement hyper connu de la communauté CMS : il vient de basculer son propre site sur un framework qui s’appelle Astro. Ce framework produit des pages statiques, sans PHP ni base de données à chaque visite, assemblées à partir de composants réutilisables. Dans notre tête, ça ouvre aussi la possibilité de créer un back-office, dont il faudrait définir la forme, qui continuerait à offrir à l’équipe la possibilité de contribuer au site et de créer son propre contenu.
Six mois de poterie
Du coup, on se lance dans l’intégration des maquettes sous Astro. Les maquettes, on les a conçues comme d’habitude sous Figma. Comme on l’a précisé, l’équipe est formée au dev front et au design system, donc la logique de tokenisation, de nommage, de variabilisation, d’auto-layout, tout ça a été intégré dans la conception, avec de nombreuses itérations sur lesquelles on a parfois pinaillé. On s’aperçoit quand même que ce n’est pas parfait de ce point de vue. C’est une période où le MCP Figma n’est pas encore pleinement disponible, donc il faut bricoler : il y a un petit bout de MCP, Figma propose un MCP web et un MCP desktop qui n’ont pas tout à fait les mêmes fonctionnalités, et l’API est disponible à côté. Des détails techniques, mais du sable dans des rouages qui sont déjà pas simples à faire tourner de manière fluide. Rapidement, on arrive quand même à produire une première page avec un rendu satisfaisant sans être tout à fait parfait.
On n’a pas besoin de rentrer dans les détails, mais ce qui est sûr, c’est que ça a été extrêmement long, parce que c’est un travail d’allers-retours. C’est de la poterie : on dégrossit, on a de la glaise au début, puis il faut raffiner, raffiner, raffiner jusqu’à ce que ça finisse par ressembler à quelque chose. Pour faire ce travail, on a essayé de structurer au maximum. On a construit un harnais avec des skills qui vont chercher les informations dans Figma et les traduisent dans un langage complètement utilisable par Claude. On a ajouté un processus de vérification systématique qui compare l’implémentation à la maquette initiale. Les capacités de vision ne suffisent pas, parce que c’est trop plein d’approximations. On a donc aussi écrit des algorithmes pour superposer les maquettes prévues et les maquettes implémentées et calculer mathématiquement le décalage. On est vraiment dans une logique où on essaie de pousser le pixel perfect au maximum.
À partir du moment où on a commencé à avoir des pages, on a eu besoin d’un processus de recettage interne. Il implique une personne en charge de l’intégration, certes réalisée par Claude, mais qui pilote cette intégration, et l’équipe UI, en charge d’un processus 100 % maison. On a développé un petit plugin Chrome qui permet un recettage très fin des maquettes, avec une logique de tableau de bord pour suivre page par page. C’est une logique de dev, tout bêtement : on s’approprie ce que c’est, et on l’adapte pleinement à notre métier, à notre process, à notre façon de travailler.
On a aussi instauré une démarche qualité sur chacune des pages. Avant que la moindre page soit soumise au recettage, des agents vérifient les critères Opquast et le RGESN, calculent l’EcoIndex, regardent le WCAG et vérifient le RGAA. Tout ça est réalisé automatiquement. C’est très améliorable, très faillible, critiquable, il n’y a pas de doute, mais on met en place cette démarche pour s’assurer qu’on y pense déjà, qu’on fait l’effort et que, quand il y a des choses qui ne vont pas, parce que beaucoup de choses remontent, même de manière automatique, on les corrige.
Le chantier a duré quasiment six mois au final, infiniment plus longtemps que si on avait travaillé avec une agence de dev, sans le moindre doute. Mais c’est aussi le coût de la montée en compétence, du test et de la construction d’une conviction forte sur le sujet. On a été confrontés un nombre incalculable de fois à des situations où on règle un problème à droite et où l’IA en crée un autre à gauche, sans aucune raison, puis on règle le problème à gauche et ça casse à droite, sans aucune raison non plus. Ça nous a amenés à beaucoup faire évoluer nos pratiques, et les harnais qu’on met en place pour arriver à faire de la modification chirurgicale, pour arrêter de dégrader, de détricoter d’un côté quand on tricote de l’autre.
Ce que ça change pour l’intégration
C’est ce qui nous permet aujourd’hui d’avoir la conviction que le métier de l’intégration, s’il ne disparaît pas, est quand même un peu menacé : si en 2026, avec des IA qui continuent à progresser, on arrive, nous, à faire ce genre de choses, beaucoup de choses vont devenir possibles pour beaucoup de monde, et la tendance au vibe coding ne nous contredit certainement pas. Alors bien sûr, deux mois après avoir arrêté une version définitive publiable, on découvre encore chaque jour ou presque des choses qui vont pas tout à fait, des bugs, des approximations à corriger, des erreurs au travers desquelles on était passé. Avec une agence de dev, on aurait clairement pas eu tout ce travail a posteriori, on aurait eu une livraison de bien meilleure qualité, c’est le prix qu’on paie encore.
Mais ça nous a aussi permis de nous construire une conviction sur le travail qu’il faut initier en direction de notre propre production en research et en design, et sur la manière dont notre propre métier est directement touché par l’IA. À court terme, il est même menacé, et à moyen et long terme, il va évoluer, en profondeur. Le temps que tout le monde prenne la pleine mesure de la situation telle qu’elle est aujourd’hui et que les organisations sédimentent ces nouvelles pratiques armées de ces nouveaux outils. Mais ça, ça fera l’objet d’un autre article.
Les illustrations de cet article ont été générées par IA (voir notre déclaration d’usage de l’IA).
