Créée le mardi 30 janvier 2024
index
Premier contact
J'ai lu 2-3 choses sur Garage, une solution créée par l'association deuxfleurs pour faire du partage distribué de fichiers tout en restant sobre au niveau des ressources. Lors de ce premier contact, j'ai entendu parler de l'état d'esprit lié à ce développement, le réappropriation du web par les usagers couplé à des enjeux de sobriété technologique. J'ai aussi entendu parler de standard aws ou S3 ce qui en tant que libriste a eu pour effet d'un peu me dresser les oreilles : qu'est-ce qu'un protocole Amazon vient faire là-dedans... ? Que voulez-vous, quand on n'utilise pas les services GAFAM, on ne connaît pas non plus leurs standards, etc.
Bref, tout çà pour dire que je n'ai pas saisi tout de suite l'intérêt de Garage pour moi, un usager individuel du web qui cherche à mettre des choses en ligne, comme ce billet, mais tout en restant maître techniquement de la solution utilisée, qui idéalement doit être dans l'esprit du libre, associative, etc.
Le besoin technique pour être en ligne
Lorsque l'on crée du site et que l'on veut mettre en ligne quelque chose, des billets de blog ou autre, on a besoin :
- d'un serveur en ligne
- de fichiers sur ce serveur
- d'un outil logiciel qui sert ou met en forme ces fichiers pour qu'ils soient accessibles sous forme d'un site web.
- d'un nom de domaine qui pointe vers ce serveur, d'un certification SSL sur le serveur, de la sécurité côté serveur
Au niveau de l'architecture de la relation client-serveur, on a le choix entre :
- serveur avec code actif, fichiers, base de données : c'est le typique php / mysql
- serveur avec fichiers texte + code actif : php ou nodejs ou python
- serveur en serveur de fichiers statiques "pur" c'est à dire sans code actif côté serveur. Soit on utilise une "moulinette" qui permet de générer le site à partir des fichiers (générateur de sites statiques) voire même du code actif côté client qui met en forme le site "à la volée".
Dans tous ces cas de figure, on peut avoir ou pas du code actif "client side".
Le besoin d'hébergement associé
En pratique, on a grosso-modo les solutions suivantes :
Note : Pour la suite, je traite essentiellement de l'hébergement, le nom de domaine étant un sujet en soi et que l'on peut faire pointer vers la solution de son choix.
- solution "clé en main" : dans ce cas de figure, un prestataire de service ou une asso fournit une solution opérationnelle sur ses serveurs et permet de passer à l'action rapidement. C'est intéressant si on n'a pas de pré-requis en terme d'autonomie, de sobriété, etc. Que l'on est prêt à accepter de travailler en ligne. Typiquement, c'est un wordpress sur wordpress.com ou encore chez un CHATONS type Te Domum par exemple. Cette solution fournit un nom de sous-domaine du domaine principal. Concrètement, on travaille en ligne dans le navigateur pour créer son site.
- hébergement mutualisé : dans ce cas, un prestataire de service fournit un espace disque partagé sur un serveur qui dispose en général de langage côté serveur (php, python, nodejs, ...). C'est couplé à un nom de domaine, la gestion du certificat SSL, de la sécurité sur le serveur, etc. On a deux options d'utilisations :
- soit on installe une application php/mysql sur le serveur et on se retrouve quasiment dans la même situation qu'un "clé en main" sauf qu'on a son nom de domaine dédié, etc. On travaille alors en ligne.
- soit on envoie soi-même les fichiers du site en ligne grâce à une communication dite FTP. C'est la façon "classique" de faire des sites depuis le début du web.
- serveur personnel en ligne : ici, on loue un serveur personnel, appelé VPS, et on assure soi-même tous les aspects sur ce serveur. On peut indifféremment faire un serveur très simple à des choses complexes voire ésotériques. On peut faire absolument ce que l'on veut. On accède au site par SSH.
- serveur personnel chez soi (auto-hébergement "vrai") : c'est comme pour le VPS, mais de chez soi. La problématique principale soulevée ici est l'accès au serveur local depuis le web. Il existe des solutions, mais ce n'est pas toujours très simple et de plus çà expose le réseau local potentiellement.
- une autre solution qui est possible, c'est de placer des fichiers sur une forge logicielle, un espace de gestion de fichiers avec versions, et à partir de ces fichiers, générés par un processus automatique les pages webs associés. C'est typiquement les pages github ou les gitlab pages. C'est possible auprès d'acteurs CHATONS et pour l'avoir fait, çà fonctionne vraiment pas mal. Mais c'est quand même un peu lourd juste pour faire un site.
- encore une autre solution est la possibilité d'un blog dans le fediverse : c'est un service fournit par writefreely que l'on trouve chez quelques CHATONS notamment Te Domum. Un autre exemple est Plume que l'on trouve chez deuxfleurs.fr
Et Garage dans tout çà ?
En fait, quelque soit la solution envisagée, l'individuel qui veut mettre un petit site en ligne se retrouve obligé soit de faire appel à un prestataire en général payant, ou de s'enfermer dans une solution gratuite mais peu souple à terme (type wordpress.com and co), soit de gérer beaucoup de choses lui-même (nom de domaine, certificat SSL, voire sécurité du serveur)et simultanément peut se retrouver face à de la complexité technique. Y compris pour un besoin très simple.
Garage va venir offrir une solution alternative intéressante : Garage va offrir l'équivalent d'un espace disque en ligne mais qui sera hébergé en associatif et redondant sur 3 machines. Le choix du service fournit par l'asso deuxfleurs fournit immédiatement un nom de sous-domaine et le ssl actif. La limite, c'est que Garage ne pourra gérer que des sites dits statiques mais on peut aller assez loin de cette façon malgré tout.
Concrètement, c'est une solution potentiellement simple, au moins sur le papier, pour mettre en ligne un site puisque l'on peut envoyer les fichiers par FTP notamment.
Par la suite, nous allons explorer l'utilisation de Garage.
Chaque solution a ses avantages/inconvénients ainsi que ses impératifs en terme de coût.