Geoportail, SNCF, ces lancement à succès ratés…

Les lancements sont nombreux et les effet d’annonce fatals ! Geoportail n’a pas vraiment pu etre accessible avant 1 semaine ou 2. Le site de la SNCF n’a dernierement pas survécu à la vente de billet TGV à 5? avec le prime le superbe resultat de 0 ventes en ligne ! mais oui ! La faute à qui ? trop de monde en même temps il parrait !

Je ne remets pas en cause ce fait car il est vrai que tout lancement conduit à un pic dramatique pour l’architecture… Mais si le fait est avéré, il est prévisible ! Qu’ont donc fait les chefs de ces projets pour palier à celà ?!? Pas grand chose semble-t-il, en tout cas je leur souhaite car les sommes investies en se sens l’ont été à pure perte vu le résultat !

La question que je me pose est la suivante : vaut-il mieux chercher à servir tout le monde avec une forte probabilité de ne servir personne ou servir une partie seulement des Internautes ? Il semble que ces CP aient choisi la première solution et cet article à pour but, vous l’aurez compris, de décrire comment employer la seconde.

J’ai en effet lu qu’avant l’opération TGV à 5 euros, la SNCF avait anticipé le pic en multipliant par 3 la capacité serveurs… Pour le résultat commercial donnée ci-dessus … c’est du gaspi ; je leur souhaite que celà s’inscrive dans un cadre d’extension global des capacités de leur infrastructure…. bref, la solution n’est pas de ce coté.

Ma vision de ce problème serait une approche différente ; les serveurs étant saturés par :

  • La saturation de la bande passante d’entrée, dûe aux très nombreuses requetes concurente; mais il ne semble pas que ce soit le facteur premier
  • La saturation des serveurs d’application, qui semble être plus directement concernée

S’attaquer à la seconde cause n’est pas vraiment compliqué, sans même multiplier le nombre de serveurs : actuellement, les applications web sont le genre de systèmes extrèmement lourds en consommation mémoire, requete de bdd, cpu. Elles sont l’accumulation des dizaines de couches logicielles : OS, JVM, bibliothèques diverses, jdbc, ejb, frameworks, jps / servlet de présentation … bref, à chaque ouverture de nouvelles sessions, tout ce petit monde se met en branle, réserve beaucoup de mémoire et consomme une quantité astronomique de temps CPU pour n’afficher qu’un bandeau, un menu et deux trois news … L’arrivée de milliers de connexions simultanées sature alors les ressources au point que l’application ne soit tout simplement plus accessible pour personne. La machine arrive rapidement dans un etat de saturation où son temps de réponse n’est plus lineaire mais exponnentiel ; autant dire que le serveur est planté.

Une bonne solution, économique, pour se sortir de cette situation est de protéger ces serveurs de la saturation en limitant le nombre d’utilisateur concurent pouvant accéder à l’application. Celà revient à limiter le nombre de sessions simultanées. Pour empécher la saturation, cette limitation sera prise en compte par un serveur différent dont le rôle, sera, par l’utilisation d’une technologie la plus légère possible, de recevoir toutes les demandes de connexion et de ne transmettre que celles pouvant etre traitées à l’application. Les autres etant renvoyées proprement sur une page d’erreur ou d’information.
L’utilisation d’une technologie légère est la clef de cette solution. J’imagine que les modes “cluster” de serveurs apaches doit pouvoir être configurable en ce sens en limitant le nombre de sessions par serveur : jusqu’a une certaine limite, les sessions sont redirigées vers l’application, les suivante vers une simple page HTML d’erreur.
Bref.. ce n’est qu’une ébauche de solution est il y en a de multiples autres, le tout etant d’y réfléchir et de prendre le problème par le bon bout, ce qui ne me semble pas etre souvant le cas !
La solution optimale serait d’intégrer ce genre de fonctionnalités dans des éléments réseaux matériels dédiés, ce qui existe peut etre, ou en tout cas ce ne serait pas très compliquer à construire pour des spécialistes.

Au passage ces solutions sont aussi une bonne protection contre les attaques en provenance des vers de type flood… ce sont donc des solutions toujours utiles, y compris hors lancement et campagne de promotion : un investissement durable.

En conclusion, les situations que j’ai évoqué et qui font la risée des utilisateurs me semblent majoritairement évitables. Leurs impacts peuvent être tout du moins amoidris et il me semble que ces problématiques doivent donc etres prises en compte plus sérieusement.

