Créer un site web automatisé par des agents IA en 2026 : la méthode complète

En 2026, un site d'entreprise fait bien plus que communiquer. C'est une machine à capter des visiteurs humains via Google, à se faire citer par ChatGPT, Perplexity et Google AI Overviews, et à se mettre à jour elle-même. Gartner estime que le trafic organique vers les sites commerciaux chutera de 25 % d'ici fin 2026 sous l'effet du report des recherches vers les moteurs génératifs. Dans le même temps, un contenu mis à jour dans les trois derniers mois est cité deux fois plus souvent par les IA qu'un contenu figé.

Les outils qui ont dominé la décennie 2015-2025 (WordPress, Webflow, Framer) ont été pensés pour des designers et des équipes marketing, bien avant que les agents IA n'entrent dans le jeu. Ils commencent à montrer leurs limites dès qu'on veut industrialiser la production de pages, automatiser les mises à jour ou brancher un LLM sur le code source.

Ce guide présente la méthode mise en place chez Lonestone pour lonestone.io et rolebase.io, puis appliquée aux sites de plusieurs clients. Elle repose sur un socle simple (Astro + MDX + Tailwind), une cohérence pilotée par un fichier AGENTS.md, une bibliothèque de skills pour automatiser les tâches répétitives, et une orchestration via Claude Code ou OpenClaw. Le site devient rapide, durablement bien référencé, peu coûteux à faire vivre, et n'importe qui peut le faire évoluer en discutant avec un agent IA.

Les trois changements qui touchent les sites en 2026

La recherche passe par les moteurs génératifs

Les internautes tapent de moins en moins de requêtes dans Google pour lire une page de résultats. Ils posent leurs questions à ChatGPT, Perplexity, Claude ou Gemini, et lisent une réponse synthétique qui cite quelques sources. Google lui-même intègre désormais AI Overviews en haut des SERP, et a lancé en 2026 un AI Mode où la réponse générée prend le pas sur les dix liens bleus classiques.

Cette bascule ouvre deux chantiers. Le SEO classique reste nécessaire, parce que les moteurs IA s'appuient en grande partie sur l'index de Google pour choisir qui citer. Le GEO (Generative Engine Optimization) s'y ajoute pour être repris dans les réponses générées. Les pages qui cumulent données structurées JSON-LD, FAQ bien rédigées, statistiques, citations et fraîcheur sont 3,2 fois plus citées par les IA que les pages équivalentes sans structuration.

Les agents IA entrent dans le workflow de production

Claude Code, Cursor, OpenCode et les autres agents de code ont cessé d'être des gadgets pour devenir des membres à part entière de l'équipe web. Un rédacteur peut désormais écrire un article en discutant avec un agent, un designer peut convertir une maquette Figma en composant Astro+Tailwind via un serveur MCP, un chef de projet peut demander à un agent de générer 40 landing pages à partir d'un tableau CSV.

Pour que ces agents produisent un résultat aligné sur la charte de l'entreprise, il leur faut deux choses : un code source lisible, textuel et versionné, où chaque page est un fichier qu'on ouvre et modifie sans passer par une interface propriétaire, et un prompt de contexte clair qui décrit les règles du projet. Les CMS classiques offrent rarement l'un ou l'autre.

Le coût d'un site doit baisser

À budget constant, les entreprises attendent plus de pages, plus de langues, plus de variantes commerciales, plus de fréquence éditoriale. Les tarifs des plateformes propriétaires, facturés au siège, à la langue et à la collection, tirent dans le sens inverse. Un Webflow multilingue avec plusieurs utilisateurs dépasse vite 100 € par mois, et chaque nouvelle page publiée consomme un quota. Sur un site statique hébergé sur Netlify ou Cloudflare Pages, la même page coûte près de zéro à publier et à servir.

Webflow et Framer : leur apport et leurs limites

La phase Webflow puis Framer chez Lonestone

Avant la bascule actuelle, les sites Lonestone sont passés par Webflow, puis Framer. Cette trajectoire est familière à beaucoup d'agences et d'équipes produit. Webflow a ouvert une grande liberté de conception sans code. Framer a poussé encore plus loin l'ergonomie pour les designers, avec une IA intégrée capable de générer une ébauche de site à partir d'une phrase.

Ces outils ont bien servi l'époque. Ils ont permis à des designers d'intégrer eux-mêmes leurs maquettes, de publier sans passer par un développeur, et d'obtenir un rendu visuel très maîtrisé. Pour des sites vitrines simples et des landing pages ponctuelles, ils restent des options valables.

Cinq blocages pour l'automatisation

Dès qu'on cherche à piloter un site avec des agents IA, plusieurs problèmes apparaissent.

L'absence de code source accessible. Webflow et Framer gardent le code sur leurs serveurs. Les API permettent de lire et écrire des entrées de CMS, mais pas de composer une page complète programmatiquement. Demander à un agent "ajoute une section témoignage dans cette landing page, puis crée trois variantes A/B" reste hors de portée, puisqu'il n'a accès ni au DOM ni aux composants.

Les coûts qui grimpent avec l'usage. Un site de blog actif avec plusieurs rédacteurs, plusieurs langues et des dizaines de landing pages commerciales atteint vite un forfait Business à 49 $ par mois chez Webflow, plus un coût par siège, plus des plugins tiers pour l'internationalisation. L'addition annuelle dépasse 2 000 € pour des fonctionnalités qu'un site statique rend gratuitement.

