La méthode du site web AI-Native : 10+ sites qui scorent tous 90+ sur Google PageSpeed

Salut !

Je m’appelle Lambert. J’ai 23 ans et je dirige le growth chez Morgen.

Depuis quelques années, je construis, je maintiens et je shippe des sites web. La plupart tournaient sur WordPress, avec le stack habituel : Elementor, Astra, Crocoblock, JetEngine, JetElements, des plugins de performance, des plugins de traduction, tout le zoo. Le site marketing de Morgen vit sur Webflow. J’ai travaillé dans les deux mondes.

Les deux produisent de vrais sites. Les deux ont leur taxe.

Il y a quelques mois, pendant qu’on construisait Kai (l’assistant exécutif IA qu’on lance), on a commencé à utiliser un stack différent pour construire le site de Kai lui-même : une base de connaissances, un design system serré, Cursor, Claude Code, Next.js, GitHub, Vercel. Pas de CMS. Pas de file d’attente de plugins. Pas d’éditeur Webflow.

Ça a tellement bien marché que j’ai commencé à migrer d’autres sites de la même façon.

J’ai désormais construit ou migré 10+ sites web comme ça. Ils scorent tous 90+ sur Google PageSpeed. Aucun ne nécessite de maintenance mensuelle.

Cet article, c’est la méthode : ce que je faisais tourner avant, ce qu’est réellement un « site web AI-Native », comment fonctionne le processus de migration, et pourquoi je parie tout le site de Kai, ainsi qu’une nouvelle agence que je viens de (re)lancer (Wellosite), sur la même approche.

Cet article est pour toi si :

• Tu es CMO ou marketeur et tu possèdes un site web que tu peux à peine modifier sans développeur
• Tu gères plusieurs sites clients ou produits et la maintenance te dévore
• Tu paies Webflow et tu ressens la friction de l’éditeur à chaque fois que tu shippe quoi que ce soit
• Tu as entendu parler d’« AI-Native » à toutes les sauces et tu veux une image concrète de ce que ça veut dire

C’est parti.

Partie 1 : Les deux anciens mondes dans lesquels je vivais

Les deux mondes fonctionnent. Les deux m’ont permis de shipper de vrais sites. Je ne suis pas là pour enterrer l’un ou l’autre. Je suis là pour nommer le coût.

WordPress + plugins : la taxe de maintenance

Je gérais 10+ sites WordPress en même temps. Chacun avait Elementor ou un builder visuel similaire, quelques modules JetEngine, un plugin de traduction, un plugin de cache, un plugin SEO, et une poignée de plus petits plugins pour des fonctionnalités spécifiques.

Ça marchait. Ça saignait aussi.

Quelques moments qui m’ont marqué, pour donner une idée concrète de ce à quoi ressemble cette saignée :

• J’ai un jour voulu changer la police d’un site de plus de 500 pages. En théorie : simple. Tu modifies les réglages du thème, ça se propage. En pratique : même après avoir changé les réglages du thème, certaines polices refusaient de se mettre à jour correctement. J’ai passé quatre heures à essayer d’appliquer la nouvelle police de façon cohérente. J’ai abandonné.
• J’ai mis à jour un site une fois. Tous les plugins, le thème, tout. Hygiène standard. Le site a cassé. Les effets avaient disparu, les sections Elementor étaient cassées, j’ai dû tout rollback et réinitialiser des parties du site pour le ramener à un état propre.
• Le grand classique : se reconnecter à WordPress après deux semaines de travail concentré ailleurs. Dix mises à jour en attente dans la file. Cette appréhension, c’est un truc à part entière.
• Plus d’une fois, je me suis retrouvé à chercher un plugin pour faire un truc basique, comme un formulaire de contact ou un élément de page spécifique, et à finir par installer des choses qui n’avaient quasiment aucun sens, juste pour que le site fasse ce que je voulais.
• Et à chaque fois que j’héritais d’un site web créé par quelqu’un d’autre, je devais nettoyer le cimetière de plugins avant même de pouvoir commencer. Supprimer les plugins de design, trier ce qui était réellement utilisé, démêler les dépendances, reconstruire des parties du site avec une config plus serrée juste pour le rendre performant à nouveau.

