shshsh shshsh shshsh shshsh  sh  sh  sh  sh
sh     sh  sh   sh     sh    sh  sh  shshsh
sh     shshsh   sh     sh    sh  sh  sh  sh
sh     sh  sh   sh     sh    sh  sh  sh  sh
shshsh sh  sh   sh   shshsh  shshsh  sh  sh

                   Wait it's all shell scripts ?
                            /
                           🚶🔫🚶 - Always has been

Une histoire de Catium

Je discutais un jour avec une personne du contenu que l’on consommait sur internet. Le dialogue était à peu près le suivant, elle commence :

A - “Je suis abonné à plusieurs newsletters de journaux, de blogs, de revues etc"
B - “Ah j’aime pas trop les newsletter, perso j’utilise des flux rss quand ils existent"
A - souriant je crois un peu nerveusement “Ah ouais ? C’est pas vieux et presque mort les flux rss ? Je pensais que plus personne n’utilisait ça."
B - “Bah c’est plus vraiment à la mode mais c’est encore presque partout et je le préfère aux newsletter parce que blablabla”

J’ai repensé plusieurs fois à cet échange depuis. Je n’ai pas été surpris pas le manque de considération pour des technologies pensées comme vieillissantes, obsolètes, démodées, remplacées. J’ai été cependant marqué par le fait que cette personne percevait les flux rss comme plus vieux et donc moins digne d’intérêt que les mails. Pourtant les mails (entre 27 et 50 ans) sont bien plus anciens que les flux rss (23 ans). Il y a donc autre chose à l’œuvre, quelque chose qui modifie notre perception de l’ancienneté d’une technologie indépendamment de son âge réel. On peut imaginer pleins de facteurs pouvant l’expliquer, le taux d’adoption en est un assez évident, comme si l’on commençait à décompter l’âge d’une techno qu’à partir du déclin de son utilisation. Je pense qu’il y en au moins un autre. Il se trouve que cette personne écrit une newsletter et qu’elle utilise le service Substack pour le faire. Substack est une plateforme proposant des services pour construire et publier des newsletter monétisables. L’outil profite d’une certaine hype, construit par défaut des newsletter avec tous les codes esthétique du web et des pages webs associées. J’imagine que ce qui explique en partie que cette personne ne voit pas la publication et l’agrégation de contenu web à travers des mails comme une pratique obsolète contrairement aux flux rss est le fait qu’elle le fait à travers un service qui a techniquement, mais surtout socialement, repackagé la pratique. On n’envoie plus des mails à la papa, “on a un Substack”. La corolaire dit donc qu’une plateforme de la silicon valley ou un projet open source à la mode pourrait relancer la popularité des flux rss sans modifier quoi que ce soit à la techno.

Ce phénomène, qui s’il en est vraiment un doit déjà être connu et porter un nom que j’ignore, se retrouve à mon avis avec medium et la pratique d’avoir un blog ainsi que jekyl/hugo et le fait de construire des sites statiques plutôt qu’une single page app.

On peut se réjouir de cette résurgence des sites statiques pour de multiples raisons. On peut regretter - pas trop fort mais quand même - que cela ait nécessité l’apparition de nouveaux logiciels pour motiver l’industrie à s’y remettre. Cela semble être la démonstration parfaite que parfois, peut-être même souvent, ce que la technologie facilite et sa façon de se présenter à nous (voir le concept d’affordance, des outils de génération de sites statiques ont toujours existé) a un impact conséquent sur les comportements humains jusqu’à créer à posteriori les idées et justifications morales de son utilisation. Autrement dit, on (du moins je) voyait peu d’articles faisant la promotion des sites statiques avant l’apparition de ces outils. C’est dorénavant assez fréquent avec une mention presque systématique de ces outils de là à presque oublier pourquoi un site statique est dans certains cas préférable.

Autre constat, ces outils destinés à produire des sites simples, le sont assez rarement eux-mêmes. Évidemment cela dépend du référentiel choisi. On aura du mal à argumenter qu’hugo est aussi lourd et complexe à dégainer que React. Mais au regard des fonctionnalités essentielles pour un générateur de site statique, il est possible d’argumenter qu’hugo est un logiciel trop complexe et faisant trop de choix pour vous. On pourrait épiloguer là dessus, pour une autre fois et une autre personne peut-être.

Si ces outils ont relancé l’intérêt pour les sites statiques, Catium souhaite à son tour profiter de l’intérêt nouveau pour les sites statiques afin de relancer l’intérêt pour une certaine approche du développement d’outils numériques, que l’on choisit à tort ou à raison d’appeler convivialiste. Plus concrètement cette envie s’est cristallisée courant 2022 à l’Université de Strasbourg autour du besoin de générer des sites statiques pour le domaine de la recherche. L’une des utilisations identifiées était la création de page personnelles pour les chercheureuses. Pour en faire une démonstration il avait été décidé de faire la page de Marguerity Perey, chercheuse française ayant travaillé à l’université de Strasbourg et ayant découvert… le catium.
Ce projet initial de générer des pages personnelles de chercheureuses n’est pas mort. Un template html et une feuille de style adéquate, à l’identité visuelle Unistra, pourrait aider à le concrétiser.

