Dimanche 09 avril 2006
Faut-il croire avec John Markoff du New York Times que l'Internet est à l'aube de son « ère Lego » ?
Les signes annonciateurs de cette nouvelle période historique seraient, selon lui, à chercher dans la prolifération de « composants logiciels » sur le Web. Le mode de développement des applications informatiques subirait alors une transformation massive : au lieu de programmer, à proprement parler, ces applications, il s'agirait maintenant de les assembler à partir de ces composants. En conséquence, l'innovation dans l'industrie des logiciel deviendrait complètement décentralisée. Au lieu d'applications lourdes, englobant de plus en plus de fonctions, développées, maintenues et commercialisées par des très grandes entreprises comme Microsoft et Oracle, on verrait des éditeurs plus petits au dynamisme conquérant proposer des composants et des services Web simples mais immédiatement réutilisables.
Reconnaissons dans cette opinion la dernière incarnation d'une idée au moins aussi ancienne que celle de programmer, mais cette fois énoncée à l'échelle mondiale du Web. Néanmoins ce sur quoi John Markoff attire l'attention est que si cette idée trouve aujourd'hui un début de réalisation, après avoir longtemps flotté dans l'air du temps, sa concrétisation n'est pas venue des quartiers d'où on l'attendait.
Il y a presque deux ans, fin 2004, le W3C promulguait la Web Services Architecture s'appropriant à l'époque le sujet de nombreuses discussions menées dans l'industrie du logiciel depuis 1998. Déjà l'accent portait sur l'interopérabilité des applications informatiques connectées au Web. À l'aide de protocoles et de standards partagés, bien sûr fondés sur les protocoles et les standards rendus populaires par la généralisation de l'Internet et du Web (TCP/IP, HTML, HTTP, etc.), les applications informatiques pouvaient désormais communiquer et échanger données et informations au travers du Web. Même si l'architecture se voulait très générale, il était entendu qu'elle trouvait son premier champ d'application dans le développement des applications d'entreprise, c'est-à-dire dans l'urbanisation des systèmes d'information. Aujourd'hui il est d'ailleurs courant de parler de « Web Services Stack » pour désigner l'empilement des API Web dont il faut vêtir les applications informatiques d'entreprise pour les acclimater à l'environnement Web. (Deux grands organismes de standardisation travaillent à l'élaboration de ces spécifications : le W3C lui-même, avec une orientation technique, et OASIS, avec une orientation plus fonctionnelle et métier.)
Il y a dix ans, ou peu s'en faut, naissaient, dans la préhistoire du Web, les méthodologies orientées objet sous l'étendard unifié de la « réutilisation ». Les trois « amigos », Ivar Jacobson, James Rumbaugh et Grady Booch, promoteurs de méthodologies et de notations différentes, parmi les plus utilisées à l'époque, fumèrent alors le calumet de la paix en un conclave dont sortirait UML, qui reste à ce jour d'un emploi généralisé pour le développement d'applications d'entreprises.
Il y a quinze ans, les grands acteurs de l'industrie se regroupaient au sein de l'Object Management Group, afin de créer un modèle orienté objet du système d'information des entreprises. Ayant tous compris que sans standard de tous adoptés, il n'y aurait ni interopérabilité ni réutilisation des résultats d'efforts coûteux et complexes de développement, industriels et utilisateurs appelaient de leurs voeux une coopération sur l'établissement de langages et de modèles standardisés. Ce forum devait publier la norme Corba (Common Object Request Broker Architecture) et définitivement asseoir le « middleware » orienté objet comme outil respectable de développement et de déploiement des applications d'entreprise. C'était aussi l'époque où Visual Basic se généralisait dans l'esprit de donner au plus grand nombre la faculté de construire des composants logiciels, sous Windows tout du moins.
Antérieure encore à l'OMG, l'émergence au milieu des années 1980 des langages de programmation orientés objet, et notablement de C++ (Bjarne Stroustrup) d'Objective C (Brad Cox) et de SmallTalk (Goldberg et Robson) - et de nombreux autres dont Eiffel (Bertrand Meyer) l'archétype à la fois théorique et pratique de cette approche -, devait immanquablement conduire à des interrogations architecturales. Tous les grands fournisseurs de l'époque - et ce sont pratiquement les mêmes aujourd'hui qui cherchent à s'emparer du thème technique du Web 2.0, Ajax - étaient alors occupés à fourbir leurs ateliers de développement autour de ces nouveaux langages. Prenant conscience du risque de balkanisation de cette politique de course à la part de marché, ils durent, bon gré mal gré, se rapprocher les uns des autres. (Soit par fusion acquisition, par exemple, soit par adoption de standards partagés au sein de consortiums et de partenariats comme l'OMG déjà cité.)
Antérieurement encore, ceux qui commencent à voir pointer les cheveux blancs se rappeleront de POSIX, l'effort de standardisation des API des différentes variantes d'UNIX dans un but d'interopérabilité et de réutilisation. Pour ceux à la mémoire véritablement borgésienne, programmation modulaire et bibliothèque de programmation évoquent ces excitantes nouveautés promettant une nouvelle ère de facilité et de simplicité dans le développement des programmes d'ordinateurs. Quant à ceux, enfin, qui auraient l'indulgence de me lire et qui auraient souvenir du papier visionnaire de McIlroy à la conférence de l'OTAN sur le développement logiciel en 1968 (Mass Produced Software Components qui pose le concept de « bibliothèques de routines réutilisables ») qu'ils soient ici salués pour avoir inspiré les idées directrices de l'évolution du logiciel.
Quid novi donc ? Ne s'agirait il là pas d'une nouvelle forme, à peine plus élaborée, du mythe évasif des composants logiciels réutilisables, simplement récité dans la langue moderne du jour (XML accent Javascript) ? Pas uniquement. Comme précédemment illustré, les réincarnations du mythe de l'assemblage des composants logiciels se produisent à des instants bien spécifiques dans l'évolution socio-économique de l'industrie du logiciel. Hier motivées par les besoins algorithmiques croissants des applications militaires, par le risque de fragmentation des marchés, par la nécessité de réduction des coûts de développement et de maintenance des applications informatiques d'entreprise, les raisons fondamentales de l'intérêt soudain pour les composants logiciels sont toujours les mêmes : produire les applications plus vite et moins cher. Aujourd'hui rien n'est changé : à l'heure où tous les analystes sonnent le glas, répètant que le logiciel d'entreprise a atteint le même degré de maturité que celui d'autres secteurs industriels comme l'automobile, le formidable déploiement du Web a massivement exacerbé ces deux causes, plus vite et moins cher. D'un côté des utilisateurs, en bien plus grand nombre que naguère, qui s'étonnent de plus en plus de la difficulté d'emploi des applications en entreprise par comparaison avec celles du Web, disponibles partout (du foyer au bureau, du PC au téléphone portable, bientôt) ; de l'autre le phénomène de développement coopératif massif auquel le mouvement Open Source (et Linux !) a donné ses lettres de noblesse ; enfin, l'intégration en douceur d'un format, à mi-chemin entre texte et donnée, quasi-universel (XML) et de son API (Javascript) dans les navigateurs Web : voilà les ingrédients qui ravivent aujourd'hui la flamme de la réutilisation.
Au-delà de l'émerveillement de John Markoff devant les premiers mashups (le terme consacré pour désigner un assemblage de services constituant à la volée des applications Web) il faut également rappeler que le succès de la diffusion des outils techniques n'est pas tout. Pour que la réutilisation marche effectivement, il faut une approche systématique. Les quelques exemples ponctuels dont il est si vivement fait écho - surtout à l'occasion du rachat des startups qui en sont à l'origine par Yahoo et par Google - ne suffisent pas encore à assurer que nous sommes entrés dans une nouvelle ère. Si l'on relit l'histoire récente et moins récente des appels à la mobilisation sur les composants logiciels, quatre obstacles viennent habituellement s'opposer à un basculement global de l'industrie.
Ingéniérie et technique tout d'abord. Quel est le niveau de qualité des avatars Web 2.0 des composants logiciels ? A-t-on procédé à une identification claire des modèles et des besoins auxquels ils devaient répondre ? Leurs possibilités et les scénarios de réutilisation sont-ils documentés, classés et accessibles ? Ont-ils été conçus avec sufisamment de « flexibilité » embarquée pour être adaptés à des situations variées de réutilisation ? Les outils du jour incorporent ils d'emblée ces procédures de gestion des composants, essentielles dans l'économie du cycle de la réutilisation ? Sur ce plan, l'approche Ajax, qui est souvent identifiée à la réutilisation dans le cadre des applications Web - ce qui me semble réducteur pour le Web 2.0 dont l'ambition est plus vaste - apparaît au mieux balbutiante. On est loin de disposer d'environnements Ajax dotés de l'appareillage et de l'instrumentation méthodologiques comparables à ceux employés couramment chez les éditeurs de logiciels et dans les départements informatiques des entreprises. (Précisément, les grands éditeurs les promettent sous peu, rapprochant un peu plus les deux sphères économiques, mais les alternatives Open Source prolifèrent également.)
Second obstacle : moins encore que dans les résurgences antérieures n'y a-t-il aujourd'hui de réflexion sur les processus et le rôle éventuel de l'architecte logiciel. Que ce soit à l'étape de la conception, à celle de l'analyse ou à celle du développement il convient de formaliser les critères de décision arbitrant le choix entre développer ab initio ou réutiliser. Même dans l'organisation des développements de logiciel libre, pourtant fondé sur le volontariat et la décentralisation, le rôle du « committer », la figure de proue d'un projet, est singularisé. Où est-il aujourd'hui dans le modèle Web 2.0 ? Nulle part et partout. Chacun est laissé à ses propres moyens pour décider ou non de mettre en ligne un service Web que l'on juge intéressant, ou pour choisir de réutiliser un service Web publié par un autre dans son propre développement. Poursuivant l'analogie avec le mouvement Open Source, ce même constat a présidé, par exemple, à la création de SpikeSource aux USA, ou de Linagora en France, qui cherchent à établir des critères objectifs de décision et un catalogue raisonné des ressources du libre.
Troisième raison : peu d'organisations pratiquent systématiquement une réutilisation affichée, documentée et régulièrement évaluée. C'est déjà le cas avec le niveau actuel de diffusion des méthodes et des environnements orientés objet. Ca l'est plus encore pour des outils et des langages encore considérés avec une certaine méfiance par les directions informatiques. Dans son article John Markoff souligne avec admiration que l'on peut ainsi utiliser Skype depuis Salesforce.com en utilisant directement les données commerciales du site pour passer ses appels téléphoniques ; en France, on veut interdire Skype.
Enfin l'obstacle business, partialement évacués par les prosélytes des composants logiciels Web 2.0, n'en est pas moins là. La réutilisation requiert du capital et du financement. Il faut du capital pour financer l'ingéniérie et la qualité des processus de production des composants. Dès qu'ils ont l'ambition de prendre un peu d'ampleur les startups qui publient ces services Web ont recours au capital risque - voire sont rachetées avant même cette étape par Google ou par Yahoo comme nombre d'exemples récents le démontrent. Mais pour un Writely acheté au berceau par Google, combien d'autres services Web de traitement de textes trouveront-ils des fonds ? Et quel retour sur investissement pour ces éventuels financements ? Le cas se produira-t-il d'une startup rachetée fort cher par l'un des grands de l'industrie et qui n'aurait à son catalogue qu'un mashup de services Web produits par d'autres ? Ces fournisseurs, oubliés dans une telle transaction, ne seraient-ils pas poussés à se manifester et exiger leur part de cette valorisation, ou bien doivent-ils penser dès maintenant à embarquer dans leurs services Web un mode de paiement à l'usage, par exemple sous forme de trafic publicitaire redirigé vers leur site par le composant en question. (C'est le modèle de Google et d'Amazon.) Aux changements de circuits de distribution des logiciels, même considérés comme des services (ASP ou SOA), devront correspondre des transformations des modèles de rémunération du développement. Ces transformations, si l'on en juge par le spectacle actuel de la confrontation dans l'industrie des médias entre les majors et les tenants de la diffusion par Internet, peut provoquer des traumatismes durables.
Gardons notre émerveillement devant l'ingéniosité technique déployée dans cette nouvelle itération de l'idée du développement logiciel par assemblage de composants, mais méditons aussi les expériences, parfois mitigées, des succès et des demi-succès des générations précédentes.
