Avec son propre site, il est particulièrement facile d’expérimenter : le client est toujours à côté et crée régulièrement lui-même de nouveaux problèmes. Après assez de migrations, j’ai cessé de considérer le CMS suivant comme la réponse définitive.

nevsky.ae est passé par Ghost et EmDash. La source éditoriale actuelle est constituée des fichiers du dépôt. Une application Astro construit les pages ; Svelte intervient là où l’interface a réellement besoin d’interactivité. Les anciens systèmes sont conservés pour la récupération, mais ne doivent plus modifier les articles actuels en parallèle.

L’écran « nevsky.ae — premier écran » conserve les vrais contenus et le design du projet.

nevsky.ae — premier écran

Version actuelle du site

nevsky.ae — premier écran
Écran du projet conservé · le terminal peut être ouvert séparément
Ouvrir le terminal ↗

Un article, plusieurs façons de le lire

Un contenu possède un identifiant permanent, un original russe, un ordre commun des blocs et des versions linguistiques. Les médias sont rattachés à cette structure. Une traduction modifie le texte ; elle ne crée pas un nouvel article indépendant qui oublie peu à peu ses proches.

L’écran « nevsky.ae — rubrique intérieure » conserve les vrais contenus et le design du projet.

nevsky.ae — rubrique intérieure

Version actuelle du site

nevsky.ae — rubrique intérieure
Écran du projet conservé · le terminal peut être ouvert séparément
Ouvrir le terminal ↗

Le brouillon et la version publiée n’ont pas les mêmes droits. Je peux réécrire un texte en local et l’ouvrir comme un article normal pendant que le lecteur reçoit toujours la version validée. Cette idée simple devient précieuse quand des agents AI arrivent dans le dossier, très disposés à aider.

nevsky.ae — rubrique contact

Version actuelle du site

nevsky.ae — rubrique contact
Écran du projet conservé · le terminal peut être ouvert séparément
Ouvrir le terminal ↗

Les fichiers publiés génèrent le site, la recherche, Ask, Markdown, RSS et d’autres représentations. Si chacun dispose de son propre texte modifiable, on obtient une petite rédaction sans rédacteur en chef : une interface raconte déjà le nouveau récit, une autre cite l’ancien, une troisième invente avec assurance une version conciliatrice.

Pourquoi les fichiers me convenaient

Un diff rend la modification visible : voici le paragraphe avant, le voici après. On peut la vérifier, la refuser ou revenir en arrière. Le texte côtoie le code qui l’affiche tout en restant un contenu distinct. Avec un agent, c’est pratique : la tâche produit un résultat visible, et accepter une modification n’autorise pas automatiquement sa publication.

Ce choix a aussi un coût. Une rédaction fondée sur des fichiers demande de la discipline, des contrôles de structure et de l’attention aux traductions et aux images. Git ne corrige pas tout seul les mauvais textes et ne remplace pas un éditeur pratique pour chaque auteur. Je l’ai choisi pour ma façon de travailler.

La migration n’impliquait pas d’inventer en même temps un autre design, de changer toutes les adresses et de couper l’histoire. Je voulais conserver un site reconnaissable et modifier son fonctionnement interne.

Dans cette version, j’ai conservé le design et les adresses du site, puis déplacé la source éditoriale vers des fichiers. On peut préparer un article, l’ouvrir dans son véritable habillage et le valider séparément du build. Le terminal et l’ancien Content OS ont leurs propres articles.

À lire aussi : Le terminal du site · L’ancien Content OS · Une plateforme commune à trois sites.