Pourquoi réécrire tout le site ?

Par @jbnahan69
Photo de code source
Source https://www.pxfuel.com/en/free-photo-xpaur

Cette réflexion est très ancienne pour moi, mais je vous à la suite à la série d'articles publiés récemment sur la gestion de plusieurs sites similaire dans le même dépôt de code.

Commençons par les choses qui fâche (enfin qui me fâche), malgré sa grande notoriété, Wordpress ne me convient plus. Dès que je fais une mise à jour ou que je souhaite ajouter une extension, il y a de fortes chances que ça casse quelque chose sur le site, et je ne m'en aperçois pas tout de suite malgré les tests.

Ensuite, je gère mon blog (ce site) et le site de l'extension PHP Win32Service. Ce dernier est à l'abandon à cause d'une stack technique que je ne maîtrise pas et qui a le don de m'énerver plus que Wordpress. J'aimerais déplacer les blogposts consernant Win32Service sur son site pour qu'il vive et reprendre le flux RSS sur mon site.

Ce que je recherche ?

Avant de commencer, j'ai fait un petit état des lieux des fonctionnalités que j'utilise régulièrement et de celle qui me manque.

Quelques exemples de ce que j'utilise ou pas :

  • La rédaction d'article / page avec des fonctionnalités particulières :
    • Ajout d'extrait de code source dans l'article de façon sécurisé et colorisé.
    • Pouvoir ajouter des blocs qui reprennent les X derniers articles publiés dans une catégorie ou un tag
    • Ajouter un bloc pour ajouter des informations, alerte...
  • Pouvoir définir une date de péremption de l'article (avec une alerte côté front quand la date est passée) ce qui est pratique pour les articles techniques.
  • La gestion des tags et catégorie (mais j'aimerai plus de personnalisation possible pour leur page)
  • La publication en plusieurs langues (FR/EN globalement) d'un même contenu avec la gestion correcte des URLs canonical et alternative.
  • Le module de commentaire n'est pas important, mes lecteurs ne mettent pas de commentaire (contactez-moi pour me demander de remettre le module de commentaire)
  • La publication programmée est importante, car je ne suis pas forcément disponible au moment de la publication (en général tôt le matin).
  • Une fonctionnalité que j'aimerai avoir c'est le partage programmé des publications sur Twitter et Linkedin.
  • Pouvoir gérer les redirections (automatiquement lors de la modification d'un slug, ou manuellement) et obtenir un historique des erreurs 404.
  • Pouvoir suivre les versions de PHP facilement et appliquer les mises à jour de sécurité des dépendances.

Côté front, tout est à faire, mais je compte

  • Réduire la taille des éléments téléchargés.
  • La charge processeur (réaliser un pré rendu de l'article m'intéresse).
  • Utiliser des images optimisées pour le navigateur en utilisant les nouveaux formats (WebP, JPEG2000, AVIF) avec le chargement fainéant (lazy) et une image légère intégrée à la page.
  • CSS réduit au maximum mais qui gère quand même le responsive.
  • Un minimum de JS (avec une saveur vanille de préférence).

Le budget

Parlons un peut des sous sous, bah en fait le budget est de 0€ pour ce projet (quelques bières pour ceux qui m'aideront). Seul mon temps libre sera consommé. Mais pour la mesure, voici un petit relevé du temps déjà passé :

Temps de développement du projet pour les précédents blogpost : 6h
Temps de développement passé depuis le 22 juin (entre 3h et 4h par soir) : 45h

Au taux journalier moyen de 450€ HT (ce n'est même pas mon TJM), cela donne une première valorisation à raison de 8h par jours de : ((45+6) / 8 ) x 450 = 2868.75€ HT (très loin de la licorne).

Je mets un objectif arbitraire : arriver à terminer la première version en moins de 100 heures (soit 5 625 € HT). C'est un objectif très ambitieux. Je ne suis pas sûr que vous arriviez à trouver une agence web qui propose un site sur mesure à ce prix là. Je suis conscient que c'est très peu, mais c'est un projet personnel et je fais tout SEUL.

Pour l'hébergement, j'en ai déjà un mutualisé pour Wordpress. Je compte l'utiliser ou en souscrire un autre selon les besoins techniques du site final.

La raison à un budget aussi serré est simple, les sites ne me rapportent rien, il n'y a pas de pub ni de traqueur. Seul Matomo me sert pour la mesure d’audience. Il est configuré pour le respect de la vie privée. Les résultats sont suffisants pour mes besoins.

Les CMS tout faits

J'ai regardé ce qu'il existait et rien ne correspondait à mes besoins. Enfin, si ! Ibexa Content semblait être suffisamment solide pour faire ce que je souhaitais. Il me permettrait également d'apporter les modifications nécessaires pour mes besoins.

Malgré un début de projet sur un Ibexa Content 4.0, j'ai finalement abandonné le projet.

Les raisons de cet abandon sont multiples. Dans ma liste des besoins, la mise à jour des composants est un point important. Je veux pouvoir migrer facilement de version de PHP et de Symfony (et donc d'IbexaContent). C'est un projet personnel et le temps qui sera consacré à la maintenance sera très variable. Je dois donc contrôler et réduire la chaîne approvisionnement au maximum. Que ce soit pour le font (JS/CSS) que pour la back (PHP).

En abandonnant Ibexa Content, je réduis énormément les dépendances, mais j'augmente également le besoin de développement pour la première version du site. En effet, je devrais développer le backoffice à la main. Pas question de troquer Ibexa Content contre Sonata Admin ou Easy Admin ni même le ResourceBundle de Sylius. D'autant plus que la base de l'administration est du CRUD et que Symfony MakerBundle sait très bien faire tout en laissant la possibilité de personnaliser les éléments générés par la suite.

L'autre point qui me dérangeait avec Ibexa Content et Wordpress c'est les URLs techniques. Ces URL qui permettent d'afficher un contenu grâce à son identifiant technique et qui finissent toujours par être indexées par les moteurs de recherche.

La solution retenue

À force d'en discuter avec d'autre dev, et bien sûr après avoir fait ce mini projet qui m'a servi de support pour mes articles, je me suis lancé.

Je vais donc avoir un dépôt de code source pour les deux sites (le blog et le site de Win32Service).

Symfony 6.1 sera donc le framework côté serveur et il n'y en aura pas côté navigateur.

Et je vais donc parler de ce projet et pourquoi pas, en partager certaine partie.

Pour commencé, je suis parti sur la base de mon projet test et j'ai apporté deux modifications importantes :

  • J'ai supprimé le SyliusThemeBundle, je l'ai remplacé par le fichier de configuration de Twig. Le but est de réduire les dépendances au minimum.
  • Je suis passé sur une stratégie de migration de la base de données par site web (j'ai donc supprimé les migrations communes aux deux sites).

Par contre, j'ai ajouté Liip Imagine bundle pour gérer le traitement des images, le paginator de Knp et le Captcha de Gregwar en plus des dépendances Symfony.

Le front est divisé en deux partie, la partie admin et la partie site web.

Pour la gestion du code JS, je m'impose une règle : une fonctionnalité = 1 fichier JS.

La partie admin utilise Bootstrap et le JS associés sans plus d'optimisation. Le JS écrit pour les fonctionnalités des différentes pages est natif.

Pour l'éditeur de contenu, je me suis tourné vers la version gratuite de TinyMCE. J'ai redécouvert cet outil et il a bien évolué. Contrairement à l'éditeur de Imperavi, j'ai réussi à écrire les plugins spécifiques à mes besoins en quelques heures.

Je me demande quand même si l'utilisation de TypeScript ne serait pas un avantage. Donnez-moi votre en me contactant. Je trouve cependant que PHPStorm se débrouille pas trop mal avec le JS.

La partie blog utilise également Bootstrap pour le CSS et uniquement le JS des modules nécessaires de Bootstrap sans jQuery en plus de Prism pour la coloration du code source.

Pour le site web, la légèreté est de mise, j'ai donc ajouté PurgeCSS pour permettre la suppression de tout le CSS inutilisé.

L'économie est de 89% (70.3KiB avec Purce CSS contre 656 KiB sans Purge CSS) pour le fichier app.css et de 61% pour prism.css (2.34 KiB avec Purge CSS contre 6.12 KiB sans).

Première conclusion

Repartir depuis zéro a du bon et du moins bon. Le temps de développement initial est important (et dans presque tous les cas, source de l'échec du projet), mais il peut être considérablement réduit en reportant les fonctionnalités les moins utilisées.

La liste des dépendances est moins importante qu'avec un CMS. Ce dernier m'aurait apporté une administration clé en main, mais avec des contraintes plus ou moins importante selon le CMS.

Avec moins de dépendance, c'est l'indépendante et donc la liberté ! La liberté de réaliser ce que je n'arrivais pas à réaliser avec l'ancien site.

Que pensez-vous de ce format ? Dois-je continuer ? Cela vous intéresse ? Dite-le-moi en me contactant ou sur les réseaux sociaux.

Author avatar
Jean-Baptiste Nahan

Consultant Expert Web, j'aide les entreprises ayant des difficultés avec leur projet Web.

@jbnahan69 | Macintoshplus | Linkedin | JB Dev Labs