La stack technique Claude Code pour un site web agentique

Réponse rapide : un site web agentique est un site marketing que des agents d'IA aident à construire, à exploiter et à améliorer, tandis que des personnes valident les changements importants. La stack qui lui convient garde tout ce qu'un agent touche dans des fichiers qu'il peut lire : un framework de site statique comme Astro, un CMS headless dont les schémas sont dans le code comme Sanity, un hébergeur proposant des aperçus de déploiement et des fonctions planifiées comme Netlify, et Claude Code qui travaille via des pull requests.

La plupart des équipes SaaS B2B utilisent désormais l'IA pour rédiger leurs textes. Bien moins nombreuses sont celles qui laissent un agent modifier le site lui-même, et celles qui essaient en découvrent souvent la raison à leurs dépens : une plateforme conçue pour cliquer dans un éditeur visuel ne donne à un agent rien à lire, rien à tester et aucun endroit sûr où essayer. La solution passe par une stack et des règles pensées pour l'agent dès le départ.

Ce guide présente cette stack, les garde-fous qui protègent un site en production et les workflows d'agents qui tournent dessus. Il s'appuie sur la refonte de saas-hackers.com, qui repose sur Astro, Tailwind, Sanity et Netlify et a été construite avec Claude Code. Si vous cherchez encore à définir ce que votre site doit accomplir, commencez par notre guide de la stratégie de site web SaaS B2B, puis revenez pour la construction.

Qu'est-ce qu'un site web agentique ?

Un site web agentique est un site où des agents d'IA assurent une grande partie de la construction et de la maintenance, dans le cadre de règles fixées par des personnes et de contrôles exécutés à chaque fois. Les agents rédigent des pages, corrigent des liens, actualisent des contenus et ouvrent des modifications de code. Les personnes décident de la finalité du site, valident tout ce qui présente un risque et vérifient les résultats.

C'est différent d'un générateur de site par IA, qui crée un site une seule fois à partir d'un prompt. Sur un site web agentique, l'agent continue de travailler après le lancement, comme le feraient un développeur et un éditeur de contenu, et chacune de ses modifications passe par la même relecture que celles d'une personne.

Trois éléments font qu'un site est agentique, et pas seulement assisté par l'IA :

• L'agent peut lire tout ce qui définit le site. Les templates de pages, les types de contenu, les design tokens, les redirections et les règles elles-mêmes se trouvent dans un dépôt de code, et pas uniquement dans un tableau de bord.
• Chaque modification peut être testée avant sa mise en ligne, avec un build qui échoue en cas de page cassée, un lien d'aperçu pour chaque changement et un essai à blanc pour chaque script de contenu.
• Les personnes gardent les clés qui comptent. La fusion du code, la publication de contenus sensibles et tout ce qui coûte de l'argent restent entre les mains d'une personne identifiée.

Pourquoi la stack compte-t-elle davantage quand ce sont des agents qui travaillent ?

La stack compte davantage parce qu'un agent ne peut travailler en toute sécurité qu'avec ce qu'il voit et peut vérifier. Une personne repère qu'une page a un problème dans un éditeur visuel. Un agent a besoin que ce savoir soit écrit : sous la forme d'un schéma qui rejette un champ manquant, d'un contrôle qui fait échouer le build, ou d'une règle dans un fichier qu'il lit avant chaque session.

Une stack conçue pour les agents présente quatre propriétés :

1. Du texte plutôt que des clics. La configuration, les modèles de contenu et les styles sont des fichiers du dépôt, si bien qu'un agent peut les lire, les modifier et les expliquer.
2. Un retour rapide et honnête. Un build ou un test qui échoue bruyamment indique à l'agent qu'il se trompe avant qu'un visiteur ne s'en aperçoive.
3. Un endroit sûr où essayer. Les branches, les brouillons et les liens d'aperçu permettent à un agent de montrer son travail sans toucher au site en production.
4. Un point de validation unique. Chaque modification de code arrive sous forme de pull request qu'une personne peut lire, puis fusionner ou rejeter.

Une fois ces éléments en place, le choix du modèle compte moins. Sans eux, même un agent prudent finira par casser quelque chose, car rien ne l'en avertit.

Quelle est la stack technique Claude Code pour un site web agentique ?

La stack comporte cinq couches : un framework de site statique, un CMS headless, un hébergeur, l'agent, et le point de validation entre eux. Chaque couche est là parce qu'elle donne à l'agent quelque chose à lire ou à vérifier.

