XXP

mai 2016

lun. mar. mer. jeu. ven. sam. dim.
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

« La long tail des mashups encore trop short -- dénouement | Accueil | La long tail des mashups encore trop short -- dénouement »

10 septembre 2007

La long tail des mashups encore trop short -- dénouement

Suite et fin heureuse d'une petite série sur les promesses non tenues de la personnalisation "long tail" du Web 2.0.

Donc, nous avons vu que le Web 2.0 tiendra sa promesse de personnalisation du contenu quand l'internaute pourra inclure ses données personnelles au sein des mashups, et que ces données d'intérêt font partie du Web invisible, le plus souvent via des petits sites qui n'exposent ni fils RSS ni APIs ouvertes.

Nous avons aussi vu que la voie est d'offrir à l'internaute un moyen de créer lui-même des widgets (appelons ça un Widget Maker, même si ce terme est déjà employé pour désigner des systèmes ingénieux mais trop complexes pour le non-technicien – Cf. Konfabulator), voie empruntée par des pionniers comme WebWag et Dapper.

Dressons un portrait du Widget Maket idéal pour mieux comprendre pourquoi ceux qui iront jusqu'au bout du Widget Maker grand public devront très probablement choisir une autre solution technique que celle des pionniers.

Les qualités du Widget Maker idéal :

1.    Simplicité, ergonomie. L'interface graphique est intuitive et dénuée de jargon technique.
2.    Accès au web invisible.
3.    Javascript-enabled, capable de gérer entre autres des sites bourrés d'Ajax.
4.    Respect  de la confidentialité des données de l'internaute, en particulier de ses mots de passe.
5.    Autorise une bonne montée en charge. Doit pouvoir rafraîchir des milliers de widgets par heure.

L'impasse du client léger

Le client léger s'accommode sans problème du point 1, le WOD de WebWag le démontre.

En revanche tous les autres points sont des casse-têtes si le navigateur sert de plate-forme technique (attention jargon technique).

Rafraichir les données du Widget personnel de l'utilisateur requiert d'avoir mémorisé tous les échanges entre le navigateur et le ou les serveurs Web pour les rejouer. Cela suppose d'intercepter en JavaScript les submit des formulaires, les clics sur des liens avec target=_blank, la création dynamique d'iFrame dont l'URL a été généré en javascript, les refresh asynchrones d'XmlHttpRequest, et d'autres pièges bien pointus.

Il est tout bonnement impossible d'y parvenir à 100% parce que les navigateurs sont conçus pour éviter ce type d'interception pour des raisons de sécurité : une session de navigation met en œuvre des évènements volontairement inaccessibles au moteur de script et au DOM car gérés par le navigateur. Le vrai chef, c'est le browser, pas le moteur de script, qui est aux bottes du browser. D'où les inextricables difficultés de Dapper, pourtant incroyablement astucieux.

Que des solutions

Positivons.

Points 2 et 3 (javascript, Web invisible) : pour contrôler le browser et non plus seulement la page et les scripts associés, il faut "sortir du navigateur", c-à-d le contrôler par un client "lourd" assis sur le système d'exploitation.

Point 4 : savoir que nos mots de passe sont stockés sur un serveur distant peut être un frein à l'adoption. Ok à la limite pour y laisser un relevé du montant de mon coffre-fort, mais pas les clés… Une solution est de stocker ces données sensibles (et cryptées) sur la machine de l'utilisateur, ce que les navigateurs font très mal (c-à-d très bien jusqu'à ce que l'utilisateur vide son cache), n'ayant pas accès aux disques par sécurité.

Point 5 : Même en supposant que tous les autres points aient été validés, il reste à gérer l'énorme charge en calcul que représentent des millions (bon ok des milliers) de browsers virtuels en train de rafraîchir le contenu de Widgets qui nécessitent JavaScript. Il vaut mieux employer l'astuce du peer-to-peer et du grid computing : le moteur de collecte de données est la machine de l'utilisateur.