Comment fonctionne WEP ?

C’est à grand renfort d’articles sur tout la toile qu’un nouveau POC (Proof Of Concept) vient annoncer que WEP est mort ! rien de bien nouveau en soit puisqu’on l’avait dejà tué depuis des années, mais cette fois la méthode est plus rapide, plus automatique et sans doute bientot à la portée de tous, ou presque.

Est-ce alarmant ? en soit, utiliser Wep est alarmant depuis bien longtemps, donc un peu plus un peu moins ? et si vous dormez sur vos deux oreiles malgré cela et bien continuez ! il n’y a pas de raisons ; le tout c’est d’en être concient, non ?

Qu’est ce que cette nouvelle methode de Bitau, Handley et Joshlack ? Elle repose en fait sur l’utilisation d’un utilitaire existant dans le protocole 802.11 (Wifi) : la fragmentation de trame ou plutot la défragmentation par l’AP. Le rôle de l’AP dans un réseau avec architecture est de recevoir les trames de tout le monde puis de les réémettre : ainsi si tout le monde capte l’AP, tout le monde peut communiquer, y compris si deux postes sont trop distants pour se joindre directement … L’AP etant un périphérique intelligent, lorsqu’il recoit des fragments de trames, il commence par les réunir en trame plus grosses avant de les réémettre. Alors comment cela nous aide-t-il a craquer une clef Wifi, c’est assez simple :
Avec le cryptage WEP, qui n’est autre qu’un simple XOR, il suffit de connaitre une chaine et son equivalent crypté pour connaitre la clef de cryptage, donc puisque nous captons des données cryptées, il nous faut connaitre leur equivalent non crypté pour connaitre la clef associée. Les protocoles de couches basse nous aident en celà : certaines trames LLC/SNAC, ARP ont des parties qui sont constantes et celles-ci sont identifiables par des tailles caractéristiques. En captant ces trames, nous avons des données cryptées et connaissons leur équivalent non crypté. Ainsi il est possible d’obtenir facilement quelques octets de la clef de cryptage (qui n’est cependant pas directment la clef partagée que l’utilisateur configure).
Cette étape accomplie, la nouvelle solution par fragmentation entre en jeu : les morceaux de clef que nous avons sont trop petits, la fragementation va nous permettre de les multiplier : il suffit de renvoyer plusieurs fois la trame reçue en l’indiquant fragmentée : connaissons la cryptée et son équivalent décryptée. L’AP va recevoir ces fragments, les décrypter et les assembler dans une nouvelle trame qu’il va crypter puis, enfin, réémettre cettre trame sur le réseau. Cette trame nous allons pouvoir l’écouter, nous connaissons sa version non cryptée puisqu’il s’agit de la concaténation du message precédent avec lui-même et l’AP vient de nous fournir sa version cryptée. Nous sommes donc à même, comme à l’étape 1 de connaitre la clef associée, mais cette fois nous n’avons plus 8 octets mais n*8 octets (avec n le nombre de framents).

En continuant ainsi il est possible d’obtenir une clef de cryptage valide suffisemment grande pour crypter n’importe quel paquet. Nous allons donc pouvoir emettre sur le réseau n’importe quel paquet, sans connaitre la clef partagée initiale mais simplement la suite issue du RC4. Cette facultée va nous permettre de générer du traffic valide vers le réseau et ainsi collecter un maximum de trames pour, par la suite, lancer une attaque sur ces informations et en déduire la clef partagée (type aircrack).
Cette methode, présentée ainsi est donc une solution plus rapide et encore imparable pour générer du traffic : le principe de defragmentation est à la base du protocole, il est difficile de le bloquer alors que bloquer les réémissions forcée d’une methode aireplay est assez courant. Par ailleurs, il permet de connaitre bcp plus de données de chaque chaînes cryptées (contrairement aux ARP habituels) et ainsi d’etre plus efficasse avec moins de trames.
Cette mehode reste totalement interdite à l’utilisation hors de son propre réseau privé puisqu’elle demande l’emission de données vers le réseau distant, ce qui implique une intrusion dans le dit système, Acte répréhensible par la lois.

