Un Electron Libre... - Tag - web 2.0

Quel avenir pour les applications web libres ?

NiCoS — Sat, 01 Dec 2007 00:00:00 +0100

David nous demande notre avis sur le futur des applications web libres. Je me prête au jeu

Vous avez dit application web libre ?

Il faut avant tout distinguer 2 cas :

Une application web distribuée sous une licence libre,
Une application permettant à ses utilisateurs d'aller et venir librement en proposant des capacités d'import/export basées sur des standards ouverts et ausein desquelles il peut controler ses données.

En posant cette question à David, celui ci a répondu :

Libre dans le sens Logiciel Libre, ce qui implique généralement des formats de données standards et interopérables.

Mon avis est assez mitigé sur sa réponse :

Une application libre ne veut pas forcément dire qu'elle est interopérable et s'appuie sur des standards. Même si pour des libristes convaincus cela va de pair, je ne suis pas certain que cette relation se vérifie systématiquement.
Une application distribuée sous licence propriétaire peut tout à fait s'appuyer sur des standards et être interopérable.

Personnellement et comme j'ai déjà pu l'aborder lors de mes réflexions sur les outils de bookmarking sociaux ou sur les données que l'on aime tant (Partie 1 & Partie 2), je suis avant toute chose pour la liberté de l'utilisateur et dans sa capacité à contrôler ses données à tout moment. Que l'application soit distribuée sous licence libre, je dirais que cela arrive au second plan. Je pourrais même dire que c'est du bonus.

Facebook, la prise de conscience du public (ou pas) ?

Une partie du net s'est offusquée de l'utilisation des données des utilisateurs de Facebook à des fins commerciales (publicité, etc). Maintenant, que représente cette partie du net face à l'ensemble des utilisateurs ? A mon humble avis, une goutte d'eau dans cet océan. La quasi-totalité des utilisateurs ne se pose même pas la question et se contente de profiter des services offerts, imaginant que Facebook offre son service gracieusement et de façon désintéressée. Pourtant, faut vraiment être naif pour ne pas se rendre compte que le seul business model des services web 2.0 tient à la capture d'un utilisateur et à leur capacité à en connaitre un maximum sur ce-dernier afin de pouvoir monayer cela auprès d'annonceurs et investisseurs potentiels. Rien n'est gratuit en ce bas monde et encore moins sur le net.

