Reprendre le Web avec un lecteur personnel
(olano.dev)- Après s’être lassé de l’industrie du logiciel et des réseaux sociaux traditionnels, l’auteur a aussi essayé Mastodon, mais ce dont il avait réellement besoin n’était pas une timeline centrée sur les personnes : c’était un lecteur de flux personnel rassemblant les articles du Web et les notifications
- L’objectif n’était pas la liste d’éléments en retard façon boîte de réception d’un lecteur RSS, mais une interface en flux où du contenu intéressant défile à chaque ouverture, comme le fil d’accueil de Twitter ou Mastodon
- Les critères de conception étaient expérience utilisateur > facilité d’exploitation > facilité de développement, avec la priorité donnée à des choix simples à opérer : htmx·hyperscript, une application Web monolithique, SQLite, Python, gevent et l’extension Huey
- À l’usage, des fonctionnalités ont été ajoutées : lire les articles dans l’application, épingler pour lire plus tard, bookmark, tri selon la fréquence de publication des sources, marquage automatique comme « déjà vu » lors du défilement
- Après environ trois mois de travail détendu, feedi a été créé ; utilisé pendant plusieurs mois comme « première page d’Internet », il a permis de retrouver un sentiment de contrôle sur l’information consommée
Retrouver une manière d’utiliser le Web après le burn-out
- Une succession de mauvais projets et une désillusion vis-à-vis de l’industrie du logiciel ont conduit à un burn-out professionnel
- L’auteur a réduit son temps de travail, quitté son emploi, commencé une thérapie et corrigé des habitudes comme l’alimentation, l’exercice et la méditation
- Il s’est tenu à distance de la programmation et des lectures liées au logiciel pendant un moment, et a aussi quitté Twitter, le dernier réseau social qu’il utilisait
- En lisant How to Do Nothing, il a été amené à réexaminer Mastodon comme communauté en ligne alternative
Les limites constatées avec Mastodon
- Mastodon propose un fil chronologique sans intermédiaire algorithmique, ce qui donne l’impression de reprendre le contrôle du flux
- Des personnes ressentant un malaise similaire face à l’industrie du logiciel et au Web revisitaient des éléments de l’ancien Web comme RSS, les BBS, les digital gardens et les webrings, ou imaginaient un Web plus ouvert et indépendant
- L’usage réel recherché relevait davantage du hub d’information que du microblogging
- Suivre des personnes servait à recevoir une notification quand elles publiaient des articles sur leur site Web
- Suivre des bots servait à recevoir du contenu de link aggregators
- Après avoir découvert le concept de social readers de l’IndieWeb, il a conclu que l’outil nécessaire n’était pas Mastodon, mais un lecteur de flux directement ajustable
Objectifs utilisateur d’un lecteur personnel
- Il voulait non pas une liste d’éléments en retard façon boîte de réception d’un lecteur RSS classique, mais un flux de contenus intéressants à chaque ouverture de l’application
- Le flux devait mélanger plusieurs sources
- Articles de blogs, magazines, sites d’actualité et link aggregators
- Notifications de comptes personnels comme Mastodon, Goodreads et GitHub
- Il fallait une personnalisation du parsing pour obtenir une apparence et une expérience cohérentes malgré des formats de données différents selon les sources
- Les fonctions sociales d’un lecteur IndieWeb complet n’étaient pas dans le périmètre
- Ouvrir un autre onglet pour laisser un commentaire n’était pas un problème
- Il était acceptable que le contenu soit dispersé sur des sites tiers
- L’objectif à court terme était de vérifier rapidement si cet outil pouvait devenir la principale, voire l’unique, source d’information Web ; sinon, le projet devait être abandonné immédiatement
Principes de développement et périmètre
- Le principe de développement était
user > ops > dev- Dans la priorisation et les compromis de conception, la facilité d’exploitation passait avant la facilité de développement
- Au-dessus encore venait l’expérience utilisateur
- Comme il s’agissait d’une application personnelle, « l’utilisateur d’abord » signifiait satisfaire d’abord ses propres besoins en l’utilisant soi-même au quotidien (dogfooding)
- Plutôt que d’imaginer un utilisateur idéal, il jugeait probablement plus utile de créer un outil ergonomiquement adapté à lui-même
- Ce projet ne devait pas être un projet d’apprentissage ni un projet de portfolio
- Le but n’était pas la productivité, mais de renouer avec le plaisir du développement logiciel
- Ce plaisir devait venir non pas du fait de « construire quelque chose », mais d’« utiliser quelque chose que l’on a construit soi-même »
- En supposant un utilisateur cible unique, plusieurs décisions pouvaient être repoussées
- L’authentification utilisateur, inutile dans l’immédiat, a été remise à plus tard
- Des fonctions très spécifiques comme l’envoi vers Kindle pouvaient être traitées dès le début
- Des connaissances en programmation pouvaient être présupposées, par exemple pour personnaliser les parsers de flux ou se connecter à Mastodon
Choix d’interface utilisateur et d’architecture
- Pour être accessible non seulement depuis un ordinateur portable mais aussi depuis un téléphone, il fallait une application Web
- C’était un moyen rentable de prendre en charge deux appareils avec une seule interface
- Il était possible d’utiliser HTML et CSS, déjà familiers
- Stocker l’état côté serveur résolvait la synchronisation entre appareils
- L’interface Web devait être assez dynamique, mais il ne voulait ni application front-end séparée ni apprentissage d’un nouveau framework
- Suivant les conseils autour de la boring tech et de la radical simplicity, il a cherché une bibliothèque de rendu côté serveur et a utilisé htmx avec hyperscript
- Pour faciliter l’exploitation, le déploiement et la configuration locale devaient être simples, sans présupposer une infrastructure comme Docker ou Nix
- Le lecteur IndieWeb formel décrit par Aaron Parecki se divise en plusieurs composants par protocole, comme Micropub, Microsub et Webmentions, mais pour un usage personnel cela compliquait surtout le développement et l’exploitation sans grand bénéfice
- Le choix s’est donc porté sur une application Web monolithique, avec SQLite comme base de données afin de réduire le nombre de composants à installer et configurer
Langage et tâches en arrière-plan
- Go semblait bien adapté au projet : simple, généraliste, doté d’un ramasse-miettes, suffisamment rapide, avec un bon modèle de concurrence et des binaires faciles à déployer
- Mais l’auteur n’avait jamais écrit une seule ligne de Go et ne voulait pas transformer le projet en projet d’apprentissage
- Il a choisi Python, le langage déjà familier avec lequel il pouvait prototyper le plus vite
- Python gardait des inconvénients liés aux environnements et dépendances, en particulier les dépendances envers les bibliothèques de l’OS hôte
- Pour le polling périodique des flux, il ne voulait pas multiplier les composants séparés ; après recherche, il a utilisé gevent et l’extension mini-huey de Huey pour exécuter des tâches en arrière-plan dans le processus de l’application
- En contrepartie, Python disposait de bonnes bibliothèques pour HTTP, le parsing de flux et le scraping
Pourquoi repousser les tests
- Au départ, il a choisi de ne pas écrire de tests
- Comme il prévoyait d’expérimenter en ajoutant, supprimant et réorganisant des fonctionnalités, le coût de maintenance des tests unitaires lui semblait supérieur à leur valeur
- Il pouvait accepter de petits bugs de logique et, l’application étant utilisée directement tous les jours, il s’attendait à ce que les bugs importants apparaissent avec le temps
- Pour inspirer confiance, il estimait que les tests d’intégration avaient davantage de valeur, mais beaucoup de bugs du projet venaient des intégrations avec des sources externes et de l’interface utilisateur
- Les tests d’intégration auraient pu détecter certains bugs et régressions plus tôt, mais il a jugé que cela ne valait pas le coût initial
Comment l’usage réel a guidé les fonctionnalités
- L’usage quotidien en tant qu’utilisateur final a déterminé les idées, les expérimentations et les priorités
- Après avoir essayé plusieurs mises en page et fonctionnalités d’interface, un schéma d’usage s’est installé
- Ouvrir l’application
- Faire défiler le flux principal
- Épingler les éléments à lire plus tard
- Ouvrir les éléments à lire maintenant
- Bookmarker les éléments à consulter plus tard
- Il voulait pouvoir lire les articles sans quitter l’application, notamment pour éviter les paywalls et les fenêtres de consentement
- Il a essayé plusieurs bibliothèques Python d’extraction de contenu HTML, mais aucune ne fonctionnait aussi bien que readability, utilisé par Firefox
- Comme readability est un package JavaScript, il a fallu ajouter Node.js comme dépendance optionnelle
Tri du flux et traitement « déjà vu »
- Même une fois les fonctionnalités de base en place, le simple tri par date de publication rendait difficile la découverte de contenus intéressants
- Les rares articles de blog se retrouvaient noyés derrière les toots Mastodon
- Les longs articles de magazine étaient enterrés sous les articles d’actualité quotidiens
- Comme toutes les sources suivies étaient jugées intéressantes, l’hypothèse était de vouloir voir en priorité le contenu des sources publiant peu fréquemment
- Si une newsletter mensuelle était sortie dans les derniers jours, elle devait apparaître au-dessus du microblogging ou de l’actualité quotidienne
- Les sources ont été classées en « frequency buckets », et le flux trié pour afficher d’abord les buckets les moins fréquents
- Pour éviter que les contenus rares restent en permanence en haut à chaque ouverture de l’application, une fonction marque automatiquement les éléments comme « already seen » lors du défilement
- Cette approche permet de voir constamment de nouveaux contenus sans rater les mises à jour rares
Du local au VPS
- Au début, l’auteur lançait l’application dans un onglet de terminal sur son ordinateur portable, en développant et en l’utilisant en parallèle
- Quand le contenu affiché dans le flux a commencé à lui plaire, il l’a installée sur un serveur Raspberry Pi du réseau local afin de la rendre accessible en permanence
- L’usage continu sur Raspberry Pi l’a conduit à améliorer le rendu mobile pour l’accès depuis le téléphone
- Lorsqu’il a commencé à regretter l’application en déplacement, il l’a déployée sur un VPS
- Le déploiement sur VPS l’a amené à ajouter l’authentification et le support multi-utilisateur, jusque-là repoussés, et à donner à quelques amis un accès de bêta-test
- La configuration du VPS a été l’occasion d’acheter un domaine et de créer ce site Web, un pas de plus vers les idéaux IndieWeb qui l’avaient inspiré au départ
Le résultat : feedi
- Après environ trois mois de travail détendu, il a créé le lecteur de flux personnel feedi
- feedi est moins un produit fini qu’un outil à la manière d’une configuration Emacs : toujours à moitié cassé, mais dont on prend l’habitude
- D’un point de vue productivité, il est difficile à justifier, mais il procure de la satisfaction parce qu’il a été façonné selon ses propres conditions
- Pendant plusieurs mois, feedi a servi de « front page of the internet »
- Avec un lecteur personnel, l’auteur a repris le contrôle des informations qu’il consomme, cherché plus activement des blogs et magazines intéressants, et s’est davantage exposé à la découverte et à la surprise
1 commentaires
Avis sur Hacker News
J’ai pris pas mal de plaisir à configurer urlwatch(https://urlwatch.readthedocs.io/en/latest/). Surtout quand on dépasse le boilerplate Puppeteer et qu’on peut scraper des sites JavaScript avec une instance de Chrome : on a l’impression de reprendre le contrôle, de faire en sorte que le Web vienne à soi plutôt que d’aller le chercher
Il y a une vraie force à pouvoir surveiller des sites sans effort et les parcourir le matin. On peut suivre les offres d’emploi d’une entreprise qu’on aime, les recrutements/clôtures de son entreprise actuelle, les produits dont on attend une promo, un réassort ou du reconditionné, les statistiques des eaux usées liées au Covid, les annonces d’appartements, les releases GitHub qui nous intéressent, et même les changements de conditions d’utilisation de sites importants
Personnellement, j’auto-héberge aussi un lecteur RSS et un bot Telegram, et je crée souvent de petits sites HTTP expérimentaux, donc j’utilise un Droplet DigitalOcean à 5 $, mais comme il n’est pas nécessaire que ça tourne tous les jours à la même heure, ça peut aussi se faire depuis un ordinateur portable
Comme c’est pour un usage personnel, je ne reçois que des résumés de mises à jour Twitter sur les sujets qui m’intéressent, tout en évitant le site lui-même, les polémiques toxiques et les publicités agaçantes
L’état actuel de l’IT me met tellement en colère que j’ai du mal à le formuler correctement, mais j’imagine parfois le concept de « mon responsable IT ». Quelqu’un qui prendrait en charge une partie de ma vie numérique, comme le coiffeur du quartier, le médecin traitant, le tailleur ou le boulanger
Il disposerait d’une petite infrastructure locale, créerait des flux personnalisés, s’occuperait de la confidentialité et de l’hygiène numérique, et se connecterait au lecteur de flux via des interfaces simples ou des protocoles ouverts. Il couvrirait aussi les films, les textes, les mèmes, les vidéos amusantes, mais l’essentiel serait qu’il y ait un humain avec qui discuter, et non un algorithme d’optimisation des revenus
J’imagine aussi des datacenters gérés par des communautés locales, comme des bibliothèques, ou des services de contenu simples fournis via l’accès Internet domestique. C’est pour ça que j’ai aimé des idées comme Veilid(https://gitlab.com/veilid/veilid)
Ce n’est pas la première fois que j’entends dire que des gens se portent mieux après être passés au Fediverse. De mon côté, j’empile des scripts et de mini-apps au-dessus de Puppeteer, avec des résumés et recommandations via llamacpp en local, et j’aimerais affiner tout ça pour le recommander à mes amis et à ma famille
J’ai appelé ces scripts « not a browser ». Je veux un Web qui ne serve pas HTML/CSS/JS avec les données, mais seulement les données, en laissant l’utilisateur décider de la manière de les afficher
Pas d’algorithmes hostiles à l’utilisateur, pas de systèmes financés par la publicité ; ce sont pour l’essentiel des logiciels qui placent l’utilisateur d’abord et parlent de protocoles ouverts. C’est possible quand on travaille dans l’IT et qu’on sait exploiter soi-même un serveur, mais la question est : que font les autres ?
L’idée d’un « responsable IT » personnel est intéressante. Je me demande s’il serait possible de proposer ce genre de service aux personnes qui veulent s’éloigner des géants de la tech et des algorithmes pour utiliser quelque chose de plus personnel, mais qui n’ont pas les moyens techniques de le faire
Les données de santé posent un problème similaire. Je n’aime pas que mon dossier médical soit stocké dans MyChart et divers systèmes propriétaires, sans que j’en aie le contrôle. J’ai un superordinateur dans la poche ; pourquoi ne puis-je pas conserver moi-même une copie de mes dossiers et les partager sélectivement avec le médecin lors d’une consultation ?
Le fait que les hôpitaux doivent encore s’échanger des fax est aussi aberrant. Je devrais pouvoir partager mes données en appuyant sur un bouton. Apple Health est ce qui s’en rapproche le plus pour certaines fonctionnalités, mais son adoption aux États-Unis semble quasi inexistante, et même là, cela favorise seulement les utilisateurs Apple. Les données de santé ne devraient pas être enfermées dans des systèmes propriétaires, même sous une forme à la Apple Health qui tourne en local ; il faut des protocoles ouverts et un écosystème d’implémentations
Il y a eu une brève période correcte avant que le marketing et la cupidité ne prennent le contrôle d’Internet. Un produit comme un NAS Synology, avec des apps utiles à l’utilisateur final, accompagné de « mon responsable IT » pour aider, pourrait bien fonctionner
Pour l’utilisateur, ce serait presque une utopie si la structure ne cherchait pas à extraire ses données personnelles et son argent, mais l’économie du modèle ressemblerait probablement à une activité à faibles marges et à gros risques. Par exemple, la responsabilité en cas de perte de fichiers serait un problème majeur
On écrit du code une fois et on l’exécute un million de fois à un coût supplémentaire quasi nul. Toutes les forces structurelles semblent pousser dans l’autre sens. Peut-être que cela deviendra plus possible quand l’IA aura remplacé tous nos emplois
How to Do Nothing de Jenny Odell est vraiment un excellent livre. Il ne correspond peut-être pas tout à fait au lectorat habituel de Hacker News, mais je le recommande vivement à toute personne qui commence à ressentir la pression de la fausse « productivité » imposée par l’économie de l’attention
Les autres projets de Jenny Odell valent aussi le détour. Par exemple The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html)
Dans le même esprit, je recommande aussi Saving Time de Jenny Odell. C’est un livre discret mais très radical, et personnellement je l’ai préféré aux deux. Le récit y était plus resserré
Au-delà d’un simple fil personnel, je voudrais un fil limité dans le temps et sans distractions
J’aimerais qu’il rassemble tous les contenus écrits des personnes que je suis, puis choisisse une combinaison d’éléments correspondant à environ 30 minutes de lecture par jour. Il faudrait tout inclure : billets de blog, articles, tweets, etc.
En utilisant ChatGPT ou un autre outil, il faudrait filtrer les contenus les plus « nourrissants » et donner la priorité à ceux qui ont de la valeur plutôt qu’aux disputes. Ensuite, j’aimerais les envoyer vers un Kindle ou une tablette reMarkable pour lire à l’écart des couleurs, des clignotements et de l’Internet rapide.
L’étape suivante serait de m’abonner au fil d’un ami pour recevoir de temps en temps aussi du contenu « invité » provenant de ce fil.
L’idée d’ajouter des résumés GPT me plaît, et si d’autres personnes sont intéressées, je pourrais le mettre au propre et le partager. Pour l’instant, c’est une simple application JavaScript que j’utilise en local, mais cette idée me semble désormais plus prometteuse que je ne l’imaginais au départ.
Je crois que c’était Douglas Engelbart, mais je n’arrive pas à retrouver de documents sur les agents. C’était peut-être un autre spécialiste de la technologie.
J’ai remarqué, et cela m’a parlé, la décision consciente de ne pas forcément faire de tests automatisés au début. Il m’a fallu pas mal de temps pour dépasser le malaise de ne pas écrire de tests, mais pour mes petits projets personnels, j’adopte désormais une approche similaire.
Trop de projets sont morts dès le premier jour, à peu près. C’était justement le moment où ils auraient dû prendre de l’élan, mais je perdais la motivation en construisant l’infrastructure de test et le pipeline CI.
Maintenant, je pars du principe que j’ajouterai des tests quand leur absence deviendra un vrai problème.
Ce qui est indispensable dans un projet mature avec beaucoup de développeurs et une grosse base de code peut être encombrant dans un petit projet solo.
Ensuite, chaque fois qu’un problème survient, je me concentre sur l’ajout ponctuel d’un test.
Il y a quelques années, j’ai construit comme projet personnel un analyseur de gaz respiratoires, ainsi qu’un logiciel qui s’y connectait en Bluetooth pour afficher les données en temps réel. Les tests unitaires ont été très utiles pour les fonctions qui devaient effectuer correctement des calculs scientifiques, mais avec le recul, tester le reste de l’interface a été presque une perte de temps.
Une fois que j’ai eu la certitude que les fonctions ne changeraient plus, j’ai supprimé tous les tests. Quand on développe seul, les tests manuels peuvent suffire.
J’ai créé un nouveau compte anonyme pour parler franchement de l’avenir
Cet article m’a surpris, parce qu’il semblait avoir été écrit par mon moi futur. J’avais tellement de points communs avec l’auteur que c’en était difficile à croire.
J’avais pris conscience de mon burnout et je prévoyais de quitter mon travail au début de l’année prochaine. C’est aussi pour cela que j’ai créé ce compte anonyme. Je pense que beaucoup de gens ressentent probablement quelque chose de similaire.
Ce qui est encore plus surprenant, c’est que ce que l’auteur a fait ressemble presque exactement à ce que je rêvais de faire pendant ma pause. Je réfléchissais à la manière de participer à l’open web/IndieWeb, et je prévoyais de créer une application pour expérimenter dans ce domaine.
Même les questions techniques se ressemblent : comment éviter que les publications rares soient noyées dans le flot, quels langages et technologies utiliser. J’ai environ dix ans de retard en développement web, mais j’envisageais aussi de construire quelque chose avec les technologies web modernes.
D’un côté, je suis heureux parce que mes pensées et émotions récentes me semblent validées. J’ai l’impression d’être sur la bonne voie. De l’autre, je suis contrarié que l’auteur l’ait fait avant moi, et il me reste aussi un peu de jalousie.
À l’époque, je voulais mon propre lecteur RSS. Je n’aimais pas les lecteurs existants, et je voulais un lecteur qui ne ressemble pas à une boîte de réception, mais à un blog ordinaire, avec un design que je pouvais contrôler comme je le voulais. J’ai donc créé un parseur de flux RSS et je l’ai conçu pour qu’il ressemble à mon blog habituel.
Ensuite, je l’ai modifié pour récupérer l’article complet quand le flux RSS ne contenait qu’un résumé. Je ne voulais pas cliquer hors du lecteur pour lire l’article complet ; je voulais que tout soit dans le lecteur de flux. Une fois que j’ai eu un scraper de page de base, je l’ai aussi utilisé sur des sites sans RSS, ce qui m’a été particulièrement utile quand les réseaux sociaux sont devenus populaires.
Je pouvais voir dans mon fil uniquement le contenu que je voulais, sans avoir à aller sur les vrais sites sociaux. Comme c’est un truc vieux de 20 ans, il repose sur de vieilles technologies comme PHP et XSLT, et c’est toujours le cas.
Quoi qu’il en soit, je recommande vivement de le construire soi-même. C’est un projet amusant. Il est vieux, rugueux, et le scraping n’est pas parfait, donc le contenu que je veux n’apparaît pas toujours, mais c’est le mien, et j’aime ce lecteur que j’utilise tous les jours depuis 20 ans.
Il n’y a aucune raison qu’une tentative similaire n’ait pas d’effet. Ce n’était pas non plus la première personne à implémenter un lecteur personnel.
Ce qui est amusant, c’est qu’en reparcourant l’article IndieWeb que j’avais lié, j’ai eu l’impression d’en répéter presque mot pour mot les idées. Un conseil du genre : « n’essaie pas de créer un logiciel pour tout le monde, crée-le pour toi-même ».
Si l’on essaie d’en faire un outil généraliste et facile à utiliser pour les autres, on risque de faire des compromis qui nuisent à sa propre utilisabilité, ou de concevoir pour des utilisateurs imaginaires qui n’existent même pas. L’idée est de le construire égoïstement afin qu’il soit plus utile pour soi.
C’était vraiment rafraîchissant. Au cours de l’année écoulée, j’ai suivi un parcours de burnout/récupération très similaire, et créer des logiciels personnels utiles m’a permis de reprendre plaisir au travail.
Un autre grand avantage est de pouvoir essayer librement les technologies « non orthodoxes » qu’on veut. Créer un exécutable PHP moderne en binaire unique, utiliser SQLite en production, déployer sans Docker : ce genre de choses m’apporte du plaisir.
Ce travail a aussi eu des retombées sur mon emploi principal. Il m’arrive souvent de découvrir de nouvelles techniques et optimisations dans mes dépôts personnels, puis de les importer dans mon travail.
Je trouve intéressant que les techniciens bricolent souvent des choses à côté, puis ramènent ce qu’ils ont appris sous une forme utile, et parfois précieuse, dans leur métier. Pourtant, les employeurs dévalorisent parfois ces efforts ou freinent cet enthousiasme.
J’ai peut-être travaillé dans le mauvais type d’organisation. Cela dit, je suis content que tu aies pu bénéficier de ces retombées.
Je préfère la logique de flux à une checklist de choses à lire/consommer. J’ai essayé quelques lecteurs RSS au fil des ans, mais je ne m’y suis jamais vraiment tenu durablement
Je me demandais si j’avais vraiment besoin de gérer encore une boîte de réception. Je compte quand même jeter un œil à feedi (https://github.com/facundoolano/feedi)
Avant de le configurer, je cliquais un peu au hasard ici et là en me demandant s’il y avait un nouveau post sur HN, ou chez Reuters. Mon expérience correspond à https://news.ycombinator.com/item?id=38642092
Mes mails personnels, listes de diffusion et flux RSS se retrouvent tous au même endroit. Avec un filtrage vers des spools séparés et un client mail puissant comme mutt, cela donne une expérience unifiée plutôt agréable
L’auteur semble avoir ajouté de l’authentification pour accéder à l’app depuis n’importe où
Je me demande s’il serait possible, ou plus simple, de la placer derrière un VPN, puis de rendre ce VPN accessible de partout
J’aimerais accéder à mes webapps personnelles de façon sûre, mais je cherche l’approche la plus simple. Chaque fois que je regarde l’authentification, j’ai l’impression d’entrer dans un labyrinthe de concepts, de protocoles et de bibliothèques, et je n’ai pas envie de maintenir tout ça
J’héberge quelques apps comme Home Assistant sur un Raspberry Pi à la maison, et j’ai installé Tailscale sur ce Pi et sur mon téléphone : ça fonctionne très bien. La seule authentification à faire, c’est « se connecter à Tailscale sur chaque appareil »
Pour constituer facilement un réseau sécurisé entre ses propres appareils, je recommande vraiment très fortement Tailscale
C’est suffisant pour « protéger » mon application qui ne fait qu’héberger des bouts de texte découpés sur d’autres sites web
Il y a plusieurs façons de faire, mais l’idée est de placer le point de terminaison VPN et la webapp au même endroit, par exemple sur la même machine ou le même réseau, puis de restreindre l’accès à la webapp depuis les autres emplacements
Caddy est configuré pour ne faire du reverse proxy que pour les requêtes venant du réseau interne ou du VPN, et pour renvoyer un 404 sinon. Ainsi, si l’on n’est pas sur le VPN ou sur le réseau domestique, on ne voit rien
Selon que vous ouvrez ou non le réseau à des invités, et selon les services que vous faites tourner, vous pouvez avoir besoin de VLAN ou d’un réseau invité séparé. Beaucoup de services que j’exécute à la maison ont aussi leur propre authentification par mot de passe, que j’utilise en plus de la restriction par VPN
Cette configuration est simplement la première qui m’est venue à l’esprit ; elle pourrait donc être peu sûre pour des raisons qui dépassent mon domaine de compétence. L’avantage, c’est que je fais aussi tourner Pi-hole dans le même fichier compose, ce qui fait que lorsque mon téléphone se connecte au VPN, j’obtiens aussi le blocage de pubs à distance « gratuitement »
Tailscale est plus simple à configurer et son interface est meilleure, mais j’ai arrêté parce qu’il consommait beaucoup de batterie sur iOS. Le fait de devoir « faire confiance au serveur de quelqu’un d’autre » est aussi un problème, mais sans le souci de batterie, j’aurais probablement accepté le risque supplémentaire pour le confort
L’app WireGuard a aussi une fonctionnalité pratique : on peut lui indiquer de ne pas se lancer sur certains réseaux, comme quand on est à la maison, de sorte qu’elle s’active automatiquement quand on sort et se désactive quand on rentre
C’est étonnamment proche de ce dont je pensais avoir besoin sur un voilier de croisière. En particulier au large, où la connexion est intermittente ; avec deux choses en plus, ce serait exactement adapté
Il faudrait pouvoir appuyer sur synchroniser maintenant lors de courts moments de connexion, par exemple quand on passe près d’une île où la LTE passe. Et, par défaut, il faudrait traiter le contenu avec Readability et le mettre en cache localement, afin de pouvoir tout lire hors ligne, images comprises