La conception web peut-elle devenir plus granulaire ? Par granulaire, on entend la possibilité de composer des sites web complexes à partir de « pièces détachées », de fonctions unitaires externalisées auprès d’autres acteurs. Ainsi, on peut de plus en plus imaginer l’externalisation de processus tels que l’authentification d’un utilisateur (OpenId), la mise en place d’un système de réputation (RapLeaf), le stockage (Amazon S3) ou le traitement de données (Amazon EC2), la vérification des e-mails (Undisposable) de vos visiteurs, etc. Autant de bases de données et de fonctions qui, connectées les unes aux autres, finissent par constituer l’infrastructure même de services riches et complexes. Cela induit deux avantages majeurs explique Emre Sokullu pour Read/Write web : diminuer le coût et le temps de développement, et profiter à la demande de solutions puissantes et massives.
Mais « pourquoi alors l’implémentation de ces solutions – qui sont pourtant l’une des promesses du web 2.0 – reste -t-elle si lente ? », s’interroge Emre Sokullu. Parce qu’avec ces applications on ne se contente pas de sous-traiter un service, on transfère une partie de son capital. Déléguer l’authentification, ou la gestion de la réputation, c’est-à-dire une partie de sa relation avec ses propres clients/utilisateurs, n’a rien d’évident. « Partager » son client pour construire des « suites servicielles » qui répondent de manière plus complète, ou plus personnalisée, à ses besoins est certes nécessaire, comme l’explique depuis longtemps Bruno Marzloff (par exemple dans Mobilités.net, pp. 54-58) – mais il s’agit bien d’abandonner, ou a minima de partager, la propriété d’une part de son capital, ce à quoi peu d’entrepreneurs sont aujourd’hui préparés…
Ces services sont aussi perçus comme incertains : comment faire confiance à des start-ups, voir même à des grandes sociétés comme Amazon, quand on ne voit pas toujours clairement où et comment elles tirent profit de ces services ? L’éventuelle indisponibilité fait aussi partie des risques invoqués : plus la chaine compte de maillons indépendants, plus les sources de problèmes potentiels se multiplient (pour ma part, j’aurais tendance à dire que c’est là l’argument le moins pertinent : la plupart de ces services sont extrêmement fiables et supportent très bien les montées de charge, c’est d’ailleurs l’un de leurs principaux arguments de vente).
Enfin, la mise en oeuvre n’est pas si facile. Les développeurs doivent comprendre de nouvelles structures de développement et intégrer des API (interfaces de programmation) toujours différentes pour expérimenter ces services.
Face aux nécessité toujours plus grandes de fonctionnalités, face à l’exigence d’innovation qu’imposent les petits comme les grands acteurs du web, on devine pourtant qu’il n’y a pas d’autres modèles à terme. Qu’on ne peut plus imaginer de vastes développements sans faire appel à des éléments extérieurs. Ça n’est d’ailleurs pas totalement nouveau. Les sociétés de service font depuis plusieurs années de l' »intégration de services », même s’il s’agit plus souvent d’agencer différents logiciels entre eux au sein des frontières du système d’information, que d’exploiter une multitude de web services.
Comme le souligne Didier Durand, cette structuration permettra bientôt de monter des sociétés sans infrastructures propres « en limitant son travail au strict apport de sa valeur ajoutée spécifique, sans répliquer les bases opérationnelles déjà disponibles en tant que service et pouvant fonctionner à l’échelle du web tout entier ». Les services vont donc pouvoir se croiser pour prospérer les uns grâce aux autres. Les sociétés pourront accéder à des centaines de millions d’utilisateurs par des canaux et dans des contextes les plus variés, sans avoir à résoudre des problèmes d’échelle ou de disponibilité de services… Une perspective qui est déjà en train de transformer radicalement le ticket d’entrée dans le monde de l’innovation technologique logicielle, et qui pourrait, pourquoi pas, souligne Didier Durand, redistribuer les cartes de l’investissement entrepreneurial.
Ce web granulaire contient en germe une autre perspective qui pourrait s’avérer encore plus déterminante à l’avenir : la capacité de ces pièces détachées à « transformer les applications en environnements programmables », comme le décrit Tim O’Reilly en évoquant Pipes, la dernière et remarquable innovation lancée par Yahoo ! (Pipes pour « tuyaux », en référence à ces lignes de code qui permettent de faire communiquer deux programmes informatiques, comme l’explique InFlux). Yahoo ! Pipes est un service en ligne qui permet de mixer très librement des flux d’information ou des fonctionnalités, via un éditeur de programmation visuel et simplifié, pour créer de véritables applications composites, sans avoir besoin de savoir programmer. « L’usager technophile et « early-adopter » est donc aujourd’hui convié à évoluer dans une sphère socio-technique dont « on » lui offre de maitriser les outils, les environnements, les procédures, les techniques », conclut Olivier Ertzscheid. On peut ainsi créer en quelques minutes une application qui va illustrer à partir de photos de FlickR les articles du Monde, du Figaro ou de votre propre site à partir des mots clefs présents dans le texte ; ou encore construire une application qui mixe les informations sur les restaurants de Chicago via Yahoo ! Local et les photos de ceux-ci via FlickR.
Bien évidemment ce qui devient le plus important dans cet environnement, c’est la qualité des données et de leur structuration, comme le souligne très justement Alex Iskold pour Read/Write Web. Sans compter qu’il faudra aussi que ce type d’outils s’ouvre vraiment… En effet, l’essentiel des bases de données que Yahoo!Pipes permet d’utiliser à ce jour sont celles de de services appartenant à Yahoo. Faut-il y voir un signe que même les grands du Web 2.0 ont du mal à partager la propriété de leur capital ?
Hubert Guillaud
0 commentaires
Bravo Hubert, tu as mis le doigt sur une des questions CENTRALES quand on dit (et que je dis) que la nouvelle frontière ce n’est pas le web 2.0, c’est l’application du web 2.0 dans les organisations et donc ici dans les projets de ces organisations.
Oui, ce n’est pas simple et tout sauf évident. Non pas que tout cela ne soit pas technologiquement pertinent, en tant que marchand de pelle de service, je dois te dire que nous sommes éminemment preneur et en veille de ces moyens. Ils permettent de dégager des moyens de choses que l’on se retrouve à recontextualiser cent fois, au détriment des vrais sujets et donc de leur performance.
Personnellement, je pointe plusieurs choses.
Ce dont on parle est une forme d’externalisation et le dire indique déjà que c’est une vraie question économique et industrielle.
Qui plus est, il s’agit d’une externalisation imparfaitement maîtrisée. On se retrouve en effet à adopter un modèle au service de ce que l’on veut faire plutôt que de mettre en place des choses qui y collent. C’est un problème bien connu de solutions, elles vous obligent à adopter leur modèle plutôt que de répondre à celui que vous avez construit.
En plus, quand le service change, on subit ce changement et il est somme toute plus rassurant pour une DSI d’avoir la maîtrise de la migration. Cela me fait dire que les solutions 2.0 feraient bien de penser à maintenir les v (n-1) de leurs applications au lancement des v (n) pour apporter cet élément de confiance qui fait qu’on maîtrise le calendrier d’adaptation à défaut de celui du spectre des fonctionnalités. Cela dit, l’intégration du client dans le processus d’évolution des produits devrait aussi faire partie des changements qu’on devrait observer (et ça vaut aussi pour l’open-source).
Enfin, il faut évidemment parler des contenus et des données. C’est bien qu’elles soient sur des environnements super-performants (et effectivement bien plus que ceux que l’organisation est capable de se donner), encore faut-il des garanties sur leur confidentialité et surtout la capacité donné à l’utilisateur de les sortir complètement et facilement. Nous avons ainsi vécu récemment des choses troublantes avec Salesforce (un très bon outil par ailleurs).
Comme tu le vois, Hubert, la question n’est pas du tout technique, la plomberie est au point et elle progresse, il faut simplement que tous ces services comprennent deux ou trois choses importantes pour toute organisation et plus encore quand il s’agit d’entreprises et quand on veut matérialiser du patrimoine, de la valeur, ou tout simplement que les conditions de la confiance dans la pérennité et la maîtrise des choses soient données.
Un paquet de services modernes ont donc des progrès à faire et il y a de l’autre côté du fossé un bel effort d’évangélisation à conduite. La conduite du changement, là encore, est la clé, ne l’oublions pas.
Très bon post effectivement !
Je me permets de rebondir sur le commentaire d’Alexis lorsqu’il dit que la question n’est pas du tout technique. C’est marrant, j’ai juste publié aujourd’hui une note sur le fait que finalement au delà des changements des comportement, le problème technique est bien réel!
En effet, le fait que de grosses sociétés comme IBM, SAP ou Microsoft mettent du temps à implémenter des outils web2.0, cela freine considérablement l’adoption des ces outils en entreprise : Problème de compatibilité, de sécurité, de pérennité…Les directeurs informatiques ne prennent pas le risque d’utiliser des outils qui semblent plutot destinés aux earlier adopters.
Ce n’est pas faux, mais c’est plutôt un processus normal d’industrialisation, disons de diffusion des innovations. C’est effectivement le rôle des éditeurs que vous citez, certains innovent, d’autres massifient. La question n’est donc pas technique au sens propre, vous pointez à mon avis un autre processus et le rythme qui lui est propre.
C’est pas des granulés … c’est des pièces de puzzle.
😉 Top la séléction des carrefours.
D’autant que les sites internets ont déja une durée de vie assez limitée , et qu’un site sur lequel apparait parfois ne serait ce qu’une fois la petite croix synonyme de « piece manquante » est déserté aussi vite qu’un buffalo bill post actualité faisandée …
Alors prendre le risque de laisser a un autre de couler son site en enlevant un jour une pièce maitresse , c’est trop pesant pour ne pas préférer la solution je fais tout moi meme .
Le Petit Nicolas (mais en Plus Grand)
Il n’y a rien de bien nouveau dans cette idée.
On la rencontre déjà dans les plateformes d’enseignement qui sont composées de briques que l’on met en service ou pas. La limite de ce modèle, aujourd’hui, est dans le fait que ces outils sont accessibles dans l’environnement de la plateforme uniquement et ne peuvent être greffés individuellement dans un portail. L’une des raisons est la complexité de construction des tuyaux de communication entre les différents blocs : lorsqu’on passe d’un forum à sa messagerie il faudrait par exemple que le site se souvienne de mon adresse électronique et, contrairement à ce que pensent certains c’est beaucoup plus compliqué à faire qu’ils ne le croient.
Quand à l’outsourcing c’est encore un problème différent. Je ne sais aps si les 29 000 étudiants de mon université et le personnel apprécieraient, ni moi d’ailleurs. Indépendemment du fait que c’est déjà difficile de faire fonctionner ensemble un ensemble de serveurs locaux et que je préfère ne pas imaginer si je devais envisager une distribution des fonctionnalités sur tout un territoire !
Bref Yaka Faucon est toujours vivant.
« Ces services sont aussi perçus comme incertains »
Ah bah tiens, justement, pour prendre un exemple, flickr ce matin brasse les photos d’un peu tout ses utilisateurs, et ce n’est pas la première fois que ça arrive si on s’en réfère au forum des utilisateurs…
Qui a dit que c’était « l’argument le moins pertinent » ?
En ce qui me concerne, ça serait plutôt L’argument, le seul, du moins un des tout premier. Bien sûr, ce genre de bug peuvent arriver, ça arrive même certainement plus souvent avec des développements maison, mais dans ce cas, quand le client appelle pour rapporter un problème, on peut lui répondre qu’on mobilise des personnes dessus, pas qu’il n’y a qu’à attendre que ça rentre dans l’ordre tout seul, avec un peu de chance…
Cette approche est très intéressante mais reste selon moi limitée par les risques pris lors de la création d’application granulaire basée sur des services externes tout en respectant scrupuleusement les règlements d’utilisation de ces services. (par exemple, selon Flickr, il n’est pas possible d’utiliser une photo provenant de leurs serveurs sans apposer un lien vers cette photo : « Flickr Terms of Service specify that if you post a Flickr photo on an external website, the photo must link back to its photo page »)
Je l’avais évoqué il y a six mois sur le blog de Clever Age :
http://www.clever-age.com/veille/blog/le-soa-pour-tous.html