Pourquoi les CMS devraient tous gérer 4 dates par contenu

Gérer une date de publi­ca­tion ne suf­fit pas : un CMS devrait tou­jours gérer en natif une date de créa­tion, date de modi­fi­ca­tion, et une date de mise-à-jour conte­nu. Mais les deux der­nières sont géné­ra­le­ment fusion­nées par les outils, à tort. Explications.

La date de création

La date de créa­tion (crea­ted) cor­res­pond à la date à laquelle un objet est créé dans le sys­tème de ges­tion de conte­nu. Elle est indé­pen­dante du type ou de l’é­tat de l’ob­jet. L’objet peut repré­sen­ter n’im­porte quel type de conte­nu : une image, un article, etc. Le conte­nu peut avoir n’im­porte quel état : brouillon, public, pri­vé, etc.

Le CMS devrait gérer cette date, pour que les per­sonnes qui y uti­lisent le sys­tème puisse répondre à la ques­tion “Quand est-ce que c’est appa­ru dans le sys­tème ?”. La date de créa­tion est la date la plus ancienne liée à l’ob­jet, et elle ne devrait pas être modi­fiable, même par un admi­nis­tra­teur ou une administratrice.

Si cette date est modi­fiable depuis le sys­tème, elle devient fal­si­fiable. N’importe quel·le admi­nis­tra­teu­rice peut fal­si­fier l’his­toire depuis le sys­tème ou faire perdre cette infor­ma­tion (peut-être défi­ni­ti­ve­ment). C’est pas un grand plan.

La date de publication

La date de publi­ca­tion (publi­shed) cor­res­pond au moment où un conte­nu est mis à dis­po­si­tion de son public, quel qu’il soit (le monde entier, les abonné·es, les col­la­bo­ra­teu­rices en interne, etc.). Tous les types de conte­nus n’ont pas for­cé­ment une date de publi­ca­tion. Un conte­nu image n’a peut-être pas de publication.

La date de publi­ca­tion donne une infor­ma­tion sur le conte­nu lui-même. Elle nous dit “Cet article a été publié à telle date”. Elle ne parle pas de l’ob­jet dans le CMS, mais du bien du conte­nu repré­sen­té par cet objet. 

La date de publi­ca­tion doit donc être modi­fiable depuis le sys­tème, parce que c’est ce qu’on attend en tant que créa­teu­rice du conte­nu. C’est à nous de déci­der quand est publié le conte­nu, pas au système.

En géné­ral, cette date est gérée par le CMS, et ils per­mettent de l’af­fi­cher aux uti­li­sa­teurs finaux (le public auquel est des­ti­né le contenu).

La date de dernière modification

La date de der­nière modi­fi­ca­tion (last_modified) indique quand l’ob­jet a été modi­fié. C’est une date tech­nique, pas édi­to­riale. Si j’ouvre un article très ancien pour lui chan­ger une coquille, l’ob­jet article est modi­fié mais le conte­nu édi­to­rial n’a pas changé.

La date de der­nière modif répond à la ques­tion “Quand est-ce qu’on a tou­ché à la der­nière fois à cet objet ?”. À l’ins­tar de la date de créa­tion de l’ob­jet, elle ne devrait pas être modi­fiable par les uti­li­sa­teu­rices depuis le sys­tème. On peut la voir comme le pen­dant de la date de création.

Beaucoup de sys­tèmes savent gérer cette date, c’est la date de der­nière sau­ve­garde de l’ob­jet. Mais sou­vent elle est mélan­gée avec la date de mise-à-jour conte­nu, et ça fout un bor­del monstre.

La date de mise-à-jour du contenu

La date de mise-à-jour du conte­nu (content_updated) indique une évo­lu­tion remar­quable du conte­nu. Comme la date de publi­ca­tion, elle porte sur le conte­nu, pas sur un objet infor­ma­tique. Là encore, tous les types de conte­nus n’ont pas besoin d’une date de mise-à-jour conte­nu. Mais pour un conte­nu texte (beau­coup du web quand même) c’est vrai­ment nécessaire.

Si le CMS ne gère pas cette date, elle va quand même être ajou­tée, direc­te­ment dans le conte­nu, sans être dis­po­nible pour le CMS lui-même. C’est ce qu’on voit à chaque fois qu’un post contient “mis-à-jour le” en haut de page. Les per­sonnes ont vou­lu indi­quer une modi­fi­ca­tion sub­stan­tielle du conte­nu, mais n’a­vaient pas d’autre option pour le faire. 

Et fina­le­ment on a une date qui aurait méri­té de déclen­cher une alerte, une mise à jour du flux RSS ou d’autres actions, et qui ne peut pas le faire. Parce que la date de mise-à-jour conte­nu consti­tue un signal pour l’au­dience, contrai­re­ment à la date de modi­fi­ca­tion de l’objet.

