Remerciements à Sophie qui a prêté sa charmante voix et à Rivel pour sa superbe musique publiée sous licence Creative Commons.

Comment faire, donc, pour réunir le monde « en ligne » et le monde « en dur » ? Quelle interface, quelle passerelle, permettra de passer de l’un à l’autre ? La réponse semble évidente, il faut introduire dans le monde en ligne la composante la plus importante du monde matériel, l’espace géographique bien sûr ! On pourrait donc avoir une interface ressemblant à une carte, telle Google Maps, ou à un monde 3D, comme Second Life mais avec le réel comme matière première plutôt que l’imaginaire. Ajoutons la géolocalisation par GPS (ou autre) et imaginons des solutions pour faire des choses aussi évidentes que d’afficher le site web correspondant à l’endroit où nous sommes, ou encore, moins évident mais tout aussi pratique, consulter le plat du jour des restaurants alentours. Les communicateurs apporteront donc, en plus du mode de navigation classique, un moyen d’accéder à l’information en partant d’une représentation physique du monde, réconciliant peut-être ainsi le réel et le virtuel.

Mais il existe une autre composante essentielle qu’il ne faudrait surtout pas négliger, c’est le temps. Comme dans le monde réel, rien n’est permanent sur le web, les choses changent, tout peut se transformer à chaque instant. Les communicateurs proposeront donc des mécanismes de navigation dans le temps afin de répondre à des questions du type de « quel était donc ce restaurant à la place de cette boulangerie ? » ou « quelle pièce ce théâtre présentera-t-il cet été ? » ou bien encore « cette photo a été retouchée, quelle était donc la version précédente ? ».

Je dois maintenant aborder des aspects un peu plus techniques afin de montrer brièvement comment tout cela pourra fonctionner. Où les données seront-elles stockées ? Que deviendront les fournisseurs d’accès et les acteurs du web en général ? Pour répondre à la première question, je dirais presque une évidence, les données des gens devraient pouvoir être stockées par les gens eux-mêmes. Les communicateurs seront donc en mesure de stocker des données et de les diffuser à d’autres communicateurs, sans aucun intermédiaire, à la manière d’une architecture P2P. Cela dit, pour des raisons pratiques, on confiera souvent le stockage des données à un fournisseur tiers, mais ce dernier n’aura rien à voir avec un YouTube ou un Flickr, ce sera plutôt une sorte de disque dur distant, un « datastore » personnel, stockant indifféremment tous les types de données. Ce service pourra être proposé par les fournisseurs d’accès ou par tout autre acteur. D’autre part, on aura la possibilité de déplacer ses données à tout moment d’un fournisseur à l’autre, et cela sans « casser » les éventuels liens qui pointeraient vers ces données. À cet effet, une distinction sera faite entre l’adresse physique d’une donnée et son adresse logique qui servira de référence. Les adresses logiques pouvant quant à elles être données par les fournisseurs d’identités numériques, les seuls acteurs auxquels on sera véritablement attaché puisqu’en changer reviendrait à changer d’identité. Mais là encore, on pourra être totalement autonome si on le souhaite en hébergeant son propre serveur d’identité.

Voilà pour le stockage des données mais il faut aussi se demander qui prendra en charge les éventuels traitements réalisées sur lesdites données ? Car il faut bien des traitements pour créer, modifier et faire toutes sortes de choses intéressantes avec les données. La solution envisagée, une fois n’est pas coutume, offre un maximum de liberté : les traitements pourront se faire partout. À la fois localement, dans nos communicateurs faisant tourner toutes sortes d’applications, mais aussi à distance, les traitements pouvant alors être pris en charge par des services tiers auxquels on aura donné des droits d’accès à nos données.

Tout cela commence à prendre forme mais il manque une dernière pierre à notre édifice. On peut voir sur le web un certain nombre de sites qui font des choses intéressantes en agrégeant des quantités plus ou moins importantes de données. C’est le cas des moteurs de recherche bien sûr, mais il y a aussi tous les sites, tels que YouTube, qui offrent des fonctionnalités communautaires en s’appuyant sur les données qu’ils nous proposent d’héberger. On peut alors se demander ce que deviendront tous ces sites si le stockage des données se fait directement dans les communicateurs ou dans une myriade de « datastores » indépendants ? C’est ici que les datahubs entrent en scène ! Pour réaliser un moteur de recherche ou un YouTube, il suffira de mettre en place un datahub afin d’agréger toutes les informations qui nous intéressent. Peu importe où les données sont stockées, si elles sont publiques elles se propageront à travers les datahubs, et tout le monde pourra jouer avec !

C’est ainsi que se termine cette première série d’articles consacrés aux communicateurs. J’ai essayé d’en tracer les grandes lignes, et cela va sans dire, il y a encore beaucoup à explorer, à découvrir et à inventer ! Merci de m’avoir lu jusque là, n’hésitez pas à me contacter pour toute remarque, suggestion ou proposition. La porte est grande ouverte et il y a encore tout à faire !

