Un benchmark des performances des solutions RIA

J'ai publié cet article ici pour les retardaires qui n'auraient pas encore noté le déménagement de ce blog... je vous encourage donc à aller le voir ici, en particulier si vous voulez faire un commentaire (ceci étant officiellement le dernier message à être publié à cette adresse).

J’avais souligné il y a quelques temps combien le besoin de comparer objectivement les solutions RIA se faisait pressant. J’avais fourni une première base de comparaison avec les fonctionnalités disponibles dans chacune des technologies et leurs exigences pour être déployées.

Il manquait deux éléments pour que la comparaison soit valable :

1- la productivité

2- les performances

Voilà justement un benchmark qui permet une bonne comparaison des différentes solutions en terme de performances. Le code source utilisé étant disponible pour chaque implémentation, on peut aussi avoir une petite idée du potentiel de productivité de chacune de ces technos.

A l’heure du choix d’une techno RIA, un site à visiter et à revisiter sans hésiter…

Alerte : Web2rules déménage !

J'avais annoncé, il y a environ 6 mois, un déménagement de ce blog afin de bénéficier des atouts de la plate-forme wordpress. Cette heure est aujourd'hui venue : vous pourrez désormais lire mes bafouilles sur blog.eutech-ssii.com et en finir avec le système de commentaires assez rebutant
qu'est celui de blogger.

Pensez aussi à changer votre flux RSS : http://blog.eutech-ssii.com/feed/rss2/
Pour les fans, le flux des commentaires existe aussi maintenant : http://blog.eutech-ssii.com/comments/feed/

Vous pouvez au passage laisser votre impression sur le nouveau look du blog, y compris
avec des phrases du genre "tiens, il a gardé son rose tout pourri ?" ou encore "encore un mec qui se la donne alors qu'il s'est contenté de repomper un thème wordpress !".

AIR / Gears : la preuve par ext

Mon billet précédent vous annonçait combien AIR et Gears étaient proches dans leur philosophie mais je ne m'attendais pas à une confirmation aussi rapide de cela dans les faits.

Pour s'amuser un peu, Jack Slocum auteur de la très réussie librairie ext, a décidé de se prendre quelques Red Bull et de coder une application AIR. Résultat ? Il nous pond un truc qui marche aussi bien avec AIR qu'avec Google Gears, en nous faisant don au passage d'une petite couche d'abstraction permettant de coder simplement une application qui fonctionnera sous l'une ou l'autre formule.

Les vainqueurs de la vague RIA ne seraient-ils pas déjà là ?

AIR (ex Apollo) / Google Gears : même combat !

Je ne suis pas de ceux qui tracent une ligne rouge entre ce que certains appellent RDA (pour Rich Desktop Application qui s'exécutent hors navigateur) et les RIA (Rich Internet Application qui s'exécutent dans un navigateur).

Les marchés, les technologies, les contenus et les possibilités de ces 2 familles sont trop proches pour les considérer comme véritablement distinctes... Je continuerai donc ici de parler de plate-formes RIA pour des technos aussi différentes que WPF, AIR, Ajax, Flash, Silverlight, XUL, Java ou les plate-formes de widgets : j'excluerai par contre OpenLazlo ou Flex de cette terminologie dans la mesure où ils ne sont que des technologies serveur (pour plate-forme RIA, certes) et non des runtimes.

Cette proximité entre des technologies au prime abord assez différentes me paraît d'ailleurs chaque jour un peu plus évidente. Dernier exemple en date avec quelques essais menés sur Google Gears d'une part et AIR d'autre part.

Ces 2 technos partent d'un même principe : l'inertie des habitudes de développement web est telle, la concurrence entre nouvelles technos si féroce, que pour s'imposer il vaut mieux accomplir une révolution douce. Et quel est le discours de ces gentils révolutionnaires ?

