Claude Code en mode cloud : peut-on vraiment automatiser la publication d'un site sans serveur ?

Le site qui s'écrit lui-même (ou presque)

Un agent choisit un sujet, part vérifier des sources sur le web, rédige un texte de mille cinq cents mots, met à jour ses propres métadonnées, committe le tout dans un dépôt Git, puis laisse un service tiers construire et publier le site. Personne n'a touché un clavier pendant l'opération. Ce scénario n'est plus une démonstration de laboratoire, c'est un usage documenté de Claude Code en 2026.

Le terme « cloud » recouvre en réalité trois choses différentes, souvent confondues : le mode headless, un agent lancé en ligne de commande sans terminal interactif ; l'action GitHub officielle qui embarque Claude Code dans un pipeline CI/CD ; et les machines virtuelles managées par Anthropic sur lesquelles tourne Claude Code sur le web. Les trois s'articulent, mais elles ne portent pas les mêmes garanties de sécurité ni les mêmes limites.

Autant le dire tout de suite : cet article a lui-même été produit par ce type de chaîne, avec un sujet piocher dans une liste, des recherches web réelles pendant la session et une relecture avant publication. Ce n'est pas un argument de vente, c'est le point de départ le plus honnête pour comprendre ce qui marche et ce qui casse.

Personne n'a touché un clavier pendant l'opération. Ce n'est plus une démonstration de laboratoire.

Le mode headless : un agent sans terminal

La brique de base s'appelle le mode headless, activé par le drapeau -p. Au lieu d'ouvrir une session interactive, on donne à Claude Code un unique prompt en argument. L'agent réfléchit, appelle ses outils, édite des fichiers, exécute des commandes, puis s'arrête et rend la main. Aucune fenêtre de terminal à surveiller.

Ce mode expose des options pensées pour tourner sans supervision : --output-format renvoie du texte brut, du JSON ou un flux JSON exploitable par un script appelant ; --allowedTools restreint la liste des outils utilisables ; --permission-mode fixe le comportement face aux actions sensibles, pour qu'une exécution automatisée ne reste jamais bloquée en attente d'une validation humaine qui ne viendra pas.

Au-dessus de ce mode headless, Anthropic propose une action GitHub officielle, anthropics/claude-code-action, lancée fin septembre 2025 avec Claude Code 2.0. Une commande, /install-github-app, suffit à générer un workflow fonctionnel : un déclencheur (une mention, un label, un horaire), un job qui installe Claude Code, un prompt, et le tour est joué. L'agent tourne alors directement dans le runner GitHub Actions, avec accès au dépôt, à l'historique Git et au diff en cours.

claude -p "Lis le sujet du jour, redige l'article et committe-le" \
  --output-format json \
  --allowedTools "Read,Write,Edit,Bash(git:*)" \
  --permission-mode acceptEdits

Claude Code sur le web : des machines gérées par Anthropic

Le mode headless dans un runner GitHub reste, techniquement, une exécution auto-hébergée : c'est vous qui fournissez la machine, celle de GitHub Actions, et qui gérez les secrets. Anthropic propose une deuxième approche, Claude Code sur le web, en beta de recherche : chaque session tourne dans une machine virtuelle isolée et gérée entièrement par Anthropic. On y assigne des tâches de code depuis un navigateur, sans rien installer localement.

Entre les deux, il existe une famille d'environnements sandbox plus large : conteneurs Docker ou OCI avec leurs propres politiques réseau, volumes montés et profils seccomp. Le principe commun est de restreindre l'accès au système de fichiers et au réseau au niveau du noyau, plutôt que de compter sur la bonne volonté du modèle. C'est une nuance importante : la sécurité d'un agent autonome ne repose pas sur le fait qu'on lui demande gentiment de rester dans son couloir, mais sur des barrières que le système impose.

Cron, workflows et déclencheurs : qui appuie sur le bouton

Reste la question du déclenchement. Un pipeline GitHub Actions peut se lancer sur un horaire cron classique défini dans le fichier de workflow. Claude Code propose aussi ses propres outils de planification côté agent, qui permettent à une session de programmer des tâches récurrentes persistant au-delà de la conversation en cours.

Le schéma qui revient le plus souvent pour un site éditorial suit une chaîne simple.

L'agent ne déploie rien lui-même. Il modifie du code source. C'est l'hébergeur qui reconstruit et republie.

