Dans public/admin/index.html, le CMS de ce site est appelé comme ceci :
<script src="https://unpkg.com/@sveltia/cms@0.172.2/dist/sveltia-cms.js"
integrity="sha384-rLinm2T7k+hELzRDmWwenzg5hwTV2Pqs+mHvP32ZwyE35nGEXvJ8Kuys/WKCjtvr"
crossorigin="anonymous"></script>
Une version épinglée, et l’empreinte du fichier attendu. Si unpkg servait un autre contenu demain, le navigateur refuserait de l’exécuter. J’ai pu écrire cette ligne parce que le fichier est public et que son empreinte se recalcule en une commande. Avec un service fermé, elle n’existerait pas.
Open source évoque encore, pour certains, le bricolage gratuit et un peu fragile. J’entends souvent la réserve et je la comprends : gratuit rime rarement avec sérieux. Mon expérience dit l’inverse, et pas pour des raisons militantes.
Inspectable, donc vérifiable
Un outil ouvert, je peux lire son code. Je sais ce qu’il fait et ce qu’il envoie. Quand un client demande où passent ses données, je peux répondre en montrant. Un service propriétaire répond « faites-nous confiance », ce qui est peut-être vrai et n’est jamais vérifiable.
Pas d’abonnement, pas de laisse
Astro pour le site et Sveltia pour l’édition ne facturent rien et n’enferment rien. Pas de palier tarifaire qui grimpe avec le trafic, pas d’éditeur qui ferme boutique en emportant le contenu. Si je veux changer une brique, les formats restent standard : du HTML, du Markdown, du git.
Le nombre au service de la robustesse
Un projet ouvert et très utilisé est éprouvé par un monde entier d’usages, dont beaucoup que ses auteurs n’avaient pas prévus. Les bugs remontent vite, les correctifs arrivent vite. Un outil fermé n’est testé que par ceux qui le vendent, et sur les cas qu’ils ont imaginés.
C’est pour la même raison que je publie mes propres outils en open source, EVA CSS le premier.