Un framework de site statique : Astro

Astro construit les pages à l'avance. Par défaut, il pré-rend chaque page, route et endpoint en HTML statique au moment du build, et vous choisissez de rendre à la demande certaines routes lorsque c'est nécessaire (Astro, 2026). Pour un agent, la sortie statique est une aubaine : après un build, tout le site existe sous forme de fichiers, et un script peut donc contrôler chaque page avant toute mise en ligne.

SaaS Hackers rend toutes ses pages de façon statique. La seule page rendue à la demande est l'aperçu de brouillon, que les éditeurs ouvrent depuis le CMS pour voir les modifications non publiées. Tout le reste est contrôlé au moment du build, et le contenu est présent dans le HTML dès le premier chargement, y compris chaque élément d'une liste filtrée.

Un CMS headless avec des schémas dans le code : Sanity

Un CMS headless sépare le contenu du design du site et le lui fournit via une API. Ce qui compte pour les agents, c'est l'endroit où se trouve le modèle de contenu. Dans Sanity, un schéma décrit les types de documents et de champs que les éditeurs peuvent créer, et il est défini dans le code de la configuration du Studio (Sanity, 2026).

Comme les schémas sont du code, un agent peut lire précisément de quoi se compose un article de blog ou un profil, ajouter un champ via une pull request et écrire du contenu avec des scripts que le schéma valide. Les éditeurs conservent un éditeur visuel. SaaS Hackers garde chaque schéma dans le dépôt, jamais uniquement dans le tableau de bord, ce qui fait partie des règles de son fichier de projet.

Un hébergeur avec aperçus et fonctions : Netlify

L'hébergeur apporte à l'agent deux choses : un aperçu de chaque modification et un endroit où exécuter de petites tâches. Netlify construit automatiquement un aperçu de déploiement à l'ouverture d'une pull request dans un dépôt connecté, à sa propre adresse, et y ajoute un en-tête noindex pour que les moteurs de recherche l'ignorent (Netlify, 2026). Ce lien d'aperçu permet à une personne de vérifier la modification d'un agent sur une vraie page avant de la fusionner.

Les fonctions planifiées de Netlify s'exécutent comme une tâche cron selon un calendrier fixe en UTC, uniquement sur le déploiement de production publié, avec une limite de 30 secondes par exécution (Netlify, 2026). Des tâches courtes et planifiées conviennent bien à la maintenance agentique : vérifier si quelque chose a changé, puis décider de relancer ou non un build.

Claude Code : CLAUDE.md, skills, hooks et MCP

Claude Code est l'agent. Quatre de ses fonctionnalités font d'un modèle performant un membre fiable de l'équipe :

• CLAUDE.md. Les fichiers CLAUDE.md sont des fichiers Markdown qui donnent à Claude des instructions permanentes pour un projet, et Claude les lit au début de chaque session (Anthropic, 2026). Partagé via le contrôle de version, le fichier du projet contient les commandes de build, les standards et les règles que tout le monde suit.
• Skills. Un skill est un SKILL.md fichier d'instructions que Claude ajoute à sa boîte à outils et utilise quand c'est pertinent. Contrairement à CLAUDE.md, le contenu d'un skill ne se charge que lorsqu'il est utilisé : les procédures longues ne coûtent donc presque rien tant qu'on n'en a pas besoin (Anthropic, 2026). Notre article sur les Claude Skills pour les équipes marketing explique comment ils fonctionnent pour la rédaction.
• Hooks. Les hooks sont des commandes shell que Claude Code exécute à des moments définis, ce qui offre un contrôle déterministe : certaines actions ont toujours lieu, sans dépendre d'un choix du modèle (Anthropic, 2026). Utilisez-les pour les règles qui ne doivent jamais fléchir, comme le blocage des modifications d'un fichier de secrets.
• Serveurs MCP. Le Model Context Protocol est un standard open source pour connecter des outils d'IA à d'autres systèmes, et les serveurs MCP donnent à Claude Code l'accès à vos outils, bases de données et API (Anthropic, 2026). C'est ainsi qu'un agent lit directement les données d'analytics, les positions ou un CMS, au lieu de se fier à ce que vous collez. Notre guide sur les agents marketing IA et MCP présente les outils marketing que vous pouvez connecter.