Le vendor lock-in. Migrer un site Webflow ou Framer vers une autre plateforme demande une réécriture quasi complète. L'export des designs reste approximatif, le CMS se transporte mal, les animations propriétaires restent sur place. À cinq ans, ce coût de sortie latent est un risque stratégique pour l'entreprise.

Le décalage avec les agents IA. Les serveurs MCP (Model Context Protocol) de Figma, GitHub, Netlify ou Linear rendent un workflow fluide quand le code est local et textuel. Ils deviennent anecdotiques quand le site vit dans une interface propriétaire dont l'API ne couvre qu'une fraction des actions possibles.

Les designers eux-mêmes s'y retrouvent. La surprise chez Lonestone est venue de là. Passer à Astro + Tailwind leur a donné plus de latitude : ils promptent désormais un agent IA pour modifier une section ("élargis la hero, assombris le fond, ajoute une animation de scroll") ou utilisent un serveur MCP pour convertir une maquette Figma en composant Astro+Tailwind directement dans le code. Ils y gagnent du temps et du contrôle.

On vous prévient, la suite entre dans le détail technique. Monter un site un tant soit peu ambitieux garde toujours une part de complexité (Lonestone est là pour la gérer !). Rassurez-vous, l'objectif reste un site facile à faire vivre au quotidien. AstroCMS couvre l'édition courante, et pour tout le reste (modifier un texte, ajuster un design, ajouter une section), il suffit d'en discuter avec un agent IA.

L'architecture cible : statique, MDX, composants Astro

Pourquoi un site statique

Un site statique est un site dont toutes les pages sont pré-générées en HTML au moment du build, puis servies par un CDN. À la différence d'un site SSR (WordPress, site PHP classique), aucun serveur ne calcule la page à la volée pour chaque visiteur. C'est la même approche que celle qu'on décrit dans le guide Jamstack.

Les pages s'affichent en 200 à 500 ms au first paint, là où les sites Webflow ou WordPress flottent autour de 1,5 à 3 secondes. Le score Core Web Vitals dépasse 95 sur 100. La surface d'attaque se réduit au strict minimum, puisque le serveur applicatif et la base de données disparaissent. Et le coût d'hébergement tend vers zéro : la plupart des sites Lonestone tournent sur le free tier Netlify ou Cloudflare Pages, soit 0 € par mois jusqu'à plusieurs centaines de milliers de visites.

60 % des sites Astro obtiennent une note "Good" à Core Web Vitals, contre 38 % pour les sites WordPress ou Gatsby mesurés par Chrome UX Report. Sur le même contenu, Astro expédie 90 % moins de JavaScript qu'un site Next.js équivalent.

Pourquoi Astro précisément

Astro est le meilleur compromis pour un site de contenu moderne. Il lit nativement des fichiers MDX comme source de contenu, il supporte les composants Astro, React, Vue, Svelte, Solid dans le même projet, il gère les images, les redirections, les sitemaps, le fichier llms.txt et les données structurées sans configuration lourde. Astro a été racheté par Cloudflare en janvier 2026, ce qui consolide sa place dans l'écosystème web.

Pour les besoins plus interactifs (configurateur, calculette, formulaire complexe), les "islands" d'Astro embarquent un composant React ou Vue hydraté sur une page qui reste 100 % statique. Chez Lonestone, ce mécanisme sert aux applications web plus dynamiques greffées sur le site principal.

Le contenu en MDX, séparé des composants d'affichage

Le Markdown est un format d'écriture ultra-simple inventé en 2004 pour rédiger du texte structuré sans ouvrir un logiciel spécialisé. Les titres commencent par des dièses (# pour un grand titre, ## pour un sous-titre), les liens s'écrivent [texte](adresse), les listes commencent par un tiret. Le résultat ressemble à un texte ordinaire, lisible tel quel dans n'importe quel éditeur de texte. C'est le format utilisé par GitHub, Notion, Discord, Slack pour leurs contenus, et par la plupart des blogs techniques.

Le MDX (Markdown eXtended) ajoute une seule capacité au Markdown : appeler des composants visuels au milieu du texte. Concrètement, voici un fichier .mdx :

---
title: "Notre offre Starter"
description: "L'offre d'entrée pour lancer son premier produit."
date: 2026-04-22
tags: [offres, starter]
---

## Notre offre

Un texte d'introduction ordinaire, écrit comme dans un document Word.

