La table ronde sur le futur des applications Web, qui a eu lieu dans le cadre du lancement d’eXo WebOS, a été filmé et vous pouvez voir la video sur le blog d’eXoPlatform.

Crédit photo : Didier Girard

Sur la photo :
Michael Chaize (Adobe)
Christophe Lauer (Microsoft)
Eric Mahe (Sun)
Tristan Nitot (Mozilla)
Dave Armstrong (Google)
Benjamin Mestrallet (eXo Platform)
Christian Fauré (Atos Origin)

Related posts:

1. eXo Enterprise WebOS J’aurai le plaisir d’animer la table ronde qui aura lieu...
2. Le code collaboratif en ligne Tristan Nitot se fait l’écho du lancement de Bespin par...
3. Adobe RIA 2008 A l’invitation d’Adobe, Je ferai l’allocution d’ouverture de l’évènement annuel...

J’aurai le plaisir d’animer la table ronde qui aura lieu lors du lancement officiel de la dernière mouture d’eXoPlatform le 18 Avril prochain.
Une table ronde avec du beau monde puisque seront présents :

• Mozilla Europe, Tristan Nitot (Founder and Chairman)
• Microsoft, Christophe Lauer (Web Platform Evangelist at Microsoft France)
• Sun Microsystems, Eric Mahe (New Technologies Manager)
• Google, Dave Armstrong (Product Marketing Manager)
• eXo Platform, Benjamin Mestrallet, Founder
• Adobe, Michaël Chaize

La thématique sera : « Quel avenir pour les applications Web ? »

Related posts:

1. Table ronde sur le futur des applications Web La table ronde sur le futur des applications Web, qui...
2. SUN bascule la totalité de son informatique « on the cloud » Avec plus de 30 000 employés, on ne peut pas...
3. Ironie du sort Le « slogan » de Microsoft pour décliner sa mutation vers le...

Toutes nos condoléances aux entreprises qui avaient un lien de parenté avec les architectures de service SOAP.

Vous pouvez lire l’épitaphe chez Aurélien Pelletier.

Related posts:

1. Architecture Orientée Ressources J’ai pu avoir un avant goût de la présentation que...
2. Ars Industrialis sur Twitter Vous pouvez à présent suivre l’actualité d’Ars Industrialis sur Twitter....
3. C’est clair, non ? Le site twitteradar vous tient informé de l’actualité du service...

Exodus est le nom de code que je donne à un processus de grammatisation dans lequel toutes les entreprises sont engagées, qu’elles en aient conscience ou non.
De quelle exode s’agit-il ?

Il s’agit de l’exode des données des systèmes d’information legacy vers le web. C’est la migration des données, non pas de telle application vers telle autre application, mais des applications vers le web.
Le web est la plateforme dit-on. Mieux que çà, le web est le milieu, l’environnement dans lequel des plateformes commencent à se constituer. La tendance majeure, qui correspond à un vrai changement de paradigme, c’est d’avoir les données sur web. Nous allons vers un web of data :

• avec le web 2.0, ce sont les données fournies par les utilisateurs qui ont commencé à migrer sur le web ; une toute nouvelle économie est naît, bousculant la plupart des acteurs économiques traditionnels.

• avec le SaaS, pour les entreprises, ce sont des données de l’entreprise qui sont sur le web : data on the web. Et tout les éditeurs traditionnels de logiciels doivent faire en ce moment des choix cruciaux, quand ce n’est pas déjà fait).

• avec le Web 3.0 et le Semantic Web, c’est le « web of data » qui se constitue, et ce n’est pas seulement des datas sur le web.

La référence biblique à l’Exode est bien évidemment voulue, mais c’est ici une version moderne, technologique, industrielle et économique qui se joue.

Au départ, et pour les systèmes d’information des entreprises, il y a donc les « dix plaies de l’égypte » :

