Google Buzz: le "Social Network Service" interopérable émerge!

[Je n'ai pas parlé de buzz lors de sa naissance: le web était "blindé" sur le sujet. Maintenant que l'agitation retombe, je peux y revenir. Mon article préféré sur le thème d'un point de vue utilisateur est celui de F. Cavazza: il donne la meilleure synthèse bien étayée du sujet]

Tim-Berners avait évoqué il y a plus de 2 ans la nécessité de l'émergence d'un GGG (Giant Global Graph) pour casser les silos informationnels actuels des Facebook, Twitter, LinkedIn et autres Xing qui nous imposent:

• soit un temps passé infernal à recopier son profil et les activités de son lifestream personnel de l'un à l'autre
• soit la mise en place de services en ligne multiples (et sans garantie de pérennité...) souvent "obscurs", en tout cas réservé aux geeks pour faire des passerelles plus ou moins solides entre tout ce petit monde
  

Un tel système n'est pas tenable à terme: les internautes vont se lasser de gaspiller une telle énergie pour tenter d'échanger leurs états d'âmes ou photos avec leur proches et connaissances.

En annonçant Buzz, Google a fait des choses en profondeur qui n'ont pas encore été discutées: il a jeté les bases du "Social Network Service" interopérable précédemment évoqué.

Bien sûr, en surface, il y a aussi l'envie de lutter contre Twitter et Facebook qui sont les 2 fers de lance (actuels) du micro-blogging social. [Et bien sûr, vu le domaine, il y a eu les soucis de jeunesse sur le sujet de la sphère privée]

Mais, ainsi qu'il le fait actuellement avec succès pour le monde du mobile, Google préfère l'hégémonie lente au ko rapide. En effet, l'hégémonie lente lui amène au mieux ce qu'il recherche en premier lieu: une utilisation plus grande de l'internet qui fait prospérer son coeur de métier (la publicité = 98% de ses revenus). C'est le même but qu'il réalise parfois par une autre moyen: la destruction créatrice (cf Feedburner, etc.)

Pour maximiser cette utilisation du web, Google a donc mis en action une multitude de protocoles ouverts ui sont destinés à restituer sous une forme programmatique toutes les informations disponibles sur ce contenu Buzz: QUI a crée QUOI depuis OU, etc... Il souhaite ensuite qu'une armée de développeurs tiers (comme chez Amazon...) bâtissent des services innovants générant donc une utilisation maximum.

Les protocoles standards mis en action sont les suivants:

[je vous laisse chercher les points d'entrée vers la foultitude de protocoles ci-dessous. Si vous ne les trouvez pas, contactez-moi]

• les flux des utilisateurs de Buzz sont intégralement publiés en temps réel sous forme de flux Atom. A chaque Buzz est par ailleurs associé un autre flux Atom: celui des commentaires sur ce buzz. Des mécanismes de découvertes sont inclus pour permettre de retrouver ces flux alors même qu'ils peuvent être en provenance de multiples machines totalement distribuées sur l'Internet. Pas de création de monopole possible...
• les mises à jours sont pilotées par le protocole Pubsubhubhub afin d'éviter que dans une telle (future) architecture distribuée tout le monde crawle tout le monde ne permanence...
  
• la sémantique de ces flux est très élevée: ils sont enrichis d'éléments descriptifs du protocole ActivityStrea.ms pour définir au mieux les actions de l'utilisateur. Les éléments multimédia sont décrits sémantiquement par le protocole MediaRss
  
• les données de profil de l'utilisateur sont décrites par le protocole WebFinger associé à PortableContacts, SocialGraph API, aux microformats, etc...
• le flux des commentaires autour d'un article publié et re-publié vont se trouver davantage dispersés. Le protocole Salmon est là pour les faire percoler à 100% (quel que soit leur lieu d'émission) vers la source et tous les points de publication intéressé.
  
• la partie privée de Buzz est protégée par OAuth qui permet une délégation d'accès aux informations sans risque
• etc...

Dès que j'ai un moment, je vous fait un graphique combiné montrant la conjonction de tous ces protocoles. J'y reviens rapidement, c'est promis!

Cette conjonction de protocoles est très intéressante: elle permet (au moins en théorie... et au prix d'une bonne infrastructure et de pas mal de développements) de pouvoir reconstituer, pour son propre service, un miroir intégral des données publiés dans Buzz et de tous les clones ou concurrents qui se mettront à respecter ces mêmes standards.

Une vraie démarche ouverte dès la genèse du service en quelque sorte! Et ce alors que cette ouverture est encore souvent conçue comme un moyen ultérieur de catalyser le développement d'un service quand ses moyens propres et propriétaires ne lui permettent plus de croître de manière endogène.

Une autre conséquence intéressante de cette démarche: ses concurrents (Twitter, Facebook, etc.) vont certainement devoir aussi réviser - quand Google Buzz aura un peu grandi: si l'on part du principe que 9 millions de buzzes d'utilisateurs Buzz en 2 jours, c'est petit.... - leurs positions très propriétaires actuelles en termes de formats et de protocoles et les contraindre à s'ouvrir.

Un bien pour nous autres internautes certes mais pas forcémment un bien pour ces services car leur modèle d'affaires (actuel) est basé sur un étroit contrôle du contenu généré par leurs utilisateurs alors que ce sont finalement ces utilisateurs qui en ont les propriétaires.

Conclusion: bien joué, Mr Google! Sa taille de l'ordre de grandeur de l'Internet lui-même et sa profitabilité lui permettent d'avoir une stratégie de croissance propre parfaitement alignée avec la plus grande masse d'acteurs de l'Internet et d'avoir aussi la patience de la mettre en oeuvre. En l'appliquant, de plus, il plante en plus systématiquement ses banderilles sur ces adversaires en les forçant à bouger dans des directions désagréables pour eux.

PS: en tant qu'utilisateur, je vois 3 avantages initiaux majeurs à Google Buzz par rapport à ses concurrents:

• pas de limite de taille: on peut se tenir aux 140 caractères de Twitter mais on peut aussi faire plus bavard si on voit qu'il y a un créneau sur Buzz pour la volubilité
• flux multimédia: Twitter impose un clic vers un service idoine pour aller voir une photo qu'un utilisateur voulait associer à son tweet. Dans Google Buzz, le multimédia (photos, vidéos, etc... ) intégré dans le texte.
• commentaires attachés: le service Twitter basique (sans l'utilisation de client sophistiqués) impose une gymnastique fastidieuse de rebond entre les différents flux des intervenants d'une conversation. Dans Google Buzz, si je lis un billet initial, je vois juste en dessous les commentaires associés.
  

Source: blog Media & Tech (par didier durand)