Bien sur on ne peut que souhaite qu'un maximum de personne soit sensibilisé à ces problématiques de contrôle de ses données, il serait naif de croire que cela arrivera tout de suite. C'est un peu comme le paradgime logiciel libre vs logiciel propriétaire. Certains commencent à peine à se rendre compte des limites et de la dépendance que cela entraine (mais l'iPhone va nous aider) . Certains s'en contentent, d'autres pas du tout et certains y viendront progressivement quand les solutions libres seront plus matures ou que la migration d'une solution propriétaire vers une solution libre sera peut couteuse (en terme de temps, prise en main, coût, etc).

Application web libre, vers un internet de confiance ?

Le scandale de Facebook n'est qu'une des manifestations de cette méfiance vis à vis des services du Web 2.0 que peuvent entretenir certains. Même si une déclaration des droits des utilisateurs de services Web 2.0 a vu le jour, je doute qu'elle soit réellement appliquée dans les faits. En outre, ce n'est pas forcément compatible avec les modèles économique de ces services.

A l'inverse, une application web garantissant la liberté de ses utilisateurs telle que définit précédemment permet de commencer à batir un internet de confiance dans lequel chacun est maitre de ses données et peut évoluer librement au gré de ses envies. Cela peut paraître utopique, mais cela commence à être réalisable. Les Open API (ou API ouvertes), l'utilisation de standards et de briques libres permettent petit à petit de créer de telles plateformes.

le SaaS frein ou accélérateur d'application web libre ?

SaaS pour "Software as a Service" que l'on peut assimiler aux applications hébergées vont-elles pousser ou freiner ce passage vers des applications web libres ? Là encore, pas évident de trouver une réponse fiable. De nombreux SaaS existent dans un mode propriétaire et fermé. A l'inverse, certains cherchent à partir sur des formats ouverts (Google Docs par ex) pour tenter de capter le marché. Je dirais alors que le passage ou pas vers des applications web libre dépendra de la valeur du service et de sa portée. Elle pourra rester sur un mode propriétaire et fermé tant que sa valeur ajoutée est forte. Par contre, pour des besoins courants, il lui faudra impérativement être ouverte et basée sur des standards.

Un ou plusieurs avenirs ?

Je vois plusieurs avenirs pour les applications web libres :

A court terme et comme tout mouvement, cela se développera chez les plus utopistes, avant-gardiste, geeks existant sur cette planète. Les applications web libres auront un succès limité.
A moyen terme, si la prise de consicence se fait au niveau des masses, un engouement va commencer et les applications web libres vont se développer petit à petit.
A long terme, aura-t-on que des applications web libres ? un mix libre et propriétaire ? Tout comme pour la couche système d'exploitation et logiciel je pense que le libre est l'avenir, cela mettra du temps à se faire et si une application propriétaire utilise des standards et est interopérable, alors elle aura tout à fait sa place. Par contre, une application propriétaire et fermée est condamnée d'avance. On le voit déjà aujourd'hui avec l'arrivée d'OpenSocial. Point de salut pour un service Web 2.0 sans une API ouverte.

En conclusion : oui y a un avenir pour les application web libres selon moi, même si c'est pas forcément gagné d'avance

Hors Série Courrier International : "Révolution 2.0 : Comment le Net va (encore) changer votre vie" chan

NiCoS — Fri, 26 Oct 2007 10:20:00 +0200

J'ai profité de ma descente la semaine dernière pour acheter le Hors Série de Courrier International : Révolution 2.0 : Comment le Net va (encore) changer la vie. Je m'attendais à ne rien apprendre et regretter d'avoir dépensé 7€ et bien non. Même si je ne l'ai pas encore tout à fait fini (j'avais du travail à faire mardi en allant à Bruxelles (oui, je me la joue Globe Trotter en ce moment :-P )), je ne peux m'empêcher de vous le recommander (même pour ceux qui connaissent le Web 2.0 en long large et en travers), car pour une fois, on ne parle pas que de technique, buzz & co.

Personnellement, j'ai bien aimé :

La partie historique et présentation des différents éléments constitutifs du web 2.0 (ajax, user generated content, podcast, réseau sociaux, wikipedia, etc). On notera quelques approximations sur la technique mais bon c'est pas un journal de geeks non plus
La forte conivence entre le logiciel libre et le web 2.0. Pour moi, cette conivence n'était pas aussi évidente. Je voyais plutot ça comme deux mouvements parallèles avec bien sur des interactions mais sans plus.
Le Web 2.0 et les enjeux en termes de développement (Afrique, projet OLPC, etc)
Le Web 2.0 et les démocraties/régimes totalitaires (Chine, Moyen Orient, etc)
...

Ce hors série donne un coté beaucoup plus humain/interessant au web 2.0 et rend le buzz plus supportable...

A lire donc...

Ces données qu'on aime tant... (suite)

NiCoS — Mon, 15 Oct 2007 23:17:00 +0200

La nuit portant conseil et surtout ayant du mal à m'endormir et en y réfléchissant de temps à autre ou en discutant avec Niko le midi, quelques petits compléments au précédent billet "Ces données que l'on aime tant...".

Après mure réflexion, seul Flickr est un bon service dans le sens où je l'ai exprimé. En effet, contrairement à Flickr, Dailymotion ne permet pas de récupérer la version originale de la vidéo. Et paf ! Vivement que flickr supporte les vidéos...

Ensuite, se pose quelques problématiques fonctionnelles :

Dans le cas où j'héberge mes commentaires dans mon dépot, il ne faut pas que je puisse les éditer, sous peine de fausser totalement la discussion. Cela doit fonctionner de la même façon qu'aujourd'hui, à savoir, une fois le commentaire posté, il n'est plus éditable.
Par contre, contrairement au système actuel, cela veut dire que le propriétaire du blog sur lequel je commente n'est plus en mesure d'éditer mes propos s'il les juge déplacé - normal, les contenus ne sont pas hébergés chez lui, il n'a dans le meilleur des cas qu'un "cache". Du coup, cela veut dire qu'il faut implémenter un système de retrait d'une ressource de la part du propriétaire du blog (sinon, c'est le spam et le box assurés).
Je ne dois pas pouvoir non plus supprimer un commentaire pour les mêmes raisons. Par contre, si le propriétaire du blog a retiré de son site mon commentaire, est-ce que cela a un sens de le laisser publié dans mon dépot, j'ai un doute.
A l'inverse, certains types de contenus doivent être révisables (articles, tutoriels, cv, etc). Les différentes versions doivent-elles alors être accessibles ou seulement la dernière ? Faut-il que l'url de la ressource contiennt alors une notion de "timestamp" ?
Comment permettre à un utilisateur de dire aisément quelle ressource il veut publier à tel ou tel endroit ? Pour un commentaire, je dois en effet dire que je veux poster un "commentaire" et à une certaine url. Faire un copier coller d'url va devenir vite rébarbatif. Il faudrait pouvoir capturer l'url du billet pour lequel je souhaite poster un commentaire et être ensuite orienté vers mon dépot où je choisit le type de ressource à publier. Pour des facilités d'écriture, on pourrait même imaginer afficher le billet que l'on veut commenter dans une frame visible depuis le dépot (au dessus ou en dessous de la zone d'écriture du fameux commentaire dans notre exemple).

Se pose aussi quelques problèmes techniques :

Il va falloir trouver en premier lieu des schema RDF ou assimilés correspondant à mes besoins et suffisamment générique pour que d'autres puissent aussi les utiliser. Si chacun se met à faire son propre format, c'est l'échec assuré. Si un membre d'un consortium me lit, ce serait sympa de proposer un draft de norme en la matière. Dublin Core donne déjà une base solide mais non suffisante. Je suis ouvert à toute suggestion de pointeurs utiles en la matière
L'importance du cache et de la synchronisation est primordiale. On ne peut pas aller chercher les contenus partout à chaque appel de page sous peine que tout s'écroule et d'avoir des temps de chargement de dingue. Le maillon faible serait alors le serveur non disponible / saturé / à faible bande passante.
Si edition il y a, et suivant si l'on utilise ou pas le timestamp, doit/peut-on fournir un différentiel ou bien prévenir de la mise à disposition d'une nouvelle version du contenu ? Doit-on faire en sorte que le lien renvoit alors vers la dernière version du contenu via des jeux d'url ? (j'ai du coup un doute sur le coté unicité d'une ressource à un instant t et que cette notion d'alias perturbe plus qu'autre chose)

Affaire à suivre...

Ces données que l'on aime tant...

NiCoS — Fri, 12 Oct 2007 23:03:00 +0200

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.

Le Web 3.0 est enfin défini :-)

NiCoS — Fri, 05 Oct 2007 09:45:00 +0200

Et non, le Web 3.0 ne sera pas le web sémantique comme on pouvait le lire ici ou là depuis quelques temps, ni la définition du web 3.0 de Google (Voir ici ou là ou encore là (perso, j'ai pas pris le temps de regarder la dite vidéo)).

C'est Jason Calacanis dans son billet "Web 3.0, the official definition"

Web 3.0 is defined as the creation of high-quality content and services produced by gifted individuals using Web 2.0 technology as an enabling platform

L'idée est que les services estampillées "web 2.0" ne sont plus une fin en soi mais un simple moyen, voir une commodités. L'autre différence tient au fait que les contenus sont évalués/triés pour faire ressortir des contenus à valeur ajoutée (ex : modération accrue des contenus chez wikipedia, contenus inéditables lorsqu'ils ont atteint un certain niveau de qualité/complétion, etc). L'expertise est donc un des mots d'ordre de ce web 3.0.

Personnellement, je dis : enfin, pas trop tôt ! J'en ai marre d'être submergé de contenus inutiles ou de passer des heures à trouver un contenu intéressant dans une masse ! Et si tant est qu'il faille donner un numéro à ce web, je lui aurais plutôt donner un Web 2.1 ou Web 2.0 SP1 ;-P

Edit du 8/10 :

Web 3.0 -- The Best Official Definition Imaginable, en réponse à J. Calabanis
Geek&Poke appuie là où ça fait mal : The Podnoses - Episode 23 - The Story Of The Web

L'après web 2.0, l'heure des meta-applications ?

NiCoS — Wed, 26 Sep 2007 10:30:00 +0200

Tout le monde est (à peu près) d'accord pour dire que :

Le web 2.0 est source d'une grande profusion d'application et de clones d'applications
L'utilisateur en a marre de devoir se réinscrire sur chaque nouveau service et d'y ajouter tout ses contacts.
Les passerelles inter-services existent pas/peu. Les ouvertures se font généralement vers des services annexes/complémentaires. Pourtant chaque service propose (ou proposera) une API ouverte permettant l'intégration de son service sur une page ou dans une application distante.c

Partant de ce constat, je suis étonné que personne n'ait encore développé de "meta-application" qui se positionnerait entre l'utilisateur et des services similaires. On pourrait imaginer par exemple une meta-application de micro-blogging qui envoie vos messages sur Twitter et Pownce. Certains me diront que des solutions existent pour qu'un propos de Pownce soit affiché sur votre compte twitter via Twitterfeed, dont le principe est d'envoyer sur twitter n'importe quel contenu disponible via un flux RSS. Je trouve que cette solution relève plus du bidouillage et fait en outre intervenir un troisième acteur chez lequel il faut avoir un compte (heureusement, dans le cas d'espèce, il a la bonne idée de s'appuyer sur une authentification OpenId.

Revenons donc à ma meta-application de micro-blogging. Le principe est simple : "Tout message entrée dans la-dite application serait alors envoyée vers Twitter et Pownce". Cet envoi se faisant via les API des services concernés (je sais, celle de Pownce n'est pas encore disponible, faites comme si c'était le cas...)

Regardons plus en détail ce que devrait gérer cette meta-application (liste non exhaustive) :

Gestion de compte :
- Gestion d'un compte au niveau de la meta-application (ou pas à la limite si c'est ma meta-application est une application desktop)
- Création d'un compte dans chaque service retenu par l'utilisateur et ce de façon transparente. L'idée est d'éviter que l'utilisateur ait à aller se créer un compte sur chaque service puis les rentrer dans la meta-application
- Si l'utilisateur a déjà un compte, il lui faut pouvoir rentrer ses informations de connexion
Envoi des messages :
- Gestion des spécificités de chaque service (ex : Pownce permet d'envoyer différent types de messages : note, lien, événement, fichier et ce sans limite de caractères; alors que Twitter a un type de message et limité à 140 caractères)
- Capacité à fournir une version "dégradée" des messages si les autres services ne gèrent pas les mêmes éléments (ex, un événement pownce sera traduit sous la forme d'un message simple twitter ou un message de plus de 140 caractères chez pownce est rendu sous la forme de n messages twitter, etc)
Gestion des contacts :
- Capacité à ajouter des contacts utilisant n'importe quel service de micro-blogging
- Capacité à afficher les messages des dits-contacts : simple intégration de flux RSS avec un soupçon d'authentification si on veut pouvoir accéder à des messages filtrés (message non public de Pownce ou messages protégés de Twitter

J'ai grosso modo fait le tour pour une version basique de cette meta-application et on voit bien en quoi elle résoud les trois problèmes mentionnés en début de texte.

D'un point de vue technique, cela ne me semble pas insurmontable à faire, la seule condition préalable étant l'existence d'une API ouverte et documentée mise à disposition par le fournisseur du service. Ces meta-applications pourtant tout aussi bien être déclinées en version full web qu'en version RIA, RDA (Rich Desktop Application - étonnant que wikipedia n'ait rien à ce sujet )

Ne jamais avoir confiance... jamais !

NiCoS — Mon, 05 Feb 2007 12:04:00 +0100

Un billet assez édifiant et à lire absolument, qui explique comment il est "facile" de hacker Netvibes.

Au-delà de l'exploit en lui-même, ce type de billet permet de se rappeler qu'il faut :

Mettre des mots de passe surs et différents d'une application à une autre et qu'il faut les changer régulièrement (alors que la solution de facilité est de mettre le même partout, un simple de préférence et surtout jamais le changer). Personnellement, j'ai choisit une solution intermédiaire en fonction de la criticité du type de compte. Pour les applications que je juge non critiques, le mot de passe est souvent le même et plus on monte en criticité, plus les mots de passe sont complexes (les membres hébergés sur le serveur râlent d'ailleurs à ce sujet régulièrement :-P )
Ne jamais stocker des informations sensibles à des endroits facilement accessibles (le cas des mots de passe vers les applications de dev dans la zone de notes de netvibes est le meilleur exemple de ce qu'il ne faut pas faire)
Ne pas faire confiance à un services tiers, que ce soit sur sa sécurité, sa politique de sauvegarde, etc au risque d'avoir de mauvaises surprises. Il vaut mieux ne compter que sur vous même (et c'est là où vous vous sentez bien seul en réalisant que vous n'avez aucune sauvegarde de vos données...).

Prudence est donc de mise...

Signé, Nicolas, qui vient de rechanger quelques mots de passe :-P