Sessions cloud et tâches planifiées

Une session cloud est une session Claude Code qui s'exécute sur une infrastructure cloud plutôt que sur votre ordinateur portable, et qui continue de tourner une fois l'écran fermé (Anthropic, 2026). Les exécutions planifiées et déclenchées démarrent chacune comme une session cloud. C'est ce qui permet à un agent de publier un article de blog à 01:43 ou de mesurer les positions un mardi matin sans que personne ne soit devant un clavier.

Les pull requests GitHub comme point de validation

Chaque modification de code faite par un agent arrive sur une branche et prend la forme d'une pull request. La préversion de déploiement est construite à partir de cette pull request, les vérifications s'y exécutent, et une personne la fusionne ou non. Chez SaaS Hackers, la règle est simple : les agents ouvrent des pull requests, et Darren les fusionne. Aucun agent ne fusionne son propre travail.

Comment empêcher un agent de casser un site web en production ?

Pour empêcher un agent de casser un site en ligne, il faut que le chemin sûr soit le seul possible : une sauvegarde avant toute écriture, une simulation qui montre la modification, des vérifications à chaque build, et des limites sur ce qu'il peut modifier seul. Rien de tout cela ne dépend du fait que l'agent pense à être prudent. Ces garde-fous sont inscrits dans les scripts, les schémas et le build.

Sauvegarder, simuler, puis écrire

Chaque script qui modifie du contenu publié sur SaaS Hackers fonctionne de la même façon :

1. Sauvegarde. npm run backup exporte l'ensemble des données dans un fichier daté avant toute modification.
2. Simulation. Le script s'exécute sans --write, vérifie tout et rédige un rapport de ce qu'il modifierait.
3. Lecture de la simulation. L'agent, ou une personne, lit ce rapport avant de continuer.
4. Écriture. Ce n'est qu'ensuite que le même script s'exécute avec --write.
5. Vérification. Le site est construit à partir du contenu publié, puis les vérifications des routes et des schémas sont lancées.

Le compte rendu qui suit chaque tâche indique la sauvegarde effectuée, de sorte que toute modification peut être annulée.

Des verrous dans le CMS

Certaines erreurs coûtent moins cher à prévenir dans le CMS qu'à repérer après coup. Dans le Studio de SaaS Hackers, un slug est verrouillé dès que son document est publié, ce qui évite de changer par accident une adresse en ligne. Une page ne peut pas être publiée à une adresse qui a une redirection active, et les nouvelles images ne peuvent pas être publiées sans texte alternatif. Les scripts dépublient au lieu de supprimer, et ne touchent pas aux brouillons des autres.

Des vérifications à chaque build

Le build est le critique le plus honnête de l'agent. Sur SaaS Hackers, npm run build s'arrête si l'une de ces vérifications échoue :

• design tokens obsolètes, couleurs ou tailles utilisées en dehors des tokens, ou texte dont le contraste est insuffisant ;
• un bloc de section du CMS sans composant de page correspondant ;
• des données structurées qui ne passent pas l'analyse ou qui n'ont pas le schéma du type de page, ou une page sans exactement un H1 ;
• des liens de langue (hreflang) qui ne pointent pas dans les deux sens.

Après un build, la vérification des routes confirme que chaque adresse en ligne concernée renvoie un code 200, et la vérification de parité compare les titres, descriptions, canoniques, titres de section et schémas avec le site en ligne. La vitesse a aussi sa place dans les vérifications : notre fiche du guide sur les Core Web Vitals explique les mesures à surveiller.

Les secrets restent hors du dépôt

Les jetons et les clés se trouvent dans un fichier local .env ignoré par git, et dans les variables d'environnement de l'hébergeur. Le dépôt ne conserve que la liste de leurs noms. Un agent peut utiliser une clé présente dans son environnement sans jamais l'écrire dans un fichier, un commit ou un rapport.

Limites de ce qu'un agent peut modifier seul

Décidez à l'avance ce qu'un agent peut faire sans demander, mettez-le par écrit et appliquez-le dans le code partout où c'est possible. Voici comment SaaS Hackers répartit les rôles aujourd'hui :