![Une photo d'équipe](./photo-equipe.jpg)

Voici les points clés :

- Premier avantage
- Deuxième avantage
- Troisième avantage

<Pricing plan="Starter" price="29 €" />

<Callout type="info">
Un expert Lonestone suit l'équipe pendant les trois premiers mois. Elle convient particulièrement aux équipes qui lancent leur premier produit.
</Callout>

Le bloc en haut du fichier, délimité par deux lignes de tirets, s'appelle le frontmatter. C'est un petit formulaire au format YAML qui porte les métadonnées de la page : titre affiché dans l'onglet du navigateur, description lue par Google et par les moteurs IA, date de publication, tags, auteur, miniature. Chaque type de page définit les champs qu'il attend, certains requis, d'autres optionnels. Il reste séparé du corps de l'article, et c'est lui qui alimente automatiquement les listes de pages, les flux RSS, les balises Open Graph et les données structurées. Les champs prévus pour chaque type de page (article de blog, page solution, page offre) sont vérifiés à la compilation pour éviter les oublis.

Sous le frontmatter, on reconnaît le texte ordinaire (les titres, les paragraphes, les listes, les images) et, au milieu, deux formes d'appels à des composants. Certains prennent uniquement des propriétés (le composant <Pricing> reçoit son plan et son prix comme attributs). D'autres enveloppent du contenu riche (le composant <Callout> reçoit du texte rédigé entre sa balise ouvrante et sa balise fermante, et le met en forme avec un encadré coloré). Chaque composant est écrit une fois puis réutilisé dans toutes les pages qui en ont besoin : un bouton stylisé, une grille de tarifs, un carrousel de témoignages, une FAQ dépliable, un tableau comparatif, un bloc d'alerte.

Les composants restent à la portée des équipes non techniques. Les grands modèles de langage actuels (Claude, GPT, Gemini) maîtrisent MDX et Astro, et peuvent écrire ou modifier un composant à partir d'une simple description en langage naturel, d'une capture d'écran ou d'une maquette Figma. Un chef de projet ou un rédacteur peut ainsi demander à un agent "crée-moi un bloc de comparaison à trois colonnes" ou "ajoute une option d'animation à ce composant", et récupérer un composant Astro propre, prêt à être utilisé dans n'importe quelle page. Le designer et le développeur restent utiles pour les choix structurants et la relecture, mais la création des composants courants devient accessible à toute l'équipe.

Un fichier MDX est du texte, tout simplement. Un rédacteur peut l'ouvrir dans n'importe quel éditeur, un agent IA peut le lire et le modifier comme un document Word, et Git peut le versionner ligne par ligne. On combine la simplicité d'un article Notion ou WordPress avec la puissance d'un design system professionnel, sans jamais passer par une interface propriétaire.

Chaque page du site, chaque article de blog, chaque landing produit vit dans un fichier .mdx de ce type. Cette séparation entre le contenu (ce qui est dit) et l'affichage (comment c'est rendu) a trois vertus.

Les agents IA lisent et écrivent sans frottement. Un LLM peut parcourir le fichier, en extraire la structure, en modifier une partie, ajouter des liens internes, insérer un composant d'affichage supplémentaire. Le fichier se suffit à lui-même, là où un CMS impose une API, un schéma propriétaire et des quotas d'appels.

La cohérence visuelle est forcée par les composants. Les équipes content appellent <Advantages>, <FAQ>, <Features>, dont le rendu est géré une fois pour toutes par le design system, plutôt que d'écrire des balises et des classes au cas par cas. Un changement de charte graphique se propage automatiquement à tout le site.

Le versioning vit dans Git. Chaque modification de contenu passe par un commit. On sait qui a changé quoi, quand, pourquoi. On peut ouvrir une pull request pour une relecture. On peut publier une version préliminaire sur une branche pour recueillir des retours avant mise en ligne.

Le CMS pour les non-techniques

Pour que les équipes content, marketing ou communication restent autonomes sans ouvrir un éditeur de code, Lonestone maintient un CMS open source qui lit directement les fichiers MDX et commit vers Git : AstroCMS. Il propose un éditeur visuel MDX, des formulaires de frontmatter générés automatiquement à partir des schémas Zod, un navigateur de collections, l'insertion de composants Astro dans le texte, et une intégration optionnelle avec Claude Code pour la rédaction assistée. Il fonctionne sans base de données, puisque la source de vérité reste les fichiers versionnés dans Git.

Pour démarrer vite avec une base propre, le template Astro de Lonestone embarque déjà le socle complet : Astro, Tailwind, MDX, collections typées Zod, sitemap automatique, open graph, hreflang, JSON-LD, table des matières, miroir markdown de chaque page, fichier llms.txt, navigation mobile clonée et mode multilingue. AstroCMS est préinstallé. Il reste à remplir le contenu et à adapter la charte graphique.

Le pilotage par un fichier AGENTS.md

Un prompt unique qui aligne tous les agents

Dès qu'on travaille avec des agents IA, la cohérence devient le sujet numéro un. Un agent bien prompté produit un résultat excellent, un agent mal prompté produit du texte générique qu'il faut réécrire. La bonne pratique qui s'est imposée en 2026 consiste à placer à la racine du projet un fichier AGENTS.md qui décrit au LLM tout ce qu'il doit savoir pour travailler comme un membre de l'équipe. Ce nom de fichier est devenu le standard commun à la plupart des agents de code (Claude Code, Cursor, OpenCode, Codex, Aider, Cline).

Un bon AGENTS.md ressemble à un document d'onboarding. On y trouve notamment la stack technique (Astro, Tailwind, TypeScript, React pour les composants complexes, Netlify), les conventions de contenu (français, pas de tirets cadratins, formulations positives), la structure des dossiers (src/content/ pour les collections, src/components/ pour les composants), les règles de rédaction pour les FAQ (questions formulées comme un prospect, réponses à la troisième personne pour être réutilisables par un chatbot IA), les conventions de design (utiliser Tailwind).

N'importe quel agent IA qui ouvre ce repo respecte alors la charte immédiatement. Un nouveau rédacteur qui prompte Claude pour écrire un article obtient un résultat aligné sur les 73 articles existants. Un designer qui convertit une maquette Figma en composant Astro obtient un rendu cohérent avec le design system.

Symlinks pour les agents qui utilisent un autre nom

La plupart des agents majeurs (Cursor, Cline, Copilot, Codex, Aider) lisent directement AGENTS.md. Claude Code, lui, cherche en priorité un fichier CLAUDE.md à la racine. Plutôt que de dupliquer le contenu, on garde AGENTS.md comme source unique et on ajoute un symlink pour les cas particuliers :