C’est finalement la page perso de Marc Chantreux aujourd’hui hors ligne qui sera le premier site généré et publié grâce à Catium. A date du 11 janvier 2023 le site généré par ce dépôt est le seul en ligne généré par Catium. Le socle du projet a été conçu et développé par Marc Chantreux. Après la mise en ligne de ce site le développement s’est étendu à d’autres membres du collectif Kaztele.

Il y aurait bien d’autres choses à dire sur la genèse du projet, d’où le titre de cette rubrique, Une histoire de Catium. J’invite les autres parties prenantes à écrire la leur.

Sur la nature de Catium

Un jour Marc et moi sortions de plusieurs heures de discussions pendant lesquelles nous avons plusieurs fois fait référence à Catium comme un outil atomique, se suffisant à lui même. En disant ça nous mettions peut-être dans la tête de nos interlocuteurs l’image d’un simple couteau qui tient dans la main, dont les contours sont nettes et la forme plus ou moins identique pour tous ses utilisateurices. En sortant nous nous sommes partagés une intuition commune : cette image n’est pas celle qui se formait dans nos têtes quand on parlait de Catium. Il est compliqué de définir le périmètre exact de ce qu’est Catium.

Où est-ce que l’outil commence, où est-ce qu’il se termine ? Qu’est-ce qui relève du générateur et qu’est-ce qui relève du contenu du site ? Ces interrogations se retrouvent dans certains choix techniques que le projet est amené à prendre. Ce dépôt permet aujourd’hui de versionner à la fois Catium (sans savoir ce que c’est exactement) et le contenu du site de Katzele. Si nous voulions créer un dépôt Catium pour d’autres projets nous devrions répondre à ces questions pour détricoter l’un de l’autre.

Pourquoi n’est-ce pas trivial ?

Prenons en exemple atomic, le script permettant de générer des flux atom.

Premier point d’accroche, tous les sites n’ont pas besoin d’un flux atom. Bien que ce soit souvent utile et qu’atomic soit léger, l’inclure dans le dépôt revient à penser que tous les projets, ou au moins une majorité, ont intérêt à avoir un script de génération de flux atom.

Second point, si l’on fait le choix de l’inclure par défaut, tous les flux ne veulent pas y inclure les mêmes informations. Au delà de la spécification des flux rss/atom, chaque projet peut vouloir mettre quelque chose de différent dans les balises. Par exemple la balise “content” est très libre, et son contenu peut éventuellement être mis en page avec de l’html. Autre exemple, un flux annonçant des évènements dans le futur voudra sûrement inclure la date dans le titre, la spécification atom n’ayant pas prévue de balise pour renseigner la sortie d’un contenu dans le futur. La seule date prévue est celle de publication du contenu qui ici est l’annonce au présent de la tenue de l’évènement dans le futur. Il tombe donc sous le sens qu’aucun script atomic ne se ressemblera. Quel doit donc être l’atomic par défaut ? Le minimum vital ? Un script générant un flux orienté annonce d’évènements ou publications d’articles ?

Troisième point, qui découle du précédent, un projet pourrait vouloir générer plusieurs flux aux formes différentes. Il pourrait alors vouloir plusieurs atomic. Ce qui pose la question, qu’est-ce que l’on appel atomic ? Le script par défaut tel que fourni dans le dépôt source s’il existe un jour ? La version actuelle maintenue pour le site de Katzele ? L’idée de générer un flux atom via du shell ? Bref on en a pas fini.

Nous pourrions décliner ces questions pour toutes les parties de Catium. Pour revenir à l’échange avec Marc, il avait d’avantage mûri la question que moi. Catium ne devrait pas être pensé comme, un outil indivisible mais une comme armature intellectuelle soutenant des outils, certains pré existants, d’autres créés pour l’occasion. D’ailleurs pour le site de Katzele sed est un outil autant nécessaire qu’atomic même si l’un a été développé pour et l’autre non.\ Si l’on voulait pousser cette idée d’armature intellectuelle jusqu’au bout nous pourrions dire que Catium est un système décrit à travers de la documentation et non pas ses implémentations. Il n’existerait donc pas de sous-ensemble de ce dépôt que l’on pourrait raisonnablement appelé Catium. Ce dépôt ne serait que la première implémentation de Catium, celle sous une forme qui rend les services dont le collectif Katzele a besoin à un instant T.

Il existera probablement un jour un dépôt Catium dont le contenu aura été le résultat de choix plus ou moins raisonnables, fait en fonction des projets qui veulent utiliser Catium sur le moment¹. Ce sera certainement pour le mieux. Si le concept un peu prétentieux d’armature intellectuelle nous sert à quelque chose ce sera de faire sens de cette tension : construire un outil convivialiste qui respecte autant que possible l’autonomie des personnes qui l’utilisent en minimisant les choix qu’il véhicule et vouloir le publier facilement n’est pas naturel. La première caractéristique incite à la construction d’une armature, l’autre à celle d’un outil boite noire.
Tracer le contour optimisant la convivialité et la facilité de publication étant hasardeux, on le fera à main levée et on compensera comme il se doit, en conversant entre humains, en vivant ensemble.