Il existe deux types de CMS, et la différence détermine pour toujours la quantité de travail manuel que votre site vous coûte. L'un stocke des pages. L'autre stocke des données et en génère les pages. Le second est dit relationnel, la plupart des créateurs de sites ne le proposent pas, et l'écart ne devient évident qu'une fois que vous avez quelques centaines d'éléments à organiser de plusieurs façons.
Que signifie réellement « relationnel » ?
Cela signifie que vos collections peuvent pointer les unes vers les autres, et que la base de données fait respecter ces liens. Deux formes couvrent presque tout :
- Un à plusieurs. Un article appartient à une catégorie, une commande à un client, un bien à une ville. L'enregistrement propriétaire stocke une référence vers une seule cible, il est donc impossible d'en avoir deux.
- Plusieurs à plusieurs. Un article porte plusieurs étiquettes, une agence propose plusieurs services. Cela exige une vraie jointure entre les deux collections, et non un champ texte rempli de virgules.
Le mot important est « respecter ». Dans un système relationnel, une référence ne peut pas pointer vers quelque chose qui n'existe plus, parce que la base de données le refuse. Dans un système plat, supprimer une catégorie laisse chaque article porter silencieusement une étiquette morte.
Pourquoi est-ce important pour un site web ?
Parce que ce sont les relations qui permettent à une collection de générer tout un ensemble de pages. Définissez correctement les articles et les catégories et vous obtenez automatiquement les pages de catégorie, les listes filtrées, les blocs d'éléments liés et les fils d'Ariane à partir de la même structure, et ils restent justes à mesure que le contenu évolue.
Sans relations, vous construisez chacun de ces éléments à la main. Ajouter une catégorie veut dire créer une page, l'ajouter à un menu, et penser à y classer les futurs articles. En renommer une veut dire retrouver chaque endroit où l'ancien nom a été saisi. Ce travail ne s'arrête jamais, il s'accumule discrètement jusqu'à ce que le site devienne trop fastidieux à maintenir.
Où les modèles de contenu plats cassent
Trois défaillances, à peu près dans l'ordre où on les rencontre.
- Saisi au lieu d'être choisi. Quand une catégorie est un champ texte plutôt qu'une référence, vous finissez avec « Design », « design » et « Desgin » comme trois catégories, et aucune liste n'affiche tout.
- Renommer devient une migration. Changez le nom d'une catégorie et chaque enregistrement portant l'ancienne chaîne est faux tant que personne ne les a tous retrouvés.
- Une seule organisation possible. Un contenu plat ne peut être listé que d'une seule façon. Un contenu relié peut l'être par catégorie, par étiquette, par auteur, par lieu, par n'importe quelle combinaison, sans dupliquer un seul enregistrement.
Les champs comptent aussi
Une collection n'est utilisable que si chaque champ s'édite comme son contenu le mérite. Des champs texte pour tout, c'est ainsi qu'on finit par coller du HTML brut dans une description. Ce qu'un CMS sérieux doit vous donner :
- Texte enrichi avec un vrai éditeur pour les corps d'articles et de pages
- Images avec aperçu, remplacement et texte alternatif édité sur place, plus des galeries ordonnées où chaque image porte son propre texte alternatif
- Fichiers pour ce qui n'est pas une image : PDF, tableurs, archives
- Couleur sous forme de pastille et de sélecteur, plutôt qu'un code hexadécimal que l'on peut mal saisir
- Horodatages gérés par le système, pour que les dates de création et de modification soient vraies plutôt que saisies à la main
Le texte alternatif mérite une mention particulière. Quand il se trouve à côté de l'image plutôt que dans un champ séparé ailleurs, il est réellement rempli, et c'est toute la différence entre un site accessible et une remarque d'audit.
Comment Modulify procède-t-il ?
La base de données derrière un projet est du véritable PostgreSQL, interrogé en SQL, et non un magasin de contenu propriétaire. C'est pourquoi les relations ci-dessus sont de vraies relations de base de données plutôt qu'un confort dans l'éditeur, et c'est aussi pourquoi les données peuvent être exportées en CSV, JSON ou SQL et déplacées vers n'importe quel système standard.
Le texte stocké dans la base peut aussi être modifié directement sur la page : cliquez sur un titre ou un libellé dans l'aperçu, tapez par-dessus, et la modification est réécrite dans cet enregistrement. Sur un site multilingue, elle est écrite dans la langue que vous consultez, ce qui évite beaucoup d'allers-retours entre les onglets.
Une limite honnête à connaître. Vous pouvez ajouter, modifier, rechercher, dupliquer et supprimer des enregistrements vous-même, mais vous ne pouvez pas créer ni restructurer des tables, ni changer le type d'un champ depuis le CMS. Cela se fait en le demandant, ce qui garde la structure cohérente mais implique que les changements de structure passent par une demande plutôt que par un écran de réglages.
Comment savoir si mon CMS est relationnel ?
Deux tests rapides, sans documentation.
- Le champ catégorie est-il une liste déroulante d'enregistrements existants, ou un champ texte ? Une liste déroulante alimentée par une autre collection est une référence. Un champ texte est une chaîne, et les chaînes dérivent.
- Renommez une catégorie. Qu'est-ce qui casse ? Si tout ce qui y faisait référence se met à jour, c'est relationnel. Si vous devez maintenant retrouver et corriger chaque enregistrement, ça ne l'est pas.
Si votre contenu se limite à quelques dizaines de pages qui changent rarement, rien de tout cela ne vous gênera. Dès que vous avez des éléments qui appartiennent à d'autres choses, et qu'il faut lister de plusieurs façons, cela décide si le site grandit tout seul ou à la main. Pour une vue d'ensemble, voyez comment l'IA construit une application complète avec une vraie base de données, et comment la même structure porte plusieurs langues.