- Continuez à utiliser vos technos de développement web : Ajax, Flash... ce sont de bonnes technos, et vous avez encore pas mal de clients à satisfaire avec.
- Continuez à développer des sites/applications que l'on peut visiter avec un simple navigateur : c'est une avancée majeure du web qu'il ne faut pas perdre.
- Allez plus loin sur certaines fonctionnalités avec les clients/utilisateurs qui le souhaitent grâce à nos technologies : mode offline, accès aux ressources systèmes.
- Soyez rassurés, nos technologies sont convergentes : Javascript, XML, SQLite...

Et vous savez quoi ? C'est vrai ! Il n'agit pas simplement d'un discours commercial comme on en a beaucoup entendu ces dernières années. Les quelques essais que nous avons faits mes collègues et moi, nous ont montré que pour une même application les implémentations AIR et Gears sont très proches... et, ça, c'est une très bonne nouvelle, vous ne trouvez pas ?

Traduction de "What is web 2.0" : nouvelle release

Avec l'aide de Christelle, collaboratrice de passage, j'ai pu compléter les quelques morceaux qui manquaient à la version française de "What is web 2.0", l'exposé de la brillante vision de Dale Dougherty et Tim O'Reilly. Tout cela a été mis sur le site de la jeune et sympathique société de votre serviteur. Les liens de la version originale ont également été ajoutés et quelques bourdes corrigées.

Ce nouveau petit plongeon dans cet article fondateur a d'ailleurs été pour moi l'occasion de constater que près de 2 ans après, il garde encore toute sa fraîcheur et sa pertinence comme si ses grands principes étaient intemporels...

Pour les connaisseurs, quelques raccourcis vers les nouvelles parties traduites (ce sont les pavés latéraux) :
Une plateforme gagne contre une application à tous les coups
L'architecture de participation
Une thèse de l'investissement dans le Web 2.0
Les modèles de conception du Web 2.0

Développement Ajax : quelques clés pour une architecture javascript moderne

A l'heure où Ajax se répand au point d'envahir bon nombre des offres d'emploi de certains sites spécialisés et où de plus en plus de code repasse côté client, il devient nécessaire de se poser quelques questions sur l'architecture des développements Javascript.

Ces questions, les voici :
1- Utilisera-t-on (ou non) des frameworks intégrant serveur et client (backbase, GWT, webdev) ?
2- Le javascript sera-t-il situé uniquement côté client ou alors sera-t-il aussi généré par le serveur ?
3- Quelles librairies js utiliser côté client ? comment les articuler ?
4- Utilisera-t-on (ou non) Javascript comme un vrai langage objet avec "espaces de nom" et "classes" héritant les unes des autres ?
5- Quelles couches distinguer dans le développement Javascript et comment les articuler à la fois entre elles et avec les couches serveur ?
6- Quelles bonnes pratiques architecturales suivre de manière générale en js ?

Je vous donne rapidement MES réponses à ces questions... je tranche assez franchement pour mieux faire naître le débat !

1- Un framework Ajax côté serveur ?
Non, déléguer la reponsabilité du client à une technologie serveur est une mauvaise idée. Ca vous permettra peut-être un temps d'être plus productif, mais certainement pas sur la durée. Pour traiter les problèmes côté client, il est bien entendu beaucoup plus efficace d'utiliser une technologie cliente... même si ça peut paraître pénible à certains de se (re)mettre à Javascript, XHTML et aux css.

2- le JS côté client uniquement ?
Oui, autant que cela est possible... les avantages sont nombreux : séparation des couches applicatives claire, performance, productivité du développement sur le long terme.