ln -s AGENTS.md CLAUDE.md

Si la charte évolue, on met à jour AGENTS.md et tous les outils suivent automatiquement. On ajoute un symlink supplémentaire au cas par cas si un nouvel agent utilisé par l'équipe attend un autre nom.

Un fichier AGENTS.md qui se lit facilement

Il fait en général 100 à 300 lignes, structuré en sections courtes. On y place des règles qui se vérifient : "tous les titres doivent passer sous 60 caractères" ou "les pages solutions vont dans src/content/solutions/". On y place des exemples concrets : "au lieu d'écrire 'ne dépend pas', écrire 'reste indépendant'". On y évite les paragraphes philosophiques et on s'en tient aux informations que l'agent doit avoir sous la main.

Les skills pour industrialiser la production

La définition d'un skill

Un skill est un ensemble d'instructions et d'outils qu'un agent peut invoquer pour accomplir une tâche précise. Concrètement, un skill est un dossier qui contient un fichier SKILL.md (la procédure à suivre, étape par étape), mais aussi, au besoin, des scripts exécutables, des gabarits de texte, des exemples de bon résultat ou des documents de référence que l'agent peut lire pour ne pas réinventer à chaque fois. Ce format encode à la fois la procédure, les outils à employer et le résultat attendu.

Un standard ouvert (Agent Skills) émerge autour de ce format, mais l'emplacement du dossier parent n'est pas encore unifié : Claude Code lit .claude/skills/, Cursor lit .cursor/skills/, Codex lit .codex/skills/, et d'autres outils ont leur propre convention. Cursor sait déjà découvrir les dossiers de Claude Code, Cursor et Codex pour faciliter le passage d'un agent à l'autre. La même logique que pour l'AGENTS.md s'applique : on maintient un seul dossier canonique et on crée les symlinks nécessaires selon les agents utilisés par l'équipe. L'équipe définit une fois la procédure et l'agent la rejoue à chaque demande.

Au gain de temps s'ajoute une qualité constante. Un skill qui rédige des articles de blog oblige l'agent à vérifier que le titre fait moins de 60 caractères, que la meta description tient en 160 caractères, que le keyword principal apparaît dans les 100 premiers mots, que les liens internes pointent vers des pages existantes. Ce sont des contrôles qu'un humain pressé oublie, qu'un agent exécute systématiquement.

La bibliothèque de skills Lonestone

Sur le repo du site lonestone.io, une quinzaine de skills tournent en production, notamment :

• write-blog-post fait la recherche web, analyse les rapports SEO internes, rédige l'article MDX complet, génère l'illustration et la miniature, et vérifie les longueurs de balises.
• seo est le point d'entrée et dispatche vers les scripts de collecte de données (rank tracking, keyword opportunities, competitor analysis, on-page audit, backlinks, SERP features, content performance, dashboard).
• seo-optimize-page audite une page précise et applique les optimisations (balises, maillage, FAQ, internal linking).
• seo-content-plan croise les rapports et propose un plan éditorial avec priorités, mots-clés cibles et outlines.
• update-evergreen parcourt la liste des pages evergreen et lance pour chacune un sous-agent qui recherche les changements récents sur le web et met à jour le contenu.
• research-and-update mène une recherche ciblée pour rafraîchir un contenu précis.
• generate-social-preview capture la preview OG à 1200x630 via Playwright.
• generate-image génère les illustrations d'articles à partir d'un prompt.
• replicate-webpage reproduit une page web existante à partir d'un screenshot, ce qui s'est avéré très utile pour migrer depuis Framer.
• page-solution crée une page commerciale en respectant le schéma des collections solutions.

Chaque skill est exécutable à la demande (/write-blog-post "sujet") ou orchestré dans une routine. Pour les membres de l'équipe, la barrière technique est nulle : ils promptent l'agent comme ils parleraient à un collègue.

Un skill est versionné dans le repo

Quand la méthode évolue (nouveau format de frontmatter, nouvelle règle SEO, nouveau ton éditorial), on met à jour le skill et tous les membres de l'équipe, humains et agents, partent de la nouvelle version la fois suivante, sans formation à refaire ni variante personnelle qui traîne.

Le pilotage par la data : DataForSEO, GSC, Analytics

Trois sources croisées

Un site ne se pilote plus à l'intuition. Les décisions éditoriales chez Lonestone s'appuient sur :

DataForSEO fournit les positions SERP, le volume de recherche, la difficulté concurrentielle, les mots-clés de la concurrence, les SERP features (featured snippet, People Also Ask, AI Overview). Les API DataForSEO couvrent le rank tracking quotidien, l'exploration de mots-clés par intention, les audits on-page via instant_pages, le profil de backlinks, les questions extraites de Google. Pour un site commercial, c'est la première source pour repérer les opportunités.

Google Search Console donne la vérité du trafic entrant : impressions, clics, CTR, positions moyennes, requêtes exactes que Google associe à chaque page. GSC a ajouté en 2026 des dimensions de filtrage par type d'apparition (AI Overviews, featured snippets) et une configuration en langage naturel. On peut désormais demander au GSC : "montre-moi les requêtes mobiles à fort volume mais faible CTR sur les 28 derniers jours".

