Pourquoi migrer ?

SAR France — la section française des Sons of the American Revolution — dispose d’un site institutionnel qui existe depuis de nombreuses années sous WordPress. WordPress est une plateforme adaptée pour démarrer rapidement, mais au fil du temps, les contraintes s’accumulent : mises à jour de plugins à gérer, base de données MySQL à maintenir, hébergement dynamique coûteux, et une inertie éditoriale qui ralentit toute contribution ponctuelle.

L’idée a germé simplement : et si le site était un ensemble de fichiers Markdown stockés dans GitHub, compilés en HTML statique, servis depuis AWS à un coût maîtrisé ?

C’est ce que permet Hugo, le générateur de sites statiques écrit en Go. C’est ce projet que j’ai mené à bien, avec un outillage adapté.

L’outillage : Claude Anthropic via Kiro

La migration d’un site existant vers une nouvelle architecture implique un travail conséquent : extraction du contenu, reformatage des pages, reconstruction de la navigation, recréation du thème, et validation de l’intégrité des données.

Pour ce projet, j’ai utilisé Kiro, un environnement de développement assisté par IA qui s’appuie sur Claude d’Anthropic comme moteur de raisonnement. Cette combinaison s’est avérée efficace :

  • Kiro m’a permis de piloter la migration de façon structurée, en gardant un suivi des tâches directement dans le dépôt (le fichier TASKS.md en témoigne)
  • Claude a analysé les pages WordPress existantes, reformaté le contenu en Markdown propre, suggéré l’architecture des dossiers et généré les templates Hugo adaptés au style institutionnel de SAR France

Ce qui aurait pris plusieurs semaines de travail manuel a été ramené à quelques jours de développement ciblé. L’IA ne remplace pas la décision humaine — le choix de la palette de couleurs marine/or/crème, de la typographie, du ton institutionnel — mais elle accélère l’exécution de manière significative.

L’architecture résultante

Le dépôt source est public et consultable ici :
👉 github.com/gautric/preprod.sarfrance.org


preprod.sarfrance.org/
├── .github/          # GitHub Actions (CI/CD, build automatique)
├── .kiro/            # Configuration et tâches Kiro
├── archetypes/       # Modèles de nouveaux contenus Hugo
├── content/          # ✅ Tout le contenu du site en Markdown
│   ├── organisation/
│   ├── histoire/
│   ├── activites/
│   └── contact/
├── data/             # Données structurées (carousel, événements…)
├── static/           # Images, PDF, fichiers statiques
├── themes/
│   └── sarfrance-theme/  # Thème custom navy/gold/cream
└── hugo.toml         # Configuration principale

La structure est intentionnellement lisible par n’importe quel contributeur, même sans compétences techniques avancées.

Un avantage notable de cette approche : Hugo repose sur des formats ouverts (Markdown, YAML, HTML, TOML). Le contenu n’est enfermé dans aucun format propriétaire. Si un jour l’association souhaite changer de générateur de sites ou de plateforme, la migration sera simple — les fichiers restent exploitables en l’état. Ce choix s’inscrit dans une logique open source, où la portabilité des données et la transparence du code sont des priorités.

Avant / Après

Avant — WordPress.com (SaaS)

L’ancienne version du site reposait sur WordPress.com, la version SaaS de WordPress, à 60 €/an. Cette solution présente des avantages pour démarrer : hébergement inclus, interface d’administration clé en main, pas de serveur à gérer.

Mais sur la durée, les limites sont apparues clairement :

Flexibilité restreinte
La version SaaS bride considérablement les possibilités de personnalisation. Nombre de fonctionnalités qui sont gratuites dans WordPress auto-hébergé deviennent des extensions payantes : formulaires avancés, import/export de contenu, outils SEO, redirections…

Import/Export : un processus complexe
Exporter proprement son contenu depuis WordPress.com pour le migrer ailleurs présente des difficultés. Les outils gratuits sont limités, et récupérer l’intégralité du contenu structuré — pages, médias, métadonnées — sans passer par une extension payante reste un exercice contraignant.

