Je cherche désormais cinq propriétés en même temps : des identifiants à durée de vie courte, des builds réchauffés sur des runners neufs, des uploads prévisibles, des en-têtes de cache cohérents avec les fichiers livrés, et une cohérence de cache automatique. Cette configuration me donne les cinq sans ajouter de scripts de déploiement propres à chaque dépôt.

Pipeline en un coup d’œil

En régime de production nominal, le workflow de ce dépôt fait maintenant trois choses :

1. Récupère le dépôt.
2. Installe Deno avec la version verrouillée dans .tool-versions et active le cache outillage du runner.
3. Exécute l’action de synchronisation OSS/CDN, qui restaure _cache, lance deno task build, synchronise _site, rafraîchit le CDN et nettoie.

À ce stade, ce build fingerprint aussi la feuille partagée et les feuilles critiques par route, retire les source maps et supprime les fichiers optionnels de Pagefind qui ne sont plus référencés par le HTML final avant la synchro de _site.

name: Deploy static content to OSS

on:
  push:
    branches: ["master"]
  workflow_dispatch:

permissions:
  contents: read
  id-token: write

concurrency:
  group: "oss-deploy"
  cancel-in-progress: true

jobs:
  deploy:
    environment:
      name: development
    runs-on: macos-26
    steps:
      - name: Checkout
        uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: Setup Deno environment
        uses: denoland/setup-deno@v2
        with:
          deno-version-file: .tool-versions
          cache: true

      - name: Deploy to Alibaba Cloud OSS
        uses: frenchvandal/aliyun-oss-cdn-sync-action@master
        with:
          role-oidc-arn: ${{ secrets.ALIBABA_CLOUD_ROLE_ARN }}
          oidc-provider-arn: ${{ secrets.ALIBABA_CLOUD_OIDC_PROVIDER_ARN }}
          role-session-name: ${{ github.run_id }}
          role-session-expiration: 3600
          cache-enabled: true
          cache-key: >-
            lume-cache-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('deno.lock') }}-${{ hashFiles('_cache/**/*') || 'empty' }}
          cache-restore-keys: |
            lume-cache-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('deno.lock') }}-
            lume-cache-${{ runner.os }}-${{ runner.arch }}-
          input-dir: _site
          bucket: ${{ secrets.OSS_BUCKET }}
          region: ${{ secrets.OSS_REGION }}
          audience: ${{ github.repository_id }}
          cdn-enabled: true
          cdn-base-url: ${{ secrets.OSS_CDN_BASE_URL }}
          cdn-actions: refresh
          build-command: deno task build

Dans ce dépôt, j’utilise maintenant cdn-actions: refresh. L’action supporte toujours refresh,preload, mais le workflow de ce site n’active plus le preload à chaque déploiement.

Pourquoi OIDC plutôt que des clés d’accès

L’action utilise GitHub OIDC pour endosser un rôle RAM Alibaba Cloud à l’exécution. Aucune clé d’accès longue durée n’est stockée dans le dépôt. Le workflow n’a besoin que de id-token: write, de l’ARN du rôle RAM et de l’ARN du fournisseur OIDC.

L’authentification est désormais strictement OIDC : l’action ne retombe pas sur des access keys statiques passées en entrée ou via l’environnement si la prise de rôle échoue.

La configuration actuelle transmet aussi audience: ${{ github.repository_id }}. GitHub peut émettre un ID token avec une audience personnalisée, et Alibaba Cloud RAM peut valider cette valeur aud par rapport aux Client ID configurés sur le fournisseur d’identité OIDC et dans la trust policy du rôle. La frontière de confiance est donc plus resserrée qu’avec l’audience par défaut seule.

Fonctionnement interne de l’action

L’action est découpée en trois phases :

• pre : endosse le rôle RAM via OIDC et stocke des identifiants temporaires dans l’état de l’action.
• main : restaure éventuellement le dossier local _cache, exécute build-command, upload les fichiers locaux sur OSS, applique les en-têtes de cache et déclenche les actions CDN si elles sont activées.
• post : compare les objets distants sous le préfixe cible avec les fichiers locaux produits par le build, supprime les orphelins côté distant, rafraîchit au besoin les URL supprimées, écrit des résumés d’exécution CDN et peut sauvegarder _cache si cache-key est configuré.

La phase de nettoyage s’exécute avec post-if: always(), donc elle se lance même si des étapes précédentes échouent. Le nettoyage, les appels CDN et la restauration ou sauvegarde du cache sont volontairement non bloquants : les avertissements sont journalisés, mais des incidents CDN ou cache transitoires n’interrompent pas le déploiement.

Upload, cache, quota et contrôle de dérive

Quelques détails d’implémentation comptent pour la fiabilité :

