CMS or not CMS ?

Cet article est le début d'une série.

Choix cornélien s'il en est !

Vous voulez créer une plateforme, mais votre client vous demande une partie applicative et une partie contenu... et là c'est le drame.

Disclaimer / Parti pris

Oui je suis architecte et développeur Symfony, donc pas beaucoup de mystère. Mais on sera ici loin de la critique.
L'idée n'est pas de critiquer telle ou telle plateforme, mais essayer d'expliquer pourquoi on arrive parfois à se trouver dans des situations complexes, dont il n'y a pas de réponse évidente.
Et puis il faut toujours considérer des paramètres qui peuvent parfois passer au second plan et qui sont pourtant fondamentaux:

• la compétence du ou des développeurs. Si celui ne connait que Drupal (au hasard, mais on va en parler) alors clairement cela peut être le bon choix. Si en revanche c'est un pur développeur Java/Spring, l'effort de prise en main d'un CMS est souvent rédhibitoire;
• l'appétence de ceux-ci pour telle ou telle techno. "J'aime pas PHP", "Moi je fais tout sans framework", etc....ne négligez pas ces aspects.
• les contraintes du client, ou de l'environnement. Environnement 100% Microsoft, ou au contraire 100% Open Source, "PHP, non j'en veux pas !".... et là vos 10 ans d'expérience sur Wordpress s'envolent !

Une p'tite histoire ?

Avant d'entrer dans le vif du sujet, je vais vous compter 2 histoires.

Cas N°1 : client pressé - compétence 0

Un client (interne dans mon cas mais ça ne change rien) vient me voir et me dis : "Guillaume, il faut refaire le site abc.com et tu as 3 mois". Ouch. Le truc est vieux, pas simple et il faut évidemment refaire design et le reste....
C'est 60/70% de contenu mais il y a un gros morceaux autour de la recherche et je n'y connais rien.
Me lancer dans un CMS ? Je n'ai jamais touché ni un Drupal, ni un Wordpress...
Mais bon, en discutant avec le client, on trouve un designer qui me fais des maquettes aux petits oignons et je leur dis que je me charge des modifications de contenu en attendant.
Je code donc des templates Twig en Symfony et la recherche, de la BDD et un ElasticSearch font l'affaire.
On met le tout en prod, tout le monde est content et finalement le contenu n'a pas beaucoup bougé depuis 1 an.....

Cas n°2 : figure imposée !

Client n°2 : "Guillaume, puisque tu as fais le premier, le 2ème est à refaire, mais là le client c'est Drupal ou rien".
Effctivement, on a beau négocier, rien à faire....je dois me mettre à Drupal. J'écume Youtube et la doc (horrible) de Drupal. 2ème coup de massue : j'arrive à faire 2 pages simples (Hello world je te hais) mais pas beaucoup d'autres trucs.... et de là à faire un truc "pro" il y a 1 (2 !) pas.
J'arrive à négocier un presta, ultra compétent, qui m'explique sans faire à ma place, mais que c'est lourd !

Le truc est une usine à gaz !

Je ne retrouve pas mes repères. C'est à la fois une usine à clics et à la fois un truc dégueu où il faut faire des hooks partout, rajouter des plugins à foison sans trop savoir ce qu'ils font..... expérience de développement horrible !

Donc dilemme pour la suite, maintenant que je sais faire un peu de CMS. Stop ou encore ?

Pourquoi choisir un CMS ?

Alors pourquoi choisir un CMS en 2022 ?
Objectivement, quelques éléments relevés, notamment en discutant avec le client:

• on connait la pile logicielle
• on a déjà ce CMS sur d'autres sites, on maitrise
• le backoffice est déjà fait, on a notre usine à clics
• on peut créer du contenu nous-mêmes

Toutes ces raisons sont sûrement valables, mais honnêtement de moins en moins:

• la pile logicielle est remplie de plugins non maîtrisés
• la retro-compatibilité entre les versions n'est souvent pas assurée
• oui le backoffice est déjà présent, mais il contient souvent beaucoup de fonctionnalités dont le client n'a pas besoin
• créer proprement un contenu dans un CMS, mis à part un blog, je demande à voir sans être un spécialiste.

En résumé, la "promesse" des CMS de permettre à un utilisateur non développeur de mettre en ligne du contenu n'est JAMAIS tenue.

Pourquoi ne pas choisir un CMS ?

• La sécurité ! On ne compte plus les CVE sur Wordpress, ou sur Drupal. Que dire quand en plus on lui ajoute 50 plugins contribs ?
• Parce que c'est compliqué ! On passe finalement son temps à casser des comportements natifs du CMS, donc finalement on ...code !
• Qui a déjà laissé créer un type de contenu à un utilisateur en prod ? Du coup à quoi ça sert ????

On va y revenir, mais cette approche "type de contenu" est assez paradoxale.

Un headless CMS peut-être ?

Ces dernières années, des tentatives, comme Directus ou Strapi, permettent de créer des types de contenu et des contenus dans un backoffice générique. Sympa, mais du coup, on se retrouve à faire un front office "from scratch".
Là aussi, une approche "data" pure : un contenu = une data d'un type particulier.
C'est bien pour une liste d'articles, mais pas pour bien d'autres chose. Pour des éléments constitués oui, mais sur un site web il n'y a pas que ça !
Ce n'est pas un blog !

Et si on le faisait nous-mêmes ?

Un site web aujourd'hui n'est pas juste une liste d'articles et une page "article". ça c'est un blog !
Et c'est bien le problème !

Nous avons aujourd'hui des pages de plus en plus complexe où il faut gérer des blocs de contenu des complexes mais surtout et souvent non reproductibles.

En conclusion, on va essayer une nouvelle approche.
Garder ce qui fait la force de notre framework web préféré tout en offrant des possibilités de création de contenu.

A suivre !

Dans les prochains épisodes:

• exposer le problème
• comment faire ça dans Symfony ? la théorie
• Développement de bundle : BlockMS

La suite ici