· Tech watch

10 conseils pour les types de contenus de vos CMS

Dans les projets d’intégration de CMS qui comportent des contenus typés, il est primordial de bien modéliser les types de contenus au risque de rendre la vie impossible aux contributeurs. Voici 10 recommandations pour y parvenir…


Dans ce billet, je vais me pencher sur la modélisation des types de contenu utilisés dans vos CMS préférés. Dans tout projet d’intégration d’un CMS (alors, oui des CMS qui fonctionnent avec des contenus et pas ceux par page), la création des types de contenu est une étape obligatoire et fondamentale. Des types de contenus simples et bien pensés faciliteront la vie des contributeurs (qui vous seront reconnaissant !).

1. Se mettre à la place du contributeur

C’est bête à dire mais le type de contenu sera utilisé par quelqu’un et généralement non-informaticien. Donc, la première des choses est d’enlever sa casquette de programmeur et de se mettre dans la peau du contributeur. Cela passe par une bonne compréhension des enjeux métiers et de l’organisation des équipes en interne.

Il en ressortira que les types de contenus seront plus simples et adaptés au besoin réél du contributeur.

2. Ne pas assimiler un type de contenu à un modèle de données informatique

Une erreur classique est de croire qu’il est possible de concevoir des types de contenu comme on modélise de données informatique. Cela ne peux pas marcher. Pourquoi ?

Parce qu’en tant qu’informaticien, nous avons appris que pour modéliser des données, il faut privilégier les structures abstraites et réutilisables avec des dépendances entre elles. Sans oublier, de ne pas dénormaliser les données : une information ne doit pas être dupliquée.

Avec les types de contenus, il faut faire le contraire ! Alors, oui, j’exagère mais ce qu’il faut bien comprendre, c’est qu’il faut masquer la complexité du modèle de données dans le type de contenu. Celui-ci doit pouvoir être saisi de manière simple et sans demander un effort de réflexion.

3. Nommer les types de contenus avec soin

Une autre bonne pratique (plutôt évidente mais souvent délaissée) est de bien nommer les champs composants un type de contenu. Il faut également les compléter avec de l’aide en ligne (généralement dans la description) pour guider un contributeur novice ou incertain.

4. Ne pas intégrer de logique métier aux types de contenu

La saisie d’un type de contenu doit être simplifiée au maximum. Si la saisie d’un même type de contenu doit être différente suivant le gabarit d’affichage (ou suivant d’autre contraintes…), c’est qu’il a mal été conçu et qu’il nécessite d’être repensé et peut-être d’être séparé en plusieurs types de contenus.

5. Ne pas détourner l’utilisation d’un type de contenu

Encore un réflexe d’informaticien : pourquoi créer un nouveau type de contenu alors que j’en ai déjà un qui fait plus ou moins l’affaire moyennant l’ajout/modification de quelques champs ?

La réutilisation de type de contenu génère des types de contenus fourre-tout. Ils disposent d’un infinité de champs et on ne sait plus très comment on s’en sert. Il faut aller regarder dans le gabarit pour voir quel champ est utilisé.

6. Organiser ses types de contenu

La majorité des CMS propose nativement un système de catégorisation multiple/tags à positionner sur vos types de contenus. Il est important de bien connaître le fonctionnement de catégorisation de son CMS pour en tirer le maximum.

Catégoriser correctement son type de contenu va permettre d’ajouter de la flexibilité dans l’évolution du type de contenu sans avoir à le modifier et donc sans nécessité d’une livraison supplémentaire. En conséquence, les services métiers seront plus autonomes pour la maintenance du site.

De plus, une bonne catégorisation permettra de faciliter la création de facette pour un moteur de recherche ou de mettre en place des navigation alternatives (nuages de tags, affinage par thème…).

Enfin, il faut privilégier le regroupement de contenus par la catégorisation des contenus et non par la création de liens inter-contenus. Ici encore, la flexibilité et la maintenance des contenus seront privilégiées.

7. Restreindre l’arborescence des contenus

Il est préférable de concevoir un type de contenu comme un entité à part entière qui ne dépend pas d’autres contenus. Cela évitera au contributeur d’avoir à créer précédemment des sous-contenus et d’avoir un seul formulaire pour la saisie de son contenu.

Exemple d’un type de contenu à éviter :

  • type de contenu article, contenant :
  • * une liste de type de contenu paragraphe, contenant :
  • ** une liste de type de contenu liste à puce

8. Tester chaque type de contenu avec son workflow associé

Il faut bien sûr valider le type de contenu créé avec son workflow. Dans bien des cas, les workflows sont configurés en dernier et c’est à ce moment qu’on s’aperçoit qu’un type de contenu est mal conçu et ne rend pas le service voulu.

9. Privilégier la simplicité : 1 type de contenu = 1 fonctionnalité

