Utiliser des sites web statiques pour de petites archives
(alexwlchan.net)- Pour retrouver plus tard des documents, captures d’écran, marque-pages et médias accumulés en local, chaque petite collection est explorée via un site web statique
- Chaque collection reste un dossier sur le disque, et un fichier HTML à la racine, ouvert dans le navigateur, offre plus de métadonnées et d’options d’organisation que le Finder
- Le tout est écrit à la main, sans serveur web, système de build, dépendances ni framework JavaScript ; chaque site ne fait au plus que quelques centaines de lignes de code, ce qui convient à de petits projets
- Les hiérarchies de dossiers classiques, les tags du Finder, les applications « fourre-tout » et les outils faits maison présentaient chacun des limites : rigidité hiérarchique, implémentation insuffisante, nécessité d’adopter la logique de l’app, ou charge de maintenance
- L’organisation manuelle prend du temps, mais elle aide à ne conserver que les fichiers qui en valent la peine, et la simplicité du HTML favorise la conservation à long terme
Voir des archives locales comme des mini-sites web
- Des sites web statiques sont créés pour chaque collection afin de parcourir des archives locales
- documents numérisés
- documents créés soi-même
- captures d’écran enregistrées
- marque-pages de pages web sauvegardés
- fichiers vidéo et audio conservés
- Chaque collection a une présentation différente selon la nature des fichiers
- une collection de captures d’écran s’affiche sous forme de grille d’images
- les marque-pages apparaissent comme une liste de liens textuels
- les vidéos sont organisées dans une liste mêlant vignettes et texte
- L’objectif n’est pas de bâtir un système complexe, mais de créer une interface d’exploration de fichiers un peu meilleure que le Finder de macOS
- il est possible d’ajouter davantage de métadonnées dans la page
- on peut utiliser ses propres méthodes de recherche et d’organisation
Organisation et choix techniques
- Chaque collection est un dossier sur le disque local, et le site web consiste en un ou plusieurs fichiers HTML placés à la racine de ce dossier
- À l’usage, les fichiers HTML sont ouverts directement dans un navigateur web
- Le choix est délibérément de rester à petite échelle et avec une faible complexité technique
- pas de serveur web
- pas de système de build
- pas de dépendances
- pas de framework JavaScript
- Tout est écrit à la main, mais cela reste gérable pour de petits projets
- chaque site web ne fait au plus que quelques centaines de lignes de code
- Comme l’ensemble repose uniquement sur les fichiers du disque et du HTML, il est considéré comme plus durable dans le temps
- cela préserve la simplicité et la portabilité de la structure de dossiers
- en y ajoutant seulement les fonctions nécessaires
Pourquoi les approches précédentes n’ont pas tenu dans la durée
- Le modèle classique fichiers/dossiers impose une structure hiérarchique, et chaque fichier doit se trouver à un seul endroit précis
- cela fonctionne bien pour certaines données, comme du code
- mais il était difficile de concevoir une hiérarchie satisfaisante pour des fichiers média
- à force d’hésiter sur le bon dossier, le bureau finissait en désordre
- Le balisage par mots-clés est préféré, car il permet d’attribuer plusieurs étiquettes à un même fichier et de le retrouver de plusieurs façons
- le Finder de macOS prend aussi en charge les tags, mais leur implémentation n’a pas semblé assez solide pour un usage important
- Les applications « fourre-tout » comme DEVONThink, Evernote, Yojimbo ne convenaient pas non plus
- il y avait l’impression de devoir adapter sa manière de penser au fonctionnement de l’application
- Des outils maison de classement de fichiers ont aussi été tentés au moins une douzaine de fois, dont l’une des dernières était docstore
- ils correspondaient mieux à la manière de penser de l’auteur, mais introduisaient une charge de maintenance
- à chaque mise à niveau de Python ou mise à jour de macOS, quelque chose cassait et il fallait corriger le code
Transformer des dossiers en mini-sites web
- En plaçant un fichier HTML servant d’index dans le dossier de premier niveau, il devient possible d’afficher tous les fichiers avec les métadonnées et tags souhaités
- Cette approche simplifie la structure des dossiers et réduit la pression de devoir trouver une hiérarchie parfaite
- les fichiers sont généralement regroupés seulement par année ou par première lettre du nom de fichier
- les dossiers ne sont consultés que lors de l’ajout de nouveaux fichiers, pas pour la navigation
- pour retrouver un fichier, le site web est toujours utilisé
- Le site web permet de retrouver les fichiers de plusieurs façons grâce aux tags par mots-clés, tout en masquant les détails de la structure réelle des dossiers
- Le HTML a été choisi comme technologie peu exigeante en maintenance, flexible et peu susceptible de disparaître
- c’est une technologie fondamentale du web
- presque tous les ordinateurs modernes ont un navigateur capable d’afficher des pages HTML
- même un premier site scolaire créé en 2006 s’affiche encore sans problème dans un navigateur moderne
Pourquoi cela convient aux « petites » archives
- Comme le classement des fichiers, la rédaction des métadonnées et la création de la visionneuse se font largement à la main, cette méthode passe mal à l’échelle pour de grandes collections
- Même conserver quelques centaines d’éléments demande un temps non négligeable, mais cette friction aide à choisir ce qui mérite vraiment d’être gardé
- elle pousse à se demander si le fichier mérite réellement d’être bien organisé
- elle amène à se demander si l’on reverra un jour un fichier qu’on ne voudrait même pas passer une minute à sauvegarder
- pour les fichiers finalement conservés, elle incite à mieux rédiger les métadonnées afin de les retrouver plus facilement plus tard
- Auparavant, des milliers de fichiers s’accumulaient dans de gros dossiers vagues, et comme ils n’étaient pas correctement organisés, ils n’étaient jamais revus
- Désormais, il existe de petits sites web contenant quelques centaines d’éléments, choisis avec plus de soin et décrits de façon plus utile
- Même en aimant l’automatisation, les contraintes d’un processus plus manuel sont ici vues de manière positive
Les sites web statiques comme outil de conservation
- Cette approche a été inspirée par l’export de compte Twitter
- l’export de compte Twitter fournit un mini-site web navigable en local
- plusieurs plateformes de réseaux sociaux proposent aussi leurs données sous forme de site web facile à parcourir pour un humain
- Les sites web statiques peuvent aussi être utiles comme méthode de préservation numérique pour des archives born-digital
- leur simplicité, leur pérennité et leur faible besoin de maintenance ont encore plus de valeur pour les institutions patrimoniales qui visent une conservation sur des décennies ou des siècles
- il suffit d’un simple bloc-notes ou éditeur de texte pour créer un site web HTML basique
- Le Data Lifeboat project construit ainsi des sites web statiques plus vastes pour empaqueter une partie des archives de Flickr
- les archives locales ressemblent en général davantage à des vues en liste, tandis que les sites du Data Lifeboat offrent davantage de pages et de fonctionnalités
- Le billet d’Ed Summers sur les sites statiques pour préserver Historypin va dans le même sens
Migration progressive et usage personnel du HTML
- Comme de nombreux fichiers sont déjà dispersés sur le disque, tout déplacer d’un seul coup représenterait trop de travail
- Les nouveaux fichiers sont stockés dans des sites web statiques, et les anciens sont déplacés depuis leur emplacement d’origine vers le dossier du site statique approprié au moment où on en a besoin
- Une fois la structure initiale du site mise en place, la charge de maintenance nécessaire pour le faire fonctionner est devenue presque nulle
- Pour celles et ceux qui veulent créer leur premier site web, Blake Watson recommande HTML for People
- le projet porte l’idée que « si on le souhaite, tout le monde devrait pouvoir créer un site web en HTML »
- Le HTML a longtemps été perçu comme un outil servant à publier des sites web destinés aux autres, mais il peut aussi servir à des archives personnelles locales
- Mise à jour du 19 février 2025 : ajout d’un billet de suivi expliquant les détails du code, How I create static websites for tiny archives
1 commentaires
Avis Hacker News
Copier des images depuis le presse-papiers pour les enregistrer dans un fichier HTML et s’en servir comme galerie en un seul fichier
https://gist.github.com/egeozcan/b27e11a7e776972d18603222fa5...
Exemple live : https://gistpreview.github.io/?b27e11a7e776972d18603222fa523...
La sélection via le sélecteur de fichiers fonctionne aussi, mais le glisser-déposer marche généralement mal. Quand ça fonctionne correctement, l’image est insérée en ligne dans le document sous forme de blob
Après avoir ajouté une image, si l’on enregistre la page telle quelle, c’est-à-dire avec file->save, le blob est également enregistré. Si l’on veut en retirer une partie avant l’enregistrement, par exemple supprimer une image, il suffit d’ouvrir l’inspecteur d’éléments, de la retirer, puis d’enregistrer la page
Ce fichier peut être mis sur un serveur, ou ouvert d’un double-clic sur un ordinateur ou un mobile
https://github.com/cadars/john-doe donne une impression similaire
Prototype rapide : https://gistpreview.github.io/?14a2c3ef508839f26377707dbf5dd... - code : https://gist.github.com/simonw/14a2c3ef508839f26377707dbf5dd...
Dans les commentaires, beaucoup parlent de Markdown, et j’ajoute ma voix. Le texte brut est ce qu’il y a de mieux. Je réfléchis beaucoup à la collecte et à la conservation de mes données, et le texte brut en est le cœur, avec une excellente compatibilité future
Depuis WordPerfect, j’ai tendance à préférer les documents plus déterministes et légers dans leur mise en forme, où l’on peut voir directement les caractères de formatage. Markdown est excellent et, en pratique, assez proche d’un langage spécifique au domaine pour HTML
Le point clé du texte brut, ce sont les outils. Certains outils Markdown sont déjà passés sur HN, mais je ne les ai pas encore vus ici
https://addons.mozilla.org/en-US/firefox/addon/markdown-view... - rend joliment le Markdown dans le navigateur
https://casual-effects.com/markdeep/ - formateur Markdown autonome, riche en fonctionnalités et adapté au web
Utilisé dans ce type de site web local, cela permet de profiter de la simplicité consistant à écrire simplement du Markdown standard
=> https://www.tducret.com/pure-markdown/
Code source : https://github.com/tducret/pure-markdown
J’aimerais que des utilisateurs non techniques puissent aussi s’en servir, mais je n’en suis pas encore là
https://joeldare.com/using-neat-css-on-github-pages
Un bon nombre de personnes arrivent depuis Google/Search en cherchant comment prendre des notes en texte brut, et ce simple billet semble les avoir aidées
Je convertis le contenu en Markdown avec les images associées, puis je l’enregistre dans un Obsidian vault. Je gère moi-même la synchronisation avec Syncthing. Sur ordinateur portable et téléphone, cela devient un aide-mémoire de type zettelkasten assez efficace
J’importe aussi Google/Facebook Takeout, je reformate les résultats, puis j’y stocke et indexe toute la correspondance lisible par un humain. Le texte ne coûte pas cher, donc j’évite la plupart des images. Malgré tout, l’ensemble fait encore moins de 200 Mo, se recherche instantanément avec une bonne UI, et comme c’est un paquet de fichiers Markdown, il se déplace facilement
Personnellement, je m’appuie sur Obsidian d’une manière similaire. Quand il y a quelque chose que je veux conserver, comme une publication FB que je pourrais partager plus tard, je l’enregistre avec le lien d’origine. Les services externes peuvent disparaître à tout moment ; les données locales ont donc deux avantages : nous les possédons et elles sont faciles à rechercher.
J’ai aussi créé un script qui convertit les passages surlignés Kindle en fichiers Markdown. S’il y a des personnes intéressées, je peux le peaufiner un peu et le partager.
Pour le contenu public, l’écosystème des générateurs de sites statiques continue de s’améliorer. J’ai commencé avec Jekyll parce que c’est le choix par défaut de GitHub, je suis passé par Gridsome, puis j’ai fini par me poser sur Nuxt 3 Content, qui me semble aujourd’hui être le meilleur compromis pour moi. Si je commençais maintenant, j’aurais peut-être choisi Astro.
Quoi qu’il en soit, la barrière à l’entrée n’a jamais été aussi basse. On peut héberger gratuitement un site sur GitHub, et si l’on a besoin de styles personnalisés, les modèles d’IA sont d’une aide énorme pour le CSS.
Markdown, c’est un peu le JavaScript de la mise en forme du texte. Il a ses bizarreries, mais au final ça marche bien.
[1] https://github.com/IAmStoxe/obsidian-markdownr
[2] https://addons.mozilla.org/en-US/firefox/addon/markdownload/ - Il existe aussi une extension Chrome.
Je fais quelque chose de similaire depuis 15 ans. Je crée du HTML portable avec images intégrées, des mp3, etc., afin de ne pas avoir besoin de logiciel spécifique pour les consulter. Aujourd’hui, il suffit de les garder dans le cloud ou sur son téléphone, et un navigateur suffit sur n’importe quel appareil et système d’exploitation.
Intégrer des mp3 dans du HTML peut augmenter la taille, mais il suffit d’un navigateur, sans lecteur de musique ni app séparée.
Ces temps-ci, j’essaie de conserver les choses au format MHTML avec le HTML, plutôt que de les intégrer manuellement.
Il suffit de lancer un petit serveur HTTP et de parcourir l’archive.
Pour les images, je fais comme ceci : enregistrer toutes les images dans un dossier → ouvrir un serveur localhost → ouvrir le dossier dans le navigateur → avec JavaScript, convertir les liens en balises dont
src=link→ quand le navigateur a récupéré et affiché toutes les images, faire « Enregistrer sous » pour obtenir une archive MHTML intégrée.On peut aussi créer avec un simple script Bash un HTML contenant des balises img et des liens vers les dossiers, ou fabriquer du MHTML à partir d’un modèle manuel.
Mais autant laisser le navigateur faire le travail difficile, pas besoin de tout faire à la main.
De plus, intégrer directement des images binaires dans du MHTML est bien plus efficace que l’intégration en Base64, et consomme moins de mémoire. Par exemple, pour 15 images, l’encodage binaire MHTML faisait 4 Mo, contre 5 Mo pour l’encodage Base64 MHTML.
Une autre méthode consiste à exécuter
python -m http.serverdans n’importe quel dossier, ou, sous Linux,tree -Hhttp://localhost:8000 avec une profondeur de récursion définie.Ensuite, ouvrez dans le navigateur les liens de dossiers du serveur ou le HTML généré par tree, puis exécutez en ligne de commande
wget -rkpN -e robots=offhttp://localhost:8000 : cela recrée un dossier avec un index.html navigable. Après cela, plus besoin de serveur pour le consulter.C’est le même principe que les exports Google, Twitter ou YouTube.
En réfléchissant dans la même veine, j’ai créé mon propre petit framework : https://www.smallweb.run
La fonctionnalité clé ajoutée par rapport à une configuration maison classique est le mappage des sous-dossiers vers des sous-domaines. Les sites web dynamiques sont aussi possibles, mais ça ne semble pas être ce qui vous intéresse.
Exemple :
~/smallweb/example=> https://example.localhostS’il y a des personnes intéressées, il existe aussi une petite communauté Discord : https://discord.smallweb.run
Personnellement, pour la prise de notes au travail, je préfère VimWiki. Je m’en sers comme endroit où mélanger des idées, de courts documents et des bouts de code trouvés sur le web.
Comme je veux surtout conserver des articles, tutoriels et astuces utiles, j’ai plutôt tendance à archiver des sites web entiers. Pour ça, SingleFile[1] est ce que je préfère.
Avec SingleFile, on peut enregistrer des sites web avec les images intégrées, ajouter des annotations ou découper les pubs gênantes, etc. Il prend aussi en charge les copies de sites sans éléments distrayants. Je recommande vraiment d’y jeter un œil.
[1]https://github.com/gildas-lormeau/SingleFile
Ce genre d’article est toujours intéressant. J’aime l’orientation low-tech et maintenable, mais je n’ai jamais passé de temps significatif à rechercher d’anciens travaux.
Les photos font exception, mais il m’a suffi de faire défiler une timeline personnelle de photos triées par date. Quand j’étais plus jeune, je passais plus de temps sur ce genre de choses, puis j’ai fini par me rendre compte que je ne les consultais en fait jamais.
Je me demande pourquoi les gens reviennent souvent sur des travaux datant de plusieurs années.
Au moins dans mon cas, si je devais modifier un fichier HTML à la main chaque fois que j’ajoute un élément à une collection, je pense que je ne tiendrais jamais sur la durée, même si c’est rapide et simple
Cela me semble être un cas idéal pour utiliser un générateur de site statique DIY très simple. Écrit en Bash ou en Perl, il restera compatible avec l’avenir pour toujours
Utiliser un site web statique de cette manière n’a rien de nouveau. L’inspiration vient de l’export d’un compte Twitter, qui fournit un petit site web consultable en local. J’ai vu plusieurs autres plateformes de réseaux sociaux fournir elles aussi un site web permettant de parcourir les données de façon lisible par un humain
J’ai lu quelque part que les exports Telegram fonctionnent aussi ainsi. Les fichiers d’origine sont plus ou moins organisés en répertoires et restent navigables tels quels, avec en plus un petit site web statique local pour les parcourir plus confortablement
C’est très différent du dernier gros export que j’ai utilisé, Google Takeout. Google Takeout se contente de déverser bêtement des fichiers bruts avec un schéma de nommage dénué de sens pour l’utilisateur, et du XML incompréhensible
Même maintenant, je ne suis pas sûr d’avoir reçu toutes les données demandées avant de les supprimer côté cloud