Cohérence visuelle difficile à maintenir dans le temps
Le mode WYSIWYG de WordPress.com est accessible au premier abord, mais il présente des limites sur la durée. Chaque éditeur applique ses propres styles inline, ses propres choix de blocs, ses propres mises en page. Sur un site institutionnel alimenté par plusieurs contributeurs sur plusieurs années, le constat est récurrent : des pages visuellement incohérentes, des styles qui se contredisent, des layouts qui varient selon le navigateur ou la taille d’écran.

Le no-code est adapté pour commencer. Il pose en revanche un problème de maintenabilité sur le long terme.

Après — Hugo sur AWS

La nouvelle architecture repose sur une approche statique :

[Contributeur] → [Markdown sur GitHub] → [Hugo Build] → [Amazon S3 + Amazon CloudFront] → [Navigateur]

Le site est compilé en HTML/CSS/JS statique à chaque modification. Il n’y a plus de serveur applicatif, plus de base de données, plus de surface d’attaque dynamique.

Aperçu de la nouvelle architecture :

GitHub Repository (source de vérité)
    └─ content/ (Markdown)
    └─ data/ (YAML structuré)
    └─ themes/ (HTML/CSS/JS custom)
    └─ GitHub Actions (CI/CD automatique)
         └─ hugo build
              └─ Amazon S3 (hébergement statique)
                   └─ Amazon CloudFront (CDN mondial)

Une réduction significative des coûts

C’est l’un des arguments concrets de cette migration.

Poste Ancien (WordPress.com) Nouveau (Hugo/AWS)
Hébergement + CMS ~60 €/an ~6–12 €/an
Base de données Incluse Aucune
Mises à jour plugins ~2–3h/an Aucune
Certificat SSL Inclus Inclus (AWS Certificate Manager)
CDN mondial Optionnel, payant Inclus (Amazon CloudFront)

Pour un site institutionnel avec un trafic modéré, le coût mensuel sur AWS reste marginal.

Le contenu comme donnée : Markdown et GitHub

L’un des changements structurants est que le site est désormais un dépôt Git. Toute la documentation, les pages, les événements, les publications — tout est du Markdown versionné.

Ce choix ouvre des possibilités concrètes :

Contribution simplifiée

Un membre du bureau qui souhaite corriger une date ou mettre à jour un texte peut le faire directement depuis l’interface web de GitHub, sans installer quoi que ce soit. Le CONTRIBUTING.md du projet détaille pas à pas cette procédure, accessible à des non-développeurs.

Historique complet

Chaque modification est tracée avec son auteur et sa date. Il est possible de revenir à n’importe quel état antérieur du site en quelques secondes.

Pull Requests comme circuit de validation

Un rédacteur propose une modification → le webmaster la relit et la valide → le site se déploie automatiquement. C’est le workflow Git standard, adapté à la gouvernance d’une association.

Le pipeline CI/CD : zéro intervention humaine

Le déploiement est entièrement automatisé via deux workflows GitHub Actions :

  • hugo.yml : se déclenche à chaque push sur main et tous les jours à 6h UTC. Build Hugo v0.157.0 (extended) + Dart Sass + Node.js 24, puis déploiement sur GitHub Pages.
  • hugo-preview.yml : construit une prévisualisation sur chaque Pull Request, permettant de voir le résultat avant validation.
on:
  push:
    branches: ["main"]
  schedule:
    - cron: '0 6 * * *'   # Rebuild quotidien pour l'agenda
  workflow_dispatch:        # Déclenchement manuel si besoin

Le résultat : un contributeur qui corrige un texte voit la modification en ligne dans les deux minutes suivant son commit.

Données complexes sans complexité de code

L’un des arguments que j’entends souvent contre les générateurs de sites statiques : “C’est bien pour un blog, mais pour des données structurées ?”

