Créé en 2016 pour répondre à mes besoins de développeur pour faire des sites moins impactants et aussi simplifier la vie de mes clients, le CMS Translucide continue toujours d'évoluer, ou plutôt d'entamer une dévolution.
Auteurice :
| |5 minutes de lecture
Parce que l'objectif n'est pas de rajouter des fonctionnalités mais plus de rendre toujours plus efficient l'existant. Réduire la friction, la consommation de ressources serveur, réseaux et navigateur (donc moins de ressources naturelles consommées/prélevées), rendre plus accessibles aux personnes en situation de handicap. Tout cela en maintenant l'existant sans mise à jour à outrance, pour ne pas obsoletiser ou perturber les habitudes.
Aussi aujourd'hui tout s'alourdit, grossit, se complexifie, devient de plus en plus touffu, fouillis. Des boutons en plus, des applications à l'origine sympa qui deviennent insupportables après les âges. On parle de plus en plus d'Enshittification, merdification en français, des plateformes et services.
Ce n'est pas long, 10 ans, mais pour le web ça ressemble au pays des dinosaures.
En 2016, quasiment tous les CMS fonctionnaient avec des formulaires dans le Backoffice (espace d'administration des contenus) pour éditer ce contenu qui ensuite était repris en Frontoffice (partie que les visiteurs voient, le site).
Mon idée était de rendre éditable ce que l'on voit, directement en Frontoffice, pour ne plus avoir de Backoffice. Pourquoi avoir 2 interfaces alors qu'une pourrait suffire ?
J'avais souvent des clients qui ne se souvenaient plus du parcours pour pouvoir modifier un contenu et avaient des différences de présentation entre ce qui est fait dans l'administration et le rendu final sur le site.
J'ai quitté mon travail qui ne me convenait pas. J'y étais, comme souvent, obligé d'utiliser des outils que je trouvais peu adaptés, pas d'espace (et de budget) pour la créativité, la recherche.
L'idée de base était de créer un système avec le moins de fichiers possible, le moins lourd, avec le moins de code. Pour s'y retrouver plus facilement, moins s'éparpiller.
Toujours chercher des inspirations et des codes qui tiennent dans le moins de fichiers et de lignes de code possible.
J'ai commencé à faire des tests d'interface d’édition qui permet de modifier en direct le site que l'on voit. Ça marchait !
Après, en vrai, la première étape était de pouvoir accéder de manière sécurisée à cette édition, donc avant de pousser le concept, j'ai dû commencer le système d'authentification.
Première étape pour protéger l'édition du contenu, qui finalement était un des plus gros morceaux. Je me suis beaucoup documenté sur la sécurité, comment fonctionnaient les systèmes existants, pour faire quelque chose de solide et aussi qui permet de ne pas perdre son travail en cours quand on se fait déconnecter.
Ensuite, le gros morceau était l'édition des contenus et toute la palette d'outils pour mettre en forme les contenus. Les éditeurs Wiziwig (palette d'outils pour mettre en forme les contenus dans le navigateur) de l'époque étaient déjà des usines à gaz, avec des tonnes de fonctionnalités et qui parfois ne fonctionnaient pas comme je voulais, ou avec un UX pas adapté à mes besoins et ceux de mes clients. Des lourdeurs, de la complexité, et aussi une marche très grande à franchir pour faire ce que je voulais. De plus, utiliser les systèmes existants me rendait dépendant d'un code qu'il faut suivre et mettre à jour. Potentiellement aussi des changements d'interface intempestifs alors que les usagées se sont habituées à une ergonomie.
Aussi mon projet, en plus de limiter les dépendances, était de limiter la taille du projet. Pas trop de fichier et poids de fichier (ligne de code). Quand ton projet tient dans 40 fichiers et qu'il faut en rajouter autant, ou beaucoup plus pour juste une fonctionnalité, ça interroge !
Je me suis mis à regarder le code de ce qui existait, comment ça fonctionnait et je suis parti de zéro avec ce dont j'avais besoin.
A suivi un système d'envoi de fichiers pour les images, en glisser-déplacer, avec envoi multiple en parallèle, avec suivi de la progression d'envoi.
Et encore plein de choses pour faire un système fonctionnel, en vrac :
Il n'a pas grossi, l'essentiel est là. Des modes sont passés, sans grande influence sur notre système.
Un CMS qui pèse moins de 1 Mo, dans une 40ène de fichiers. C'est très contenu.
Clairement, si je devais aujourd'hui ajouter une librairie externe, une dépendance, le système sortirait totalement de ce calibre.
Ce qui me fait clairement refuser d’intégrer une librairie externe. En général je regarde comment marchent les systèmes et en fais une version simplifiée qui tient dans le moins de ligne possible, sans superflu ou sur-vérification.
Les sites créés avec le CMS sont stables et les performances de ces derniers restent au top. Des temps de chargement toujours très rapides, un bon référencement. Je pense que là, au bout de 10 ans, les sites sont toujours là, fonctionnels, performants, on peut parler d'une certaine robustesse. Tout ça sans mise à jour à outrance.
Chaque année, en plus d'optimisation, amélioration de l'accessibilité, je mets à jour le CMS pour qu'il marche avec les dernières versions stables de PHP et JQuery. Sans grand changement, car j'utilise plutôt basiquement ces librairies. Aussi pour que ça soit plus accessible au développeur débutant ou amateur.
En général, les nouvelles fonctionnalités, amenées souvent par un client, sont testées avec ce dernier, comme un plugin. Et si la fonctionnalité s'avère intéressante pour tous, elle est alors intégrée au CMS après un certain temps de test.
Par défaut, une nouveauté n'est pas forcément indispensable, ou à intégrer ; elle est d'abord en test en bac à sable et si la demande s'avère utile, on réfléchit à la déployer. Il faut laisser passer le temps du côté brillant de l'attrait de la nouveauté, pour se poser et voir si on en a vraiment besoin. Après tout, on ne fait que des sites, des pages HTML lues par un navigateur, ceci depuis plus de 20 ans que je fais ce métier.