1. Des systèmes dont les coûts de maintenance deviennent insupportables.
2. L’incapacité à provoquer des échanges et des partages : quand les données ne se mélangent pas, les pratiques ne peuvent pas suivre.
3. Des projets pharaoniques qui explosent les budgets et qui, pour une majorité d’entre eux, n’aboutissent jamais, ou accouchent d’une souris.
4. Une frustration croissante des utilisateurs internes qui se demandent « pourquoi à la maison avec les service web 2.0 c’est si simple » ?
5. Des contraintes à n’en plus finir où, pour être compliant, il faudrait ne jamais se logger au SI de l’entreprise.
6. L’accès à l’information qui relève plus de l’archéologie que d’une « user expérience » apportée par les services 2.0.
7. Des prestations de codage et de recodage des tuyaux entre des applications qui n’utilisent pas la même sémantique
8. Des fuites de l’information avec des salariés qui utilisent des solutions web hors du système d’information, mais avec des données de l’entreprise.
9. Des données difficilement accessibles en situation de mobilité.
10. Une perte d’intérêt et de motivation généralisée dans l’utilisation du système d’information, alors même que les ressources humaines s’éfforcent de trouver des leviers pour redonner de la motivation aux salariés.

Puis virent les 10 commandements :

1. La simplicité toujours tu choisiras
2. L’hébergement des données n’est pas ton métier, toujours tu étudieras l’opportunité de faire héberger tes données par un tiers.
3. La visibilité budgétaire tu privilégieras, et seul le coût d’usage et par utilisateur tu mesureras.
4. Ne réinvente pas ce qui est déjà fait et qui est proposé par un acteur bénéficiant des coûts induits par une économie d’échelle.
5. L’information est un capital, et comme tout capital il doit circuler ; jamais dans des bases de données propriétaires tu ne les enfouiras. Tu passeras de la logique applicative à la logique informationnelle.
6. Les clés de ton système d’information à un ERP jamais tu ne confieras.
7. De la tentation d’architecture de service en SOAP tu te méfieras, car les architecture REST seules sont réalistes et scalables.
8. Des solutions grand public tu te rapprocheras le plus.
9. Le web est la plateforme des plateformes, et sur elle tu construira ton système d’information.
10. Les données sont faites pour être échangées, combinées : vers des mashups de données structurées tu t’engageras, et sur les APIs tu seras vigilant.

Une exode, ce n’est pas un « switch », et ce n’est pas en un claquement de doigt que cela se fait. Il faut scanner l’ensemble de ses processus (IT, fonctionnels, métiers) et, pour chacun d’eux, identifier les opportunités (financières et fonctionnelles) de basculer les données sur le web.

Quand je dis « sur le web », cela veut dire en conformité avec l’architecture du web. Cela peut être un intranet en interne, en hébergement externe ou directement sur le web dans les data center d’une solution SaaS (software as a Service).
Ce qu’il faut c’est :

• S’assurer que les architectures soient full web (et pas seulement webisées pour faire de l’affichage en html)
• Les services doivent être les plus simples et unitaires possibles : comme me le faisait remarquer Louis Naugès, si un service de gestion RH (en mode SaaS par exemple) propose en même temps un service de calendrier, et bien ce n’est pas bon. Vous en avez déjà un, Google Calendar par exemple, donc demandez à ce que cette fonction soit déconnectée du service. Vous devez maîtriser l’unité des services web et ne pas vous la laisser imposer.
• Vous vous souvenez de ces ERP qui valorisaient l’intégration des services, le tout intégré ? Et bien là, c’est le tout désintégré. Chaque service ne doit faire que ce qu’on lui demande, posséder de bonnes APIs, en mode REST (puisqu’on sait que si les APIs sont ce que les DRM sont à la musique, alors les APIs Restfull sont les les « mp3″ des APIs).

Dernier point ; lorsque l’on parle de Software as a Service (SaaS) il faut faire des distinctions car, la nuit, « tous les SaaS sont gris ».