Hugo répond à ce besoin via ses shortcodes et ses fichiers de données.

Exemple : la chronologie historique

SAR France a une vocation historique forte. La page de chronologie affiche des événements de la Guerre d’Indépendance américaine sur une frise temporelle. Avec Hugo, les données sont stockées dans un fichier YAML :

periodes:
  - nom: "Les Colonies (1607-1763)"
    events:
      - date: "1757-09-06"
        titre: "Naissance de La Fayette"
        description: "Naissance de Marie-Joseph Paul Yves Roch Gilbert du Motier, marquis de La Fayette."
        tags:
          - france
          - personnalité
        wikipedia: "https://fr.wikipedia.org/wiki/Gilbert_du_Motier_de_La_Fayette"

Un template Hugo parcourt ces données et génère automatiquement la frise. Aucune ligne de JavaScript complexe, aucun plugin à maintenir.

Exemple : l’agenda des événements

De même, les événements de l’année sont gérés via un fichier data/ structuré, rendu par un shortcode dédié. Ajouter un événement = ajouter trois lignes dans un fichier texte. La mise en page reste cohérente sans effort.

L’agenda couvre les activités de l’association depuis 2018 jusqu’en 2026. Les événements sont typés (conférence, assemblée, commémoration, visite, exposition…) et chaque type dispose de son icône et de sa couleur dans data/agenda.yaml :

types:
  commémoration:
    label: "Commémoration"
    icon: "🎖️"
    color: "#6b2737"
  conférence:
    label: "Conférence"
    icon: "🎤"
    color: "#5a6a3a"
  assemblée:
    label: "Assemblée"
    icon: "🏛️"
    color: "#2c5282"

events:
  - date: "2026-05-27"
    titre: "Cérémonies du Memorial Day"
    type: commémoration

Et grâce au rebuild quotidien automatique à 6h UTC via GitHub Actions, les événements passés disparaissent automatiquement de l’affichage sans aucune intervention humaine.

Exemple : les Hauts Lieux de la mémoire franco-américaine

SAR France recense les lieux emblématiques liés à l’histoire franco-américaine — monuments, champs de bataille, plaques commémoratives, demeures historiques. La page des Hauts Lieux présente ces sites avec leur localisation, leur description et leur contexte historique.

Le contenu de cette section a été généré par IA : Claude a produit les fiches descriptives de chaque lieu à partir de sources historiques, en respectant le ton institutionnel du site et les conventions de nommage franco-américaines. Cela a permis de constituer rapidement un corpus riche et cohérent, qui aurait demandé un travail de recherche et de rédaction considérable en mode manuel.

Comme pour la chronologie et l’agenda, cette page s’appuie sur la fonctionnalité data/ de Hugo pour séparer clairement les données de la présentation. Les informations sur chaque lieu sont stockées dans un fichier YAML structuré (data/hauts_lieux.yaml), tandis que le rendu visuel est géré par un template Hugo dédié :

# data/hauts_lieux.yaml
lieux:
  - nom: "Château de Versailles"
    ville: "Versailles"
    departement: "Yvelines"
    description: "Lieu de signature du traité de 1783 reconnaissant l'indépendance des États-Unis."
    periode: "Guerre d'Indépendance"
    tags:
      - diplomatie
      - traité
    coordonnees:
      lat: 48.8049
      lon: 2.1204

Le template Hugo parcourt site.Data.hauts_lieux.lieux et génère les cartes de chaque lieu avec un rendu homogène. Cette séparation vue/données est un pattern central du site : les contributeurs modifient uniquement le YAML, sans toucher au HTML ni au CSS. L’ajout d’un nouveau lieu se résume à quelques lignes dans le fichier de données.

Ce découplage illustre bien la philosophie retenue : les données structurées dans data/, la logique d’affichage dans les templates, et la GenAI comme accélérateur de production de contenu.