Au départ, il nous sera donc demandé de nous identifier, on pourra choisir une identité existante ou en créer une nouvelle. Le communicateur affichera alors notre espace personnel, un espace qu’on pourra personnaliser à volonté en y ajoutant toutes sortes de choses, un espace qui nous servira aussi de point de départ vers le reste du web et vers les autres. Typiquement, on y ajoutera des choses créées par nous ou par d’autres, des choses que l’on aime ou qu’au contraire on n’aime pas du tout et que l’on souhaite faire savoir. On pourra également ajouter nos sites préférés mais aussi nos amis et personnes avec qui nous souhaitons rester en contact. Ainsi, on construira peu à peu une représentation publique de nous-mêmes, donnant corps à notre identité numérique. Mais cela va de soi, notre espace pourra également comporter des parties privées afin de conserver des choses personnelles que l’on ne souhaite pas partager. Enfin, il sera envisageable de créer des espaces collectifs, appartenant à plusieurs personnes autorisées à les modifier, ou même appartenant à tous, à la manière des wikis.

Dans les communicateurs, le concept de page disparaît au profit d’objets permettant de représenter tout ce qu’il est possible d’imaginer : vidéo, image, musique, livre, texte, commentaire, calendrier, événement, entreprise, produit, personne, facture, paiement… tout-ce-que-vous-voulez peut devenir un objet. Aujourd’hui, on trouve des sites spécialisés dans un ou plusieurs types d’objets, par exemple, YouTube propose des vidéos, Flickr des images, WordPress propose des objets de type blogs, articles et commentaires, Amazon propose des livres, des bons de commande, des factures, etc. Tous ces objets sont formidables mais ils ont un gros défaut, ils sont enfermés dans les sites dans lesquels ils sont créés. C’est comme s’ils n’avaient pas d’existence propre, ils ont bien du mal à apparaître ailleurs que sur leur plate-forme d’origine, et les rares fois où ils le font, c’est généralement sous une forme très limitée (les fameux widgets). Les communicateurs proposent une logique totalement inverse en plaçant les objets au centre (tout comme l’identité numérique). Les sites tels qu’on les connaît aujourd’hui demeureront mais leur raison d’être principale devrait être de proposer des objets autonomes, capables d’échapper à leur contexte initial, se matérialisant partout où on le désire.

Je ne veux pas trop m’avancer dans la description d’une interface graphique mais j’imagine aisément une sorte de Dock en bas de l’écran dans lequel on pourrait placer toutes sortes d’objets types qu’il suffirait de glisser/déposer afin de les mettre en oeuvre où l’on veut. Par exemple, pour ajouter un commentaire à un article de blog, il suffirait de déposer un objet « texte » sur l’article en question, si on préfère faire un commentaire vidéo, libre à nous d’utiliser un objet « vidéo », et encore mieux, on pourra déposer un objet « paiement » pour effectuer un don à l’auteur du blog ! Bien entendu, le propriétaire d’un objet (l’auteur du blog dans notre exemple) pourra refuser certaines associations avec d’autres objets. Soit globalement, il refusera par exemple tous les commentaires vidéos s’il ne les aime pas, soit au cas par cas, en rejetant un commentaire spécifique qu’il jugerait inapproprié.

En somme, si un objet est un contenu, c’est également un contenant susceptible de recevoir d’autres objets, des objets créés par d’autres. C’est un pas supplémentaire vers l’ouverture et vers la transparence, c’est une généralisation du web collaboratif, tout objet pouvant donner naissance à d’autres, leur offrant une visibilité et une accessibilité immédiate. Prenez un objet très populaire comme le dernier tube d’un groupe à la mode et imaginez que tout un chacun puisse poster des choses juste en dessous, ou pas très loin, à un ou deux clics de distance. On trouvera toutes sortes de commentaires, mais aussi des clips, des remix, des articles, des soirées organisées par des fans, des produits dérivés, etc. Bref, à partir d’un objet c’est tout un monde qui émerge, chaque objet ayant le potentiel d’engendrer un nouvel univers !

Le web nous a habitué à aller chercher nous-même l’information (« pull »), les communicateurs perpétueront cette tradition mais ils apporteront également un mécanisme de souscription permettant à l’information de venir à nous automatiquement (« push »). Aujourd’hui, on trouve déjà une telle mécanique à l’oeuvre grâce aux agrégateurs de flux Atom/RSS et les communicateurs généraliseront cette idée en devenant des sortes d’hyper-agrégateurs. Il sera possible de s’abonner à tout objet que l’on souhaite suivre : un blog, une série TV, un championnat sportif, un fil d’actualité, les résultats scolaires de nos enfants, etc.

Mais un communicateur digne de ce nom se doit de proposer également un système de messagerie de personne à personne pour remplacer notre courrier électronique déjà vieillissant. Comment améliorer les choses en ce domaine ? À quoi ressemblera l’e-mail 2.0 ? Tout d’abord, je propose une solution radicale pour résoudre définitivement le problème du spam, il s’agit d’interdire les mailings, ni plus ni moins. Il faudrait donc limiter l’usage de la messagerie aux messages personnels, composés et envoyés par de vraies personnes et non par des robots, le fait d’être une véritable personne pouvant être vérifié au cas par cas, grâce à une CAPTCHA demandée par le destinataire du message. Mais vous me répondrez peut-être que les robots aussi sont parfois amenés à nous envoyer des messages utiles. Ils nous signalent par exemple l’existence d’une nouvelle version d’un logiciel qu’on utilise, ou bien ils nous préviennent qu’un nom de domaine en notre possession va bientôt expirer. Mais quel que soit le cas de figure, on peut voir qu’il y a toujours une action préalable (un achat dans notre exemple) conduisant à une forme d’abonnement à quelque chose (suivi sur le produit acheté). On peut donc envisager de s’appuyer sur le mécanisme de souscription mentionné au paragraphe précédent pour recevoir de tels messages. Des messages pouvant cette fois être envoyés automatiquement par des robots autorisés, grâce à une souscription qu’on aura soi-même demandée et qu’on pourra donc annuler à tout moment.

