Pare-Feu

A lire en cas d'urgence.

Propulsé par ...

2026-07-13 6 Min. lecture Devops Jidhay

Ayant vécu dans les années 2000, j’ai connu l’essor de WordPress avec son fameux pied de page “Propulsé par WordPress”. J’ai toujours trouvé cette idée amusante, car elle permet de donner de la visibilité à un logiciel ou une marque. Pour ce blog j’ai mis un pied de page équivalent mais certaines parties de la propulsion de ce site ne sont pas visibles.

La simplicité avant tout

Je voulais rester dans une approche Keep it simple, stupid (KISS). Les CMS comme WordPress nécessitent une pile technique complète Linux, Apache, MySQL, PHP (LAMP) en plus du CMS lui-même (moteur, extensions, thèmes). Ce sont autant d’éléments à maintenir et à sécuriser.

Je voulais également avoir une identité propre avec un nom de domaine personnalisé.

Dans le cadre de ma carrière professionnelle, j’ai eu l’occasion de travailler avec des outils de génération de sites statiques orientés documentation comme Javadoc ou tfplugindocs, mais je n’ai eu le déclic que lorsque j’ai découvert Github Pages et son générateur de sites statiques Jekyll.

L’approche Github Pages répondait à mes besoins mais je voulais que mon dépôt soit privé pour pouvoir gérer mes brouillons. À l’époque (~2017), Github ne proposait pas de dépôts privés gratuits. Ils ont changé leur politique en 2019 (annonce) mais j’avais déjà mis en place le reste de la fusée.

Le moteur de rendu

Travaillant de plus en plus au moment de la création du site avec le langage Go, c’est assez naturellement que je me suis tourné vers Hugo. Le binaire unique et les performances ont achevé de me convaincre quand j’ai testé plusieurs solutions comme Jekyll ou Pelican.

Le dépôt & la CI/CD

Github ne répondant pas à mes besoins, je me suis tourné vers Framagit qui est une instance GitLab maintenu par l’association Framasoft. L’avantage est que GitLab propose un système de gestion de la CI/CD sur le modèle des Github Actions.

J’ai mis en place un pipeline en trois étapes :

  1. Vérification grammaticale avec Grammalecte
  2. Génération du site avec Hugo
  3. Déploiement sur le serveur OVH via SFTP avec lftp

Vérification grammaticale

Écrivant mes articles en français, je voulais m’assurer que le contenu soit correct avant leur publication. Grammalecte est un correcteur grammatical open source dédié au français. Il est utilisé par LibreOffice, Firefox et Thunderbird.

Pour l’utiliser dans le pipeline, j’ai créé un script qui convertit les fichiers Markdown en texte brut via Pandoc.

J’ai dû ajouter un filtre lua pour que la conversion :

  • supprime les blocs de code
  • extrait le contenu des citations
  • remplace les puces par des tirets
-- Remove code blocks and inline code so Grammalecte doesn't flag them
function CodeBlock() return {} end
function Code() return pandoc.Str("") end

-- Unwrap blockquotes to their content (removes leading-space indentation)
function BlockQuote(el)
  return el.content
end

-- Replace bullet list markers with plain paragraphs (avoids tiret warnings)
function BulletList(el)
  local blocks = {}
  for _, item in ipairs(el.content) do
    for _, block in ipairs(item) do
      table.insert(blocks, block)
    end
  end
  return blocks
end

Le script suivant invoque Pandoc sur tous les fichiers Markdown du dossier content/, convertit le contenu en texte brut avec le filtre lua précédent, et sauvegarde le résultat dans le dossier plain/ avec l’extension .txt.

find ./content -iname "*.md" -type f -exec sh -c 'pandoc "${0}" --from markdown --to plain --wrap=none --lua-filter=strip-code.lua --output "./plain/$(basename ${0%.md}.txt)"' {} \;

Ensuite la ligne de commande Grammalecte est exécutée sur tous les fichiers du dossier plain/ et remonte les erreurs dans les logs du pipeline.

    for f in $(find ./plain -iname "*.txt" -type f); do
      result=$(grammalecte-cli.py --file "$f" --only_when_errors --opt_off typo 2>&1 \
        | grep -v "^Python \|^Grammalecte " || true)
      if [ -n "$result" ]; then
        echo "=== Grammar errors in $f ==="
        echo "$result"
      fi
    done