3- quelles librairies JS ?
Une et une seule bonne librairie "noyau" (prototype ou JQuery sont mes premiers choix mais il n'est pas interdit de regarder ailleurs... en faisant très attention !) qu'il faut utiliser à fond : plus question par exemple d'utiliser prototype uniquement pour Ajax.Request ! La librairie noyau doit servir à la gestion des événements, la manipulation du DOM et aux appels AJAX dans l'ensemble de votre code.
Si vous avez bien choisi la librairie noyau, les éléments qui viennent s'y raccrocher (en particulier les effets graphiques évolués) ne devraient pas vous manquer.

4- des classes et des espaces de nom ?
Oui, bien sûr ! Même si javascript n'offre pas ces possibilités de manière native, il est tout à fait possible de les simuler et de tirer tous les bénéfices que l'on connaît depuis longtemps côté serveur à ces pratiques. Prototype en est un excellent exemple.

5- quelles couches côté JS ?
A l'heure où le stockage local devient une réalité dans les applications Ajax, établir une véritable couche d'accès aux données paraît de plus en plus incontournable : lire à ce sujet le très bon brief de l'équipe de Google Gears.
De manière générale, les couches côté JS vont ressembler de plus en plus à celles que l'on connaît habituellement "server side" : données / accès aux données / logique métier / interface. Tout le défi va être d'articuler cela avec les responsabilités attribuées au serveur : rien d'infaisable en réalité.

6- les bonnes pratiques architecturales JS ?
Ce ne sont évidemment pas tout à fait les mêmes que sur une technologie serveur : Javascript est un langage bien particulier (mais pas un sous-langage !) et le client riche pose des problèmes très spécifiques. Cependant, ça n'empêche pas, bien au contraire, d'avoir recours à des motifs de conception pour bien aborder et résoudre la plupart des problèmes : un petit tour sur Ajax Patterns sera utile à toute personne qui se pose de bonnes questions sur le sujet.

Allez-y, réagissez, indignez-vous, lancez moi des fleurs, insultez moi ! Ces questions-là sont capitales, alors il vaut mieux en parler...

Google Gears : tout l'intérêt de WorkerPool en une démo

Je reviendrai très prochainement plus en détail sur ce qui risque de changer Google Gears pour les utilisateurs, les développeurs et les entrepreneurs du web... mais je ne résiste pas dans l'attente au plaisir de vous faire partager une petite démo qui montre tout l'intérêt d'une partie de Gears qui n'a, semble-t-il, pas été apprécié à juste valeur par nombre de lecteurs : WorkerPool.

En effet, si les atouts d'un serveur et d'une base de données accessibles en JS sur le poste client paraissent assez évidents, le concept du workerpool l'est moins. Rappelons-le. Le workerpool permet de faire fonctionner des morceaux de javascript dans un processus différent des autres. Ce n'est pas vraiment un "thread", mais ça a le même goût : les processus créés ne se bloquent pas les uns les autres et sont traités de manière efficace par le système d'exploitation.

Pas convaincu ? Après avoir installé Gears, essayez la démo suivante avec workerpool et sans workerpool... on reparlera ensuite des limites de performance de javascript !

Google Gears... une révolution ?

Je ne pouvais décemment pas passer à côté de la sortie du projet sur Google Gears après tous mes articles sur le web offline. Faute de temps, il va néanmoins me falloir faire (très) court sur le sujet pour le moment.

Google Gears arrive en 3 morceaux : workerpool (une solution pour faire tourner le JS hors du runtime habituel du navigateur), localserver (un mini-serveur web pour page stockées en cache) et Database (une base de données SQLite munie d'une API Javascript).

Cela n'a pas grand chose à voir avec l'approche de Dojo Offline Toolkit, mais c'est tout de même très excitant : cette solution est même techniquement à ce point séduisante qu'elle pourrait à terme être inclue dans les systèmes d'exploitation et/ou les navigateurs. On parie ?

Les principales technos RIA enfin comparées

Cela faisait un moment que je recherchais un comparatif clair entre les technologies RIA majeures : n'ayant rien trouvé de satisfaisant, j'ai décidé de faire mon propre comparatif.

Vous trouverez donc ci-dessous Flash, Ajax, Apollo, WPF, Silverlight et Java comparés au regard des critères qui permettent - pour moi - d'apprécier une technologie RIA : dessin vectoriel, animations, multimedia, mode offline, 3D, accès système, besoin d'installation, cross-platform.

	Des. Vect.	Animation	3D	Multimedia	Accès syst.	Offline	Installation	Multi plateforme
Flash	Oui	Oui	Difficile	Oui	Non	Difficile	Plug-in	Oui (dont mobile)
Ajax	Limité	Limitée	Non	Non	Non	Difficile	Non	Oui
Apollo	Oui	Oui	Difficile	Oui	Oui	Oui	Oui	Oui
Silverlight	Oui	Oui	Non	Oui	Non	Non	Plug-in	Windows / MacOSX
WPF	Oui	Oui	Oui	Oui	Oui	Oui	Non	Vista / XP SP2
Java	Oui	Oui	Oui	Perfectible	Oui	Oui	Oui	Oui (dont mobile)

Conclusion ? Java semble être la killer app des RIA ! Le gros problème de ce comparatif, c'est qu'il occulte quelques points importants : performances (et là, Java en prend un coup), et productivité du développement en particulier.

Ma préférence personnelle continue à aller vers Ajax dans la mesure où il peut avantageusement tirer partie de toutes les autres technologies selon les besoins. La productivité du développement reste évidemment son gros problème, mais on y progresse indéniablement.

Et vous, votre opinion ?

HTML 5 sur les rails !

Grande nouvelle : le W3C a accepté d'utiliser le travail du WHATWG comme base de spécification pour HTML5 !

On peut donc affirmer que les grandes avancées proposées jusque là dans les working draft (la balise canvas, les datagrids, la cohérence HTML/DOM/javascript...) ont désormais de grandes chances d'être officiellement recommandées par l'organisme de Tim Berners-Lee.

Je vous invite à relire mon article sur HTML5 pour comprendre à quel point cela est une bonne nouvelle...

Tamarin : le futur de Javascript par Adobe et Mozilla

A une époque où le web est la technologie dominante et Javascript son nouveau ressort, on comprend aisément que ce qui peut révolutionner Javascript peut changer beaucoup de choses par ailleurs.

Javascript, je l'ai déjà dit à de nombreuses reprises est bourré de défauts, et parmi ceux-ci, ses performances calamiteuses n'est pas le moindre. Or, à l'heure où tout est bon pour faire du javascript, cela peut s'avérer très pénible. Pénible au point que notre web 2.0 se surprend à reprendre des couleurs 1.0, lorsque toutes ces jolies fonctions ajax qui facilitent la vie de l'utilisateur se mettent à patiner à un point invraisemblable. Pire : certaines applications (comme la 3D) resteront hors de portée de JS tant que ces limitations ne seront pas levées.

Une fois encore, le problème de vient pas vraiment de javascript en tant que langage mais plutôt des moteurs d'exécutions embarqués dans les différents navigateurs... et c'est précisément là que Tamarin intervient.

Tamarin est le nom de code donné par Adobe à son projet de moteur ecmascript (javascript si vous préférez, la nuance est subtile) destiné à le booster significativement en le compilant Just In Time en code machine (façon Java ou .Net) : une excellente idée... Et Adobe ne s'est pas arrêté en si bon chemin, puisqu'en novembre dernier, le code du projet a été ouvert et que le leadership du projet confié à la fondation Mozilla.

Résultat ? Les applications web de demain pourront être autrement plus exigeantes que les bricolages d'aujourd'hui ! Pour être plus précis, sachez que FlashPlayer 9 utilise déjà Tamarin et Firefox devrait l'intégrer en 2008 (à l'occasion du passage vers Javascript 2). C'est aussi pour cela qu'à contre-courant de l'actualité, je choisis de parler aujourd'hui de ce projet : parce qu'il crédibilise encore un peu plus Ajax et Flash face aux alternatives RIA montantes.

Dojo Offline Toolkit : la beta est sortie

Annoncé dès janvier, Dojo Offline Toolkit fait partie de ces projets qui m'ont immédiatement passionné : visionnaire et pragmatique, DOT répond à un vrai problème (le web offline) avec d'excellentes solutions. J'avais d'ailleurs expliqué le fonctionnement de DOT dans un précédent billet.

L'infatigable Brad Neuberg a sorti une première version bêta hier. Je la qualifierais personnellement de version alpha tant il reste de problèmes à résoudre :
- seules les plate-formes MacOS X et Windows (hors Vista) sont supportées à ce jour
- de nombreux bugs restent à corriger
- la couche de persitance en javascript doit devenir plus indépendante de Dojo

Malgré tout cela, il faut saluer la performance et ne pas hésiter à commencer les tests (et remonter les bugs) sur cette techno sous license BSD et franchement très prometteuse.

Quelques ressources pour aller plus loin :
La FAQ
Une démo (Moxie, un éditeur de texte... attention bugs !)
Le SDK pour les développeurs
Une video expliquant l'intérêt du web offline version DOT

Google "PowerPoint" : le retour de Java sur le web ?

Le web est un truc si riche qu'il retrouve régulièrement de vieilles techniques comme solution à de nouveaux usages :
- c'est ainsi qu'on a redécouvert, il y a 3 ans, Javascript pour enrichir les interfaces
- que Flash redevient une solution acceptable pour de nombreux problèmes
- et que Java pourrait repointer le bout de son nez à la faveur de Google

Je m'explique. Google nous a récemment expliqué que son powerpoint maison (prévu pour l'été) utiliserait une technologie venue d'une boîte rachetée récemment (Tonic Systems). Le site de la boîte en question a disparu mais le cache Google (!) nous apprend que ces gens proposaient une API Java pour faire du powerpoint.

