Le développement de ce site

Ce site n’a pas été créé avec un outil « clé en main » comme WordPress ou Wix. Je l’ai construit à partir de briques open source, je l’héberge dans le cloud et il se met à jour automatiquement à chaque nouvelle publication.

Cette fiche présente les technologies utilisées, sans entrer dans tous les détails : l’objectif est d’avoir une vue d’ensemble et de savoir quelles compétences il faut pour travailler sur un projet comme celui-ci.

Vue d’ensemble

Du texte que j’écris jusqu’à la page que tu lis, voici le chemin parcouru :

J’écris une page en Markdown ou MDX, sur une branche Git dédiée.
Je pousse la branche sur GitLab et j’ouvre une merge request vers master.
Au merge, un pipeline GitLab CI se déclenche automatiquement.
Le pipeline construit une image Docker qui contient le site, et la stocke dans Google Artifact Registry.
Le pipeline déploie cette image sur Google Cloud Run, où un serveur nginx sert les pages.

Frontend

Astro, Starlight, starlight-blog, Markdown/MDX, CSS

Hébergement

Docker, nginx, Google Cloud Run, Artifact Registry

CI/CD

Git, GitLab, GitLab CI, Kaniko, gcloud

Outillage

Node.js, npm, TypeScript

Le frontend

Astro, le générateur de site

Astro est un framework web orienté contenu. Ici, il est utilisé comme générateur de site statique : au moment du build, il transforme les fichiers de contenu en pages HTML prêtes à être servies. Aucun code ne tourne côté serveur quand un visiteur consulte une page, ce qui rend le site rapide, léger et simple à héberger.

Astro prend aussi en charge :

l’optimisation des images : les images sont redimensionnées et converties au format WebP lors du build, grâce à la bibliothèque sharp (guide des images) ;
les redirections : quand une page change d’adresse, l’ancienne URL renvoie vers la nouvelle au lieu d’afficher une erreur 404 (guide du routage).

Starlight et starlight-blog, le thème

Starlight est le thème de documentation officiel d’Astro. Il fournit la structure du site : menu latéral généré à partir des dossiers, recherche intégrée, mode sombre, navigation adaptée au mobile et composants prêts à l’emploi (cartes, encadrés, étapes…).

Le plugin starlight-blog ajoute la partie blog : liste des articles, images de couverture et tags.

Le contenu : Markdown, MDX et collections

Les pages sont écrites en Markdown, un format texte très simple, ou en MDX, qui permet d’y insérer des composants. C’est ce qui donne les cartes et les encadrés de mes fiches de révision.

Le contenu est organisé en collections de contenu : chaque page commence par un en-tête (le frontmatter) dont les champs sont validés par un schéma. Une page sans titre, par exemple, fait échouer le build au lieu d’être publiée cassée.

Directorysrc/
- Directoryassets/ images des fiches, témoignages et page d’accueil
  - Directoryblog/ images de couverture des articles du blog
    …
- Directorycontent/
  - Directorydocs/
    Directoryblog/ articles du blog
    …
    Directoryformations/ fiches de formation
    …
    Directorypensees-positives/
    …
    Directorytemoignages/
    …
- content.config.ts schéma des collections
- Directorystyles/
  - custom.css styles personnalisés
astro.config.mjs configuration du site
Dockerfile
.gitlab-ci.yml

---
title: Le développement de ce site
description: Les technologies derrière ce site…
date: 2026-09-28
tags: [informatique, développement web]
---

Le style

Le thème est personnalisé avec une feuille de CSS : frise chronologique, grille de trois cartes, bloc « à retenir » des fiches de révision… Chaque style est pensé pour fonctionner en mode clair et en mode sombre, et pour s’adapter aux petits écrans.

Le « backend » : l’hébergement

Comme le site est statique, il n’y a ni serveur applicatif ni base de données. Le travail côté serveur consiste à servir des fichiers de façon fiable, rapide et automatisée.

Docker : empaqueter le site

Docker permet d’empaqueter une application et tout ce dont elle a besoin dans une image, qui fonctionnera de la même façon partout.

Le Dockerfile du site utilise une construction en plusieurs étapes (multi-stage build) :

# --- Étape de build ---
FROM node:22-alpine AS build
RUN npm ci
RUN npm run build

# --- Étape de service ---
FROM nginx:1.27-alpine AS runtime
COPY --from=build /app/dist /usr/share/nginx/html

Une première image, avec Node.js et npm, installe les dépendances et construit le site.
Une seconde image, beaucoup plus légère, ne garde que le résultat du build et le serveur web. Les outils de développement ne partent pas en production.

nginx : servir les pages

nginx est le serveur web qui répond aux visiteurs. Sa configuration gère :

la correspondance entre une adresse et la bonne page HTML ;
la page d’erreur 404 personnalisée ;
la mise en cache des images, feuilles de style et scripts pendant 30 jours ;
le port d’écoute, fourni par Cloud Run à travers une variable d’environnement.

Google Cloud Run : exécuter le conteneur

Cloud Run est un service de Google Cloud qui exécute des conteneurs sans avoir à gérer de serveur : il démarre et arrête les instances selon le trafic. Les images Docker du site sont stockées dans Artifact Registry, le registre d’images de Google Cloud, dans la région europe-west1.

Le CI/CD : publier automatiquement

CI/CD signifie Continuous Integration / Continuous Deployment (intégration et déploiement continus) : chaque modification validée est construite et mise en ligne automatiquement, sans manipulation manuelle.

Git et GitLab : le workflow

Le code est versionné avec Git et hébergé sur GitLab. Je ne modifie jamais directement la branche principale master :

chaque nouveauté (article, fiche, correction) est développée sur une branche dédiée (feat/..., fix/...) ;
elle est ensuite intégrée par une merge request, qui permet de relire l’ensemble des changements avant publication ;
le merge dans master déclenche la mise en ligne.

Le pipeline GitLab CI

Le pipeline est décrit dans le fichier .gitlab-ci.yml (documentation GitLab CI/CD). Il ne se lance que sur la branche principale, et comporte deux étapes :

stages:
  - build
  - deploy

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

build:
  stage: build
  image: gcr.io/kaniko-project/executor:v1.23.2-debug
  # construit l'image Docker et la pousse dans Artifact Registry

deploy:
  stage: deploy
  image: google/cloud-sdk:slim
  # gcloud run deploy : déploie la nouvelle image sur Cloud Run

1. Build

Kaniko construit l’image Docker sans démon Docker, ce qui est adapté à un environnement de CI. L’image est taguée avec l’identifiant du commit, pour savoir exactement quelle version tourne en production.

2. Deploy

L’outil en ligne de commande gcloud déploie cette image sur Cloud Run. Le pipeline s’authentifie auprès de Google Cloud avec un compte de service, dont la clé est stockée dans les variables protégées de GitLab et jamais dans le code.

Les compétences mobilisées

Domaine	Compétences
Frontend	HTML, CSS (thèmes clair/sombre, responsive), Markdown et MDX, composants Astro/Starlight
Outillage	Node.js, npm et gestion des dépendances, configuration TypeScript
Conteneurisation	Docker, builds multi-étapes, configuration de nginx
Cloud	Google Cloud Run, Artifact Registry, comptes de service, CLI gcloud
CI/CD	Git, workflow par branches et merge requests, pipelines GitLab CI en YAML, gestion des secrets
Maintenance	Lecture de logs de pipeline, diagnostic d’erreurs de build, redirections d’URL