Génération du site

Hugo génère le dossier public/ contenant l’intégralité du site en HTML, CSS et JavaScript statiques via la ligne de commande suivante :

hugo

A ce dossier, j’ai rajouté un fichier .htaccess sur lequel je vais revenir dans la section sur l’hébergement.

Déploiement

Le contenu du dossier public/ est transféré vers le serveur web via SFTP à l’aide de l’outil lftp.

lftp -e "mirror -Rnev -P 10 public www ; quit" -u $SFTP_USERNAME,$SFTP_PASSWORD sftp://$SFTP_SERVER

La commande mirror synchronise le dossier local public/ avec le dossier www du serveur distant. Les fichiers supprimés localement sont également supprimés sur le serveur, et dix transferts s’effectuent en parallèle.

Comme le montre la ligne de commande précédente, les identifiants de connexion sont passés en tant que variables d’environnement. Les identifiants de connexion ne sont jamais écrits en clair dans le dépôt dans les paramètres du projet : Settings > CI / CD > Variables.

Variables GitLab CI

Les quatre variables à définir sont les suivantes.

  • SFTP_SERVER : nom du serveur SFTP OVH

  • SFTP_SERVER_FINGERPRINT : empreinte du serveur, récupérée avec la commande suivante

ssh-keyscan -t ssh-ed25519 $SFTP_SERVER 2>/dev/null
  • SFTP_USERNAME : nom d’utilisateur SFTP

  • SFTP_PASSWORD : mot de passe de l’utilisateur SFTP

Toutes ces informations sont disponibles dans la console d’administration de l’hébergeur.

L’hébergement

Pour l’hébergement, je n’avais besoin que de deux services :

  • un nom de domaine
  • un serveur web

Je suis partie sur l’offre OVH Web Hosting qui m’apportait les éléments suivants:

  • Serveur Web Apache Mutualisé
  • 1 Go de stockage SSD
  • Certificat SSL Let’s Encrypt
  • Accès FTP

Le coût est de 1,99 € HT par mois, soit 23,88 € HT par an. C’est un coût très faible pour un site personnel.

Cependant même si l’offre est très abordable, les options ne sont pas activées par défaut.

De plus la configuration du serveur Apache n’est pas assez restrictive et nécessite de déployer un fichier .htaccess pour améliorer le niveau de score de sécurité.

Activation du SFTP

Pour activer le SFTP dans l’espace OVH, je suis allé dans Web > Hébergements > Nom de votre hébergement > FTP - SSH

Espace FTP OVH

Par défaut, le SFTP est désactivé.

SFTP désactivé

Après activation, le champ passe à l’état activé.

SFTP activé

L’adresse du serveur SFTP ainsi que les identifiants se trouvent également dans le même écran :

Serveur SFTP OVH

Identifiants FTP OVH

Activation du SSL

Même si je déploie uniquement un site statique et qu’il n’y a pas d’information sensible transmise, la plupart des navigateurs affichent un avertissement lorsque le site n’est pas en HTTPS. Pour activer le SSL, je suis allé dans Web > Hébergements > Nom de votre hébergement > Multisite.

Espace SSL OVH

J’ai dû cliquer sur la molette du domaine, puis sur Modifier et activer l’option SSL, puis valider.

SSL activé

Sécurisation du serveur Apache

Sur les serveurs de type Apache, il est possible de modifier le comportement du serveur via un fichier .htaccess (documentation).

J’ai utilisé le site securityheaders pour avoir une première liste d’en-têtes HTTP de référence à déployer :

  • Strict-Transport-Security force la communication via HTTPS (documentation)
  • X-Frame-Options protège contre le clickjacking (documentation)
  • X-Content-Type-Options protège contre le cross-site Scripting en utilisant le sniffing MIME (documentation)
  • Content-Security-Policy protège contre le cross-site Scripting et d’autres attaques (documentation)
  • Referrer-Policy protège la vie privée de l’utilisateur en limitant les informations transmises dans l’en-tête HTTP Referer (documentation)
  • Permissions-Policy permet de désactiver certaines fonctionnalités du navigateur qui ne sont pas nécessaires pour le site comme la géolocalisation ou le micro (documentation)