Et alors, me direz-vous ? Et alors, vous dirais-je, il se pourrait fort qu'utiliser Java (côté client) soit une excellente solution pour :
- d'une part, faire du offline/online
- d'autre part, faciliter un certain nombre de fonctions très pénibles pour l'utilisateur web telle que la copie d'images.

Si tout ce que je dis se vérifiait, ça pourrait marquer le retour de Java très intéressant à l'époque des RIA... Et puis jouer les madames Irma ne m'a trop mal réussi jusque là, alors je tente ma chance !

5 bonnes raisons de regarder HTML 5 de plus près

Il paraît que les internautes-lecteurs sont friands de listes en tout genre. Racoleur à mes heures, je me plie aujourd'hui à cet exercice sans rien oublier de mon sacerdoce : livrer aux surfeurs échoués ici une véritable valeur ajoutée informative.

Avant de lister, quelques mots de présentation : HTML5, aussi appelé "web applications 1.0" est une proposition avancée par le WHATWG (think tank du web très écouté, à l'origine par exemple du système de cookies persistants de Firefox 2.0) pour succéder à HTML4/XHTML1. HTML5 est donc à distinguer de XHTML2, qui couvre les travaux actuels du W3C sur le sujet.

HTML5, donc, est un vrai truc emballant, et ce pour au moins 5 raisons :

- HTML5 est pragmatique
le WHATWG ne préconise pas la révolution, mais une évolution qui saura garder une compatibilité avec les pratiques courantes des développeurs web actuels. Ca embête souvent les puristes mais ça permet d'avancer.

- HTML5 est ambitieux
On peut être pragmatique mais ambitieux avec des balises comme canvas pour réaliser des graphiques en javascript ou encore l'élément datagrid qui permettrait de résoudre un problème constant des développeurs Ajax.

- HTML5 est ouvert aux contributions
Les travaux du WhatWG sont ouverts à toutes les contributions (dont la vôtre ?)... contrairement à ceux du W3C.

- HTML5 est pensé pour le web de demain
HTML5 tente de répondre à un grand nombre d'utilisations modernes du HTML : le contenu multimédia, les applications web, ou les échanges entre internautes. HTML5 assume en ce sens définitivement la rupture avec le langage de structuration de données qu'était HTML à l'origine. XHTML2 fait plutôt le chemin inverse en cherchant à nettoyer HTML de ses incohérences avec ses principes initiaux.

- HTML5 est très suivi de ceux qui font le web
Mozilla, Opera, Apple ont récemment et très officiellement demandé au W3C d'utiliser le travail du WhatWG comme d'une base de réflexion pour le nouvel HTML... tout en implémentant en parallèle certaines propositions (telles que canvas) sans attendre une quelconque approbation de ce dernier !

Ext, OpenAjax : la planète Ajax s'organise

Un des doux rêves que caresse plus ou moins consciemment l'intégralité des développeurs Ajax est de disposer de librairies javascript organisées, modulables et répondant à des normes limitant au maximum les problèmes de compatibilité. Bien loin de penser qu'un tel Graal puisse être atteint à court terme, c'est avec un plaisir non dissimulé que je vous fait part du lancement de la bêta de Ext.

Ext est une librairie qui, à son origine, étendait le noyau de Yahoo UI pour mettre à disposition un certain nombre de widgets bien pratiques (calendriers, onglets, sliders...). Bien architecturée, la librairie a pu être rapidement adaptée pour se passer du noyau YahooUI, pour le remplacer par l'excellent JQuery ou encore le célèbre couple Protoype + scriptaculous.

Ext possède à ce jour une vingtaine de widgets d'une grande qualité, mais aussi et surtout une excellente documentation tirant pleinement partie de ext. Au delà de la performance, c'est l'effort de généricité/modularité des auteurs de cette librairie qui me rend optimiste pour l'avenir.

Cette démarche me semble s'inscrire dans un mouvement plus général de rationalisation du petit monde Ajax. Autre fait révélateur de ce mouvement, l'OpenAjax Alliance est en train de sortir de l'impasse dans laquelle je pensais qu'elle se trouvait :
- Google et Microsoft l'ont récemment rejointe
- l'OpenAjax Hub, un ensemble de spécifications à respecter pour les librairies Ajax produites
par les membres de l'Alliance, est sur le point de sortir en version 1.0

Il est assez heureux de voir ajax arriver à maturité à l'heure où les alternatives RIA se multiplient et où les éditeurs se donnent un mal fou à faire venir les développeurs ajax vers leur technologie.

L'heure du choix d'une techno RIA est-elle arrivée ?

Les choses bougent sérieusement côté des techno RIA en ce moment :

- Apollo, le framework, vient de sortir en version alpha
- Microsoft Expression Blend, l'outil de design pour WPF est disponible en évaluation
- le petit monde RubyOnRails propose SlingShot, une alternative alléchante à Apollo
- OpenLaszlo 4.0 est sorti et permet désomais de générer des interfaces
Ajax tout comme des interfaces interprétées par un lecteur Flash.

A vos marques, prêts, testez !

La 3D, le web et javascript

La 3D sur le web est un vieux rêve qui semble être repoussé chaque jour :
- VRML n'a jamais vraiment pris
- X3D son successeur désigné, ne semble pas vraiment prendre la suite
- aucune solution de remplacement n'a réellement émergé

Une fois encore, des hackers javascript se sont retroussé les manches pour parvenir à une solution à l'aide de le nouvelle balise HTML "canvas" (malheureusement inconnue de nos amis de chez Microsoft)... et à ma grande surprise, ça marche ! Du moins, de temps en temps.

Quelques exemples, parce que ça vaut quand même le coup d'oeil :
- une démo d'un moteur de rendu (qui fait ce qu'il peut)
- un jeu en 3D (injouable)
- une démo de voiture avançant une route improbable

