Ne jamais perdre son contenu : protéger le travail éditorial d'un site PME
Le contenu d'un site vaut souvent plus que le code qui l'affiche. Dans le cadre de la maintenance Voren, on protège les textes, l'historique CMS et la base applicative d'une PME romande par le versioning, des exports réguliers et une restauration testée.
Sommaire
Le contenu, c’est le vrai capital
Une PME romande refond son site. Six mois de travail éditorial : trente pages de services réécrites, quarante articles de journal, les fiches produits, les études de cas rédigées avec le patron sur un coin de table. Un matin, une manipulation malheureuse dans le CMS écrase la moitié des textes. La version affichée en ligne était déjà la nouvelle. Personne n’a d’export récent. Le travail de six mois repart de zéro.
Ce scénario arrive plus souvent qu’un incident technique. Le code d’un site se reconstruit vite. Le contenu, lui, porte des heures de rédaction, des arbitrages de ton, des mots-clés travaillés, une mémoire d’entreprise, et c’est lui qui prend du temps à refaire.
Chez Voren, on protège cette couche applicative (les textes, l’historique du CMS, la base de données du site, les exports) selon un principe : chaque version du contenu doit pouvoir être retrouvée, à froid, sans dépendre d’une seule personne ni d’un seul outil.
Les quatre couches de contenu à protéger
Un site PME contient rarement une seule sorte de contenu. Distinguer les couches permet de savoir quoi protéger, et à quelle fréquence.
Le contenu éditorial : les pages, les articles, les fiches produits. Ce sont les textes que le client relit, valide et modifie au fil des mois, et la couche qui coûte le plus cher à reconstituer.
L’historique CMS : les brouillons, les versions intermédiaires, les révisions. Un bon CMS garde une trace de qui a modifié quoi et quand. Cet historique vaut de l’or le jour où il faut revenir à la formulation d’il y a trois semaines.
La base de données applicative : les entrées structurées gérées par le site, comme un catalogue de services, une liste de références clients, des formulaires enregistrés ou des commentaires modérés. Le client les a saisies, et elles n’existent nulle part ailleurs.
Les médias associés : les photos, les visuels, les documents PDF téléversés dans le CMS. Souvent oubliés parce qu’ils semblent « évidents », alors que la version optimisée et recadrée n’existe que là.
Le versioning du contenu au fil de l’eau
La première protection tient à la façon dont le contenu est produit. Chez Voren, les pages et les articles sont écrits en fichiers texte versionnés dans Git. Chaque modification est horodatée, attribuée à son auteur et réversible. Retrouver la formulation d’une page telle qu’elle était le 3 mars prend quelques secondes. Restaurer une version antérieure revient à annuler une correction dans un traitement de texte, mais sur l’historique complet du site.
Une erreur de rédaction ne détruit donc rien de définitif, et une suppression accidentelle se rattrape. Quand deux personnes travaillent sur le même texte, leurs contributions fusionnent proprement au lieu de s’écraser.
Pour le contenu géré directement dans un CMS par le client, la logique se transpose. On active l’historique des révisions, on documente qui a le droit de publier, et on met en place une relecture avant mise en production. Le contenu ne saute jamais d’un brouillon à la version affichée sans passage intermédiaire tracé.
Les exports réguliers du CMS
L’historique interne d’un CMS protège contre l’erreur humaine. Il ne protège pas contre la perte de l’outil lui-même : un compte suspendu, une base corrompue, un prestataire qui ferme.
La réponse est l’export : le contenu doit sortir du CMS à intervalle régulier, sous une forme lisible et indépendante.
Concrètement, un export programmé récupère l’ensemble du contenu structuré et le dépose dans un stockage séparé de l’outil de production. Selon le CMS, cela prend la forme d’un fichier de données complet, d’une exportation de la base ou d’un dossier de fichiers. Quelle que soit la forme, le jour où le CMS devient inaccessible, le contenu existe ailleurs, dans un format qu’on peut relire et réimporter.
La fréquence dépend du rythme de modification :
Site vitrine peu modifié : un export hebdomadaire suffit. On perd au pire une semaine de changements, ce qui reste rare sur ce type de site.
Site avec blog actif : un export quotidien. Le contenu bouge assez pour justifier une trace fraîche chaque jour.
Site à contenu saisi par le client (catalogue, références, formulaires) : un export quotidien au minimum, avec conservation des versions successives sur trente à nonante jours.
La rétention : garder plusieurs versions dans le temps
Un export unique qui écrase le précédent protège mal. Il suppose que l’on remarque un problème dans les vingt-quatre heures. Or les dégâts silencieux existent aussi dans le contenu.
Une modification maladroite change, par exemple, le ton de dix fiches produits. Personne ne le voit tout de suite parce que les pages s’affichent normalement. Trois semaines plus tard, le client s’en rend compte. Si le seul export disponible date d’hier, il porte déjà l’erreur. Il faut pouvoir remonter à la version d’avant la modification.
La règle de conservation en découle : garder plusieurs générations d’exports, sur trente jours pour un site vitrine et sur nonante jours pour un site où le contenu est un actif business. Cette profondeur d’historique couvre les erreurs qu’on ne remarque pas immédiatement.
La même logique vaut pour l’historique CMS. Une rétention trop courte des révisions revient à effacer la mémoire des textes. On la règle assez large pour couvrir un cycle de relecture complet.
La restauration testée : la partie que tout le monde saute
Tant qu’on ne l’a jamais réimporté, un export reste une supposition. Le fichier peut être tronqué, illisible, incompatible avec la version actuelle du CMS. Un dossier de médias peut avoir perdu les chemins qui relient les images aux pages. On ne le découvre qu’au moment de la remise en place, c’est-à-dire au pire moment si on ne l’a jamais vérifié à froid.
La parade est une habitude trimestrielle :
- Récupérer le dernier export du contenu.
- Le réimporter dans un environnement de relecture séparé.
- Vérifier que les pages, les articles et les fiches s’affichent avec leur texte intact.
- Contrôler que les médias sont bien reliés à leur contenu.
- Noter le résultat : durée, points de friction, corrections à faire.
Si la restauration échoue, l’export était inutile, et mieux vaut le découvrir pendant un test tranquille que pendant un incident. On corrige le processus dans la foulée.
L’exemple du journal Voren
Le journal que vous lisez compte plus de cent articles, chacun en fichier texte versionné, et l’historique complet de chaque page remonte à sa première ligne. Une réécriture comme celle-ci y laisse une trace attribuée et réversible.
En parallèle, le contenu structuré du site est exporté chaque jour vers un stockage distinct de l’outil de production, avec nonante jours de rétention glissante. Une restauration de contrôle est faite chaque trimestre dans un environnement de relecture. La dernière a pris onze minutes et a validé l’intégrité de l’ensemble.
Ce dispositif ne coûte presque rien à faire tourner une fois posé. Il coûte surtout de la rigueur à l’installation. C’est le rôle de la maintenance : transformer une bonne intention en routine qui tient.
Les erreurs courantes
Compter uniquement sur l’historique du CMS. L’outil garde une mémoire interne, très utile contre l’erreur humaine. Le jour où l’outil lui-même tombe ou devient inaccessible, cette mémoire part avec lui. Il faut une copie du contenu hors de l’outil.
Oublier les médias. Le texte est exporté, les images non. La version recadrée et optimisée des visuels n’existe que dans le CMS. On l’inclut dans le périmètre du contenu à protéger.
Ne garder que la dernière version. Sans profondeur d’historique, une erreur remarquée trois semaines plus tard devient irréparable. On conserve plusieurs générations d’exports.
Ne jamais tester la réimportation. Un export jamais rejoué reste une hypothèse, que la vérification trimestrielle transforme en certitude.
Laisser le processus échouer en silence. Un export programmé qui plante sans alerte pendant deux mois donne une fausse sécurité. On met une alerte en cas d’échec, et on la surveille.
Pour aller plus loin
Voir notre forfait Maintenance : versioning du contenu, exports programmés et restauration testée inclus, avec vérification trimestrielle sur les forfaits Pro et Premium.
Voir notre article sur le calendrier éditorial : il aide à bâtir le contenu qui mérite d’être protégé.