Les auteurs de cette methode, proposent une autre alternative à la simple collecte d’informations en vue de connaitre la clef partagée ; en effet, ils proposent d’utiliser cette methode, associée à d’autres pour forcer l’AP à router des paquets cryptés vers l’Internet : dans ce cas, le paquet emis en direction de l’Internet est décrypté par l’AP avant d’etre envoyé sur la ligne (logique on sort du WLAN). Le site distant est alors un site amis du pirate qui va ainsi recevoir les données décryptées issues du réseau WLAN dit “sécurisé” … pas mal ! Le principe en est assez simple, il s’agit de créer une entête IP a destination du serveur sur l’Internet, de l’indiquer fragmenter et de réémettre un paquet crypté que l’on souhaite faire décrypter en l’indiquant comme étant la suite du précédent. L’AP va alors decrypter les deux, concaténer le paquet “secret” à notre entete IP, constater qu’il s’agit d’une trame pour l’extérieur et la router décryptée. Reste que ce type d’attaque est plus facile à tracer qu’un wardriving sauvage, rendu rapide par la methode.

Quid de l’implémentation ? Les auteurs proposent quelques sources de leur POC, la mise en oeuvre demande un contrôle au niveau le plus bas des cartes Wifi, pour, entre autre, gérer les flags permettant la fragmentation au niveau logiciel. Ces possibilités ne sont pas offertes sure toutes les puces ou demandent des workaround un peu touchy .. bref, pour l’instant 2 chips sont supportés dont le PRISM2. Il y a de fortes chances pour que d’autres arrivent.
Point vraiment interressant, ce qu’ils ont mis en oeuvre est totalement automatisé, contrairement à ce qui existe sur aircrack. Les outils aircrack ne peuvent pas etre mis entre toutes les mains, elle doivent toujours être averties : ligne de commandes, options compliquées… Une solution entierement automatisée pourrait etendre la chose aux pirate boutoneux du dimanche …
Il n’en reste pas moins que ca ne marche et ne marchera sans doute jamais que sous Linux et autre BSD ;o)

Déjà de la concurence dans les desktop léger !

Le concept n’existe pas encore, autant dire qu’aucune courbe de Garnet n’envisage même la chose et pourtant la concurrence s’annonce rude pour ce qui se nomme par abus de langage des OS légers, disons plutot des desktop legers ! Après eyeOs voici la venue de YouOS

Comme d’habitude, il s’agit surtout d’un démonstrateur de ce qui se fait en Ajax, on est encore loin d’un système utilisable tout les jours, applications très limitées, performances et compatibilité un peu légères. Comme eyeOs il s’agit surtout un POC (Proof Of Concept).

Et comme eyeOs ca ne marche pas trop mal en ce sens. Il semble que ce système soit porté par une entreprise qui doit donc y voir un avenir commercial, point plutôt intéressant et il est vrai qu’il n’y a pas de raison pour que ca ne le deviennent pas. Après tout emporter son espace personnel avec soit est plutôt un concept prometteur.

Ce qu’il manque avant tout à cela à mon avis est ce qui fédère un front-end graphique : des librairies de développement, des standards de communication pour que d’autres puissent développer des applications et ainsi dépasser les simples calculatrices et autres joujou ajax. Une architecture principalement basée sur les webservice avec une composante serveur très forte serait beaucoup plus intéressante que l’espèce de paquet de nouille javascript qui nous est présenté.

Bref le concept n’est donc pas nouveau mais récent, il n’est pas le premier, ça reste prometteur mais on attend de voir mieux, en tout cas cette concurrence devrait stimuler les développeurs !

VmWare player ou Xen ?

Avant d’utiliser cette technologie avec un objectif de rationnalisation de mes serveurs de dev (restons très modeste je parle de ce qui me sert à developper quelque site perso dont celui-ci), j’ai essayé deux produits me semblant être les principaux outils concernant ma cible d’implémentation à savoir Linux : vmware, outil payant mais disponible en version communautaire et xen, outil totalement ouvert.

