Update Article “2023-02-28-staticcms-une-autre-approche-aux-cms”

_posts/2023-02-28-staticcms-une-autre-approche-aux-cms.md

@@ -16,6 +16,7 @@ Alors si vous avez l'habitude de réaliser vos sites webs à la main, vous devri
 À moins que… à moins qu'on puisse combiner “sites statiques” et “CMS”. Et heureusement pour nous, les sites statiques sont à la mode, donc pas mal de gens ont travaillé sur la question ces dernières années ! Quand on est cool, on appelle ça une [Jamstack](https://jamstack.org/). Ici rien à voir avec la confiture ou des concerts de musique, JAM veut dire Javascript, API et Markup, et c'est issu de réflexion par des développeurs web sur l'architecture idéale pour développer des sites webs. Nous, on va prendre juste les principes qui nous intéressent dedans.
 
 ![](/assets/screenshot-2023-02-28-at-14-47-22-for-fast-and-secure-sites-jamstack.png)
+
 Un premier principe, c'est un découplage entre le _front_, c'est à dire le site web que voient les internautes, et le _back_, c'est à dire l'interface qui permet de créer, modifier, ou supprimer du contenu. Un autre principe, c'est que le _front_ qui est présenté aux internautes doit être le plus _pré-calculé_ possible pour que ce soit le aussi rapide et économe que possible de charger une page web. À partir de ces deux principes, on a tout un ensemble de conséquences très désirables (bonnes performances, faibles coûts, sécurité, passage à l'échelle, mise en cache facilitée, etc.).
 
 Maintenant qu'on a vu la théorie, passons à la pratique, et prenons ce (billet de) blog comme exemple ! Vous lisez ce billet depuis le _front_ qui est en réalité une série de fichiers HTML, CSS et Javascript. Ces fichiers sont stockés dans garage et ont été créés par un _générateur de site statique_, ici le vénérable [Jekyll](https://jekyllrb.com/), qui va transformer des fichiers [Markdown](https://fr.wikipedia.org/wiki/Markdown) en HTML. Bien sûr, Jekyll ne fonctionne pas tout seul, ni automatiquement, il faut le lancer à chaque modification. Pour automatiser ce lancement et l'envoi des fichiers, on va utiliser un _exécuteur de tâches_, ici [Drone](https://www.drone.io/). Maintenant, il faut bien stocker ces fichiers Markdown quelque part, pour ça on utilise Git, et plus particulièrement [Gitea](https://gitea.io). Enfin, parce qu'éditer ces fichiers Markdown à la main, et les envoyer dans Git, est une tâche fastidieuse, on a créer une interface _back_ qui permet de cacher toute cette complexité et proposer un environnement d'écriture.
@@ -47,6 +48,6 @@ backend:
 
 Vous devriez maintenant pouvoir valider vos modifications dans git, les pousser sur le dépôt, et lancer un serveur de développement local (exemple : `jekyll serve`). En accédant à [http://localhost:4000/admin/](http://localhost:4000/admin/) (pensez à adapter le port) vous devriez pouvoir accéder à votre interface CMS.
 
-Une fois le CMS en place, vous pouvez configurer l'automatisation via Drone en ajoutant un fichier .drone.yml, puis en activant la CI sur votre dépôt, après avoir configuré les secrets pour publier sur Garage. Au final, vous pourrez ensuite travailler sur votre site web depuis l'URL complète de votre site, dans mon cas [https://quentin.dufour.io/admin/](https://quentin.dufour.io/admin/). 
+Une fois le CMS en place, vous pouvez configurer l'automatisation via Drone en ajoutant un fichier .drone.yml, puis en activant la CI sur votre dépôt, après avoir configuré les secrets pour publier sur Garage. Au final, vous pourrez ensuite travailler sur votre site web depuis l'URL complète de votre site, dans mon cas [https://quentin.dufour.io/admin/](https://quentin.dufour.io/admin/).
 
 Bien entendu, nous pourrions imaginer une interface qui vous permettrait de choisir _un thème_ de site web, et qui vous créerait automatiquement le dépôt, avec les bons fichiers, et la configuration Drone qui va bien, de sorte qu'en moins de 5 minutes vous aillez un squelette en ligne sur lequel vous pouvez ajouter du contenu ! C'est pour une autre fois ça :-)