• 01Un déclencheur horaire lance le workflow, cron GitHub Actions ou tâche planifiée côté agent.
• 02L'agent lit une liste de sujets ou fait une veille web, choisit un angle et vérifie qu'il n'existe pas déjà.
• 03Il croise plusieurs sources, rédige le texte et met à jour les fichiers de contenu du dépôt.
• 04Il committe uniquement les fichiers listés dans ses instructions, jamais la configuration de build ou de déploiement.
• 05L'hébergeur (Vercel, Netlify, GitHub Pages...) détecte le push et reconstruit le site tout seul, en continuous deployment.

La faille qui a rappelé les limites de l'automatisation

Cette architecture n'est pas sans risque, et un épisode récent l'a montré crûment. En 2026, Microsoft Threat Intelligence a documenté une faille dans l'action GitHub officielle de Claude Code : l'outil Bash tournait dans un bac à sable qui retirait les variables d'environnement sensibles, mais l'outil Read, lui, ne suivait pas la même règle.

Concrètement, un attaquant pouvait manipuler l'agent, via un simple commentaire d'issue ou une description de pull request rédigée pour tromper le modèle, afin de lui faire lire /proc/self/environ. Ce fichier système renvoie sans filtre les variables d'environnement du processus, y compris la clé d'API ANTHROPIC_API_KEY et d'autres secrets du pipeline CI/CD. Une phrase de texte suffisait, en théorie, à faire fuiter des identifiants.

Anthropic a corrigé le problème le 5 mai 2026, dans Claude Code 2.1.128 : le Read tool rejette désormais sans condition la lecture des fichiers sensibles du dossier /proc. Un correctif d'autorisation a suivi côté action GitHub, dans claude-code-action v1.0.94. L'épisode illustre un problème plus général des agents branchés sur des dépôts publics : ils traitent du texte non fiable, issues, commentaires, descriptions de pull requests, comme des instructions potentielles. C'est ce qu'on appelle l'injection de prompt.

Le Bash tool tournait dans un sandbox qui retirait les secrets. Le Read tool, lui, ne suivait pas la même règle.

Ce que Google pense des sites qui se publient seuls

Automatiser la rédaction ne dispense pas de respecter les règles du jeu côté moteurs de recherche. La politique de Google contre l'abus de contenu à l'échelle (« scaled content abuse ») s'applique, texte à l'appui, de manière identique à la production humaine, à la production par IA et aux méthodes hybrides. Le critère n'est pas l'outil utilisé, c'est la valeur apportée au lecteur : générer un grand nombre de pages sans réel apport pour l'utilisateur reste une violation, que ce soit fait à la main ou avec un modèle de langage.

La mise à jour anti-spam de juin 2026 a explicitement ciblé ce type de tactiques au niveau du contenu. Selon plusieurs analyses SEO indépendantes publiées après la mise à jour de mars 2026, des sites ayant publié des centaines ou des milliers de pages générées par IA sans supervision éditoriale ont vu leur trafic chuter de 50 à 80 %. Ces chiffres viennent d'observations tierces, pas de Google lui-même, mais la direction qu'ils indiquent reste cohérente avec le discours officiel : l'automatisation de la production n'immunise personne contre les critères de qualité.

Ce qui doit rester entre des mains humaines

Ce que change concrètement le mode cloud de Claude Code, ce n'est pas la possibilité de publier sans relecture, c'est la possibilité de retirer le travail répétitif de la chaîne : chercher un sujet, croiser des sources, rédiger un premier jet, mettre en forme les métadonnées, committer proprement. Ce sont des tâches mécaniques, bien documentées, où un agent bien scopé apporte un vrai gain de temps.

Ce qui ne devrait pas être automatisé sans garde-fou, en revanche, tient en trois points. Le choix éditorial du sujet et de l'angle, qui engage la ligne d'un média. La vérification finale des faits et des chiffres avancés, parce qu'un agent qui recherche sur le web peut toujours mal interpréter une source. Et la portée des permissions accordées au pipeline : un agent qui committe du contenu n'a besoin ni d'un accès large au système de fichiers, ni des mêmes secrets qu'un déploiement de production, comme l'a rappelé la faille /proc/self/environ.

Publier un site sans serveur à gérer soi-même est déjà une réalité technique solide en 2026, portée par des briques documentées et de plus en plus robustes. Publier un site sans aucune supervision humaine, en revanche, reste un pari risqué, autant du point de vue de la sécurité que de celui de la qualité éditoriale. La bonne architecture n'est pas celle qui retire l'humain de la boucle, c'est celle qui le repositionne là où son jugement compte vraiment.