Vous le savez sûrement déjà, Mozilla a annoncé il y a peu Prism. Cette nouveauté vous permettra de pouvoir exécuter vos applications web à l'extérieur de votre navigateur, profitant d'un lien plus direct vers vous, l'utilisateur. On peut donc parler de technologie RDA, bien que actuellement Prism est plutôt un "conteneur". Le but est tout simplement de pouvoir proposer des applications web directement accessible depuis votre bureau, comme par exemple Gmail, GCalendar, Zoho, etc. Les plus nommées sont de vraies applications au sens propre du terme (organizer, calendrier, etc.) et montre donc un peu la cible souhaitée de Prism. Plutôt que de décrire les fonctionnalités de Prism, je souhaite revenir sur deux aspects très intéressants autour de cette initiative.


Tout d'abord la "roadmap" de Prism, dont on peut lire quelques idées sur l'excellent blog d'Alex Faaborg. Au menu donc, une meilleure intégration au niveau du bureau (icônes réduites, du drag and drop), des notions autour de la sécurité (sujet très délicat et très intéressant), un mode connecté-déconnecté (sachant que cela est prévu dans Firefox 3), etc. En résumé, on voit là un ensemble de notions qui correspondent totalement aux définitions des RDA que l'on peut se faire. Et c'est une très bonne nouvelle de voir Mozilla se lancer officiellement dans ce domaine ; ayant bien débattu autour de XULRunner, je pense que l'apparition de Prism (non simple, très ciblé sur les RDA, s'affiche en concurrent direct d'AIR et de WPF (et non Silverlight), etc.) est tout à fait logique et bien venue. Mozilla, de part sa position dans le monde de l'open source et du navigateur, ne pouvait pas ignorer le domaine des RDA.


Au delà de ça, l'investissement de Mozilla et surtout le nouveau positionnement (je rappelle que Prism n'est "que" WebRunner renommé) valide l'importance que l'on pourrait avoir autour des RDA, que ce soit autour des fonctionnalités offertes ou de son but. Je m'explique : en se basant également sur un modèle connecté-déconnecté, en mettant en avant l'expérience utilisateur tirée du rapprochement entre l'application et l'utilisateur, en offrant aux webapp une plus forte indépendance en s'affranchissant du navigateur.

Au final, je retiendrais cette phrase tout à fait pertinente autour des RDA : cela regroupe le meilleure des deux mondes (le web et le bureau). A suivre...

J'ai pu récupérer une invitation Pownce via Ouriel Ohayon (merci encore !) et ai donc commencé à tester ce service. Pour ceux qui ne le connaissent encore pas, voici un petit résumé très personnel :

Vous prenez Twitter, et vous ajoutez l'envoi de liens, de fichiers (10Mo) et d'événements : cela vous donne Pownce. Facile, non ?


Pour les pownceurs, vous pouvez m'ajouter via mon pseudo : FabienD.

Je trouve ce service excellent sur le papier, car ajoutant des fonctionnalités très utiles par rapport à Twitter. J'apprécie beaucoup l'interface, très propre, simple et intuitive (du vrai web 2.0, pas du twitter tout laid !). Et surtout, le client RDA (basé sur Adobe AIR) est très pratique, si ce n'est deux trois défauts. Toutefois, le service n'a t'il pas été lancé trop vite ? En effet, il y a déjà eu quelques problèmes d'accès hier dans la journée... Il y aurait également de nombreuses améliorations à ajouter pour en faire une killer-app : pourquoi ne pas tout simplement réutiliser l'API Twitter et ainsi rapatrier les twits sur Pownce ? Cela éviterait la duplication de ce genre d'outils...

Je garde donc ce service sous un bon oeil, en espérant très fortement y voir des améliorations régulières : le potentiel est à mon avis supérieur à celui de Twitter : je suis donc plus à même d'être utilisateur fréquent (contrairement à Twitter auquel j'accroche tout de même difficilement).


