Ceux qui avaient sagement remplis les bancs de l'amphithéâtre Binet, rue des Saints-Pères, ce vendredi soir, pour assister à une confrontation disputée entre tenant et opposant du « patriotisme économique », l'une des notions clé de la réflexion économique exprimée par notre classe politique depuis l'affaire Danone de 2005, furent probablement déçus. Car de dispute point ! Les deux prestigieux orateurs, Nicolas Baverez et Jean Pisani-Ferry, étaient au fond bien d'accord. Le concept même est au mieux une erreur de jugement regrettable, au pire un aveuglement dogmatique particulièrement menaçant pour l'avenir !
Nicolas Baverez s'auto-proclamant procureur à charge remarquait, en introduction, que les manifestations d'un patriotisme économique n'avaient pas attendu l'envolée lyrique de M. de Villepin pour mettre quelques grains de sable dans le commerce mondial. Le renforcement réglementaire ad hoc aux USA pour interdire à la compagnie pétrolière chinoise CNOOC de prendre le contrôle d'Unocal ou à une société originaire de Dubaï de s'emparer de la gestion des ports américains, montrait que même au pays « modèle » du libéralisme les tendances protectionnistes étaient loin d'être éteintes. Mais en Europe, le débat fit rage dans les mêmes termes autour d'Airbus, de Volkswagen et d'Euronext en Allemagne, du rôle de la Banque centrale italienne à Rome, d'Endesa en Espagne et, en France, autour de Danone, de Thomson, d'Arcelor, de Suez-GDF, etc. Dans la Russie de Poutine, l'énergie est devenue une affaire d'Etat avec Gazprom, et les concessions de Total et de Shell sont remises en cause. Nicolas Baverez trouve à ce sujet une belle formule : « depuis qu'elle n'est plus communiste la Russie est de plus en plus soviétique ». En Amérique du Sud, Evo Morales et Hugo Chavez renationalisent progressivement le secteur de l'énergie. Bref, en même temps que progresse la mondialisation, de nombreuses réactions isolationnistes se font jour çà et là.
Car c'est bien là que Nicolas Baverez situe la source de ces difficultés. En progressant, la mondialisation transforme capitalisme et démocratie. La mutation est sensible sous plusieurs formes : une demande croissante de protection pour les populations déstabilisées par ces progrès ; la montée des pays émergents dans l'économie mondiale. Baverez ne put s'empêcher de rappeler qu'à l'occasion de l'OPA de Mittal sur Arcelor, un éminent ministre avait cru bon de déclarer péremptoirement que « M. Mittal ne connaît pas la grammaire de l'économie moderne», propos littéralement racistes que l'on juge aujourd'hui à l'aune du comportement du management d'Arcelor qui ne trouva rien de mieux que de courir dans les bras des oligarques russes de Severstal pour monter une contre-offre dont l'artificialité ne trompa heureusement personne (d'excellents grammairiens probablement !). C'est précisément des entreprises comme Mittal, Tata, Huawei, Lenovo et d'autres qui écrivent la nouvelle grammaire de l'économie mondiale.
Pour Baverez, le constat est exacerbé en France par notre tempérament national qui porte au déclin et à la crise identitaire. La réponse de tous les gouvernements, de droite comme de gauche finalement, à été de vouloir « étatiser le social », ce qui a conduit, selon lui, à des investissements stratégiques « extravagants », ayant pour résultat de freiner l'adaptation de notre système économique à la mondialisation jugée « satanique ». Le recours au registre religieux et à celui des passions est intéressant chez Nicolas Baverez. En effet si l'on parle de « patriotisme » - qu'un sang impur abreuve nos sillons ! - et « d'économie » on entretient bien une confusion entre les registres de la passion et de la raison qui ne peut tenir lieu de réflexion.
Cette confusion des genres est, de plus, dangereuse pour l'avenir, selon Baverez. Il n'y a pas d'exemple de réussite par le protectionnisme et les fondements de cette doctrine, déjà employée dans les années 30 en France, avaient entraîné malthusianisme et repli sur l'empire colonial avec une chute marquée de l'activité en France qui en 1939 n'avait pas même retrouvé son niveau de 1929. Contre l'anti-libéralisme, « plaie de notre pays », Baverez se fait l'avocat de nouveaux rôles pour l'état qu'il juge plus à même d'accompagner les transformations évoquées plus haut et de faire jouer à plein les atouts français. Ces points et d'autres ont été développés par Jean Pisani-Ferry qui dirige, à Bruxelles, l'institut Bruegel qui mène précisément une réflexion sur ces mutations.
L'état, ont rappelé les deux orateurs, instituent le marché et non pas l'inverse. (Lire là dessus le salutaire "La Place du marché" de Michel Henochsberg, paru en 2001.) Il devrait donc réassurer les risques de l'économie ouverte de marché, qui s'étendent aujourd'hui, au delà du marché même (autre incunable : "Les Défaillances de marché" de Bernard Salanié), aux registres de l'environnement, du climat, de la santé, etc. Seconde responsabilité : édicter les normes juridiques, comptables, et généralement la réglementation de l'indispensable gouvernance du marché, son rôle institutionnel. Enfin, promouvoir la compétitivité du territoire dont, an tant que gouvernement des citoyens, il a la charge. En France, nous dit Baverez, le bilan sur ce point est pathétique : plus d'un million de français de moins de 35 ans ont quitté le pays depuis 10 ans. (Les dix années précédentes avaient également connu un exode important de jeunes très qualifiés, particulièrement dans le secteur de l'informatique : la Silicon Valley constituait curieusement une des plus grandes « colonie » de français hors de France.)
Sur la plupart des points, Jean Pisani-Ferry, directeur du « think tank » européen Bruegel, acquiesçait. Le patriotisme économique, remarquait-il ironiquement - on l'espère - est un des produits français qui s'exporte bien ! Reprenant le discours originel du Premier ministre, il y décelait derrière la formule la conviction fondatrice que, d'après de Villepin, la nation devait maintenant « défendre les intérêts des salariés » et pour ce faire « protéger les entreprises ».
Du coup, Pisani-Ferry exprimait sa perplexité devant le réflexe obsidional alors que le CAC 40 est à 46 % détenu par des intérêts étrangers, que 2/3 du chiffre d'affaires des vingt premières entreprises françaises est réalisé hors de France et que 2/3 de leurs personnels y travaillent. Les grandes entreprises que l'on se plaît à imaginer françaises sont aujourd'hui internationales. Pisani-Ferry renvoie à ce sujet à Robert Reich qui au début des années 1900 publiait "Who Is US?" s'interrogeant sur la nationalité réelle des entreprises américaines qui migraient de la structure centralisée des multinationales à celle distribuée des réseaux fonctionnels. On pourrait y rajouter les articles de Thomas Friedman, célèbre pour "The World Is Flat". Selon Pisani-Ferry, dans le monde économique actuel, la localisation des entreprises compte moins que leur capacité à trouver et employer les talents où qu'ils soient dans le monde. Sur ce point il rejoint donc l'analyse de Baverez et concède qu'un des rôles de l'état est bien d'encourager l'éclosion de ces talents (éducation, enseignement, formation) sur son territoire (aménagement, regroupements du capital, de l'université et de la recherche). Plutôt que l'Agence de l'innovation industrielle, institution d'un autre âge, il recommande évidemment les pôles de compétitivité - mais 66 pôles, vraiment ? Pour illustrer, il oppose Gazprom, l'état russe sous le voile bien léger de l'entreprise privée, archétype de ces entreprises étatiques qui dépassent dans certains secteurs (énergie, armement...) les entreprises privées, au modèle IBM d'aujourd'hui, entreprise totalement décentralisée qui bénéficie des talents là où ils se trouvent. Dans cette chronique j'avais déjà noté que même pour les toutes jeunes entreprises, les startups que nous sommes amenés à rencontrer, il n'était plus rare de trouver des modèles « mondiaux » à leur (petite encore) échelle : équipe de développement en Ukraine ou en Inde, marketing en Angleterre ou aux USA, sous-traitants dans le monde entier.
Le débat qui suivit permit surtout aux orateurs renforcer leur position commune sur l'ineptie du patriotisme économique par de nombreux exemples sortis de l'actualité. Pour Nicolas Baverez il n'y a pas de secteur clé pour lesquels se justifierait une forme même édulcorée de protectionnisme ; pour Pisani-Ferry, plus nuancé sur ce point, il est urgent de définir les nouvelles politiques publiques en s'écartant des politiques industrielles d'arrière-garde mais également du laissez-faire incontrôlé.
Débat consensuel donc sur l'inanité de l'arsenal poliorcétique déployé à grands frais ces derniers temps dans notre beau pays. Mais qu'importe, pendant ce temps là, selon le classement de la compétitivité de 125 pays publié chaque année par le Forum économique mondial, la Suisse se hisse à la première place mondiale, devant les . La France perd six places pour se retrouver au 18e rang, victime de ses déficits et d'un manque de flexibilité du marché du travail. Ailleurs, la Commission va s'attaquer au décret français sur les secteurs protégés annonçant la multiplication des contentieux entre la France et la Commission européenne. Le bilan très mitigé de la fameuse « stratégie de Lisbonne », adoptée lors du Conseil européen de 2000 - dans la période d'exubérance irrationnelle sans doute - a mené, en 2005, à une révision des objectifs et des méthodes et imposé, notamment, à chaque État de présenter un « programme national de réformes », et patriote aurait-on envie d'ajouter !
dimanche, octobre 22, 2006
samedi, octobre 21, 2006
Prochaine étape pour AJAX : un middleware orienté message
Avertissement : ce billet contient des fragments explicites de CODE ; le CODE a été reconnu comme substance à risque dans de très nombreuses études de cas ; consulter votre urbaniste des systèmes d'information avant toute consommation de CODE et pas d'usage prolongé sans avis médical.
Le succès d'AJAX auprès des programmeurs d'applications Web est fulgurant. Il faut l'attribuer d'une part à la demande croissante d'interactivité dans le navigateur Web, conséquence du succès de sa diffusion comme frontal aux applications d'entreprise et aux services grand public, et, d'autre part, à la simplicité de l'implémentation. Toutes les versions modernes des navigateurs offrent en effet un interpréteur JavaScript, permettant d'exécuter des traitements programmés directement dans la page Web sur le navigateur du poste client, et, bien sûr, la fonction d'appel asynchrone de pages Web, écrites en général en XML - l'objet XMLHttpRequest.
Le principe de fonctionnement est assez simple. Lorsqu'un navigateur affiche une page Web, il construit une représentation interne de la page en mémoire sous forme d'un arbre dont les « feuilles » représentent les objets de base à afficher (texte, image, etc.) avec leurs attributs graphiques. Cet arbre en mémoire est formellement défini par une spécification du W3C, le DOM (Document Object Model), à laquelle se conforment les navigateurs Web. Cette spécification définit également une interface de programmation complète qui permet de modifier au vol cet arbre, et donc le document, à partir d'un langage de programmation, en particulier de Java et de JavaScript. (D'autres bibliothèques ont été depuis développées qui permettent également de travailler sur l'arbre DOM depuis d'autres langages comme C, C++, PHP, Python, etc.) Dans le cadre d'AJAX, l'API JavaScript est particulièrement intéressante dans la mesure où le navigateur lui-même contient un interpréteur ce qui autorise le développeur à mettre dans la même page Web le contenu et les programmes les modifiant en réponse aux actions des utilisateurs. D'un simple document la page Web est devenue un objet complexe, contenant programmes et données.
Voilà pour l'interface graphique interactive. Pour ce qui est de la communication avec les serveurs, le sésame s'appelle XMLHttpRequest. Il transforme la page Web en client dans une architecture client-serveur classique. Au travers d'un requête XMLHttpRequest qui est envoyée à un serveur, le script JavaScript en cours d'exécution depuis une page Web peut recevoir des données supplémentaires du serveur. Cette communication est asynchrone : le script est « réveillé » par l'arrivée des données lorsqu'elles ont été envoyées par le serveur ; la communication ne bloque donc pas l'utilisateur qui peut poursuivre les interactions pendant l'attente des résultats de la requête (ou d'un message d'erreur du serveur). La requête est transportée par le protocole HTTP, elle bénéficie donc des mêmes avantages et souffre des mêmes inconvénient que le protocole lui-même. En particulier, cette implémentation du mode de communication n'offre pas de notion de session : chaque requête est indépendante des autres.
En théorie, la réponse du serveur à une requête asynchrone XMLHttpRequest peut prendre des formats divers. Le texte complet de la réponse est renvoyé dans un champ particulier "responseText". Cependant, et dans l'esprit d'interopérabilité des services Web prôné dans l'architecture orientée service (SOA), il est habituel que la réponse à une telle requête soit un document XML. Pour en simplifier le traitement, un autre champ du résultat, "responseXML", contient les données directement sous forme d'arbre DOM qui peut alors être manipulé par la même API en JavaScript que nous avons mentionné plus haut.
Mais ce n'est pas, loin de là, la seule possibilité. On trouve par exemple de plus en plus des réponses constituées de données au format JSON. JSON est un format léger de transport de données sous forme d'une chaîne de caractères empruntant directement à la syntaxe JavaScript. Ainsi ce format n'a formellement pas à être « interprété » par un script qui le reçoit mais simplement « évalué ». Les données au format JSON occupent moins de place qu'un document XML dans le transport via HTTP et leur exploitation est immédiate du côté navigateur, qui n'a pas dans ce cas à utiliser d'interpréteur XML.
Ajax ne pourra atteindre un nouveau degré de maturité que lorsque la question de la communication avec les programmes et processus se déroulant sur les serveurs aura trouvé une réponse qui s'affranchisse des contraintes imposées par le mode « sans mémoire » de HTTP. Plus précisément, l'épineuse difficulté réside dans le moyen à trouver pour qu'un processus serveur, déclenché ou non par une requête XMLHttpRequest, puisse, à son initiative, communiquer des données au navigateur du poste client. Le protocole HTTP ayant été conçu pour transporter des requêtes et des données à l'initiative du client, il s'agit de réfléchir à une forme d'inversion du modèle de communication. C'est ce à quoi s'attellent aujourd'hui différents groupes de travail dans la communauté des développeurs Ajax.
En l'état, il existe des solutions techniques. D'abord signalons que le protocole HTTP prévoit déjà la possibilité de provoquer le rechargement périodique d'une page depuis le serveur. En utilisant une balise:
META HTTP-EQUIV="Refresh" CONTENT="n"
on indique au navigateur de recharger et réafficher toute la page en question toutes les « n » secondes. Le rafraîchissement périodique de toute la page ne fait cependant pas forcément l'affaire de scripts Ajax du côté client, qui peuvent n'être intéressés que par une partie des données qui y figurent, qui doivent conserver un état de l'interaction avec l'utilisateur à un instant donné (état qui serait perdu au rafraîchissement suivant), voire pour lesquels la périodicité d'un rafraîchissement est inutile ou incohérente.
D'autres solutions ont donc été recherchées pour inverser l'initiative de la communication. Une première repose sur l'utilisation des protocoles des serveurs de messagerie instantanée (IM). Dans ces serveurs, la gestion de la présence des interlocuteurs est à l'initiative du serveur lorsqu'un nouvel utilisateur se déclare prêt à recevoir les messages. Nous avons tous l'expérience des messageries instantanées MSN dans lesquelles les interlocuteurs disponibles apparaissent dans nos « buddy lists » dès qu'ils se connectent. Dans l'esprit Ajax, et XML en particulier, le projet ouvert Jabber est particulièrement intéressant. La Jabber Software Foundation a mis au point un protocole basé sur XML pour le développement de services de messagerie instantanée (au sens le plus large). Cette spécification, XMPP pour Extensible Messaging and Presence Protocol, vise à décrire les bases d'un protocole de communication en temps réel qui emploie des messages au format XML. Il y également une communauté active de développeurs travaillant à des extensions du protocole pour des applications spécifiques. Beaucoup de clients Jabber sont aujourd'hui disponibles, en versions Open Source et commerciales, implémentés dans différents langages de programmation, y compris JavaScript (par exemple, JSJaC). Il y a également des implémentations facilement accessibles de serveurs Jabber comme Jabberd, ejabberd et WildFire. L'intégration d'une librairie cliente Jabber en JavaScript à un programme Ajax permet, en liaison avec un serveur XMPP, de mettre en place, au prix certes d'un environnement un peu plus lourd et complexe du côté serveur, un véritable canal de communication bidirectionnel entre une page Web et des services Web. Dans cette architecture, on détourne la gestion de la présence fournie par le serveur Jabber pour envoyer, à l'initiative du service Web, des données à la page affichée par le navigateur. Ces données, enveloppées dans un message XMPP issu du serveur vers le navigateur, appellent au vol un script JavaScript dans la page qui récupère ainsi résultats et données pour affichage et présentation à l'utilisateur.
On peut également se passer de cette couche supplémentaire IM et simuler cette méthode de communication avec JavaScript et XMLHttpRequest seuls. Une première idée consiste à implémenter le service de façon à ce qu'il maintienne la connexion HTTP ouverte tant qu'il n'a pas fini de communiquer ses données à la page Web qui l'héberge. Chaque nouvelle donnée disponible sur le serveur est glissée dans un script JavaScript, qui, exécuté dans le navigateur client, va rafraîchir la page avec la nouvelle valeur et celle-là seulement. Le fragment de PHP suivant :
<div id="news"></div>
<?PHP
while( $n > 0 ){
?>
<script language="javascript">
$("#news").html( '<? echo getLatest(); ?>' );
</script>
<?PHP
ob_end_flush();
sleep( 1 );
}
?>
rajoute n copies du même script JavaScript, à la valeur de la donnée près (fournie par le résultat de l'appel getLatest(), dans l'exemple). Ces scripts modifient simplement le contenu de la balise « div » qui les précède. Vu de l'utilisateur, le contenu de la page change une fois par seconde, plus ou moins la latence, avec la succession des n valeurs distinctes. Il n'y a qu'un aller-retour HTTP et pas de rechargement de page. Cette forme de « page streaming » présente le double inconvénient de maintenir le navigateur en mode lecture tant que le service n'est pas terminé (la barre d'attente dans le bandeau inférieur du navigateur progresse donc lentement pendant le défilement des n valeurs des données) et la page Web elle-même s'allonge au fur et à mesure de l'accumulation des copies du même script successivement appelés avec des valeurs différentes. Si l'on songe à des pages Ajax même moyennement complexes qui contiennent une grande quantité de données variables, ces inconvénients peuvent rapidement tourner au blocage complet du client et du service.
Pour pallier ces difficultés, on peut songer à charger la page une fois pour toute en affichant la première valeur de la donnée appelée à varier par la suite. Ensuite, la page Web émet une requête XMLHttpRequest vers le serveur pour récupérer les nouvelles données. Cet appel est asynchrone et le script reprend la main juste après l'émission de la requête, pour lancer, via un « timer » une interrogation périodique de l'état de la requête. Une « astuce » dans l'implémentation de l'objet XMLHttpRequest permet de récupérer le contenu de la réponse avant qu'il ne soit complet. Le fameux champ reponseText est accessible et à jour dans l'intervalle de temps séparant l'émission de la requête de la réception de la réponse complète. Il suffit alors d'en extraire uniquement la dernière donnée pour reconstituer sur le poste client la file d'attente des données construite en parallèle sur le serveur. Illustrons :
1) du côté du serveur, notre service émet à intervalle régulier une balise XML « message » contenant la donnée réactualisée, en PHP :
$n = 50;
function getXMLData(){
global $n;
return '<message>'.$n .'</message>';
}
while( $n > 0 ){
sleep( 1 );
echo getXMLData();
ob_end_flush();
$n = $n - 1;
}
qui envoie la suite décroissante de nombres depuis 50.
2) du côté du client, le script charge la page et affiche la première valeur (50), émet une requête XMLHttpRequest qui se terminera lorsque notre code PHP aura construit ses 50 messages XML, puis immédiatement se met à demander périodiquement l'état de la réponse, en JavaScript :
var xhReq = createXMLHttpRequest();
window.onload = function() {
setInterval(pollLatestResponse, 250);
xhReq.open("GET", "service.php", true);
xhReq.onreadystatechange = function() {
if (xhReq.readyState==4)
{ /*On ignore la notification de fin d'exécution*/ }
}
xhReq.send(null);
}
dans lequel la fonction pollLatestResponse, appelées toutes les 250 ms, extrait la dernière balise « message » du champ responseText de la requête.
Vu de l'utilisateur, dans cette forme de « service streaming », la page affiche successivement la suite de valeurs de 50 à 1 comme si le serveur lui envoyait la nouvelle valeur au fur et à mesure de son exécution. En fait, dans un exemple réel il est fort probable que la connexion soit rompue d'autorité par le protocole HTTP après un timeout, puisque la page a été chargée d'emblée et en une fois au début. La synchronisation du timer dans les scripts Ajax et de l'exécution des services sur le serveur pose alors de vrais problèmes.
Ces solutions présentent toutes mérites et inconvénients. Aujourd'hui le temps est à la réflexion et au développement d'une authentique architecture de middleware par échange de messages pour Ajax. La Dojo Foundation, célèbre pour son « Ajax Toolkit » utilisé dans nombre d'applications Web 2.0, a lancé le projet cometd qui vise à fournir une librairie de communication à base de messages entre applications Web sous Ajax. Sur ce sujet, signalons encore la spécification Bayeux - un hommage à la tapisserie mais un curieux anachronisme qui verrait le héros, rempart des Achéens, fils de Telamon voisiner avec Guillaume le Conquérant, mais enfin, passons - dans laquelle les messages envoyés pour synchroniser client et serveur utilisent JSON. La spécification est en cours d'élaboration mais vise ambitieusement à donner à Ajax une base de communication par messages comparables aux produits comme MQSeries et Tibco. Une API de messagerie permettrait aux applications Ajax de passer les portes de l'informatique d'entreprise et donnerait probablement naissance à une nouvelle génération de services et d'applications Web interactives.
Le succès d'AJAX auprès des programmeurs d'applications Web est fulgurant. Il faut l'attribuer d'une part à la demande croissante d'interactivité dans le navigateur Web, conséquence du succès de sa diffusion comme frontal aux applications d'entreprise et aux services grand public, et, d'autre part, à la simplicité de l'implémentation. Toutes les versions modernes des navigateurs offrent en effet un interpréteur JavaScript, permettant d'exécuter des traitements programmés directement dans la page Web sur le navigateur du poste client, et, bien sûr, la fonction d'appel asynchrone de pages Web, écrites en général en XML - l'objet XMLHttpRequest.
Le principe de fonctionnement est assez simple. Lorsqu'un navigateur affiche une page Web, il construit une représentation interne de la page en mémoire sous forme d'un arbre dont les « feuilles » représentent les objets de base à afficher (texte, image, etc.) avec leurs attributs graphiques. Cet arbre en mémoire est formellement défini par une spécification du W3C, le DOM (Document Object Model), à laquelle se conforment les navigateurs Web. Cette spécification définit également une interface de programmation complète qui permet de modifier au vol cet arbre, et donc le document, à partir d'un langage de programmation, en particulier de Java et de JavaScript. (D'autres bibliothèques ont été depuis développées qui permettent également de travailler sur l'arbre DOM depuis d'autres langages comme C, C++, PHP, Python, etc.) Dans le cadre d'AJAX, l'API JavaScript est particulièrement intéressante dans la mesure où le navigateur lui-même contient un interpréteur ce qui autorise le développeur à mettre dans la même page Web le contenu et les programmes les modifiant en réponse aux actions des utilisateurs. D'un simple document la page Web est devenue un objet complexe, contenant programmes et données.
Voilà pour l'interface graphique interactive. Pour ce qui est de la communication avec les serveurs, le sésame s'appelle XMLHttpRequest. Il transforme la page Web en client dans une architecture client-serveur classique. Au travers d'un requête XMLHttpRequest qui est envoyée à un serveur, le script JavaScript en cours d'exécution depuis une page Web peut recevoir des données supplémentaires du serveur. Cette communication est asynchrone : le script est « réveillé » par l'arrivée des données lorsqu'elles ont été envoyées par le serveur ; la communication ne bloque donc pas l'utilisateur qui peut poursuivre les interactions pendant l'attente des résultats de la requête (ou d'un message d'erreur du serveur). La requête est transportée par le protocole HTTP, elle bénéficie donc des mêmes avantages et souffre des mêmes inconvénient que le protocole lui-même. En particulier, cette implémentation du mode de communication n'offre pas de notion de session : chaque requête est indépendante des autres.
En théorie, la réponse du serveur à une requête asynchrone XMLHttpRequest peut prendre des formats divers. Le texte complet de la réponse est renvoyé dans un champ particulier "responseText". Cependant, et dans l'esprit d'interopérabilité des services Web prôné dans l'architecture orientée service (SOA), il est habituel que la réponse à une telle requête soit un document XML. Pour en simplifier le traitement, un autre champ du résultat, "responseXML", contient les données directement sous forme d'arbre DOM qui peut alors être manipulé par la même API en JavaScript que nous avons mentionné plus haut.
Mais ce n'est pas, loin de là, la seule possibilité. On trouve par exemple de plus en plus des réponses constituées de données au format JSON. JSON est un format léger de transport de données sous forme d'une chaîne de caractères empruntant directement à la syntaxe JavaScript. Ainsi ce format n'a formellement pas à être « interprété » par un script qui le reçoit mais simplement « évalué ». Les données au format JSON occupent moins de place qu'un document XML dans le transport via HTTP et leur exploitation est immédiate du côté navigateur, qui n'a pas dans ce cas à utiliser d'interpréteur XML.
Ajax ne pourra atteindre un nouveau degré de maturité que lorsque la question de la communication avec les programmes et processus se déroulant sur les serveurs aura trouvé une réponse qui s'affranchisse des contraintes imposées par le mode « sans mémoire » de HTTP. Plus précisément, l'épineuse difficulté réside dans le moyen à trouver pour qu'un processus serveur, déclenché ou non par une requête XMLHttpRequest, puisse, à son initiative, communiquer des données au navigateur du poste client. Le protocole HTTP ayant été conçu pour transporter des requêtes et des données à l'initiative du client, il s'agit de réfléchir à une forme d'inversion du modèle de communication. C'est ce à quoi s'attellent aujourd'hui différents groupes de travail dans la communauté des développeurs Ajax.
En l'état, il existe des solutions techniques. D'abord signalons que le protocole HTTP prévoit déjà la possibilité de provoquer le rechargement périodique d'une page depuis le serveur. En utilisant une balise:
META HTTP-EQUIV="Refresh" CONTENT="n"
on indique au navigateur de recharger et réafficher toute la page en question toutes les « n » secondes. Le rafraîchissement périodique de toute la page ne fait cependant pas forcément l'affaire de scripts Ajax du côté client, qui peuvent n'être intéressés que par une partie des données qui y figurent, qui doivent conserver un état de l'interaction avec l'utilisateur à un instant donné (état qui serait perdu au rafraîchissement suivant), voire pour lesquels la périodicité d'un rafraîchissement est inutile ou incohérente.
D'autres solutions ont donc été recherchées pour inverser l'initiative de la communication. Une première repose sur l'utilisation des protocoles des serveurs de messagerie instantanée (IM). Dans ces serveurs, la gestion de la présence des interlocuteurs est à l'initiative du serveur lorsqu'un nouvel utilisateur se déclare prêt à recevoir les messages. Nous avons tous l'expérience des messageries instantanées MSN dans lesquelles les interlocuteurs disponibles apparaissent dans nos « buddy lists » dès qu'ils se connectent. Dans l'esprit Ajax, et XML en particulier, le projet ouvert Jabber est particulièrement intéressant. La Jabber Software Foundation a mis au point un protocole basé sur XML pour le développement de services de messagerie instantanée (au sens le plus large). Cette spécification, XMPP pour Extensible Messaging and Presence Protocol, vise à décrire les bases d'un protocole de communication en temps réel qui emploie des messages au format XML. Il y également une communauté active de développeurs travaillant à des extensions du protocole pour des applications spécifiques. Beaucoup de clients Jabber sont aujourd'hui disponibles, en versions Open Source et commerciales, implémentés dans différents langages de programmation, y compris JavaScript (par exemple, JSJaC). Il y a également des implémentations facilement accessibles de serveurs Jabber comme Jabberd, ejabberd et WildFire. L'intégration d'une librairie cliente Jabber en JavaScript à un programme Ajax permet, en liaison avec un serveur XMPP, de mettre en place, au prix certes d'un environnement un peu plus lourd et complexe du côté serveur, un véritable canal de communication bidirectionnel entre une page Web et des services Web. Dans cette architecture, on détourne la gestion de la présence fournie par le serveur Jabber pour envoyer, à l'initiative du service Web, des données à la page affichée par le navigateur. Ces données, enveloppées dans un message XMPP issu du serveur vers le navigateur, appellent au vol un script JavaScript dans la page qui récupère ainsi résultats et données pour affichage et présentation à l'utilisateur.
On peut également se passer de cette couche supplémentaire IM et simuler cette méthode de communication avec JavaScript et XMLHttpRequest seuls. Une première idée consiste à implémenter le service de façon à ce qu'il maintienne la connexion HTTP ouverte tant qu'il n'a pas fini de communiquer ses données à la page Web qui l'héberge. Chaque nouvelle donnée disponible sur le serveur est glissée dans un script JavaScript, qui, exécuté dans le navigateur client, va rafraîchir la page avec la nouvelle valeur et celle-là seulement. Le fragment de PHP suivant :
<div id="news"></div>
<?PHP
while( $n > 0 ){
?>
<script language="javascript">
$("#news").html( '<? echo getLatest(); ?>' );
</script>
<?PHP
ob_end_flush();
sleep( 1 );
}
?>
rajoute n copies du même script JavaScript, à la valeur de la donnée près (fournie par le résultat de l'appel getLatest(), dans l'exemple). Ces scripts modifient simplement le contenu de la balise « div » qui les précède. Vu de l'utilisateur, le contenu de la page change une fois par seconde, plus ou moins la latence, avec la succession des n valeurs distinctes. Il n'y a qu'un aller-retour HTTP et pas de rechargement de page. Cette forme de « page streaming » présente le double inconvénient de maintenir le navigateur en mode lecture tant que le service n'est pas terminé (la barre d'attente dans le bandeau inférieur du navigateur progresse donc lentement pendant le défilement des n valeurs des données) et la page Web elle-même s'allonge au fur et à mesure de l'accumulation des copies du même script successivement appelés avec des valeurs différentes. Si l'on songe à des pages Ajax même moyennement complexes qui contiennent une grande quantité de données variables, ces inconvénients peuvent rapidement tourner au blocage complet du client et du service.
Pour pallier ces difficultés, on peut songer à charger la page une fois pour toute en affichant la première valeur de la donnée appelée à varier par la suite. Ensuite, la page Web émet une requête XMLHttpRequest vers le serveur pour récupérer les nouvelles données. Cet appel est asynchrone et le script reprend la main juste après l'émission de la requête, pour lancer, via un « timer » une interrogation périodique de l'état de la requête. Une « astuce » dans l'implémentation de l'objet XMLHttpRequest permet de récupérer le contenu de la réponse avant qu'il ne soit complet. Le fameux champ reponseText est accessible et à jour dans l'intervalle de temps séparant l'émission de la requête de la réception de la réponse complète. Il suffit alors d'en extraire uniquement la dernière donnée pour reconstituer sur le poste client la file d'attente des données construite en parallèle sur le serveur. Illustrons :
1) du côté du serveur, notre service émet à intervalle régulier une balise XML « message » contenant la donnée réactualisée, en PHP :
$n = 50;
function getXMLData(){
global $n;
return '<message>'.$n .'</message>';
}
while( $n > 0 ){
sleep( 1 );
echo getXMLData();
ob_end_flush();
$n = $n - 1;
}
qui envoie la suite décroissante de nombres depuis 50.
2) du côté du client, le script charge la page et affiche la première valeur (50), émet une requête XMLHttpRequest qui se terminera lorsque notre code PHP aura construit ses 50 messages XML, puis immédiatement se met à demander périodiquement l'état de la réponse, en JavaScript :
var xhReq = createXMLHttpRequest();
window.onload = function() {
setInterval(pollLatestResponse, 250);
xhReq.open("GET", "service.php", true);
xhReq.onreadystatechange = function() {
if (xhReq.readyState==4)
{ /*On ignore la notification de fin d'exécution*/ }
}
xhReq.send(null);
}
dans lequel la fonction pollLatestResponse, appelées toutes les 250 ms, extrait la dernière balise « message » du champ responseText de la requête.
Vu de l'utilisateur, dans cette forme de « service streaming », la page affiche successivement la suite de valeurs de 50 à 1 comme si le serveur lui envoyait la nouvelle valeur au fur et à mesure de son exécution. En fait, dans un exemple réel il est fort probable que la connexion soit rompue d'autorité par le protocole HTTP après un timeout, puisque la page a été chargée d'emblée et en une fois au début. La synchronisation du timer dans les scripts Ajax et de l'exécution des services sur le serveur pose alors de vrais problèmes.
Ces solutions présentent toutes mérites et inconvénients. Aujourd'hui le temps est à la réflexion et au développement d'une authentique architecture de middleware par échange de messages pour Ajax. La Dojo Foundation, célèbre pour son « Ajax Toolkit » utilisé dans nombre d'applications Web 2.0, a lancé le projet cometd qui vise à fournir une librairie de communication à base de messages entre applications Web sous Ajax. Sur ce sujet, signalons encore la spécification Bayeux - un hommage à la tapisserie mais un curieux anachronisme qui verrait le héros, rempart des Achéens, fils de Telamon voisiner avec Guillaume le Conquérant, mais enfin, passons - dans laquelle les messages envoyés pour synchroniser client et serveur utilisent JSON. La spécification est en cours d'élaboration mais vise ambitieusement à donner à Ajax une base de communication par messages comparables aux produits comme MQSeries et Tibco. Une API de messagerie permettrait aux applications Ajax de passer les portes de l'informatique d'entreprise et donnerait probablement naissance à une nouvelle génération de services et d'applications Web interactives.
jeudi, octobre 12, 2006
Interopérabilité, la nouvelle question clé dans le débat Open Source contre propriétaire
Assisterait-on, comme dans les pré-(pré-pré-pré...)campagnes présidentielles qui font rage ici et là, à un changement progressif de sujet dans le débat autour de l'Open Source ? Jusqu'à maintenant les thèmes des inlassables discussions entre partisans du camp de l'Open Source et ceux des éditeurs professionnels, à vocation commerciale entendue comme signifiant propriétaire, se réduisaient finalement à trois questions : la fiabilité, la sécurité et le fameux coût total de possession.
Les logiciels Open Source sont ils plus ou moins fiables, plus ou moins sûrs et plus ou moins chers que les progiciels propriétaires et systèmes d'exploitation (Microsoft Windows en tête) concurrents ? Ce débat est souvent considéré comme un préliminaire indispensable à l'introduction disciplinée du libre dans les systèmes d'information des entreprises. Ce qui n'empêche pas certains acteurs, comme les grandes administrations en Europe, par exemple, de s'être déjà déclarés franchement en faveur de l'une ou l'autre approche. En France, « la modernisation de l'Etat », Adèle (Administration électronique - tout un programme ! -) est l'un des cris de ralliement de nos gouvernements successifs. Adèle se caractérise par un recours affiché, et même militant, au logiciel libre. Économie de coûts à qualité égale et contournement de la difficulté que représente la gestion des licences propriétaires ont été, de l'aveu même des DSI au Ministère de l'économie, les facteurs décisifs. D'autres, moins revendicatifs, considèrent que le débat n'est pas clos et qu'aucun des arguments jusqu'ici avancés n'est réellement concluant. Les confrontation des coûts de possession, pour reprendre l'un des axes classiques de cette discussion, entre l'approche Open Source et l'approche propriétaire reste compliquée sous ses aspects simplistes souvent seuls à être mis en avant. La vraie mesure, économique donc, du retour sur investissement et du coût de possession met en jeu bien plus qu'un seul choix de système d'exploitation : il faut prendre en compte les couches logicielles système, les applications informatiques elles-mêmes et les coûts de service et de maintenance associés tout au long du cycle de vie. « Get The Facts » a beau clamer la campagne publicitaire comparative de Microsoft, c'est justement ces faits qui sont difficiles à produire ou à clairement délimiter.
Or une nouvelle dimension semble bien apparaître, qui renouvelle les termes du débat non tranché sur l'argumentation fiabilité-sécurité-coût : celle de l'interopérabilité. Ce déplacement de l'oeil de l'ouragan peut s'expliquer par un double constat. Premièrement, l'absence de clair vainqueur dans la bataille d'idées propriétaire contre libre, sur le champ jalonné par les thèmes classiques, se double dans la pratique par des résultats mitigés dans le processus d'adoption des logiciels libres. Ainsi s'il est incontestable que Linux s'est construit une solide part de marché dans les systèmes d'exploitation pour serveurs, il n'en reste pas moins que le nombre de livraison de Linux embarqué avec les nouveaux PC reste loin derrière celui de Windows. À l'inverse, Apache règne en maître loin devant IIS de Microsoft pour ce qui est des serveurs Web. Pour les applications, les constatations varient avec le secteur : SugarCRM, dans le domaine de la relation client, ne semble pas progresser à un rythme inquiétant les acteurs propriétaires en place ; par contre, Asterisk, dans le secteur des PCBX, a rapidement pris une place prépondérante. Certains éditeurs font don à la communauté Open Source de pans entiers de propriété intellectuelle dans le domaine du logiciel. À l'opposé, on voit des sociétés commerciales comme JBoss, racheté par Red Hat, lui-même un distributeur commercial triomphant sur les marchés financiers, se faire les championnes d'une forme contrôlée du logiciel libre différant du « purisme » parfois revendiqué par l'Open Source.
Deuxièmement, l'importance croissante de l'infrastructure Web dans l'urbanisation des systèmes d'information et dans la mutation de l'architecture informatique des entreprises, petites ou grandes est aujourd'hui partout visible. Que ce soit sous les vocables de SaaS (Software as a Service), de SOA (Services Oriented Architecture), de Services Web ou d'autres encore, ce mouvement prend acte d'une hétérogénéité inévitable de l'environnement dans lequel les applications d'entreprises doivent aujourd'hui être développées, déployées et maintenues. Les progiciels commercialisés sous forme d'abonnement à un service, plutôt que sous licence exploitée sur des serveurs internes à l'entreprise, sont de plus en plus souvent hébergés sous Linux dans les datacenters des grands opérateurs. (D'autant plus si le choix matériel est celui d'IBM, qui a très tôt développé une offre Linux de produits et services d'entreprise.)
L'interopérabilité devient alors le facteur clé à prendre en considération dans un univers Web décentralisé, que les évolutions techniques récentes (RSS, Ajax, etc.) ne font d'ailleurs que renforcer. La question réside moins dans un choix exclusif de l'une ou l'autre solution sur la base fiabilité-sécurité-coût, que sur le meilleur processus d'intégration des deux. Intégration et interopérabilité sont à entendre au sens large : y participent autant des critères techniques que des critères économiques et juridiques. Deux points pour illustrer l'élargissement de la question de l'interopérabilité : la multiplication des licences Open Source et l'arrivée imminente de la version 3 de la GPL originelle a sérieusement complexifié et renchéri la barrière juridique pour les entreprises ou administrations souhaitant recourir au logiciel libre. La startup SpikeSource, fondée entre autres par Kim Polese, figure mythique des débuts de Java en 1995-96, vient de lever un second tour de $24m (après $12m en Série A auprès de Kleiner Perkins en mai 2005). SpikeSource certifie des « stacks » Open Source compatibles entre eux en termes de licences, de numéros de versions, d'API etc. ; elle vend aussi des stacks « verticaux » prêt à l'emploi (CRM, CMS et Business Intelligence). SpikeSource et d'autres répondent d'avance au besoin de vérification et d'assurance d'interopérabilité des services et des composants logiciels. Si la startup le propose aujourd'hui pour les seuls logiciels Open Source, on imagine aisément la formidable amplification du problème que représentera à brève échéance la prise en compte des logiciels et progiciels propriétaires.
Après avoir montré leurs forces et faiblesses dans un débat aux termes classiques, les deux modèles, propriétaire et Open Source, voient maintenant venir le temps du travail sur les questions d'interopérabilité. Les premiers signes de cette « entente cordiale » peuvent être décelés : souci, qui devrait être prioritaire, de l'interopérabilité entre offres Open Source elles-mêmes, mouvements d'ouverture de Microsoft vers ODF (mesurés certes mais exprimés néanmoins), etc. Là encore, on n'a pas fini de prendre la mesure du Web, le grand égalisateur.
Les logiciels Open Source sont ils plus ou moins fiables, plus ou moins sûrs et plus ou moins chers que les progiciels propriétaires et systèmes d'exploitation (Microsoft Windows en tête) concurrents ? Ce débat est souvent considéré comme un préliminaire indispensable à l'introduction disciplinée du libre dans les systèmes d'information des entreprises. Ce qui n'empêche pas certains acteurs, comme les grandes administrations en Europe, par exemple, de s'être déjà déclarés franchement en faveur de l'une ou l'autre approche. En France, « la modernisation de l'Etat », Adèle (Administration électronique - tout un programme ! -) est l'un des cris de ralliement de nos gouvernements successifs. Adèle se caractérise par un recours affiché, et même militant, au logiciel libre. Économie de coûts à qualité égale et contournement de la difficulté que représente la gestion des licences propriétaires ont été, de l'aveu même des DSI au Ministère de l'économie, les facteurs décisifs. D'autres, moins revendicatifs, considèrent que le débat n'est pas clos et qu'aucun des arguments jusqu'ici avancés n'est réellement concluant. Les confrontation des coûts de possession, pour reprendre l'un des axes classiques de cette discussion, entre l'approche Open Source et l'approche propriétaire reste compliquée sous ses aspects simplistes souvent seuls à être mis en avant. La vraie mesure, économique donc, du retour sur investissement et du coût de possession met en jeu bien plus qu'un seul choix de système d'exploitation : il faut prendre en compte les couches logicielles système, les applications informatiques elles-mêmes et les coûts de service et de maintenance associés tout au long du cycle de vie. « Get The Facts » a beau clamer la campagne publicitaire comparative de Microsoft, c'est justement ces faits qui sont difficiles à produire ou à clairement délimiter.
Or une nouvelle dimension semble bien apparaître, qui renouvelle les termes du débat non tranché sur l'argumentation fiabilité-sécurité-coût : celle de l'interopérabilité. Ce déplacement de l'oeil de l'ouragan peut s'expliquer par un double constat. Premièrement, l'absence de clair vainqueur dans la bataille d'idées propriétaire contre libre, sur le champ jalonné par les thèmes classiques, se double dans la pratique par des résultats mitigés dans le processus d'adoption des logiciels libres. Ainsi s'il est incontestable que Linux s'est construit une solide part de marché dans les systèmes d'exploitation pour serveurs, il n'en reste pas moins que le nombre de livraison de Linux embarqué avec les nouveaux PC reste loin derrière celui de Windows. À l'inverse, Apache règne en maître loin devant IIS de Microsoft pour ce qui est des serveurs Web. Pour les applications, les constatations varient avec le secteur : SugarCRM, dans le domaine de la relation client, ne semble pas progresser à un rythme inquiétant les acteurs propriétaires en place ; par contre, Asterisk, dans le secteur des PCBX, a rapidement pris une place prépondérante. Certains éditeurs font don à la communauté Open Source de pans entiers de propriété intellectuelle dans le domaine du logiciel. À l'opposé, on voit des sociétés commerciales comme JBoss, racheté par Red Hat, lui-même un distributeur commercial triomphant sur les marchés financiers, se faire les championnes d'une forme contrôlée du logiciel libre différant du « purisme » parfois revendiqué par l'Open Source.
Deuxièmement, l'importance croissante de l'infrastructure Web dans l'urbanisation des systèmes d'information et dans la mutation de l'architecture informatique des entreprises, petites ou grandes est aujourd'hui partout visible. Que ce soit sous les vocables de SaaS (Software as a Service), de SOA (Services Oriented Architecture), de Services Web ou d'autres encore, ce mouvement prend acte d'une hétérogénéité inévitable de l'environnement dans lequel les applications d'entreprises doivent aujourd'hui être développées, déployées et maintenues. Les progiciels commercialisés sous forme d'abonnement à un service, plutôt que sous licence exploitée sur des serveurs internes à l'entreprise, sont de plus en plus souvent hébergés sous Linux dans les datacenters des grands opérateurs. (D'autant plus si le choix matériel est celui d'IBM, qui a très tôt développé une offre Linux de produits et services d'entreprise.)
L'interopérabilité devient alors le facteur clé à prendre en considération dans un univers Web décentralisé, que les évolutions techniques récentes (RSS, Ajax, etc.) ne font d'ailleurs que renforcer. La question réside moins dans un choix exclusif de l'une ou l'autre solution sur la base fiabilité-sécurité-coût, que sur le meilleur processus d'intégration des deux. Intégration et interopérabilité sont à entendre au sens large : y participent autant des critères techniques que des critères économiques et juridiques. Deux points pour illustrer l'élargissement de la question de l'interopérabilité : la multiplication des licences Open Source et l'arrivée imminente de la version 3 de la GPL originelle a sérieusement complexifié et renchéri la barrière juridique pour les entreprises ou administrations souhaitant recourir au logiciel libre. La startup SpikeSource, fondée entre autres par Kim Polese, figure mythique des débuts de Java en 1995-96, vient de lever un second tour de $24m (après $12m en Série A auprès de Kleiner Perkins en mai 2005). SpikeSource certifie des « stacks » Open Source compatibles entre eux en termes de licences, de numéros de versions, d'API etc. ; elle vend aussi des stacks « verticaux » prêt à l'emploi (CRM, CMS et Business Intelligence). SpikeSource et d'autres répondent d'avance au besoin de vérification et d'assurance d'interopérabilité des services et des composants logiciels. Si la startup le propose aujourd'hui pour les seuls logiciels Open Source, on imagine aisément la formidable amplification du problème que représentera à brève échéance la prise en compte des logiciels et progiciels propriétaires.
Après avoir montré leurs forces et faiblesses dans un débat aux termes classiques, les deux modèles, propriétaire et Open Source, voient maintenant venir le temps du travail sur les questions d'interopérabilité. Les premiers signes de cette « entente cordiale » peuvent être décelés : souci, qui devrait être prioritaire, de l'interopérabilité entre offres Open Source elles-mêmes, mouvements d'ouverture de Microsoft vers ODF (mesurés certes mais exprimés néanmoins), etc. Là encore, on n'a pas fini de prendre la mesure du Web, le grand égalisateur.
vendredi, octobre 06, 2006
Le Complexe d'ICANN
La semaine dernière l'ICANN (Internet Corporation for Assigned Names and Numbers) la société, de droit privé mais sans but lucratif, dont la mission d'allouer les espaces d'adresses IP et de gérer les fameux TLD (top level domain) vient d'être renouvelée après de long débats internationaux sur qui contrôle ou non Internet, a publié une série de documents visant à clarifier ses relations avec le Département du Commerce américain.
Rappelons à grands traits les termes du débat. L'ICANN a été formée pour assurer cette mission critique à la stabilité et au fonctionnement d'Internet en 1998 sur une décision du Département du Commerce aux USA. Elle agit sous l'autorité d'un Board of Directors qui représente l'intérêt public, mondial en l'occurrence. Au plan commercial, son rôle a été critiqué fin 2003 dans une affaire l'ayant opposé à Verisign sur la gestion des DNS. L'ICANN avait enjoint Verisign de mettre hors ligne un service propriétaire de gestion de DNS et Verisign avait contre-attaqué en justice début 2004 pour abus d'autorité, remettant en cause l'étendue des droits d'intervention d'ICANN. Plus récemment, la question de l'inféodation éventuelle du Board of Directors au Département du Commerce s'est reposée, comme d'ailleurs à chaque élection de ses membres.
Dans les documents publiés le 26 septembre, dont le style administratif et juridique ne doit pas cacher l'importance au plan de l'évolution de la gouvernance de l'Internet, l'ICANN prend une certaine distance avec le DoC, gage de bonne volonté face aux critiques précédemment essuyées. L'ICANN n'est plus liée par les étapes imposées par le DoC, héritage de ses anciens statuts, et qui faisaient craindre une mainmise complète du gouvernement américain sur la gestion d'Internet. Mais comme, par ailleurs, l'ICANN n'est pas en situation de concurrence avec d'autres organismes internationaux, une solution que certains avaient poussé au dernier Sommet de l'information à Tunis, sa responsabilité vis-à-vis du public n'en est qu'encore plus grande.
Seconde nouveauté, l'ICANN fait auditer ses processus de décision et d'attribution des TLD (les extensions type .com, .fr, .mobi en particulier) par la London School of Economics. À la recherche de plus de transparence et de fiabilité, l'ICANN répond ainsi à un deuxième volet de critiques. Dans le rapport de la LSE (que l'on trouve à l'URL http://www.icann.org/announcements/gnso-review-report-sep06.pdf), 24 recommandations formelles montrent qu'il y a fort à faire sur ce plan à l'ICANN. La constitution de l'organisme votant les attributions et les classes différentes de votes y sont particulièrement mises en cause.
Il reste encore quelques problèmes épineux, en particulier autour de la protection des données privées qui, on le sait, font furieux débat aux USA et en Europe dans le contexte actuel. Pour l'ICANN la question porte sur quel volume d'information exiger puis publier sur les propriétaires d'un site Web : ce qu'on appelle communément la base de données WHOIS. C'est le même esprit que la confrontation venimeuse, et toujours non résolue, entre autorités américaines, européennes et les compagnies aériennes sur la soumission de données relatives aux passagers aériens avant les décollages. L'ancienne politique, à laquelle le DoC est vivement attaché, impose la publication d'un nom, d'un numéro de téléphone et d'une adresse pour un contact technique et pour un contact administratif, entendre responsable juridiquement. Les lobbies pour la protection des données privées tentent de réduire ces restrictions et exigent que la politique de l'ICANN se réduisent à la seule exigence d'un contact technique. L'enjeu est évidemment celui de l'identification des sites frauduleux et des poursuites judiciaires associées. On a vu, par exemple, pendant que l'ouragan Katrina dévastait la Louisiane des sites apparaître, se prétendant affiliés à la Croix rouge et tenter de recueillir des dons en ligne. La base WHOIS a permis de les détecter et les stopper très vite. De même les grands éditeurs comme Microsoft, Sony, Walt Disney Co., etc. défendent la politique actuelle qui leur permet de détecter et de poursuivre ceux qui enfreignent les lois sur le copyright et les marques commerciales. La question des limites au droit de protection de la vie privée s'immisce donc au coeur même de la politique de gestion d'Internet et du Web.
Dans quelques semaines, nous saurons dans quel camp a basculé l'ICANN. À l'heure où un Frank Quattrone de Crédit Suisse First Boston va en prison sur la base de courriers électroniques interceptés, ou bien que Patricia Dunn de HP et Mark Foley du Congrès américain sont trahis par les archives de leurs conversations sur messagerie instantanée, à quel régime de gouvernance du Web devons nous nous attendre ?
Rappelons à grands traits les termes du débat. L'ICANN a été formée pour assurer cette mission critique à la stabilité et au fonctionnement d'Internet en 1998 sur une décision du Département du Commerce aux USA. Elle agit sous l'autorité d'un Board of Directors qui représente l'intérêt public, mondial en l'occurrence. Au plan commercial, son rôle a été critiqué fin 2003 dans une affaire l'ayant opposé à Verisign sur la gestion des DNS. L'ICANN avait enjoint Verisign de mettre hors ligne un service propriétaire de gestion de DNS et Verisign avait contre-attaqué en justice début 2004 pour abus d'autorité, remettant en cause l'étendue des droits d'intervention d'ICANN. Plus récemment, la question de l'inféodation éventuelle du Board of Directors au Département du Commerce s'est reposée, comme d'ailleurs à chaque élection de ses membres.
Dans les documents publiés le 26 septembre, dont le style administratif et juridique ne doit pas cacher l'importance au plan de l'évolution de la gouvernance de l'Internet, l'ICANN prend une certaine distance avec le DoC, gage de bonne volonté face aux critiques précédemment essuyées. L'ICANN n'est plus liée par les étapes imposées par le DoC, héritage de ses anciens statuts, et qui faisaient craindre une mainmise complète du gouvernement américain sur la gestion d'Internet. Mais comme, par ailleurs, l'ICANN n'est pas en situation de concurrence avec d'autres organismes internationaux, une solution que certains avaient poussé au dernier Sommet de l'information à Tunis, sa responsabilité vis-à-vis du public n'en est qu'encore plus grande.
Seconde nouveauté, l'ICANN fait auditer ses processus de décision et d'attribution des TLD (les extensions type .com, .fr, .mobi en particulier) par la London School of Economics. À la recherche de plus de transparence et de fiabilité, l'ICANN répond ainsi à un deuxième volet de critiques. Dans le rapport de la LSE (que l'on trouve à l'URL http://www.icann.org/announcements/gnso-review-report-sep06.pdf), 24 recommandations formelles montrent qu'il y a fort à faire sur ce plan à l'ICANN. La constitution de l'organisme votant les attributions et les classes différentes de votes y sont particulièrement mises en cause.
Il reste encore quelques problèmes épineux, en particulier autour de la protection des données privées qui, on le sait, font furieux débat aux USA et en Europe dans le contexte actuel. Pour l'ICANN la question porte sur quel volume d'information exiger puis publier sur les propriétaires d'un site Web : ce qu'on appelle communément la base de données WHOIS. C'est le même esprit que la confrontation venimeuse, et toujours non résolue, entre autorités américaines, européennes et les compagnies aériennes sur la soumission de données relatives aux passagers aériens avant les décollages. L'ancienne politique, à laquelle le DoC est vivement attaché, impose la publication d'un nom, d'un numéro de téléphone et d'une adresse pour un contact technique et pour un contact administratif, entendre responsable juridiquement. Les lobbies pour la protection des données privées tentent de réduire ces restrictions et exigent que la politique de l'ICANN se réduisent à la seule exigence d'un contact technique. L'enjeu est évidemment celui de l'identification des sites frauduleux et des poursuites judiciaires associées. On a vu, par exemple, pendant que l'ouragan Katrina dévastait la Louisiane des sites apparaître, se prétendant affiliés à la Croix rouge et tenter de recueillir des dons en ligne. La base WHOIS a permis de les détecter et les stopper très vite. De même les grands éditeurs comme Microsoft, Sony, Walt Disney Co., etc. défendent la politique actuelle qui leur permet de détecter et de poursuivre ceux qui enfreignent les lois sur le copyright et les marques commerciales. La question des limites au droit de protection de la vie privée s'immisce donc au coeur même de la politique de gestion d'Internet et du Web.
Dans quelques semaines, nous saurons dans quel camp a basculé l'ICANN. À l'heure où un Frank Quattrone de Crédit Suisse First Boston va en prison sur la base de courriers électroniques interceptés, ou bien que Patricia Dunn de HP et Mark Foley du Congrès américain sont trahis par les archives de leurs conversations sur messagerie instantanée, à quel régime de gouvernance du Web devons nous nous attendre ?
vendredi, septembre 29, 2006
Quelles voies alternatives aux menaces du brevet logiciel ?
Andrew White, analyste au Gartner Group, tire la sonnette d'alarme. Selon lui, la généralisation de la Service Oriented Architecture (SOA) pourrait donner lieu à une recrudescence de procès en brevets, copyright et propriété intellectuelle. La SOA s'appuie en effet sur une plus large, et souvent plus profonde, exposition des services métier qui étaient auparavant intégrés dans des applications informatiques spécifiques et monolithiques. Le réflexe naturel des grands éditeurs devant la menace d'une application SOA composite qui reproduirait de trop près la fonctionnalité de leur progiciel propriétaire pourrait être de lancer des hordes d'avocats en propriété actuelle à la défense des brevets logiciels qu'ils assureraient être bafoués. Cette évolution vers une meilleure définition des fonctions est au coeur de la SOA ; elle est même formalisée par des langages dérivés de XML qui les décrivent en détail (WSDL, lié à SOAP). Elle conduit à l'abstraction progressive de ces fonctions dans la « plate-forme » SOA de même que des fonction originellement de haut niveau se coulent progressivement dans les systèmes d'exploitation (sécurité et intégrité des données, middleware et connectivité, virtualisation aujourd'hui). Pour répondre à ce nouveau défi, une tactique éprouvée des grands éditeurs, qui en ont les moyens, est de faire le plein de brevets logiciels comme munitions dans la bataille positionnelle qui s'annonce pour la défense de leurs parts de marché.
Et cette bataille est d'autant plus difficile que sur son flanc arrière l'armée des éditeurs commerciaux de logiciels est sérieusement à la lutte avec les tenants et les champions de l'Open Source. Le thème des brevets logiciels a fait et continue de faire, on va le voir, l'objet d'intenses débats en Europe à l'occasion de la valse-hésitation de l'adoption des nouvelles directives par la Commission européenne. En juillet 2005, au soulagement de la communauté Open Source, elle avait voté contre les brevets logiciels après de nombreux retournements et coups de théâtre. Par contre, il apparaît que l'Office européen des brevets (OEB) a néanmoins poursuivi l'attribution de brevets logiciels qui, du coup, se trouvent systématiquement dénoncés en justice. À une question écrite sur ce comportement jugé abusif directement posée à la Commission européenne, elle a répondu en se défaussant, préférant rappeler que l'OEB n'est pas un organe de la Communauté et reste dès lors souverain. Plus insidieux encore, s'ouvre en octobre le débat sur European Patent Litigation Agreement (EPLA), un accord sur le règlement des litiges en matière de brevet européen. Aux termes de l'EPLA, les juges des chambres de recours techniques de l'OEB pourraient être amenés à siéger aux Cours européennes de justice. Les mêmes experts techniques de l'OEB, qui auraient accordé une brevetabilité à une invention logicielle, seraient alors juges de la validité de cette attribution à la Cour de justice où ces mêmes brevets sont systématiquement dénoncés : juge et partie ! La situation est pour le moins confuse.
Dans le même temps, Microsoft, rendu prudent par des années de pratique du contentieux devant les tribunaux de toutes sortes, annonce des délais probables dans la livraison de Vista, la prochaine version de Windows, en Europe. Le géant de Redmond craint en effet une énième investigation de la Commission européenne au titre de la réglementation antitrust. De l'autre côté de l'Atlantique, l'office américain des brevets (USPTO) erre dans l'excès inverse semble-t-il. 2006 s'annonce comme sa « meilleure » année en nombre de brevets logiciels accordés, plus de 30.232 au 20 septembre dernier et une estimation de 40.000 pour toute l'année : un record. Comme le dépôt et l'examen du « prior art » ne sont évidemment pas gratuits, on imagine aisément comment la tactique d'accumulation des portefeuilles de brevets des grands éditeurs s'aligne aussi sur les intérêts bien compris de l'USPTO. Et donc tous s'en servent. Derniers exemples en date : i2, l'éditeur de progiciels de logistique, attaque SAP sur des techniques de modélisation et d'optimisation de la chaîne logistique (qu'aucun des deux éditeurs n'a d'ailleurs inventé mais dont ils proposent des implémentations concurrentes) ; ou encore Research in Motion, le fabricant canadien du fameux Blackberry, qui vient de transiger pour $612.5m avec NTP, un « patent troll » c'est-à-dire une société holding dont l'objet est uniquement de détenir des brevets pour ensuite attaquer en violation de propriété intellectuelle les grandes sociétés dont certains produits peuvent reposer sur ces techniques logiciel (pour lesquelles aucun brevet n'aurait du être accordé pour commencer).
Afin de désamorcer cet effet pervers du système, on voit depuis peu les grands acteurs de l'industrie du logiciel, qui d'un côté gonflent leur portefeuille de brevets, en relâcher de l'autre la pression croissante en livrant des pans entiers à la communauté Open Source. Ils font ainsi d'une pierre deux coups : ils prêtent moins le flanc aux attaques éventuelles des patents trolls en se débarrassant de certains brevets (jugés peu utiles ou susceptibles de poursuites) et ils donnent des gages de bonne conduite à la communauté Open Source, bien positionnée aujourd'hui pour éroder leur position dominante sur certains marchés. Ainsi IBM a fait une « donation » de plus de 500 brevets à la communauté Open Source en 2005. Microsoft, lui même, près avoir annoncé, en juillet dernier, vouloir assurer l'interopérabilité entre les formats d'échange de documents Open XML et ODF, a dévoilé mercredi 13 septembre son initiative « Open Specification Promise », pour la SOA et les services Web. L'OSP offre la possibilité à ceux, particuliers et entreprises, qui utilisent des logiciels commerciaux ou open source d'utiliser des brevets Microsoft pour mettre en oeuvre, gratuitement, 35 spécifications de services Web élaborées par l'éditeur et ses partenaires. Triple réponse donc de Microsoft : on peut accéder à ses technologies bien sûr par les licences commerciales (brevets, code source, protocoles, accords sur la propriété intellectuelle), mais aussi par les licences communautaires (projets sous licence Shared Source sur SourceForge, GotDotNet, Codeplex, etc.) ou encore via l'Open Specification Promise.
Il en est même une quatrième toute récente au premier exercice de laquelle j'ai eu l'honneur d'être invité à Cambridge, à deux pas du vénérable King's College noyé dans la verdure des berges de la rivière Cam, au laboratoire de Microsoft Research en Europe. Organisé par Microsoft IP Ventures, une toute nouvelle division de l'éditeur, le séminaire était consacré à la présentation d'un panel de nouvelles technologies dévelopées par Microsoft Research que l'éditeur cherche à essaimer hors de ses laboratoires. Microsoft IP Ventures, qui agit comme une agence interne de valorisation de l'innovation, cherche ainsi à réunir équipes entrepreneuriales, investisseurs et spécialistes de marketing autour de technologies mûries dans ses labos. Les accords sont discutés au cas par cas avec des licences d'exploitation exclusives ou non exclusives et des conditions financières variant d'une indépendance totale à une prise éventuelle de participation au capital des startup essaimées. Le jour même du séminaire Wallop, une jeune pousse américaine parmi les premières bénéficiaires de ce système, mettait en ligne son site offrant des services comparables à MySpace mais sans le modèle publicitaire qui fait aujourd'hui l'admiration béate des observateurs. Skinkers, européenne quant à elle, qui a récupéré des travaux de Microsoft Research sur les middleware de messagerie instantanée, était également présente pour témoigner du coup d'accélérateur que représentait cet adoubement de Microsoft pour une très jeune société.
Face à la menace d'engorgement du système actuel de protection et de diffusion de la propriété intellectuelle logiciel qui est confronté à la montée en puissance des nouvelles architectures et des nouveaux usages liés au Web, les solutions créatives des acteurs de l'industrie se multiplient.
Et cette bataille est d'autant plus difficile que sur son flanc arrière l'armée des éditeurs commerciaux de logiciels est sérieusement à la lutte avec les tenants et les champions de l'Open Source. Le thème des brevets logiciels a fait et continue de faire, on va le voir, l'objet d'intenses débats en Europe à l'occasion de la valse-hésitation de l'adoption des nouvelles directives par la Commission européenne. En juillet 2005, au soulagement de la communauté Open Source, elle avait voté contre les brevets logiciels après de nombreux retournements et coups de théâtre. Par contre, il apparaît que l'Office européen des brevets (OEB) a néanmoins poursuivi l'attribution de brevets logiciels qui, du coup, se trouvent systématiquement dénoncés en justice. À une question écrite sur ce comportement jugé abusif directement posée à la Commission européenne, elle a répondu en se défaussant, préférant rappeler que l'OEB n'est pas un organe de la Communauté et reste dès lors souverain. Plus insidieux encore, s'ouvre en octobre le débat sur European Patent Litigation Agreement (EPLA), un accord sur le règlement des litiges en matière de brevet européen. Aux termes de l'EPLA, les juges des chambres de recours techniques de l'OEB pourraient être amenés à siéger aux Cours européennes de justice. Les mêmes experts techniques de l'OEB, qui auraient accordé une brevetabilité à une invention logicielle, seraient alors juges de la validité de cette attribution à la Cour de justice où ces mêmes brevets sont systématiquement dénoncés : juge et partie ! La situation est pour le moins confuse.
Dans le même temps, Microsoft, rendu prudent par des années de pratique du contentieux devant les tribunaux de toutes sortes, annonce des délais probables dans la livraison de Vista, la prochaine version de Windows, en Europe. Le géant de Redmond craint en effet une énième investigation de la Commission européenne au titre de la réglementation antitrust. De l'autre côté de l'Atlantique, l'office américain des brevets (USPTO) erre dans l'excès inverse semble-t-il. 2006 s'annonce comme sa « meilleure » année en nombre de brevets logiciels accordés, plus de 30.232 au 20 septembre dernier et une estimation de 40.000 pour toute l'année : un record. Comme le dépôt et l'examen du « prior art » ne sont évidemment pas gratuits, on imagine aisément comment la tactique d'accumulation des portefeuilles de brevets des grands éditeurs s'aligne aussi sur les intérêts bien compris de l'USPTO. Et donc tous s'en servent. Derniers exemples en date : i2, l'éditeur de progiciels de logistique, attaque SAP sur des techniques de modélisation et d'optimisation de la chaîne logistique (qu'aucun des deux éditeurs n'a d'ailleurs inventé mais dont ils proposent des implémentations concurrentes) ; ou encore Research in Motion, le fabricant canadien du fameux Blackberry, qui vient de transiger pour $612.5m avec NTP, un « patent troll » c'est-à-dire une société holding dont l'objet est uniquement de détenir des brevets pour ensuite attaquer en violation de propriété intellectuelle les grandes sociétés dont certains produits peuvent reposer sur ces techniques logiciel (pour lesquelles aucun brevet n'aurait du être accordé pour commencer).
Afin de désamorcer cet effet pervers du système, on voit depuis peu les grands acteurs de l'industrie du logiciel, qui d'un côté gonflent leur portefeuille de brevets, en relâcher de l'autre la pression croissante en livrant des pans entiers à la communauté Open Source. Ils font ainsi d'une pierre deux coups : ils prêtent moins le flanc aux attaques éventuelles des patents trolls en se débarrassant de certains brevets (jugés peu utiles ou susceptibles de poursuites) et ils donnent des gages de bonne conduite à la communauté Open Source, bien positionnée aujourd'hui pour éroder leur position dominante sur certains marchés. Ainsi IBM a fait une « donation » de plus de 500 brevets à la communauté Open Source en 2005. Microsoft, lui même, près avoir annoncé, en juillet dernier, vouloir assurer l'interopérabilité entre les formats d'échange de documents Open XML et ODF, a dévoilé mercredi 13 septembre son initiative « Open Specification Promise », pour la SOA et les services Web. L'OSP offre la possibilité à ceux, particuliers et entreprises, qui utilisent des logiciels commerciaux ou open source d'utiliser des brevets Microsoft pour mettre en oeuvre, gratuitement, 35 spécifications de services Web élaborées par l'éditeur et ses partenaires. Triple réponse donc de Microsoft : on peut accéder à ses technologies bien sûr par les licences commerciales (brevets, code source, protocoles, accords sur la propriété intellectuelle), mais aussi par les licences communautaires (projets sous licence Shared Source sur SourceForge, GotDotNet, Codeplex, etc.) ou encore via l'Open Specification Promise.
Il en est même une quatrième toute récente au premier exercice de laquelle j'ai eu l'honneur d'être invité à Cambridge, à deux pas du vénérable King's College noyé dans la verdure des berges de la rivière Cam, au laboratoire de Microsoft Research en Europe. Organisé par Microsoft IP Ventures, une toute nouvelle division de l'éditeur, le séminaire était consacré à la présentation d'un panel de nouvelles technologies dévelopées par Microsoft Research que l'éditeur cherche à essaimer hors de ses laboratoires. Microsoft IP Ventures, qui agit comme une agence interne de valorisation de l'innovation, cherche ainsi à réunir équipes entrepreneuriales, investisseurs et spécialistes de marketing autour de technologies mûries dans ses labos. Les accords sont discutés au cas par cas avec des licences d'exploitation exclusives ou non exclusives et des conditions financières variant d'une indépendance totale à une prise éventuelle de participation au capital des startup essaimées. Le jour même du séminaire Wallop, une jeune pousse américaine parmi les premières bénéficiaires de ce système, mettait en ligne son site offrant des services comparables à MySpace mais sans le modèle publicitaire qui fait aujourd'hui l'admiration béate des observateurs. Skinkers, européenne quant à elle, qui a récupéré des travaux de Microsoft Research sur les middleware de messagerie instantanée, était également présente pour témoigner du coup d'accélérateur que représentait cet adoubement de Microsoft pour une très jeune société.
Face à la menace d'engorgement du système actuel de protection et de diffusion de la propriété intellectuelle logiciel qui est confronté à la montée en puissance des nouvelles architectures et des nouveaux usages liés au Web, les solutions créatives des acteurs de l'industrie se multiplient.
mardi, septembre 19, 2006
La France de l'innovation : 11 secteur protégés, 67 pôles de compétitivité et 83 technologies clés.
Le Ministère en charge de l'industrie, au sein du Ministère de l'Economie, des Finances et de l'Industrie, vient de ressortir de ses tiroirs le document « Cartographie des compétences relatives aux technologies clés 2010 » par lequel il décrète que 83 technologies pas une de plus, pas une de moins sont qualifiées de « clés » pour la France de 2010. Lancé en novembre 2004 (voir le site http://www.tc-2010.fr/), le projet a abouti, après de nombreuses réunions d'experts et de « spécialistes de la DGE » (entendre la Direction générale des entreprises au MINEFI), à cet inventaire dont il est précisé dans le cahier des charges initial qu'il doit impérativement faire l'objet d'une « présentation ergonomique, compréhensible par un public non spécialiste en 5 exemplaires papier ». On est rassuré.
Ce recensement des technologies est « destiné à aider les décideurs territoriaux à construire une une stratégie de développement technologie à partir des technologies jugées essentielles pour la compétitivité et l'attractivité de la France à l'horizon 2010 ». Laissons de côté la tentation « déclinologue » et passons outre l'admonition récente de Daniel Bouton dans un grand quotidien du soir qui rappelle que sans union en Europe, le PIB de la France à la même époque ne sera au mieux qu'un peu inférieur à celui d'une province chinoise, et considérons un instant cette liste pour ce qu'elle est : la production d'un collège d'experts, d'industriels et de chercheurs interrogés par la puissance publique dans des groupes de travail thématiques organisés par le Ministère.
Qu'y trouve-t-on ? Avant tout, et par construction même de l'étude, un ratissage très large des grands secteurs d'innovation et d'investissement actuel : n°5, par exemple, outils et méthodes pour le développement de système d'information. À priori, tout le secteur industriel des SSII tombe peu ou prou sous cette rubrique. Plus bas, n°15, modélisation, simulation et calcul ; n°7, composants logiciels ; n°2, stockage de l'information numérique. On vient de rajouter à peu près 60 % du NASDAQ. Mais lisons encore : n°25, textiles techniques et fonctionnels ; n°29, gestion de l'eau dans le bâtiment ; n°32, système éoliens avec stockage intégrés ; n°21, biotechnologies industrielles ; n°77, micro et nanocomposants. Ici, il me semble déceler une forte composante « aménagement du territoire » et satisfaction des demandes d'édiles régionaux. Ailleurs : n°34, réacteur nucléaires de troisième génération, à mettre en regard du n°53, alimentation pour le bien-être et la santé. Mais il est vrai que le n°43, traitement des odeurs non confinées ou le n°41, traitement automatique des déchets, voisine bien avec les N°27 et 33, matériaux composite pour la construction (toujours le BTP !) à base de biomasse, et carburants de synthèse issus de la biomasse. Puisqu'on parle de carburants, la sacro-sainte voiture n'est pas oubliée : n°58, infrastructures routières intelligentes (et celles que l'on a maintenant, que sont-elles donc ?), n°59, sécurité active des véhicules, n°64, acoustique des véhicules, n°65 et 66, architectures électrique et électronique des véhicules, n°67, gestion de l'énergie à bords des véhicules - bref plus de 14 technologies clés ! Pour survivre à ces technologies là, d'autres technologies : du n°44, transgénèse, et n° 45, thérapie cellulaire au n°52, vaccins recombinants seront également « clés » en 2010. Difficile de résister à conclure sur trois technologies clés pour la France de 2010 qui laissent, au moins dans leur énoncé, assez perplexe : n°83, transfert de technologie ; n°57, travaux d'infrastructure furtifs et n°62, moteurs à pistons.
Les plus chafouins se demanderont comment faire le lien entre ces 83 technologies clés et les 67 récents pôles de compétitivité que la caravane itinérante du Ministère en charge de l'Industrie ne cesse de vanter (pour Paris-Île de France, tréteaux et estrades seront installés à Bercy, le 26 septembre dès 8h30). D'érudits occultistes, certainement versés dans l'herméneutique et l'exégèse de la prose administrative ont cru relever que 8 des 83 technologies clés ne figurent pas dans celles attribuées aux 67 pôles. Des hermétistes pencheraient pour 13. Avec les 11 secteurs économiques protégés, décrétés par Dominique de Villepin il y a exactement un an puis passés au Journal Officiel en décembre dernier, le seul lien entre ces recensions tenant lieu de réflexion me semble être le nombre premier de leurs objets. Je prédis donc à brève échéance la liste des 107 domaines d'intérêt national...
Pris en tenaille entre les souhaits intéressés des collectivités locales et des administrations régionales, d'une part, et la véritable tétanisation française à propos de la « mondialisation », qui voit le sujet de l'attractivité de la France devenir progressivement un objet législatif et juridique sous l'autorité de l'Etat (comme on a inscrit naguère le « principe de précaution » dans la Constitution), il est facile de faire apparaître en transparence dans ce récolement des techniques traditionnelles de nos terroirs, certes sous leurs habits neufs de la technologie, le « mal-être » de toute une population scientifique et technique à la fois en perte de considération de la part du grand public et de moins en moins en prise avec le lien entre modernités technologique et économique. Qui a inventé le mécanisme magnétique des têtes de lecture que l'on trouve dans les milliers de disques durs qui peuplent notre vie courante ? Quel joueur, n°10, de l'équipe de France de football a terminé sa carrière professionnelle sur un coup (de boule) d'éclat lors de la finale 2006 de la Coupe de monde de football ? (Interdiction d'utiliser Google !) Pour être cynique, on pourrait compléter la première question de l'indication suivante : et dont l'exploitation commerciale n'a évidemment pas fait la fortune de son inventeur mais bien celle des géants américains et asiatiques de HP à Dell, d'IBM à Fujitsu, d'Acer à Apple. Il vaut mieux être joueur de football que scientifique !
La confusion règne dans les esprits.
Le 15 juin dernier, l'INSEE, dont on ne saurait évidemment mettre en doute la neutralité, sortait un dossier « Innovation et niveau technologiques des entreprises industrielles françaises » (lire http://medias.lemonde.fr/mmpub/edt/doc/20060615/783679_inseeinnovation.pdf) dans les Comptes et dossiers 2006, Rapport sur les comptes de la Nation 2005. La Nation donc, selon le dossier, se trouve à la croisée des chemins. « L’économie française était dans l’après-guerre une économie « de rattrapage », dont les gains de productivité étaient fondés sur l’imitation des technologies issues des pays « leaders » (les États-Unis). Elle aurait aujourd’hui rejoint cette frontière technologique mondiale. Ayant épuisé le précédent gisement de gains de productivité, il lui faut maintenant innover pour continuer à croître. » Bilan mitigé pour la Nation : les entreprises innovantes sont le moteur le plus régulier de la croissance mais la capacité à breveter est insuffisante. Conclusions prudentes et éludant les sujets de fâcherie : « D’une part, l’intensité des activités de R&D et le niveau technologique général semblent être des facteurs cruciaux pour innover. D’autre part, les entreprises innovantes semblent être à l’origine d’une part importante de la croissance sur la période récente, et surtout en être devenues l’un des moteurs les plus stables. Ces entreprises innovantes, « de pointe », jouent bien le rôle que l’on attend d’elles dans un régime de croissance fondé sur le savoir et la compétitivité hors prix. Mais la contribution de ce moteur resterait néanmoins en deçà des pays les plus performants et le positionnement de la France à la frontière technologique resterait donc fragile, fragilité dont témoignerait également le fléchissement des dépenses de R&D ».
Début septembre, alors que la Nation, en vacances et aux abonnés absents depuis mi-juin, se remettait lentement des torpeurs caniculaires et estivales en calculant les RTT d'ici à l'élection présidentielle, Forrester Research - sortant de son domaine de prédilection habituel - publiait un rapport d'un ton bien différent du précédent, mettant au contraire en avant les capacités et les modèles d'innovation en France, pour une fois cités en exemple. Un hapax !
Navi Radjou, VP du groupe américain, n'hésitait pas à titrer : A French Revolution in Innovation is Unfolding (http://www.forrester.com/Research/Document/Excerpt/0,7211,40105,00.html). (Juste une note lexicographique, pour nos amis américains il y a peu de substantifs que l'on peut accoler, sans déchoir, à l'adjectif « french » : « kiss », « fries », « toast », « letter », « leave » qui est plutôt anglais, « bean » et bien sûr « Revolution » ce qui donne une nouvelle idée de l'attractivité de la France.) M. Radjou a interrogé LASER, Renault-Nissan, Air Liquide, France Telecom, Société Générale, CNP Assurances, Banque de France, L'ATelier (à BNP Paribas) et Ilog. Curieusement, toujours au plan de l'attractivité de la France bien sûr, parce que France Telecom a placé 9 de ses 17 centres de recherche et développement hors de France, l'analyste de Forrester salue la capacité de l'opérateur à puiser dans les viviers de compétences hors de ses frontières. On frise le politiquement incorrect. Dans le même esprit, il souligne l'importance de structures comme l'Atelier de BNP Paribas ou Laser auprès du groupe Galeries Lafayette pour d'abord anticiper et diffuser les bonnes pratiques en matière d'innovation, et plancher ensuite sur les usages qui peuvent en découler. D'ailleurs, selon une enquête menée cette année par IBM au niveau mondial auprès de 765 PDG de grands comptes (Global CEO Study 2006), ceux-ci se reposent en priorité sur leurs salariés pour apporter des innovations. Les départements R&D, eux, n'obtiennent que la huitième place. C'est donc en se tournant vers elles-mêmes que les entreprises trouveraient les ressources de leur développement à venir. Tous ne jugent pas l'entreprise France capable d'y parvenir. Ainsi l'Insead et le World Economic Forum de Davos placent-ils notre pays en vingt-deuxième position, avant l'Estonie et la Malaisie, dans le palmarès (Global Information Technology Report 2006) des nations et des communautés à même de participer et de bénéficier des développements des technologies de l'information. Sans parler du classement académique des universités mondiales par l'université Jiao Tong de Shanghai, bien connu maintenant, dans lequel le premier français, Paris VI, arrive en quarante-cinquième place (45 n'est pas premier, c'est 3*3*5).
Alors on ne sait plus qui croire. Sur le site de Forrester Research, on note quand même dans la biographie de M. Radjou : « Navi holds undergraduate degrees in computer science from the University of Paris and CNAM-Paris and an M.S. in information systems from Ecole Centrale Paris. Navi also attended the Yale School of Management ». Au moins n'a-t-il pas « used all his french » (autre curiosité lexicographique que je laisse à la sagacité du lecteur) dans la rédaction du rapport et lui a-t-il donné une touche optimiste qui tranche avec le discours ambiant.
Il n'en fallait pas plus pour se sentir pousser des ailes. L'Ambassade de France aux États-Unis a lancé un vaste programme de recrutement de jeunes entrepreneurs américains (http://www.france-science.org/innovation/yei/home.html) les incitant à créer et développer leur entreprise en France. Bien sûr, mais pourquoi n'y a-t-on pas pensé plus tôt !
Ce recensement des technologies est « destiné à aider les décideurs territoriaux à construire une une stratégie de développement technologie à partir des technologies jugées essentielles pour la compétitivité et l'attractivité de la France à l'horizon 2010 ». Laissons de côté la tentation « déclinologue » et passons outre l'admonition récente de Daniel Bouton dans un grand quotidien du soir qui rappelle que sans union en Europe, le PIB de la France à la même époque ne sera au mieux qu'un peu inférieur à celui d'une province chinoise, et considérons un instant cette liste pour ce qu'elle est : la production d'un collège d'experts, d'industriels et de chercheurs interrogés par la puissance publique dans des groupes de travail thématiques organisés par le Ministère.
Qu'y trouve-t-on ? Avant tout, et par construction même de l'étude, un ratissage très large des grands secteurs d'innovation et d'investissement actuel : n°5, par exemple, outils et méthodes pour le développement de système d'information. À priori, tout le secteur industriel des SSII tombe peu ou prou sous cette rubrique. Plus bas, n°15, modélisation, simulation et calcul ; n°7, composants logiciels ; n°2, stockage de l'information numérique. On vient de rajouter à peu près 60 % du NASDAQ. Mais lisons encore : n°25, textiles techniques et fonctionnels ; n°29, gestion de l'eau dans le bâtiment ; n°32, système éoliens avec stockage intégrés ; n°21, biotechnologies industrielles ; n°77, micro et nanocomposants. Ici, il me semble déceler une forte composante « aménagement du territoire » et satisfaction des demandes d'édiles régionaux. Ailleurs : n°34, réacteur nucléaires de troisième génération, à mettre en regard du n°53, alimentation pour le bien-être et la santé. Mais il est vrai que le n°43, traitement des odeurs non confinées ou le n°41, traitement automatique des déchets, voisine bien avec les N°27 et 33, matériaux composite pour la construction (toujours le BTP !) à base de biomasse, et carburants de synthèse issus de la biomasse. Puisqu'on parle de carburants, la sacro-sainte voiture n'est pas oubliée : n°58, infrastructures routières intelligentes (et celles que l'on a maintenant, que sont-elles donc ?), n°59, sécurité active des véhicules, n°64, acoustique des véhicules, n°65 et 66, architectures électrique et électronique des véhicules, n°67, gestion de l'énergie à bords des véhicules - bref plus de 14 technologies clés ! Pour survivre à ces technologies là, d'autres technologies : du n°44, transgénèse, et n° 45, thérapie cellulaire au n°52, vaccins recombinants seront également « clés » en 2010. Difficile de résister à conclure sur trois technologies clés pour la France de 2010 qui laissent, au moins dans leur énoncé, assez perplexe : n°83, transfert de technologie ; n°57, travaux d'infrastructure furtifs et n°62, moteurs à pistons.
Les plus chafouins se demanderont comment faire le lien entre ces 83 technologies clés et les 67 récents pôles de compétitivité que la caravane itinérante du Ministère en charge de l'Industrie ne cesse de vanter (pour Paris-Île de France, tréteaux et estrades seront installés à Bercy, le 26 septembre dès 8h30). D'érudits occultistes, certainement versés dans l'herméneutique et l'exégèse de la prose administrative ont cru relever que 8 des 83 technologies clés ne figurent pas dans celles attribuées aux 67 pôles. Des hermétistes pencheraient pour 13. Avec les 11 secteurs économiques protégés, décrétés par Dominique de Villepin il y a exactement un an puis passés au Journal Officiel en décembre dernier, le seul lien entre ces recensions tenant lieu de réflexion me semble être le nombre premier de leurs objets. Je prédis donc à brève échéance la liste des 107 domaines d'intérêt national...
Pris en tenaille entre les souhaits intéressés des collectivités locales et des administrations régionales, d'une part, et la véritable tétanisation française à propos de la « mondialisation », qui voit le sujet de l'attractivité de la France devenir progressivement un objet législatif et juridique sous l'autorité de l'Etat (comme on a inscrit naguère le « principe de précaution » dans la Constitution), il est facile de faire apparaître en transparence dans ce récolement des techniques traditionnelles de nos terroirs, certes sous leurs habits neufs de la technologie, le « mal-être » de toute une population scientifique et technique à la fois en perte de considération de la part du grand public et de moins en moins en prise avec le lien entre modernités technologique et économique. Qui a inventé le mécanisme magnétique des têtes de lecture que l'on trouve dans les milliers de disques durs qui peuplent notre vie courante ? Quel joueur, n°10, de l'équipe de France de football a terminé sa carrière professionnelle sur un coup (de boule) d'éclat lors de la finale 2006 de la Coupe de monde de football ? (Interdiction d'utiliser Google !) Pour être cynique, on pourrait compléter la première question de l'indication suivante : et dont l'exploitation commerciale n'a évidemment pas fait la fortune de son inventeur mais bien celle des géants américains et asiatiques de HP à Dell, d'IBM à Fujitsu, d'Acer à Apple. Il vaut mieux être joueur de football que scientifique !
La confusion règne dans les esprits.
Le 15 juin dernier, l'INSEE, dont on ne saurait évidemment mettre en doute la neutralité, sortait un dossier « Innovation et niveau technologiques des entreprises industrielles françaises » (lire http://medias.lemonde.fr/mmpub/edt/doc/20060615/783679_inseeinnovation.pdf) dans les Comptes et dossiers 2006, Rapport sur les comptes de la Nation 2005. La Nation donc, selon le dossier, se trouve à la croisée des chemins. « L’économie française était dans l’après-guerre une économie « de rattrapage », dont les gains de productivité étaient fondés sur l’imitation des technologies issues des pays « leaders » (les États-Unis). Elle aurait aujourd’hui rejoint cette frontière technologique mondiale. Ayant épuisé le précédent gisement de gains de productivité, il lui faut maintenant innover pour continuer à croître. » Bilan mitigé pour la Nation : les entreprises innovantes sont le moteur le plus régulier de la croissance mais la capacité à breveter est insuffisante. Conclusions prudentes et éludant les sujets de fâcherie : « D’une part, l’intensité des activités de R&D et le niveau technologique général semblent être des facteurs cruciaux pour innover. D’autre part, les entreprises innovantes semblent être à l’origine d’une part importante de la croissance sur la période récente, et surtout en être devenues l’un des moteurs les plus stables. Ces entreprises innovantes, « de pointe », jouent bien le rôle que l’on attend d’elles dans un régime de croissance fondé sur le savoir et la compétitivité hors prix. Mais la contribution de ce moteur resterait néanmoins en deçà des pays les plus performants et le positionnement de la France à la frontière technologique resterait donc fragile, fragilité dont témoignerait également le fléchissement des dépenses de R&D ».
Début septembre, alors que la Nation, en vacances et aux abonnés absents depuis mi-juin, se remettait lentement des torpeurs caniculaires et estivales en calculant les RTT d'ici à l'élection présidentielle, Forrester Research - sortant de son domaine de prédilection habituel - publiait un rapport d'un ton bien différent du précédent, mettant au contraire en avant les capacités et les modèles d'innovation en France, pour une fois cités en exemple. Un hapax !
Navi Radjou, VP du groupe américain, n'hésitait pas à titrer : A French Revolution in Innovation is Unfolding (http://www.forrester.com/Research/Document/Excerpt/0,7211,40105,00.html). (Juste une note lexicographique, pour nos amis américains il y a peu de substantifs que l'on peut accoler, sans déchoir, à l'adjectif « french » : « kiss », « fries », « toast », « letter », « leave » qui est plutôt anglais, « bean » et bien sûr « Revolution » ce qui donne une nouvelle idée de l'attractivité de la France.) M. Radjou a interrogé LASER, Renault-Nissan, Air Liquide, France Telecom, Société Générale, CNP Assurances, Banque de France, L'ATelier (à BNP Paribas) et Ilog. Curieusement, toujours au plan de l'attractivité de la France bien sûr, parce que France Telecom a placé 9 de ses 17 centres de recherche et développement hors de France, l'analyste de Forrester salue la capacité de l'opérateur à puiser dans les viviers de compétences hors de ses frontières. On frise le politiquement incorrect. Dans le même esprit, il souligne l'importance de structures comme l'Atelier de BNP Paribas ou Laser auprès du groupe Galeries Lafayette pour d'abord anticiper et diffuser les bonnes pratiques en matière d'innovation, et plancher ensuite sur les usages qui peuvent en découler. D'ailleurs, selon une enquête menée cette année par IBM au niveau mondial auprès de 765 PDG de grands comptes (Global CEO Study 2006), ceux-ci se reposent en priorité sur leurs salariés pour apporter des innovations. Les départements R&D, eux, n'obtiennent que la huitième place. C'est donc en se tournant vers elles-mêmes que les entreprises trouveraient les ressources de leur développement à venir. Tous ne jugent pas l'entreprise France capable d'y parvenir. Ainsi l'Insead et le World Economic Forum de Davos placent-ils notre pays en vingt-deuxième position, avant l'Estonie et la Malaisie, dans le palmarès (Global Information Technology Report 2006) des nations et des communautés à même de participer et de bénéficier des développements des technologies de l'information. Sans parler du classement académique des universités mondiales par l'université Jiao Tong de Shanghai, bien connu maintenant, dans lequel le premier français, Paris VI, arrive en quarante-cinquième place (45 n'est pas premier, c'est 3*3*5).
Alors on ne sait plus qui croire. Sur le site de Forrester Research, on note quand même dans la biographie de M. Radjou : « Navi holds undergraduate degrees in computer science from the University of Paris and CNAM-Paris and an M.S. in information systems from Ecole Centrale Paris. Navi also attended the Yale School of Management ». Au moins n'a-t-il pas « used all his french » (autre curiosité lexicographique que je laisse à la sagacité du lecteur) dans la rédaction du rapport et lui a-t-il donné une touche optimiste qui tranche avec le discours ambiant.
Il n'en fallait pas plus pour se sentir pousser des ailes. L'Ambassade de France aux États-Unis a lancé un vaste programme de recrutement de jeunes entrepreneurs américains (http://www.france-science.org/innovation/yei/home.html) les incitant à créer et développer leur entreprise en France. Bien sûr, mais pourquoi n'y a-t-on pas pensé plus tôt !
mercredi, septembre 13, 2006
Microsoft dans l'arène, face à Ajax
Dans l'Iliade, Homère rapporte qu'il y avait Ajax fils de Télamon, dit le grand Ajax, et Ajax, fils d'Oîlée, dit Ajax le petit. Durant le long siège de Troie, Ajax le Grand fut tiré au sort pour combattre au nom des Achéens (les Grecs) Hector, le formidable champion des Troyens. « Ils parlèrent ainsi, et Ajax s'armait de l'airain éclatant. Et après qu'il eut couvert son corps de ses armes, il marcha en avant, pareil au monstrueux Arès que le Kroniôn envoie au milieu des guerriers qu'il pousse à combattre, le coeur plein de fureur. Ainsi marchait le grand Ajax, rempart des Akhaiens, avec un sourire terrible, à grands pas, et brandissant sa longue pique. Et les Argiens se réjouissaient en le regardant, et un tremblement saisit les membres des Troiens, et le coeur de Hektôr lui-même palpita dans sa poitrine » traduit Leconte de Lisle, histoire de poser le personnage.
La relecture d'Homère peut donc conduire à s'interroger sur les choix de Microsoft pour le nom de son « framework Ajax » maison. Rappelons d'abord, pour ceux qui viendraient d'être libérés de leurs salles blanches étanchéifiées en prévision du bug de l'an 2000, qu'Ajax, plébiscité par la clameur des programmeurs se réclamant de l'Open Source et du Web 2.0, est le nec plus ultra de la mode pour le développement d'applications Web. Visant à donner aux utilisateurs du navigateur Web la même richesse d'interaction graphique que celle à laquelle les postes clients, dits riches, sous-entendus Windows, les ont habitués, Ajax est un mélange astucieux de code Javascript et de requêtes asynchrones vers les services Web. Comme le code Javascript contenu dans la page Web est exécuté sur le poste client, le serveur n'est pas surchargé et son rôle de fournisseur de services mieux identifié. Comme les requêtes vers ces services sont asynchrones, elle n'apparaissent pas ralentir l'affichage de la page Web pour l'utilisateur.
La banalisation de XML, abondamment utilisé dans cette communication asynchrone avec les services Web, et l'inclusion d'un interpréteur Javascript dans la plupart des navigateurs Web ont conjointement permis le développement véritablement proliférant d'Ajax. La saveur « communautaire » d'Ajax s'est teintée d'un arrière goût anti Microsoft avec le ralliement de Google à cette technologie, utilisée dans ses offres applicatives grand public comme GMail, et son alliance dans Open Ajax avec IBM. (Les autres membres du projet sont BEA, Borland, the Dojo Foundation, Eclipse Foundation, Laszlo Systems, Mozilla Corporation, Novell, Openwave Systems, Oracle, Red Hat, Yahoo, Zend et Zimbra. Microsoft n'en fait donc pas partie.) OpenAjax travaille à un environnement de développement Ajax ouvert et à la promotion d'Ajax en général.
L'émergence d'une solution de développement d'applications Web, promettant la richesse de Windows sans ses lourdeurs (supposées ou réelles) ne pouvait donc laisser Microsoft de marbre. Son framework maison, annoncé rapidement l'année dernière, vient de prendre consistance plus épaisse avec l'annonce et la publication d'une feuille de route pour la livraison de la version 1.0. L'histoire des noms n'est pas anodine. Si, lecteurs d'Homère, nos VP Marketing de Microsoft avaient choisi de nommer leur framework « Hector », on aurait tout de suite compris des intentions belliqueuses. (D'ailleurs inexactes, puisque dans l'épopée les dieux arrêtent les combattants à la tombée de la nuit sans qu'ils n'aient été départagés : de force égale les deux héros antiques deviennent les meilleurs copains du monde, échangent leurs baudriers et leurs épées, avant d'aller respectivement fêter l'événement dans leurs camps !) Non, Microsoft a choisi Atlas, géant de la mythologie grecque pétrifié et transformé en montagne pour avoir offensé Persée, comme nom de code. Interprétation : Atlas, déplaçant des montagnes soutient le monde sur ses épaules !
Dans la valse récente des virages techniques (abandon de WinFS), des reports de dates de livraison (Windows Vista), voire des changements à la tête du management (Bill Gates laissant à terme sa place à Ray Ozzie), Microsoft annonce aujourd'hui la livraison avancée de la version 1.0 d'Atlas fin 2006 et... un changement de nom. La bibliothèque Javascript client d'Atlas devient « Microsoft AJAX Library » et s'annonce compatible avec tous les navigateurs Web. Sur le serveur, l'intégration d'Atlas avec ASP.NET devient « ASP.NET 2.0 AJAX » et le Control Toolkit devient « ASP.NET Ajax Control Toolkit ». Atlas disparaît et devient (se pétrifie ?) ASP.NET. L'interprétation est du coup assez claire : réintégration dans la plate-forme ASP.NET.
Il reste à voir si ce mouvement de réintégration est offensif ou défensif, face aux tenants originaux de l'architecture Ajax. Le foisonnement des développements libres comme ceux de Google, Yahoo!, Dojo, Mochikit, Backbase, JQuery, Prototype, Script.aculo.us, etc. (cf. http://ajaxpatterns.org/Javascript_Multipurpose_Frameworks), sans oublier celui des offres propriétaires comme Bindows, Open Rico, Zimbra AjaxTk, etc. laisse à penser que le dernier mot est loin d'être dit et que la communauté des développeurs fourbit aussi ses armes.
Dans l'épopée du poète, les choses tournent rapidement au vinaigre : Hector fêté par les siens, trouve la mort en combat singulier (littéralement « homérique ») contre Achille malgré la protection du dieu Apollon (Chant XXII). Plus tard, Ajax concourt à la lutte contre Ulysse, mais aucun des deux ne l'emporte décisivement sur l'autre. Après la mort d'Achille, Ulysse et Ajax se disputent l'honneur d'en recevoir les armes. Ulysse est finalement choisi par Agamemnon, ce qui rend Ajax fou de colère et le conduit à se suicider, se jetant sur l'épée même qu'Hector lui avait donnée en gage d'amitié !
Souhaitons seulement un destin moins épique à l'avatar moderne d'Ajax sur le Web 2.0...
La relecture d'Homère peut donc conduire à s'interroger sur les choix de Microsoft pour le nom de son « framework Ajax » maison. Rappelons d'abord, pour ceux qui viendraient d'être libérés de leurs salles blanches étanchéifiées en prévision du bug de l'an 2000, qu'Ajax, plébiscité par la clameur des programmeurs se réclamant de l'Open Source et du Web 2.0, est le nec plus ultra de la mode pour le développement d'applications Web. Visant à donner aux utilisateurs du navigateur Web la même richesse d'interaction graphique que celle à laquelle les postes clients, dits riches, sous-entendus Windows, les ont habitués, Ajax est un mélange astucieux de code Javascript et de requêtes asynchrones vers les services Web. Comme le code Javascript contenu dans la page Web est exécuté sur le poste client, le serveur n'est pas surchargé et son rôle de fournisseur de services mieux identifié. Comme les requêtes vers ces services sont asynchrones, elle n'apparaissent pas ralentir l'affichage de la page Web pour l'utilisateur.
La banalisation de XML, abondamment utilisé dans cette communication asynchrone avec les services Web, et l'inclusion d'un interpréteur Javascript dans la plupart des navigateurs Web ont conjointement permis le développement véritablement proliférant d'Ajax. La saveur « communautaire » d'Ajax s'est teintée d'un arrière goût anti Microsoft avec le ralliement de Google à cette technologie, utilisée dans ses offres applicatives grand public comme GMail, et son alliance dans Open Ajax avec IBM. (Les autres membres du projet sont BEA, Borland, the Dojo Foundation, Eclipse Foundation, Laszlo Systems, Mozilla Corporation, Novell, Openwave Systems, Oracle, Red Hat, Yahoo, Zend et Zimbra. Microsoft n'en fait donc pas partie.) OpenAjax travaille à un environnement de développement Ajax ouvert et à la promotion d'Ajax en général.
L'émergence d'une solution de développement d'applications Web, promettant la richesse de Windows sans ses lourdeurs (supposées ou réelles) ne pouvait donc laisser Microsoft de marbre. Son framework maison, annoncé rapidement l'année dernière, vient de prendre consistance plus épaisse avec l'annonce et la publication d'une feuille de route pour la livraison de la version 1.0. L'histoire des noms n'est pas anodine. Si, lecteurs d'Homère, nos VP Marketing de Microsoft avaient choisi de nommer leur framework « Hector », on aurait tout de suite compris des intentions belliqueuses. (D'ailleurs inexactes, puisque dans l'épopée les dieux arrêtent les combattants à la tombée de la nuit sans qu'ils n'aient été départagés : de force égale les deux héros antiques deviennent les meilleurs copains du monde, échangent leurs baudriers et leurs épées, avant d'aller respectivement fêter l'événement dans leurs camps !) Non, Microsoft a choisi Atlas, géant de la mythologie grecque pétrifié et transformé en montagne pour avoir offensé Persée, comme nom de code. Interprétation : Atlas, déplaçant des montagnes soutient le monde sur ses épaules !
Dans la valse récente des virages techniques (abandon de WinFS), des reports de dates de livraison (Windows Vista), voire des changements à la tête du management (Bill Gates laissant à terme sa place à Ray Ozzie), Microsoft annonce aujourd'hui la livraison avancée de la version 1.0 d'Atlas fin 2006 et... un changement de nom. La bibliothèque Javascript client d'Atlas devient « Microsoft AJAX Library » et s'annonce compatible avec tous les navigateurs Web. Sur le serveur, l'intégration d'Atlas avec ASP.NET devient « ASP.NET 2.0 AJAX » et le Control Toolkit devient « ASP.NET Ajax Control Toolkit ». Atlas disparaît et devient (se pétrifie ?) ASP.NET. L'interprétation est du coup assez claire : réintégration dans la plate-forme ASP.NET.
Il reste à voir si ce mouvement de réintégration est offensif ou défensif, face aux tenants originaux de l'architecture Ajax. Le foisonnement des développements libres comme ceux de Google, Yahoo!, Dojo, Mochikit, Backbase, JQuery, Prototype, Script.aculo.us, etc. (cf. http://ajaxpatterns.org/Javascript_Multipurpose_Frameworks), sans oublier celui des offres propriétaires comme Bindows, Open Rico, Zimbra AjaxTk, etc. laisse à penser que le dernier mot est loin d'être dit et que la communauté des développeurs fourbit aussi ses armes.
Dans l'épopée du poète, les choses tournent rapidement au vinaigre : Hector fêté par les siens, trouve la mort en combat singulier (littéralement « homérique ») contre Achille malgré la protection du dieu Apollon (Chant XXII). Plus tard, Ajax concourt à la lutte contre Ulysse, mais aucun des deux ne l'emporte décisivement sur l'autre. Après la mort d'Achille, Ulysse et Ajax se disputent l'honneur d'en recevoir les armes. Ulysse est finalement choisi par Agamemnon, ce qui rend Ajax fou de colère et le conduit à se suicider, se jetant sur l'épée même qu'Hector lui avait donnée en gage d'amitié !
Souhaitons seulement un destin moins épique à l'avatar moderne d'Ajax sur le Web 2.0...
Inscription à :
Commentaires (Atom)