Aucun de ces moments n’est dramatique. Mais sur 10+ sites, ils constituent une taxe de fond récurrente. Chaque site est une petite dette récurrente, et la dette se cumule.

Webflow : la taxe d’éditeur + la taxe de coût

Je travaille aussi sur Webflow. Le site marketing de Morgen est construit sur Webflow. Webflow n’a pas le problème des plugins. L’hébergement est solide, la plateforme est fiable, et tu n’as pas de mises à jour aléatoires qui cassent ton build.

Mais Webflow a sa propre friction.

À chaque fois qu’on veut implémenter quelque chose, on entre dans l’éditeur et on modifie la page. Si on veut un bloc ou un layout légèrement unique, ça prend du temps. Publier un article de blog prend du temps. Construire un composant custom prend du temps. Il y a aussi une friction de performance selon la façon dont le site est structuré.

Et puis il y a le coût.

220,52 $ par mois. Tous les mois. Environ 2 650 $ par an, juste pour faire tourner le site marketing. Et ça, c’est un seul workspace. Multiplie ça par plusieurs sites, plusieurs clients, ou plusieurs langues (Morgen shippe en 6 langues), et la friction de l’éditeur se multiplie en même temps que la facture.

Encore une fois : ce n’est pas un mauvais logiciel. Mais le levier plafonne vite.

La question

Les deux mondes fonctionnent. Les deux sont taxés. La question que j’ai commencé à me poser, coincé entre une fenêtre de maintenance WordPress et une session d’éditeur Webflow, était simple :

Et si la taxe n’était pas nécessaire ?

Partie 2 : Ce qu’est réellement un « site web AI-Native »

L’expression est balancée à toutes les sauces. Laisse-moi lui donner une définition concrète.

Un site web AI-Native, c’est un site construit pour que l’IA puisse le lire, le modifier et l’étendre en quelques prompts.

Ce n’est pas « l’IA a généré mon site ». Ce cadrage passe à côté de l’essentiel. L’essentiel est structurel : chaque partie du site, le design, le contenu, les composants, le pipeline de déploiement, est façonnée pour que la manière la plus naturelle de faire un changement soit une conversation avec un assistant IA, et non un clic dans un éditeur ou l’installation d’un plugin.

Le stack

Les pièces sont simples :

• Une base de connaissances. Des fichiers Markdown décrivant le produit, la marque, l’audience, la voix, la hiérarchie de messaging, les règles de design. La vérité sur le site vit ici.
• Un design system en code. Des tokens pour les couleurs, la typographie, les espacements. Un seul fichier CSS comme source unique de vérité.
• Cursor + Claude Code. L’éditeur et la couche de raisonnement. Claude lit la base de connaissances, les design tokens et le codebase, puis propose des changements.
• Astro ou Next.js. Le framework. Statique, rapide, sans CMS sauf si un CMS est réellement nécessaire. Pour Kai on utilise Next.js. Pour la plupart des sites clients j’utilise Astro.
• GitHub. Versionnage, PRs, historique, rollbacks. Tout le site est un artefact sur lequel l’équipe peut collaborer.
• Vercel. Déploiement au push. Pas d’hébergement à surveiller.

C’est tout. Pas de marketplace de plugins. Pas d’abonnement CMS. Pas de verrouillage par l’éditeur.

Pourquoi ça change l’équation

Chaque changement est une conversation avec Claude qui se termine par une PR. Un nouvel article ? Tu déposes un fichier markdown. Une nouvelle traduction ? Tu fais tourner un prompt sur les pages existantes. Un nouveau bloc ? Tu le décris. Une nouvelle section ? Tu la décris. Mettre à jour la voix de marque sur tout le site ? Tu mets à jour la base de connaissances, tu régénères les pages concernées.

Le point de levier n’est pas « l’IA écrit mon code à ma place ». Le point de levier, c’est que le site est désormais un système que l’IA comprend de bout en bout.

Une phrase d’ancrage : AI-Native, ce n’est pas « l’IA a généré mon site ». C’est un site façonné pour que l’IA soit la façon la plus naturelle de le maintenir.

Partie 3 : La méthode de migration

La théorie ne coûte rien. Voici le processus concret que je fais tourner quand je migre un site.

Décision de stratégie : clone d’abord ou reconstruction de zéro

