J'ai eu le plaisir de participer à l'[IndieWebCamp](http://indiewebcamp.com/) à Portland le mois dernier, une conférence de style BarCamp où des techniciens se réunissent pour réfléchir à des idées sur la façon dont ils peuvent aider les gens à posséder et à contrôler leur identité en ligne.

Le soi-disant mouvement Web indépendant, cousin spirituel des mouvements open source et normatif, est enraciné dans un désir de liberté numérique, principalement face aux monopoles qui menacent de restreindre et de violer l'existence en ligne de l'internaute moyen. Il appelle à des moyens pratiques pour protéger cette existence en empêchant ou en perturbant le contrôle qu'une entreprise exerce sur l'identité en ligne d'une personne, que ce soit du point de vue des fonctionnalités ou des données.

C'est un mouvement qui suscite la réflexion pour un certain nombre de raisons, notamment parce qu'il se retrouve en train de crier contre le vent, pour ainsi dire. La plupart des utilisateurs d’Internet, avec la prolifération des réseaux sociaux, confient de plus en plus leur vie numérique à des services propriétaires gérés par des entreprises pour la plupart privées – et toujours intéressées. Ces utilisateurs ne possèdent pas l'identité et le contenu qu'ils publient sur ces services d'une manière qui les isole de leurs vagues conditions de service et de leur application. Ils ne peuvent pas non plus continuer à bénéficier de ces services (au moins de la même manière) si les entreprises les ferment, les redessinent de manière indésirable ou ne parviennent pas à les améliorer. Pourtant, seule une petite minorité d'utilisateurs s'inquiète activement de ces problèmes et généralement seulement après avoir été piqués par la désactivation de compte, des temps d'arrêt incessants, la censure, des fuites de confidentialité ou des défauts de conception critiques.

Il y a un ton moral dans le mouvement du Web indépendant, et pas seulement une insistance sur le fait que les utilisateurs doivent contrôler leur identité en ligne dans le but pratique d'éviter les conflits avec leurs fournisseurs de services. Les partisans soutiennent qu’Internet doit conserver sa nature décentralisée et résister aux consolidations de pouvoir, de peur que le progrès technologique ne soit entravé, que les données ne soient perdues, thésaurisées ou corrompues et que les utilisateurs ne soient massivement privés de leurs droits. Il y a une tension ici, puisque les entreprises privées qui traitent leurs utilisateurs comme des [métayers virtuels](http://nomoresharecropping.org/) sont clairement responsables d'une grande partie des progrès réalisés sur le Web aujourd'hui, et leurs services facilitent considérablement la participation en ligne pour tout le monde, y compris les analphabètes techniques.

Deux défis particuliers se sont posés au mouvement du Web indépendant qui m'ont frappé en assistant à la conférence. Le premier concernait l’identification des besoins pertinents et reconnaissables de l’internaute moyen afin d’obtenir un meilleur contrôle sur son identité en ligne. Les partisans du Web indépendant déposent un nombre disparate de plaintes valables contre des services propriétaires, chacune ayant ses propres mérites, mais aucune ne serait reconnue par le grand public comme un problème massif et immédiat en soi.

[Tantek Çelik](http://tantek.com/), l'organisateur principal de la conférence et mon aimable hôte, a cité le fameux temps d'arrêt de services comme Twitter et Tumblr comme raison de la décentralisation, ainsi que la tendance des services acquis à être fermés. D'autres ont évoqué le désir d'exporter et de gérer plus facilement le contenu qu'ils publient sur les services afin qu'il puisse être utilisé sur leurs ordinateurs personnels et publié ailleurs sur le Web. Pour d’autres encore, il s’agissait avant tout d’une question de personnalisation et de possibilité d’interagir avec de nombreux services en ligne et leurs fonctionnalités respectives avec plus de flexibilité et de fluidité.

Tous ces problèmes sont mieux articulés par les technologues qui prennent le temps de les comprendre, mais sont sûrement également ressentis par les « normaux ». Ces problèmes ne semblent cependant pas suffisamment présents à l'esprit pour contraindre des millions d'internautes ordinaires à prendre des mesures concrètes pour y remédier, du moins avec les solutions actuelles. Les temps d'arrêt sont frustrants, mais la plupart des gens apprennent à les contourner ; les services fermés déçoivent les utilisateurs fidèles, mais ont très probablement été confrontés à leur disparition en raison du désintérêt populaire ; et la plupart des gens ne savent pas ce qu'ils attendent d'autre des services qu'ils utilisent, du moins suffisamment pour rechercher des solutions alternatives.

Cette complaisance pose un problème de motivation crucial pour le scénario de décentralisation primaire proposé par les acteurs du mouvement Web indépendant, dans lequel les utilisateurs (aussi bien les premiers que les derniers adoptants) prennent l'initiative d'héberger leur identité et leur contenu personnel indépendamment de tout service propriétaire. L'idée ici est que chacun devrait enregistrer son propre [domaine de deuxième niveau](http://en.wikipedia.org/wiki/Domain_name) et créer un site Web personnel, tout comme j'ai enregistré markmhendrickson.com et y ai centralisé mon identité en ligne. Ce site peut être une présence simple et statique ou suffisamment avancé pour échanger des informations avec des services propriétaires afin que des interactions puissent avoir lieu avec des amis ou des abonnés. Théoriquement, ces services propriétaires pourraient disparaître complètement au fil du temps, et des sites Web personnels indépendants pourraient commencer à communiquer directement entre eux, cartographiant ainsi efficacement les relations des réseaux sociaux sur Internet de manière distribuée et peer-to-peer.

En plus du défi marketing consistant à obliger les individus à créer ces sites indépendants, il y a le défi technique de donner vie à ce système distribué et de permettre aux gens normaux de s'impliquer. Le défi technique peut être divisé d’une part en problèmes d’infrastructure liés à la décentralisation des communications en temps réel qui ont actuellement lieu au sein de services centralisés (comme l’établissement de relations sociales, la publication de contenu sur des flux et l’interaction avec ce contenu). De l'autre côté, il y a les problèmes techniques liés à l'installation de chaque utilisateur au sein du système décentralisé et à la garantie qu'il dispose des outils nécessaires pour participer sans être lié à un seul fournisseur.

Chaque participant à l'IndieWebCamp a passé la deuxième journée de la conférence à travailler sur un projet de son choix qui aiderait le mouvement. J'ai pris sur moi de concevoir un outil qui résoudrait peut-être la seconde moitié de ce défi technique tout en communiquant aux utilisateurs traditionnels pourquoi ils devraient créer leurs propres domaines. Mon projet était principalement centré sur l'utilisateur, car il différait de nombreuses décisions d'ingénierie complexes de la décentralisation et se concentrait plutôt sur la motivation des utilisateurs à surmonter leur complaisance par défaut et à innover sur leur propre propriété en ligne.

J'ai établi plusieurs exigences principales pour cet outil :

- Il devait simplifier pour les utilisateurs le processus d'enregistrement d'un nom de domaine et d'un hébergeur de base, qui devaient tous deux être traités comme des marchandises et substituables à tout moment. Bien qu'il ne soit pas possible ou faisable pour les utilisateurs de posséder littéralement leur domaine et leur hébergement, la meilleure chose à faire est de minimiser le pouvoir de différenciation de ces services en les faisant abstraction.

- Il devait automatiser le processus de création d'un site Web initial, ou propriété, sur le domaine et l'hébergeur nouvellement enregistrés, ainsi que d'automatiser les processus de mise à jour ou d'extension ultérieure. Alors que le logiciel du site Web devait être entièrement hébergé par l'utilisateur et open source pour un contrôle maximal, il pouvait être assisté par l'outil de manière continue via des poussées de code et de données.

- On ne peut pas s'attendre à ce que l'utilisateur utilise FTP, une interface de ligne de commande, un système de fichiers ou toute autre technologie au-delà du navigateur, car cela limiterait considérablement son accessibilité. Les interactions des utilisateurs devaient se limiter à remplir des formulaires Web et à cliquer sur des éléments.

- La charge financière et temporelle liée à l'utilisation de l'outil pour créer et entretenir une ferme devait être minimisée autant que possible.

- Il ne peut pas être demandé aux utilisateurs de saisir à nouveau leurs informations personnelles ou de télécharger manuellement le contenu qu'ils ont déjà partagé ailleurs.

![Filaire de l'expérience utilisateur initiale de l'outil de homesteading]()

L'expérience utilisateur initiale de l'outil est décrite par le wireframe ci-dessus. Le marketing fait directement appel au besoin de contrôle d'une personne, puisque c'est en fin de compte ce que les utilisateurs sont censés obtenir dans un système décentralisé, il résonne probablement avec une peur sous-jacente que leur identité en ligne actuelle soit en désordre, et c'est une proposition suffisamment vague pour permettre de nombreux détails de solution.

La page répond ensuite à quatre des besoins les plus identifiables sous le couvert du contrôle de son identité en ligne. L'obtention d'une URL personnelle permet à un utilisateur de diriger plus facilement les personnes vers ses informations en ligne ; le classement d'informations personnelles bien organisées en bonne place sur Google permet à un utilisateur de contrôler ce que les gens découvrent à son sujet lorsqu'ils recherchent leur nom ; répertorier tous les profils de réseaux sociaux d'un utilisateur en un seul endroit met de l'ordre dans la fragmentation de l'identité ; et la sauvegarde du contenu en ligne d'un utilisateur à partir de nombreuses sources offre une tranquillité d'esprit. La zone en bas qui répertorie les sites Web d'autres personnes est destinée à fournir une validation sociale à ces propositions.

Pour commencer, l'utilisateur doit saisir simplement l'URL souhaitée, une adresse e-mail et un mot de passe (l'URL souhaitée étant vérifiée par rapport à l'API d'un registraire de domaine, en supposant qu'il en existe une). Les demandes d'autres valeurs, telles que le nom de l'utilisateur, sont omises car elles peuvent être collectées ultérieurement auprès de l'utilisateur. L’objectif ici est de les amener à s’engager dans le processus de configuration de la manière la plus simple possible.

![Filaire de l'étape de connexion au service]()

Après avoir saisi ces informations de base, l'utilisateur est invité à connecter sa nouvelle propriété à un certain nombre de ses services en ligne. Un lien vers chacun de ces services, une fois connecté, apparaîtra sur la propriété de l'utilisateur. Le contenu qui y est publié peut également être extrait, une fois ou continuellement, pour être réaffiché ou simplement sauvegardé sur la propriété de l'utilisateur, selon le type de service dont il s'agit.

Par exemple, lorsqu'un utilisateur connecte son compte Facebook, il peut choisir que toutes ses photos et mises à jour de statut soient automatiquement republiées sur sa propriété. Les options possibles pour simplement les sauvegarder mais pas les republier ne sont pas affichées. En se connectant à l'un de ces services, l'outil peut également déterminer automatiquement le nom, le portrait et tout autre détail de l'utilisateur à afficher sur la propriété.

![Wireframe de l'étape de paiement du domaine]()

La dernière étape de configuration consiste à payer réellement l'URL souhaitée, en supposant que l'outil puisse organiser un hébergement gratuit. Cette partie de la maquette n'est pas très détaillée, mais fondamentalement, la page afficherait le formulaire approprié une fois que l'utilisateur aurait choisi son mode de paiement préféré.

![Wireframe de la page de profil de propriété résultante]()

Le résultat est une page de profil pas très différente de celles que l'on trouve sur la plupart des sites de réseaux sociaux, mais hébergée sur le propre domaine de l'utilisateur et composée d'informations sur et provenant de l'utilisateur provenant de diverses sources. Leurs profils de service apparaissent à gauche avec leur portrait et leur biographie, et le contenu qu'ils ont décidé d'importer dans leur propriété apparaît regroupé à droite.

Ceci n’est censé être qu’un début. Il existe un certain nombre de façons d'améliorer la conception et la fonctionnalité de la propriété d'un utilisateur donné. La mise en page et le thème peuvent être personnalisables. L'utilisateur pourrait ajouter la possibilité de publier du contenu directement sur sa propriété, puis de le diffuser sur d'autres services. Ils pourraient même commencer à créer des liens avec d’autres colons en les ajoutant comme amis ou autre, tous référencés par leurs propres URL.

Peut-être qu'un écosystème open source pourrait même émerger, fournissant des plugins et d'autres modifications au progiciel de base, permettant finalement des expériences sociales qui rivalisent avec celles des services propriétaires, avec des flux, des messages, des balises et bien plus encore. La principale réussite serait de permettre à un grand nombre de personnes de revendiquer une présence en ligne indépendante avec le potentiel de jouer un rôle croissant dans leur vie en ligne. Une fois qu'un nombre suffisant de personnes l'auront fait, il sera beaucoup plus facile de tisser une toile indépendante entre leurs propriétés et de les isoler des décisions ou du sort d'une entreprise particulière.