Vous venez de passer un après-midi à construire un dashboard, un portfolio ou un site de documentation — et maintenant vient la partie que personne n’aime : le mettre en ligne. Il vous faut un hôte, une commande de deploy, un moyen d’apercevoir avant la mise en public, et la certitude de pouvoir faire un rollback si quelque chose casse. Si vous avez déjà deploy un site à 23 h pour découvrir un chemin d’asset cassé sur l’URL en ligne, vous connaissez la douleur. Hermes livre désormais un skill optionnel qui transforme tout ce rituel en un pipeline en cinq étapes, une seule commande : publish-site.

Fusionné le 27 août 2026 (PR #72189), publish-site est un skill à empreinte nulle sur le cœur — aucun nouvel outil, aucune modification du cœur de Hermes — qui vous donne le même résultat que « Sites » de ChatGPT Work : sauvegarder une version, deploy, et faire un rollback si nécessaire, sur une infrastructure que vous possédez. C’est un pipeline discipliné : aperçu local pour validation, version avant deploy, une échelle de providers, vérification HTTP-200 obligatoire avant de déclarer le succès, et rollback à une commande.

Ce que fait le skill

Le pipeline est toujours fait des cinq mêmes mouvements, et le SKILL.md du skill détaille chacun d’eux avec des commandes exactes :

1. Build — exécutez votre étape de build (npm run build, etc.) et identifiez le répertoire de sortie (dist/, build/).
2. Aperçu pour validation — servez-le localement, ou ouvrez un tunnel partageable pour que quelqu’un d’autre puisse approuver avant la mise en ligne.
3. Commit + tag — versionnez chaque deploy avec un tag git (version avant deploy).
4. Deploy via l’échelle de providers — GitHub Pages par défaut ; Cloudflare Pages ou Netlify quand vous avez besoin de plus.
5. Vérifiez l’URL en ligne — un vrai contrôle HTTP qui attend 200 avant de déclarer le succès.

Installez-le avec :

hermes skills install official/web-development/publish-site

Pas à pas

1. Aperçu local, partagez si nécessaire

Buildez si besoin et servez le répertoire de sortie :

python3 -m http.server 8080 --directory dist

Pour un lien d’aperçu partageable — un utilisateur sur une autre machine, ou vous voulez sa validation avant la mise en ligne — ouvrez un tunnel rapide dans une session de terminal en arrière-plan :

cloudflared tunnel --url http://localhost:8080

Vous obtenez une URL https://*.trycloudflare.com à transmettre. Tuez le tunnel après la validation.

2. Version avant deploy

Chaque deploy reçoit un tag git — c’est ce qui rend le rollback possible en une ligne plus tard :

git add -A && git commit -m "deploy: <what>" && git tag deploy-YYYYMMDD-HHMM

3. Deploy via l’échelle de providers

Le skill vérifie les CLI de providers authentifiées dans l’ordre :

Provider	Commande	Prérequis
GitHub Pages (défaut)	git subtree push --prefix dist origin gh-pages	gh auth status réussit
Cloudflare Pages	npx wrangler@latest pages deploy dist --project-name <name>	wrangler whoami réussit ou CLOUDFLARE_API_TOKEN est défini
Netlify	netlify deploy --prod --dir dist	netlify status réussit

Si vous activez GitHub Pages sur un dépôt qui ne l’a pas encore :

gh api repos/{owner}/{repo}/pages -X POST -f 'source[branch]=gh-pages' -f 'source[path]=/'

4. Vérifiez avec un vrai contrôle HTTP

Avant de déclarer le succès, le skill exige un contrôle HTTP réel sur l’URL en ligne :

curl -sS -o /dev/null -w '%{http_code}' <url>    # attend 200

5. Faites un rollback quand nécessaire

Un mauvais deploy est à une commande de disparaître : repassez sur le tag précédent et re-deploy.

git checkout <previous-tag> -- . && redeploy

Quand l’utiliser (et quand ne pas le faire)

Chargez le skill quand vous voulez mettre un site en ligne — « publie ceci », « deploy ceci », « donne-moi un lien à partager » — deploy un site dashboard/rapport/portfolio/docs que vous venez de générer, mettre à jour un site déjà publié (re-deploy = nouvelle version), faire un rollback d’un mauvais deploy, ou simplement choisir un hôte parce que vous vous moquez de l’endroit où il vit. Il couvre les sites statiques et la sortie de build des SPA : du HTML/CSS/JS pur, ou le dossier dist//build/ de Vite, Next export, Astro, etc.

Il ne couvre pas les runtimes côté serveur. Pour les deploys serverless jetables sans création de compte, le skill optionnel frère cloudflare-temporary-deploy est l’outil approprié. Le skill suppose aussi au moins une CLI de provider authentifiée — vérifiez d’abord gh auth status, wrangler whoami ou netlify status.

Pourquoi adopter ce modèle

Trois habitudes intégrées au skill méritent d’être volées même si vous ne l’installez jamais :

• Aperçu avant public. Le tunnel partageable transforme « lancer et prier » en « validation d’abord » — une étape de deux minutes qui attrape les assets cassés, les chemins de base erronés et les polices manquantes avant qu’ils ne soient visibles par le monde.
• Versionnez chaque deploy. Un tag git par deploy signifie que toute version est reproductible et que tout rollback est à un checkout. « Quelle version est en ligne ? » a une réponse exacte.
• Vérifiez avant de déclarer terminé. Le contrôle HTTP-200 tue le classique mensonge : « j’ai deploy » alors que le site renvoie en réalité une 404. Un curl sur l’URL en ligne est la seule définition honnête du succès.

L’intégrer à votre workflow Hermes

Le skill est conçu pour être chargé automatiquement par l’agent lorsque la demande correspond (« publie ceci », « deploy ceci », « donne-moi un lien ») — le même modèle déclenché par requête que les autres skills Hermes. Si vous débutez avec le système de skills, voir notre guide des skills locaux au projet pour le fonctionnement de .hermes/skills/ et l’application des portes de confiance, et notre aperçu des 8 meilleurs skills pour l’écosystème au sens large. Pour une visite de la façon dont les skills optionnels étendent Hermes sans toucher au cœur, la PR publish-site elle-même se lit facilement — 476 lignes d’ajouts, principalement le SKILL.md et sa suite de tests, zéro modification du cœur.

Installer et utiliser le skill tient en une commande, et la discipline qu’il encode — aperçu, tag, deploy, vérification, rollback — est le même workflow que les équipes professionnelles paient cher en outillage pour obtenir. Maintenant c’est un skill que vous pouvez charger à la demande, sur une infrastructure que vous possédez. La prochaine fois que vous finirez un site à 23 h, « deploy-le » sera un pipeline en cinq étapes avec un 200 à la fin — pas une prière.