Pour chaque migration, le premier choix, c’est la stratégie. Deux voies :

• Clone d’abord. Tu prends le HTML/CSS existant, tu enlèves ce dont tu n’as pas besoin, tu le portes dans Astro (ou Next.js) sous forme de pages statiques. Préserve la fidélité visuelle. Rapide.
• Reconstruction de zéro. Tu jettes le markup d’origine, tu reconstruis composant par composant à partir des design tokens. Plus lent, mais tu te retrouves avec un système plus propre.

J’ai appris ça à la dure sur Cash Converters Bienne. J’ai tenté 3 itérations de reconstruction propre. Après 3 passes, je plafonnais autour de 85 % de fidélité visuelle. De petits détails continuaient de glisser. Puis j’ai changé de stratégie en plein milieu du projet : clone-and-strip. Une seule passe. 99 % de fidélité.

La leçon : clone pour la fidélité. Reconstruction pour l’ambition. Si le design d’origine est ce que le client veut et que l’objectif est de migrer sans perturber la marque, clone. Si l’original est daté et que la migration est aussi une refonte, reconstruis.

Les quatre phases d’une migration

Chaque migration suit les mêmes quatre phases.

1. Audit. Lire le site existant de bout en bout. Lister les pages. Lister les assets. Lister les plugins ou dépendances CMS. Lister la surface SEO : meta tags, hreflang pour les sites multilingues, schema JSON-LD, redirections. Tout ce qui porte le SEO ou l’UX est signalé.

2. Base de connaissances + design tokens. Extraire les design tokens : couleurs primaires, couleurs secondaires, stack typographique, échelle d’espacement, radius, ombres. Écrire un CLAUDE.md qui dit à Claude ce qu’est le site, à qui il s’adresse, ce qu’il faut préserver et ce qui est ouvert au changement. Ce fichier, c’est la différence entre un Claude qui devine et un Claude qui exécute.

3. Build. Soit clone-and-strip du HTML, soit build par prompt composant par composant, selon la phase 1. C’est là que Claude fait le gros du travail d’implémentation. Moi, je fais le jugement.

4. Préservation du SEO. Meta, hreflang, JSON-LD, portés à l’identique. Redirections mappées en 1:1, sans chaînes. Cette phase n’est pas négociable. Les migrations cassent le SEO quand les équipes la sautent. Elles gardent le SEO quand les équipes la traitent comme une checklist, et non comme un détail de fin de parcours.

À quoi ça ressemble en pratique

Quelques chiffres réels issus de migrations que j’ai shippées :

Site	Stratégie	Itérations	Fidélité
Cash Converters Bienne (FR/DE)	Clone-and-strip	4 (3 tentatives de rebuild, puis 1 clone)	99 %
Laura Van Therapies	Clone-and-strip	1	100 %
psychotrauma.expert (en cours)	Deux en parallèle : v1 clone + v2 refonte	n/a	n/a
Wellosite	Build greenfield	n/a	n/a
Kai (hirekai.ai)	Build greenfield	n/a	n/a

Sur Cash Converters, le poids du CSS raconte l’histoire à lui seul : le bloc <style> Elementor d’origine, c’était environ 80 Ko de surcharge dans le head. Les styles scopés reconstruits sont sortis autour de 6 Ko. Tout le site n’a nécessité que 70 lignes d’overrides CSS pour corriger un seul widget Slick Carousel qui dépendait du JS. C’est tout. Le reste, c’est de l’Astro propre.

Ce ne sont pas des histoires de « l’IA a tout fait ». Ce sont des histoires de « l’IA a géré l’implémentation pendant que je gérais le jugement ». C’est exactement cette répartition qui fait que le workflow fonctionne.

À retenir : Clone pour la fidélité. Reconstruction pour l’ambition. Choisis celle qui colle au site, pas celle qui sonne le plus impressionnant.

Partie 4 : La boucle qui se cumule, pourquoi l’AI-Native, c’est plus que shipper plus vite

Cette section, c’est la partie qui m’a pris du temps à voir clairement, et c’est la partie qui compte le plus.

Construire un site plus vite, c’est bien. Construire un site qui s’améliore avec le temps, avec moins d’effort, c’est le vrai prix à gagner.

