Ni Thomas Cochet ni Quentin Kozyra n'ont de passé de développeur. Thomas est Founding Designer chez Hyperline, seul designer sur le produit et la marque. Quentin est Head of Growth, en charge de l'inbound, des ads et de l'outbound. Cet été, ils ont reconstruit le site d'Hyperline avec des coding agents. Ils ont surtout construit l'outil qui permet de le gérer : le Hyperline Studio.
Sommaire14 sections
- 1.Pourquoi quitter Webflow
- 2.Trois exigences de départ
- 3.Partir d'un Figma complet et systémisé
- 4.Tokens, composants, blocs : l'approche atomique
- 5.Des guidelines pour que l'agent ne divague plus
- 6.Le studio, pour éditer sans GitHub
- 7.Créer une page avec un coding agent
- 8.CMS, maillage interne et performance
- 9.Les chiffres du projet
- 10.Pourquoi ça a marché chez Hyperline
- 11.Gérer les accès et les externes
- 12.Au-delà du site
- 13.Pour qui c'est pertinent
- 14.Le replay
1. Pourquoi quitter Webflow
Le projet part d'un rebranding préparé par Quentin. L'ancien site était simple, basique et neutre. Le nouveau devait avoir plus de personnalité et mettre en avant tous les modules du produit. Il devait aussi être plus scalable.
Le plan initial était de rester sur Webflow. Quentin en connaît les limites.
"Quand des personnes du marketing vont agir sur Webflow, la moitié du temps, en fait, ils vont casser une classe. J'en ai cassé assez souvent."
Les rollbacks étaient fréquents. L'implémentation demandait des compétences que l'équipe growth n'a pas. Chaque nouvelle section passait par un design Figma, puis par une agence.
Début été, l'équipe était déjà à l'aise avec les coding engines. Thomas et Quentin ont tenté de refaire la home page avec Claude. En une demi-journée, la landing était refaite, avec un petit outil pour héberger le UI kit. Le CEO a validé la suite. Le site comptait entre soixante et quatre-vingt-dix pages statiques, plus de nombreuses collections.
Très vite, la question a changé. Il ne fallait pas seulement refaire le site, mais toute la manière de le gérer. Le studio est devenu plus important que le site lui-même.
2. Trois exigences de départ
Le projet avait trois exigences dès le départ :
Le design : un site propre, systémisé et cohérent, y compris après les évolutions futures.
L'autonomie du marketing : garder celle de Webflow et l'élargir, avec plus de facilité pour créer des pages.
La performance : ne pas dégrader le SEO ni les aspects techniques par rapport à Webflow.
3. Partir d'un Figma complet et systémisé
Thomas avait déjà un fichier Figma complet, préparé pour l'agence qui maintenait le site. Variables, composants et blocs y suivaient les mêmes normes. Pour lui, c'est le point le plus important du projet.
Ce fichier cadre le travail de l'équipe. Il permet aussi à l'IA de lire Figma via le MCP et de retrouver tous les éléments du design.
"Le plus gros champion des commits sur le repo, c'est Claude."
Selon Thomas, ni lui ni Quentin n'ont écrit une ligne de code pendant le projet.
4. Tokens, composants, blocs : l'approche atomique
Tout a d'abord été tokenisé : fontes, couleurs, spacing.
"La première règle, c'était on ne sort pas du design system."
Si un besoin sort du cadre, l'équipe ajoute un token ou un élément. Les composants suivent la même règle : boutons, checkbox, aucun composant one-off.
Viennent ensuite les molécules, appelées blocs. Chaque bloc a des props, chacun de ses éléments est relié au code. L'IA ne peut pas sortir de ce cadre quand elle crée une page.
Le site a été construit en même temps que l'outil. À chaque page, un nouveau bloc était ajouté. S'il rendait mal, l'équipe le corrigeait et mettait à jour les guidelines.
5. Des guidelines pour que l'agent ne divague plus
À chaque étape où l'IA réfléchit, elle relit des guidelines très précises. Elles couvrent la création d'UI, la composition des blocs et celle des pages. Une règle simple : ne jamais coder une couleur en dur.
En fin de page, l'agent vérifie qu'aucun élément one-off n'a été introduit dans le code. Il se review lui-même pour éviter les incohérences avec le design system.
Avant chaque publication, des tests et des audits contrôlent qu'aucun token n'a été modifié. Si l'agent en change un, l'audit le détecte et le corrige.
"On a vraiment construit le website et par la suite le studio comme des vrais produits."
6. Le studio, pour éditer sans GitHub
Le studio rassemble les pages statiques et les collections CMS, toutes éditables avec leurs props. Changer l'image ou le texte d'un hero se fait directement dans l'interface.
Un « save and push » ouvre une PR. Le repo GitHub est connecté au studio avec authentification. Les personnes non techniques n'ont besoin ni d'un compte GitHub, ni d'un accès au repo.
Une PR correspond à une page. Deux personnes peuvent travailler sur deux pages sans conflit. Un bandeau prévient si une page est déjà en cours de modification. Le merge se fait aussi depuis le studio, puis Vercel déploie en quelques secondes.
Les modifications simples sont ouvertes à tous. Créer une page, modifier ou supprimer des blocs demande plus de technicité. L'équipe ne veut pas que tout le monde touche à la structure.
L'objectif est aussi d'éviter la « prison du website » : la personne qui s'occupe du site devient la seule à pouvoir le mettre à jour.
7. Créer une page avec un coding agent
Pour créer une page, Thomas interroge le repo qui contient à la fois le studio et le site. L'agent utilise un Page Builder skill. Ce skill ajoute la navbar, le préfooter et le footer, puis construit la page bloc par bloc.
Copie, assets et blocs sont hébergés au même endroit. L'agent rédige donc une copie cohérente avec la feature, en suivant les guidelines de copywriting.
Si un bloc ne convient pas, le studio prend le relais. Thomas choisit un bloc dans la librairie, change l'image et le texte, puis copie le code pour l'agent. L'implémentation correspond exactement à ce qui a été prévu.
Le section builder suit la même logique. On assemble ses blocs, on règle l'affichage via les props, puis on copie le code. Quentin construit ses pages ainsi, section par section.
La librairie compte une vingtaine de blocs. Un nouveau bloc reste un travail de designer, à la marge.
"Je ne pense pas qu'on se passe à cent pour cent du designer. En revanche, je pense que le designer peut être beaucoup plus serein sur le fait que le site est complètement sous le design system."
8. CMS, maillage interne et performance
L'équipe n'a pas tout réinventé. La gestion des collections CMS de Webflow fonctionnait bien. Le studio la reprend presque à l'identique, avec des ajouts comme le monitoring de performance.
Le studio couvre aussi ce que Webflow gérait mal : le tracking et le maillage interne. Une section dédiée montre quelle page renvoie vers quelle autre. Quentin s'en sert pour comprendre l'architecture et demander des recommandations à un LLM.
Le Lighthouse de Google tourne automatiquement chaque nuit. Une alerte part dès qu'une page pose problème. La correction passe par l'agent, avec un humain dans la boucle.
"Franchement, je n'ai jamais vu un site aussi performant dans mes précédentes boîtes ou sur les stacks que j'avais sur Webflow avant."
9. Les chiffres du projet
Coût : zéro euro de prestation externe.
Outils : les deux abonnements Claude Max déjà payés, à 200 dollars par mois, sans over usage.
Économie : l'abonnement Webflow est supprimé.
Volume : environ 250 PR et quelque 2 000 commits pour la première version.
Durée : quatre semaines du POC au site prêt, à mi-temps.
Système : vingt blocs, une quinzaine de composants et un UI kit repris du produit.
Hébergement et données restent sur le repo et sur le compte Vercel de l'entreprise. Aucun plan payant supplémentaire n'a été souscrit.
10. Pourquoi ça a marché chez Hyperline
Premier facteur : les designs étaient prêts.
"C'est toujours mieux de partir de ça que de le laisser faire un peu ce qu'il veut, parce que je pense que là, ça ne marcherait pas et ça finirait très vite AI sloppy."
Deuxième facteur : l'itération continue. L'équipe n'améliore pas le site directement. Elle améliore le studio, qui améliore le site. Toute l'équipe peut tester et remonter ce qui ne marche pas.
Troisième facteur : la culture. Presque toute l'équipe travaille sous Claude ou Codex au quotidien. Construire des outils internes y est une habitude. Les retours sur le studio arrivent sous forme de PR ou de suggestions.
Les rôles restent clairs.
"Je suis encore le website owner sur la partie qualité, et Quentin sur la partie market et perf."
Aucun développeur n'a travaillé sur le site. Le CTO a branché l'authentification du studio et validé la stack technique au départ. Thomas a aussi fait tourner des agents pour vérifier la sécurité.
11. Gérer les accès et les externes
L'accès au studio est réservé aux adresses email Hyperline, sans limite d'utilisateurs. Les prestataires externes, comme l'agence SEO, accèdent au repo GitHub. Ils peuvent ouvrir des PR, mais pas merger. Les règles de merge sont fixées dans GitHub.
Les conflits de PR existent, comme sur un produit. Ils portent souvent sur du contenu modifié et se règlent avec l'agent.
12. Au-delà du site
Toutes les images du site sont en HTML, pas en SVG ni en PNG. Thomas a écrit un algorithme qui convertit ses illustrations Figma en code. Le site peut ainsi être traduit sans refaire les visuels. Le texte des images compte aussi pour le SEO.
Le studio héberge tous les assets : icônes, logos clients, images. Ils sont téléchargeables et utilisables par les agents. Thomas travaille sur un builder d'illustrations produit, encore à l'état de projet.
Le design system du studio sert aussi ailleurs. La team produit l'utilise dans ses artefacts Claude ou Codex. Les dashboards internes reprennent son design. Un prototype de sales deck existe, pas encore utilisé par les sales.
L'objectif long terme est un site en autopilote. Chaque PR produit génère déjà un article de documentation. Le même mécanisme pourrait mettre à jour les pages du site, avec une review humaine.
13. Pour qui c'est pertinent
L'approche convient aux sites dont la conversion principale est un formulaire, souvent en B2B. Elle est risquée dès qu'on touche au fonctionnel : e-commerce, gestion de catalogue, member management, liens avec le produit.
Elle marche pour des équipes restreintes qui adoptent l'IA à fond. Thomas ne recommande pas d'en faire son premier projet de vibe coding.
Pour les équipes sans ressources internes, Thomas cite deux alternatives. L'agence Ouiflow accompagnait Hyperline sur Webflow depuis trois ans. Fimo, créé par des anciens de Strapi, propose une approche studio produitisée.