Google Analytics ou Umami apporte la donnée d'engagement : durée de session, pages vues par visite, taux de rebond, conversions. Quand on la croise avec GSC, cette donnée sépare les pages qui rankent sans convertir de celles qui convertissent sans ranker encore. Chez Lonestone, le choix se porte sur Umami plutôt que sur Google Analytics : Umami fonctionne sans cookies (donc sans bandeau de consentement à afficher), son interface est nettement plus simple à prendre en main et elle est auto-hébergée en France, ce qui simplifie la conformité RGPD et garde les données d'audience sous contrôle. Le branchement sur un site Astro se fait en quelques minutes.

L'analyse cross-sources

Le skill seo:content chez Lonestone croise GSC et Umami page par page. Les pages qui apparaissent en haut de GSC mais en bas d'Umami sont des candidates à la refonte (elles attirent mais n'engagent pas). Les pages avec un bon engagement mais peu de visibilité SEO sont des candidates à l'optimisation (le contenu convainc, il manque le trafic). Chaque semaine, un dashboard résume les quick wins prioritaires.

La barrière à l'entrée est faible. DataForSEO facture à la requête (environ 0,0015 $ par requête SERP), GSC est gratuit via API, Umami tourne sur un petit serveur ou une version cloud à quelques euros par mois.

Rédaction et mise à jour automatisées

La rédaction assistée d'articles de blog

Un skill write-blog-post en production chez Lonestone orchestre quatre étapes :

1. Il fait une recherche web ciblée sur le sujet, les statistiques récentes et les prises de position d'experts.
2. Il lit les pages internes connexes pour repérer les opportunités de maillage et écarter les doublons.
3. Il explore les rapports SEO pour récupérer les mots-clés sous-exploités et les questions People Also Ask.
4. Il rédige au format Lonestone (titre sous 60 caractères, description sous 160, takeaways en frontmatter, liens internes, FAQ, structure respectant l'AGENTS.md).

Le rédacteur humain n'a plus qu'à relire, corriger les formulations marketing, ajouter des anecdotes clients. Le temps passé sur un article est divisé par 5 à 10 pour une qualité supérieure à la moyenne des articles écrits en mode artisan.

Les pages alternatives et les landing pages

Au-delà du blog, deux types de pages commerciales profitent de l'automatisation :

Les pages alternatives portent sur "alternative à Salesforce", "alternative à Webflow" ou "alternative à ClickUp". Un skill dédié génère ces pages à partir d'un brief produit et d'une analyse de la concurrence. Chaque page cible un mot-clé transactionnel à fort potentiel ("alternative à X") avec une intention claire, celle d'un prospect qui cherche à quitter un outil propriétaire pour une solution plus adaptée.

Les landing pages commerciales se déclinent par secteur, par persona ou par cas d'usage. Le skill page-solution chez Lonestone génère une page complète en respectant le schéma des collections Astro : hero avec tag, composants d'avantages, section pricing, FAQ, CTA, social preview. Le designer et le CMO relisent, ajustent, publient.

Programmatic SEO, version 2026

Le SEO programmatique consiste à produire des centaines de pages uniques à partir d'un jeu de données et d'un template. La version 2026 y ajoute l'IA pour différencier chaque page en profondeur.

Chez Lonestone, le pattern typique combine trois ingrédients : un fichier YAML ou CSV qui contient les données (liste de villes, de technologies, de secteurs), un template Astro qui génère la structure commune, et un skill qui enrichit chaque page avec une introduction spécifique générée par un LLM, des cas d'usage contextualisés, des liens internes variés et des métadonnées uniques. On obtient ainsi 200 pages "agence développement web à Nantes", "à Lyon", "à Bordeaux" et ainsi de suite, différenciées page par page plutôt que dupliquées, qui captent chacune des requêtes longue traîne.

Le coût marginal par page est de l'ordre de quelques centimes en tokens LLM, plus le coût de build et de stockage (négligeable sur un CDN statique). Un équivalent sur Webflow, à ce volume de 200 pages, atteindrait rapidement les 1 000 € par mois en licences et en frais par collection.

La mise à jour du contenu evergreen

Le mot evergreen désignait à l'origine un contenu "indémodable", qu'on publie une fois et qui reste pertinent pendant des années sans qu'on ait besoin d'y toucher : un guide de fond, une définition, une page pilier. Avec l'arrivée des moteurs IA et leur prime à la fraîcheur, la définition a évolué. Chez Lonestone, on parle désormais d'evergreen pour qualifier un contenu vivant qui reste à jour en continu grâce aux routines automatisées : les faits, les chiffres, les versions logicielles, les tarifs, les réglementations cités dans la page sont rafraîchis à chaque changement pertinent, pendant que la structure et l'angle éditorial restent stables.

Un guide, une page pilier ou une FAQ perdent leur visibilité dès qu'ils vieillissent. Une page non modifiée depuis 14 jours subit en moyenne 23 % de citations en moins dans les IA qu'un contenu frais. Une page mise à jour dans les trois derniers mois est citée deux fois plus souvent qu'une page non maintenue.

Le skill update-evergreen chez Lonestone lit un fichier EVERGREEN.md qui liste les pages à maintenir, puis lance pour chacune un sous-agent :

1. Le sous-agent lit la page actuelle.
2. Il identifie les sujets susceptibles d'avoir évolué (tarifs cités, versions de logiciels, statistiques, réglementations).
3. Il fait de la deep research sur chaque sujet.
4. Il met à jour uniquement les faits qui ont changé, sans réécrire les parties encore valides.
5. Il met à jour la date update du frontmatter.

Sur un site de 73 articles comme lonestone.io, cette routine tourne en quelques dizaines de minutes et maintient l'ensemble du corpus à jour. Sans automatisation, c'est plusieurs semaines de travail manuel qu'aucune équipe n'a le temps de faire sérieusement.

Le maillage interne géré par l'agent

Quand un agent IA écrit ou met à jour une page, il explore spontanément le reste du site avant de rédiger. Il lit les articles connexes, les pages solutions, les offres, les cas clients, et tisse au fil du texte des liens internes pertinents : un article sur le SEO qui renvoie vers l'offre correspondante, un guide produit qui met en avant un cas client, une FAQ qui pointe vers un autre article qui creuse la réponse.

Trois bénéfices en découlent :

• Le netlinking SEO s'enrichit sans effort humain. Chaque nouveau contenu renforce l'autorité des pages piliers vers lesquelles il pointe, et l'agent écarte les liens cassés comme les ancres génériques.
• Les parcours de conversion se construisent tout seuls. Un visiteur qui arrive par un article de blog est progressivement orienté vers les pages commerciales par des liens contextuels glissés dans le fil du texte, plutôt que par un bandeau collé en fin d'article.
• La cohérence globale du site se maintient. Les messages clés, les formulations, les positionnements reviennent page après page sans duplication, parce que l'agent s'appuie sur la charte et sur les pages existantes plutôt que de réinventer à chaque fois.

Un humain peut tenir cette discipline sur 10 articles. Au-delà de 50, l'oubli et l'incohérence s'installent. Un agent maintient la même rigueur sur 1 000 pages.

Le GEO pour être cité par les IA

Les signaux qui comptent pour les moteurs génératifs

ChatGPT, Perplexity, Claude, Google AI Overviews ne lisent pas le web comme Google classique. Ils favorisent des signaux précis quand ils choisissent quoi citer :

• Des données structurées JSON-LD bien implémentées (Article, FAQPage, HowTo, Organization, Product). Les pages avec un schema propre sont citées 3,2 fois plus souvent, et entre 65 % et 71 % des pages citées par Google AI Mode et ChatGPT en comportent.
• Une structure de titres claire, avec un H1 unique, des H2 et H3 logiques et des paragraphes denses mais courts (40 à 60 mots pour les blocs de réponse).
• Des statistiques et des citations. Les pages qui citent des chiffres sourcés ou des experts gagnent 30 à 40 % de visibilité IA selon les travaux de recherche de Princeton.
• Une FAQ explicite. Les questions formulées comme un prospect, avec des réponses autonomes réutilisables hors contexte, sont très prisées par les moteurs IA.
• Un fichier llms.txt, index dédié aux LLM qui liste les pages importantes et leur version markdown. Le template Astro Lonestone le génère automatiquement.
• De la fraîcheur, avec une date de mise à jour récente et des modifications substantielles (20 à 30 % du contenu) plusieurs fois par an.

La FAQ, premier levier de citation par les IA

La section FAQ est un investissement à très haut rendement. Chaque question est une opportunité d'être cité par un moteur IA quand un utilisateur pose cette même question. Chez Lonestone, la règle de rédaction des FAQ est stricte : les réponses sont rédigées à la troisième personne ("Lonestone intervient" plutôt que "nous intervenons"), sans formulations marketing, avec des liens internes pertinents, et compréhensibles hors contexte. Un chatbot IA doit pouvoir reprendre la réponse telle quelle.

Le fichier llms.txt

Le fichier /llms.txt est devenu en 2026 l'équivalent du sitemap.xml pour les LLM. Il liste les pages importantes du site, avec pour chacune une URL vers sa version markdown brute (sans design, sans JavaScript), que l'IA peut parser efficacement. Sur le template Astro Lonestone, ce fichier est auto-généré au build à partir des collections de contenu, avec un en-tête qui présente le site et son périmètre.

Les assets visuels : miniatures, illustrations, previews et screenshots automatisés

Les miniatures et illustrations d'articles

Chaque article de blog a besoin d'une miniature (la vignette qui apparaît dans la grille du blog, dans les listes d'articles associés, dans les aperçus de partage) et parfois d'une ou deux illustrations intégrées au texte pour expliquer une comparaison, un processus ou un concept abstrait. Les produire à la main demanderait du temps de designer sur chaque article.

