Pérennité

Publié le par /

En réponse à mes questions métaphysiques sur le moyen de permettre les interactions sur ce carnet, Sarah m’a signalé le site Camen Design qui utilise pour les commentaires des articles un forum fait maison. L’idée est bonne et correspond en partie à ce que je voudrais faire. Mais…

Le site de micro-blogging Identi.ca a connu de fréquentes pannes ces derniers temps1. Ces pannes ne seraient à vrai dire pas bien gênantes si StatusNet, le logiciel de micro-blogging dont il est la vitrine, était utilisé à bon escient2. Mais malheureusement, il y a relativement peu d’instances de StatusNet dans la nature, la majorité des utilisateurs dépendent d’identi.ca, et les pannes du serveur réduisent au silence des milliers d’internautes. À vrai dire, j’ai installé StatusNet sur mon serveur, mais ne m’en sers pratiquement pas, préférant comme tout le monde utiliser identi.ca. Il suffirait pourtant de peu de choses pour remplacer mon compte sir Identi.ca par celui sur mon propre serveur. Mais…

Toute la journée, je reçois des alertes me signalant le blocage d’IP à l’origine d’attaques automatiques contre mon serveur. Tous les matins, je jette un œil aux logs pour voir s’ils ne contiennent pas de nouvelles tentatives d’attaques, et ajouter si nécessaire de nouvelles règles de filtrage. Je met à jour mes logiciels, suis les alertes de sécurité, les annonces de failles… et serre les fesses pour qu’un des logiciels qui tournent sur ma machine ne soit pas victime d’un faille exploitée par les kits d’attaque clé en main dont se servent tous les script kiddies. Bien sûr, cela ne me prend que quelques minutes chaque jour, mais pour être efficace n’autorise aucun repos. Il faut prendre ces quelques minutes tous les jours, ne jamais relâcher sa vigilance. Surtout, espérer que les logiciels, et même les technologies que l’on utilise, seront maintenues sur le long terme. Quid par exemple si j’installe une galerie d’image qui dans cinq ans sera abandonnée et ne recevra plus de mise à jour de sécurité. Quid encore si le logiciel que j’utilise évolue dans une direction qui ne me plait pas ? C’est le cas par exemple de StatusNet. C’est un bon logiciel de micro-blogging, mais la version 1.0 a inauguré de nouvelles fonctions, le destinant davantage à un usage en entreprise. Si je veux continuer à avoir un logiciel à jour du point de vue de la sécurité, il me faut adopter cette branche, même si elles contient de nombreuses fonctions que je n’utiliserai pas. D’où ma réticence à utiliser mon instance de StatusNet plutôt qu’Identi.ca. Parce que je ne sais pas combien de temps encore le logiciel me donnera satisfaction. Et n’ai pas envie de passer davantage de temps qu’aujourd’hui à assurer sa maintenance quotidienne.

Avec le temps, je suis de plus en plus réticent à installer de nouveaux logiciels. Je sais que chacun augmente le coût de maintenance, le temps que je devrais passer chaque jour à m’occuper du serveur. Multiplie également les risques d’attaque. Oui, la vieillesse est un long naufrage où l’on sombre lentement dans le conservatisme toujours plus figé ;)

On conseille souvent, pour garantir la pérennité de ses données, de ne pas faire confiance à des services qui risquent de fermer du jour au lendemain, mais de privilégier l’auto-hébergement. C’est vrai. En partie. Car l’auto-hébergement ne protège pas de l’obsolescence des logiciels et des technologies. Le Web grand public a une quinzaine d’années à présent, et j’ai l’impression que la plupart de ses contenus des premières années ont commencés à disparaître. Et pas seulement parce qu’ils étaient hébergés chez Mygale ou GeoCities. Que deviendront tous nos contenus stockés dans des bases MySQL lorsqu’un de ces jours Oracle achèvera la base de données de nos premières amours. Aurons-nous l’envie / le courage d’installer une autre base et de migrer ?

Outre l’obsolescence des technologies et le coût de maintenance des logiciels serveurs, un autre point à prendre en compte pour assurer la pérennité de nos contenus est la gestion de la permanence des URLs. Des URLs sympa ne devraient pas changer. Hélas, lorsqu’on crée un contenu, on ne fait pas toujours attention à l’URL. On laisse le CMS la fixer pour nous. On n’imagine pas tout ce qui va arriver, les autres espaces de nom dont on aura besoin pour d’autres projets, etc. Cinq années, deux changement de logiciel et un d’hébergement plus tard, on se retrouve à gérer des règles de ré-écriture d’URL de plus en plus complexes pour que tout le bazar reste accessible. La prochaine fois, il faudra réfléchir davantage aux URL avant de lancer un nouveau projet.

Tout cela pour dire qu’à l’instar de bon nombre de mes estimables collègues, je me dis de plus en plus que la meilleure solution de publication sur le Web, la plus résistante parce que peu coûteuse en maintenance, celle qui garantit la pérennité à long terme des contenus, c’est un bon vieux site statique en HTML. Ce qui ne signifie pas non plus revenir entièrement au début de l’histoire et recommencer à tout faire à la main, car on serait vite fatigué et repartirait pour un nouveau cycle d’invention de systèmes de publication. Pas revenir au tout début, non. Mais apprendre de ces dix ou quinze ans depuis lesquels on publie nos bêtises en ligne, pour essayer de rendre le Web un peu plus résilient.

Quand à savoir si assurer la pérennité sur le long terme de nos publications a le moindre intérêt autre qu’égocentrique… Je répondrais oui, sans hésiter. Nos gribouillis font partie de notre mémoire et de la mémoire commune. Et la mémoire est importante. Ne serait-ce pour nous rappeler qu’on n’apprend rien de nos erreurs.

  1. à la décharge de son créateur, Evan Prodromou, il semble seul pour s’occuper d’un service équivalent à Twitter.

  2. car StatusNet n’est pas seulement une version libre de Twitter, c’est aussi un logiciel intégrant nativement des fonctions de décentralisation. Son but n’est pas de créer un site unique, pendant à Twitter basé sur un logiciel libre, mais que chacun, ou chaque communauté, installe sa propre instance du logiciel, les instances permettant les conversations de l’une à l’autre. Si cette logique était largement adoptée, la défaillance d’un serveur ne pénaliserait que peu les utilisateurs du logiciel.

Pour réagir, n'hésitez-pas à m'écrire : clochix chez clochix.net ou à soumettre l'url de votre commentaire :
(Je traite les mentions à la main, elles peuvent mettre plusieurs jours avant d'apparaître)

Si vous avez un compte Github, vous pouvez me proposer des corrections en éditant ce billet

Fork me on GitHub