Un type de contenu n’est pas fait pour laisser s’exprimer la créativité du contributeur. Au contraire, il sert à fixer donner un périmètre pour simplifier la saisie du contributeur.

En conséquence, on évitera les types de contenu générique, souvent générateur de bug, les gabarits associés n’étant pas prévus pour tous les cas de contribution.

De plus, un type de contenu doit être simple, il ne faut pas hésiter à dupliquer des types de contenu (en changeant, par exemple, le titre du contenu, la description de ses champs) pour simplifier la saisie par le contributeur.

10. Gare aux éditeurs WYSIWYG

Ne pas utiliser d’éditeur WYSIWYG (de type CKEditor) produisant du HTML, cela génère les problèmes suivants :

  • le code HTML produit n’est pas valide (W3C), contient des balises inutiles, peu performant
  • vous aurez des problèmes de copier-coller depuis Word : même avec les fonctionnalités proposées par l’outil, le code HTML résultant sera parasité par des balises inutiles ou des styles inline.
  • la présentation de vos contenus ne sera pas uniforme
  • les contributeurs ne sont généralement des experts HTML bercés de bonnes pratiques Web

Généralement lorsqu’on a besoin de mettre en gras un texte, faire une liste à puces, le language WIKI est parfait pour cela et vous guarantit que le code HTML généré sera correct et la présentation homogène.

Pour conclure

Vous l’aurez compris, réaliser un type de contenu simple et pérenne n’est pas aussi simple qu’il n’y paraît. Un CMS mal intégré provoque souvent un sentiment de rejet par les contributeurs.

Toutefois avec une bonne connaissance du CMS, ces quelques règles en tête et un peu de bon sens, la création et la maintenance des types de contenu sera un jeu d’enfant.

Tags :

5 commentaires

  1. Bonjour, merci pour cet article très intéressant.
    _ Pourriez-vous préciser ce qu’est le langage WIKI ?
    Merci d’avance

  2. Guillaume Saint-Raymond

    Bonjour, le wiki est un langage permettant de formater simplement du texte (mettre en gras, liste à puces, lien hypertexte…). Wikipedia en est le plus illustre exemple. Vous pouvez modifier un article sur Wikipedia pour voir comment celui-ci est formaté au travers du wiki.

  3. Ok merci pour la réponse !

  4. Sébastien Lucas

    Merci pour cet article, le sujet est rarement abordé car à cheval entre le développement et l’ergonomie, l’expérience utilisateur. Nous avons développé la plateforme collaborative dédiée à l’architecture http://www.archiref.com en nous basant sur le CMS Drupal.

    La définition des types de contenus a évolué avec le temps en allant vers une simplification. Je suis assez d’accord avec votre phrase «il faut masquer la complexité du modèle de données dans le type de contenu». Du point de vue de l’utilisateur, tous les champs sont des champs textes même si en réalité la complexité peut être plus grande. (liaison entre contenu, taxonomie …)

    En allant plus loin dans la programmation, on peut faire beaucoup de choses, pour filtrer le formulaire d’édition pour qu’il soit le plus simple possible et adapté au contexte dans lequel le contributeur se trouve.

    Le type de contenu n’est donc plus uniforme et on peut très bien avoir une version simplifiée pour une saisie rapide ou une version plus longue, ou enfin une édition sous-partie par sous-partie.
    Je ne connaissais pas cette souplesse au début.

  5. Dans la même lignée que se mettre à la place du contributeur, je conseille de se mettre à la place de l’internaute car un contenu s’adresse à l’utilisateur final. Il faut accompagner le client pour qu’il pense au visiteur.

    De mon expérience avec le CMS Ametys je constate souvent que les clients souhaitent un masque de saisie riche alors qu’après plusieurs mois d’utilisations ils n’utilisent que 30% des champs et souhaitent faire évoluer leurs types de contenus vers la simplicité. Je conseille de chercher la simplicité (KISS: Keep It Simple and Stupid).

    L’aide en ligne (souvent disponible au survol de la souris à côté de chaque champ) est très pratique pour les contributeurs.

    Les contributeurs réclament des éditeurs WYSIWIG et ça ce comprend. L’outil est au service de son utilisateur, les fonctions de bases doivent nécessiter aucune ou peu de formation pour apprendre à s’en servir. Le CMS Ametys a fait le choix d’implémenter un éditeur WYSIWIG et d’ajouter une conversion en docbook. Les contributeurs retrouvent ainsi un outil proche des outils de bureautique les plus connus tel que Word et n’ont pas besoin d’apprendre un langage spécifique.
    Avec cette solution le CMS Ametys produit un code portable et propre, Ametys génère ensuite un code HTML valide en fonction des interfaces choisis.

    Je finirais en ajoutant un point : Je trouve intéressant de demander au client de produire des contenus réels pour les appliquer au modèle de contenu avant de le valider et de l’implémenter. Cela permet de se confronter à la réalité.

Les commentaires sont désormais fermés.