En 2022 comme en 2009, je n'aime toujours pas les CMS. En 13 ans, malgré tous les progrès techniques, le choix de s'en passer reste pertinent. Quoi qu'on en dise.
Pour rappel, un CMS est un outil qui permet à tout un chacun de créer un site Internet, sans avoir de connaissances techniques.
L'outil s'occupe de tout : une interface d'administration pour personnaliser son site et y ajouter des contenus, généralement des librairies de plugins pour ajouter des fonctionnalités supplémentaires, etc.
Sur le papier, c'est cool, parce que ça ne sert à rien de réinventer la roue. Si d'autres le font déjà, ne le refais pas.
Dans les faits, à partir du moment où on a un peu de connaissances et qu'on veut aller à l'essentiel pour faire son petit site, c'est l'assurance de devoir apprendre, et surtout comprendre, des concepts souvent tordus et incroyablement compliqués, pour parfois simplement afficher 4 news par ans et un agenda concert.
Et bonjour les notions de content_types, de nodes, de hooks, etc. qui n'ont absolument aucun intérêt pour la plupart de nos besoins.
C'est-à-dire que le problème que les CMS doivent résoudre, c'est de se rendre indispensable partout où ils passent. Donc de s'adapter à nos moindre désirs. Sauf que pour y arriver, il faut concevoir des modèles super abstraits, super génériques. Qu'il faut ensuite utiliser. Et donc comprendre. Et donc à un moment, quitte à apprendre quelque chose, je préfère apprendre un langage à peu prêt universel que la logique de la core team d'un CMS qui s'est monté à une époque où PHP était à peine un langage objet.
Wordpress, c'est l'enfer.
Avec plus de 60% de parts de marché, c'est l'outil le plus plébiscité pour faire du web. Un petit PHP/MySQL comme dans le temps, un répertoire d'extensions incroyable, une interface vraiment ergonomique, et plusieurs outils populaires pour modifier l'apparence de son site en Wysiwyg.
En réalité, on ne va pas se mentir, ça marche. Mais à quel prix ?
Je n'ai pas remis sérieusement le nez dans le code depuis longtemps. Je ne sais donc pas si les mauvaises pratiques sont toujours légions ou bien si ils ont améliorés leur code. Mais rien ne m'a plu là dedans. Impossible de bosser en équipe (le "développement" se faire en partie dans la base de données)
Certains utilisateurs de Wordpress se diront surement que je suis juste mauvais et que je ne sais pas coder. Moi je dirais simplement que si un CMS a besoin de s'appuyer sur une économie de professionnels et de spécialistes de la technologie, c'est que tes utilisateurs ne sont pas réellement autonomes, tu perds l'intérêt premier de ton outil. Et en plus en tant que développeur, je n'ai aucune envie de bosser sur une techno comme ça : encore une fois quitte à devenir un expert, autant devenir un expert d'une solution qui a un peu de gueule.
J'ai déployé un Wordpress pour mon asso, que j'ai personnalisé. C'est cool, ça prends 2 clics à déployer avec l'hébergeur, on est vite fait opérationnel. En plus avec un plugin j'ai des backups qui se font tout seuls. Par contre je n'ai pas touché à grand chose. J'ai pris un thème jaune. Je voulais du jaune. J'ai été créer un content type, quand même. Ça marche. En vrai, ça fonctionne. Mais je touche trop à rien.
Ce qui m'intéressait c'était de déléguer le déploiement et l'hébergement à un service externe, et à ne vraiment pas faire de code. Et pour ça, c'est toujours bien.
En vrai, dans la plupart des cas, on a pas besoin de CMS. Historiquement, le CMS, c'est là pour gérer des contenus : des versions de contenus, des droits d'accès, des workflows de publications.
Dans la plupart des cas, c'est plus direct et plus efficace d'utiliser d'autres outils.
Des frameworks comme Django ont été créés tout spécialement pour gérer de la publication de contenus sur Internet. Django a été conçus par des journaux, pour faire des journaux en ligne.
Et là, out-of-the-box, tu as tout ce qu'il te faut. Tu peux faire un site dynamique en 1h à tout casser, et prendre le reste de ton temps à concevoir de jolies pages Internet. Tu écris 2 ou 3 modèles super simples pour tes types de contenus, et roule. Si tu as des besoins particulier, tu as également une collection de librairies assez incroyables (mais assez inégales, open-source oblige). Tu reste libre, mais en vrai encore une fois si c'est pour publier 10 contenus par ans (ou même 100, allez disons 100), c'est largement suffisant.
Le pur HTML reste la solution la plus simple pour faire un site Internet. En vrai, si vous faites 2 modifications à l'année, pourquoi payer une grosse prestation de développement à plusieurs milliers d'euros quand de simples pages HTML toutes jolies font remplir le même rôle ?
Vous faites du multilingue ? Vous avez besoin d'intégrer des contenus externes ? D'avoir une interface client ? Si toutes les réponses à ces questions sont négatives, faites juste quelques pages HTML.
Et puis il y a l'intermédiaire. PHP est un langage de script qui a été pensé, à la base, pour ajouter des balises dynamiques dans le HTML. Depuis, on en a fait un vrai langage, mais ça reste encore tout à fait possible de l'utiliser comme au bon vieux temps.
<html>
<head><title>Attaque cardiaque chez les puristes dans 3... 2... 1...</title></head>
<body>
<h1>Gazouillis</h1>
<ul>
<?php $gazouillis = getGazouillis(); ?>
<?php foreach ($gazouillis as $gazouilli) ?>
<li><?=$gazouilli?></li>
</ul>
</body>
</html>
Je ne détailles pas ici la méthode de récupération des Gazouillis, mais vous avez l'idée : connexion en lecture à une base, petit SELECT tout simple.
Et vous avez besoin d'une interface d'administration ? PhpMyAdmin ou Adminer feront très bien le job. Alors parfois oui certains contenus sont compliqués à écrire, mais c'est comme pour tout : il faut toujours penser, d'une part, au temps qu'on va gagner à automatiser une tâche, et, d'autre part, au temps qu'on va passer à l'automatiser.
C'est radical, mais encore une fois, selon le besoin, ça fait très bien le job. Et ça laisse du temps pour se concentrer sur ce qui est peut-être l'essentiel : un site qui a de la gueule.
Voilà, c'était juste une introduction, pour commencer l'année en postant des trucs sans queue ni tête, pour m'échauffer un peu avant d'essayer de retrouver une liberté de ton que j'ai perdu depuis longtemps.
Pour conclure, pour ceux qui éventuellement se poseraient la question, ce site tourne derrière un Django, j'ai réutilisé du code que j'avais déjà fait pour d'autres projets. J'ai pris beaucoup de plaisir à adapter le code à Django 4 pendant les 2h qui m'auront été nécessaires pour sa conception. Parce que c'est ça aussi, le code : un truc qui doit rester une passion et un plaisir.
Demain, je parlerais de mes emojis préférés !
2022 - tominardi.fr