Bon, en attendant que tout ça progresse, Flash et WPF semblent pour le moment les alternatives les plus raisonnables... à moins que vous n'ayez une meilleure idée ?

AJAX, JSON et BISON au secours de la bande passante

Dans la formidable époque que nous sommes en train de vivre, le web subit une révolution discrète et pourtant cruciale au royaume de "l'expérience utilisateur" : les applications du web ont en effet maintenant plus que jamais les moyens de réduire considérablement la bande passante utilisée.

Or sous des dehors techniques, cet aspect du web 2.0 est tout sauf un problème de geek :
- pour l'utilisateur, moins de données à faire transiter signifie une meilleure réactivité de l'application à ses différentes actions.
- pour le financier, moins de bande passante entraîne une baisse qui peut être significative des coûts de structure... en particulier dans le cas d'une montée en charge rapide de l'application.

Comment concrètement s'opère cette baisse de consommation ?
- Dans le passé, ce fut AJAX qui permit d'économiser des rechargements de page complets à chaque fois que des appels serveur sont nécessaires.
- Aujourd'hui, c'est JSON (si il est bien utilisé) qui diminue de manière considérable la taille des réponses renvoyées par les serveurs suite à une requête AJAX.
- Demain, ce sera peut-être quelque chose comme BISON (qui n'est qu'une expérimentation) d'une part et le stockage client massif d'autre part qui permettront d'optimiser encore un peu plus le flux d'information transitant entre le serveur et le client.

