Choisir un CMS pour construire son site
La première question qu'on peut se poser avant de créer un site Web, est quelle solution choisir.
De nombreuses solutions s'offraient à moi :
De nombreuses solutions s'offraient à moi :
- Utiliser un CMS en SaaS
- Utiliser un CMS dynamique avec rendu côté serveur
- Utiliser un static site generator, permettant de générer directement des pages HTML.
CMS en SASS ?
Utiliser un CMS en SaaS a plusieurs intérêts valides. Le premier est de n'avoir pas à gérer l'infrastructure du site, car le back-office et le front sont gérés par la solution.
De plus les solutions SaaS se sont améliorées avec le temps, que ce soit en terme d'interface ou tout simplement en possibilité du customisation.
On pourrait penser à Wix, car les publicités de cette solution inondent le web, mais il existe, je trouve, des solutions plus modernes et innovantes, comme Webflow par exemple.
J'ai malgré tout écarté cette solution, car je voulais être maître de mon contenu. Il ne faut pas oublier qu'utiliser une solution SaaS, vous lie pieds et mains avec la plateforme.
Si demain, la solution décide de doubler ses prix ou si l'entreprise ferme, passer sur une autre solution sera moins aisé.
L'autre problématique souvent relevée, est liée au référencement.
Le fait que les site builders comme Wix sont souvent plus lents à s'afficher, impacte le référencement.
De plus les solutions SaaS se sont améliorées avec le temps, que ce soit en terme d'interface ou tout simplement en possibilité du customisation.
On pourrait penser à Wix, car les publicités de cette solution inondent le web, mais il existe, je trouve, des solutions plus modernes et innovantes, comme Webflow par exemple.
J'ai malgré tout écarté cette solution, car je voulais être maître de mon contenu. Il ne faut pas oublier qu'utiliser une solution SaaS, vous lie pieds et mains avec la plateforme.
Si demain, la solution décide de doubler ses prix ou si l'entreprise ferme, passer sur une autre solution sera moins aisé.
L'autre problématique souvent relevée, est liée au référencement.
Le fait que les site builders comme Wix sont souvent plus lents à s'afficher, impacte le référencement.
CMS dynamique ?
Ce que j'entends par CMS dynamique, c'est un CMS avec rendu côté serveur, souvent en PHP, utilisant une base de données pour stocker le contenu du site.
On pense forcément à Wordpress qui reste de loin la solution la plus utilisée, mais on pourrait également penser à Drupal.
Sur le papier, cela semble la solution idéale, car de nombreux thèmes existent pour développer un site rapidement, de nombreux modules / plugins, sont développés pour aider à intégrer des fonctionnalités que ce soit pour le référencement, l'analytics ...
Mais le fait que ce soit la solution la plus utilisée, constitue également le frein le plus important.
En effet, Wordpress est le vecteur d'attaque le plus commun. Posséder un site Wordpress oblige à mettre à jour régulièrement le site.
Cela s'explique par le fait que les hackers savent qu'il est plus rentable de s'attaquer à la solution la plus utilisée.
De plus, la qualité des modules tiers est aléatoire et les failles de sécurité peuvent arriver par ce biais là.
On pense forcément à Wordpress qui reste de loin la solution la plus utilisée, mais on pourrait également penser à Drupal.
Sur le papier, cela semble la solution idéale, car de nombreux thèmes existent pour développer un site rapidement, de nombreux modules / plugins, sont développés pour aider à intégrer des fonctionnalités que ce soit pour le référencement, l'analytics ...
Mais le fait que ce soit la solution la plus utilisée, constitue également le frein le plus important.
En effet, Wordpress est le vecteur d'attaque le plus commun. Posséder un site Wordpress oblige à mettre à jour régulièrement le site.
Cela s'explique par le fait que les hackers savent qu'il est plus rentable de s'attaquer à la solution la plus utilisée.
De plus, la qualité des modules tiers est aléatoire et les failles de sécurité peuvent arriver par ce biais là.
Static Site Generator
Pour mon besoin, aucun système nécessitant un back-end. Rendre des pages HTML est suffisant. L'intérêt de n'avoir aucun langage côté serveur est de pouvoir mettre son site sur un CDN entièrement sans avoir des stratégies de cache compliquées. Tous les assets et pages seront mis en cache de la même manière. L'autre intérêt est un coût moindre car un CDN coûte moins cher qu'un serveur.
En faisant le comparatif entre les différentes solutions que ce soit javascript (Nextjs, Nuxt..), Go (Hugo) ou Ruby (Jekyll), mon choix s'est porté sur Hugo.
Les solutions JavaScript sont souvent très lourdes en terme de dépendances.
En essayant de démarrer un nouveau site Nuxt, je me suis rendu compte que NPM téléchargeait plus de 400 Mo de dépendances.
J'ai également le souvenir dans le passé, d'être revenu sur un projet JavaScript qui avait deux ans. Le simple fait d'essayer de récupérer les dépendances pouvait être une gageure.
Partant de ce constat, et en analysant les fonctionnalités d'Hugo, je me suis dit qu'il était le choix parfait pour mon besoin.
Si j'ai besoin un jour de fonctionnalité intéractives, comme par exemple un système de commentaires, une page de contact, ces fonctionnalités seront externalisées.
En faisant le comparatif entre les différentes solutions que ce soit javascript (Nextjs, Nuxt..), Go (Hugo) ou Ruby (Jekyll), mon choix s'est porté sur Hugo.
Les solutions JavaScript sont souvent très lourdes en terme de dépendances.
En essayant de démarrer un nouveau site Nuxt, je me suis rendu compte que NPM téléchargeait plus de 400 Mo de dépendances.
J'ai également le souvenir dans le passé, d'être revenu sur un projet JavaScript qui avait deux ans. Le simple fait d'essayer de récupérer les dépendances pouvait être une gageure.
Partant de ce constat, et en analysant les fonctionnalités d'Hugo, je me suis dit qu'il était le choix parfait pour mon besoin.
Si j'ai besoin un jour de fonctionnalité intéractives, comme par exemple un système de commentaires, une page de contact, ces fonctionnalités seront externalisées.