J'ai donc pu récupérer des invitations pour Pownce ! Et j'en offre donc cinq aux premiers qui posteront un commentaire m'expliquant en quoi ils pensent que Pownce peut devenir meilleur que Twitter ou inversement (un peu de débat ne fera pas de mal !).

• de vous résumer cet article en français
• de donner en parallèle mon avis sur certains points

• San Dimas d'eBay
• Muse de SAP
• Ascension, le lecteur média
• Les applications présentées par Christian Cantrell

Les forces

Les faiblesses et les craintes

Les opportunités

• Les utilisateurs professionnels
• Les utilisateurs finaux - consommateurs
• Les utilisateurs finaux - processus longs ou moyens gérés seuls
• Les groupes d'utilisateurs
• Les utilisateurs finaux - utilisation personnelle

A l'arrivée d'une nouvelle "technologie", ou plutôt d'une nouvelle évolution, arrive également sa flopée d'enthousiastes et de fans qui n'écoutent que leur foi et leur admiration envers ce qu'ils annoncent comme la nouvelle bombe. Arrive aussi ses détracteurs, toujours prêts à critiquer, et souvent sans savoir. Mais parmi ces derniers se trouvent des gens qui pointent de véritables défauts, des vérités masquées que les enthousiastes connaissent pour certains mais dissimulent sous d'autres termes. Maintenant que débarquent les Rich Desktop Applications, on peut donc essayer de se poser les bonnes questions sur cette évolution des applications. En se basant sur deux exemples technologiques : WPF/E et Apollo.

Que va apporter une Rich Desktop Application comparée à une application de bureau "classique" ?

Prenons donc les choses dans l'ordre et démarquons les RDA de leur équivalent lourd. Une Rich Desktop Application apporte de nouveaux éléments, ce "rich" qui se veut porteur de nombreux changements selon deux axes : un axe développement et un axe utilisateur.

Concernant le développement, une RDA n'arrive pas seule : elle s'accompagne de son IDE (environnement de développement) graphique, d'une grammaire de description d'interface, d'interactions fortes avec des éléments de graphismes. Illustrons-donc ceci :

• Apollo se base sur le Flex Builder, un outil de développement spécialement conçu pour le développement d'interface riche. WPF/E se base sur Visual Studio, et sera intégré à la prochaine version. Les interfaces sont faciles à créer : un simple glisser-déposer suffit pour créer sa fenêtre. Cela existait déjà avant, mais pas dans cette optique unique de création d'interface.
• A ce jour, le XML a su trouver sa place dans de nombreux standards du fait que c'est un langage verbeux, simple et rapidement parlant. Quoi donc de plus pratique que de décrire des interfaces via ce langage, comme le XAML de Microsoft ou le MXML d'Adobe ?
• Les machines sont plus puissantes et le développeur d'application lambda peut se permettre d'apporter du graphisme vectoriel ou même 3D dans ses applications, sans pour autant faire fuir l'utilisateur. Ainsi, Apollo et WPF/E se basent sur des outils graphiques ayant fait leur preuves pour concevoir entièrement leur applications, comme le Flash et ses dix années d'expérience ou DirectX, une référence.

On voit donc un intérêt bien plus centré sur l'interface, tout en gardant les possibilités de back-office tout aussi grande (interactions Java ou .NET). Le développeur peut se centrer sur cet aspect attirant, et se rapprocher ainsi du graphiste pour des développements plus adaptés aux besoins utilisateurs, et l'on se rend bien compte à quel point l'utilisateur est l'acteur clé de toute application de nos jours.

Concernant l'utilisateur, là aussi les différences sont nombreuses. Tout d'abord au niveau des fonctionnalités :

• Plus besoin de navigateur pour accéder à des pages du Web.
• Les contenus vidéos et audios sont directement utilisables par les RDA, donc pas besoin de multiplier les applications : Apollo surtout les vidéos en Flash, les mp3 ; WPF/E lit les vidéos wmv, etc.
• Il n'y a plus cette dépendance vis-à-vis d'une connexion Internet : les applications peuvent conserver les données en cache, et se synchronise par la suite. Ainsi on peut imaginer consulter ses mails offline, en rédiger et que ceux-ci soient envoyés dès l'arrivée d'une connexion.

