Modifier le site
depuis le site
L'interface d'administration est la page réelle, augmentée de repères. Chaque texte modifiable porte la clé du fichier de textes ; chaque image, son emplacement dans la médiathèque. Le site public n'en porte aucune trace.
On modifie la page, pas un formulaire
L'interface d'administration est le site. Elle rend la page d'accueil réelle — barre de navigation et pied compris — et y ajoute de quoi modifier.
L'administrateur voit donc le résultat exact, pas une approximation dans un champ de saisie.
Le site public ne paie rien pour cette interface. Les ancres d'édition sont émises uniquement en mode édition : dist/index.html en contient 0. Le CSS et le script de l'interface ne partent que dans les pages d'administration.
Pourquoi passer par le moteur de conversion
Les pages d'administration sont engendrées par pages_admin(), dans le même programme que les pages publiques. Elles traversent donc les mêmes contrôles : vocabulaire des composants, hiérarchie des titres, contrastes, interligne mesuré, compatibilité des navigateurs.
L'alternative — une application séparée — aurait deux conséquences immédiates : l'interface pourrait afficher une page que le moteur refuserait de produire, et toute évolution du vocabulaire devrait être répercutée à deux endroits.
139 textes et 13 images modifiables
Chaque texte modifiable porte la clé réelle du fichier de textes, pas un identifiant inventé.
Il n'y a donc aucune table de correspondance à maintenir — donc rien qui puisse se désynchroniser.
<h2 data-cle="accueil.temoignages.titre" data-prop="titre">
Ce que ça a changé.
</h2>
<picture data-media="hero" data-media-l="1280" data-media-h="1600">
…
</picture>Comparaison avec le module précédent. Il employait des identifiants positionnels — accueil.nav_1, accueil.nav_2. Insérer une rubrique au milieu du menu décalait tous les suivants, et les modifications suivantes s'écrivaient dans la mauvaise entrée.
Une clé de jeton — nav.decouverte — désigne le même texte quel que soit l'ordre d'affichage.
Comment l'ancre est posée, et pourquoi c'est fiable
Le lien entre une propriété et sa clé n'existe qu'à un seul instant : avant la résolution. Après, la valeur a remplacé la clé et le lien est perdu.
Le convertisseur note donc la table propriété → clé au moment où il construit l'arbre, puis retrouve chaque valeur dans le HTML produit pour ancrer la balise qui la contient.
On cherche la valeur échappée, telle qu'elle a été écrite. Si elle n'apparaît pas, on n'ancre pas : mieux vaut un texte non modifiable qu'une ancre posée au mauvais endroit, qui écrirait dans la mauvaise clé.
Le défaut de conception qui a divisé la couverture par deux
La première version tenait une liste blanche des propriétés éditables : texte, titre, chapo… Elle oubliait en silence tout ce qui n'y figurait pas — etiquette, surtitre, bouton, description.
Mesure : 40 textes sur 74 étaient inatteignables, sans qu'aucun message ne le signale.
La liste est désormais noire : destinations, apparence, identifiants et métadonnées du <head> sont exclus, tout le reste est modifiable. Ajouter un composant rend ses textes modifiables sans qu'on ait à y penser.
Une clé peut apparaître plusieurs fois
Les libellés du menu figurent dans l'en-tête et dans le menu mobile. Six clés sont concernées sur la page d'accueil.
Modifier l'une des deux occurrences seulement laisserait l'autre afficher l'ancien mot — et l'administrateur conclurait à un bug. Toutes les occurrences d'une clé sont donc mises à jour ensemble.
Modifier un texte
Un clic ouvre une fenêtre qui affiche la clé, la valeur actuelle et le nombre de caractères.
La modification est appliquée dans la page — jamais dans un aperçu séparé.
clic sur un texte
│
├── la fenêtre s'ouvre, préremplie
├── « Appliquer » → le texte change DANS LA PAGE
│ repère ambre : modifié, non enregistré
│
└── « Enregistrer » → 1. sauvegarde complète du site
2. écriture au journal
3. rechargement de la pageRien n'est enregistré sans le clic sur « Enregistrer ». C'est vérifié : après rechargement sans enregistrement, le texte est revenu à sa valeur d'origine, et aucune entrée n'a été écrite au journal.
Un avertissement du navigateur intervient si l'on quitte la page avec des modifications en attente.
Modifier une image
La fenêtre montre la photo en place avec ses caractéristiques réelles, la médiathèque complète, et une zone de dépôt.
Le texte alternatif se modifie ici, avec l'image.
| Élément | Rôle |
|---|---|
| Photo en place | dimensions, nombre de variantes, poids, format d'origine — lus dans la médiathèque |
| Texte alternatif | obligatoire ; refusé s'il est vide |
| Bibliothèque | toutes les photos, celles déjà employées étant marquées |
| Zone de dépôt | importer une photo par glisser-déposer ou parcourir — convertie en WebP, en cinq largeurs |
Déposer une photo CRÉE de la donnée — c'est la seule opération de l'interface qui le fasse. Modifier un texte remplace une valeur existante ; ajouter une photo doit produire les fichiers, une entrée de médiathèque, et une clé d'alt dans chaque langue.
En oublier une seule fait échouer la compilation de cette langue : la médiathèque ne porte que la CLÉ de l'alt, le mot vit dans le fichier de langue. Les quatre sont donc écrites d'un coup, les non saisies portant un marqueur visible ([de], [en], [es]) — une copie muette passerait pour une traduction faite.
un dépôt écrit CINQ fichiers, jamais un seul
├── site/medias/fichiers/ les variantes WebP (+ AVIF en local)
├── site/medias/mediatheque.json
└── site/textes/txt_{fr,de,en,es}.json la clé d'altLe texte alternatif est exigé AVANT tout encodage. Contrôlé après, il laissait sept fichiers orphelins sur le disque à chaque refus : le travail était fait, puis jeté, et rien ne le référençait plus. Un contrôle qui coûte cher vient avant la dépense, pas après.
Pourquoi l'alt se modifie avec l'image, et nulle part ailleurs. Un texte alternatif décrit ce que l'on voit : il doit s'écrire en regardant la photo. Placé dans un onglet séparé, il reste vide — c'est le constat qui a mené à ce choix.
Ce que l'interface ne télécharge pas
Les vignettes emploient la plus petite variante de chaque photo, et l'attribut loading="lazy". Sans cela, ouvrir la bibliothèque téléchargerait 37 images en pleine taille — plusieurs mégaoctets pour des vignettes de 88 px.
La médiathèque est injectée dans la page, réduite aux champs utiles. La fenêtre s'ouvre donc sans aucun appel réseau : une fenêtre qui attend une réponse avant de s'afficher donne l'impression d'un logiciel lent.
Deux défauts trouvés en contrôlant le rendu
L'aperçu était vide. Le code cherchait un champ fichier ; le manifeste porte webp et avif par variante. Résultat : src="/assets/img/", une image cassée.
Le format et l'état « utilisée » étaient toujours vides. Le code lisait ctx.medias, qui est une version réduite du manifeste pour le rendu et ne porte ni fichier_origine ni usages. Corrigé en lisant le manifeste brut : 37 formats sur 37, 35 photos marquées employées.
Une interface par langue
Les 62 textes de l'interface et les 22 phrases du journal sont des jetons, comme n'importe quel texte du site.
/de/admin affiche donc l'interface en allemand sans dupliquer une ligne de code.
site/textes/txt_de.json
"admin.mode" : "Administrationsmodus"
"admin.enregistrer" : "Speichern"
"journal.titre" : "Aktivität"
"journal.aujourd-hui": "Heute"Contrôlé en front. Sur /de/admin, aucun des mots « Enregistrer », « Actualité », « Aucune », « Fermer », « Aujourd'hui » n'apparaît — recherche dans le texte de la page rendue.
Les valeurs des différences restent dans leur langue d'origine : ce sont les textes réels qui ont changé, pas des étiquettes d'interface.
Une langue incomplète n'a pas d'interface
Seules les langues dont la traduction est complète reçoivent une page d'administration. Une interface à moitié traduite serait pire qu'absente : l'administrateur ne saurait pas si un mot français est un oubli de traduction ou un défaut du CMS.
Les adresses, dans un fichier
Les règles d'adresse vivent dans noyau/urls.json : elles changent plus souvent que le code qui les applique.
Le fichier _redirects lu par l'hébergeur en est engendré.
| Adresse | Comportement | Pourquoi |
|---|---|---|
| /admin | 200 — langue maîtresse | adresse canonique |
| /de/admin | 200 — allemand | une page par langue complète |
| /fr/admin | 301 → /admin | deux adresses servant le même contenu seraient un contenu dupliqué |
| /it/admin | 404 | l'italien n'existe pas ; un repli sur le français ferait croire qu'il est installé |
Pourquoi robots.txt ne contient PAS « Disallow: /admin »
C'est contre-intuitif, et c'est le piège classique.
Une page interdite au parcours ne peut pas être lue : la balise noindex qu'elle porte n'est donc jamais vue, et l'URL peut malgré tout apparaître dans les résultats, découverte par un lien externe. Pour retirer une page de l'index, il faut au contraire laisser le robot la lire.
Seconde raison, indépendante : robots.txt est public. Y écrire le chemin de l'administration revient à le publier.
Protection effective : noindex, nofollow en balise sur les trois pages, et absence du sitemap.
Réserve à lever. Ces pages ne sont pas protégées par authentification. Le noindex les tient hors des moteurs de recherche ; il n'empêche personne d'y accéder en connaissant l'adresse. La protection reste à mettre en place.
La présentation reprend celle du module v2
Les choix visuels du module précédent sont justes : ils ont été conservés à l'identique.
Trois d'entre eux méritent d'être expliqués, parce qu'ils ne sont pas arbitraires.
| Élément | Choix | Pourquoi |
|---|---|---|
| Bandeau | #c0392b, 46 px, en haut | il DÉCALE la page au lieu de la recouvrir — posé par-dessus, il masquerait la barre de navigation, dont les libellés sont modifiables |
| Repères | pointillé 1 px → trait 2 px au survol → vert si modifié | le pointillé signale sans déplacer : une bordure pleine décalerait la mise en page et l'administrateur ne verrait plus le site tel qu'il est |
| Pastilles | 54 px, rondes, en bas et au milieu à droite | le pouce les atteint sans traverser l'écran ; l'icône est un SVG tracé, pas un emoji — un emoji change de dessin selon le système et ne suit pas la couleur du bouton |
| Volets | 430 px, ou pleine largeur sous 640 px | sur mobile ils montent du bas : un panneau latéral de 430 px sur un écran de 414 px n'aurait aucun sens |
Un écart assumé avec le module v2 : les valeurs d'interligne proposées.
Il offrait « Très serré (0.90) » et « Serré (0.94) ». À ces valeurs, les accents percutent la ligne du dessus — et le moteur refuse désormais de compiler (code TYP-001).
Le volet propose donc le minimum MESURÉ sur la police comme valeur la plus serrée. Proposer un réglage que le moteur rejette serait une promesse fausse.
Le volet d'apparence est engendré depuis les jetons
Les couleurs, typographies, tailles, espacements et effets ne sont pas énumérés dans le code de l'interface : ils sont lus dans design.json.
Ajouter une couleur au design la fait apparaître dans le volet, avec son libellé et sa valeur, sans modification de code.
Une modification est appliquée immédiatement via la variable CSS correspondante : l'administrateur voit l'effet sur la page réelle. Un nuancier ne dit pas ce que donne une couleur sur une photo.
Le survol d'une image annonce ce qu'elle est
Un pointillé autour d'une photo se confond avec le cadre de la photo : rien ne dit qu'elle est modifiable.
Au survol, une pastille apparaît en son centre — « Remplacer la photo principale » — et nomme à la fois l'action et l'objet. Le nom est en mots, pas en identifiant : « hero » ne dit rien à qui n'a pas écrit la médiathèque.
La pastille porte pointer-events: none. Sans cela, elle intercepterait le clic qu'elle invite à faire.
La phrase entière est tokenisée, pas seulement le nom de l'image : l'ordre des mots suit alors la langue. L'allemand place le verbe à la fin — « das Hauptbild ersetzen » — ce qu'un gabarit « Remplacer {quoi} » figé en français ne permettrait pas.
Le bandeau annonce ce qui est modifiable
« 146 textes et 13 images modifiables sur cette page ».
Sans ce compte, l'administrateur ne sait pas s'il voit TOUT ce qu'il peut changer ou seulement une partie. Il est calculé sur la page rendue, jamais annoncé à l'avance : un chiffre écrit à la main finirait par mentir.
Pourquoi le sélecteur de couleur du système, et pas un nuancier
Réimplémenter un nuancier priverait l'utilisateur de sa pipette, de son historique de couleurs et de ses réglages d'accessibilité — le navigateur fournit tout cela.