Techniquement : Hugo sans thème (layouts et partials écrits à la main), CSS sur mesure sans framework, pipeline qualité (lint, tokens, contraste, build) qui tourne à l’identique en local et en CI.

Pourquoi Hugo

Projet perso avec un double objectif : une vitrine professionnelle pour recruteurs et clients freelance, et un terrain d’entraînement pour monter en compétence sur du templating Go, du CSS sans dépendance, et une chaîne CI/CD tenue de bout en bout — sans sacrifier la lisibilité du contenu à la démonstration technique.

Un générateur de site statique répond aux deux à la fois. Côté vitrine, la cible (recruteurs, agents de recherche) n’a pas de rendu JS à franchir pour indexer le contenu, contrairement à une SPA. Côté apprentissage, le HTML/CSS produit reste la sortie principale — pas de couche framework JS entre l’auteur et le résultat, donc chaque décision (tokens, contraste, breakpoints) reste visible et vérifiable dans la feuille de style elle-même plutôt que dissoute dans un système de composants.

Contexte

• Site personnel, parti d’un squelette : thème installé, contenu en Lorem Ipsum, une seule page content/_index.md
• Aucune contrainte de delivery externe — le calendrier est le seul arbitre du scope
• Exigence posée dès la Phase 0 (avant tout contenu) : les quality gates et la CI existent avant que le contenu s’accumule, pas après
• Cible recruteurs/clients : le site doit rester une vitrine lisible, pas seulement un prétexte à empiler des scripts de vérification

Les contraintes

• Pas de framework CSS, pas de PostCSS, pas d’autoprefixer — seul css.Build (esbuild, natif Hugo) prend en charge la transpilation et les préfixes vendeur
• Une baseline navigateurs explicite (Chrome 105+, Firefox 121+, Safari 16+, Edge 105+) à tenir, alors que deux mécanismes différents la couvrent : transpilation de syntaxe d’un côté, blocage de features runtime non transpilables de l’autre
• Contraste ciblé à AAA (7:1) plutôt que le AA/RGAA (4.5:1), sans dérive silencieuse tolérée à mesure que la palette ou les composants évoluent
• Aucune valeur de couleur, d’espacement ou de breakpoint écrite en dur dans un composant — tout doit venir d’un token déclaré une seule fois
• Le hook pre-commit local et la CI doivent exécuter la même définition, pour qu’aucun contrôle qualité ne puisse diverger entre les deux

Les choix écartés

• Une revue manuelle du contraste à chaque changement de palette : tolérable une fois, pas répétable sans dérive — d’autant que la palette est passée de AA à AAA en cours de route, avec des marges initiales aussi fines qu’entre 7,00 et 7,06
• Une exemption CSS ajoutée « au cas où » dans la config Stylelint plutôt que prouvée : une feature ignorée sans vérification empirique dans public/ reste ignorée même quand la baseline évolue et que le support natif la couvre déjà
• Dupliquer la logique de vérification entre pre-commit et CI (deux configs qui divergent tôt ou tard) plutôt qu’une définition unique appelée par les deux

Décisions techniques

