Le retour triomphal du RPC

IBM qui n'a évidemment pas l'intention de laisser à d'autres, même prétendus pionniers, le monopole de l'idée du « cloud computing », vient d'annoncer haut et fort, juste avant les Jeux Olympiques, son intention d'investir $360m dans un datacenter neuf et rutilant en Caroline du Nord destiné à compléter le réseau qu'il met énergiquement en place.

Google Maps m'indique bien volontiers qu'en suivant la I-40W pendant environ trois heures je pourrais rejoindre, si la curiosité archéologique de visiter ces pyramides modernes me tournait soudain la tête, la charmante bourgade de Lenoir, North Carolina (« All America City 2008 » !) depuis le site d'IBM dans le Research Triangle Park. C'est en effet à Lenoir, NC, par ailleurs inconnu, que Google avait quant à lui annoncé en 2007 un investissement massif de $600m pour un nouveau datacenter de son crû, venant compléter son propre réseau de mégalithes calculatoires.

(La polémique avait à l'époque tourné autour des avantages fiscaux promis à Google par le comté de Caldwell pour favoriser son installation à proximité de la centrale hydro-électrique de Rhodiss — on le sait, ces bunkers informatiques ont un besoin dévorant d'eau et d'énergie. Il y a là une idée à creuser pour les centres anémiés de la recherche française dont on persiste à nous dire que le monde entier nous les envie malgré les dégringolades annuelles dans le classement de Shanghaï. Qu'attend-on pour proposer à Google notre excellent site de Bollène, tombé quelque peu en désaffection depuis certains « dysfonctionnements » de la centrale du Tricastin en juillet dernier ?)

Microsoft qui avait annoncé début 2007, juste avant Google, lui aussi un nouveau datacenter de compétition à San Antonio au Texas, (un investissement de $550m, médaille d'argent au podium des dépenses BTP des géants de l'Internet), vient de publier sa propre vision du « cloud computing » qui sera officiellement dévoilée en octobre prochain, à l'occasion de sa Professional Developers Conference (amateurs s'abstenir !). Tel un moderne Carl Linnaeus — mais non, pas Linux ! Carl von Linné, voyons ! naturaliste suédois fondateur de la systématique — David Chappell, l'auteur du papier, propose une taxonomie qui a le mérite de clarifier les initiatives techniques pour le moins proliférantes de l'éditeur de Redmond :

• Red Dog annoncé par Ray Ozzie en avril dernier et généralement perçu comme une réponse immédiate à AppEngine de Google lancé à la même époque ; et plus généralement comme un contrepoids au grand-père fondateur reconnu de tous les services de « cloud computing », EC2 (Elastic Compute Cloud) d'Amazon.
• BizTalk Services, le terme générique désignant les technologies liées au processus métier (business processes) et leur interconnexion — SOAP dopé au workflow amphétaminé maison (Windows Workflow Foundation).
• Zurich un mystérieux projet de plateforme de cloud computing pour les ISV, voilé derrière les sous-entendus d'un Ray Ozzie et d'un Bill Gates qui n'en finit pas d'être sur le départ.
• SQL Server Data Services (SSDS) du stockage distant « à la demande », composant indispensable d'une architecture distribuée. (Là-aussi l'antériorité d'Amazon avec S3 (Simple Storage Services) et SimpleDB vient assez vite à l'esprit.)
• Microsoft Dynamics CRM Live clairement opposé à Salesforce.com avec Force.com et Apex.

La classification périodique proposée par notre Mendéleïev du jour — au moins le chimiste russe ne provoquera pas de confusion politiquement incorrecte à propos de Microsoft entre un naturaliste suédois et un programmeur finlandais ! — distingue trois catégories de services cloud :

• Software as a service (SAAS), recyclage obligatoire de l'acronyme en vogue dont le succès est indubitablement, malgré qu'il en coûte de certainement à Chappell de l'admettre, à mettre au compte de l'insolent Salesforce.com ;
• Les services joints (Attached Services) qui, distants, viennent compléter une application métier tournant localement, l'exemple de Exchange Hosted Services étant mis en avant ;
• Les plateformes cloud, probablement les plus innovantes qui, rendues possibles par le développement récent des techniques de virtualisation et de services Web, sont aujourd'hui en concurrence pour s'attirer les faveurs des développeurs.

Ceux dont l'âge approche ou dépasse 110000 ans trouveront sans doute que cette classification rappelle de loin, mais mis à l'échelle du Web, Corba et la subdivision proposée à l'origine par l'Object Management Group de l'univers en objets métiers (Domain Specifications), objets techniques (Corbaservices) et middleware (Object Request Broker). D'ailleurs, il y a exactement dix ans, David Chappell, l'auteur même de ce position paper de Microsoft se dévoilait fort critique de l'OMG et de Corba.

Il y aurait certainement beaucoup à commenter autour de ces premières idées de mise en ordre de l'architecture distribuée des applications d’informatique d'entreprise — sans parler des enjeux économiques et d'organisation. À ce stade, il est peut-être simplement intéressant de souligner à quel point la résilience de certaines techniques, dont la pratique plutôt que la théorie a présidé au choix par le passé, reste visible dans ces concepts que l'on nous (re)présente comme nouveaux, innovants, voire bouleversants et prioritaires.

En l’occurrence, on pourrait lire dans le cloud computing le retour triomphal du RPC.

Alors que le vétéran fruste des débuts balbutiants d'une informatique naissante semblait à tous infréquentable, au dernier stade du Parkinson, et relégué à une disparition silencieuse et bienvenue dans l'oubli poussiéreux des salles de musées logiciel, il fait un retour à la scène inattendu en meilleure forme que jamais ! (Le RPC est, après tout, bien plus jeune que Madonna.)

Prenons Google à nouveau : Protocol Buffers, nous dit-on, forment une méthode de codage des donnés structurées très efficace et cependant facile à enrichir ; « Google utilise Protocol Buffers pour pratiquement tous ses formats internes de fichiers et de protocoles RPC ». (Et GWT RPC alors ?) Du côté du navigateur client maintenant, JSON est « un format léger d'échange de données » adapté à Javascript et complément fréquent de l'architecture Ajax. Mais ce n'est pas tout : Facebook, le réseau social que l'on ne présente plus, a fait donation à la Fondation Apache de Thrift, « un environnement de sérialisation et de RPC indépendant des langages de programmation », qui est utilisé en interne sur le réseau social. Yahoo!, quant à lui, avait donné Hadoop à la même fondation, un RPC survitaminé destiné à des applications cloud computing : Yahoo! a même poussé l'effronterie jusqu'à y implémenter un algorithme que l'on ne peut évoquer sans stupeur ni tremblement, MapReduce, l'arme absolue mise au point par Google pour la distribution de ses applications dans ses propres datacenters ! Même Cisco annonce son RPC propriétaire, Etch.

Pourquoi un tel retour en grâce du RPC ? D'abord, ne pas négliger les mouvements de mode (toujours d'actualité en informatique comme ailleurs) : les réseaux sociaux sont cools donc le RPC, qu'ils mettent en œuvre, est cool ! Sinon qu'est ce qui pousserait Microsoft à acheter 1,6 % de Facebook pour $240m ? Ou Cisco à acheter Tribe.net après Five Across ? Sans parler de Google et YouTube et autres transactions qui défraient la chronique (et effraient le chroniqueur).