Un skill generate-image délègue cette production à un modèle d'image (Nano Banana Pro, Imagen, Midjourney via API). L'agent qui rédige l'article identifie les 1 à 3 endroits où une illustration aide la compréhension, écrit lui-même les prompts adaptés au ton visuel de la marque (fond sombre diffus, palette dusty pastel, accent jaune, style éditorial légèrement 3D), et lance la génération. Les images atterrissent directement à côté du fichier MDX de l'article, versionnées dans Git, et prêtes à être référencées dans le contenu. Un article de blog standard se publie ainsi sans ouvrir Photoshop ni briefer un designer.

La miniature suit la même logique, avec un format spécifique (1200x630) et des contraintes plus strictes sur la lisibilité à petite taille. Le prompt, affiné une fois dans le skill, produit des miniatures cohérentes visuellement d'un article à l'autre, même quand une dizaine de rédacteurs ou d'agents différents interviennent.

Les modèles d'image récents, et en particulier Nano Banana Pro, ont franchi un cap sur les visuels complexes. Ils produisent désormais des schémas, des diagrammes et des infographies soignés à partir d'un simple prompt descriptif (une architecture technique, un parcours utilisateur, un comparatif visuel). Un visuel qui demandait quelques heures à un illustrateur tient en une minute, avec un rendu exploitable directement.

