Infrastructure

Infrastructure

Self-hosting, souveraineté numérique et stack personnelle.

Explication de la marmotte

Cette rubrique ressemble au choix entre louer un appartement meublé et bâtir sa propre maison : chez soi, on décide de tout, de la serrure aux étagères, mais on répare aussi soi-même la fuite du dimanche. Elle aide à peser ce que l’on garde sous son toit et ce que l’on confie à d’autres.

→ Lire l’explication complète de la marmotte

Héberger ses services chez soi a un charme certain : aucune facture à la seconde, aucune condition d’utilisation réécrite un vendredi soir, et la satisfaction de savoir exactement sur quel disque dort chaque donnée. Le prix est connu de quiconque l’a payé : l’astreinte, c’est soi, la sauvegarde, c’est soi, et la mise à jour de sécurité oubliée pendant les vacances, c’est encore soi. Cette rubrique aide à peser ce qu’on garde sous son toit et ce qu’on confie à d’autres, sans romantisme dans un sens ni dans l’autre.

L’ordre de lecture proposé va du concret au stratégique : d’abord le socle de l’hébergement personnel (système, isolation, exposition, sauvegarde), puis la question de la souveraineté, enfin les briques logicielles d’une pile locale. Plusieurs pages citées ici vivent dans d’autres rubriques, parce que le sujet les traverse toutes.

Héberger soi-même

• Une infrastructure tenue par une seule personne : la faiblesse la plus grave d’un serveur autohébergé est son administrateur unique.
• Durcir un serveur Linux avant la mise en production, checklist : de l’accès SSH par clé au scan de conformité.
• Hyperviseur Type 1 ou Type 2 : lequel choisir : machines virtuelles et surface d’attaque de l’hyperviseur.
• Docker ou Podman en auto-hébergement : démon root ou mode rootless, ce que vaut une compromission dans chaque cas.
• Images Docker de base et confiance héritée : ce qu’on hérite en écrivant une ligne FROM.
• NAT, translations et publication de services : exposer un service interne sans confondre traduction d’adresses et protection.
• QUIC, HTTP moderne, TLS et proxys applicatifs : le proxy inverse et la terminaison TLS devant les services.

Sauvegarder et restaurer

• La règle 3-2-1 à l’épreuve du rançongiciel : une sauvegarde joignable avec les identifiants de production n’en est pas une.
• Configurer une sauvegarde restic résistante au ransomware : dépôt en ajout seul et copie verrouillée.
• Sauvegarde immuable anti-ransomware et verrouillage WORM : la rétention que même un administrateur ne peut pas raccourcir.
• Tester une restauration après sinistre simulé : la seule preuve qu’une sauvegarde existe.

Souveraineté numérique

• Ce que « hébergé en France » garantit : la localisation des disques compte moins que la juridiction et la maîtrise des clés.
• Résidence des données et souveraineté cloud : localisation réelle, contrôle technique et dépendances juridiques.
• Comment minimiser les données collectées : la donnée personnelle la mieux protégée est celle qu’on n’a pas.
• Local-first : architecture de données locale et durable : des données et des traitements qui restent sur l’appareil, synchronisation en option.

Briques d’une pile locale

• Déployer Ollama sur un poste de travail et dimensionner la mémoire : un modèle de langage local, réglé selon la mémoire disponible.
• Déployer Qdrant local pour recherche sémantique interne : une base vectorielle installée et exploitée sur place.
• Faire tourner un modèle chez soi : ce que le local garantit vraiment, et ce qui reste à la charge de l’utilisateur.
• Protéger les branches Git et permissions entreprise : le dépôt de code comme surface de sécurité.

🐝 Ce qui arrive si on s’en passe

Une organisation qui ne se pose jamais la question de l’hébergement finit par découvrir sa pile personnelle le jour où une brique disparaît : un fournisseur change ses conditions, un compte est suspendu, un disque lâche, et personne ne sait plus où résident les données ni comment les récupérer. Les données personnelles confiées au passage à un tiers échappent à tout contrôle direct, et les sauvegardes jamais organisées se révèlent, au moment critique, n’avoir jamais existé. La dépendance au nuage n’est pas un défaut en soi ; l’ignorer en est un, et il se paie toujours au pire moment, avec une ponctualité remarquable.

🦫 Explication de la marmotte 🍫

Cette rubrique traite de l’endroit où tournent les services et où dorment les données. Héberger soi-même signifie faire fonctionner ses propres services sur son propre matériel : un mini-ordinateur, un boîtier de stockage branché au réseau, ou des machines virtuelles, c’est-à-dire des ordinateurs simulés par logiciel sur une machine réelle. Les conteneurs emballent chaque programme avec tout ce dont il a besoin, isolé des autres, mais ils héritent aussi des défauts de l’image de départ. Un relais d’entrée, appelé proxy inverse, reçoit les connexions venues de l’extérieur et les transmet au bon service ; la traduction d’adresses qui rend un service joignable n’est pas, à elle seule, une protection. Les sauvegardes copient régulièrement les données ailleurs, et une sauvegarde n’a de valeur que si on a déjà réussi à la restaurer, et si un intrus qui a pris la machine principale ne peut pas l’effacer.

La souveraineté numérique pose la question du contrôle : un service confié à un fournisseur en ligne dépend de ses conditions, de sa disponibilité, de ses choix et du droit du pays où il est établi, quel que soit l’endroit où se trouvent ses disques. L’approche « local d’abord » garde les données sur l’appareil de l’utilisateur et laisse fonctionner les outils sans connexion. Les briques d’une pile locale, enfin, comprennent un outil pour faire tourner des modèles de langage sur sa propre machine, une base qui retrouve des textes par leur sens et un dépôt de code. Quand une brique hébergée tombe sans sauvegarde, ses données disparaissent avec elle ; quand un fournisseur externe s’arrête, tout ce qui s’appuie sur lui s’arrête aussi ; et quand la seule personne qui sait tout réparer part en vacances, les deux arrivent en même temps.