Enfin, une dernière idée me semble importante, c’est la possibilité d’adresser des messages aux objets en plus des personnes. On a vu plus haut qu’il était possible d’ajouter des objets un peu partout, y compris à l’intérieur des objets ne nous appartement pas, il s’agissait alors d’objets publics, les commentaires d’un blog par exemple. Mais il est tout à fait envisageable de pouvoir également ajouter des objets privés, visibles par nous et par le possesseur de l’objet destinataire. Or, un objet visible par deux personnes ressemble étrangement à un message vous ne trouvez pas ? C’est en tout cas ainsi que fonctionnera la messagerie intégrée aux communicateurs, il sera possible de déposer des messages sur n’importe quel objet ! Pour répondre à une offre d’emploi, on déposera par exemple notre CV directement sur l’offre concernée, pour poser une question à propos d’un produit, il suffira de déposer notre message sur ledit produit.

Tout cela est passionnant mais je dois malheureusement m’arrêter ici sous peine de faire fuir même les plus courageux de mes lecteurs. Je reviendrai bientôt (pas après six mois c’est promis !) pour écrire la troisième, et vraisemblablement, la dernière partie de l’introduction aux communicateurs. J’aborderai alors les dimensions géographiques et temporelles du nouveau web et j’espère avoir également l’occasion de vous parler de l’architecture technique, très orientée P2P, sur laquelle les communicateurs s’appuieront pour fonctionner.

En gros, les navigateurs mettent aujourd’hui en oeuvre trois choses : une barre d’adresse, des liens hypertextes et une fonction « Back » permettant de revenir aux pages précédentes. C’est tout, il n’y a pas autre chose et c’est ainsi depuis le premier navigateur Mosaic. En fin de compte, les navigateurs ressemblent à des livres avec des liens hypertextes assimilables à des notes de fin de page amenant le lecteur vers d’autres pages, d’autres livres. Ils ont été conçus pour représenter un monde fait de concepts, d’idées, un monde de textes et d’histoires que j’aime à qualifier de monde de la conscience. Il existe cependant deux autres mondes tout aussi importants : le temps (donnant lieu aux blogs, aux lifestreams, aux podcasts, etc.) et l’espace (allant de Google Map à Second Life). Malheureusement, ces mondes induisent des mécanismes de navigation différents et absents des navigateurs actuels, les web designers sont totalement démunis en la matière, ils parviennent à se débrouiller grâce à un savant mélange de HTML, CSS ou autre JavaScript, mais reconnaissons-le, tout cela n’est pas très propre, ça ressemble à de la bidouille, du hacking.

Que faudrait-il faire pour améliorer les choses ? Tout d’abord, je crois qu’il faut sortir du paradigme de la « page web » qui ne correspond plus à nos besoins actuels. Il serait nettement préférable de recentrer les choses autour de l’idée des « objets » qui permettent beaucoup plus de choses. Tout peut être objet, un article d’un blog, une vidéo, une musique, un courrier, etc. Et bien qu’ayant une adresse unique, chaque objet peut apparaître à plusieurs endroits sur la toile et être mis en oeuvre dans différents contextes.

Par exemple, l’auteur d’un livre (ou son éditeur) créera un objet en définissant plusieurs choses : le titre, l’auteur, le nombre de pages, la quatrième de couverture, etc. S’agissant du contenu même du livre, le texte intégral, il sera probablement accessible sous une forme numérique, l’auteur disposant d’un choix de licences d’utilisation et de diffusion répondant à toutes les situations : vente classique à prix fixe, rémunération basée sur le don (freeware), licence Creative Commons (copyleft), etc. Le livre pourra s’afficher sur le site de l’auteur, de son éditeur ou même dans le cadre d’une boutique comme Amazon. Cette dernière enrichira éventuellement l’objet avec des critiques, des extraits de texte, des commentaires et que sais-je encore. Mais qu’on soit sur le site de l’auteur ou chez Amazon, c’est du même objet dont il est question, la présentation peut éventuellement varier, des informations peuvent être ajoutées mais tout ce qui est défini par l’auteur reste sous son contrôle. Libre à lui de changer à tout moment la quatrième de couverture, le résumé, la licence de diffusion ou même le contenu, chaque changement étant automatiquement reporté sur tous les sites référençant le livre en question.