J’ai donc commencé par vmware et de dois avoué que c’est à peut pret aussi simple qu’une installation de logiciel classique : installation du RPM qui va bien, lancement de l’executable en temps que root … la compilation des package, la signature de je ne sais trop quoi … tout est automatique. C’est beau c’est pro. nickel !
L’installation d’une VM est assez simple : vmware lance un vrai machine completement virtuelle, avec son bios, ses périphériques virtuel qui ne sont autre que les vrai périphériques physiques de la machine après association faite lors de la configuration de la VM. Bref, il suffit de mettre un cd d’install dans le lecteur, démarrer la VM en cliquant sur le bouton et zou, on boot la VM sur le CD et l’installation débute. Trop facile !!
Une fois installé, le petit package de drivers pour le système hôte se déploie en un clic et optimise grandement la performance des périphériques souris et clavier.
Avantage de vmware, simulant une machine physique, il supporte n’importe quel systeme fonctionnant sur la même plateforme (voir une autre plateforme dans des conditions plus pro). Du coup il est possible de s’en servir pour l’installation de windows XP sous linux lorsque l’on en a une utilisation très ponctuelle comme par exemple vérifier la compatibilité d’un site avec IE ou flasher un périphérique USB pour lequel on a qu’une version windows du soft (c’est du vecu). Parceque oui, le petit plus c’est la possibilité en un click de connecter un element USB sur la VM ! solution très interressante qui ouvre de nombreuses nouvelles possibilités en terme de support de périphérique sur une VM.
Bien sure, il faut aussi regarder les performance de cet environnent virtuel, et de ce point de vue là, dans un cadre d’utilisation simple c’est vraiment correct : pour vous dire j’ai fait tourner un XP sous Linux avec en tache de fond un calcul distributed.net + un calcul BOINC et franchement, l’utilisation etait acceptable, le tout sur une machine à environ 1.5Gz. Les problèmes de performance apparaissent vraiment avec le manque de mémoire : à savoir que le disque est simulé, il s’agit en réalité d’un fichier, lui-même écrit sur un file-système géré par linux et mappé sur un disque physique. Lorsque le système virtuel vient à manquer de mémoire physique, celui-ci se met à swapper dans un fichier, lui-même ecrit dans le fichier décrit ci-dessus … bref, l’empilement d’IO virtuelles et réelles que l’on rencontre alors finit vite par venir à bout de n’importe quoi … et vous amenè par exemple à fermer windows en plus de 2h … beau score ! POur une utilisation plus proffessionnelle ou resemblant moins à des tests je ne peux que conseiller l’utilisation de partitions physique plutot que logique pour les VM.

C’est ainsi que j’ai ensuite décidé de faire quelque essais avec Xen, d’autant que ma suse préférée offrait cette possibilitée. Pour la petite histoire, j’ai tout d’abord essayer ça dans une VM sous vmware (lol).
Le principe de Xen est un peu différent, il ne s’agit pas d’une application hébergée par un système hôte qui va faire tourner des VM, mais d’une couche basse, située en dessous du noyau hôte et qui va permettre le partage des ressources matérielles. Donc en gros, au boot, on demarre une sorte de noyau Xen (l’hyperviseur) qui lui-même va démarrer un noyau principal, le domaine0 depuis lequel on va pouvoir lancer les machines secondaires.
Le noyau est compilé spécifiquement pour Xen avec une architecture eponyme. Xen ne fournit pas une machine vituel, au même sens que vmware qui vous fournit une sorte de PC version logiciel, il fournit un service de partage des ressources matérielle à plusieurs systèmes ce qui est assez différent, surtout dans le sens où il n’est pas possible d’installer avec Xen n’importe quelle VM, mais seulement des noyaux type linux, openbsd & co. Pas de Windows ici bas. L’installation d’une VM ne se fait d’ailleurs pas de le même façon que celle d’un système classique : ici pas de boot depuis le cd pour l’install … on se débrouille pour installer l’OS dans un file système (logique ou physique) puis on boot sur ce file system. Un peu moins user-friendly, mais après tout, la création de VM est-ce vraiment une fonctionnalité grand publique ?
Les performances sont plutot au rendez-vous, j’utilise une VM comme serveur de DEV avec tomcat, mysql & co, les temps de réponse sont les même que sur mon serveur précédent dont la conf était certe un peu inférieur mais sans que ce soit sensible. Grosso modo, je concidère que le fait que ce soit une VM est transparent avec Xen, pour l’instant. A noter qu’il est possible de gérer la priorité entre les différentes VM, solution utile si l’on souhaite partager le même hardware pour des serveur de DEV et PROD par exemple.