Google Apps For Your Domain V2 : une killer app pour les PME

On le dit depuis longtemps et ça devient chaque jour qui passe une réalité plus tangible : Google va bientôt devenir un acteur important de l'application d'entreprise. La nouvelle mouture de GAFYD a en effet de nombreux arguments pour convaincre un bon paquet de PME (parole d'utilisateur d'entreprise !) :
- un webmail loin devant les solutions concurrentes
- un système d'édition et de partage de documents terriblement efficace
- un agenda en ligne au top
- une gestion des comptes simple et conviviale
- des possibilités de support et de développements spécifiques enfin dignes d'une société comme Google

Si les équipes commerciales de Google for enterprise sont un peu etoffées en France, ça pourrait changer pas mal de choses dans nos petites entreprises. Surtout que la suite va probablement arriver dans l'année... c'est à dire :
- une solution de PowerPoint-like
- un mode Offline pour les différentes applications
- la poursuite du développement des interfaces Smartphone
- l'intégration à la Google Appliance

Bon courage aux concurrents !

OpenID s'impose comme référence de l'identité numérique

La gestion de notre identité à travers les différents services de l'internet est un des problèmes non résolus qu'avait évoqués oncle Tim O'Reilly dans "what is web 2.0". Petit rappel du problème en question par exemple tout bête...

