Pourquoi faire du self-hosting ?

 (romanzipp.com)
17 points par GN⁺ 2025-10-11 | 1 commentaires | Partager sur WhatsApp
  • Le self-hosting de services personnels permet d’échapper à la surveillance des géants de la tech et des gouvernements, afin de garantir la confidentialité et la souveraineté des données
  • Des données personnelles sensibles comme le calendrier, les contacts ou la localisation révèlent bien plus d’informations qu’on ne le pense, et doivent être gérées directement sans dépendre d’entreprises comme Google ou Apple
  • Dans un contexte où des entreprises technologiques bloquent des comptes sans raison ou imposent des API propriétaires au lieu de protocoles standards, exploiter son propre serveur fondé sur des standards garantit la souveraineté numérique
  • Présentation de services de self-hosting concrets et d’options logicielles précises : serveurs CalDAV/CardDAV, serveurs mail, Home Assistant, lecteur RSS, traceur de localisation, etc.
  • Malgré la complexité de la configuration initiale, il est important, sur le long terme, d’assurer le contrôle de ses données et la stabilité des services pour protéger la vie privée et gagner en autonomie technique

Pourquoi choisir le self-hosting

  • En partageant récemment mon environnement Homelab avec un collègue, on m’a demandé : « Pourquoi installer soi-même des serveurs, configurer des conteneurs et dépenser autant d’argent en matériel pour gérer tout cela ? »
  • Cette question a été l’occasion d’expliquer concrètement les principales motivations du self-hosting et les types de services que l’on peut réellement auto-héberger

Confidentialité

  • La confidentialité n’est pas un droit accordé automatiquement, c’est un droit qu’il faut défendre
  • Les géants de la tech et certains gouvernements (par ex. le chat control de l’UE) continuent de chercher à scruter l’ensemble de la vie privée
  • Héberger soi-même ses services permet de réduire ou d’éliminer le risque de surveillance, mais cela exige des connaissances techniques
  • En fournissant des services à sa famille ou à ses proches, on peut aussi les aider à gagner en indépendance vis-à-vis de leurs données

  • Calendrier & contacts

    • Le calendrier révèle beaucoup plus d’informations qu’on ne l’imagine
      • Au-delà de l’identité : rencontres régulières, famille, collègues, réunions professionnelles confidentielles
      • Informations de santé via les rendez-vous médicaux, habitudes de sommeil et d’exercice
      • Informations financières comme les obligations légales, les échéances de prêt ou les abonnements
      • Convictions politiques à travers la participation à des manifestations
      • Possibilité d’identifier les moments où l’on est joignable pour faciliter une usurpation d’identité
    • Les données de contacts sont tout aussi sensibles
      • Le graphe social et les métadonnées (historique de recherche, date de création) permettent de déduire des informations personnelles
      • Exemple : si des contacts d’un même sexe avec seulement un prénom se multiplient soudainement, on peut supposer une vie amoureuse active ; la création du contact d’un thérapeute peut indiquer une consultation en psychiatrie
    • La plupart des gens ne savent pas où sont stockées les données de leur graphe social, alors qu’en pratique elles sont traitées par Google, Apple, Samsung, etc.
    • Même l’Advanced Data Protection d’Apple ne chiffre pas de bout en bout le calendrier et les contacts

  • Localisation

    • Il y a plusieurs années, en utilisant Android et Google Maps, j’ai découvert dans mon compte Google des années d’historique de localisation détaillé
      • Une fonctionnalité que je n’avais jamais activée moi-même enregistrait automatiquement tous mes déplacements et lieux visités avec géocodage
    • C’était une expérience à la fois fascinante et inquiétante, qui m’a donné envie de contrôler directement ces données et de faire en sorte que moi seul puisse y accéder

  • Le reste

    • Énumérer toutes les façons dont les données sont suivies, et pourquoi il faut en prendre conscience, dépasse le cadre de cet article
    • L’objectif est plutôt de donner l’envie de commencer un nouveau parcours