En apparence, tout est SaaS : Google doc, Facebook, Salesforce, etc. Ce n’est que lorsqu’on se place du point de vue du programmeur que des distinctions éclairantes apparaissent. C’est ce qu’a mis en lumière Marc Andreessen en distinguant trois niveaux de « plateformes » web.

Appliqué au SaaS, cela donne :
1. SaaS d’accès en lecture et écriture -> Accès aux données (Google, eBay, Flickr)
Ce niveau 1 du Saas vous offre un SDK pour travailler avec les données via les APIs

2. SaaS de plugin -> Accès aux fonctionnalités (facebook)
Ce niveau 2 du SaaS vous offre un SDK pour réaliser des Plugins qui introduisent des fonctionnalités dans une offre SaaS et vous offre une audience (en contre partie, comme le signalait Aurélien, vous travaillez à la constitution du graphe social).

3. Platform as a service (PAAS) -> Accès à la plateforme (SalesForce, Amazon avec EC2 et S3)
Ce niveau 3 du SaaS vous offre un SDK une réelle plateforme qui héberge et fait tourner votre code.

Exodus est donc un programme planétaire qui vise à migrer les données sur la terre promise qu’est l’architecture web. Le web étant alors compris comme une gigantesque base de données.

C’est un processus de grammatisation car il discrétise les services, les simplifie et nous fait reconsidérer toute notre grammaire du numérique, c’est à dire aussi celle de nos/vos usages.

Related posts:

1. Le périmètre trouble du Search en terrain SaaS La promesse d’une solution de Search fédérée permettant de lancer...
2. Il n’y a pas que le SaaS dans la vie Il y a aussi Saas, petit village suisse : Image...
3. Adobe Photoshop en SaaS Conformément à sa stratégie SaaS, Adobe a mis en ligne...

RESTful Web Services est peut-être l’ouvrage informatique de l’année.

Je vais tenter d’expliquer le plus simplement possible l’enjeu de cet ouvrage.

Internet, c’est le protocole TCP/IP. Protocole sur lequel s’appuient d’autres protocoles comme HTTP, SMTP, FTP, SNMP, TELNET, DNS, SSH, etc.

Le langage courant a tendance à confondre le Web et Internet. Or le Web, c’est uniquement l’utilisation du protocole HTTP, celui que nous utilisons avec nos navigateurs pour lire les pages HTML.
Les services web, par définition, utilisent le protocole HTTP précisément parce qu’ils délivrent des services web.

Le protocole HTPP est très simple : il permet le dialogue entre un client et un serveur. Généralement c’est un navigateur qui formule des requêtes (à chaque clic) et le serveur y répond.

Le protocole HTTP est donc un langage, et comme tout langage il a, entre autres, des verbes et des noms :

• les méthodes HTTP sont les verbes, les principaux sont : GET, HEAD, PUT, DELETE, POST
• les URIs, qui constituent le chemin d’accès à une ressource, sont sont les noms du langage HTTP.

Le langage du protocole HTTP constitue une enveloppe qui permet de délivrer un message, et donc un contenu, du client au serveur et réciproquement.

Le formidable avantage de HTTP est que les verbes (que les programmeurs appellent aussi méthodes ») sont peu nombreux et standardisés. Du coup, on peut facilement comprendre les requêtes qui s’expriment en HTPP :

« GET http://www.christian-faure.net/qui-suis-je/ »

Forcément, si l’on veut mettre en place des requêtes ou des services web particulièrement complexes, il y a deux choix possibles :

• soit on mène une politique simple mais rigoureuse au niveau des URIs (on enrichi son vocabulaire et on classe ses ressources) et alors on s’oriente vers une architecture orienté ressource
• soit on défini des verbes spécifiques, mais qui ne sont plus ceux de HTTP, et alors on s’oriente vers une architecture de style RPC qui est un protocole permettant de faire des appels de procédures sur un ordinateur distant.