Ce que l’IA a changé dans ce projet

Un point important : l’IA n’a pas tout fait. Les décisions d’architecture, le choix des couleurs, la structure de navigation, la politique de contribution — c’est du travail humain de conception.

Mais voici ce que Claude (via Kiro) a concrètement accéléré :

  • Conversion du contenu WordPress → Markdown : analyse des exports XML, reformatage propre, correction des caractères spéciaux, normalisation des titres
  • Génération de l’architecture et des templates Hugo : à partir d’une description du rendu souhaité, Claude a proposé des layouts fonctionnels que j’ai ensuite affinés
  • Génération des shortcodes Hugo : les templates pour la chronologie et l’agenda ont été générés selon mes instructions afin d’obtenir la structure et le rendu souhaités
  • Rédaction de la documentation contributeur : le guide de contribution que l’on trouve dans le CONTRIBUTING.md a été co-rédigé avec Claude, en ciblant un public non-technique
  • Développement des pipelines GitHub Actions : création des workflows pour build Hugo, création de helpers pour les issues via les templates
  • Création du dictionnaire de notices biographiques : génération des données structurées et du layout Hugo pour un dictionnaire de 150 patriotes de la Guerre d’Indépendance, avec filtrage par catégories
  • Génération des Hauts Lieux de la mémoire franco-américaine : production par GenAI des fiches descriptives des lieux emblématiques, stockées dans data/hauts_lieux.yaml et rendues via un template Hugo dédié — séparation vue/données native
  • Traduction et mise en place du multilingue : restructuration du site pour le support fr/en natif de Hugo, traduction contextualisée de l’ensemble des pages par Claude, et mise en place d’un hook Kiro pour la traduction semi-automatique des nouveaux contenus

C’est cette combinaison — vision humaine + exécution assistée par IA — qui a rendu le projet viable dans un délai raisonnable.

Un autre bénéfice concret : les administrateurs de l’association peuvent formuler leurs demandes de modification en langage naturel. Il n’est plus nécessaire de convertir manuellement ces retours en code ou de passer par un traitement technique intermédiaire. Claude, via Kiro, interprète directement les remarques et applique les modifications sur le code du site. Cela réduit la friction entre les décideurs et le code, et rend le cycle de mise à jour accessible à des profils non-techniques.

Et la suite ?

Le dépôt est en pré-production (preprod.sarfrance.org). Plusieurs chantiers sont encore ouverts :

  • Formulaire de contact et paiement de cotisation : intégration d’un endpoint Amazon API Gateway pour les formulaires, sans introduire de serveur applicatif permanent
  • Magic link : partage sécurisé de fichiers via Amazon API Gateway, AWS Lambda, Amazon DynamoDB, Amazon SES et Amazon S3 presigned URLs — sans compte à créer
  • Enrichissement éditorial : dictionnaire biographique des patriotes français, galerie photographique des cérémonies
  • GitHub Pages → Amazon S3 : le site est actuellement en pré-production sur GitHub Pages. La mise en production prévoit une migration vers Amazon S3 et Amazon CloudFront.

Le modèle est en place. L’infrastructure est opérationnelle. La contribution est ouverte.

Conclusion

Cette migration illustre un principe : la technologie doit servir l’organisation, pas l’inverse. SAR France n’a pas besoin d’une équipe de développeurs pour maintenir son site — elle a besoin d’un outil simple, fiable et économique, que ses membres peuvent alimenter sans friction.

Hugo sur AWS, avec GitHub comme colonne vertébrale et Claude via Kiro comme accélérateur de migration, répond à ce besoin.

Le code source est ouvert. Les contributions sont bienvenues.

👉 github.com/gautric/preprod.sarfrance.org

Annexe — Traduction du site : le multilingue par la GenAI

SAR France est par nature une association franco-américaine. Un site uniquement en français ne suffit pas — les membres américains, les correspondants outre-Atlantique et les visiteurs anglophones doivent pouvoir naviguer dans leur langue.

