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. Voici comment on protège les textes, l'historique CMS et la base applicative d'une PME romande dans le cadre de la maintenance Voren.
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. C’est le capital qui prend du temps à refaire.
Cet article explique comment on protège cette couche applicative chez Voren : les textes, l’historique du CMS, la base de données du site, les exports. Le principe tient en une phrase. 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, modifie au fil des mois. 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. Un catalogue de services, une liste de références clients, des formulaires enregistrés, des commentaires modérés. Des données que le client a saisies et qui 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 ne se met pas en place après coup. Elle vit dans 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 laisse une trace horodatée, attribuée, 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.
Ce choix change la nature du risque. Une erreur de rédaction ne détruit rien de définitif. Une suppression accidentelle se rattrape. Deux personnes qui travaillent sur le même texte voient leurs contributions fusionner proprement plutôt que 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 tient en un mot. 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. L’important reste le résultat. 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.
Un exemple concret. Une modification maladroite change 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.
D’où une règle simple sur la conservation. Garder plusieurs générations d’exports dans le temps, pas seulement le dernier. Trente jours pour un site vitrine, 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
Un export qu’on n’a jamais réimporté n’est pas une protection. C’est 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 tient en 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. On le découvre pendant un test tranquille, pas 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 vit en fichier texte versionné. L’historique complet de chaque page remonte à sa première ligne. Une réécriture comme celle-ci laisse une trace propre, réversible, attribuée.
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é est une hypothèse, pas une garantie. La vérification trimestrielle transforme l’hypothèse 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.
Un calendrier éditorial aide à bâtir le contenu qui mérite d’être protégé ; notre article dédié paraît prochainement.