Ensuite il y a l'effet de fatigue SOAP. Mis au point il y a dix ans en s'appuyant sur les technologies les plus cools du moment, XML et HTTP, SOAP a été présenté par les obsédés de l'interopérabilité, craignant à juste titre il est vrai la domination impérialiste d'un certain éditeur, comme le protocole définitif d'échange de données à l'heure du Web. Esprit de « coopétition » oblige, les groupes de travail réunissant les ennemis d'hier ont proliféré, les manifestations de bonnes intentions standardisatrices se sont multipliées ainsi que les spécifications, sous-spécifications et leurs variantes au W3C, à l'IETF et à l'OASIS (15 recommandations au W3C et 10 groupes de travail, 12 comités techniques à l'OASIS et une quarantaine de spécifications), sans parler des subtiles variations entre les implémentations commerciales de telle ou telle spécification.

Protocole réputé lourd, SOAP est donc souvent invoqué comme exutoire par les promoteurs de ces nouveaux RPC qui se réclament, par contraste, de l'architecture REST. (Si l'on en croit la blogosphère, le débat « SOAP ou REST » est largement tranché.) En fait, beaucoup de ces RPC réinventés sont livrés en Open Source et pour le programmeur pragmatique, du moment que c'est gratuit et que l'implémentation fait raisonnablement le travail qu'on attend d'elle, pourquoi creuser plus loin ? Il serait pourtant salutaire de relire à la lueur des annonces actuelles la note prémonitoire (1994 !) de Jim Waldo, Distinguished Engineer du projet Darkstar chez Sun Microsystems, une plateforme de cloud computing pour les mondes virtuels, les jeux en ligne et les résaux sociaux « massifs ». Dans ce monde post-SOAP, le RPC n'est plus un protocole c'est plutôt l'absence de protocole...

Voilà qui promet bien des maux de tête pour nos naturalistes systématiciens et nos urbanistes des systèmes d'information !

Harmonie au pays des scripts

Dans un monde informatique qui nous avait habitué à voir les organismes de standardisation se transformer en arènes de combats commerciaux, l'irénisme du Comité technique n°39 de l'ECMA, réuni en Norvège la semaine dernière, fait plaisir à entendre ! Ces nouveaux accords d'Oslo scellent un apaisement entre deux factions dont les désaccords menaçaient rien moins que le bon fonctionnement de nos indispensables navigateurs Web.

Vous l'aurez certainement compris : il s'agit ici du sujet pressant de la standardisation de l'évolution de Javascript, le langage de script qui s'est glissé, sous des dialectes variés, au cœur de nos navigateurs. Javascript, maintenant banalisé, est pourtant né dans la douleur. Baptisé à l'origine LiveScript, le langage est apparu en 1995 avec la première version du navigateur Netscape qui acceptait les applets Java — la grande nouveauté de l'époque. Conçu par Brendan Eich, il visait à simplifier les interactions entre pages Web et applets pour les non-Javaïstes, la majorité des développeurs en ces temps protohistoriques du Web. Soumis à un feu nourri de critiques acerbes visant tout à la fois la monumentale erreur (de jeunesse) de marketing dans le choix de « Javascript » comme nouvelle dénomination — déclenchant une confusion durable entre Java et Javascript pendant les premières années —, les innombrables failles de sécurité du système de scripts, l'absence d'environnement de développement et de debugging, les incompatibilités flagrantes entre navigateurs, Javascript acquit cependant une vie et un développement autonome loin des applets Java initiales, atteignant peut-être au succès précisément en raison de ces faiblesses. D'accès apparemment facile, pratique, interprété et donc moins contraignant pour certains que les langages à compiler, rapidement réutilisé d'une page Web à l'autre, c'est l'apogée de la technique du « copier-coller » à l'heure de l'Internet.

Les choses devinrent plus sérieuses quand Microsoft donnait non pas une mais deux versions d'un langage de script pour le Web : VBScript originellement limité aux plates-formes Windows, et JScript, en 1996, son propre portage de Javascript pour Internet Explorer. Les incompatibilités importantes entre ces différents dialectes valurent alors à Javascript la réputation pas totalement usurpée d'écueil dans la mer de standards et de protocoles ouverts du Web. L'irruption d'un Microsoft affichant sa stratégie « embrace and extend » de 1996 alors qu'il devait trébucher dans le méga-procès anti-trust dont les scories sont toujours sensibles aujourd'hui, poussèrent aussi Netscape et Sun Microsystems à chercher une réponse tactique, en proposant de standardiser rapidement le langage en le confiant à l'ECMA — un choix d'organisme de standardisation européen qui surprit à l'époque — qui l'adopta mi-1997, ainsi que l'ISO, un an plus tard. La dernière révision de ECMAScript, puisque tel est le troisième patronyme du langage, date de 1999 (ECMA 262, 3e édition).

Depuis quelques années une très ambitieuse version 4.0 du langage était en cours de spécification, également connue sous le surnom de « Javascript 2 », touchant aux sujets délicats de l'adjonction (ou non !) de véritables classes avec héritage, de fonctions génériques, de réflexion, de systèmes de types sophistiqués, bref de l'appareillage moderne d'un langage de programmation orienté objet ultra-complet. Avec, une fois de plus dans son histoire mouvementée, la menace d'incompatibilités majeures entre les éditions n°3 et n°4 d'ECMAScript. (Au moment même où, dans l'industrie qui décidément avance sans nécessairement se soucier de la discipline des standards, Javascript joue un rôle devenu primordial avec le succès de facto d'Ajax et la banalisation d'une version light des services Web.)

Cette question cristallisait depuis un an l'antagonisme entre deux courants de l'ECMA : les suppôts de l'édition n°4 dans toute sa gloire, principalement Opera, Mozilla, Adobe/Macromedia et Google — rien que le standard mais tout le standard ! — et les partisans d'une amélioration incrémentale de l'édition n°3, une version 3.1 qui aplanirait les principales difficulté et coûterait moins à implémenter, et dont les champions sont plutôt Yahoo! et Microsoft. (Tiens ! Microsoft est en pleine phase Beta d'Internet Explorer 8.0 et a lancé sans succès, il y a peu, une OPA sur Yahoo!)

À Oslo, les tractations de la semaine dernière ont abouti à un « recentrage sur la simplicité et sur les extensions pragmatiques » comme il est politiquement correct de l'exprimer. D'ailleurs pour témoigner des épanchements soudains de bons sentiments entre factions naguère irréductibles, il a été convenu de rebaptiser le projet ECMAScript Harmony !

L'harmonie est donc revenue au pays des scripts. La version 3.1 d'ECMAScript s'inscrit bien sûr dans le contexte plus vaste des spécifications putatives de l'édition n°4, reprenant certaines notions (comme une version édulcorée des classes) mais en laissant d'autres de côté, en particulier celles relatives aux visions grandioses de nouvelles syntaxe et sémantique du langage.

Doug Crockford, inventeur de JSON et Senior Javascript Architect de Yahoo!, s'empresse de se féliciter de cette sage décision dans son blog ; Mike Chambers d'Adobe, quant à lui, se veut rassurant : ActionScript 3, qui était basé sur l'édition n°4, « n'est absolument pas affecté par la décision d'Oslo », tout est donc pour le mieux. (Mozilla avait parrainé et adopté le projet Open Source Tamarin d'interpréteur ActionScript 3/Javascript 2, sur lequel travaillait Adobe sur la base de ECMAScript n°4, l'enjeu est donc de taille.)

Mettant un point final à la discussion, Brendan Eich, dans un courrier électronique récent, loue l'œcuménisme et la sérénité retrouvée du groupe de travail.

