Arpeteria — Plateforme de diffusion culturelle savoyarde (Astro, Directus, Docker)

Site en ligne : arpeteria.net-flow.fr — Code : github.com/Radiowar1792/arpeteria (dépôt public)

Contexte

Mon frère est conservateur dans un musée et passionné par la culture et la langue savoyarde (arpitan) : textes anciens, chansons, grammaires, créations contemporaines. Il avait besoin d’un outil pour référencer, numériser et diffuser ce patrimoine — sans dépendre de moi à chaque publication. J’ai conçu et déployé Arpeteria de bout en bout, seul, pour un vrai utilisateur non-technique — pas un exercice académique.

Ce que j’ai fait

Architecture & infrastructure — le cœur du projet

• Monorepo découpé en modules indépendants et remplaçables : apps/web (frontend), cms/ (config Directus versionnée), infra/ (reverse proxy, sauvegardes), scripts/, docs/
• Orchestration Docker Compose de 6 services en production sur un VPS Debian 12 : PostgreSQL 16 (données applicatives), Directus 11 (CMS headless), build Astro (site statique), Umami + sa propre instance Postgres (analytics), et Caddy 2 (reverse proxy)
• Réseaux Docker segmentés (internal / web / umami) : la base de données applicative n’est jamais joignable depuis le réseau du reverse proxy, et l’analytics tourne dans son propre réseau cloisonné
• Caddy en façade unique : routage multi-domaine (arpeteria.net-flow.fr → site, admin.arpeteria.net-flow.fr → Directus), HTTPS automatique via Let’s Encrypt, en-têtes de sécurité (CSP, X-Frame-Options, nosniff)
• Pipeline de publication autonome : un Flow Directus appelle un webhook géré par un service systemd dédié (arpeteria-rebuild-webhook), qui relance le build Astro et republie le site en ~2 minutes — sans aucune intervention technique du conservateur
• Stratégie de sauvegarde 3-2-1 : dump PostgreSQL quotidien + archivage incrémental du volume de fichiers (scans patrimoniaux, donc irremplaçables) vers un stockage externe
• Analytics auto-hébergées (Umami) plutôt que Google Analytics : plus léger, données maîtrisées, pas de bandeau de consentement nécessaire

Développement & modélisation — pour prouver que ce n’est pas que de l’infra

• Modèle de données conçu dans Directus (œuvres, catégories, personnages, lieux, recommandations) avec formulaires conditionnels adaptés à un éditeur non-développeur
• Frontend Astro 6 (SSG) : une page HTML par œuvre, TypeScript pour le client API Directus et les helpers SEO
• SEO structuré avancé : JSON-LD Schema.org typé selon le contenu (Book/VideoObject/AudioObject/Article/Person/LandmarkOrHistoricalBuilding), sitemap, fil d’Ariane balisé
• Recherche full-text côté client avec Pagefind (index généré au build, aucun serveur de recherche à maintenir), avec facettes par section/type/langue/catégorie
• Thème sombre/clair, feuille de style d’impression dédiée, flux RSS, classement par orthographe savoyarde (ORB, graphie de Conflans…) — fonctionnalités ajoutées itérativement suite aux retours d’usage réels du conservateur

Architecture de production

Caddy (reverse proxy, HTTPS auto)
  ├── arpeteria.net-flow.fr        → web (build statique Astro)
  └── admin.arpeteria.net-flow.fr  → directus:8055
                                 │
                                 ├── database (PostgreSQL 16) — réseau "internal" uniquement
                                 └── volume /uploads (PDF, images)

umami (analytics) + umami-database  — réseau "umami" isolé

Pipeline de publication

Le conservateur publie une œuvre dans Directus
        │
        ▼
Flow Directus (déclencheur : "item publié")
        │  webhook
        ▼
Service systemd (arpeteria-rebuild-webhook)
        │
        ├── npm ci && npm run build   (Astro interroge l'API Directus,
        │                              génère une page HTML par œuvre + sitemap)
        ├── npx pagefind --site dist  (index de recherche)
        └── Redémarrage du conteneur Astro (Caddy route vers lui)
        │
        ▼
Site en ligne en ~2 minutes — le conservateur ne touche jamais à un terminal

Compétences mobilisées

Mené seul, de la conception à la mise en production, pour un vrai utilisateur non-technique : un projet complet plutôt qu’un exercice de formation. Il mobilise directement la conception d’infrastructure (B2.1 — architecture Docker multi-services, segmentation réseau), l’installation et configuration (B2.2 — déploiement VPS, Caddy, systemd), le travail en mode projet (B1.4 — monorepo, feuille de route, documentation de passation), la sécurisation (B3.3 — HTTPS automatique, CSP, cloisonnement réseau, secrets hors dépôt), et la conduite de projet (B3.5 — sauvegardes 3-2-1, documentation de passation). Le volet frontend/CMS (B1.3 — présence en ligne, B1.5 — mise à disposition de service) montre que la maîtrise du développement web et de la modélisation de données vient compléter, et non remplacer, les compétences systèmes et réseaux qui restent le cœur de ce projet.