Le concept de lien devrait également subir une petite révolution. Il faut bien prendre en compte les nouveaux mondes correspondant au temps et à l’espace qui s’ajoutent à la conscience. En plus des liens hypertextes classiques, on devrait donc pouvoir créer des liens pointant vers des dates ou des coordonnées spatiales, voire même une combinaison de tout cela. Par exemple, un lien vers « le concept température à une certaine date dans un endroit donné » pourrait être très utile dans le cadre d’un site web traitant de météorologie. Vous me répondrez peut-être qu’on peut déjà définir ces informations dans une URL traditionnelle en ajoutant simplement des paramètres. Certes, mais le navigateur ne comprenant pas grand chose aux paramètres, comment identifiera-t-il les concepts, les dates et les lieux afin de nous aider à naviguer plus efficacement à l’intérieur des différents mondes ?

Mais au delà des liens, il serait intéressant d’ajouter quelques éléments de structuration essentiels. On parle souvent de l’arborescence d’un site mais il n’y a malheureusement rien dans le HTML qui nous permet de la définir clairement. Les web designers mettent en oeuvre des liens ordinaires accompagnés de quelques artifices visuels pour représenter des menus de navigation, des barres latérales et autres onglets, mais il n’y aucune sémantique dans tout ça, il faut vraiment avoir des yeux en bon état pour comprendre de quoi il s’agit.

D’une manière ou d’une autre, j’aimerais beaucoup pouvoir revenir à la pureté du web original qui s’attachait d’avantage au contenu qu’à la forme. C’est aux navigateurs de s’occuper de la forme et non aux web designers. Pour afficher une arborescence, il suffirait de la décrire tout en précisant éventuellement quelques attributs permettant d’indiquer comment on souhaite la voir s’afficher, sous la forme d’une liste verticale ou d’onglets horizontaux par exemple, les navigateurs s’occupant de tout le reste. Le gros avantage d’une telle approche c’est que les navigateurs pourraient automatiquement transformer l’aspect d’un site en fonction du périphérique sur lequel il est affiché. Un ordinateur n’étant pas la même chose qu’un téléphone mobile, la présentation des sites et les mécanismes de navigation s’en trouvent nécessairement modifiés.

Pour comprendre où je veux en venir, il faut s’imaginer en train de naviguer sur un site avec une interface composée d’une colonne unique, un iPhone par exemple. Prenons un gros site tel que celui d’Amazon et essayons de voir comment la page d’accueil se présentera. En haut de l’écran, s’affichera le logo du site accompagné d’un petit texte décrivant brièvement le service. Ensuite, il pourrait y avoir quelques news importantes ainsi qu’une sélection de produits spécialement mis en avant. Enfin, on trouvera les grands rayons du magasin (le niveau 1 de l’arborescence) qui pourrait se présenter sous la forme d’une liste de choix. Rentrons par exemple dans le rayon DVD, que va-t-il se passer ? Avec un iPhone, l’écran étant ce qu’il est, la page d’accueil disparaîtra pour laisser la place à l’affichage du nouveau contenu. S’agissant d’un écran d’ordinateur qui offre d’avantage d’espace, une colonne supplémentaire pourrait apparaître pour afficher le nouveau contenu juste à côté de l’ancien. La page d’accueil ne bougerait pas et la liste des rayons serait par conséquent toujours visible, rejoignant ainsi l’idée d’un site classique disposant d’un menu de navigation répété sur chaque page. Finalement, on recréait des sites composés de plusieurs colonnes mais c’est le navigateur qui en a la gestion et il est donc capable de s’adapter automatiquement aux différents périphériques.

Ajoutons au rayon DVD les sous-rayons Comédie, Drame et Science-Fiction. Que va-t-il se passer si l’utilisateur rentre dans un sous-rayon ? Le navigateur affichera une nouvelle colonne, tout simplement. En fin de compte, le navigateur du futur est quelque chose qui ressemble un peu à l’explorateur de fichier du système NeXTSTEP, une formidable idée reprise plus tard dans le Finder de Mac OS X. Le fait de naviguer dans une arborescence entraîne la création de nouvelles colonnes et le bouton « Back » que j’évoquais au début de cet article se résume à un simple scrolling horizontal. On peut alors entrevoir une nouvelle façon de naviguer et concevoir les sites web, tout en gardant les avantages des sites multi-colonnes du web traditionnel, ils fonctionneraient parfaitement dans le cadre d’un web mobile. Qu’il s’agisse d’un PDA, d’un iPhone, d’un e-Book ou d’un écran 21″, un glissement de doigt ou un coup de molette devrait suffire à passer d’une colonne à l’autre.

J’ai débuté cet article en mentionnant l’idée de la convergence et je viens d’en donner un premier exemple. Il me reste encore beaucoup à écrire sur le sujet, à commencer par les aspects communicants dont je n’ai encore rien dit alors qu’ils permettraient de comprendre ce que j’entends par « communicateurs web ». Mais je ne voudrais pas précipiter les choses, je suis bien conscient que tout cela n’est pas facile à appréhender. J’ai à peine aborder le premier monde, celui correspondant à la conscience, j’y reviendrai sûrement mais avant d’aller plus loin il me faut réfléchir aux deux autres mondes fondamentaux, le temps et l’espace qui devraient contribuer à changer radicalement notre façon de voir le web. N’hésitez pas à me faire part de vos remarques et rendez-vous bientôt sur ce blog pour découvrir la suite de l’aventure !