Dans le deuxième cas, on ne va utiliser HTTP que pour le transport d’une enveloppe dans laquelle on aura redéfini l’appel à des verbes qui nous conviennent. Dit autrement, le verbe (et donc le sens) de la requête n’est plus porté par HTTP mais au niveau du serveur interrogé.

L’alternative entre une architecture orienté ressource comme l’est REST et une architecture RPC comme l’est SOAP pourrait être schématisé de la manière suivante :

• soit on déporte l’intelligence sur les ressources
• soit on déporte l’intelligence sur des procédures (verbes) spécifiques et non-standards.

Les grands marchands du web comme Amazon, par souci de simplicité et d’interopérabilité sont plutôt portés vers l’architecture REST, tandis qu’au sein des entreprises on s’échine à faire toujours plus compliqué avec du RPC-SOAP-WSDL : il faut bien faire vivre les éditeurs et les SSII.

Je terminerai cette note en précisant que l’intérêt de REST, en tant qu’architecture orientée ressource, va dans le sens d’une promotion de RDF, précisément en tant qu’environnement de descriptions de ressources.

[Update] Il faut lire la note de David sur REST et les commentaires de Got à cette note, en attendant de voir leur développement sur le sujet sur leur blogs respectifs.

Related posts:

1. Activation de compte en mode REST Voici la traduction d’une partie d’une note de Seth Ladd....
2. POWDER : Protocol for Web Description Resources Un nouveau groupe de travail vient de se créer au...
3. Le processus dans le navigateur Web O’Reilly signale la disponibilité de CoScripter qui sort du centre...

Quelques soustractions prédictives risquent de bousculer le métier des grands prestataires informatiques.

Prenons les lignes budgétaires classiques des prestataires en informatique :

• revente de licence
• installation et paramétrage des logiciels
• intégration de plusieurs logiciels entre eux.
• administration des logiciels
• maintenance des logiciels
• développement
• assistance / Conseil / Expertise

Ce qui va changer :

• Software as a Service (SaaS) : pas d’installation dans le système d’information donc des lignes budgétaires qui disparaissent :

Ce qui va disparaître du Chiffre d’Affaire des SSII :

• Revente de licence
• Installation et paramétrage des logiciels
• Administration des logiciels
• Maintenance des logiciels

Reste, de manière très allégée, les lignes budgétaires suivantes :

• Intégration de plusieurs logiciels entre eux.
• Développements
• Assistance / Conseil / Expertise

Sachant que les développements seront plus largement outsourcés, que l’intégration se fera sur des architectures web RESTful et que le conseil représente un volume de chiffre d’affaire peu important, sachant tout cela donc, que va-t-il rester comme activité aux SSII ?

Réponse : la peau du cul si elles ne ré-inventent pas leur métier.

Related posts:

1. Le jour où Microsoft utilisera des logiciels libres Ce jour n’est pas si loin, quand on voit les...
2. La carte des services Google Zorgloob, qui suit de près l’actualité de Google, nous propose...
3. Lignes de temps Le logiciel « Lignes de temps », développé à l’Institut de Recherche...

L’ASP (Application Service Provider) tend à devenir du SaaS (Software as a Service). Pour bien comprendre ce basculement il faut rappeler les principes techniques qui sont à l’oeuvre :

• Les solutions ASP sont historiquement des solutions de type client / serveur dans lesquelles le prestataire héberge le serveur.

• La solution SaaS s’appuie, elle, sur les standards web pour proposer des applications accessibles par des clients légers.

On retiendra donc que l’ASP et le SaaS sont identiques dans leurs intentions (vendre un service plutôt qu’un logiciel qui s’installe), mais différentes dans leur réalisation technique : seul le SaaS reproduit des architectures web (SOAP, XML, etc.).
Si l’on voulait aller plus loin, il faudrait faire la distinction entre les SaaS qui utilisent une architecture REST et celles qui utilisent SOAP ou RPC. Voir à ce propos la très belle note sur Biologeek sur l’architecture REST.

