Cela commence généralement par une question simple : ne puis-je pas le faire moi-même ?
Un album photo. Un partage de fichiers. Un wiki d’équipe. Quelque chose que l’on utilise actuellement — auprès d’un fournisseur qui l’offre commodément, gratuit ou bon marché, avec une jolie interface. Et puis un moment où l’on réalise : les données sont quelque part. Pas ici. Pas chez moi. Chez quelqu’un que je ne connais pas, sous des conditions que je ne peux influencer.
Ce moment est le début de l’auto-hébergement. Et il change plus qu’on ne le soupçonne au départ.
Ce que l’auto-hébergement enseigne
Quiconque décide d’exploiter un service lui-même entre dans une école. Pas théorique — pratique.
Soudain, il est question de réseaux : adresses IP, redirection de ports, DNS, proxys inverses, sous-réseaux. Des choses invisibles jusque-là deviennent concrètes. On apprend comment un paquet voyage de A à B, pourquoi une connexion bloque, d’où vient un dépassement de délai.
Il est question de sécurité : pare-feu, chiffrement, certificats, mises à jour, règles d’accès. Celui qui met un service sur internet en est responsable. Cela aiguise le regard sur des menaces qu’on ne connaissait auparavant que par la presse.
Et il est question de gestion du cycle de vie des services : mises à jour, sauvegardes, supervision, restauration, migration. Un service n’est pas installé et terminé. Il vit. Il vieillit. Il doit être entretenu. Qui l’a compris une fois comprend l’infrastructure tout autrement.
L’auto-hébergement est la formation informatique la plus intensive qui existe. Parce qu’elle n’est pas simulée.
La vérité honnête sur les coûts
Maintenant, cela devient inconfortable. L’auto-hébergement est souvent plus cher que le cloud.
Pas toujours, mais souvent. Un serveur coûte de l’électricité. La redondance coûte un deuxième appareil. Les sauvegardes coûtent du stockage. Un serveur mail personnel coûte des nerfs et du temps qu’on économiserait avec un service hébergé. Et puis les heures de travail : installation, maintenance, dépannage, mises à jour. Des heures que quelqu’un doit payer — en argent ou en temps libre.
Celui qui le nie n’est pas honnête. Les fournisseurs de cloud n’ont pas inventé leurs économies d’échelle. Elles existent. Un centre de données avec des centaines de milliers de serveurs peut livrer un courriel moins cher qu’un serveur unique dans une cave. Ce n’est pas un argument contre l’auto-hébergement. C’est un fait qu’il faut connaître avant de décider.
Pourquoi confier ses données n’est plus une option
Mais maintenant, renversons l’argument. Car le prix n’est pas tout.
Lorsque vous confiez vos données à un service cloud, vous ne savez pas où elles résident physiquement. Vous ne savez pas qui y a accès. Vous ne savez pas si elles sont analysées, vendues, utilisées comme matériau d’entraînement pour une IA ou transmises à des filiales. Les conditions d’utilisation sont formulées de sorte que vous consentez sans comprendre.
Vous ne savez pas si des sauvegardes existent — et si oui, selon quel schéma. Vous ne pouvez rien faire si le service tombe. Vous ne pouvez pas aller jusqu’au disque dur. Vous ne pouvez pas débrancher et redémarrer. Vous ne pouvez qu’attendre. Quelqu’un que vous ne pouvez pas joindre, dans un système que vous ne contrôlez pas.
À une époque où les données sont une monnaie, où des profils sont dressés, des comportements prédits et des décisions sur des personnes automatisées, la question de qui on confie ses données n’est plus un détail. Elle est existentielle.
« Je n’ai rien à cacher » — l’erreur la plus dangereuse
Il y a un argument qui revient toujours. « Je n’ai rien à cacher. » Prononcé par des gens qui ferment leurs rideaux, gardent un journal intime sous clé, mettent un mot de passe sur leur téléphone — et croient sincèrement que la protection des données ne concerne que les criminels.
C’est faux. Dangereusement faux.
Tout le monde a quelque chose à cacher. Non par honte, mais parce que la vie privée est la condition de l’autonomie. Celui qui tout révèle est manipulable. Celui qui n’a aucun secret n’a aucune limite. Et celui qui n’a aucune limite n’a aucune liberté — seulement l’illusion de la liberté.
Les lois de protection des données comme le RGPD ne sont pas un exercice bureaucratique. Elles sont la reconnaissance institutionnalisée que le pouvoir des données est un pouvoir sur les personnes. Celui qui détient les données détient le pouvoir d’interprétation. Celui qui peut prédire le comportement peut l’influencer. Celui qui connaît l’empreinte numérique connaît la personne mieux qu’elle ne se connaît elle-même.
Le Big Data ne fonctionne que parce que nous avons collectivement renoncé. Parce que des millions de personnes ont dit un jour : « Bon, tant pis, je vais dans le cloud. » Chacun individuellement, inoffensif. Ensemble : un homme de verre. Un citoyen transparent, analysé par des systèmes qu’il ne comprend pas, optimisé pour des modèles économiques qui ne poursuivent pas ses intérêts.
Celui qui dit n’avoir rien à cacher devrait mener sa prochaine conversation avec son médecin, son comptable ou sa banque en public. Rien à cacher ? Non. Il n’a simplement pas encore compris qu’il a déjà livré ce qu’il aurait dû protéger.
Nommer honnêtement les inconvénients
L’auto-hébergement a des désavantages. Les dissimiler détruit toute crédibilité.
Portée mondiale. Un hyperscaler — AWS, Azure, Google Cloud — exploite des points de présence partout dans le monde. Livrer simultanément du contenu à Tokyo, São Paulo et Le Cap exige une infrastructure mondiale. Votre propre serveur à Alsdorf livre rapidement à Alsdorf. Pas à Tokyo.
Performance. Les réseaux de diffusion de contenu mettent en cache près de l’utilisateur. C’est rapide. C’est efficace. C’est quelque chose qu’on ne peut reproduire soi-même qu’avec un effort considérable.
Disponibilité. Les grands fournisseurs de cloud proposent des SLA qu’un opérateur unique peut difficilement égaler. Alimentation redondante, réseaux redondants, centres de données redondants. Cela coûte — mais cela fonctionne.
Tout cela est vrai. Et c’est pourquoi certains services sont mieux placés dans le cloud que dans votre propre cave. Le nier catégoriquement est idéologique, pas pratique.
Et pourtant : pourquoi la souveraineté n’est pas négociable
Maintenant le tournant. Car malgré tous les inconvénients, il y a une question qu’aucune vitesse et aucun SLA au monde ne peuvent répondre : Qui a le contrôle ?
La disponibilité compte. Mais la disponibilité sans contrôle est une promesse que quelqu’un d’autre peut rompre à tout moment. Un service cloud peut doubler ses prix. Il peut modifier ses conditions. Il peut suspendre votre compte — à cause d’une analyse de contenu pilotée par IA défectueuse, sans avertissement, sans recours. Il peut arrêter le service. Il peut être racheté, et la nouvelle stratégie ne couvre plus votre cas d’usage.
L’internet a été conçu comme un medium décentralisé. Un réseau où chaque nœud est égal, où les données peuvent emprunter de nombreux chemins, où il n’y a pas de point de défaillance unique. Cette architecture fut la condition de la croissance d’internet. Elle fut la condition de sa résilience.
Les grands fournisseurs de cloud brisent ce concept. Ils centralisent ce qui devait être décentralisé. Ils construisent des silos qui ne se parlent guère. Ils créent des dépendances qui contredisent l’esprit d’internet.
Quand le cloud tombe
Et puis il y a l’argument le plus rarement cité mais le plus difficile à réfuter : le risque de concentration.
Les fournisseurs de cloud sont hautement disponibles. Jusqu’à ce qu’ils ne le soient plus. Quand un hypercale tombe — et cela s’est produit, à plusieurs reprises —, ce n’est pas un service qui échoue. Des centaines, des milliers échouent. Simultanément. Mondialement. Compagnies aériennes, banques, sites d’information, SI hospitaliers, systèmes de paiement. Tous sur la même plateforme. Tous touchés par le même incident. Tous impuissants.
C’est le revers de la centralisation. Une entité unique fiable jusqu’à ce qu’elle ne le soit plus — et qui entraîne tout dans sa chute. Les structures décentralisées sont plus lentes, moins efficaces, moins parfaites. Mais quand un nœud tombe, les autres ne tombent pas avec lui. Ce n’est pas une faiblesse. C’est de la résilience.
La prison oligopolistique
Parlons des prisons que nous nous sommes construites.
Deux plateformes mobiles. Trois fournisseurs de cloud. Une poignée de moteurs de recherche. Un réseau social qui a absorbé tous les autres. Nous vivons dans un monde numérique dominé par une poignée d’entreprises — et nous appelons cela du choix.
C’est le choix entre la peste et le choléra. iOS ou Android. AWS ou Azure. Google ou — eh bien, quoi exactement ? L’illusion des options est l’instrument le plus puissant des oligopoles. On peut choisir — entre deux options qui suivent toutes deux le même modèle : collecter des données, créer une dépendance, rendre la sortie difficile.
Choisir iOS, c’est choisir un jardin clos. Choisir Android, c’est choisir un autre jardin clos — d’une couleur différente. Dans les deux cas, on se rend. Dans les deux cas, le fournisseur décide ce qui tourne sur l’appareil, quelles applications sont permises, quelles données circulent. L’utilisateur choisit l’appareil. Le fournisseur choisit les conditions.
Ce n’est pas une théorie du complot. C’est un modèle économique. Et il fonctionne parce que partir coûte plus cher que rester. Verrouillage fournisseur, comme nous le connaissons — sauf que cette fois, ce n’est pas un logiciel, mais tout un écosystème.
La sortie de la prison commence petit. Elle commence par un service que l’on auto-héberge. Un premier pas vers la souveraineté. Tout n’a pas besoin d’être auto-hébergé d’un coup. Mais chaque service retiré de l’oligopole est un fragment de liberté reconquis.
Auto-héberger — aussi pour les autres
Et ici intervient une responsabilité souvent ignorée.
Ceux qui ont la capacité de s’auto-héberger — techniquement, temporellement, mentalement — portent une responsabilité qui les dépasse. Tout le monde ne peut pas exploiter un serveur mail. Tout le monde ne peut pas administrer Nextcloud. Tout le monde ne le souhaite pas. Mais tout le monde a des données. Et tout le monde mérite un endroit où ces données ne sont pas vendues à la prochaine corporation.
Ceux qui s’auto-hébergent ne devraient pas le faire uniquement pour eux-mêmes. Mais aussi pour leurs amis. Pour leur famille. Pour le voisin qui ne veut pas confier ses photos à Google mais ne connaît rien à Linux. Pour les parents qui cherchent un carnet d’adresses sécurisé. Pour le club qui a besoin d’un wiki qui lui appartient.
Ce n’est pas de la charité. C’est de la résistance. Chaque fois que quelqu’un détourne son flux de données hors de l’oligopole vers un service auto-hébergé, le monopole s’affaiblit. Pas de façon perceptible. Pas immédiatement. Mais en principe.
Et c’est de l’éducation. Quiconque utilise un service auto-hébergé — même sans l’administrer — apprend qu’il existe des alternatives. Que les données n’ont pas inévitablement à vivre chez Google. Que l’on peut faire confiance à quelqu’un que l’on connaît plutôt qu’à quelqu’un que l’on ne connaît pas. C’est la graine dont, un jour, quelque chose pousse.
D’autres pistes à explorer
Quiconque s’intéresse à l’auto-hébergement bute sur des questions qui vont loin :
Chiffrement et gestion des clés. Chiffrer ses données — mais laisser la clé chez le fournisseur de cloud — signifie chiffrer pour le fournisseur, pas pour soi-même. Les architectures à divulgation nulle de connaissance en sont la conséquence. Elles sont laborieuses. Mais elles sont le seul moyen pour qu’un fournisseur ne puisse vraiment rien lire.
Sauvegardes et restauration. Une sauvegarde qu’on n’a jamais testée n’est pas une sauvegarde. Les auto-hébergeurs testent. Les sous-traitants font confiance. La différence n’apparaît que quand ça brûle.
Droit et conformité. Où se trouvent les données ? RGPD, localisation des serveurs, chaînes de sous-traitants. Les auto-hébergeurs le savent. Les sous-traitants espèrent.
Migration. Le chemin vers le cloud est facile. Le chemin inverse ne l’est pas. Formats d’export, formats de données propriétaires, API manquantes — le schéma bien connu de verrouillage fournisseur. Les auto-hébergeurs possèdent leurs données dans des formats qu’ils comprennent. Les sous-traitants possèdent un abonnement.
Comment libcom.de peut aider
Ici, cela devient concret. L’auto-hébergement n’est pas une fin en soi. C’est un moyen de souveraineté. Et la souveraineté exige du savoir-faire.
Chez libcom.de, nous exploitons des infrastructures auto-hébergées depuis plus de deux décennies. Nous savons ce que cela coûte — en temps, en argent et en nerfs. Mais nous savons aussi ce que cela vaut.
Notre travail ne commence pas par un produit, mais par une question : De quoi avez-vous besoin, et que voulez-vous garder entre vos mains ? Parfois la réponse est : une solution complète sur site. Parfois : un dispositif hybride où les données sensibles sont auto-hébergées et les services gourmands en ressources tournent là où les économies d’échelle s’appliquent. Parfois : simplement une estimation honnête de savoir si l’auto-hébergement a du sens pour votre cas.
Nous planifions, implémentons, documentons et remettons. Nous formons les équipes pour qu’elles comprennent et poursuivent ce que nous construisons. Et nous ne restons pas le goulot d’étranglement — ceux qui nous quittent peuvent continuer à faire fonctionner le système parce qu’il est documenté, normalisé et compréhensible.
Si vous vous demandez si l’auto-hébergement est une option pour vous, ou si vous auto-hébergez déjà et avez besoin de soutien : écrivez-nous à contact@libcom.de. Nous faisons un inventaire honnête — sans pression commerciale, avec le regard sur ce dont votre infrastructure a besoin à long terme.
L’auto-hébergement n’est pas la voie la moins chère. C’est souvent la plus chère. Mais c’est la voie sur laquelle on comprend ce que l’on exploite. Sur laquelle on apprend comment les choses se relient. Sur laquelle on garde le contrôle — sur les données, sur la disponibilité, sur la question de qui a réellement accès.
L’internet a été pensé comme décentralisé. Il est peut-être temps de récupérer cette idée.