Rich Client, Interface riche, Rich Internet Application : les termes ne manquent pas pour désigner ces applications qui se connectent à des serveurs d'application comme le ferait un navigateur web classique, mais en proposant une interface plus avancée que le HTML traditionnel, et des fonctionnalités jusqu'alors difficiles à mettre en œuvre (mode déconnecté par exemple).
Bref des interfaces combinant les avantages du client "léger" et du client "lourd". Des voix se sont élevées pour dénoncer le retour masqué du client-serveur… Rien de neuf sous le soleil en quelque sorte. Pourtant le Rich Client pourrait bien préparer une révolution en profondeur des applications Web, notamment grand public.
Client et Serveur : des phases de maturité différentes
Il est assez étonnant de constater la disproportion des efforts investis au cours des dix dernières années entre la partie Serveur et la partie Cliente des applications.
Certes la partie Serveur concentre l'essentiel des développements. Certes la partie Cliente évolue dans un cadre imposé qui est celui du navigateur Web, naturellement restrictif. Pourtant, d'un côté les applications Web sont passées du stade de "CGIs" à celles d'architectures orientées services (autrement dit, des années lumières d'écart) ; de l'autre, les interfaces Web telles que nous les développions il y a dix ans n'ont finalement que très peu évolué.
Bien sûr en dix ans nous avons gagné en standardisation d'interface, en homogénéisation. Avec beaucoup d'efforts nous arrivons à simuler - en moins bien - l'ergonomie des applications bureautiques lorsque cela s'avère nécessaire.
Mais si nous nous étions trompés ? Si le succès des applications (en particulier grand public) passait d'abord par l'interface entre l'utilisateur et la partie serveur ? Et si nous nous étions auto-restreints à une ergonomie médiocre, dont seuls quelques acteurs comme Apple ont réussi - avec succès - à se libérer ? Si finalement tout restait à inventer ?
Voici probablement la promesse du Rich Client : faire progresser la partie Cliente autant que la partie Serveur a pu progresser en 10 ans. Pratiquement tout reste à faire.
Typologie des solutions Rich Client
Il y a des signes qui ne trompent pas : le nombre d'acteurs et de technologies qui se bousculent sur le marché du Rich Client n'est pas sans rappeler l'explosion des technologies Serveur il y a quelques années. Pas facile d'y retrouver son latin dans cette jungle technologique. Néanmoins on peut catégoriser les solutions Rich Client :
- Les applications HTML "nouvelle génération" : en s'appuyant sur des solutions de type AJAX (Asynchronous Javascript and XML), ou en proposant des composants Javascript avancés (support du drag'n drop par exemple) ces technologies font évoluer "sans rupture" les applications Web classiques, avec de réels apports du point de vue ergonomie : des parties de page peuvent notamment se rafraîchir sans recharger l'ensemble de la page, ce qui constitue une avancée majeure.
- Les applications Flash : le client est toujours le navigateur Web, mais c'est un "container" Flash qui prend en charge l'ensemble de l'application, en dialoguant via services Web ou Flash Remoting avec la partie Serveur. L'interface est construite soit de manière très classique (par exemple avec Macromedia Flash MX), soit à partir d'une description XML des composants de l'interface, traitée côté serveur, pour générer le Flash renvoyé côté client (exemples : Macromedia Flex ou Laszlo).
- Les applications Java (et oui, ne les oublions pas) : soit sous forme d'applets, soit sous forme d'application auto-déployables via Internet. Ici encore, une myriade de sous-possibilités ; utilisation de la technologie IBM Workplace, utilisation du socle Eclipse, Java "classique"…
- Les applications .NET dites "Smart Client" : auto déployables, avec une durée de vie paramétrable, pouvant se mettre à jour automatiquement, ces applications reposent sur le socle .NET.
- Les applications Windows "classiques" mais qui dialoguent avec la partie Serveur via http, par le biais ou non de services Web.
- Les applications orientées "formulaires", type Microsoft InfoPath : l'application est déployée une fois pour toute, et ce sont des formulaires dont la structure est décrite par un schéma XML qui sont pris en charge par l'application. Les formulaires dialoguent via XML avec la partie Serveur.
- Les applications qui dans la même lignée utilisent le XML pour décrire leur interface, cette interface étant générée côté client ou côté serveur : nous citions Flex, mais nous pourrions également citer XUL, XAML.
- Ajoutons à cela toutes les technologies dites "Rich Media", qui permettent d'intégrer à l'interface homme-machine de l'audio et de la vidéo synchronisés avec les actions de l'utilisateur.
La liste est loin d'être terminée, mais ce premier panorama donne l'éventail des possibilités.
Typologie des acteurs
Sur ce marché qui s'apprête à exploser, les acteurs avec lesquels il va falloir compter sont pratiquement déjà en place.
On peut d'ores et déjà citer les 4 plus importants : IBM, Microsoft, Adobe et…le libre. IBM dispose avec son expérience Lotus d'une très bonne connaissance des problématiques client riche, notamment sur la gestion du mode déconnecté.
L'atout de Microsoft réside dans la simplicité de mise en œuvre des applications Smart Client. Ces deux acteurs sont pratiquement incontournables sur tous les domaines, il est logique de les retrouver ici.
Adobe, en dépit de sa position de challenger, est pourtant l'un des mieux positionnés pour attaquer ce marché. L'acquisition de Macromedia lui permet de disposer d'un parc de runtime Flash (auquel s'ajoute celui d'Acrobat) qui peut faire pâlir d'envie IBM et Microsoft.
Mais le monde du libre est incontestablement le quatrième acteur avec lequel il va falloir compter. Rarement une telle énergie créatrice aura été dépensée pour proposer des solutions, souvent très abouties. Notamment pour créer des applications Rich Client reposant sur Flash (l'exemple de Laszlo est plutôt l'arbre qui cache la forêt).
Nul doute que les trois premiers acteurs, à commencer par Adobe, se seraient peut être bien passés de cette concurrence.
Le Rich Client, nouvel interlocuteur des architectures orientées services
La technologie Rich Client tombe à point nommé au moment où les architectures orientées services arrivent à maturité. Si les applications ont été bien pensées, avec des services de bonne granularité, le passage d'un client HTML classique à un client riche n'aura que peu d'impact sur la partie Serveur. L'ensemble des efforts pourront donc se concentrer sur le client, avec une réutilisation maximale des services existants.
Le Rich Client bouleverse les parts de marché
Cela dit, est ce que le Rich Client crée réellement de la valeur ? Est-ce qu'il va permettre aux entreprises présentes sur Internet de renforcer leurs parts de marché ? Ou s'agit-il d'une innovation technologique sans finalement grand intérêt d'un point de vue business ?
Deux exemples permettent déjà d'esquisser des réponses : Skype et Itunes se sont rapidement imposés en faisant le pari d'un client riche dialoguant en HTTP avec des tiers (que ce soit sur des architectures peer to peer ou centralisées).
Une ergonomie simple, efficace et très aboutie combinée à des fonctionnalités à vraie valeur ajoutée permet de prendre position très rapidement, pour ensuite proposer des services qui vont renforcer "l'accoutumance" au produit. Côté Skype : Skype-In, Skype-Out, répondeur… Coté iTunes : les Podcasts par exemple.
Ces deux exemples montrent que sur des marchés soi-disant déjà saturés (Skype sur le marché de la messagerie instantanée, iTunes sur le marché de la vente de musique en ligne) on peut créer de véritables brèches. Sur les applications e-commerce, le champ des possibles est colossal, car les utilisateurs attendent finalement peut-être d'autres interfaces pour acheter. Ceux qui réussiront à combiner audace et efficacité pourraient bien bouleverser à cette occasion des marchés déjà établis.
Une mise en œuvre pas si évidente
La mise en œuvre de ces solutions Rich Client peut, à première vue, paraître simple. Pourtant elle est loin d'être évidente. Pourquoi ? Le schéma classique de production en HTML (les infographistes maquettent sous Photoshop, les maquettes validées sont montées en page HTML par des monteurs, les modèles ainsi construits sont utilisés par les développeurs) vole en éclat.
La valeur ajoutée de ces interfaces tient à leur dynamisme, à leur ergonomie qui dépasse ce qui se réalise classiquement en HTML. Le maquettage sous Photoshop n'est pas évident car il ne peut représenter la dynamique que l'on souhaite matérialiser. Le maquettage doit très rapidement se faire dans l'environnement de développement du client riche (Flash ou autre) par des équipes très polyvalentes, compétentes sur les aspects infographie, ergonomie, business.
Le développement final doit lui aussi être réalisé avec vigilance, et requiert de bonnes compétences puisqu'il faudra dialoguer avec des architectures orientées services, en maîtrisant la performance, les éventuelles problématiques d'auto-déploiement, de sécurité… Quitte d'ailleurs à refaire une surcouche de services au dessus des applications serveur existantes, plus adaptée au type de dialogue que l'on souhaite réaliser avec le client.
Bref pas mal de pain sur la planche, mais à la clé de véritables leviers de différenciation.
|
Jean-Louis Bénard