Une des facettes du Web 2.0 est la capacité pour tout utilisateur de partager des données et en retour de profiter des données partagées par les autres. Pour autant, un point me gène particulièrement, c'est le contrôle que je peux avoir sur les données que je stocke sur différents services. Je n'aborde pas ici la partie contrôle sur l'utilisation, je pars du principe que dès lors que c'est sur internet, cela peut être bien utilisé (respect des licences, etc) ou bien très mal. Sur ce sujet là, si vous voulez tout controler, ne publier rien ! L'idée est ici de voir dans quelle mesure je suis maitre de mes données.
Sur cette base, on peut dresser une typologie des services web 2.0 de deux types :
- Les bons services web 2.0 qui permettent un contrôle total sur les données que j'ai produites
- Les mauvais services web 2.0 sur lesquels je n'ai aucun contrôle sur les données que j'ai produites.
Comment différencier ses services ? Je la fais de la façon suivante : si le service venait subitement à disparaitre, qu'est ce qu'il me reste sur le volume de données que j'ai pu produire sur le dit-service.
Parmi les services que j'utilise, je vais avoir :
- Dans le panier des bons services : des services comme Flickr ou Dailymotion ; les données présentes sur le service ne sont qu'une copie des données présentes sur mon PC et précautionneusement sauvegardées.
- Dans le panier des mauvais services : quasiment tous les autres : Del.icio.us, Pownce, Twitter, 6nergies, Linkedin, Viadeo, Copaing, Amazon, Google Reader, Google Apps, etc. Certains sont "moins pire" que d'autres dans la mesure où ils proposent des services d'export mais bon sérieusement, qui fait une sauvegarde régulière de ces données sur ces sevices ? Pas moi et à mon humble avis, je suis loin d'être le seul.
Il ne sert à rien de parler des bons ici, surtout que leur mode de fonctionnement implique que l'on ait la donnée source sur son PC.
Parmi les mauvais services, on peut creuser un peu plus la disctinction :
- Je n'offre aucune porte de sortie à mon utilisateur : 6nergies, Viadeo, LinkedIn, Copaing, Twitter, Pownce, ... Là, le modèle est clair, on vous veut à tout prix et une fois entré dans le service vous n'en sortez plus ou en tous cas, pas sans perte (vos fameuses données que vous avez saisi).
- J'offre un export dans un format ouvert mais avec une structure à ma sauce : on va retrouver del.icio.us qui propose un export html de ses favoris. On peut donc quitter le service (vu que c'est un format ouvert) mais faut prier qu'un importateur existe si on va vers un service tiers
- je m'appuie sur des formats ouverts, structurés et directement réutilisable dans un service tiers : blogmarks, google reader par ex avec des formats xml/opml ou google calendar avec l'export au format ical ou xml. Comme pour l'exemple précédent, on a des formats ouverts et structuré mais avec en plus une notion de définition/schema liés à des normes établies (et non propre au service), L'utilisation de ces données est dès lors possible aisément par tout outil capable de gérer de l'opml ou de l'ical par ex.
Il est évident que je vais préférer le troisième type de service par rapport aux deux autres. C'est d'ailleurs une des raisons pour lesquelles j'utilise Google Apps pour certains de mes domaines. Il est très facile de s'en séparer. Les seules pertes pouvant se faire lors de la migration vers une solution de mail / calendrier / aggrégation classique. A ce titre, il faudrait que je vérifie si gtalk permet une sauvegarde de ses contacts pour pouvoir être utilisé via un autre client/compte jabber par ex. J'utilise donc d'autant plus facilement ce type de service que je peux facilement en changer (ça me rappelle un des principes de l'intégration réversible tout ça).
Il me reste donc à régler le cas des deux premiers types pour avoir la main sur mes contenus. Certains diront qu'il existe une déclaration des droits de l'utilisateur du web social. Cette partie est rassurante mais pour autant pas tout à fait satisfaisante. Par contre, je rejoinds tout à fait l'analyse de David et les meta-applications ne sont qu'un élément de réponse sur la partie interopérabilité.
J'allais dire qu'il faudra admettre que pour certaines applications, on ne puisse pas contrôler les données dans leur intégralité. Cette phrase est en fait innaceptable. A court terme, oui on ne pourra pas le faire et l'exemple parfait est les réseaux sociaux, ceux là même qui ont porté les débuts du web 2.0. A moyen terme, cela ne devra plus être acceptable. On devrait pouvoir publier une seule fois son cv et le diffuser sur toutes les applications... Aie, j'en ai déjà trop dit...
Pour le formaliser, je verrais donc bien la solution suivante :
- Centralisation de ses données dans un "dépot"
- Gestion de la publication de ses données sur différentes services - l'inscription au service ne consisterait dès lors qu'à se doter d'un compte (ou donner son compte openid) et d'indiquer l'url de la ressource à utiliser.
- Les spécificités d'un service (ex le champ X ne fait pas partie des champs de base chez 6nergies mais existe chez Linkedin) seraient gérées dans son dépot. Il suffirait de mettre des attributs propre au service autour de la donnée à utiliser.
- Le service peut aspirer les contenus de votre dépot pour des problématiques de performance, cache, partage, etc mais à tout moment vous pouvez le retirer. Ex : on peut imaginer que je publie mes favoris gérés depuis mon dépot sur del.icio.us. Bien sur, del.icio.us a besoin de les stocker et de leur associer des propriétaires (comme actuellement en fait). La seule différence tiendrait à ce que c'est mon dépot qui pousse les favoris vers del.icio.us et non moi directement depuis mon extension firefox. del.icio.us ne serait alors qu'une réplication des contenus de mon dépot.
- Le service doit aussi permettre de pouvoir synchroniser dans les deux sens. Si mon dépot tombe, je dois pouvoir récupérer mes favoris depuis del.icio.us pour les réimporter (je rêve peut être un peu là, mais soyons fous).
Délirant ? Pas du tout et c'est déjà en place pour certaines fonctionnalités. Rappelez-vous les trackbacks. Ce ne sont après tout que des commentaires postés depuis un dépot (son propre blog) et sur un blog distant. Il suffit "juste" de structurer un peu mieux le concept et de gérer le spam.
Qu'est-ce qu'il nous fait pour faire tout ça :
- A minima du RSS - on a déjà
- ... ou une architecture REST si on est plus exigeant - on a plus ou moins
- Des formats ouverts de typologies de contenus : RDF, XML, FOAF, bref tout ce qui a trait au
Web 3.0 Web Sémantique
- De l'authentification : OpenID
- Des services ouverts : bon là, c'est la misère pour le moment
Seule l'utilisation d'une architecture ouverte et de formats ouverts peut permettre la réussite d'un tel projet.
Certains pourraient dire à juste titre : certes mais alors pour un del.icio.us, quelle est leur valeur du coup ? quel est leur intérêt de fonctionner ainsi ? Ils auraient toujours des utilisateurs et des données. Seul le mode de contribution change. Ce nombre et ces données peuvent d'ailleurs augmenter puisqu'il est dès lors facile de s'inscrire à tous les services de bookmarking social.
Une fois dit tout ça, on voit que l'on contrôle à nouveau alors l'ensemble de ses données et leur publication. Personnellement, c'est la raison d'être du projet Atome que je compte bien batir sous peu (une fois que MvMo sera un peu plus stabilisé et publié). Atome ne sera certainement pas tout ce que je souhaite plus haut dans un premier temps. La seule chose sur est qu'il sera mon dépôt de données pour mon blog, un peu de micro-blogging, mes favoris, le wiki et peut être quelques snippets.Pour le reste, on verra en temps et en heure...
Le seul truc qui me chiffone pour le moment, c'est que je n'ai pas réussi à intégrer du Jabber dans tout ça et notamment la partie pubsub. Mais bon, ça devrait venir... 
Edit 1 : Edition suite au commentaire de Leviathan.