• Les articles de blog sont publiés immédiatement, une fois les vérifications du script passées, et une personne les relit ensuite.
• Les textes des pages, les titres et les liens internes sont modifiés par l'agent SEO, dans des limites fixes par exécution.
• Les modifications de code passent par une pull request qu'une personne fusionne.
• Les demandes de profil des agences attendent qu'une personne appuie sur Approuver dans Slack.
• Les scores, avis et classements ne sont jamais modifiés par un agent ni sur demande.

Limites de coût

Les agents peuvent dépenser de l'argent très vite, si bien que le coût est aussi un garde-fou. SaaS Hackers reconstruisait autrefois le site à chaque publication, et chaque déploiement en production coûte 15 crédits Netlify. Les reconstructions sont désormais limitées à une par jour : une fonction planifiée s'exécute à 05:17 UTC et ne reconstruit que si quelque chose a été publié depuis le build en ligne. Le brief de l'agent SEO précise aussi de ne jamais déclencher lui-même un déploiement.

Quels workflows d'agents tournent sur un site web agentique ?

Une fois la stack et les garde-fous en place, les agents peuvent prendre en charge le travail répétitif qui est souvent négligé : publier, mesurer, mettre à jour et traduire. Chaque workflow dispose d'un brief écrit, d'un calendrier, de limites et d'un rapport.

Publier un article de blog tous les deux jours

Une tâche planifiée rédige et publie un article issu du backlog de contenus tous les deux jours à 01:43 UTC, avant la reconstruction quotidienne. Elle rédige avec une compétence de copywriting, contrôle le texte avec une compétence d'audit de contenu, puis un script de publication refuse l'article s'il trouve un tiret cadratin, un texte provisoire, un mauvais slug, une meta description trop longue, moins de trois liens internes, ou un lien interne qui n'est pas en ligne. Elle ne fait que créer de nouveaux articles et ne modifie jamais un article existant.

Un agent SEO qui mesure et agit deux fois par semaine

Les mardis et vendredis à 06:41 UTC, une nouvelle session mesure les positionnements, évalue le site par rapport à ses objectifs et déroule une liste d'actions classées par priorité. Chaque exécution peut modifier 8 pages au maximum, créer 1 nouvelle liste et ajouter 30 liens internes, avec des plafonds pour les appels de données payantes et les dépenses de traduction. Elle enregistre chaque modification avec une copie d'avant pour pouvoir revenir en arrière, envoie les modifications de code vers des pull requests et rend compte dans le canal Slack de l'équipe. Notre comparatif Claude Code et AirOps pour les équipes de contenu examine dans quels cas ce type de dispositif l'emporte sur un outil no-code.

Garder les profils de l'annuaire à jour

Un script mensuel vérifie le site web de chaque agence et note s'il fonctionne, s'il a déménagé ou s'il est en panne. Une exploration trimestrielle lit le site propre à chaque agence et enregistre les faits qu'il indique, en ajoutant les tags de services et de secteurs que le site mentionne, sans jamais en retirer. Ni l'un ni l'autre ne touche aux scores, avis et classements.

Demandes approuvées dans Slack

Les agences peuvent demander la mise à jour de leur profil ou candidater pour être référencées. Chaque demande est confirmée par e-mail, vérifiée par Claude à partir du site web de l'agence, enregistrée comme brouillon dans le CMS et envoyée dans Slack sous forme de carte. Seule une personne autorisée peut appuyer sur Approuver, chaque clic est vérifié à l'aide de la signature de requête de Slack, et chaque demande ne peut être tranchée qu'une seule fois.

Traduire chaque page

Chaque page de SaaS Hackers existe aussi en allemand, en français, en espagnol, en néerlandais, en japonais et en portugais du Brésil. Claude Sonnet 5.5 a traduit le site via l'API Batch pour 91,35 $ au total, et les exécutions suivantes n'envoient que le texte qui a changé. Les citations et ce que les agences disent sur leur propre site restent en anglais, mot pour mot.

Comment SaaS Hackers a-t-il été construit sur cette stack ?

SaaS Hackers a été reconstruit depuis Webflow vers Astro, Tailwind, Sanity et Netlify avec Claude Code, par étapes, chacune sous la forme d'une pull request relue et fusionnée par une personne de SaaS Hackers. Le fichier de projet fixait l'ordre, les règles et les commandes, et une spécification écrite définissait ce que « terminé » signifiait pour chaque étape. Le volet design de cette refonte est détaillé dans notre guide sur la création d'un site web avec Claude Code.