Restructuration du site pour le multilingue

Hugo gère nativement le multilingue via une organisation par répertoires de langue. Chaque langue dispose de sa propre arborescence sous content/ :

content/
├── fr/
│   ├── histoire/
│   │   └── _index.md
│   ├── activites/
│   │   └── _index.md
│   └── ...
├── en/
│   ├── histoire/
│   │   └── _index.md
│   ├── activites/
│   │   └── _index.md
│   └── ...

La configuration Hugo a été adaptée pour déclarer les deux langues avec leurs répertoires respectifs, le français comme langue par défaut :

defaultContentLanguage = "fr"

[languages]
  [languages.fr]
    languageName = "Français"
    contentDir = "content/fr"
    weight = 1
  [languages.en]
    languageName = "English"
    contentDir = "content/en"
    weight = 2

Le thème a été enrichi d’un sélecteur de langue dans la navigation, et les chaînes de caractères de l’interface (menus, boutons, libellés) sont externalisées dans les fichiers i18n/fr.yaml et i18n/en.yaml. Cette restructuration — renommage de dizaines de fichiers, adaptation des templates, création des fichiers i18n — a été réalisée avec Claude via Kiro en quelques heures.

Traduction du contenu par Claude

La traduction de l’ensemble des pages du site a été effectuée par Claude. Pas une traduction mot-à-mot, mais une traduction contextualisée : le ton institutionnel est préservé, les noms propres et les références historiques sont adaptés aux conventions anglophones (dates, titres, appellations), et les formulations sont naturelles.

Par exemple, la page sur la chronologie de la Guerre d’Indépendance a été traduite en tenant compte du fait que les lecteurs anglophones connaissent ces événements sous des noms différents (Battle of Yorktown plutôt qu’une traduction littérale de “Bataille de Yorktown”).

Un hook Kiro pour la traduction semi-automatique

Pour maintenir la parité linguistique dans le temps, un mécanisme semi-automatique a été mis en place via les hooks Kiro. Le principe est simple : lorsqu’un fichier Markdown est créé sous content/fr/, un hook déclenche automatiquement une demande de traduction vers l’anglais dans le répertoire content/en/ correspondant.

{
  "enabled": true,
  "name": "Create English page from new French page",
  "description": "When a new French content page (content/fr/**/*.md) is created, automatically creates the corresponding English translation under content/en/.",
  "version": "1",
  "when": {
    "type": "fileCreated",
    "patterns": [
      "content/fr/**/*.md"
    ]
  },
  "then": {
    "type": "askAgent",
    "prompt": "A new French content page was just created. Create its English counterpart:\n\n1. Identify the new file path under `content/fr/` and derive the matching English path under `content/en/` (same relative path, just replace `fr` with `en`).\n2. Read the new French file.\n3. Translate the content into English, preserving:\n   - The exact same YAML front matter structure (translate field values like `title`, `description`, `subtitle`, etc.)\n   - The same Markdown structure, shortcodes, and links\n   - Any Hugo-specific syntax (params, shortcodes, front matter keys) must remain unchanged\n   - Only translate the human-readable text, not the keys or technical markup\n4. Create the English file at the derived path.\n5. Do NOT modify the French file.\n6. Do NOT commit — just write the English file."
  }
}

Concrètement, le workflow est le suivant :

  1. Un contributeur crée ou modifie une page en français sous content/fr/ dans Kiro
  2. Le hook détecte la modification et demande à Claude de produire la version anglaise
  3. Claude génère la traduction dans le fichier correspondant sous content/en/
  4. Le contributeur relit et valide (ou ajuste) la traduction

Ce système est semi-automatique par choix : la traduction est générée instantanément, mais un humain garde la main sur la validation finale. C’est un équilibre entre productivité et qualité — l’IA fait le gros du travail, le contributeur s’assure que le résultat est fidèle.