Tous harmonisés, il n'en reste pas moins, me semble-t-il, que chacun reste finalement sur ses positions : Microsoft peut continuer à livrer trois implémentations différentes d'un langage de script (Windows Scripting Host JScript, JScript.NET, et JScript pour DLR dans Silverlight, dont il n'est pas très clair que les VM partagent effectivement du code) ; Adobe continuer à promettre des innovations dans ActionScript 3 et éventuellement proposer une version de Javascript conforme aux spécifications plus modestes de l'édition 3.1, ce qui sera encore plus facile quand Mozilla livrera de série dans Firefox un front-end Javascript à Tamarin.

Il nous restera à voir, pauvres utilisateurs désarçonnés, si les implémentations promises incessamment seront aussi harmonieuses qu'annoncées...

La vie artificielle dans tous ses états

Quelle est donc cette secrète congrégation qui, dès l'aurore, bat le pavé de Winchester, cité médiévale glorieusement nichée dans un repli pluvieux mais verdoyant des collines du Hampshire ? Quels signes occultes de reconnaissance rassemblent cette file de silhouettes recourbées sous les parapluies qui serpente matinalement dans le cimetière de West Hill depuis quelques jours ? Dans quel dialecte, inconnu même d'Harry Potter, sont exprimées leurs exhortations, qu'un vent humide emporte aussitôt proférées, incompréhensibles tant aux sorciers qu'aux moldus : « automate cellulaire ! » s'écrie l'un d'entre eux ; « réseaux booléens aléatoires ! » lui répond-on plus loin ; « chimie des essaims ! » assène l'un des pèlerins ; « evo-devo ! », reprend soudain un chœur improvisé.

Nul conclave de sorciers conspirateurs égarés dans ce coin ombragé de countryside anglais, nulle table ronde d'une confrérie de chevaliers médiévaux égarés à l'âge de l'Eurostar, on l'aura peut-être deviné, sont exceptionnellement réunis là, venus de tous les continents, les auditeurs de la onzième édition de la conférence Artificial Life (Vie Artificielle, ou encore A-Life). Tous passionnés par l'idée de créer une ou plusieurs formes de vie artificielle — rien moins !

Dans cet univers, qui au fond n'est pas très éloigné de l'école des sorciers imaginée par J.K. Rowling, l'objet des recherches est donc de construire des systèmes — à base de logiciels, mais pas uniquement, chimie moléculaire et robots autonomes sont aussi à l'honneur ici — exhibant certaines des caractéristiques que l'on attribue plutôt exclusivement aux organismes vivants. Comme chacune de ces caractéristiques — et les grands mots sont rapidement invoqués : causalité, émergence, autopoïèse, finalité, on imagine les débats ! — est évidemment sujette à de nombreuses controverses, que ce soit dans sa définition, sa mesure, voire même sa pertinence, la conférence devint prestement le lieu de polémiques animées...

L'A-Life est au confluent, en perpétuel mouvement, de nombreuses disciplines techniques et scientifiques. Que l'on en juge seulement par les thèmes retenus pour les sessions qui se déroulent en parallèle dans les bâtiments flambant neufs de l'Université de Winchester — rénovés et couverts de WiFi mais quand même dans le campus du Roi Alfred, à deux pas de l'imposante cathédrale (Xe siècle) où Guillaume le Conquérant vint s'emparer de la couronne d'Angleterre ! Dans cette merveilleuse collision d'époques, la liste des sortilèges étudiés à cette conférence pourrait moins surprendre :

• Théorie(s) de l'évolution en 4 dimensions
• Méthodologies de modélisation en écologie
• Culture et évolution sociale
• Système neuronaux
• L'intelligence des essaims et l'optimisation des colonies de fourmis
• Développement durable et homéostasie
• Les marchés, coalition d'agents et centralité
• De la communication au langage
• Modèles de la théorie de Gaia
• Robotique amorphe et soft-robotique
• Evolution ouverte
• Développement et morphogénèse artificielle
• Automates cellulaires
• Robots danseurs
• Biologie synthétique
• Chimies artificielles et cellules minimales
• Entropie, transfert d'information et flèche de la complexité
• Conscience artificielle et vie mentale d'agents autonomes
• etc.

où l'on voit que de solides connaissances en neurologie, mathématiques, physique de la matière (condensée), chimie, médecine, robotique et automatisme paraissent évidemment indispensables pour pénétrer les mystères de ce nouvel Eleusis des côtes britanniques.

Et pourtant c'est tout à fait l'inverse qui se produit lorsque le professeur Sayama, de la State University de New York, montre le film de ses simulations de vols d'oiseaux en formation. À partir de règles individuelles de comportement simplistes pour chaque oiseau simulé, le vol groupé d'un groupe d'oiseaux artificiels ressemble à s'y méprendre aux formations qui traversent parfois nos cieux : vols en « V » des canards et des oies sauvages, succès incontesté des documentaires animaliers, envol groupé et rapide des moineaux ou des hirondelles tel qu'on le voit dans les champs sous les orages d'été ; tout semble incroyablement naturel. La perception du comportement de l'ensemble est immédiate, transcendant complètement la simplicité individuelle que l'on sait pourtant de l'automatisme mis en œuvre dans la simulation.

C'est le premier résultat et peut-être l'effet le plus démonstratif des recherches en vie artificielle : faire émerger de composants individuels simples, homogènes ou hétérogènes, tous mis en relation, de façon simple ou compliquée suivant les modèles, un comportement global, persistant, que nous percevons immédiatement comme causal, animé, téléologique ou vivant.

À partir de ce constat tous les questionnements qu'on imagine se mettent à rayonner et ces interrogations font l'objet d'intenses débats dans cette communauté de chercheurs. Quelques thèmes abordés ici, par exemple : la pression sélective de l'évolution peut-elle s'exercer sur autre chose que sur les organismes et ne peut-elle s'exprimer qu'au moyen des gènes et de l'hérédité ? Y a-t-il des caractéristiques non subjectives qui nous font attribuer à un système le caractère vivant ou non ? De quelle chimie ou biochimie minimale a-ton besoin pour construire une cellule ? L'A-Life peut-elle nous aider à comprendre l'intelligence humaine ? Peut-elle instruire ou guider des politiques écologiques, environnementales et de développement durable ? Autour donc de simulations qui tournent à peu près toutes sur le PC que vous utilisez en ce moment, on voit que ça vole tout de suite assez haut !

Depuis la première édition de la conférence, à l'époque proto-Internet de 1987, sous les auspices du Santa Fe Institute aux Etats-Unis, les praticiens de l'A-Life ont cherché à construire des systèmes artificiels — le plus souvent sous forme de simulations d'univers dynamiques sur ordinateur — reproduisant certaines des caractéristiques des organismes ou des systèmes naturels. Le fameux « jeu de la vie » (Life) de Conway est l'archétype de ces travaux. Depuis Conway, les automates cellulaires ont acquis, au-delà de leur aspect ludique — parfois hypnotique —, une richesse insoupçonnée : Stephen Wolfram a montré que certains automates cellulaires aux règles très simples peuvent afficher des comportements très complexes mais organisés qui sont analogues à ceux de systèmes naturels. Les réseaux booléens aléatoires mis au point par Stuart Kauffman offrent un degré supplémentaire dans la richesse de ces modèles ; aujourd'hui les « essaims » (ou les « colonies de fourmis » artificielles) y ajoutent la notion d'espace et la possibilité pour ces automates, aussi appelés agents, de s'y déplacer et d'interagir entre eux.

Le bestiaire artificiel s'est donc singulièrement enrichi, plus de vingt ans après, et l'on s'intéresse aujourd'hui à la modélisation de l'évolution (darwinienne) de ces monstres artificiels, avec des algorithmes dits génétiques. On théorise leurs interactions — des modèles ou règnent jeux, tournois, marchés, prédation, socialisation comme métaphores des relations entre agents. On leur insuffle enfin de véritables métabolismes ; on se préoccupe de leurs développement et de leur morphogénèse — cf. les travaux de René Doursat, de l'Institut des systèmes complexes.

Les « matheux » de l'A-Life sont fascinés par la similarité parfaite des propriétés des graphes qui représentent des systèmes aussi éloignés que la régulation de l'expression des gènes, la croissance du réseau de transport aérien, la croissance du Web, les flux d'impulsions des neurones des régions du cortex préfontal, le développement des sous-réseaux sociaux sur Facebook. La croissance du Web, en particulier, comme parfaite illustration du développement « vivant » d'un graphe de pages et de liens (hypertexte) a redonné un coup de fouet, il y a quelques années, à la théorie des graphes — quelque peu assoupie, disons le, depuis les résultats pourtant superbes de Renyi et Erdos sur les graphes aléatoires — un outil immédiatement adopté par tout A-Lifer qui se respecte. À la conférence, on croisait communément des graphes small-world, qui sont presque aléatoires mais où tous les noeuds sont quand même proches les uns des autres, voire des graphes scale-free, qui présentent le même aspect quelque soit le grain auquel ils sont examinés, objets d'études et de modélisations innombrables.

D'autres chercheurs s'inspirent directement de la nature et travaillent volontairement hors du domaine de la simulation par logiciel à construire des systèmes moléculaires, biologiques ou physiques, qui soient autonomes, capables de se reproduire et d'évoluer. Des chimères surprenantes hantèrent une matinée les couloirs de l'Université de Winchester : toute la chimie de la transcription et de la polymérisation du RNA réinjectée dans une émulsion de gouttes d'eau dans l'huile, circuits logiques des semi-conducteurs simulés in vivo par des brins de DNA... Avec une approche intéressante à bien des titres : à une époque où l'on se précipite vers les nanotechnologies et l'on envisage, sans blêmir, des systèmes dans lesquels sont lâchés 10^24 nano-molécules censées accomplir ensemble une fonction particulière — et dont la programmation centralisée dépasse évidemment non seulement les capacités de calcul mais remet carrément en question nos méthodologies mêmes de programmation, inadaptées à un parallélisme si massif — il est urgent d'affiner notre compréhension du développement « par évolution » de tels systèmes !

Enfin cette édition de la conférence a également permis de remettre ces travaux en perspective. La principale question, que nous apprennent ces systèmes artificiels sur la vie et la nature elles-mêmes ? est évidemment ouverte et le restera. Peut-on déduire de l'émergence de comportements apparemment intelligents de modèles (artificiels) placés dans des environnements à la complexité contrôlée, que l'évolution naturelle a suivi et suit les mêmes routes ?

La présentation salutaire d'Eva Jablonka rappelait par exemple l'incroyable variété des mécanismes naturels d'évolution épigénétique, c'est-à-dire des dispositifs de transmission de caractères d'une génération à l'autre sans recours aux gènes. De même, plusieurs débats étaient consacrés au lien aujourd'hui controversé entre évolution naturelle et complexité. La pression sélective favorise-t-elle toujours les organismes plus complexes ? Intuitivement la réponse nous semble évidente : bien sûr, votre organisme, cher lecteur, résultat de la longue chaîne évolutive qui nous rattache à nos ancêtres eucaryotes, est certainement plus complexe que celui de la bactérie, du moins je l'espère. Mais, en fait, il n'y a pas de mesure universelle de la complexité pour le vivant et le parallélisme intuitif entre la flèche de l'évolution et celle de la complexité ne va pas de soi. (Par exemple, si l'on se contente de compter le nombre de gènes, les résultats du Human Genome Project, menés entre autres par Craig Venter, ont montré qu'à cette aune la complexité de l'homme est à peine supérieure à celle de la souris — ce qui laisse à penser...) Des philosophes, invités à débattre ici avec les biologistes et les informaticiens, s'interrogeaient encore sur quel urgence nous pousse à considérer la distinction entre vivant et non vivant comme aussi primordiale, et en même temps nous fait attribuer, sans sourciller, perception, raison ou volonté à des objets quotidiens tout à fait inanimés.

Il faut bien conclure, provisoirement, que l'on aurait besoin de bien plus qu'une seule vie (naturelle) pour comprendre et dominer les arcanes de la vie artificielle.

Les très riches heures de l'informatique française

Dans une concomitance toute aussi imprévue que superbe, le tandem Patricia Russo et Serge Tchuruk annoncent leur intention conjointe de quitter le navire Alcatel-Lucent en pleine déroute, tandis qu'IBM celle d'acquérir l'éditeur de logiciels national emblématique, Ilog. Dans la torpeur orageuse d'un été qui menace d'être meurtrier pour la finance mondiale — Merrill Lynch aux abois implore aujourd'hui le singapourien Temasek de le sauver à nouveau de la déconfiture façon Bear Stearns — on devrait entendre une fois encore le concert contradictoire des vitupérations bien hexagonales contre les méfaits de la mondialisation et du capitalisme libéral, automatiquement qualifié de « sauvage », devant le désastre révélé de la fusion de Lucent et d'Alcatel, et des cocoricos patriotiques devant cette nouvelle démonstration de la valeur inégalée des talents scientifiques français qui attirent la concupiscence d'Armonk jusques aux riantes pâtures de Gentilly-sous-Périphérique...

Revenons à des perspectives plus sérieuses : la transaction proposée par IBM, une OPA amicale — les deux sociétés se connaissent bien et travaillent depuis longtemps ensemble ; des rumeurs d'acquisition avaient déjà circulé plusieurs fois par le passé — pour un prix maximal de 10 Euros par action, soit une prime substantielle sur le cours de Bourse, en chute libre depuis le début de l'année, tombe probablement à pic à plus d'un titre pour l'éditeur français. D'abord notons la décence du comportement d'IBM dont l'offre valorise généreusement la société. Invariablement présentée comme la « startup » française qui a réussi, hélas bien esseulée, sur les marchés mondiaux, émanation de l'Inria qui concentre tout le prestige et le panache du savoir-faire informatique national, en particulier, dans les logiciels complexes — n'a-t-il pas su séduire le titan même de cette industrie , Microsoft, à venir créer dans les champs fertiles de la Ferme du Moulon un Centre de recherche commun ? — Ilog est à ce prix ! Quoi de plus gratifiant pour « l'industrie du logiciel français » ? (Vivement que l'on étende l'Appellation d'origine contrôlée au logiciel ce qui permettrait peut-être à nos éditeurs encore anémiques de connaître le sort enviable de la Noix du Périgord, du Camembert de Normandie où du Jambon de Parme, dont on sait qu'il est une des causes graves de rupture des négociations du Cycle de Doha à l'OMC.)

Au plan financier, l'éditeur était depuis un an pénalisé par la faiblesse du dollar, alors qu'il est coté au NASDAQ autant qu'à Paris et qu'une grande partie de son chiffre d'affaires est réalisé aux Etats-Unis. D'après Les Echos, l'effondrement du cours de Bourse depuis son plus haut de 100 et quelques Euros au plus fort de la « bulle Internet » en mars 2000, suivi d'une nouvelle glissade depuis début 2007 après un redressement laborieux dans les années 2003-2005, aurait attiré un fonds, Conversion Capital, dont l'activisme aurait accéléré des discussions qui, comme on l'a dit, devaient être dans l'air depuis quelques temps déjà.

Et que dire de l'usure des dirigeants-fondateurs français de jeunes pousses cotées au NASDAQ et à Paris ? Après des années à la tête de l'éditeur de logiciels qu'il avait co-fondé, Bernard Liautaud a passé cette année la main à SAP, pour réapparaître chez Balderton Capital sous les habits (britanniques) de l'investisseur en capital-risque. Si l'aventure tente aujourd'hui Pierre Haren, placé finalement dans la même situation, nous serions ravi de l'accueillir dans notre bien modeste équipe d'investissement de fonds étiques (rien à voir avec les fonds éthiques) en TIC (Technologies de l'information et de la communication) !

C'est une aventure bien différente que celle de Patricia Russo et de Serge Tchuruk, dont la démission de la tête d'Alcatel-Lucent ressemble fort à un aveu du bilan désastreux de la fusion des deux équipementiers télécoms. Alors qu'une certaine fraction de l'échiquier politique lance la curée en ne retenant de l'événement que « les indemnités de départ indécentes » de ces dirigeants, semblant oublier le balayage sous le tapis de la sordide affaire de fausses factures de l'Alcatel-Alsthom de l'époque qui avait coûté à Pierre Suard, le dirigeant d'alors, son poste et plusieurs inculpations en 1995 — dont les non-lieux viennent, rassurons-nous, de tomber en 2006 et au printemps de cette année, treize ans après ! — il semble qu'il faille plutôt s'interroger utilement sur l'évolution de cette industrie des télécoms où jadis champion brillant et innovateur, Alcatel s'est naguère fait largement distancer au point d'apparaître complètement immobilisé. La consolidation à l'oeuvre chez les opérateurs télécoms les a progressivement transformés en géants (comme Verizon et AT&T). Du coup, ces nouveaux géants se sont emparés du contrôle effectif du marché des équipements où les équipementiers télécoms historiques régnaient jusqu'alors en maîtres incontestés. Le pouvoir avait changé de mains et la course à la taille pouvait apparaître alors aux yeux des Lucent, Alcatel, Motorola, Tellabs, comme une stratégie appropriée pour reprendre la main. (D'ailleurs les difficultés actuelles d'un Motorola sont sans doute un effet de la même cause.) Mais le timing était défavorable : la montée en puissance des fournisseurs chinois comme ZTE et Huawei a brutalement érodé les marges et doublé la course à la taille d'une concurrence fatale sur les prix.

Quant à l'industrie du logiciel d'entreprise, le rachat d'Ilog par IBM est une péripétie de plus, comme celui de BO par SAP pour n'en citer qu'un seul autre qui ait marqué récemment les esprits, dans la consolidation massive maintenant bien entamée. L'offre, de plus en plus indifférenciée et globale, se concentre dans les mains d'un oligopole de quelques acteurs comme IBM, Oracle, Microsoft, SAP et pour quelque temps encore peut-être des Sungard, CA, et Symantec dans certains secteurs.

Redécoupage des marchés, consolidation de l'industrie, rééquilibrages à l'échelle mondiale, comme dans beaucoup de secteurs celui du logiciel français est réduit à subir, sans pouvoir réellement agir, les contrecoups et les mouvements mondiaux qui agitent les marchés d'aujourd'hui.

P.S. du 1er août : Et le shopping continue ; c'est aujourd'hui Sungard qui annonce son intention d'acquérir le français GL Trade !

Le Web sous surveillance : quand Lopsi rencontre Hadopi

Le moins que l'on puisse dire c'est que la conception gouvernementale
de « l'Internet à la française » — comme le service public « à la
française » que l'on sait envié par le monde entier, copié mais jamais
égalé depuis Napoléon — et mis en texte par la loi Hadopi provoque
une nouvelle levée de boucliers. La loi tire son nom aux consonances
vaguement italiennes (addoppiare signifie redoubler) ou
américano-indiennes (la brique de terre crue séchée au soleil qui a
donné son nom au fameux éditeur de logiciels Adobe Systems, Inc.)
d'une nouvelle « haute autorité » — il n'y en a point de basse même
pour les basses oeuvres — la Haute autorité pour la diffusion des
oeuvres et la protection des droits sur Internet. La loi Hadopi est
dans la droite ligne du rapport Olivennes livré en novembre dernier à
l'Elysée par l'ex-PDG de la FNAC, rescapé depuis à la direction du
Nouvel Observateur. Après de très nombreuses réactions, le projet de
loi présenté au Conseil des ministres le 25 juin n'a gardé que le
titre moins sujet à controverse « Création et Internet » tout en conservant
l'essentiel de l'arsenal techno-répressif préconisé par le rapport
Olivennes.

Le point qui fait évidemment débat c'est, dans le cadre de la mission
de prévention et, éventuellement, de sanction du piratage des oeuvres
confiée à la Haute autorité, le recours à la « riposte graduée ». Mais
l'autre volet de sa mission, la régulation des mesures techniques de
protection et d’identification des oeuvres sous droits, semble à
l'examen tout aussi porteur de questions et de débats.

Depuis le rapport Olivennes on connaît bien l'ingénieux dispositif de
la riposte graduée. La rigueur et la précision du processus fait
honneur aux technocrates français. Postulat de départ, axiome
immarcescible : l'indépendance et l'impartialité de la Haute autorité
sont garanties. (Par qui ? Par quoi ? Quels recours ? Nous touchons là
aux mystères de l'Infaillibilité immaculée.) Implémentation retenue
pour ce postulat : au sein de cette Haute autorité, c’est la
commission de protection des droits, exclusivement composée de hauts
magistrats, qui prendra les mesures pour prévenir et sanctionner le
piratage. Les mesures en question constituent la fameuse riposte
graduée : façon Les Choristes — « Action ! Réaction ! » —, la
détection d'un piratage donnera lieu à des avertissements suivi
éventuellement de sanctions si le sujet ne se soumet à résipiscence
dans les délais.

Le premier avertissement délivré par les Commissaires de protection
des droits prendra la forme d’un message électronique et le second
d’une lettre recommandée, de façon à s’assurer que l’abonné a bien
pris connaissance du comportement qui lui est reproché. Si les
manquements persistent en dépit de ces deux avertissements,
l’internaute s’exposera à une sanction consistant en une suspension de
l’abonnement Internet pour une durée de trois mois à un an. La
commission pourra toutefois lui proposer une transaction comportant
une réduction de la durée de la suspension. En outre, le Commissaire
pourra, en fonction de l’usage, notamment professionnel, qui est fait
de l’accès au service de communication, recourir à une sanction
alternative à la suspension, sous la forme d’une injonction délivrée à
l’abonné de prendre des mesures de nature à prévenir le renouvellement
du manquement et à lui en rendre compte, le cas échéant sous
astreinte.

La CNIL, UFC-Que Choisir (« projet monstrueux conçu par les marchands
de disques, pour leur intérêt exclusif »), les députés européens, le
Conseil d'Etat, l'ARCEP, l'Association des services Internet
communautaires et hier encore
l'Association des Fournisseurs d'Accès et de Services à Internet
(Free, AOL France, Aricia, Azuria, Bouygues Telecom, DartyBox, Google
France, Kewego, Mana, Microsoft France, MySpace France, Neuf Cegetel,
Numericable, Orange, SFR et Telecom Italia) ont vite trouvé les deux «
bugs » évidents du texte pour étayer leur contestation.

Première question, qu'en est-il de la légalité et de la faillibilité
du dispositif de surveillance généralisée des réseaux numériques
nécessaire pour la détermination incontestable de l'oeuvre, de son
piratage et de l'auteur du piratage ?

Seconde question, l'abonné n'est pas forcément le pirate et vice-versa
! Foneros français, tenez-vous le pour dit, ou alors téléchargez
depuis les bornes WiFi aimablement mises en place par la Mairie de
Paris, par exemple, dans certains lieux publics. C'est la moindre des
politesses à rendre...

Le texte désamorce néanmoins partiellement cet épineux débat en
précisant que la mission des Commissaires de la protection des droits
n’est pas d’assurer une surveillance générale des réseaux numériques
ou des fournisseurs d’accès Internet. (Nous voilà rassurés !) Ils
agiront exclusivement sur saisine, pour le compte des ayants droit
dont les oeuvres auront été piratées, des agents assermentés des
organismes de défense professionnelle et des sociétés de perception et
de répartition des droits. Ce qui suppose évidemment que ces ayant
droits, ces agents assermentés et autres officines aient eu vent d'un
acte de piratage et en apportent les preuves incontestables : on se
demande avec intérêt comment ils pourront acquérir cette certitude
pour saisir la Hadopi !

Le texte prévoit que les sanctions prononcées pourront faire l’objet
d’un recours contentieux devant le juge. Le projet de loi durcit par
ailleurs la procédure judiciaire existante en permettant au tribunal
de grande instance d’ordonner, à la demande des titulaires de droits
sur les oeuvres protégées, des mesures de suspension, de retrait ou de
filtrage des contenus portant atteinte à un droit d’auteur ou un droit
voisin (par référé et plus par la procédure inspirée de la saisie
contrefaçon instaurée en matière de services de communication en ligne
par la loi du 21 juin 2004 pour la confiance dans l’économie
numérique).

Un autre éclairage sur la riposte graduée peut aussi être jeté si l'on
procède à une relecture plus fouillée du rapport Olivennes qui est à
son origine. Le 20 juin dernier, au milieu même de la tumultueuse
mêlée provoquée par le projet de loi, la startup AdVestigo
s'empressait de publier opportunément un communiqué de presse
affirmant qu’elle pouvait détecter et identifier la quasi-totalité des
contenus vidéo sur les réseaux peer-to-peer, bêtes noires de
l'industrie du disque et du film. Advestigo aurait ainsi atteint un «
taux de reconnaissance des différentes copies réellement disponibles
sur les réseaux de 97,9 % à 100 % selon les films considérés, avec 0.0
% de faux positifs ». Voilà fort à propos une technologie susceptible
d'intéresser les ayant droits et autres agents assermentés ! AdVestigo
a démarré en 2002, créée par deux docteurs chercheurs du CEA-LETI —
laboratoire du CEA implanté à Grenoble, le Leti est l’un des
principaux centres européens de recherche appliquée en
électronique. Le Leti est évidemment l'un des pourvoyeurs principaux
de propriété intellectuelle liée aux activités de défense nationale et
de sécurité intérieure. (L'un des fondateurs a, par exemple, travaillé
sur le traitement des images en temps réel sur des calculateurs
parallèles embarquée sur l'avion de combat Rafale.)

La société industrialise avec succès des travaux de recherche sur les
langages de programmation et les architectures matérielles pour les
traitements dits « data-parallèles ». Ses investisseurs sont Cap
Décisif, fonds de capital-risque amont en Île-de-France, I-Source, un
fonds de capital risque issu à l'origine de la CDC et de l'INRIA, et
EonTech un fonds d'investissement d'un groupement de banques
italiennes. AdVestigo avait été auditionné par la commission du
rapport Olivennes et sa caution technique est invoquée dans le texte
final du rapport de l'année dernière.

La Sacem et le STRJD (le Service Technique de Recherches Judiciaires
et de Documentation), qui s'est vu confier la police du réseau
Internet et la lutte contre toutes les formes de cybercriminalité,
sont déjà, sans surprise, utilisateurs du moteur de recherche
d'AdVestigo. On comprend que la startup soit pressentie pour fournir
le dispositif national déclencheur de la riposte graduée.

Constatons que la loi Hadopi, issue laborieusement
d'un an de sourdes tractations et de lobbying intensif selon certains,
arrive décidément en conjonction parfaite avec la préparation de la
future loi d'orientation et de programmation pour la performance de la
sécurité intérieure, dite Lopsi 2. (Mais où donc le législateur
va-t-il chercher tous ces noms ?) La crispation entre les partisans de
la ligne dure et leurs opposants se cristallise autour de trois
chantiers lancés par Lopsi : le fichier Périclès, énième et plus
récente forme du mythe du fichier de rapprochement total entre
affaires criminelles pour lutter contre tout type de délinquance —
selon des événements récents liés à la délation de cyberdissidents,
Google et Yahoo! sont déjà parfaitement équipés pour ça ! —, la
limitation ou non du pouvoir des juges d'instruction à accéder aux «
lieux de pouvoir » comme les ministères et les services secrets, et
surtout la permission à l'avenir de l'introduction de « chevaux de
Troie » informatiques dans les ordinateurs des citoyens. Cette
captation informatique et sonore (sont aussi visées les écoutes
téléphoniques) sera possible avec l'aval d'un juge mais sans le
consentement des intéressés.

Et cela au moment même où, le 18 juin, la Suède vote une nouvelle loi
autorisant un organisme civil, chapeauté par le ministère de la
Défense, à mettre en place de grandes écoutes des communications de
tous ses citoyens. Sans parler du programme des douanes américaines
vivement critiqué par Bruce Schneier, ou du projet de loi similaire à
celui voté en Suède discuté en Allemagne. L'arsenal français projeté
par Lopsi n'a donc plus rien a envier à celui des grandes démocraties
éprises de la liberté de la presse comme la Chine, la Birmanie, la
Corée du nord, l'Irak, la Tunisie, etc. Patients et charitables
lecteurs, il est temps de s'intéresser d'urgence à Freenet, PGP,
TrueCrypt, Entropy, Tor, Omemo, autres OFFSystem...

Surveillance privée, motivée par des ayant droits et des agents
assermentés d'officines de gestion de droits, et surveillance
publique, versée à la doctrine au nom d'un idéal sécuritaire, se
rejoignent donc parfaitement dans l'avatar moderne du Panopticon de
Bentham dont la métaphore, annoncée par Foucault, menace aujourd'hui
de s'appliquer au Web.

Eben Moglen moderne ouvrier à la trôle

Quel choix plus judicieux de l'OW2 pour recevoir à Paris Eben Moglen que celui de l'étroite cour chargée d'histoire donnant sur le Faubourg Saint-Antoine, « le cratère d'où s'échappa le plus souvent la lave révolutionnaire » ! Eben Moglen, avocat et professeur de droit, est avec Richard Stallman l'artisan des dernières évolutions de la GNU Public Licence (GPL) qui aboutirent à la publication de la version 3, dernière en date. Et de la tension entre système légaux et règles corporatistes, dont il est abondamment question dans la GPL v3, il y a bien longtemps que ce quartier du Paris ouvrier en abritait les querelles ! Autorisés par Louis XI à travailler librement dans dans le domaine à l'époque de l'abbaye Saint-Antoine, chassissiers, charpentiers de la grande et de la petite cognée, huchiers et ébénistes se regroupèrent en une vibrante communauté. Les règlements de la corporation, datant de 1290, furent assouplis en 1657 par Colbert pour « libérer la croissance » dirait on aujourd'hui, avant d'être resserrés et durcis en 1740, dans un esprit du temps pas très éloigné de celui qui prévaut actuellement, « pour oster les fraudes, les décevances et les mesprentures du mestier » ; leur disparition formelle fut l'oeuvre de Turgot à partir de 1776. Ce qui n'empêcha pas les explosions populaires ultérieures, incendies et pillages en 1789, barricades en 1830 et 1848, après le licenciement des Ateliers nationaux — déjà les méfaits rampants de la mondialisation, vous dis-je —, et en 1851 pour protester contre le coup d'état du prince-président. À proximité immédiate donc de la trôle de naguère, tuée par la fabrication en série, entre la Fontaine Trogneux et l'enseigne disparue du « Soldat Cultivateur », Eben Moglen présentait magistralement cette réédition moderne des débats séculaires qui avaient soulevé les passions du quartier parisien.

L'élaboration de la GPL V3, dixit Mogen, fut, comme pour les réglementations d'antan, un processus à la fois social et politique même s'il ne s'est pas manifesté par des pillages, des incendies ou des barricades. (Quoique, si l'on veut bien compter les modes « virtuels » de manifestations sur le Web...) Et en premier, la GPL v3 essaye de s'éloigner du caractère très centré sur le droit du copyright américain qui avait présidé à la GPL v2. Pour l'anecdote, Eben Moglen raconte que lors de multiples rencontres avec les autorités européennes de Bruxelles celles-ci sont systématiquement revenues sur l'usage du langage statutaire (issu du glossaire du copyright américain), et exigés que paragraphes et parties soient titrés et numérotés successivement à partir de 1. Autant ces premières exigences ont-elles été satisfaites rapidement, la dernière, cependant, devait heurter au plus profond le mysticisme éclairé de Stallman qui ne saurait envisager d'autre numérotation que celle, comme en C, qui ne commence par 0 ! La GPL v3 a donc été conçue pour être « transnationale » et compatible du mieux possible avec les législations locales : pour ce faire elle s'interroge sur comment « donner la permission » plutôt que sur « imposer des restrictions ». Une première conclusion se dégage alors : l'interprétation de la GPL v3 peut dépendre du droit local (souvent national).

Il y a donc distinction entre « l'état de fait », la « propagation » du code qui couvre tout ce qui n'en est pas l'exécution à proprement parler, qui relève d'un jugement technique d'une part et la « transmission » du code qui a trait à la permission effective de le recevoir et relève d'un jugement de droit local. Toutes les difficultés tournent ensuite autour d'une définition appropriée de la notion d'oeuvre. Doit-on considérer qu'une application résultant de liens statiques entre codes, dont certains sont sous le régime GPL, constitue une seule oeuvre ou non ? Et si l'édition de liens est dynamique à l'exécution comme en Java ? Les mêmes questions se posent pour les applications bâties sur une architecture orientée services qui distingue, par exemple, conteneurs et composants (que l'on songe aux serveurs d'applications, Beans, servlets et JSP), ou bien de services qui s'interposent entre application cliente et serveurs. Ces subtilités se composent avec le développement de nouvelles formes de livraison et d'accès au logiciel : hébergement propriétaire ou public, SaaS (Software As A Service), bientôt cloud computing.

Par ailleurs, la GPL a également ses variantes pour répondre à des besoins ad hoc de certains éditeurs et utilisateurs. Pour l'illustrer, Eben Moglen insiste sur le contraste entre la LGPL, qui ajoute de nouvelles permissions à la GPL, et l'Affero GPL (AGPL) qui, à l'inverse, ajoute de nouvelle restrictions à la GPL. Dans le premier cas la LGPL autorise l'édition de liens, pourvu que l'on puisse ré-exécuter cette édition de liens après une modification ultérieure de la partie du code applicatif sous le régime GPL v3 ; l'AGPL impose que le fournisseur de services basés sur un code sous régime GPL donne accès à ses utilisateurs au code source postérieurement modifié de la partie du code sous GPL v3. (Le contre-exemple est ici Google dont l'approche de la fourniture de services est propriétaire, alors que le repoussoir habituel de Moglen et Stallman reste le plus souvent Microsoft.)

D'autres sujets abordés par la GPL v3 masquent d'acrimonieux débats et des sourdes luttes d'influence entre les grands industriels du secteur. L'abandon des poursuites sur les brevets, par exemple, doit beaucoup d'après Moglen au radicalisme d'IBM et de HP sur le sujet de la brevetabilité du logiciel. La position de la GPL v3 sur le matériel — comment la « liberté » d'un logiciel s'étend-elle ou non aux autres terminaux et matériels sur lesquels il peut être amené à fonctionner ? — doit ici beaucoup au lobbying de Sun Microsystems en vue de protéger la source, considérable d'après Moglen, de revenus que représentent les licences Java pour les téléphones cellulaires. Le compromis offert par la GPL v3 repose sur une définition du « consumer device » (terminal ou appareil grand public), qui exclut les systèmes d'armes (!), les instruments médicaux, les réseaux sécurisés défense, etc. qui sont de facto exclus du champ de la GPL v3. Mais cette définition de l'appareil grand public est elle-même issue de la législation du droit de garantie aux USA : a-t-elle une valeur internationale ?

On le voit, il n'y a pas que dans le domaine de la programmation et du code que la complexité s'amplifie. Il faut envisager un temps où tout texte de code source et tout service Web devra être accompagné d'un meta-texte légal aussi complexe, voire plus, en décrivant le régime d'usage et les permissions et restrictions qui lui sont associées. (Pourquoi dès lors ne pas imaginer des compilateurs, des éditeurs de liens et des environnements de programmation intégrant directement un paramétrage légal en fonction des licences des différents composants logiciels développés et employés ? Un « Legal Studio 2009 », un « Safe Harbor Eclipse IDE », une option « -legalese » pour tous les compilateurs ? ) Où sera alors la valeur pour l'utilisateur, dans le code source ou dans le code légal ?

Le retour en grâce des langages de programmation dynamiques

L'équipe de développement de Webkit, l'implémentation Open Source du navigateur Web qui est au coeur de Safari sous OS X, vient d'annoncer un moteur Javascript aux performances impressionnantes, SquirrelFish. Il existe déjà depuis quelques années plusieurs variétés d'implémentations complètes d'interpréteurs et de compilateurs du langage : dans le monde .NET, un compilateur vers la machine virtuelle CLI, ailleurs SpiderMonkey, l'interpréteur écrit en C intégré à Mozilla et Firefox, Tamarin, un projet Open Source de moteur Javascript haute performance pour la nouvelle version du standard ECMAScript (4ème édition, ES4) développé à l'origine pour ActionScript par Adobe et maintenant logé à la Fondation Mozilla, ou Rhino une implémentation en java du langage Javascript. Ce renouveau d'intérêt pour les langages « dynamiques » est porté par la vague de l'architecture nouvelles des applications Web dans laquelle — retour de balancier — le client dispose d'une capacité autonome de calcul et de présentation tout en communiquant avec des services Web distants.

Y a-t-il, à proprement parler, une définition formelle et généralement acceptée de ces langages de programmation dynamiques ? Javascript en est aujourd'hui l'exemple emblématique. Pas tout à fait orienté objet, au sens canonique de système de classes avec héritage, mais offrant néanmoins de véritables objets sur le modèle de « prototypes », Javascript présente des types dynamiques, des « closures » et de nombreuses caractéristiques de langages dynamiques antérieurs comme Smalltalk, Lisp voire Prolog et Self. Aujourd'hui on songerait plus naturellement à des langages employés dans l'univers des applications Web comme Ruby, PHP, Perl, Python, Lua, etc.

Depuis longtemps les langages dynamiques souffrent d'une image de marque déplorable, sorte de sceau de l'ostracisme qui les frappe dès qu'ils sont comparés à des langages de programmation comme C/C++ ou Java, pour ne citer qu'eux. La vulgate enseigne que les langages dynamiques sont peu performants et lents à l'exécution d'une part et ne disposent pas de tout l'outillage et l'instrumentation sophistiquée qui existe pour les autres langages et dont il est indéniable qu'elle joue un rôle crucial dans leur succès industriel et commercial.

Mais ce manque de prestige actuel de cette classe de langages de programmation est plutôt le résultat des circonstances historiques que l'expression d'une nature propre, rétive ou trop absconse. Jadis — en tous cas à ceux pour qui les mots comme CLOS, ML, Smalltalk ou Scheme évoquent passagèrement de lointains mais persistants maux de crâne — des langages dynamiques comme Common Lisp disposaient de compilateurs et d'outils très avancés dont les performances avaient finalement peu à envier à leurs jeunes concurrents typés et statiques de l'époque. À peu près contemporains des précédents, les efforts des équipes de Parc Place et de Digitalk visaient, avec un certain succès, à améliorer les performances et l'outillage du langage Smalltalk (Dave Griswold, Gilad Bracha). Ceux du Sun Microsystems Lab (David Ungar, Randall Smith) sur le langage basé sur les objets-prototypes, Self, et les innovations apportées à son compilateur par Urs Hölzle — dont les travaux sont également utilisés dans la machine virtuelle HotSpot — devaient aussi croiser Smalltalk au milieu des années 1990 sur le projet Strongtalk, emporté comme quelques autres sous la déferlante Java à partir de 1995, et survivant aujourd'hui dans le domaine de l'Open Source. Toutes ces explorations avaient mis au jour de nombreuses techniques de représentation et de compilation des langages dynamiques qui rendaient comparable leur usage à celui des langages, devenus depuis classiques, comme C et C++. Elles n'ont pas eu l'écho industriel et commercial qu'elles attendaient, victimes probablement d'un manque de marketing au moment où explosait Internet sur le devant de la scène.

Le passé, pas si lointain, nous enseignerait donc plutôt que les langages dynamiques devraient pouvoir afficher de bonnes performances à l'exécution comme leurs cousins statiques et typés. Et si l'histoire récente est conseillère, il faudrait plutôt chercher à inventer interpréteurs et compilateurs hors des canons généralement convenus et affinés pour ces langages typés et statiques. (Comme le remarque un papier de UCLA Irvine sur ces sujets, un compilateur écrit en suivant scrupuleusement les règles du fameux Dragon Book ne peut que s'étrangler devant un fragment de Javascript comme celui-ci : x = 0; for( i = 0; i < 500000; i++ ){ x = x + i; if( i == 499999 ) x = "oops!"; } dans lequel la gestion des types révèle quelques surprises.) Qu'en est-il des autres outils habituels du programmeur ?

La barre est placée assez haut. Les « Integrated Development Environments » du jour offrent tous pléthore d'assistants, d'auto-completion, de liens vers les définitions et la documentation des objets et des fonctions, de refactoring, de navigateurs, de représentations arborescentes, de compilation au vol ou incrémentale, etc. Les environnement modernes de développement pour Java ou pour C/C++ sont de bons exemples du niveau qu'il faut aujourd'hui atteindre pour prétendre à outiller correctement un langage de programmation. Au point que ces IDE tendent à se détacher des langages de programmation eux-mêmes et se transformer en plates-formes génériques de conception et de développement de programmes utilisables dans la plus grande variété de circonstances et de scénarios de production de code.

La bonne stratégie consiste alors à doter les langages de programmation dynamiques des caractéristiques nécessaire à leur intégration la plus indolore possible dans ces IDE-plates-formes dont l'emploi se généralise. La JSR 223, par exemple, « Scripting for the Java Platform » va dans ce sens. Cette spécification définit comment échanger données et information entre Java et des langages de script comme PHP, Ruby, Javascript, etc. au sein d'une même application hybride Java/script.

De même les innovations découvertes hors des sentiers battus des compilateurs traditionnels constituent probablement la prochaine étape dans l'évolution des outils et des langages de programmation dynamiques. L'équipe de recherche de Michael Franz à UCLA Irvine ont, par exemple, récemment publiés une série de papiers sur la compilation de langages dynamiques et l'optimisation de la performance à l'exécution. D'abord, même si elle est plus laborieuse, l'analyse statique des programmes écrits dans un langage de programmation dynamique reste possible et inférer le type des variables d'après le texte du programme donne de bons résultats dans la grande majorité des cas. Une autre technique — dont le nom savant, Polymorphic Inline Caching, vous permettra de briller dans les foocamps et autres barcamps — permet de contourner le problème difficile de la détermination simultanée des types de la fonction appelante et de la fonction appelée lorsque toutes deux attendent des arguments aux types variables suivant les objets. Une technique similaire dite des « arbres de trace » consiste à utiliser un interpréteur et enregistrer les chemins les plus souvent parcourus à l'exécution en fonction du type des variables sur lesquelles les choix de parcours sont faits (par exemple dans les boucles ou dans les instructions conditionnelles) et compiler chacune des branches de ces arbres de trace en appliquant les optimisations appropriées au type des variables qui figurent dans chaque branche.

Dans ces deux dernières techniques, notons qu'on emploie un tandem formé d'un interpréteur et d'un compilateur pour le langage de programmation dynamique concerné. L'interpréteur exécute le programme et collecte simultanément une information sur la statistique de l'exécution ; ces données sont examinées par le compilateur qui produit des versions optimales (code machine) pour les différents agrégats statistiques identifiés, parfois plusieurs pour le même fragment de code source, en fonction du type des variables employées.

De plus, ces techniques semblent bien adaptées aux générations actuelles et à venir de puces multicoeurs. À l'heure où beaucoup s'interrogent sur les nouveaux usages auxquels consacrer ce surcroît de capacité de calcul des postes clients — c'est un des chevaux de bataille de Craig Mundie, le patron de la recherche à Microsoft — la structure même des nouvelles techniques d'optimisation des compilateurs de langages dynamiques se projette assez bien sur ces architectures matérielles. Pourrait-on imaginer un compilateur JIT qui répartisse au vol le calcul des branches distinctes de l'arbre de trace précédent sur les différents coeurs de la machine ? L'optimisation apparaîtrait alors comme quasi simultanée aux premières exécutions du programme à laquelle elle pourrait se substituer tôt, chaque coeur exécutant une version « optimisée par les types » du même code.

On le voit les perspectives sont assez ouvertes. Alors que les programmeurs s'intéressent de plus en plus aux langages de programmation dynamiques pour leur productivité et leur flexibilité devenues indispensables pour les applications Web, chercheurs, laboratoires industriels et communautés Open Source manifestent un regain d'intérêt pour toutes sortes d'innovations techniques qui faillirent être oubliées dans la brillante génération antérieure délaissée par les haruspices du marketing.