Cette date doit donc être modi­fiable par les uti­li­sa­teu­rices du sys­tème. Comme la date de publi­ca­tion, on s’at­tend à pou­voir l’af­fi­cher aux uti­li­sa­teu­rices finales du contenu.

Illustration

Voyons com­ment tout ça s’ar­ti­cule avec un exemple. On va prendre l’exemple d’un article de blog sur lequel on tra­vaille au cours d’une semaine de cinq jours. Chaque jour on fait une sau­ve­garde de l’ob­jet, ce qui nous donne cinq dates dans le CMS, notée de T1 à T5.

Lundi, je crée un conte­nu “article” vide avec juste un titre. On est à T1. L’objet a une date de créa­tion (T1) et une date der­nière modi­fi­ca­tion (T1).

Mardi, je rédige l’ar­ticle entier et je le publie. On est à T2. L’article a une date de publi­ca­tion (T2). Sa date de modi­fi­ca­tion passe à T2.

Mercredi, je réa­lise qu’il y a une coquille et je cor­rige l’ar­ticle. On est à T3. La date de modi­fi­ca­tion passe à T3.

Jeudi, je reçois une cri­tique et je modi­fie la conclu­sion de mon article. On est à T4. J’ajoute une date de mise-à-jour conte­nu T4. La date de modi­fi­ca­tion passe à T4.

Vendredi, je m’a­per­çois que j’ai fait une coquille dans la conclu­sion. Je re-modi­fie l’ar­ticle. On est à T5, et la date de modi­fi­ca­tion devient T5.

À la fin de ma semaine, mon article a donc les dates suivantes : 

• date de créa­tion : T1
• date de publi­ca­tion : T2
• date de mise-à-jour conte­nu : T4
• date de modi­fi­ca­tion : T5

Avec ces quatre dates, je peux dis­tin­guer le moment où on n’a com­men­cé à tra­vailler sur l’ob­jet, le moment où le conte­nu a été pré­sen­té au public, le moment où le conte­nu a été mis-à-jour, et la der­nière fois où quel­qu’un est pas­sé chan­ger quelque chose dans l’objet.

Mis sur une frise chro­no­lo­gique, ça donne ça : 

On peut aus­si expri­mer tout ça dans un tableau, ce qui per­met de voir l’é­tat de chaque type de date, selon le moment. (WordPress gère super mal les tableaux, donc je mets une alter­na­tive en-dessous).

Jour	Action	Date de créa­tion	Date de modi­fi­ca­tion	Date de publi­ca­tion	Date de mise-à-jour contenu
Lundi (T1)	Je crée un conte­nu “article” vide.	T1	T1	Aucune	Aucune
Mardi (T2)	Je rédige l’ar­ticle entier et je le publie.	T1	T2	T2	Aucune
Mercredi (T3)	Je cor­rige une coquille.	T1	T3	T2	Aucune
Jeudi (T4)	Je modi­fie la conclu­sion de mon article.	T1	T4	T2	T4
Vendredi (T5)	Je cor­rige une autre coquille.	T1	T5	T2	T4

Conclusion

En bref, il y a besoin de quatre dates, parce qu’il y a deux choses dif­fé­rentes. Les objets tech­niques du CMS, qui ont besoin d’une date de créa­tion et de der­nière modi­fi­ca­tion, pour sim­pli­fier la vie de ceux qui gèrent le conte­nu et le CMS. Les conte­nus qui sont repré­sen­tés par ces objets tech­niques, qui ont besoin d’une date de publi­ca­tion et d’une date de modi­fi­ca­tion, à la fois à l’u­sage des per­sonnes qui pro­duisent le conte­nu et de leur audience.

Nom	Concerne	Modifiable depuis le CMS	Utile pour
Date de création	Objet tech­nique qui repré­sente le contenu	Non	Créateurices du conte­nu, Admin du CMS
Date de modification	Objet tech­nique qui repré­sente le contenu	Non	Créateurices du conte­nu, Admin du CMS
Date de publication	Contenu	Oui	Audience du conte­nu, Créateurices du contenu
Date de mise-à-jour du contenu	Contenu	Oui	Audience du conte­nu, Créateurices du contenu

À l’é­vi­dence, mon pro­pos pense prin­ci­pa­le­ment à par­tir de conte­nus édi­to­riaux (des articles, des tests, etc.) expri­més dans du texte. Ce qui ne man­que­ra pas de sus­ci­ter des réac­tions, qui feront que je devrai faire une mise-à-jour du conte­nu, que je pour­rais pas mar­quer, parce que mon CMS la gère pas en natif. Alors que c’est un besoin de base.

Aussi, je sais que ça sert à rien de pos­ter ça en fran­çais, mais 1) gérer une ver­sion mul­ti-lingue de WordPress alors que je publie une fois tous les deux ans du conte­nu inté­res­sant en anglais, c’est l’en­fer et 2) cet article sert à me pas­ser les nerfs, pas à chan­ger le monde.