JB Boisseau est terriblement jaloux du talent et du succès de Fred Cavazza et décide de se venger de ce sale coup du destin en usurpant l'identité de ce dernier.
Comment ? Rien de plus simple : il lui suffit d'aller sur le blog de Loic Lemeur et d'y décharger un flot d'insultes... en signant "Fred Cavazza". N'ayant pas de moyen d'identifier clairement la personne en question, le machiavélique JB Boisseau réussira à déboussoler les internautes 2.0 de passage aisément et ce, potentiellement sur une grande quantité de services.

D'un autre côté, le bon Fred aimerait bien pouvoir bénéficier d'un "single sign-on" sur la toile lui permettant d'accéder à tous ses services avec une seule authentification... chose qu'il lui ferait gagner un temps précieux.

Bien des services ont tenté de s'imposer en tant que standard dans le domaine (où, par définition, il ne peut rester qu'un acteur) et il semble qu'un vainqueur soit en train d'émerger. Le vainqueur en question, serait donc OpenId. Les raisons en sont les suivantes :
- AOL a annoncé à la suite de Microsoft être prêt à utiliser OpenId pour l'authentification à ses services.
- Plusieurs sites web de référence (Digg, Technocrati, MovableType...) ont adopté le système
- Les fournisseurs d'OpenId sont à la fois nombreux et influents : Verisign, JanRain, Sxip, MyOpenID.com..

Bref, si certaines questions se posent encore sur la capacité technique d'OpenId de jouer pleinement son rôle, ce dernier est à ce jour bien mieux que placé que les autres pour remporter la bataille.