Voici la boucle que je fais tourner maintenant sur Kai, sur Wellosite, et sur les sites sur lesquels je travaille pour des clients.

Étape 1 : Une base de connaissances pour le business

Des fichiers Markdown. Pas Notion, pas un CMS. De simples fichiers .md dans un dossier.

Ce qu’on y met : la description du produit, le positionnement, l’audience, la voix de marque, les value props, le paysage concurrentiel, la hiérarchie de messaging, les règles de design, toute décision qui mérite d’être conservée. La vérité sur le business, sous une forme que Claude peut lire.

Pour Kai, c’est un dossier de dizaines de fichiers markdown. Pour un client plus petit, ça peut être 5 fichiers. La taille n’a pas d’importance. La discipline de mettre la vérité par écrit, si.

Étape 2 : Alimenter la base de connaissances en continu

C’est là que Kai lui-même entre en scène.

J’enregistre les réunions. Les réunions internes de l’équipe, les appels clients, les conversations de vente. Kai gère l’enregistrement. Kai produit aussi la transcription.

Les transcriptions vont directement dans la base de connaissances.

Ça paraît anodin. Ça ne l’est pas. Chaque conversation devient un dépôt. La base de connaissances s’enrichit chaque semaine sans que personne ait à « rédiger de la documentation ». Le coût de capture tombe à quasiment zéro.

Étape 3 : Générer à partir du contexte complet

Quand je veux écrire un nouvel article, une nouvelle page de fonctionnalité, une nouvelle page de comparaison, je ne pars pas d’une page blanche.

Je dis à Claude : lis la base de connaissances. Lis les transcriptions de réunions pertinentes. Lis le design system. Puis propose la structure, l’angle, le brouillon.

Ce qui revient n’est pas de la prose IA générique. C’est un brouillon ancré dans le langage réel des clients, le positionnement réel du produit, la voix de marque réelle. Avec le design system verrouillé, le résultat est aussi déjà stylé, conforme à la marque et structurellement propre.

Étape 4 : Publier et capturer le tour suivant

L’article est shippé. Il performe (ou non). Les données de performance, les commentaires, les réponses des clients, tout ça revient nourrir la base de connaissances.

Le prochain article est plus tranchant que le précédent.

Pourquoi c’est ça, le point de levier

Dans le monde WordPress, chaque article est un départ de zéro. Tu t’assieds, tu fixes l’éditeur du regard, tu écris.

Dans le monde Webflow, le design est verrouillé mais la rédaction reste un départ de zéro, et la publication elle-même prend du temps.

Dans le monde AI-Native, chaque article hérite de tout ce que tu as déjà enregistré, écrit, décidé ou shippé avant. L’actif se cumule.

C’est aussi la raison pour laquelle j’ai commencé à migrer les sites clients de cette façon, et pas seulement les miens. Une fois qu’un client a une base de connaissances + un design system + le workflow AI-Native, il ne me paie pas pour toujours pour mettre à jour son site. Il me paie pour mettre en place la boucle. Ensuite, la boucle tourne.

Partie 5 : Ce que j’ai shippé

Le gros titre : 10+ sites migrés. Tous scorent 90+ sur Google PageSpeed. Aucun ne nécessite de maintenance mensuelle.

Je ne vais pas dérouler chaque projet. La plupart de ces 10+ sont des sites clients que j’ai migrés en silence, avant même d’avoir un nom pour ce que je faisais. Ceux qui méritent d’être cités ici sont ceux qui servent aussi de preuve de la direction que prend l’approche.

Kai (hirekai.ai), la méta-preuve

Kai est l’assistant exécutif IA qu’on lance. Le site marketing de Kai, hirekai.ai, tourne sur :

