Déployer proprement sur un hébergement mutualisé

Un hébergement mutualisé a mauvaise réputation chez les développeurs. Pas de Docker, pas de Node, un shell limité, et ce réflexe de tout déposer par FTP « en attendant mieux ». Pourtant, pour un site vitrine ou un blog statique, c'est souvent l'option la plus raisonnable : quelques francs par mois, un serveur géré, et zéro maintenance d'infrastructure. Le problème n'est pas l'hébergement. C'est la manière de déployer dessus.

Ce site tourne sur un mutualisé Hostinger. Voici, sans rien enjoliver, comment il est mis en ligne — et les règles que je me suis fixées pour que ça reste propre dans la durée.

Règle n°1 : les sources ne vivent pas dans le dossier web

Sur un mutualisé, tout ce qui est dans public_html/ est servi au monde entier. C'est la première erreur que je vois sur les sites qu'on me demande de reprendre : le dossier .git, les fichiers Markdown d'origine, un config.bak, parfois un .env, tout est accessible en tapant la bonne URL.

Ma règle est simple : public_html/ ne contient que le résultat du build. Les sources du blog — articles en Markdown, script de génération, backlog éditorial — vivent dans un dossier voisin, blog-src/, hors de l'arborescence web. Il est versionné avec git (disponible sur le shell Hostinger), mais ce dépôt n'est jamais exposé.

domains/stackshaka.com/
  blog-src/        ← sources, git, jamais servi
    content/blog/fr/*.md
    content/blog/en/*.md
    build.php
  public_html/     ← uniquement le résultat du build
    fr/blog/
    en/blog/
    .htaccess

En complément, le .htaccess refuse l'accès à tous les fichiers cachés et à une liste d'extensions sensibles (.bak, .env, .md, .log, .sql…). Si un fichier se retrouve au mauvais endroit par erreur, il n'est pas servi pour autant. Ceinture et bretelles.

Règle n°2 : un build reproductible, avec les outils du serveur

Le shell Hostinger n'a pas Node. J'aurais pu construire le site sur ma machine et envoyer le résultat, mais je voulais que la génération puisse tourner directement sur le serveur, depuis un cron ou un agent automatisé, sans dépendre de mon ordinateur.

J'ai donc écrit le générateur en PHP — c'est ce qui est disponible, en version 8.3. Un seul fichier, build.php, qui lit les Markdown, parse le frontmatter et écrit les pages HTML, les index et les flux RSS. Pas de dépendances, pas de node_modules qui explose le quota d'inodes d'un hébergement partagé (un vrai risque : un projet JavaScript moyen, c'est facilement 30 000 fichiers).

cd blog-src && php build.php

Une commande, un résultat identique à chaque fois. Le build réutilise la feuille de style et les polices auto-hébergées du site existant : le blog n'introduit aucune dépendance nouvelle, et la CSP stricte reste intacte.

Règle n°3 : l'upload passe par SSH, jamais par FTP

Le FTP en clair transmet votre mot de passe sans chiffrement. Le FTP tout court vous fait déposer des fichiers un à un, sans savoir ce qui a changé. Hostinger fournit un accès SSH sur ses offres mutualisées ; je m'en sers pour tout.

Concrètement, un petit script Python encapsule la connexion : il lit les identifiants dans un fichier .env local (jamais versionné, jamais uploadé), exécute une commande distante ou envoie un fichier. Le déploiement d'un nouvel article se résume à trois étapes : envoyer les deux .md (FR et EN) dans blog-src/content/, lancer php build.php à distance, puis committer les sources dans git sur le serveur. Pour un site complet, rsync sur SSH fait le même travail en ne transférant que les différences.

Ce qui compte, ce n'est pas l'outil. C'est que chaque mise en ligne soit une commande, pas une série de clics.

Règle n°4 : un cache que vous pouvez expliquer

C'est là que la plupart des sites mutualisés se trompent, dans un sens ou dans l'autre. Soit aucun cache et chaque visite recharge tout ; soit un max-age d'un an sur tout, et une correction CSS met des semaines à atteindre les visiteurs.

Ma politique tient en deux règles, dans le .htaccess :

• Les pages HTML sont toujours revalidées (no-cache, must-revalidate). Un article corrigé est visible immédiatement.
• Les ressources statiques (CSS, JS, images, polices) sont mises en cache sept jours, avec stale-while-revalidate. Pas de immutable, pas d'un an : mes fichiers n'ont pas de nom hashé, donc une durée trop longue figerait les mises à jour chez les visiteurs déjà passés.

Le CSS est chargé avec un paramètre de version calculé depuis la date de modification du fichier. Si je modifie la feuille de style, le build change l'URL, et le cache est contourné sans que j'y pense. Compression Brotli et gzip activées pour le texte, désactivées pour les images déjà compressées.

Règle n°5 : prévisualiser sans publier

Un site statique n'a pas d'environnement de staging par défaut. J'en ai fabriqué un minimal : php build.php --preview <slug> rend un article, même en brouillon, dans un sous-dossier _preview/, avec une balise noindex. L'index du blog, le flux RSS et le sitemap ne sont pas touchés. Je relis l'article à sa vraie URL, dans son vrai design, puis je publie — ou pas. À la publication, le dossier d'aperçu est supprimé.

Règle n°6 : vérifier après chaque mise en ligne

Un déploiement n'est terminé que lorsqu'il est vérifié. Ma liste, à chaque fois :

• La page publiée ne contient pas de noindex résiduel.
• Elle est listée dans l'index et dans le flux RSS.
• Le sitemap.xml a été mis à jour, et il est toujours du XML valide (un php -r 'simplexml_load_file(...)' suffit).
• Les en-têtes de sécurité sont inchangés. Un curl -I sur la page compare la CSP à la référence.

Le .htaccess a une sauvegarde, et le sitemap aussi, avant chaque modification. Ça paraît excessif pour un blog. C'est ce qui permet de laisser un agent publier seul sans que je stresse.

Ce que ça change

Rien de tout ça n'exige un serveur dédié. Ce sont des habitudes, pas des outils : séparer sources et résultat, construire par script, déployer par commande, expliciter le cache, vérifier. Appliquées sur un mutualisé à quelques francs par mois, elles donnent un site aussi propre à livrer qu'une infrastructure bien plus coûteuse.

Si votre site actuel est déployé « à la main » et que vous n'êtes pas sûr de ce qui traîne dans son dossier web, c'est exactement le genre de chose que je remets d'aplomb en une journée. Parlons-en.