La migration a d'abord transféré 233 articles et 172 profils d'experts dans Sanity sous forme de brouillons, puis les a comparés aux pages en ligne avant toute publication. La phase SEO a ajouté une vérification de l'analyse des données structurées de chaque page, ainsi qu'une vérification de parité avec le site en ligne. Au moment où le nouveau site a remplacé Webflow, la vérification des routes renvoyait 494 adresses en ligne sur 494, un build de 3 936 pages (anglais, version américaine et six langues) prenait 8,5 minutes, et les performances mobiles Lighthouse atteignaient 99 à 100 sur les pages testées en production.

La même stack porte désormais les workflows d'agents décrits plus haut. Trois éléments l'ont rendu possible : un fichier de projet que chaque session lit, des scripts qui refusent les entrées incorrectes, et une personne qui fusionne le code. Si vous voulez l'angle marketing operations de ce tableau, notre guide des marketing operations B2B SaaS traite des données et des outils autour du site.

Quels sont les avantages d'un site web agentique ?

Les bénéfices viennent du fait que le travail répétitif est fait à temps, à chaque fois, avec une trace de ce qui a changé :

• L'entretien se fait à temps. Les liens cassés, les informations périmées et les meta descriptions manquantes sont corrigés selon un calendrier, et non lors d'un grand nettoyage annuel.
• Les modifications sont réversibles. Grâce aux sauvegardes, aux copies d'avant et aux pull requests, toute modification faite par un agent peut être tracée et annulée.
• Il y a moins de transmissions. Un seul agent peut modifier le contenu, les templates et les vérifications dans la même pull request, au lieu de faire circuler le travail entre un rédacteur, un développeur et un spécialiste SEO.
• Les coûts de fonctionnement peuvent rester bas avec la bonne stack. L'analyse des coûts de SaaS Hackers n'a relevé aucun supplément d'abonnement d'hébergement pour le nouveau site, le principal coût à surveiller étant les crédits Netlify pour les déploiements.

Les problèmes courants des sites web agentiques, et comment les résoudre

L'agent fait deux fois la même erreur. Il n'a aucun souvenir de la session précédente. Inscrivez la règle dans CLAUDE.md ou dans une compétence dès que vous le corrigez, afin que chaque future session démarre avec elle.

Les modifications semblent correctes dans le code, mais pas sur la page. Sans prévisualisation, personne ne voit la page avant sa mise en ligne. Exigez un lien de prévisualisation du déploiement dans chaque pull request et vérifiez la page elle-même avant de fusionner.

Les vérifications passent, mais le site dérive quand même. Les vérifications ne détectent que ce qu'elles testent. Quand un problème passe entre les mailles, ajoutez-en une au build pour qu'il ne se reproduise pas.

Les coûts grimpent peu à peu. Chaque rebuild, chaque crawl et chaque appel d'API a un coût. Fixez une limite dans le brief de chaque agent, regroupez les rebuilds et indiquez les dépenses dans le compte rendu de chaque exécution.

Personne ne sait ce que l'agent a modifié. Demandez un compte rendu après chaque tâche : ce qui a changé, la sauvegarde effectuée, les vérifications lancées et ce qu'il n'a pas pu faire.

Que rechercher si vous vous faites accompagner pour en construire un

Si vous faites appel à une agence ou à un développeur pour créer un site web agentique, demandez à voir les garde-fous, pas seulement le design. Un bon partenaire vous montrera :

• un fichier d'instructions du projet et les règles qu'il contient ;
• des scripts de contenu avec une simulation (dry run) et une étape de sauvegarde ;
• des vérifications de build qui échouent en cas de vrais problèmes, avec les commandes pour les lancer ;
• une séparation claire entre ce que les agents peuvent modifier et ce qu'une personne doit valider ;
• les coûts de fonctionnement par écrit, y compris les déploiements et l'usage des API.

Vous pouvez comparer des spécialistes dans notre sélection des meilleures agences de web design pour les SaaS B2B.

À propos de SaaS Hackers

SaaS Hackers est une communauté de spécialistes du SaaS B2B qui partagent des retours d'expérience concrets, créée par celles et ceux qui font la croissance : marketeurs, stratèges et développeurs. Elle publie des guides, un manuel et des classements, et tient un annuaire d'agences et d'experts en marketing pour le SaaS B2B. SaaS Hackers est géré par Team 4, une agence de marketing pour le SaaS B2B référencée et classée dans l'annuaire.