Pourquoi utiliser des VM me direz-vous ? hors mis pour se trouver dans le situation hubuesque mais présente : lorsque je boot mon serveur de dev la séquence est la suivante :

  • Un bootloader sur disquette va chercher un booloader pxe sur un serveur tftp
  • Celui-ci charge un bootloder plus perfectionné qui permet de booter un noyau Xen (multi-kernel)
  • Ce dernier va ensuite chercher l’hyperviseur Xen
  • Qui boot le noyau du domaine principal présent sur NFS
  • Qui demarre enfin la VM, elle aussi présente sur un autre lien NFS

Pourquoi faire simple quand on peut faire compliqué ? et bien simplement pour détacher le matériel du logiciel !!! voila qui permet de se sortir en un clein d’oeil des problèmes de pannes, mais qui permet aussi de migrer de matériel sans avoir à faire de réinstallation fastidieuses.

EyeOs – le futur de l’informatique ?

EyeOs est ce que l’on pourrait appelé un OS riche en quelque sorte… sauf qu’il n’a pas grand chose à voir avec un OS. C’est en tout cas une application assurant la mise à disposition d’application, au travers d’un client léger, au sein d’une interface graphique semblable à celle des systèmes d’exploitation usuels.

EyesOs est plus un demonstrateur qu’un outil réellement utilisable. Il n’en reste pas moins qu’il s’agit d’un bel exemple des capacités liées aux technologies Ajax / Web2. D’un look & feel très proche de ce que propose meebo, EyesOs permet a un utilisateur identifié par un login / mdp d’accéder à un ensembles d’outils basiques tels qu’un calendrier, un traitement de texte simpliste …. le tout réunit dans une interface similaire aux gestionnaires de fenêtre de windows ou mac os X.

Ce qu’il y a d’intéressant :

  • Le menu d’accès aux applications au look mac-os, le choix de différents look & feel (dont mac-os X)
  • La possibilité de lancer plusieurs “application” en même temps
  • Manipuler ces applications comme on manipule des applications sur un système de gestion de fenêtre classique
  • Le fait que des applications hétérogènes cohabitent au sein de la même page web

On est encore loin du système d’exploitation intégré au client léger d’autant que l’on ne parle pas d’ordonnancement de tâches ni même de processus. Mais c’est un démonstrateur intéressant.

Il me semble que l’étape majeure qu’il reste à franchir est de standardiser sur ce type de portail des interfaces permettant à des applications tierces d’être intégrées ; le parc applicatif ainsi mis à disposition pourrait permettre de rendre ces systèmes plus attractifs.

Toutefois, quel intérêt y trouverons nous hors mis la prouesse technique ? C’est en quelque sorte une réinvention du terminal X, quelque couches logicielles en plus non ?

Opensuse 10.2, le test

Comme d’habitude, je mirror les installs sur mon réseau local ce qui me permet d’être pénard pour les install suivantes; rien de nouveau là dessus sauf qu’une nouvelle fois il faut faire le tri pour le pas récupérer 30Go incluant des versions ppc qui ne me sont pas utile. Tout va bien si ce n’est la ligne wget un peu longue mais bon on aime ou on aime pas ;o).
Ensuite, je suis fdonc parti sur une install NFS et pour info, comme je ne souhaite pas trop m’embéter je réalise l’install dans une machine virtuelle VMWare, le tout tournant sous une Linux Suse 10.0. Au passage vive VMWare.. magnifique outil !

Gravage du CD de boot (70 Mo) ; config réseau détectée tout seul, config de l’install via NFS… tout va bien ! un sacré + puisqu’en 10.0 je n’ai jamais rèussi à installer en NFS et j’avais été contraint de graver les 7 cd !!!
Coté installeur YAST, rien de très nouveau, c’est propre et toujours assez simple. J’ai choisi une install par défaut KDE pour ne pas trop me compliquer la vie dans mes tests. Je ne comprends pas trop pourquoi le swap est installé sur la première partition, mais à part ce point ca va ; l’install KDE par défaut fait environ 2Go et YAST s’occupe de tout.

Comme d’habitude il ne faudra pas s’attendre à trouver les packages bien utiles comme java, acrobat reader les codec mp3 et autre … La distribution est 100% GPL et ne viole pas de breuvet logiciel. Dans les liens associés à cet article vous trouverez donc deux repository contenant les packages nécessaire pour tout cela. Le principal problème que je trouve à ca est que la mise à jour des patch de sécurité pour ces élément externes ajoutés n’est pas garantie. PackMap fait des efforts pour les mise à jour mais Suse Watcher ne les prend pas en compte et il n’y a aucun angagement. Bref mieux vaut ne pas les utiliser quand on peut éviter.