• Tokens CSS à deux niveaux d’indirection : palettes brutes (--light-*, --dark-*) jamais consommées directement par un composant, tokens sémantiques (--color-surface, --color-text-soft…) seuls exposés. Le dark mode change en réassignant les tokens sémantiques dans un seul fichier, sans toucher aux composants.
• Règle « zéro valeur en dur » appliquée par script, pas seulement documentée : check-tokens.mjs échoue sur toute couleur, taille ou durée littérale hors base/tokens.css ; l’échappatoire est un commentaire token-exception justifié inline, jamais un ajout silencieux à une liste d’ignore.
• Contraste vérifié automatiquement : check-contrast.mjs lit les valeurs hex directement dans tokens.css (aucune valeur dupliquée dans le script) et calcule chaque paire de couleurs, texte à 7:1, composants à 3:1. Un token de couleur non couvert par une paire est aussi un échec — sinon un token ajouté plus tard n’est simplement jamais mesuré.
• Breakpoints déclaratifs mais vérifiés à l’exécution : les media queries ne peuvent pas lire une custom property, donc les valeurs (768px, 576px) restent en dur — mais check-breakpoints.mjs échoue sur une largeur qui ne correspond à aucun token --bp-*, et sur un token que plus aucune query n’utilise.
• Deux rôles distincts pour tenir la baseline navigateurs : css.Build transpile la syntaxe (nesting, media query range syntax) à la compilation ; Stylelint (stylelint-no-unsupported-browser-features) bloque au lint les features runtime qu’aucun transpileur ne peut simuler (container queries, subgrid). Chaque entrée de la liste d’ignore Stylelint est justifiée par une vérification dans public/ après build, pas supposée — deux entrées obsolètes (:has(), scroll-behavior) ont été retirées une fois la baseline remontée et le support natif confirmé.
• lefthook.yml comme unique source de vérité qualité : le hook pre-commit local tourne sur les fichiers stagés, la CI appelle la même commande sur l’ensemble des fichiers trackés — aucune règle qualité ne peut exister dans l’un sans exister dans l’autre.
• Contenu piloté par cascade Hugo plutôt que par template dédié : la section /veille/ (teaser-only) utilise build.render = 'link' en cascade pour rester dans les collections (donc alimenter les pages /tags/*) sans générer de page de détail — contre render = 'never', qui exclurait l’entrée de toute collection. Comportement vérifié après build (--cleanDestinationDir) plutôt que supposé : aucune page public/veille/<entrée>/ générée, sitemap propre, RSS global exempt.

Résultat

Pas de métrique de production comparable au cas Drupal — c’est un site personnel, pas un site à trafic. L’angle est différent : une CI qui tolère zéro WARN Hugo, un contraste et des tokens vérifiés par script plutôt que revus à l’œil, et un pre-commit qui ne peut pas diverger de la CI par construction. Le pipeline qualité tient à jour avec le contenu, pas après coup.

• Refonte de site institutionnel
• Drupal 10+ (10.3.x à sa mise en ligne)
• Site multilingue
• Trafic international important (notamment saisonnier), allant jusqu’à 15 000 visites uniques quotidiennes

Les contenus du site sont structurés en trois espaces distincts par public cible :

• grand public (B2C)
• professionnels (B2B)
• relations publiques (PR)

Dans chacune de ces sections, les gabarits et comportements des types contenus sont partagés, il n’est donc ni pertinent ni requis de créer des types de contenus dédiés.

Les éléments de navigation du site (menu principal et breadcrumb) doivent refléter cette organisation, c’est-à-dire que l’élément “Accueil” du breadcrumb doit renvoyer vers la page d’accueil de la section.

Le besoin éditorial, formulé simplement : permettre au contributeur de rattacher chaque contenu à l’une des trois sections, pour que :

• le fil d’Ariane affiche la bonne page d’accueil de rattachement ;
• le menu du header reflète l’espace courant.

Les contraintes

• Un menu de header en deux temps : un premier bloc pour naviguer entre les trois espaces, un second pour les rubriques de l’espace courant. Entre ces deux menus, des éléments statiques s’intercalent, cassant le flux du rendu et compromettant l’intégration du menu. Le rendu du menu ne peut donc pas se reposer sur le rendu natif de Drupal et impliquerait une préparation en amont de l’affichage (hook_preprocess, duplication de blocks ou manipulation en javascript)
• Une classification de contenu à gérer sur chaque page pour piloter ces deux menus et le fil d’Ariane
• Un besoin de simplification de la contribution
• Côté technique, un choix délibéré de limiter autant que possible le recours aux hooks
• Cette notion doit aussi s’appliquer sur des pages techniques (Views, page de terme de taxonomie ou Controller)

L’approche la plus directe — une taxonomie dédiée en parallèle du menu, ou un menu par espace — revenait à maintenir deux structures pour une seule idée (l’appartenance à un espace), avec le risque classique de désynchronisation entre les deux au fil des évolutions.

Les choix écartés

• Un menu par section : multiplication du coût en maintenance et impact possible de performance (×3), requiert des hooks preprocess pour gérer l’élément actif du menu des landing pages de sections.
• Catégorisation par vocabulaire de taxonomie : deux sources de vérité alimentées manuellement (menu et termes de taxonomie), avec le risque de désynchronisation

Décisions techniques

Chaque contenu porte un champ optionnel qui référence l’un des trois éléments racine du menu principal (basé sur le plugin_id du MenuLinkTreeElement). Laissé vide, il prend pour valeur par défaut, par ordre de priorité :

1. Son élément parent, s’il est présent dans le menu
2. La page d’accueil générale

Cette valeur est calculée dans un ContextProvider, qui l’expose dans les blocks de menu. Deux blocks sont déclarés, tous deux basés sur le menu principal :

• Le menu des sections (B2C, B2B, PR)
• La navigation dans les enfants (niveau 1 et plus)

Le ContextProvider devient la source de vérité unique de la section active et permet de piloter l’affichage et le rendu des différents éléments via une couche d’abstraction rendant cette valeur accessible à l’ensemble du site, pas seulement les nodes.

À partir de cette valeur :

• le fil d’Ariane utilise la landing page correspondante comme racine, plutôt que systématiquement / ;
• le premier bloc du menu header affiche les liens vers les deux autres espaces (ex. dans l’espace B2B, il pointe vers B2C et PR) ;
• le second bloc affiche les enfants de l’élément racine de l’espace courant.

Le rendu dépend de cette valeur, pas de la route ni de l’utilisateur connecté — les contextes de cache natifs de Drupal (route, utilisateur, langue…) n’en savent rien. Deux conséquences concrètes sans contexte dédié :

• le filtrage du menu (accès autorisé ou refusé par élément selon l’espace, via AccessResult) n’est associé à aucun contexte de cache existant : Drupal peut resservir un menu déjà filtré pour le mauvais espace ;
• changer l’espace d’un contenu produit deux jeux de contextes de cache, avant et après, sans rien en commun aux yeux de Drupal — qui lève une erreur de redirection de cache.

Le cache context personnalisé rend l’espace explicite dans la clé de cache : le menu filtré n’est plus resservi au mauvais espace, et le changement d’espace d’un contenu ne provoque plus d’erreur de redirection de cache.

Le ContextProvider devient le point central de toute la mécanique, sans taxonomie parallèle à synchroniser ou de menu multiple à contribuer.

Résultat

En production, sans incident depuis la mise en ligne (septembre 2025), sur un site à fort trafic. La classification est prise en main par les équipes éditoriales sans formation particulière — un seul champ à renseigner, dont le sens (quel espace) leur est déjà familier puisqu’il reprend directement la structure du menu qu’elles connaissent.