Publié

~4mn de lecture 🕑

lun. 05 octobre 2015

← Liste des articles

La difficile promesse de l'auto-hébergement

Read the English version

Au détour de quelques conversations, nous avons pu nous rendre compte que notre vision de Kinto est celle d'un hébergement communautaire décentralisé plutôt que celle d'un ensemble de petits serveurs personnels. Explications.

Kinto veut répondre à deux besoins principaux de la plupart des utilisateurs du Web : stocker et partager des données, sans que ceux-ci perdent le contrôle sur leurs données.

Si Kinto doit être une "base de données pour le Web", alors il est nécessaire que l'ensemble des personnes puissent facilement avoir accès à un serveur Kinto.

Auto-hébergement

Maison de campagne -- House, Automn - CC-BY-ND Gunnar Magnusson https://www.flickr.com/photos/matupplevelser/4644386646

Déployer des serveurs n'est pas actuellement chose aisée. Nombre d'initiatives visent à rendre ce déploiement plus simple, mais les défis techniques sont encore nombreux avant d'aboutir à une solution "plug and play" qui soit aisément maintenable dans le temps.

Les serveurs doivent être maintenus à jour pour éviter les failles de sécurité et qu'ils restent disponibles pour ceux qui en ont besoin.

On le voit bien sur nos systèmes déployés : il nous est nécessaire d'avoir recours à des "administrateurs" pour ces tâches. Et croyez nous, si ces interventions étaient facilement automatisables, elles le seraient déjà ! (personne ne souhaite se lever au milieu de la nuit pour résoudre les soucis des autres)

Nous ne sommes malheureusement pas arrivés à un état de l'art qui permette à tout un chacun de s'auto-héberger de manière simple et pérenne.

Un réel travail est donc nécessaire afin d'avoir un service de qualité.

Acentré

Une solution praticable semble la mise en place d'un système avec plusieurs centres, acentré, donc décentralisé.

Plutôt que d'avoir un seul endroit où les données sont stockées, on pourrait imaginer avoir un ou plusieurs serveurs par communauté (Tetaneutral, Framasoft, EFF, LUG de votre ville …), factorisant alors les coûts (humains et monétaires) de mise en production. Cela permet donc d'administrer un seul serveur pour plusieurs personnes / applications.

Je vous vois, à deux doigts de bougonner : "Il est mignon avec ses serveurs communautaires mais mes données personnelles je préfère quand même ne pas les donner à n'importe qui !". Et vous auriez raison !

Kinto permet de stocker n'importe quel type de données. Qu'il s'agisse de données qui ont vocation à être partagées ou de données qui sont les vôtres et qui doivent rester privées.

Un de nos objectifs est de rendre le chiffrement des données extrêmement simple afin que personne (sinon vous) ne soit capable de les lire.

Kinto.js le permet d'ailleurs d'ores et déjà, comme Michiel le démontre dans un article paru précedemment ici.

Éviter la création d'un nouveau silo

Le futur des silos - CC-BY-NC-ND Sunflower Silo in Boulder County Colorado by Bo Insogna — https://www.flickr.com/photos/thelightningman/5494666930

Afin d'éviter de participer à la création d'un nouveau silo, il est important de lever quelques points de vigilance :

Identité

Un des points qui permet aux silos actuels (Facebook, Twitter) de perdurer, c'est en partie leur système d'identification. Vous souhaitez partager des données avec votre cousine, mais vous n'avez que son "compte Facebook" pour la joindre.

C'est très certainement un fait malheureux, mais tentons de résoudre un problème à la fois (malheureusement, la tentative d'identité décentralisé — Mozilla Persona — bât sérieusement de l'aile).

Laissons donc les personnes s'authentifier avec la solution de leur choix, libre ou non (OpenID, Firefox Accounts, Github, Twitter, Facebook etc.) mais redonnons leur le choix de l'endroit ou leurs données sont, elles, stockées.

Interopérabilité

Peu importe la solution de stockage de données que vous choisissez, il est indispensable qu'il existe des interfaces, des formats, pour passer de l'une à l'autre.

Kinto expose (avant tout) une API HTTP (certains diraient RESTful) qui parle JSON, ce qui rend son intégration avec d'autres solutions aisée.

Dans un premier temps, cela peut être simplement des fonctionnalités d'import / export d'une solution vers une autre, mais il est préférable de se mettre d'accord sur un format pour cet échange, sans quoi un standard de facto émergera, pour le meilleur et pour le pire !

Il est donc primordial d'entamer un travail de collaboration avec les autres systèmes de "clouds privés" tels que OwnCloud ou CozyCloud.

Ces derniers ont d'ailleurs mis en place un groupe de travail sur le sujet, qui vise à utiliser MicroPub et WebMention comme briques de départ.

Décentralisation

La mise en place de serveurs communautaires n'empêche bien sûr pas l'utilisation de serveurs personnels pour les utilisateurs les plus aguerris.

Dans un tel cas, les serveurs communautaires peuvent alors servir de sauvegarde, en cas de défaillance des serveurs personnels (ou vice-versa, les serveurs personnels pouvant redonder les serveurs communautaires).

Il est tout à fait imaginable d'avoir des petits serveurs Kinto pour chaque utilisateur, mais il va falloir procéder par étapes et défricher le terrain avant d'avoir un one click pour Tatie Jeannine.

La clé ici est sans doute l'essaimage : commencez à utiliser le serveur Kinto de Framasoft (ou autre) puis migrez vers votre propre serveur, une fois l'ensemble des problèmes techniques (évoqués précédemment) résolus.

En attendant, une approche reposant sur plusieurs communautés semble être une solution pragmatique sur le court/moyen terme, rendant certaines libertés aux utilisateurs et ouvrant la voie pour le futur.

Revenir au début