Mais finalement, il s’agit de transformer le « World Wide Web » (toile d’araignée mondiale) en « World Wide Database » (base de données mondiale). Ce serait déjà un grand pas si on pouvait en arriver là mais je crois qu’il est possible d’aller encore plus loin, cela dès maintenant, au delà du web sémantique on pourrait envisager d’aller directement vers le « Web Orienté Objet ». Inutile de rechercher cette terminologie sur un moteur de recherche, elle n’existe pas (encore). Cette idée saugrenue m’est venue alors que je réfléchissais à la manière de réaliser des réseaux sociaux décentralisés. J’ai imaginé des données voyageant d’une personne à l’autre grâce au mécanisme de « propagation » (lire mon précédent billet à ce sujet) et j’ai vu qu’il pourrait être intéressant d’attacher un certain nombre de fonctionnalités à ces données. Prenez les blogs par exemple, ils apportent généralement une fonction « commentaire » et il paraît intéressant que celle-ci soit accessible quelque soit l’endroit où les articles apparaissent, qu’il s’agisse du blog d’origine, d’un agrégateur RSS tel que Google Reader ou d’un réseau social. Considérez les articles des blogs comme des objets ubiquitaires composés à la fois de données (propriétés) et d’actions (méthodes) et vous commencerez à entrevoir ce que j’entends par « Web Orienté Objet ».

En somme, si le web sémantique vise à établir des standards pour différents types de données, le « Web Orienté Objet » ajoute la possibilité de normaliser un certain nombre d’actions. Au delà de la fonction « commentaire » applicable à quasiment tous les types d’objet, on peut imaginer de nombreuses autres actions possibles dont voici un échantillon qui me vient immédiatement à l’esprit : gestion collaborative des tags, système de vote « à la Digg« , fonction « traduction humaine », mécanisme permettant de signaler les objets malveillants (contenus illégaux, spams, etc.), fonctions « acheter » ou « faire un don » pour rémunérer les auteurs des objets, etc. Toutes ces actions élémentaires devraient pouvoir être normalisées afin de permettre la portabilité des objets et l’interopérabilité des services. Quand on règle un achat dans un magasin, c’est pratique de pouvoir utiliser plusieurs cartes de paiement, qu’il s’agisse d’une carte Visa ou d’une American Express, l’appareil enregistrant les paiements devrait pouvoir fonctionner. De même, il semble intéressant de permettre l’interopérabilité des services de paiement en ligne, le client devrait pouvoir choisir à tout moment entre Paypal, Amazon FPS ou Google Checkout. Si cela semble relativement évident pour les services de paiement, il devrait en être de même pour de nombreux autres types de services plus ou moins universels tels que ceux évoqués plus haut : les commentaires, les tags, les traductions,… Par exemple, si la fonction « commentaire » de WordPress ne me convient pas, j’aimerais bien pouvoir utiliser celle de CoComment, ou tout autre service spécialisé dans la gestion des commentaires.

Il va de soit qu’on devrait tendre vers la plus grande interopérabilité possible mais il paraît néanmoins nécessaire de permettre aux auteurs des objets postés sur le web de 1) définir les actions possibles sur leurs objets, 2) maîtriser les services qui prendront en charge ces actions. Le créateur d’un objet « musique » autorisera une action permettant de recevoir des dons tout en refusant un service de donation spécifique, parce qu’il serait contraire à sa déontologie par exemple. À l’inverse, un auteur pourrait forcer l’utilisation d’un service de paiement en particulier, parce qu’il reverse un pourcentage des sommes versées à des oeuvres caritatives. En fait, cette liberté de choix devrait pouvoir s’exercer à plusieurs niveaux : 1) les auteurs des objets, 2) les services intermédiaires hébergeant les objets (réseaux sociaux, blogs, boutiques en ligne,…), 3) les personnes recevant les objets auront elles-mêmes accès à un choix d’actions et de services possibles, plus ou moins varié en fonction des choix effectués aux niveaux précédents.

Vous devriez maintenant avoir une petite idée de ce que j’entends par « Web Orienté Objet », un concept allant plus loin que le web sémantique mais qui semble être, paradoxalement, plus facile à réaliser car débouchant immédiatement sur des applications concrètes et relativement simples à appréhender. Mais comment tout ça va bien pouvoir fonctionner ? Je ne saurais le dire précisément, tout ce que j’ai pour le moment c’est la vision globale d’un système permettant à des choses dématérialisées de se propager sur le web d’une manière qui va au delà de la forme, au delà de la sémantique, il s’agit d’un mélange puissant de données et d’actions donnant lieu à des objets capables d’une existence propre. Cela d’une façon qui soit la plus ouverte possible tout en garantissant au maximum les libertés pour les auteurs, les intermédiaires, et finalement les destinataires, vous et moi qui recevons et propageons les différents objets qui composent le web.

À la base du réseau social on a donc des personnes. Celles-ci peuvent être représentées par des OpenID, le temps où on devait créer autant de comptes que de sites web est terminé. On crée un compte quelque part, chez un fournisseur OpenID, et on s’en sert partout. Ensuite, il y a des relations entre les personnes, autrement dit, le réseau social. Le terme peut paraître bien savant mais il recouvre en réalité une idée fort simple. Il suffit d’imaginer un bon vieux carnet d’adresses dans lequel on consigne l’ensemble de nos contacts. Quels sont-ils ces contacts ? Il y a la famille bien sûr, les amis proches ou de simples connaissances. Mais il peut aussi y avoir le plombier, le garagiste, les collègues du club sportif, les collègues de travail, etc. Enfin, on peut être amené à ajouter des personnes qui ne nous connaissent pas mais dont on souhaite suivre la lifestream publique : artistes, scientifiques, journalistes, blogueurs, politiques, syndicalistes, prêtres, philosophes, amateurs éclairés…

