Refonte du site lesporteslogiques.net — CMS flat-file Grav
Conception et déploiement du nouveau site de l'association Les Portes Logiques sous CMS flat-file Grav : thème enfant, arborescence, personnalisation HTML/CSS/Twig/YAML
Commanditaires : Pierre Commenge et Laure Bouscasse (co-fondateurs Les Portes Logiques)
grav-theme-oxygen-lpl (premier commit de stage, mis à jour le 02/04/2026)
Contexte de réalisation
Un CMS sans base de données
Grav est un CMS (Content Management System — Système de Gestion de Contenu) dit flat-file : il ne repose sur aucune base de données relationnelle. Le contenu est stocké directement dans des fichiers Markdown et YAML (YAML Ain't Markup Language — format de sérialisation de données) organisés en répertoires. C'est ce qui rend Grav léger, versionnable et particulièrement adapté à une petite association comme Les Portes Logiques.
La règle fondamentale dans Grav est de ne jamais modifier le thème parent directement — toute mise à jour du CMS écraserait ces modifications. On crée un thème enfant qui surcharge uniquement ce qu'on veut changer. J'ai créé oxygen-lpl à partir du thème parent Oxygen : il contient ses propres templates Twig (moteur de templates PHP), son CSS (Cascading Style Sheets — Feuilles de Style en Cascade) personnalisé, ses images et son JavaScript, et il est versionné sous Git (système de contrôle de version distribué).
L'environnement de travail était organisé en deux couches distinctes : un site de test whatthefaq pour apprendre Grav sans risque, et le site réel des Portes Logiques dans le répertoire user/ du CMS. Cette séparation m'a permis d'expérimenter librement avant d'intervenir sur le site de production.
Certaines compétences du référentiel E5 ne sont pas cochées dans cette réalisation. Répondre à des incidents réseau ou système (2.2) ou référencer des services en ligne au sens d'une campagne SEO (Search Engine Optimisation — Optimisation pour les moteurs de recherche) approfondie (3.2 partielle) supposent des actions que je n'ai pas eu à mener ici. Ce qui a été fait est documenté ; ce qui ne l'a pas été est dit clairement.
Compétences E5 mobilisées
1.1 ✅ Recenser et identifier les ressources numériques
Inventorier les composants du système d'information (matériels, logiciels, données, services) et les documenter pour en assurer la traçabilité et la gestion.
Au démarrage du projet, j'ai identifié les ressources numériques en deux dimensions : les composants du CMS Grav (thème parent Oxygen, plugins installés — admin, login, form, sitemap, email, events, fullcalendar —, structure user/) d'un côté, et les ressources propres au site des Portes Logiques de l'autre (pages, assets visuels, comptes utilisateurs, fichiers de configuration YAML). Cette identification m'a permis de distinguer précisément ce qui relevait du CMS — et ne devait pas être touché — de ce que je devais créer dans le thème enfant oxygen-lpl.
1.2 ✅ Exploiter des référentiels, normes et standards
S'appuyer sur des documentations officielles, des normes de qualité ou des standards techniques pour guider ses choix et garantir la conformité des solutions produites.
Tous mes choix techniques s'appuient sur la documentation officielle Grav (docs.getgrav.org) : la convention de nommage des thèmes enfants, la hiérarchie de surcharge des templates Twig, la structure des fichiers YAML de configuration, la numérotation des répertoires de pages pour contrôler l'ordre d'affichage. J'ai également respecté la convention de nommage des blueprints (fichiers YAML décrivant les champs de formulaire d'administration) telle que définie par Grav.
1.3 ✅ Mettre en place et vérifier les niveaux d'habilitation
Définir et contrôler qui a accès à quoi : droits, rôles, comptes utilisateurs — de façon à protéger les ressources tout en permettant le travail des personnes autorisées.
J'ai créé et configuré deux comptes dans Grav : vitally.yaml avec les droits d'administration complets, et u44.yaml avec des droits restreints destinés au gestionnaire de contenu de l'association. Cette distinction de rôles garantit que l'équipe de LPL (Les Portes Logiques) peut mettre à jour le contenu sans risquer de modifier la configuration du CMS ou du thème.
1.4 ✅ Vérifier les conditions de la continuité d'un service
S'assurer qu'un service peut rester disponible ou être rapidement rétabli en cas d'incident, de panne ou d'intervention technique.
Avant chaque modification significative du site, j'ai vérifié que le service restait accessible et fonctionnel. Les deux répertoires de sauvegarde datés (user_backup_25mars et user_qqoqccp_26mars) sont les traces de cette démarche : en cas de régression, le site pouvait être restauré à un état stable en quelques minutes. Cette précaution était d'autant plus importante que le site de l'association était potentiellement accessible en ligne pendant toute la durée de l'intervention.
1.5 ✅ Gérer des sauvegardes
Mettre en place une stratégie de sauvegarde des données et des configurations, avec une procédure permettant de les restaurer en cas de perte ou de corruption.
J'ai mis en place une procédure de sauvegarde manuelle et jalonnée : copie complète du répertoire user/ avant les étapes critiques, nommage explicite avec la date (25mars, 26mars). Ces sauvegardes complètent la sauvegarde automatique proposée par le plugin admin de Grav, qui ne couvre que les pages — pas la configuration ni les thèmes. Mes sauvegardes manuelles couvraient l'ensemble du périmètre éditorial et technique.
1.6 ❌ Vérifier le respect des règles d'utilisation
Contrôler que l'usage des outils et des systèmes est conforme aux règles définies : chartes, politiques de sécurité, obligations légales (RGPD, licences, etc.).
Non mobilisée dans cette réalisation. Il n'existait pas de politique ou charte d'utilisation interne à faire respecter dans ce contexte.
2.1 ❌ Collecter, suivre et orienter des demandes
Recueillir les demandes des utilisateurs, les qualifier, les prioriser et les orienter vers la bonne ressource ou procédure de traitement.
Non mobilisée dans cette réalisation. Le projet s'inscrivait dans une commande globale de refonte, pas dans un flux de tickets ou de demandes ponctuelles à orienter.
2.2 ❌ Traiter des demandes concernant les services réseau et système
Diagnostiquer et résoudre des incidents ou des demandes liés à l'infrastructure : réseau, système d'exploitation, serveurs, équipements physiques.
Non mobilisée dans cette réalisation. Aucune intervention sur l'infrastructure réseau ou système du serveur hébergeant le site.
2.3 ✅ Traiter des demandes concernant les applications
Diagnostiquer et résoudre des incidents ou des demandes liés aux applications : dysfonctionnement, anomalie, évolution fonctionnelle.
J'ai diagnostiqué et résolu plusieurs problèmes applicatifs concrets au fil du projet : un template Twig qui ne surchargeait pas correctement le thème parent (mauvais nom de fichier), un CSS (Cascading Style Sheets) non appliqué (chemin d'asset incorrect dans le YAML de configuration), une page qui n'apparaissait pas dans la navigation (numérotation de répertoire manquante). Chaque problème a été identifié, diagnostiqué et corrigé — c'est du support applicatif réel, même sans ticket formalisé.
3.1 ✅ Participer à la valorisation de l'image de l'organisation
Contribuer à construire ou améliorer l'image de l'organisation sur le web, en tenant compte de son identité, de sa charte graphique et du cadre juridique applicable.
J'ai construit l'identité visuelle du site en cohérence avec celle de l'association : intégration du logo LPL (Les Portes Logiques) en deux variantes (avec et sans fond, format PNG et WebP), favicon personnalisé, banners photographiques par section (qui_lpl_banner, quoi_lpl_banner, etc.), palette de couleurs et typographie adaptées dans le custom.css. Le résultat reflète l'image d'un FabLab (Fabrication Laboratory — laboratoire de fabrication) ancré dans son territoire, pas un thème générique.
3.2 ✅ Référencer les services en ligne de l'organisation
Mettre en œuvre des techniques de référencement (SEO, sitemap, structuration des URL) pour améliorer la visibilité des services en ligne dans les moteurs de recherche.
J'ai configuré le plugin sitemap de Grav, qui génère automatiquement un fichier sitemap.xml à partir de l'arborescence de pages. Ce fichier est la base du référencement par les moteurs de recherche. J'ai également structuré les URL (Uniform Resource Locator) du site de façon propre et lisible grâce à la numérotation et au nommage des répertoires de pages Grav (01.le-lab, 02.les-projets…), ce qui favorise l'indexation.
3.3 ✅ Participer à l'évolution d'un site Web exploitant les données de l'organisation
Concevoir, modifier ou enrichir un site web en intégrant les données propres à l'organisation, dans le respect de ses besoins et contraintes techniques.
C'est le cœur de la réalisation. J'ai conçu et déployé la nouvelle architecture du site à partir du cahier des charges de l'association : 9 sections principales (Le Lab, Les Projets, Les Ateliers, Les Formations, Les Résidences, KDO, Home, Footer, Sidebar), chacune avec ses sous-pages. Le contenu existant de l'association a été migré et restructuré dans ce nouveau cadre.
4.1 ✅ Analyser les objectifs et les modalités d'organisation d'un projet
Lire et comprendre un cahier des charges, identifier les contraintes, les acteurs et les ressources nécessaires avant de démarrer une réalisation.
Avant de toucher au site, j'ai lu et analysé le cahier des charges (Cahier des charges site web 2026.txt) initié par Pierre sur Framapad pour comprendre les attentes de l'association. La réunion du 26 mars 2026 a été un moment clé : j'ai présenté le site de démonstration whatthefaq à Pierre et Laure — les décideurs du projet — en présence d'Élouan et Triet, deux élèves de terminale du Lycée Thépot invités pour découvrir la démarche de brainstorming. Cette réunion a relancé une discussion sur l'identité du site que Pierre et Laure n'avaient pas eue depuis dix ans, et en est sorti un CDC structuré : architecture de navigation (sidebar, menu haut, footer), liste des sections, contraintes techniques. J'ai formalisé ma compréhension dans les fichiers RECAP d'étape, qui explicitent les objectifs de chaque phase avant de commencer à coder.
4.2 ✅ Planifier les activités
Découper un projet en tâches, les séquencer dans le temps et organiser leur enchaînement pour atteindre les objectifs dans les délais impartis.
J'ai découpé le projet en étapes successives, matérialisées par les fichiers RECAP_Etape1_whatthefaq_todolist.txt et RECAP_Etape2_whatthefaq_todolist.txt : exploration du CMS sur le site de test, création du thème enfant, construction de l'arborescence, personnalisation visuelle, tests, déploiement. Chaque étape a fait l'objet d'une sauvegarde datée avant de passer à la suivante.
4.3 ✅ Évaluer les indicateurs de suivi d'un projet et analyser les écarts
Mesurer l'avancement réel d'un projet par rapport à ce qui était prévu, identifier les écarts et les causes de blocage, et ajuster si nécessaire.
Les deux fichiers de recap hebdomadaires (recap_26mars_2026.md et recap_30mars_2026.md) dans le thème enfant documentent l'avancement réel par rapport aux objectifs prévus. Ils consignent ce qui a été fait, ce qui a bloqué et comment c'a été débloqué — c'est un suivi d'avancement concret, daté, dans l'outil de travail lui-même.
5.1 ✅ Réaliser les tests d'intégration et d'acceptation d'un service
Vérifier que les composants d'un service fonctionnent correctement ensemble et que le résultat correspond aux attentes exprimées avant mise en production.
J'ai conduit des tests à deux niveaux : d'abord sur le site de test whatthefaq en local (localhost) pour valider chaque fonctionnalité avant de la porter sur le site réel, puis sur le site de production pour vérifier l'intégration complète — rendu visuel, navigation, affichage des pages, chargement des assets. J'ai également testé l'API (Application Programming Interface) REST de Grav avec curl pour valider l'accès programmatique aux données.
5.2 ✅ Déployer un service
Installer, configurer et mettre en production un service dans son environnement réel, de façon opérationnelle et sans interruption du service existant.
À l'issue du stage, le site a été déployé sur le serveur de l'association et rendu accessible à l'adresse lesporteslogiques.net. Le déploiement incluait le transfert du thème enfant oxygen-lpl, des pages, de la configuration et des assets — en veillant à ne pas écraser les données existantes ni interrompre le service pendant le transfert.
5.3 ✅ Accompagner les utilisateurs dans la mise en place d'un service
Former, documenter ou guider les utilisateurs pour qu'ils puissent s'approprier un service et l'utiliser en autonomie.
J'ai présenté à l'équipe de l'association le fonctionnement de l'interface d'administration Grav : comment créer une page, modifier du contenu, ajouter une image. J'ai aussi expliqué la logique du thème enfant — pourquoi ne jamais modifier le thème parent, comment ajouter du CSS personnalisé dans custom.css. Cette passation était indispensable pour que l'association puisse maintenir le site de façon autonome après la fin du stage.
6.1 ✅ Mettre en place son environnement d'apprentissage personnel
Structurer les outils, méthodes et ressources qui permettent d'apprendre en faisant, de progresser de façon autonome et de capitaliser ses connaissances.
Avant d'intervenir sur le site réel de l'association, j'ai créé un environnement de test dédié : le site whatthefaq, avec sa propre arborescence de pages et ses fichiers source séparés (whatthefaq-src-md/, whatthefaq-src-yaml/). Cet environnement m'a permis d'apprendre Grav sans risque — tester les templates Twig, comprendre la logique des pages modulaires, explorer les blueprints — avant de transposer les solutions validées sur le site de production.
6.2 ✅ Mettre en œuvre des outils et stratégies de veille informationnelle
Identifier des sources fiables, les consulter régulièrement et exploiter les informations recueillies pour rester à jour sur les évolutions technologiques et professionnelles.
Tout au long du projet, j'ai consulté et exploité la documentation officielle de Grav, les forums de la communauté, et les dépôts GitHub des plugins utilisés (admin, events, fullcalendar). J'ai également lu le README-skeleton-oxygen.md et le CHANGELOG.md du thème pour comprendre l'historique des changements avant de créer le thème enfant. Cette veille continue m'a évité plusieurs erreurs de configuration documentées après coup dans mes recaps.
6.3 ✅ Gérer son identité professionnelle
Construire et entretenir une présence numérique cohérente avec son parcours et ses compétences : portfolio, profil LinkedIn, livrables publics.
Cette réalisation est documentée sur mon portfolio praxis-debug.net. Elle illustre une compétence technique concrète — maîtrise d'un CMS flat-file, création d'un thème enfant, déploiement en production — et une posture professionnelle : travail structuré, documenté, avec passation à l'équipe. C'est aussi le projet qui a initié mon premier workflow Git réel sur un projet de stage : le thème enfant oxygen-lpl est versionné dans le dépôt GitHub vitally-u44/grav-theme-oxygen-lpl, mis à jour le 02/04/2026 — dernier jour du stage.
6.4 ✅ Développer son projet professionnel
Analyser ses expériences pour identifier ses points forts, ses axes de progression et les compétences à acquérir en vue d'un objectif professionnel.
Ce stage m'a confrontée pour la première fois à l'écosystème des CMS flat-file, aux templates Twig, aux scripts Bash d'automatisation et à l'API REST de Grav. J'ai appris en faisant, sur un projet réel avec de vrais commanditaires. C'est aussi ce projet qui a déclenché mon premier usage réel de Git sur un projet de stage : avant ce stage, j'avais un dépôt test-git d'apprentissage (février 2026) — ici, pour la première fois, Git est au service d'un livrable professionnel versionné. Ces compétences — CMS sans base de données, logique de thème enfant, versionnement Git d'un projet web — viennent compléter mon profil SLAM (Solutions Logicielles et Applications Métiers) et correspondent à des besoins concrets que je rencontre déjà dans mon projet professionnel.