Pour les diagrammes plus structurés (arbres de décision, flux de données, organigrammes, séquences), une intégration Mermaid complète la génération d'image. Avec Mermaid, on décrit un diagramme directement en texte, dans un format que tous les grands LLM maîtrisent. L'agent peut ainsi écrire un bloc Mermaid dans le MDX, qui se rend en diagramme propre à la compilation, reste modifiable par n'importe quel membre de l'équipe, et se versionne ligne par ligne dans Git. Les deux approches se combinent : image générée pour les visuels artistiques, Mermaid pour les schémas précis qui doivent évoluer avec le contenu.

Les previews OG générées automatiquement

Chaque page commerciale (offres, solutions, métiers, technos) nécessite une image Open Graph de 1200x630 pixels. Générer ces images à la main prend du temps et produit des incohérences visuelles. Le skill generate-social-preview automatise la capture. Il prend un chemin de page en entrée, navigue via Playwright MCP sur la version locale du site, cache le header, force la première section à 100vh, met en pause les vidéos, et capture l'image au bon format.

Sur le site lonestone.io, la preview de chaque offre, solution, métier ou techno est ainsi régénérée dès qu'un élément visuel change. La marque reste cohérente à chaque partage LinkedIn, X, Slack ou WhatsApp.

Les screenshots d'interface pour les articles

Pour les articles techniques qui présentent une interface (un dashboard, un éditeur, un formulaire), le skill équivalent lance Playwright sur une URL cible et capture automatiquement le rendu. Les screenshots vivent à côté du MDX, sont versionnés dans Git, et se régénèrent quand l'UI évolue.

L'orchestration : Claude Code routines et OpenClaw

Les routines Claude Code

Claude Code intègre des "routines" (scheduled tasks) et des fonctions de "dispatch" (délégation à des sous-agents spécialisés) pour lancer un skill à intervalle régulier ou en parallèle sans intervention humaine. Ces fonctionnalités ont d'abord émergé dans OpenClaw : Claude Code publie régulièrement de nouveaux ajouts pour combler les manques face aux runtimes agentiques plus matures, et les routines comme le dispatch en font partie. Exemples typiques chez Lonestone :

• Lundi 8h : seo:rank pour récupérer les positions de la semaine et alerter si un mot-clé prioritaire a chuté.
• Lundi 9h : seo:dashboard pour agréger les KPI et lister les opportunités de la semaine.
• Premier jour du mois : seo:keywords + seo:competitors + seo:serp + seo:content pour le bilan mensuel.
• Premier lundi du mois : update-evergreen pour rafraîchir tout le contenu pilier.
• Chaque publication d'article : audit seo:onpage immédiat sur la nouvelle URL.

OpenClaw pour un agent joignable depuis Slack ou Telegram

OpenClaw est un runtime agentique open source, auto-hébergé, qui se branche sur n'importe quel fournisseur de modèles (Claude, GPT, Gemini, Ollama en local, OpenRouter pour mixer plusieurs modèles). Son principal intérêt par rapport aux routines Claude Code est de transformer l'agent en compagnon permanent joignable depuis les canaux que l'équipe utilise déjà : Slack, Telegram, Discord, email. N'importe quel membre de l'équipe peut envoyer un message à l'agent ("publie la nouvelle version de l'article sur le SaaS", "regénère la preview de la page X", "ajoute une FAQ sur ce sujet") et recevoir le résultat dans la foulée, depuis son téléphone comme depuis son poste, sans terminal ni IDE à lancer. L'agent garde le contexte entre les échanges et peut demander des précisions, proposer un diff avant validation, ou déclencher une action sur le repo.

La compatibilité multi-fournisseurs ouvre aussi le choix du bon modèle pour chaque tâche. On peut utiliser Claude pour la rédaction longue et les décisions éditoriales, GPT pour une requête qui bénéficie du style de ses réponses, un modèle local Ollama pour les traitements confidentiels, et laisser OpenClaw arbitrer selon le skill invoqué. Avec un skill bien calibré, OpenClaw peut aussi déléguer une partie du travail à Claude Code pour les tâches de code qui profitent de son outillage spécifique.

Pour la plupart des équipes Lonestone, Claude Code suffit au démarrage. OpenClaw prend le relais quand les dirigeants ou les équipes content veulent pouvoir interagir avec le site depuis leur téléphone ou depuis Slack, ou quand l'équipe veut basculer librement d'un fournisseur de modèle à l'autre.

Comparatif des coûts

Un site statique + agents IA vs un CMS propriétaire

Ce comparatif porte sur un site vitrine multilingue de 80 pages, avec 3 éditeurs, un blog actif et des landing pages commerciales, sur un horizon de 12 mois.

Le scénario Astro descend à 0 € quand l'activité éditoriale ralentit ou s'arrête un temps : on coupe les abonnements IA et les API de données, et le site continue à tourner gratuitement ou presque sur le free tier de l'hébergeur. Côté plateforme propriétaire, les abonnements de base continuent d'être dus quoi qu'il arrive, sous peine de voir le site disparaître.

La différence se joue donc moins sur la facture d'abonnement que sur le temps humain, le coût marginal d'une nouvelle page, d'une nouvelle langue, d'une nouvelle version commerciale, et sur la capacité à laisser des agents IA piloter le site. En Astro, une landing page supplémentaire ou une mise à jour complète du corpus coûte quelques minutes de prompt et quelques centimes de tokens. En Webflow ou Framer, chaque ajout est une saisie manuelle qu'aucun agent ne sait automatiser.