Dans le réseau social, les personnes partagent toutes sortes d’objets (textes, photos, vidéos, etc.). Ensuite, ces objets peuvent se propager d’un réseau à un autre, un peu à la manière du bouche à oreille. D’un clic, on a la possibilité de propager n’importe quelle donnée (qu’on en soit l’auteur ou non) à toute ou partie de nos contacts qui peuvent, à leur tour, la rediffuser. C’est ainsi qu’une information va pouvoir se multiplier afin de toucher un grand nombre de personnes dans un processus viral. 1) Je reçois (ou je crée) une information que je souhaite communiquer à mes amis, je clique donc sur « Propager ». 2) Mes amis reçoivent l’info et peuvent également la propager s’ils le souhaitent. 3) Les amis de mes amis reçoivent l’info à leur tour alors que parmi eux il y a des gens qui ne me connaissent même pas. Si l’info les intéresse, ils vont pouvoir se demander « Qui est ce mec ? », jeter un oeil à ma lifestream publique et éventuellement m’ajouter à leur liste de contacts. Boom (© Steve Jobs) ! J’ai étendu mon réseau social, je me suis fait de nouveaux amis !

La fonction « Propager » semble essentielle car c’est souvent ainsi que l’information circule, que ce soit sur le web ou dans le monde réel. Aujourd’hui, quand j’envoie un lien à un ami je ne fais pas autre chose, les blogs se citent les uns les autres, les pétitions par e-mail (ou histoires drôles) se propagent de personne en personne grâce à la fonction « Faire suivre », etc. On a là un système de communication totalement décentralisé, l’information ne nous parvient plus seulement depuis quelques gros médias, elle peut survenir de n’importe où. Chacun, petit ou grand, ayant le potentiel de produire un buzz planétaire grâce à un clic et quelques amis relayant l’information.

Malheureusement, cette fonction « Propager », si importante soit-elle, est absente (ou mal implémentée) dans presque tous les réseaux sociaux existants. Utilisez-vous souvent la fonction « Share » de Facebook ? Ne peut-on pas estimer qu’il est aussi important de propager une information que de la consulter ? La propagation est une fonction de base, un mécanisme naturel.

Finalement, le réseau social que j’ai à l’esprit s’appuie sur deux grandes idées. 1) Permettre une décentralisation maximale, on aura un réseau social commun à toutes les applications et celles-ci seront externes, non piégées comme c’est le cas aujourd’hui, à l’intérieur d’une plate-forme unique comme Facebook. 2) Mettre en place une infrastracture permettant une approche centrée à la fois sur les personnes (user-centric) et sur les objets (object-centric). J’ai indiqué précédement la fonction « Propager » qui est applicable à tout type d’objets mais on peut imaginer de nombreuses autres fonctions : ajouter des tags, commenter, voter, traduire dans une autre langue, sous-titrer, résumer, créer un objet dérivé, indiquer un objet relié, bannir, signaler (comme illégal, spam, etc.), dédoublonner, modifier (Wiki), marquer comme « à voir plus tard », acheter, faire un don…

En résumé, on a des gens qui s’échangent des objets disposant chacun d’un certain nombre de fonctionnalités plus ou moins génériques. Le tout devrait être totalement décentralisable, les objets pouvant être hébergés n’importe où (même chez soi, à la maison) et les fonctionnalités être prises en charge par des acteurs multiples. Par exemple, il pourrait y avoir plusieurs services pour gérer les commentaires, plusieurs services permettant de gérer les achats, les votes, les traductions, etc. Mais le tout serait parfaitement compatible et donc interchangeable. Par exemple, si la fonction « commentaire » de Blogger.com ne me satisfait pas, j’aurai la possibilité d’utiliser un autre service permettant de faire plus ou moins la même chose mais avec une approche me convenant d’avantage. Autrement dit, on sera en mesure de construire nos propres applications en assemblant les différents services qui les composent. Dans le cadre du web sémantique, cela revient à standardiser les fonctions (les API) en plus des données. On pourrait appeler cela le « Web Orienté Objet ». Mais c’est un autre sujet qui fera l’objet d’un prochain billet. Un nouveau monde s’ouvre à nous, un monde unificateur où tout peut converger d’une façon magnifique.

Le crawling semble être la partie « ennuyeuse » dans les moteurs de recherche et si ces derniers doivent se différencier les uns des autres, ça ne se fera certainement pas de côté là, l’innovation devrait plutôt se trouver dans le domaine de l’indexation, du ranking, etc. Mais peut-on imaginer que des moteurs de recherche tels que Google ou Yahoo s’entendent un jour pour mutualiser leur crawling ? Aussi surprenant que cela puisse paraître, je crois que oui.