• build-command s’exécute dans l’action avant tout upload OSS ou appel CDN.
• Si cache-enabled vaut true et que cache-key est configuré, _cache est restauré avant le build et un nouvel instantané peut être sauvegardé pendant post.
• cache-enabled ne contrôle que la restauration : je peux donc neutraliser le warm cache temporairement sans perdre la sauvegarde de cache en post-step.
• Les uploads sont parallélisés via max-concurrency.
• Un throttling global d’API est appliqué avec api-rps-limit.
• Chaque upload de fichier est retenté jusqu’à trois fois avant d’être marqué en échec.
• Les échecs partiels d’upload remontent via failed-count et le résumé du job GitHub Actions au lieu d’être noyés dans les logs.
• L’étape d’upload écrit désormais automatiquement des en-têtes Cache-Control : les fichiers HTML et sw.js sont revalidés de manière agressive, les assets hashés sont envoyés comme immuables, et les ressources statiques courantes reçoivent des fenêtres de revalidation plus courtes au lieu d’une politique unique pour tout.
• cdn-actions n’accepte que refresh ou refresh,preload ; si le CDN est activé et que la valeur est vide ou invalide, l’action retombe sur refresh.
• L’action vérifie le quota CDN restant avant de soumettre des lots de refresh ou de preload.
• La suppression d’objets OSS peut déclencher un refresh CDN des URL supprimées, ce qui réduit les fenêtres de cache obsolète et limite la dérive des objets dans le temps.
• L’action écrit aussi un résumé GitHub Actions pour le déploiement, le nettoyage et l’état des tâches CDN.

Ce dernier point est facile à sous-estimer : l’upload seul ne suffit pas pour un site statique qui évolue. Il faut aussi gérer la suppression et l’invalidation de cache des objets qui ne devraient plus exister.

Permissions RAM minimales

Au niveau des politiques, le rôle a besoin de permissions OSS sur le scope du bucket cible pour lister, uploader et supprimer les objets. Côté CDN, ce workflow a besoin des permissions de refresh ainsi que des API de lecture utilisées pour les contrôles de quota et le suivi des tâches. Si le preload est activé, il faut y ajouter la permission correspondante. La trust policy doit autoriser le fournisseur OIDC GitHub à endosser le rôle de déploiement.

Je conserve ce rôle comme rôle de déploiement dédié, sans le mélanger à des permissions opérationnelles plus larges.

Réutiliser l’action dans d’autres dépôts

L’action est publiée et réutilisable : github.com/frenchvandal/aliyun-oss-cdn-sync-action.

Ce dépôt suit actuellement @master parce que je fais évoluer le site et l’action ensemble. Dans un autre dépôt, j’épinglerais plutôt @v1, voire un SHA de commit complet. Je laisse maintenant l’action piloter le build et le cycle de vie de _cache, ce qui raccourcit encore le workflow consommateur.

Pour moi, le résultat clé reste le même : des déploiements prévisibles. Restauration du cache, build, sync, refresh, cleanup, terminé.

Tout le monde connaît la formule, mais peu de personnes en connaissent l’origine. Il s’agit d’un extrait brouillé du de Finibus Bonorum et Malorum de Cicéron, un traité philosophique rédigé en 45 av. J.-C. Ce texte est utilisé comme faux contenu depuis le XVIe siècle, lorsqu’un imprimeur inconnu a mélangé une casse de caractères pour créer un spécimen typographique.

Pourquoi le texte de remplissage compte

Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Quand vous concevez une mise en page avec de vrais mots, vous concevez pour ces mots précis. Le faux texte vous oblige à concevoir pour la structure, pas pour le sens. C’est une contrainte utile : elle révèle si votre design peut absorber l’imprévu : un titre sur trois lignes, un paragraphe sans respiration naturelle, un mot trop long pour son conteneur.

Une question de fidélité

Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam ? En design, il existe une tension entre la fidélité au contenu réel et la liberté qu’autorise l’abstraction.

Les prototypes haute fidélité avec du vrai contenu exigent que ce contenu existe déjà. Les wireframes basse fidélité, eux, communiquent la structure sans la distraction du sens. Les deux approches ont leur place. L’essentiel est de savoir quel outil sert le moment.

// A small utility to generate repeating text blocks.
function lorem(words: number): string {
  const base = "lorem ipsum dolor sit amet consectetur adipiscing elit";
  const tokens = base.split(" ");
  const result: string[] = [];
  for (let i = 0; i < words; i++) {
    result.push(tokens[i % tokens.length] ?? "");
  }
  return result.join(" ");
}

Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt.

Conclusion

Le lorem ipsum est plus qu’un simple remplissage. C’est un miroir tendu au design : il reflète la structure dépouillée de sens, la forme sans contenu. C’est précisément pour cela qu’il traverse les époques.

Un seuil n’est ni une fin, ni un commencement. C’est l’espace liminal entre les deux : le souffle retenu avant le premier mot, la pause après le tour de clé. C’est l’endroit où quelque chose s’achève et où autre chose n’a pas encore commencé.

La valeur de l’entre-deux

Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Nous vivons dans une culture qui dévalue la transition. Nous voulons des résultats, des livrables, l’objet fini. Le milieu brouillon, les brouillons successifs, le doute, l’accumulation lente de compréhension, tout cela reste peu documenté et rarement célébré.