En somme les barrières de sécurité des navigateurs rendent extrêmement risqué, pour ne pas dire impossible, la mise en œuvre d'un Widget Maker universel en client léger.

Seule une solution "desktop" peut prendre le contrôle du navigateur, stocker en confiance les données sensibles et offrir de bonnes capacités de monté en charge.

Et tout ça pour quoi ?

Tout ça pour vous dire que je travaille sur un tel projet et que je cherche des partenaires pour le mener à bien. La technologie mise en œuvre a maturé depuis 2002, date de mise en ligne de The Easy Bee, logiciel de collecte de données sur le Web qui répond aux difficultés mentionnées plus haut sans être un Widget Maker. Le logiciel s'est bonifié au fil du temps, pour preuve aujourd'hui des versions plus élaborées (non diponibles en ligne), qui reposent sur le même moteur de collecte qu'Easy Bee, sont exploitées par des clients dans le cadre de la veille sur Internet, ou pour alimenter des sites expérimentaux comme newsblogs.fr ou mashup-news.com.

Il reste à développer un logiciel spécifique basé sur cette techno, avec une chouette interface graphique : c'est un travail en cours.  En avant première, voici un screenshot d'une page netvibes telle que vous ne pouvez en créer avec les outils existants car constituée de données privées issues de sites non-widgetisés (je tiens à préciser que mon compte Paypal n'est pas mon compte en banque...).

Netvibeseasybee_2

Fonctionne aussi avec iGoogle et pourrait sans ploblème être pluggé sur WebWag, BubbleTop, etc.

Serie :
La long tail des mashups encore trop short (in franglais dans the texte) -- Partie 1
La long tail des mashups encore trop short -- Partie 2
La long tail des mashups encore trop short -- Partie 3
La long tail des mashups encore trop short -- dénouement

TrackBack

URL TrackBack de cette note:
https://www.typepad.com/services/trackback/6a00d8341c871f53ef00e54eef306c8834

Listed below are links to weblogs that reference La long tail des mashups encore trop short -- dénouement:

Commentaires

Je me pose quand même une question sur un aspect relatif aux points 2,3 et 4.

Le site web de ma banque, par exemple, utilise une saisie de mots de passe basée sur une matrice de chiffres affichés sous forme d'image (avec bien sur les chiffres qui changent de place à chaque connexion).

Face à une telle interface, que peut faire le meilleur des logiciels, qu'il soit en ligne ou desktop ? Pourra-t-il arriver à analyser l'image en question pour retrouver les bons clicks de souris à interpréter en javascript ?

Là-dessus il y a au moins trois points de vue.

Techniquement, on peut envisager de développer une solution au cas par cas pour chacun des dipositifs anti-robot (CAPTCHAs, Completely Automated Public Turing test to tell Computers and Humans Apart) à grand renfort de réseaux neuronaux par exemple. Mais il est à mon avis impossible de développer une solution générique, le principe des captchas étant de faire appel aux sens, à l'intelligence et à la culture de l'internaute (écrire le nom de l'animal affiché, écouter un message, voir une vidéo,…).

Ergonomiquement, le logiciel qui permettrait de contourner les captchas deviendrait de plus en plus complexe (je ne parle pas des coûts croissants de R&D dans la course à l'armement captcha/anti-captcha), ce qui est à l'opposé de l'objectif de simplicité d'un widget maker "grand public".

Ethiquement, mettre en œuvre des hacks anti-captchas s'opposerait à la volonté manifeste des gérants du site d'empêcher les robots d'y pénétrer. Mettre sur le marché un logiciel de piratage, c'est pas mon truc…

Au total il est sans doute plus simple et plus cohérent d'avertir clairement l'utilisateur du logiciel que le site protégé par captchas ne souhaite pas être "widgetisé" (après lecture du fichier robots.txt), et que l'agent widget peut ne pas fonctionner.

Hello!
Nice site ;)
Bye

L'utilisation des commentaires est désactivée pour cette note.