Mais avant d’aller plus loin, il faut bien comprendre de quoi on parle. Finalement, le crawling consiste à réaliser une sorte de « sauvegarde du web ». D’une manière ou d’une autre, les moteurs de recherche généralistes ont besoin de posseder une copie intégrale du web pour fonctionner efficacement. Il leur faut donc scanner et rescanner le web à longueur de temps afin d’obtenir la copie la plus fraîche possible. Pire, le problème est le même pour les moteurs verticaux, même si leur domaine de prédilection se limite à quelques sujets précis, ils doivent tout de même scruter l’intégralité du web car l’information qui les intéresse peut être cachée n’importe où. Du moins, c’est l’approche actuelle.

Comment peut-on améliorer les choses ? Tout d’abord, j’en suis de plus en plus convaincu, il faut inverser le processus. Ce n’est pas aux moteurs de recherche d’interroger les sites web, c’est aux sites de contacter les moteurs pour les informer des différents changements. Aujourd’hui, un développeur web doit mettre en place un fichier robot.txt (voire un Sitemaps) pour assurer le meilleur référencement possible. Demain, il ajoutera un mécanisme permettant d’informer les moteurs de recherche de tous les changements survenant dans sa base de données. Pour les sites modernes s’appuyant sur le paradigme MVC, ça ne devrait pas être un souci, il suffira d’ajouter un « plugin » au niveau du modèle. En gros, ce plugin sera chargé de contacter les moteurs de recherche afin de signaler l’ensemble des opérations de type « Create », « Update » ou « Delete ». Enfin, cette inversion de processus devrait permettre la création de moteurs de recherche en temps réel. Imaginez, vous rentrez vos critères de recherche et vous voyez les résultats arriver au fur et à mesure que le web évolue !

Mais au fait, si les sites doivent contacter d’eux-mêmes les moteurs de recherche, lesquels vont-ils choisir ? Vont-ils se limiter à certains ? Bien évidement non, les sites devraient pouvoir propager leurs modifications vers un maximum de moteurs, des plus importants aux plus spécialisés, sans même avoir besoin de les connaître à priori. Comment cela peut-il fonctionner ? J’imagine des sortes de relais permettant de diffuser le « flux des modifications » le plus largement possible. Appelons ça des « datahubs » si vous voulez bien (en français on pourrait traduire cela par « concentrateurs de données »). Les datahubs seront reliés les uns aux autres d’une manière totalement décentralisée et si un site web envoie une information sur un datahub donné, la totalité des autres datahubs recevront cette même information, par un jeu de cascade consécutive. Autrement dit, si je veux créer mon propre datahub, il suffira que je me connecte quelque part, à un autre datahub, pour recevoir automatiquement l’intégralité des changements susceptible de survenir n’importe où sur le web. Et de son côté, mon datahub pourra à son tour propager les données qu’il reçoit vers d’autres datahubs. Bien entendu, mon datahub devra disposer d’un tuyau suffisamment important pour faire transiter toute cette masse d’informations.

Il faudrait pouvoir quantifier la bande passante nécessaire pour transférer en temps réel toutes les modifications du web, mais je crois qu’on peut raisonnablement estimer qu’elle ne sera pas très élevée. En fait, je crois qu’elle devrait même être assez faible, et si je devais me risquer à avancer un chiffre très approximatif, je dirais que 1 Gbps devrait être suffisant si on se limite aux données textuelles. Aujourd’hui, on trouve des hébergeurs capables de fournir ce débit pour moins de 100 euros par mois. Essayez donc d’imaginer le coût total occasionné par le crawling permanent de Google, Yahoo et MSN (pour ne citer que les plus gros) comparé aux quelques centaines d’euros nécessaires pour realiser la même chose avec l’idée des datahubs !

Bien sûr, le crawling n’est pas tout me direz-vous, si on souhaite réaliser un véritable moteur de recherche il faudra stocker une masse importante d’informations afin de réaliser un certain nombre d’opérations : parsing, indexation, ranking, etc. Par conséquent, si on entreprend la réalisation d’un nouveau moteur généraliste, il faudra quand même prévoir une infrastructure conséquente. En revanche, et c’est ici que les datahubs deviennent véritablement passionnants, il sera facile et très peu coûteux de réaliser des moteurs de recherche verticaux, spécialisés sur quelques domaines choisis. D’ailleurs, une fonctionnalité importante des datahubs devrait permettre précisément cela, un datahub pourra déclarer les types de données qu’il souhaite recevoir et propager.

Finalement, l’intérêt des datahubs m’apparaît comme une évidence et j’ai peine à imaginer l’ensemble des applications possibles tellement le potentiel semble important. Mais cette idée est pour moi-même assez nouvelle, je débute tout à fait et je connais très peu l’état de la recherche dans le domaine, n’y a-t-il pas des gens qui travaillent déjà là-dessus ? Vos réactions sont les bienvenues.