LES PRINCIPAUX FACTEURS DU DEVELOPPEMENT DES SOLUTIONS SaaS :
Une logique de coût et une économie d’échelle.
Tout comme le développement spécifique a été bousculé par l’arrivée des « solutions sur étagère » que sont les progiciels d’entreprise, ces mêmes progiciels sont à leur tour bousculés par les solutions Web (le nom le plus simple des SaaS) qui ont les avantages suivants :

• logique de leasing et non d’achat (ce qui réduit les besoins de trésorerie)
• pas d’installation (pas de hardware à maintenir, pas de frais d’intégration, de maintenance, etc.)
• diminution des ressources humaines affectées à l’informatique de l’entreprise
• moins de dépendance à un éditeur dans l’évolution de son système d’information
• meilleur réactivité et souplesse des services applicatifs

Pour les prestataires offrant des SaaS cela implique :

• de construire des data center et des centres de calculs importants
• d’avoir la capacité financière pour faire face aux besoins de trésorerie

C’est donc une pure logique d’économie d’échelle qui anime le business model de ces acteurs. Logique rendue possible par l’utilisation des techniques et des standards Web, designée et socialisée dans la vague Web 2.0.

LES PRINCIPALES RÉTICENCES POUR LA BASCULE VERS UNE LOGIQUE SaaS.
Ces sont les suivantes :

• la confidentialité des données
• les besoins d’accès Offline
• couplage nécessaire avec les applications existantes installées dans le système d’information de l’entreprise
• les résistances au changement (mutation et disparition de certains métiers dans l’entreprise)

Parmi ces éléments de réticence, la confidentialité des données est le plus sérieux.

IMPACT DE LA CONFIDENTIALITÉ DES DONNÉES SUR L’AVENIR DES SaaS
En bon consultant je dirai que 80% des informations ne sont pas sensibles et peuvent donc être adressées via des solutions SaaS. Mais cela implique de construire une autre solution pour les 20% restantes et d’asssurer un service sans-couture entre les deux types d’informations ; du coup le coût global augmente sensiblement la facture initiale, réduisant par là même un des principal avantages de l’approche SaaS.
A noter que, lorsqu’on parle de confidentialité des données, on voit souvent apparaître les questions de sécurité. C’est un faux problème, car les Data Centers des prestataires de SaaS sont souvent de bien meilleures places fortes que les systèmes d’information des entreprises.

L’OPPOSITION ENTRE LE LEGACY ET LE SaaS
Louis Naugès, qui est un acteur Français très intéressant de la bascule vers le SaaS oppose souvent le Saas au « legacy » (désignant par là les applications historiques et patrimoniales des entreprises). Mais entre le Leagcy et le SaaS il existe, pour les grandes organisations, une troisième voie qui consiste à construire des data center sur lesquels des SaaS d’entreprises pourront se construire, sans aller sur Internet donc. Une autre voie et celle que tentent d’adopter les grands nom de l’ERP, ainsi SAP a commencé à proposer des logiciels en mode SaaS, mais sous forme timide d’option pour l’instant (ne pas s’attendre à des architectures REST et au respect des standards de la part de ces acteurs).

Il existe donc différentes déclinaisons dans le monde du SaaS :
- Les Saas Internet (Google Aps, SalesForces)
- Les Saas Intranet (une partie sur mesure)
- Les ERP « SaaSisés » (SAP, ORACLE)
Beaucoup de personnes vont voir leur métier changer et évoluer dans les prochaines années.

Related posts:

1. Les prévisions du Gartner pour le SaaS Gartner nous donne ses prédictions pour le SaaS en cinq...
2. Le périmètre trouble du Search en terrain SaaS La promesse d’une solution de Search fédérée permettant de lancer...
3. Adobe Photoshop en SaaS Conformément à sa stratégie SaaS, Adobe a mis en ligne...