Déployer sur Netlify
Publier la sortie construite de Chinaski sur Netlify est possible, le builder émet déjà des règles de redirection au format Netlify, mais le dépôt ne livre aucun pipeline spécifique à Netlify, donc cette page documente la mécanique vérifiée et les deux points d'attention à vérifier avant d'y publier.
Ce que le builder produit
À chaque build, la racine de la sortie gagne un fichier _redirects contenant vos règles de redirection au format propre de Netlify, de simples lignes de old-slug new-slug status-code, câblées aux redirections que vous gérez dans l'admin (le log de build indique « N Netlify redirect rule(s) written » quand des règles existent). C'est la principale surface de compatibilité avec les hôtes statiques : construisez, puis téléversez le répertoire, et vos redirections simples de chemins fonctionnent telles quelles.
Tout le reste est des fichiers ordinaires : arbres de sortie par langue avec fichiers index.html, pièces du PWA (sw.js, manifest, page offline), sitemaps et flux, et l'arborescence du dossier media.
Point d'attention 1 : la ligne de domaine canonique
Quand une Site URL est définie, le builder ajoute aussi à _redirects une règle de domaine canonique qui redirige en 301 l'hôte alternatif www/nu vers votre hôte canonique. Son marqueur final ! est de la syntaxe de redirection Caddy, pas Netlify. Si vous déployez vers un parseur Netlify strict, examinez cette ligne générée avant de publier, supprimez-la ou réécrivez-la selon la grammaire des règles de redirection de Netlify. (Le reste de _redirects (paires de chemins simples avec codes de statut numériques) est au format standard.)
Point d'attention 2 : les redirections à motifs ne sont pas dans le fichier
Les redirections à motifs (wildcards avec substitutions) ne sont jamais écrites délibérément dans _redirects ; le format de fichier simple ne peut pas les exprimer de manière sûre. Si votre site s'appuie sur des règles à motifs, elles doivent être implémentées au niveau de l'hôte plutôt que transportées dans le fichier.
Portée de l'hébergement statique : ce qu'un hôte purement statique ne peut pas voir
Deux fonctionnalités du CMS n'existent pas dans la sortie statique et doivent atteindre le CMS lui-même :
- Les soumissions de formulaires sont POSTées vers
/forms/<slug>sur le CMS. Sur un hôte statique il n'y a pas de destination, sauf si vous définissez l'URL de base du CMS, auquel cas les shortcodes[form:slug]intégrés se rendent comme des iframes pointant vers le formulaire hébergé par le CMS, et les soumissions arrivent là où le CMS est joignable. - Les téléchargements de documents sont servis dynamiquement (comptage des téléchargements et état de publication) : un déploiement purement statique ne peut pas les servir ; la fonctionnalité documents exige la route de proxy dynamique.
En résumé : l'hébergement Netlify est viable pour les sites purement éditoriaux ; les sites riches en formulaires ou en documents exigent que le CMS soit joignable (via l'URL de base) ou un autre modèle d'hébergement.
Pipelines
Il n'y a pas de cible de deploy intégrée « push to Netlify » ; les deploys sortants intégrés sont rsync-over-SSH et buckets compatibles S3 (Settings → Deploy). Pour amener les builds sur Netlify, vous câblez votre propre convoyeur (CLI/config netlify, un pipeline basé sur un dépôt, ou un upload scripté) déclenché après chaque build : le répertoire de sortie plus _redirects est l'artefact autonome, réémis entièrement à chaque build.
Points d'attention du mode langue : un site déployé en mode URL sous-domaine exige des cibles de deploy séparées par sous-domaine de langue ; les sites en mode chemin se déploient comme un seul arbre.
Une note sur les en-têtes
Les comportements de cache dans les exemples statiques livrés (cache court sur HTML, immuable pour les polices .woff2, no-cache sur sw.js) sont implémentés dans les fichiers d'exemple de reverse-proxy pour votre propre serveur, pas cuits dans le build. Sur un hôte statique géré, les règles d'en-têtes sont une affaire de configuration de l'hôte ; appliquez-les là selon le système de règles de votre fournisseur.