Souveraineté

  • La souveraineté numérique consiste à contrôler ses données, choisir ce qu’on en fait et décider avec qui on les partage

  • Le problème du verrouillage de compte

    • Les cas d’entreprises technologiques qui bloquent des comptes sans raison évidente continuent d’être signalés, et cela m’est déjà arrivé personnellement avec Google
    • Je ne veux pas dépendre de la bonne volonté des géants de la tech, impossibles à joindre ou qui vous laissent aux prises avec un chatbot IA
    • Je me demande pourquoi les autorités de régulation n’exigent pas des entreprises tech qu’elles offrent un moyen de contacter un vrai humain

  • Protocoles et standards

    • Je préfère les protocoles et formats de fichiers standards
      • Utiliser SMTP et IMAP plutôt que l’API de « Gmail » (certes anciens, mais encore ce qu’on a de mieux aujourd’hui ; la nouvelle initiative JMAP est la bienvenue)
    • Des acteurs comme Microsoft forcent l’usage de logiciels Office 365 intégrés à AI Copilot et ont récemment désactivé l’accès SMTP pour les comptes Office 365

Que self-héberger ?

  • Matériel

    • Je travaille chez enum.co, dans un environnement où la souveraineté numérique compte beaucoup
    • J’exploite un cluster Kubernetes haute disponibilité composé de 3 mini-serveurs (mis en place avec l’aide de mon manager)

  • Calendrier & contacts

    • Comme il s’agit de données sensibles, j’héberge mon propre serveur CalDAV/CardDAV
    • Options de serveur :
      • Radicale : basé sur Python, interface web basique, mono-utilisateur uniquement, incompatible avec les appareils Apple
      • ⭐ Baïkal recommandé : basé sur PHP, développement actif, interface web avancée, multi-utilisateur
      • DAViCal : basé sur PHP, non testé
      • Xandikos : basé sur Python, sans authentification intégrée, sans interface web
      • Nextcloud : basé sur PHP, correct si on l’utilise déjà, mais trop lourd
    • Être attentif à ses données de calendrier et de contacts implique aussi d’examiner quelles applications ont des droits d’accès

  • Mail

    • Le serveur mail auto-hébergé a longtemps été considéré comme tabou, mais en réalité ce n’est pas si difficile
    • Des solutions récentes comme Stalwart ou Mailcow rendent l’hébergement de boîtes mail personnelles plus simple (pas pour le mail marketing)
    • Héberger cela chez soi n’est pas recommandé (IP fixe nécessaire, accès depuis l’ensemble d’Internet obligatoire)
    • Étapes de configuration :
      • Choisir un hébergeur fiable
      • Obtenir une adresse IP propre (en vérifiant les listes noires mail, puis recommencer si besoin)
      • Configurer le serveur puis vérifier la réception et le bon fonctionnement de tous les protocoles
      • Valider avec l’outil de test en ligne internet.nl
      • Envoyer des mails vers des adresses Google, Microsoft et Yahoo pour vérifier s’ils finissent en spam
      • Vérifier et revérifier DNS, DMARC, SPF, TLS, etc.
    • Un article de blog plus détaillé est prévu à l’avenir

  • Maison intelligente

    • J’ai commencé à héberger une instance Home Assistant il y a des années ; à l’époque Apple HomeKit me suffisait, mais j’ai commencé par curiosité
    • Depuis, de nombreuses entreprises de la smart home ont fait faillite, fermé leurs services cloud, augmenté leurs prix ou transformé des offres gratuites en offres payantes
    • Il y a quelques semaines, en apprenant que Philips Hue obligeait les utilisateurs à créer un compte, Home Assistant a montré tout son intérêt
      • Il faut un compte pour profiter de toutes les fonctions de lampes déjà payées
      • J’ai toujours mis en place des règles de pare-feu pour bloquer le trafic réseau externe des appareils de maison intelligente
      • Il semble qu’on ne puisse pas non plus utiliser sur le réseau local les fonctions réservées à l’application Philips Hue (comme l’animation d’imitation de bougie)
      • J’espère qu’un plugin communautaire existe pour émuler cette fonction
    • Je ne créerai jamais de compte en ligne pour un appareil utilisé uniquement en local
    • En ce moment, je suis obsédé par le suivi de la consommation d’énergie et je prévois de développer un dispositif Raspberry Pi + caméra pour suivre la consommation de gaz via vision par ordinateur du compteur

  • Agrégateur RSS

    • Je suis abonné à de nombreux sites d’actualité et blogs via RSS, et RSS est déjà en soi décentralisé et souverain
    • Héberger soi-même un agrégateur RSS est donc optionnel, et plutôt une étape finale
    • J’utilise NetNewsWire sur iPhone et Mac
      • C’est le meilleur lecteur RSS, open source, soutenu par des gens formidables
      • Il offre une intégration native avec FreshRSS
    • FreshRSS fournit davantage de fonctionnalités comme le filtrage en tant qu’agrégateur de flux
      • Il permet aussi de s’abonner à des sources qui ne proposent pas de flux RSS nativement

  • Traceur de localisation

    • J’ai déployé une instance dawarich (« j’y étais » en allemand)
      • C’est un serveur qui collecte et affiche des données de géolocalisation
      • On peut choisir parmi plusieurs applications mobiles capables d’envoyer sa position actuelle au serveur
    • Applications disponibles :
      • Application officielle dawarich : affiche en permanence l’icône de navigation dans l’encoche iOS
      • Overland : consomme beaucoup de batterie
      • ⭐ Owntracks : fonctionne le mieux sur iOS, mais les réglages de l’application sont très déroutants
      • PhoneTrack