Après un peu plus d’utilisation et de déploiement sur differentes machines, j’ai trouvé à cette distribution pas mal de plus et un peu de contre. Coté plus, il y a la touche graphique, toujours mieux, la convivialité elle aussi toujours en progrès. Ce sont de très bonne choses. J’ai pu expérimenté Xen et quelques machines virtuelles. Super ! Bon, bien sure quelques deconvenues, surtout liées au noyau, peut etre opensuse a-t-elle voulue se doter d’un noyau trop récent ?!? n’empeche que le driver de ma ralink n’est pas supporté alors qu’en 10.0 il fonctionnait à merveille et que mes tentative pour utiliser un driver construit par mes soin et malgrès de nombreux post à ce sujet sur le net, n’ont abouti à rien.

J’ai rencontré pas mal de déconvenues avec mon portable (Del L400) :

  • Support de l’APM très moyen, les ventillos ne se declenchent pas et le cpu à finit en coupure thermique… assez desagreable
  • Détection anormal de sélection du bouton “sleep” (il n’y en a pas” qui conduit le système à rebooter sans-cesse en se mettant en “suspend-on-disk”). Ce qui se corrige simplement en modifiant l’evenement associé dans le fichier /etc/sysconfig/powersave/event
  • Pas de support de l’intel speedstep, ni des sensors

A part ca, une fois bien paramétré, le suspend-on-disk c’est du bonheur ! malgrès tout, j’ai fini par reinstallé une version 10 sur le portable pour eviter les déconvenues thermiques…
Coté installation serveur de developpement, tomcat, apache, eclipse sont bien packagés, je ne comprend pas trop la nouvelle organisation des répertoires pour ses applications, la version précédente avec tout dans le /opt me semblait plus simple même si il est vrai qu’elle etait peut etre moins standard.

A part ca je n’ai pas réussi à percer tous les mystères de la wallet à mot de passe utilisée pour le wlan et me demandant de saisir un mot de passe pour me connecter au réseau… alors qu’avec un init-level 3 ca se connecte tout seul… etrange ; comme la grande question subsidiaire ?!? comment change-t-on le mot de passe de sa wallet ?!? à creuser pour ma part.
Bref, quand j’aurai réussi à comprendre comment faire la mise à jour des packages (oui ca aussi ca a changé mais c’est pas clair non plus), je pourrai voir s’il y a eu des correctifs de faits par rapport aux problèmes évoqués plus haut et peut-être y reviendrai-je sur mon portable.

Vivement la 10.2… mais en tout cas, tout ca devient vraiment beau ;o)

Lucca : une solution Ajax de réservation de salles

Lucca, une société Française propose une solution basée sur Ajax pour la réservation de salles de réunion. Là encore, la technologie est mise en valeur : descriptions dynamiques, saisie de rendez-vous graphique digne d’un client lourd ou riche !

Le site lucca.fr propose une démo de son application de réservation de ressources en mode connecté basée sur Ajax. La solution est plutôt esthétique avec un affichage dynamique des informations de la ressource de type tooltips et la présentation graphique des disponibilités. La technique Tooltip est d’ailleurs réutilisée un peu partout pour le zoom sur les réservation … solution plutôt propre, rapie et simple d’emploi.

Mais le plus intéressant concerne le module de réservation qui permet la sélection graphique d’un créneau horaire ; solution qui n’a pas grand chose à envier aux PalmDesktop et autres Outlook. Reste le prix … a mon gout un peu élevé même pour le niveau technique mis en oeuvre mais ce doit être le prix du marché.

 

En temps qu’utilisateur de solutions de ce type, basée sur lotus Notes, cet outil me semble vraiment plus ergonomique, l’ajax apporte une ergonomie d’utilisation indéniable et les temps de réponses sont parfait. L’utilisation de tooltips permet d’éviter le chargement d’une page lors de la visualisation détaillée des réservations d’un salle, c’est super. Seul reproche : le chargement initial un peu long, je les soupçonne de charger toutes les informations de réservation lors de l’ouverture. Dans ce cas, Ajax aurait pu être utilisé pour ne charger les informations de réservation que lors du survol : c’est à dire lors de l’affichage du tooltips.

Encore un nouveau démonstrateur de qualité pour Ajax.