Le time-to-market

Le gain principal se mesure en temps de publication. Publier un nouvel article sur un site automatisé demande 20 à 40 minutes de la part d'un humain (brief, relecture, ajustements, validation). Publier la même qualité à la main demande 4 à 8 heures. Sur une cadence d'un article par semaine, c'est plusieurs centaines d'heures gagnées par an, redéployables sur le positionnement produit, la vente, les retours clients.

Les sites qui tournent déjà ainsi

Lonestone.io est construit sur ce socle. Le site tourne sur Astro, Tailwind, MDX et React pour les composants complexes, il est hébergé sur Netlify, il ouvre AstroCMS à l'équipe, il fait tourner une quinzaine de skills Claude Code avec des routines hebdomadaires pour le SEO et mensuelles pour l'evergreen, et il croise DataForSEO, GSC et Umami pour la data. Il compte aujourd'hui 73 articles de blog, 7 solutions, 8 offres, 3 métiers et plusieurs landing pages programmatiques (technos, projets). Le coût total d'hébergement est inférieur à 50 € par mois. La cadence de publication est d'un article par semaine en moyenne, avec un rafraîchissement mensuel des contenus piliers.

Rolebase.io, le SaaS de gouvernance partagée maintenu par Lonestone, utilise la même architecture pour son site marketing. L'équipe y publie des articles de fond, des cas clients, des guides, avec les mêmes routines automatisées. Les deux sites partagent le même template de base et les mêmes skills, avec une charte graphique et un ton éditorial différents, chaque site étant piloté par son propre AGENTS.md.

Le rôle du designer et du dirigeant

Pour le designer

Le designer continue de concevoir les écrans sur Figma. Au lieu de recréer la maquette dans Webflow ou Framer, il prompte un agent IA via un serveur MCP Figma qui convertit directement la sélection en composant Astro+Tailwind. Les ajustements suivants se font soit en prompting, soit en ouvrant le composant et en éditant une ligne de classes Tailwind. Le designer garde son autonomie et fait l'économie d'un CMS de plus à apprendre.

Pour les animations complexes, qui étaient un argument fort de Framer, la combinaison Tailwind + Motion (Framer Motion pour React) + View Transitions natives d'Astro couvre désormais tous les cas d'usage. Le contrôle du code et des performances reste entier.

Pour le dirigeant

Pour un dirigeant qui n'entre pas dans le code, l'expérience devient fluide. Il ouvre AstroCMS ou discute avec un agent dans Slack. Il demande "ajoute une page pour notre nouvelle offre X", "met à jour l'article sur la cybersécurité avec les dernières stats", "génère une landing page alternative à ClickUp pour notre solution de gestion de projet". L'agent exécute, montre un diff, attend validation, publie. Les allers-retours avec une équipe externe disparaissent, pour des modifications qui demandaient encore 3 jours il y a deux ans.

Le dirigeant garde le contrôle stratégique : c'est lui qui valide les directions, les messages, les priorités. Il délègue l'exécution à l'agent, comme il la déléguerait à un collaborateur expérimenté, avec la différence que le collaborateur tourne 24h sur 24 et ne demande ni congés ni réunions.

Par où commencer concrètement

Pour une entreprise qui envisage cette bascule, la progression classique chez Lonestone tient en cinq étapes.

1. Cadrer les objectifs. On fixe le volume de contenus prévu, les langues cibles, les cibles SEO et GEO, le budget et l'équipe interne impliquée. Sans cadrage, la refonte devient vite un projet sans fin.

2. Partir d'un template éprouvé. Le template Astro Lonestone évite de redévelopper le socle (structure, SEO, multilingue, CMS, llms.txt). Une refonte classique est en ligne en 2 à 3 semaines au lieu de 2 à 3 mois.

3. Installer l'AGENTS.md et les premiers skills. On y pose la charte éditoriale, les conventions de composants, les règles de FAQ et les premiers skills de rédaction et d'optimisation SEO. C'est l'étape qui conditionne la qualité de tout ce qui suit.

4. Connecter la data. On branche DataForSEO, Google Search Console et Analytics ou Umami, puis un premier audit SEO complet repère les quick wins et dessine un plan éditorial sur 12 mois.

5. Lancer les routines. On démarre avec une routine hebdomadaire de rank tracking, puis des routines mensuelles de content plan et d'update evergreen. La montée en charge suit ensuite le rythme de l'équipe.

Chez Lonestone, un projet de ce type se chiffre entre 15 000 et 60 000 € selon le volume de contenu, la complexité du design et les automatisations voulues. Comparé à un Webflow multilingue avec agents externes, le retour sur investissement est atteint en 12 à 24 mois, avec un site qui reste la propriété complète du client.

Le nouveau standard du site d'entreprise

L'ère du CMS propriétaire maintenu à la main s'achève. Le site d'entreprise de 2026 est un système composé de trois briques : un socle statique lisible par les agents IA (Astro + MDX + Tailwind), un pilotage par prompt et par skills pour industrialiser la production sans perdre en qualité, et des routines d'automatisation qui maintiennent le site frais sans intervention humaine quotidienne. L'investissement initial est du même ordre qu'une refonte classique, mais le coût de possession sur 5 ans est nettement inférieur, et le site prend une avance durable sur les nouveaux canaux (GEO, IA génératives).

Pour un projet de refonte ou de création de site dans cette approche, l'équipe Lonestone intervient sur la création de site web sur mesure, le cadrage, la mise en production et la maintenance. Prenons un temps ensemble.