Idées & perspectives

  • J’ai récemment restructuré mon homelab pour passer d’un gros serveur unique à un cluster Kubernetes à 3 nœuds
    • Cela offre beaucoup plus de flexibilité sur les types d’applications que je peux héberger
  • Liste d’apps et d’outils que j’aimerais explorer :
    • EteSync : CalDAV & CardDAV chiffrés de bout en bout
    • AnyType : héberger sa propre instance de serveur AnyType
    • Immich ou ente : quitter les photos iCloud pour du self-hosting
    • Passbolt : gestionnaire de mots de passe (je n’aime pas Bitwarden)
    • BirdNET : surveillance extérieure des espèces d’oiseaux par microphone
    • penpot : similaire à Figma, mais gratuit & open source
    • Habitica : gestionnaire d’habitudes
    • vert : convertisseur de fichiers
    • InvoiceShelf : gestionnaire de factures
  • selfh.st est une excellente ressource pour trouver des applications auto-hébergeables

À lire aussi

1 commentaires

 
GN⁺ 2025-10-11
Avis Hacker News

  • Je veux dire qu’au-delà du simple fait d’auto-héberger des services personnels, les petites entreprises de logiciel ou de SaaS devraient elles aussi envisager une approche d’hébergement plus directe
    Les fournisseurs cloud affirment qu’ils sont indispensables à cause de la complexité et de l’échelle, mais en réalité, la plupart des projets logiciels ou des activités n’en ont pas autant besoin
    Par exemple, il n’est pas nécessaire de dépendre de Vercel ou Netlify pour déployer NextJS : il suffit de lancer Nginx ou Caddy (mon préféré) sur un VPS avec Ubuntu
    Pour plus de 90 % des projets, un hébergement en direct avec la méthode suivante est largement suffisant

    • un VPS bien sécurisé avec les contrôles de sécurité essentiels appliqués (désactivation du login root, authentification par clé SSH, etc.)

    • configuration d’un reverse proxy comme Caddy/Nginx pour servir des fichiers statiques ou un site web ; sauf si vous faites des millions de requêtes par jour, un CDN n’est même pas nécessaire

    • exécuter le backend/l’API avec Supervisor ou systemd

    • le même reverse proxy peut aussi relayer vers le backend et d’autres services

    • faire tourner soi-même une base de données mysql/postgres et appliquer les réglages de sécurité

    • des scripts de sauvegarde / cron suffisent pour tout sauvegarder, à condition de tester régulièrement

    • pour se protéger du DOS/DDOS, on peut ajouter une couche Cloudflare
      Au final, l’architecture devient Cloudflare/DNS → Reverse Proxy (Caddy/Nginx) → application
      Pour le déploiement, un simple git pull suffit dans la plupart des cas, avec éventuellement une phase de build supplémentaire si besoin
      Docker et les conteneurs ne sont pas non plus indispensables ; pour des projets de petite à moyenne taille, on peut très bien s’en passer
      Cela peut sembler difficile, mais en pratique ce n’est pas aussi compliqué qu’on l’imagine ; la plupart des projets n’ont pas besoin d’une architecture web à très grande échelle

    • Ce qui m’inquiète le plus, ce sont les risques de sécurité liés à la gestion de tout l’OS (noyau et espace utilisateur compris)
      Je me demande toujours si le firewall est correctement configuré, si les derniers CVE sont traités rapidement, etc.
      C’est pourquoi j’ai plutôt tendance à considérer comme plus fiable une approche du type : workflow GitHub Actions → build d’image de conteneur puis push vers un registre privé → déploiement de cette image sur le service via une configuration k8s
      C’est aussi simple que de déployer directement sur une VM, et ainsi je n’ai à me soucier que de mon application et de ses interfaces

    • Si j’ai créé canine.sh, c’est précisément parce que je voulais transformer toute la procédure mentionnée ci-dessus en un déploiement en un clic
      Quand j’ai cofondé un petit SaaS il y a quelques années, notre facture cloud dépassait les 500 000 dollars par an
      En production, on a vite compris que sentry était indispensable ; au lieu de fouiller les logs serveur un par un, on utilisait Sentry cloud pour environ 40 dollars par mois
      Il nous fallait aussi datadog pour la supervision des données, soit 300 dollars par mois
      Pour les dashboards de présentation client, des outils BI comme Looker/Tableau/Omni coûtaient 20 000 dollars par an
      L’entrepôt de données et la réplication revenaient à 150 000 dollars par an
      Les coûts de ces services externes s’additionnent sans fin, et j’en suis finalement arrivé à la conclusion qu’il vaut mieux héberger et exploiter soi-même tous ces services dans sa propre infrastructure
      Par exemple : Cloud Sentry → Self Hosted Sentry, Datadog → Prometheus/Grafana, Looker → Metabase, Snowflake → Clickhouse, ETL → Airbyte, etc.
      C’est pour cela que la plupart des entreprises finissent par choisir Kubernetes
      On peut mal comprendre pourquoi des indie hackers auraient besoin de la complexité de Kubernetes, mais c’est précisément la raison pour laquelle on ne peut pas tout faire tourner sur un seul VPS

    • Je suis d’accord avec l’idée que « la plupart des projets n’ont pas besoin d’être au web scale »
      Le marketing actuel des grandes plateformes cloud donne en fait l’impression que le YAGNI (You Ain’t Gonna Need It) s’applique aussi à l’infrastructure
      Je travaille comme administrateur système depuis le début des années 2000, et je trouve amusant de voir le retour de l’hébergement de ses propres services présenté comme s’il s’agissait d’une révolution
      Bien avant Docker, on faisait déjà tourner du code isolé avec LXC, BSD Jails, etc. ; c’est une tradition bien plus ancienne encore que le DevOps
      Observer les développeurs d’aujourd’hui redécouvrir tout cela est assez fascinant
      Enfin, je recommande de collaborer avec quelques sysadmins chevronnés, ou de leur offrir un café pour profiter de leur aide
      Beaucoup sont encore très partants pour gérer l’infrastructure à l’ancienne et ont un savoir-faire très concret à partager

    • Un autre avantage de l’auto-hébergement, par rapport aux services cloud, est que les compétences et connaissances système sont beaucoup plus transférables
      Si l’on apprend comment fonctionnent systemd, ufw et ssh, cela s’applique immédiatement à d’autres systèmes
      À l’inverse, j’ai l’impression que le temps et le coût nécessaires pour maîtriser Docker, les builds par couches de conteneurs et toutes sortes d’astuces dépassent ceux de l’administration d’un serveur web Debian classique

    • Globalement d’accord, et merci d’avoir partagé cet avis
      Le seul point sur lequel je diverge est l’idée qu’« un CDN n’est nécessaire qu’à grande échelle »
      À mon sens, un CDN ne sert pas seulement à répartir la charge des requêtes sur l’origine, mais surtout à réduire la latence côté utilisateur
      La vitesse perçue est en réalité l’une des fonctionnalités les plus importantes ; il faut éviter l’optimisation prématurée, mais au minimum servir les assets statiques depuis un edge proche de l’utilisateur est déjà un standard de base depuis une dizaine d’années

  • Excellent sujet, et je peux apporter mon point de vue à partir de mon expérience
    En exploitant moi-même un homelab, le principal bénéfice n’est ni la réduction des coûts ni la confidentialité des données en tant que telle, mais le fait d’acquérir une connaissance pratique réellement approfondie
    Il y a un monde entre apprendre Docker, le réseau et l’administration Linux en lisant des articles, et devoir faire tourner soi-même un service utilisé par sa famille puis résoudre un DNS qui tombe ou un conteneur Docker qui ne redémarre pas
    Mais il y a aussi une autre réalité
    Au départ c’est un projet amusant, puis dès qu’on commence à auto-héberger des services critiques comme un gestionnaire de mots de passe ou une synchronisation de fichiers, on devient l’astreinte 24/7
    Les sauvegardes, les correctifs de sécurité et la disponibilité deviennent entièrement de ma responsabilité, et à partir de là ce n’est plus seulement un hobby mais pratiquement un métier
    En fin de compte, l’auto-hébergement apporte le contrôle des données et un vrai sentiment d’accomplissement, mais le coût du SaaS est remplacé par mon temps et ma charge mentale sous la forme d’un rôle d’admin IT
    Cela dit, pour des utilisateurs de HN, je pense que ça vaut largement le coup d’essayer

  • Quelqu’un écrivait qu’il avait de la chance de travailler chez enum.co, une entreprise attachée à la souveraineté numérique, mais en regardant leur serveur mail sur info.addr.tools, on voit un MX sur smtp.google.com et beaucoup de propriétés Google dans les enregistrements TXT
    Ce n’est pas juste un « slogan » : c’est visible dans le DNS
    Mettre en avant la souveraineté numérique tout en dépendant de la messagerie Google est contradictoire
    https://info.addr.tools/enum.co

    • Pour défendre enum, leur offre porte sur k8, le stockage compatible S3 et le DevOps
      S’ils vendaient explicitement de l’auto-hébergement ou de la souveraineté e-mail tout en utilisant gmail, ce serait une autre histoire
      Ce n’est pas une indépendance totale à 100 %, et d’ailleurs l’OP dit lui-même que « l’auto-hébergement d’un serveur mail est vu comme un énorme tabou, mais ce n’est pas aussi effrayant qu’on pourrait le croire »
      Tout le monde est conscient du problème, et il reste encore des axes d’amélioration

    • Bonjour, je suis le fondateur d’enum
      La remarque est juste et pertinente
      Honnêtement, utiliser Google Workspace pour nos e-mails internes était un choix pragmatique afin de rester focalisés sur le développement du produit cœur au démarrage
      C’est un choix très courant dans les startups, et nous allons migrer dans les prochaines semaines
      En revanche, notre plateforme destinée aux clients et toutes les données ont toujours été souveraines à 100 %
      L’infrastructure est totalement indépendante des big tech
      Merci d’avoir soulevé ce point

    • Pour l’e-mail, je fais une exception à l’auto-hébergement
      J’auto-héberge tous les autres services, mais pour l’e-mail je passe par un tiers

    • Je suis impressionné par le fait d’avoir relevé aussi fermement la présence d’enregistrements liés à Google dans le DNS
      Franchement, c’est remarquable

    • La partie TXT google-site-verification=... n’a rien de particulièrement « maléfique » ; c’est plutôt un compromis pour éviter que Google ne classe les mails comme spam lors de l’envoi

  • Pour l’e-mail auto-hébergé, si la souveraineté numérique compte davantage pour vous que la confidentialité
    j’utilise un domaine personnalisé sur gmail, et j’auto-héberge mon propre serveur mail pour rapatrier en continu les messages depuis gmail avec mbsync
    Le stockage et la consultation se font sur mon serveur, mais l’envoi passe toujours par gmail
    Même si Google me bloque l’accès au compte, je conserve mes e-mails chez moi, et si je veux changer de fournisseur il suffit de modifier le DNS
    En plus, je n’ai pas de problème de délivrabilité sur les messages envoyés

    • J’ai commencé à auto-héberger mon e-mail il y a six ans, avec les réglages DNS type SPF, DMARC, etc.
      Je n’ai eu que très peu de problèmes, une ou deux fois tout au plus ; en général, les vrais ennuis venaient plutôt d’autres services, de pannes aléatoires, de changements d’IP ou de l’automatisation des sauvegardes que du serveur mail lui-même
      Au contraire, le serveur mail tourne tranquillement et fait son travail

    • Si l’on demande pourquoi ne pas auto-héberger aussi l’envoi des mails
      c’est probablement à cause des problèmes de délivrabilité ?

    • La véritable souveraineté sur l’e-mail repose sur le domaine personnalisé
      Si vous gardez la maîtrise de ce point en toute sécurité, vous pouvez choisir librement parmi plusieurs fournisseurs et changer sans blocage

  • L’auto-hébergement, c’est vraiment génial
    Depuis que je suis passé d’ingénieur logiciel à fondateur de SaaS il y a un an, j’auto-héberge avec Coolify et un serveur Hetzner à 20 dollars Postgres, une ancienne version de Minio, Nuxt, NextJs, Umami analytics, Open WebUI, des sites statiques, etc.
    Au début il a fallu apprendre, mais une fois la configuration terminée, lancer un nouveau service est devenu aussi simple que du plug and play
    Je n’utilise même pas un quart des ressources du serveur (j’ai peu d’utilisateurs, haha)
    https://coolify.io/docs/

  • Je travaille dans l’IT, mais je repoussais sans cesse l’auto-hébergement à la maison et la mise en place d’un NAS ; puis j’ai fini par acheter un modèle Ugreen NAS 4 baies et installer immédiatement TrueNAS CE
    J’ai fait toute la configuration avec ChatGPT, en lui donnant même le contexte de mon propre fichier docker-compose
    Je n’avais pratiquement aucune connaissance en Docker, réseau, etc., à part quelques souvenirs d’étudiant
    Aujourd’hui, j’exploite

    • plusieurs applications Dockerized
    • un réseau indépendant pour chaque stack applicative
    • la gestion de l’exposition des interfaces web via Traefik + labels Docker
    • seule l’interface Traefik sur le port 443 est exposée vers l’extérieur, avec redirection de port uniquement si nécessaire
    • des tunnels Cloudflare en option
    • la terminaison TLS automatique par Traefik pour le domaine, en LAN comme en WAN
    • du Split-DNS pour le LAN/WAN
    • CrowdSec sur tous les conteneurs exposés
    • la MFA appliquée aux services exposés via Cloudflare
    • DHCP/DNS local avec Technitium
    • des snapshots ZFS automatiques et des sauvegardes distantes
    • les données volatiles comme les bases et les logs sur SSD, et les gros fichiers sur HDD
      et tout cela fonctionne très bien

  • L’auto-hébergement, c’est bien, mais le vrai problème ce sont les sauvegardes et les mises à niveau
    J’héberge moi-même diverses ressources, mais rien de critique ni rien dont d’autres personnes doivent dépendre
    Si la restauration de l’application ou sa mise à niveau n’est pas simple, j’évite d’en dépendre
    En réalité, il existe peu d’applications auto-hébergées dont la sauvegarde et la restauration se résument à une ou deux lignes
    Au passage, Tailscale et Pangolin sont de véritables cadeaux du ciel pour auto-héberger chez soi en toute sécurité

    • Je suis curieux : qu’attendez-vous comme solution de sauvegarde ?
      Toutes mes applications auto-hébergées tournent dans Docker, donc il suffit de sauvegarder le dossier des volumes du conteneur et le docker-compose.yml
      Pour restaurer, on remet le dossier puis on lance docker compose up, et c’est terminé
      Je ne pense pas que chaque application doive implémenter son propre mécanisme de sauvegarde ; ce serait une perte de temps pour les développeurs

    • Je recommande vivement d’auto-héberger netbird à la place de Tailscale
      Le développement est très actif et l’interface est excellente
      https://github.com/netbirdio/netbird

    • Je me demande ce qu’est Pangolin
      Quand je cherche, je ne tombe que sur l’animal

  • Ma stack d’auto-hébergement

    1. immich
    2. jellyfin
    3. ghost
    4. wallabag
    5. freshrss
    6. vaultwarden
    7. nextcloud
    8. overleaf/sharelatex
    9. serveur matrix
    10. pds pour atproto
    • J’aimerais savoir comment vous faites les mises à jour, comment vous appliquez les correctifs de sécurité, comment vous gérez les sauvegardes et surtout comment vous testez tout cela régulièrement
      Les indications sur les montées de version ou les correctifs de sécurité sont parfois insuffisantes, et il arrive même qu’on soit obligé de passer par toutes les versions intermédiaires

  • Si l’on restreint trop l’idée d’« auto-hébergement » aux seuls serveurs à la maison, cela restera forcément quelque chose de marginal
    Il faut aussi encourager toutes les approches non-SaaS : applications open source sans abonnement, anciens logiciels Windows, applications cloud facilement migrables, etc.
    Quel que soit le moyen, l’objectif réel de l’auto-hébergement est d’éviter le lock-in et de redonner le contrôle à l’utilisateur

    • Malgré cela, il ne faut pas diluer le sens du mot
      Même une application cloud migrable via des protocoles standard reste soumise aux décisions de l’opérateur si elle ne tourne pas sur un serveur que je possède ou contrôle
      Les politiques de données ou de collecte peuvent changer du jour au lendemain
      On ne peut pas être sûr de ce qui est collecté à notre insu, ni même de pouvoir migrer ses données avant une fermeture du service

    • Un logiciel Windows installé localement peut aussi relever de l’auto-hébergement
      En pratique, beaucoup commencent par un exécutable Windows ou par Docker, puis évoluent progressivement vers quelque chose de plus avancé

    • À minima, je considère que faire tourner un serveur dans le datacenter de quelqu’un d’autre (en colocation, par exemple) avec les droits root reste de l’auto-hébergement

  • Il y a 20 ans, même les grands-parents pouvaient télécharger setup.exe sur limewire.com et cliquer sur next -> next -> next pour installer un serveur de fichiers et un client parfaitement fonctionnels
    En 2007, un tiers des ordinateurs du monde utilisait LimeWire
    Pourtant aujourd’hui, même les logiciels d’auto-hébergement les plus basiques sont pratiquement réservés à des ingénieurs de niveau pro
    Il faut gérer SSH, Docker, Tailscale, des certificats TLS, les sauvegardes et une foule d’autres automatisations…
    Je me demande pourquoi les logiciels d’« auto-hébergement » qui s’installent avec un simple apt-get install sont si rares
    C’est précisément pour cela que presque personne n’héberge lui-même ses services
    https://en.wikipedia.org/wiki/LimeWire

    • Certains logiciels s’installent effectivement avec apt-get install, mais si l’on veut exposer un service sur Internet, il faut déjà configurer un nom de domaine et le HTTPS
      Des clients comme LimeWire ou BitTorrent pouvaient fonctionner sans domaine justement parce qu’ils reposaient sur des serveurs centraux (trackers, etc.)

    • Beaucoup de gens ne considéreraient pas un installateur comme LimeWire comme de l’auto-hébergement
      C’est simplement l’installation d’un programme local

    • Ubuntu avait essayé de faciliter l’installation d’applications côté serveur via snap, mais la communauté s’y est fortement opposée et l’initiative a échoué
      snap a certes des défauts, mais le format avait justement été pensé pour simplifier le déploiement des applications serveur
      On peut encore aujourd’hui installer nextcloud avec snap, par exemple
      À force de rejeter tout ce qui n’est pas parfait, on finit aussi par écarter les solutions simplement « assez bonnes » et pragmatiques

    • LimeWire est un client, pas un serveur
      Pour bien uploader, il fallait configurer le firewall et le port forwarding, voire activer l’UPnP (ce que je ne recommande pas)
      L’auto-hébergement d’un serveur, c’est un tout autre domaine
      Dans un monde où les débutants auraient pu tout faire automatiquement, les hackers malveillants ont fait monter la difficulté de configuration et d’exploitation
      Même les experts restent vulnérables face à des pentesters professionnels ou à des acteurs étatiques

    • Je pense que le développement logiciel moderne est lui-même devenu excessivement complexe
      On finit par créer artificiellement des problèmes inutiles, un peu comme une bureaucratie qui entretient sa propre existence
      La plupart des gens n’ont même pas besoin d’aller jusqu’à l’auto-hébergement ; il leur suffirait de faire tourner le logiciel sur leur ordinateur et d’y accéder occasionnellement depuis le réseau local
      Mais comme il n’y a pas de modèle économique derrière cela, les développeurs s’obsèdent pour des couches spécialisées et des architectures inutilement compliquées
      Au final, on se retrouve avec des logiciels serveurs, des webviews, un décalage entre les données et l’environnement local, et toujours plus de machines à administrer
      La majorité des ordinateurs restent sous-utilisés pendant qu’on continue d’empiler des couches de gestion au-dessus
      Je pense que la mode des laptops fait aussi partie de cette confusion
      Les bonnes applications locales pour Mac ont disparu, remplacées par des abonnements cloud à perte de vue
      Même l’open source finit souvent livré sous forme d’image Docker, avec des configurations compliquées et une montagne de gotchas
      Si l’installation et l’administration étaient vraiment simples, je serais même prêt à payer pour ça
      Mais aujourd’hui, comme on ne peut jamais savoir combien de temps cela va prendre, tout le monde finit par laisser faire les big tech
      Les technologies web sont utiles pour les documents interactifs, mais en dehors de cet usage elles restent encore très difficiles à bien rendre utilisables