Les motivations évoquées par les équipes marketing pour le choix de wordpress (ou solutions équivalentes) dans l’administration de leurs contenus étaient souvent les mêmes : interface d’administration simple à prendre en main, liberté de mise en page, nombreux widgets disponibles, facilité de mise en œuvre, indépendance vis à vis du partenaire intégrateur : des arguments tout à fait justifiés et compréhensibles. De nombreux blogs pilotés par les équipes marketing ont ainsi vu le jour, cohabitant bon an mal an avec leur site-ecommerce.
Côté agence, dans cette configuration il s’agissait généralement de créer des ponts entre le blog et le parcours e-commerce, en développant des “modules administrant les relations entre les contenus et les produits” pour afficher ci et là des blocs d’articles ou des zones de remontée produit, de manière à créer une illusion de fluidité dans les parcours utilisateurs, du shopping à la lecture et vice versa.
Côté annonceur, la gestion au quotidien des “modules de relations” créés par l’agence pouvait être au mieux, chronophage, au pire, laissée en jachère / non entretenue (liens cassés, relations créées vers des produits qui n’existent plus etc).
Du point de vue de l’expérience utilisateur, avouons-le, les rendus graphiques et la fluidité des parcours n’étaient pas vraiment au rendez-vous : la faute au maintien de deux thèmes différents (thème du socle e-commerce cohabitant avec un thème wordpress bricolé), et à la trop grande liberté laissée aux équipes marketing dans un outil non adapté à leurs niveau de compétences (sans vouloir être désobligeante, big kiss aux équipes marketing…)
Nativement, la structure technique de WordPress offre un éditeur de posts et de pages, auquel est parfois adossé une surcouche de page builder, permettant de s’affranchir de la structure de wordpress pour créer des mises en page plus complexes. L’expression “on a les défauts de ses qualités” prend, avec WordPress, tout son sens : le carcan des posts, qui permet uniquement une structure d’information de type blogging mais relativement maîtrisable pour les équipes marketing, et les pages enrichies via le page-builder, qui donne la main sur le fond mais aussi sur la forme (gestion des tranches de page et de leurs paramètres de mise en page : marges, responsive…: une grande liberté qui se transforme rapidement en catastrophe pour la performance notamment sur mobile ou sur l’expérience utilisateur décousue, pour qui n’est pas intégrateur de métier.)
Vous l’aurez compris, et peut-être vécu en interne : ce n’était vraiment pas la panacée.
Les solutions e-commerce de marché embarquent souvent de manière native une brique CMS plus ou moins avancée, ou proposent des modules compatibles via leur marketplace de développements communautaires.
Je serai moins sévère sur ces solutions, que nous avons souvent retenues pour les projets de création ou de refonte e-commerce de nos clients. En effet, pour des besoins marketing très basiques de création de “contenus simples”, utiliser les briques natives ou des modules compatibles est une hypothèse qui fonctionne à date encore très bien. Dans cette configuration, il faut simplement ne pas s’attendre à bénéficier d’options de mise en page ultra custom, mais cela peut suffire dans de nombreux cas, par exemple créer un blog d’actualités ou présenter quelques pages CMS basiques (mentions légales, options de livraison, CGV…)
Certains CMS e-commerce comme Prestashop et Magento proposent aussi des pagebuilder en module ou en extension, permettant aux marques de créer des contenus plus engageants en toute autonomie. Le problème qui se pose alors est celui des performances d’affichage, qui sont en général catastrophiques.
Quelques modules existent aussi sur le marché des extensions de ces cms monolithiques, permettant également d’insérer des zones de contenu prédéfinies pour enrichir le parcours d’achat. Dans certains cas, ces outils peuvent amplement suffire.
En tant que consultante UX, l’architecture de l’information est une composante essentielle de ma boîte à outils. Ce métier m’a amené à développer une obsession pour les données bien structurées, proprement rangées et classifiées, de manière à pouvoir les exploiter et les transformer en interfaces claires et limpides pour nos utilisateurs finaux. En UX e-commerce, la propreté de la data est essentielle si l’on veut pouvoir proposer une ergonomie satisfaisante.
En 2024, j’aimerais penser qu’ON (c’est un “on” inclusif pour tous les décideurs éclairés du digital) a pris conscience de l’importance d’un modèle de données propres pour un business viable / pérenne / durable, et qu’ON a identifié que les contenus marketing et éditoriaux font partie intégrante de ce modèle de données.
Les produits ont leurs PIMs, les clients ont leurs CRMs, les stocks ont leur WMS… toutes les autres typologies de données ont des solutions pensées pour les stocker et les diffuser proprement… Mais pour les contenus marketing et éditoriaux, ce n’a longtemps pas été le cas. Aucune solution n’existait réellement pour stocker proprement et durablement les contenus et pouvoir les diffuser sur son site à l’endroit souhaité. (enfin, malgré quelques DAMs présents pour stocker mais pas vraiment pour “diffuser” au sens éditorial du terme).
Avec les CMS Headless, la saisie du contenu se fait dans un back-office dédié, qui aura fait l’objet d’un paramétrage par nos équipes de développement front pour qu’il corresponde exactement à l’expérience que nous aurons pensée en amont, et vous pourrez alors créer vos contenus en bénéficiant d’une grande liberté, néanmoins cadrée de manière à préserver la webperformance, l’affichage responsive, et le bon sens artistique de l’histoire 🙃.
Un CMS headless permet de gérer le contenu à un seul endroit tout en le déployant sur n’importe quel canal numérique de votre choix. La séparation du frontend et du backend libère le contenu, facilitant ainsi la gestion indépendante pour les équipes marketing et permettant aux développeurs de construire plus rapidement, d’automatiser les changements et de gérer le numérique à grande échelle.
Les CMS de contenu headless sont des back-office servant à créer, stocker et diffuser des contenus. Ils n’ont pas de front-end puisqu’ils sont headless. Ils permettent donc de choisir en toute liberté des stacks techniques modernes et performantes pour développer les différentes interfaces front-end (sites, apps ou autres).
Les CMS headless envoient et reçoivent tout par API (API REST ou GraphQL) ce qui permet d’intégrer facilement divers outils et services tiers. Vous pouvez connecter des plateformes d’analyse, des solutions de marketing automation…
Vous pouvez centraliser votre contenu mais aussi l’adapter à différents formats et besoins sans grande complexité. Car oui, mesdames et messieurs, ces contenus pourront venir alimenter, via l’API, les différents canaux de votre choix. Imaginons que vous ayez d’autres plateformes au sein de votre écosystème digital : par exemple une app et une tablette en magasin. Désormais les deux pourront également exploiter le contenu stocké dans votre CMS headless. Cette approche assure une expérience utilisateur uniforme et rationalise vraiment la gestion du contenu. Fini la double ou la triple saisie d’information…
Ces outils offrent des interfaces de gestion vraiment conviviales qui permettent à vos équipes marketing de préparer, créer, modifier et organiser le contenu sans compétences techniques avancées : préparation en amont de vos campagnes avec des systèmes de releases, prévisualisation, gestion des rôles…rendant le processus de contribution plus fluide et efficace.
Les CMS headless offrent des fonctionnalités de modularité qui permettent de créer des blocs de contenu réutilisables. Cette approche favorise la cohérence et l’efficacité dans la gestion de contenu complexe et riche.
Les CMS headless présentent des inconvénients par rapport à un WordPress en mode API. Tout d’abord, leur coût peut être significativement plus élevé, car la plupart des solutions headless facturent en fonction du nombre de requêtes API, des utilisateurs, ou du volume de contenu, ce qui peut rapidement devenir onéreux pour des projets de grande envergure.
Par ailleurs, la complexité de la mise en place d’une architecture headless implique souvent un investissement initial en temps et en ressources plus important pour configurer et maintenir une infrastructure de front-end séparée.
Contrairement à WordPress, qui offre une multitude de thèmes et de plugins prêts à l’emploi pour une personnalisation rapide, les CMS headless exigent souvent un développement personnalisé pour atteindre des fonctionnalités similaires, ce qui peut ralentir le temps de mise sur le marché.
Enfin, bien que WordPress en mode API puisse également fonctionner comme un CMS headless, il bénéficie d’une communauté vaste et active, offrant un support abondant et des ressources variées, avantage souvent moins marqué pour les solutions headless plus spécialisées.
Ces outils exploitent la notion de CCK (content creation kit). C’est-à-dire qu’ils nous permettent de créer facilement des champs adaptés pour les différentes natures de contenus souhaités. Ces champs, paramétrés et mis à disposition par nos développeurs front, sont évidemment adaptés à la nature du contenu qu’ils accueillent, des champs les plus simples (booléen, date, nombre, selecteur, UID…) aux champs les plus complexes (relation de contenus, intégrations de contenus provenant d’autres sources…)
Une fois ce travail de paramétrage de champs effectué, le développeur front va pouvoir les mettre à votre disposition au sein d’une bibliothèque de tranches de pages conçue sur-mesure pour vos besoins.
Une tranche de page (appelée Slice chez Prismic) est un modèle de mise en page de contenu, elle est composée de l’ensemble des champs nécessaires (et uniquement eux!) pour sa contribution. Par exemple titre + paragraphe + bloc produit + image de mise en avant + bouton + lien + couleur de fond de la tranche + option pleine largeur d’écran ou “boxed” = ma tranche de page.
Ces slices sont mises à votre disposition pour composer et/ou enrichir vos différents gabarits, grâce aux “types de documents”.
Les types de documents sont des entités que l’on crée lorsqu’on a besoin de structurer des gabarits complets suivant un modèle d’affichage adéquat : une page de blog, une page d’accueil, une page de recette de cuisine, une page landing, une page univers, un look… Toutes ces pages font évidemment appel à des besoins de structuration spécifiques en fonction de leur nature. Elles auront donc leur propre série de champs statiques mis à disposition : Un titre, un auteur, une date, une association à une catégorie sont par exemple des champs statiques essentiels pour un type de contenu “article de blog”.
A l’inverse tout le reste du contenu de l’article de blog pourra être considéré comme “dynamique”. Les zones dynamiques sont celles qui pourront être alimentées par nos fameuses tranches de pages évoquées précédemment.
Et, pour aller plus loin, on pourra même créer des types de documents pour enrichir d’autres gabarits, entités ou zones du layout provenant cette fois-ci de votre plateforme e-commerce (Adobe commerce, Prestashop….) : Il faudra simplement créer le type de document par gabarit ou entité e-commerce que l’on souhaite enrichir.
Et c’est cette interopérabilité entre les données de votre socle e-commerce et votre CMS headless qui est absolument géniale.
Toutes les liaisons, toutes les relations “propres et structurées” sont alors possibles dans votre construction éditoriale.
Vous vendez de la décoration intérieure? Dans votre page éditoriale sur la thématique “Bohème chic”, vous pourrez remonter dynamiquement des produits, ou même des catégories de produits. Lesdits produits pourront être enrichis dynamiquement d’une mise en avant de votre thématique bohème chic.
Vous vendez du vin ? Dans votre listing produit sur les vins de Bourgogne, vous pourrez enrichir l’expérience de vos utilisateurs en proposant un encart pédagogique présentant la Bourgogne, ses top appellations, ses nouveaux vignerons ou meilleurs domaines… pointant vers les différentes rubriques associées. Et vice et versa…