Ensuite, mais je n'insisterais pas à nouveau, les graphismes qui pourront être proposés sont tout d'abord facile à mettre en place donc apparaîtront en nombre, et sont également innovants en proposant certains effets qui sont du jamais-vu pour un utilisateur quelconque (exemples : transparence de l'application avec le bureau derrière, effet de rotation sur des pages HTML, 3D intégrée et appliquée à des écrans d'interface, etc.).

Enfin, les RDA (tout du moins certaines, dont celles dont je parle dans cet article) sont interopérables, c'est à dire qu'elles fonctionneront aussi bien sous Windows (XP, Vista), que sous MacOS ou Linux. Bien évidemment, on a du mal à croire le support total de Linux par Microsoft, mais laissons leur une chance.

Ainsi, pour toutes ces raisons et bien d'autres encore que je n'ai pas abordées, les RDA apportent de la nouveauté et ne sont pas qu'un buzz supplémentaire.

Alors que les services en ligne fleurissent, comment relancer les applications de bureau ?

Tout d'abord, il faut bien cerner que le client lourd n'est jamais mort. Il évolue lui aussi, et il est vrai que son utilisation est certainement moindre par rapport aux précédentes années. Néanmoins, il faut souligner que :

• L'utilisation de certains outils de bureau (suite bureautique, lecteur multimédia) n'a jamais pu être portée sur le net. On pense bien évidemment à Google Docs par exemple, mais combien parmi vous l'utilise tout le temps et n'utilise plus Word ? Certes, ces outils sont utilisés par certaines personnes, mais la grande majorité (ainsi que le monde de l'entreprise) ne déporte pas certaines applications pour des raisons évidentes : les services Web sont limités technologiquement (HTML) et surtout ne sont pas fait pour remplacer l'existant. On le voit, les services qui marchent bien en ce moment (citons digg, flickr, youtube) n'ont pas d'équivalent de bureau, et pour cause : ils se basent sur de nouveaux concepts. Ces derniers ne remplacent donc en rien les applications de bureau.
• Certes il y a des exceptions, et pas des moindres : les boîtes mails sont maintenant en ligne, les calendriers aussi, les portails d'entreprise préfèrent les clients légers, etc. Pourquoi remplacent-ils les applications de bureau ? Quelles sont leurs qualités ? Simplicité d'utilisation, pas besoin d'installer de logiciel, accessible de tout endroit connecté, partage des informations, etc. Des qualités essentiellement tournée sur la facilité d'utilisation et donc son ouverture vers n'importe quel utilisateur. Maintenant, imaginons une application de bureau riche qui voudrait faire office, par exemple, d'agenda électronique : noter ses rendez-vous, consulter ses mails, accéder à un espace de données partagée de travail et un personnel, etc. Une application riche proposerait donc : l'installation d'une unique application (comme un navigateur web), le partage des données entre les applications, le portage entre les plates-formes (imaginez-vous au travail sur Windows et à la maison sous MacOS), orienté ergonomie (n'oublions pas que ce sont des outils spécifiquement créés pour faire des interfaces) et accessible n'importe où et n'importe quand ! Plus besoin d'Internet pour ajouter des événements sur mon calendrier partagé, plus besoin de capter la borne Wifi pour aller rédiger mon mail, etc. En conclusion : les mêmes avantages plus l'accessibilité hors-ligne, et le défaut (minime) de l'installation du logiciel.
• Je dis défaut minime car il est vrai que le fait de devoir installer un logiciel peut repousser l'utilisateur. Quand on trouve un équivalent connecté, on préfère se tourner vers lui. Mais si l'application propose des services que l'on ne trouve pas sur le net, alors je pense que l'utilisateur n'hésite pas à installer le logiciel (surtout si il vient d'un éditeur connu). Des exemples simples : Google Earth, iTunes, MSN, etc.

On peut donc en tirer comme conclusion que les applications de bureau ont dans la mesure du possible été remplacés par leur équivalent connecté. Mais d'autres applications de bureau subsistent de part l'incapacité à porter ces services en ligne. L'avenir des applications de bureau riches se présentent donc ici : proposer un service tirant avantage d'un modèle en ligne, en ajoutant une valeur ajoutée qu'on trouve sur une application de bureau. Et cela passe par la qualité de ce que propose l'application. Mais cela, riche ou pas, toute application doit en proposer pour connaître un certain succès.

Comment sensibiliser le public à cette nouvelle approche ?

A peine parle t'on à un public large de la nouvelle place de l'Internet, de ses nouveaux services centrés sur l'utilisateur, que déjà l'on voudrait leur faire part d'une nouvelle approche, d'une déportation du web vers le bureau, etc. Cela semble tout de même très confus, alors que l'on voyait le problème dans l'autre sens il y a peu (comment tout déporter sur Internet). Pour sensibiliser le public, il faut donc mettre de l'ordre dans ces choses, présenter clairement ce que sont les applications de bureau riches, ce qu'on peut faire avec et ce qu'on ne peut pas. Ainsi, cela passe par plusieurs étapes :

• La première à franchir doit venir des éditeurs eux-mêmes. C'est à eux de créer les premières applications, et surtout de créer celles qui attireront, qui plairont et qui seront utilisées. Il ne faut surtout pas tomber dans le showcase, dans le concours de l'application la plus flashy, la plus sexy. Il faut mettre en avant ses qualités, en les liant avec de l'existant pour valoriser ces technologies. Personnellement, je trouve qu'Adobe et Microsoft se débrouillent plutôt bien pour le moment. Alors que leurs plates-formes ne sont pas encore sorties, on peut déjà voir des exemples d'applications : une RDA pour eBay, une autre pour la Fnac, etc. Aussi faut-il continuer dans cette voie, tout en tentant de s'ouvrir au grand public via le pouvoir de communication de grandes sociétés du Web proposant des services. En effet, si par exemple Google sortait sa suite bureautique en application de bureau, cela aurait un véritable impact.
• La seconde étape sera celle des développeurs. Si les développeurs adhèrent à ce nouveau modèle, cherchent à travailler sur ce nouveau concept en ligne / hors ligne, travaillent leur ergonomie et arrivent à proposer des applications de qualités, proposant de nouveaux services comme l'on peut le voir dès à présent avec cette vague de nouveaux services Web 2.0, alors le "buzz" des applications riches pourra être lancé sur ce fort outil de communication que représente la blogosphère.
• Au delà, on peut également souhaiter voir de nouvelles innovations, de nouvelles façons de communiquer l'information ; une nouvelle évolution doit également apparaître avec ces nouveaux concepts. Mais quels sont-ils ? Technologiquement, nous les connaissons même si ils restent parfois flous (en ligne / hors ligne, multi plates-formes, gestion de multimédia). Fonctionnellement parlant, que peut-on tirer de ces nouveaux outils ? Il faut une réflexion poussée sur ce sujet, et cela ne pourra venir qu'avec l'expérience du développement d'applications riches de bureau, la collecte des réactions des utilisateurs, l'impact qui sera fait. En clair, il faut s'intéresser à ce modèle, l'étudier pour qu'il arrive à maturité rapidement.

Adobe et Microsoft ont fait le pari des RDA. On peut supposer que derrière ceci, il y a une réflexion déjà poussée sur l'apport que ces dernières engendreront. On peut également penser voir arriver de nouveau concurrents dans ce domaine, et on l'espère. Ceci prouve bien qu'il y a un potentiel derrière cette évolution. Si l'ensemble des personnes concernées par ces applications arrivent à pousser leurs réflexions vers une richesse, profitant du meilleur de ce que peut apporter la technologie, alors on peut espérer franchir une étape supplémentaire vers une interaction plus fluide et plus bénéfique entre l'utilisateur et sa machine.

Que nous reste-t-il à découvrir des RDA ?

Il est encore difficile de parler concrètement des RDA alors que nous n'en sommes encore qu'à une période de découverte. Il n'existe pour le moment qu'une version "preview" de WPF/E, et bientôt une alpha d'Apollo. Les versions définitives n'apparaîtront qu'à partir de mi-2007. Mais déjà on peut mettre l'accent sur certains points qui peuvent nous interroger, nous rendre sceptique ou tout simplement nous intéresser.

• Comment sera géré un domaine aussi sensible que la sécurité des informations si, par exemple, on donne la possibilité à une application d'accéder au système de fichier ? A l'heure qu'il est, nous n'avons évidemment que peu de pistes sur ce point, qui est certainement l'un des plus importants pour arriver à acquérir une crédibilité au niveau des professionnels. Le doute est permis, mais pas tellement plus qu'avec une application de bureau "classique". N'étant pas expert en sécurité, je n'oserais me prononcer sur les bonnes solutions et les dangers qui résulteraient de ce genre d'application. Néanmoins il serait fort intelligent de pouvoir mettre en place un système d'authentification de la provenance des applications, garantissant ainsi une certaine sureté nécessaire.
• L'interopérabilité sera-t-elle réelle ? Beaucoup de gens peuvent effectivement se poser la question. Microsoft sur Linux ? On croirait rêver, et on ne demande qu'à voir. Néanmoins c'est un point à ne pas négliger, il faut laisser l'utilisateur être libre d'utiliser ce qu'il lui plaît, sans contrainte matérielle. On peut aussi craindre un portage inégal entre les différentes plates-formes. Concernant Apollo, le Flash Player a connu du retard sur sa version Linux, mais la voici présente. Peut-on garantir que les utilisateurs linuxiens ne seront-ils pas lésés ? C'est encore une question qu'il faut garder de coté et ressortir dans quelques mois, quand les versions définitives arriveront.
• Quelles sont les limites des RDA ? A force de vouloir jouer sur la caractère très graphique et la panoplie d'effets allant avec, ne risque-t-on pas de se retrouver avec des applications lourdes, longues à se lancer, bref désagréables à utiliser ? Il ne faut pas croire que tout est désormais permis : l'utilisabilité, et notamment la compatibilité avec du matériel plus ancien est un enjeu important auquel il faut se contenir. Il est technologiquement possible de faire des interfaces très puissantes, garnies de 3d, etc. Est-ce bien raisonnable ? Il faut définir clairement les limites des applications riches de bureau : elles restent des applications, et ne doivent pas devenir des outils purement graphiques qui en mettent plein les yeux mais qui excluent des utilisateurs ou desservent la qualité du service fourni au profit de l'explosion d'effets graphiques. Jusqu'où peut-on aller ? Là encore il est un peu tôt pour se prononcer.
• Enfin dernier point de réflexion, comment réagiront les concurrents ? Je parle d'Apollo et de WPF/E, mais XUL fait aussi partie de ces technologies pouvant produire des RDA. Apple va t'il proposer un outil basé sur QuickTime ? Découvrirons-nous de nouvelles solutions totalement open-source ? Le futur est à surveiller, il y a surement d'autres technologies basées sur d'autres postulats qui pourront prétendre à faire partie de cette évolution.

Il reste donc beaucoup de points obscurs concernant les RDA. Le temps nous en apprendra certainement plus, alors soyons patients. Discutons de ce que nous pouvons discuter, et attendons pour élargir la discussion.

En conclusion

L'heure des Rich Desktop Applications approche. On en parle, on en débat : c'est bon signe. 2007, l'année des RDA ? Plutôt l'année de la découverte, celle où l'on va tâter le terrain, voir ce que l'avenir nous réserve. Comment réagiront les utilisateurs ? Tout ceci arrive et il est temps de prévoir ce qui peut arriver, d'en discuter pour faire de cette évolution quelque chose de bénéfique pour l'Internet et l'utilisation des données faites par vous, l'utilisateur.