Mais j’ai le sentiment qu’il manque encore quelque chose d’important pour permettre au web sémantique de véritablement décoller. Pour comprendre de quoi il s’agit on doit prendre en compte le fait que le web change en permanence, des données y sont continuellement ajoutées, modifiées ou supprimées. Le fait d’avoir des informations sémantiques n’y change rien, cela pose chaque jour un plus grand challenge aux moteurs de recherche qui sont obligés de « crawler » tout le web en permanence afin de détecter le moindre changement. Ce serait tellement plus efficace (et simple) si les sites pouvaient d’eux-mêmes prévenir les moteurs : « Salut Google, j’ai changé, merci de venir me voir ! ». En outre, on réduirait considérablement le temps d’indexation, jusqu’à parvenir à des « moteurs de recherche en temps réel ». Vous me répondrez peut-être que c’est le problème de Google, qu’ils gagnent assez d’argent pour accroître leur infrastructure indéfiniment. Vous auriez tort de penser cela car les besoins de crawling ne concernent pas que Google. Le développement du web sémantique devrait entraîner l’émergence de nombreux sites très spécialisés qui auront besoin d’agréger une masse importante d’informations ciblées sur un domaine mais pouvant apparaître n’importe où sur le web. Alors quoi, tout le monde va se mettre à crawler dans son coin ?

Le problème des moteurs de recherche n’est pas mince mais il y a plus important encore. Imaginons que je veuille fabriquer un carnet d’adresses en ligne. L’approche la plus simple consiste à stocker les différentes informations moi-même, je vais enregistrer mes adresses dans une base de données quelconque et c’est terminé. Il y a une autre approche, un peu plus compliquée mais tellement plus intéressante : il est possible de stocker des sortes de liens permettant de récupérer les informations à la source à n’importe quel moment. Dans mon carnet d’adresses, j’aurai par exemple une fiche correspondant à mon restaurant préféré. Or ce restaurant possède un site web qui contient exactement ce que je recherche : les coordonnées y sont présentes sous une forme que mon carnet d’adresses comprend parfaitement bien, le format hCard par exemple. Je vais donc « abonner » mon carnet d’adresses à ce site.

Ensuite, grâce au mécanisme d’abonnement, les coordonnées du restaurant seront récupérables « à la demande » pour s’afficher dans mon carnet d’adresses. Bien entendu, il est possible d’optimiser les choses en conservant une copie des informations dans une base de données locale. Mais entendons-nous bien, il s’agit là d’une copie temporaire, une sorte de « cache » si vous voulez. La véritable donnée reste à la source, sur le site du restaurant lui-même. Et si ce dernier doit changer quelque chose, il a déménagé par exemple, les changements qu’il fera de son côté seront automatiquement reportés dans mon carnet d’adresses.

Ce mécanisme « d’abonnement aux données » semble être une piste intéressante pour parvenir à une sorte de base de données décentralisée capable de fonctionner à l’échelle de la planète. Mais il y a un autre aspect beaucoup plus fondamental : l’idée des « liens retour ». En effet, un abonnement revient à tisser un lien bidirectionnel d’une information à une autre. Ça n’a l’air de rien comme ça mais les conséquences sont gigantesques. L’ordinateur étant en mesure de déterminer comment les données sont reliées les unes aux autres, il devient tout d’un coup beaucoup plus intelligent.

Prenons un autre exemple pour bien comprendre ce qui se passe. Imaginons que notre restaurant souhaite recueillir des commentaires de clients, pour les afficher sur son site dans une sorte de « livre d’or » par exemple. Le restaurant pourrait simplement ajouter un formulaire sur son site afin de permettre aux clients d’enregistrer leurs commentaires. Mais notre restaurateur est beaucoup plus ambitieux que ça, il souhaiterait également afficher les commentaires qui ont été enregistrés ailleurs, sur d’autres sites que le sien. Qu’ils s’agissent de critiques gastronomiques ou d’avis divers éparpillés sur la toile, notre restaurateur souhaiterait pouvoir présenter tous ces commentaires sur son propre site. Malheureusement, le web actuel n’offre pas de solution simple permettant de réaliser cette prouesse. Il n’existe aucun moyen pour rechercher facilement l’ensemble des informations se rapportant à notre restaurant.

C’est précisément ici que le concept de « liens retour » pourrait nous être fort utile. En effet, les chances sont grandes pour que les commentaires éparpillés sur la toile incluent un lien pointant vers le site du restaurant. Mais dans notre vieux web, ces liens sont à sens unique malheureusement. Notre restaurateur n’en a même pas la connaissance, à moins qu’il fasse une recherche de type « link: » sur Google ou qu’il regarde les « HTTP Referers », mais rien de tout ça n’est vraiment satisfaisant. Dans le monde des blogs, il existe quelque chose qui rejoint l’idée des liens retour, il s’agit de l’excellent protocole Pingback. Quoi qu’il en soit, imaginons que les liens soient bidirectionnels : quand un commentaire est posté quelque part, le site du restaurant serait contacté afin qu’il puisse enregistrer le lien retour correspondant. Il suffirait ensuite de « remonter » les différents liens pour retrouver instantanément l’ensemble des commentaires liés à notre fameux restaurant.

Les bases de données relationnelles ne fonctionnent pas autrement, le concept de lien retour y est prédominant et on ne pourrait même pas imaginer que cela puisse être différent. Mais ce n’est pas ainsi que fonctionne le web, est-ce un bien ou un mal ? Je ne peux le dire… Pourtant, si on veut un jour réaliser le grand rêve de la World Wide Database, je crois qu’on devra sérieusement envisager l’utilisation de mécanismes apportant les abonnements et les liens retour, permettant ainsi aux informations sémantiques de véritablement « exister ».