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 ?
Inscription à :
Articles (Atom)