Le Low-tech Lab documente habituellement des objets, des techniques et des manières de fabriquer avec moins de ressources.
En 2026, l’association a appliqué la même logique à un objet beaucoup moins photogénique : son propre système informatique.1
Pendant trois mois, de janvier à mars, l’équipe a expérimenté l’auto-hébergement dans ses locaux en Bretagne. L’objectif annoncé était double : quitter son hébergement chez OVH et remplacer la suite Google, notamment Drive et la messagerie, par des outils libres et jugés plus cohérents avec sa démarche.1
À la fin juin, le Low-tech Lab indique avoir quitté Google.1
La partie intéressante n’est pas de savoir si un serveur sous une table est soudainement devenu « low-tech ».
C’est que l’association a traité la migration comme un savoir-faire à documenter.
L’auto-hébergement devient un chantier, pas une préférence
Sur la page de synthèse, l’expérience est découpée en quatre chapitres : comprendre les enjeux autour des données, reprendre la maîtrise de l’hébergement, installer un serveur dans une structure collective, puis migrer les données.1
Ce découpage est presque banal.
C’est sa qualité.
Les discussions sur la souveraineté numérique prennent facilement la forme d’une liste de principes : ne pas dépendre d’un grand fournisseur, garder ses données, utiliser du logiciel libre, réduire les services centralisés. Ces idées disent peu de choses sur le moment où quelqu’un doit réellement déplacer des années de fichiers, des comptes, des calendriers et une messagerie sans interrompre le travail de toute l’équipe.
Le Low-tech Lab remet cette partie au centre.
La page explique par exemple que le passage de Google Drive vers Nextcloud s’appuie sur rclone, un outil de synchronisation et de transfert entre stockages.1 Ce détail est plus instructif qu’un manifeste supplémentaire : sortir d’un service ne consiste pas à choisir une nouvelle icône. Il faut construire un chemin entre l’ancien système et le nouveau.
La dépendance ne disparaît pas, elle change de forme
L’auto-hébergement est souvent raconté comme le contraire de la dépendance.
En pratique, il remplace certaines dépendances par d’autres.
Une organisation dépend moins directement du fournisseur qui héberge ses fichiers ou sa suite bureautique. En échange, elle doit posséder ou trouver des compétences pour installer, sauvegarder, mettre à jour, surveiller et réparer son infrastructure.
Le Low-tech Lab ne publie pas sur sa page de synthèse de comparaison chiffrée permettant d’affirmer que son système est moins cher, moins énergivore ou plus sûr. Il ne faut donc pas lui prêter ces résultats.1
Ce qu’il publie est un processus d’appropriation.
C’est assez cohérent avec la manière dont la low-tech aborde déjà les objets physiques. Un dispositif n’est réellement appropriable que si son fonctionnement peut être compris, entretenu et transmis par davantage de personnes que son fabricant initial.
Avec un serveur, le principe devient plus abstrait mais la contrainte reste la même.
Une infrastructure que personne dans l’équipe ne sait restaurer après une panne n’est pas très autonome, même si elle tourne dans le bâtiment d’à côté.
Documenter fait partie de l’infrastructure
La page du Low-tech Lab annonce la documentation sous licence CC BY-SA.1
Ce choix transforme l’expérience interne en matériau réutilisable.
On retrouve ici un point déjà présent dans les communautés open source et maker : un système reproductible ne se résume pas à la machine qui fonctionne aujourd’hui. Il faut aussi conserver les instructions, les choix, les étapes de migration et les raisons qui permettent à quelqu’un d’autre de reconstruire le chemin.
Pour un objet physique, ce rôle peut être tenu par un plan, une nomenclature ou un tutoriel.
Pour une infrastructure logicielle, il faut documenter des comptes, des services, des sauvegardes, des dépendances et des procédures de reprise. La matière est moins visible, mais elle vieillit tout autant.
Le serveur n’est donc qu’une moitié du projet.
L’autre moitié est la possibilité qu’un autre collectif puisse lire ce qui a été fait et décider ce qu’il veut reprendre, modifier ou éviter.
La low-tech numérique commence peut-être par rendre les sorties praticables
Il serait facile de résumer l’expérience par « le Low-tech Lab quitte Google ».
C’est vrai, mais un peu court.
La partie transférable se trouve dans le mouvement inverse : comment rendre possible le départ d’un service devenu central ?
L’association a passé trois mois à tester l’infrastructure avant d’annoncer sa migration. Elle publie ensuite le chemin au lieu de seulement publier le résultat.1
C’est une définition assez concrète de l’autonomie.
Pas l’absence de dépendance. Pas la promesse qu’un petit serveur local battra systématiquement un cloud mondial sur tous les critères.
La capacité à comprendre suffisamment sa dépendance pour pouvoir la modifier.
Dans ce cadre, rclone, une procédure de sauvegarde ou un chapitre sur la migration sont des objets low-tech au même titre qu’un assemblage démontable : ce sont des moyens de ne pas transformer une décision passée en verrou permanent.
Le numérique a longtemps caché cette question derrière des boutons « exporter mes données ».
Le Low-tech Lab la remet dans l’atelier.