Pourtant, l’entre-deux est l’endroit où se déroule l’essentiel de la vie. Les trajets. Les salles d’attente. Le temps entre l’envoi d’un message et la lecture de la réponse. Les années entre le moment où l’on sait ce que l’on veut et celui où l’on sait comment l’obtenir.

Se tenir sur le pas de la porte

Fusce suscipit varius mi. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Phasellus viverra nulla ut metus varius laoreet.

J’ai déménagé à Chengdu un mardi du début d’automne. La ville était chaude d’une manière qui m’a surpris, non pas la chaleur de l’été, mais la chaleur d’un lieu qui avait déjà décidé qu’il vous appréciait. Les rues sentaient l’huile pimentée et l’osmanthe, et tout semblait légèrement, agréablement familier et nouveau à la fois.

C’est cela, un seuil, je crois. Ni hostile, ni accueillant. Simplement ouvert, en attente de ce que vous en ferez.

Coda

Quisque sit amet est et sapien ullamcorper pharetra. Vestibulum erat wisi, condimentum sed, commodo vitae, ornare sit amet, wisi. Aenean fermentum, elit eget tincidunt condimentum, eros ipsum rutrum orci, sagittis tempus lacus enim ac dui.

Chaque texte possède son vestibule, la page de titre, l’introduction, le premier paragraphe. C’est l’espace qui prépare la lectrice ou le lecteur à ce qui vient ensuite. Il faut l’écrire avec soin.

Un bon logiciel réduit les frictions. Il anticipe l’étape suivante de l’utilisateur. Il propose la bonne affordance au bon moment. Il s’efface.

L’inventaire des frictions

Proin in tellus sit amet nibh dignissim sagittis. La première étape pour réduire les frictions est de les cartographier. Où l’utilisateur ralentit-il ? Où l’attention monte-t-elle ? Où les erreurs se concentrent-elles ?

Dans une application web classique, les moments de forte friction sont prévisibles : onboarding, envoi de formulaire, récupération après erreur et états de chargement. Ce sont les vestibules du produit, les seuils que l’utilisateur doit franchir pour atteindre la valeur.

// Friction shows up in code too.
// Compare these two approaches to handling a missing value:

// High friction — the caller must always check:
function getUser(id: string): User | undefined {/* … */}

// Lower friction — the error is explicit and handled at the boundary:
function getUser(id: string): User {
  const user = db.find(id);
  if (user === undefined) {
    throw new Error(`User not found: ${id}`);
  }
  return user;
}

Le paradoxe de la simplicité

Vivamus pretium aliquet erat. Il y a un paradoxe au cœur du « rendre simple » : c’est difficile. Éliminer les frictions demande une compréhension fine de l’utilisateur, du contexte et des modes d’échec. Cela exige plus de travail côté concepteur pour en demander moins côté utilisateur.

C’est pour cela que la simplicité est une forme de générosité. Chaque étape inutile retirée du parcours rend du temps à l’utilisateur, du temps qu’il peut consacrer à ce qui compte vraiment.

Facilisis en pratique

Donec aliquet metus ut erat semper, et tincidunt nulla luctus. Quelques principes vers lesquels je reviens régulièrement :

• Les valeurs par défaut doivent convenir à la majorité des usages.
• Les messages d’erreur doivent expliquer le problème et la correction.
• Le chemin nominal ne devrait demander aucun effort mental.
• La configuration doit être possible, jamais obligatoire.
• La documentation fait partie intégrante du produit.

Nulla facilisi. Phasellus blandit leo ut odio. Nam sed nulla non diam tincidunt tempus. Le nom même de ce principe — nulla facilisi, « rien de facile » — rappelle que la simplicité, bien comprise, n’est jamais accidentelle.

La manière la plus simple et la plus rapide de configurer ce thème est d’utiliser la commande Lume init, que vous pouvez aussi copier facilement depuis la page du thème Simple Blog. En lançant :

deno run -A https://lume.land/init.ts --theme=simple-blog

vous créez un nouveau projet avec Simple Blog déjà configuré. Modifiez ensuite le fichier _data.yml à la racine du blog pour personnaliser le titre, la description et les métadonnées du site.

Les articles doivent être enregistrés dans le dossier posts. Par exemple : posts/my-first-post.md.

Installer en tant que thème distant

Pour ajouter ce thème à un projet Lume existant, importez-le dans votre fichier _config.ts comme module distant. Pour le mettre à jour, changez le numéro de version dans l’URL d’import :

import lume from "lume/mod.ts";
import blog from "https://deno.land/x/lume_theme_simple_blog@v0.15.6/mod.ts";

const site = lume();

site.use(blog());

export default site;

Copiez ensuite le fichier _data.yml à la racine de votre blog et adaptez-le avec vos informations.

Personnalisation

Vous pouvez utiliser lumeCMS pour personnaliser le blog et ajouter du contenu facilement.