• Next.js 16, React 19
• Vercel AI SDK v6 + Claude Sonnet
• Neon Postgres (serverless, edge-compatible)
• Hébergement Vercel
• Un blog MDX : les posts vont dans content/blog/*.mdx, slug par nom de fichier, sans CMS

Chaque couche du site est façonnée pour que l’IA fasse partie de la façon dont il se construit et dont il se maintient. La démo de chat sur la page d’accueil utilise l’AI SDK nativement. La couche d’intelligence de la waitlist (extraction de contexte à partir des conversations) utilise Claude. Le blog que tu liras peut-être ensuite tourne sur le même setup MDX que cet article.

C’est, aussi concrètement que le terme peut le signifier, un site web AI-Native.

Wellosite, le pari de l’agence

Wellosite est l’agence que j’ai lancée pour appliquer cette approche aux sites des autres. La page de destination de Wellosite est elle-même un site web AI-Native : Astro 6.1.5, Tailwind v4, icônes Lucide, multilingue dès le départ (anglais, français, espagnol, portugais).

Elle shippe en 4 langues parce que traduire un fichier markdown avec le contexte complet de la marque, ça ne coûte presque rien. Tu ne fais pas passer la traduction par un plugin. Tu la fais passer par Claude avec la voix de marque verrouillée.

Positionnement : « Ton site web, AI-Native. » Pas juste moins cher que Webflow, prêt pour l’IA. Tiers : Starter, Pro, Custom.

Le site est le pitch. C’est la chose qu’il vend.

lambert.lecourtdeberu, le site que tu es en train de lire

Le site personnel sur lequel tu es en ce moment, c’est le même stack : Astro, des content collections pour le blog, des design tokens, pas de CMS. Chaque post est un fichier markdown dans un dossier. Chaque page de projet est un composant. Ajouter cet article, c’était un prompt et une PR.

La même boucle que Kai, à plus petite échelle.

Et après : Morgen

Morgen.so lui-même est dans le backlog. ~990 pages, 6 langues, un vrai projet. Délibérément pas encore démarré, le travail de cadrage est la première phase. Quand il sera shippé, ce sera le plus gros cas à ce jour.

Le pattern

WordPress ou Webflow avant, Astro ou Next.js après. Toujours avec une base de connaissances et des design tokens. Toujours shippé via GitHub et déployé sur Vercel. Les détails changent d’un site à l’autre. La forme, non.

Partie 6 : Ce que ça a changé opérationnellement

Les métriques comptent. Le changement opérationnel compte davantage, surtout si tu es CMO ou responsable marketing, parce que c’est là que la vélocité de l’équipe bascule vraiment.

La collaboration devient du langage naturel. Personne n’a à apprendre un CMS. N’importe qui dans l’équipe peut décrire ce qu’il veut : « le CTA du hero devrait dire X, et le témoignage en dessous devrait tourner chaque semaine. » Cette description devient un prompt. Le prompt devient une PR. La PR devient un déploiement. Des minutes, pas des jours.

Les traductions deviennent triviales. Wellosite shippe en 4 langues parce que traduire un fichier markdown avec le contexte complet de la marque est à un prompt Claude de distance. Pas de plugin de traduction. Pas de service tiers. Pas de dérive d’éditeur entre les langues.

Les articles prennent moins de temps, et surtout, ils s’améliorent. La base de connaissances grandit. Chaque dépôt de réunion enrichit le matériau source. Le prochain article hérite de plus de contexte que le précédent. C’est la boucle qui se cumule, en pratique.

Le coût de maintenance tombe à quasiment zéro. Pas de mises à jour de plugins. Pas de conflits de thème. Pas de « le site a cassé parce que Yoast a poussé une nouvelle version ». Si quelque chose casse (rare), git revert est à une commande de distance.

L’équation de coût bascule aussi. La facture de 220 $/mois de Webflow de la Partie 1 n’est pas une anomalie, c’est le tarif courant des plateformes pilotées par éditeur dès que tu passes à plusieurs sites ou plusieurs langues. Avec un stack AI-Native, cette ligne récurrente s’effondre jusqu’à l’hébergement (Vercel est gratuit ou quasi gratuit pour la plupart des sites marketing) plus le temps qu’il faut pour shipper un changement, qui se compte désormais en minutes au lieu d’heures.

Si tu veux faire le calcul pour ton propre site, j’ai construit un calculateur sur Wellosite qui compare le stack AI-Native à ta configuration Webflow ou WordPress actuelle -> wellosite.ch/calculator.

Le site devient un actif que l’équipe peut éditer. Pas un otage d’un set de compétences CMS. Pas un otage de la personne qui connaît assez bien Webflow pour shipper. Tout le site vit en markdown, en composants et en un design system serré. Quiconque peut décrire ce qu’il veut peut le modifier.

Partie 7 : Ce que ce N’est PAS

Quelques mises au point honnêtes. Ce n’est pas une solution miracle, et prétendre le contraire gâche ton temps et le mien.

• Ce n’est pas « l’IA a généré tout mon site ». Le jugement, la discipline de design, le goût, la stratégie de marque, tout ça reste sur tes épaules. L’IA est le levier. C’est toi qui restes l’opérateur.
• Tous les sites Webflow n’ont pas besoin de quitter Webflow demain. Si ton équipe est heureuse, que ta friction d’éditeur est faible et que le coût te va, reste. La migration vaut le coup quand la taxe est réelle.
• La boucle de dev a sa propre courbe d’apprentissage. Savoir écrire un bon prompt, structurer un CLAUDE.md, décomposer une page en composants, c’est une compétence. Elle s’apprend plus vite que la maîtrise d’un CMS, mais elle n’est pas gratuite.
• Les sites très dynamiques ont quand même besoin d’une vraie architecture. L’e-commerce avec des milliers de SKU, les systèmes de réservation complexes, les apps temps réel, l’AI-Native est un excellent fit pour les sites marketing, les sites vitrines, les blogs, les pages de comparaison, les pages de destination. Ce n’est pas une solution miracle pour les dashboards SaaS ou les plateformes de commerce transactionnel.

Si ton site est surtout du contenu, surtout du marketing, surtout de l’informationnel, surtout le genre de chose que tu construirais sur WordPress ou Webflow aujourd’hui, cette approche est faite pour toi.

Partie 8 : Pourquoi je parie Kai sur ce stack

On a fait un choix délibéré tôt dans le build de Kai : hirekai.ai est lui-même un site web AI-Native. Pas parce que ça fait cool. Parce que le produit lui-même est construit autour de l’IA, et que le site marketing devrait tourner sur la même logique.

La boucle qui se cumule que j’ai décrite en Partie 4, base de connaissances + transcriptions de réunions + design system + pages générées par Claude, c’est exactement la façon dont le produit Kai évolue ET dont le site marketing de Kai évolue. Chaque appel client affûte à la fois le produit et le messaging. La KB est le tissu conjonctif.

Et Kai, c’est ce qui boucle la boucle de bout en bout :

• Kai enregistre les réunions (internes et externes).
• Kai produit les transcriptions.
• Kai est dans la boîte de réception, en train de faire remonter les patterns sur lesquels il vaut la peine d’agir.
• La KB stocke la vérité.
• Claude lit la KB et shippe la page.

Tout le stack se compose. Tu n’as pas à l’assembler depuis cinq fournisseurs. Tu le construis une fois, et il se renforce chaque semaine.

Si cette boucle te paraît utile pour la façon dont tu mènes ton travail, Kai est l’assistant qu’on est en train de construire.

→ Rejoins la waitlist sur hirekai.ai/waitlist.

On est en accès anticipé. La première vague part bientôt.

Conclusion

Ce n’est pas de la théorie. Chaque site mentionné ici est en ligne. Chaque chiffre vient d’une vraie migration. La facture Webflow de la Partie 1 est notre vraie facture.

Le changement se résume simplement :

• WordPress est une taxe de maintenance.
• Webflow est une taxe d’éditeur et une taxe de coût.
• L’AI-Native n’est ni l’une ni l’autre.

Si tu fais tourner un site marketing, un site vitrine, un blog ou un portfolio, et que tu ressens l’une ou l’autre de ces taxes, la migration mérite un examen sérieux.

Si tu veux que je le fasse pour ton site, c’est exactement à ça que sert Wellosite.

À propos

Je dirige le growth chez Morgen. On construit Kai, un assistant exécutif IA. Wellosite est l’agence que j’ai lancée pour migrer les sites clients de la même façon qu’on a construit le site de Kai.

Suis l’aventure :

• LinkedIn : Lambert Le Court De Beru
• Kai
• Wellosite
• Morgen

Merci d’avoir lu

Si c’était utile, partage-le avec quelqu’un qui perd discrètement ses week-ends à cause des mises à jour de plugins ou qui fixe une facture Webflow à 220 $ en se demandant s’il existe une autre voie.

Des questions ? Écris-moi sur LinkedIn. Avec plaisir pour aider.