Un service irréprochable
Autant dire que l'Insee ne fera pas l'erreur deux fois : "Nous avons été très prudents pour le site final. L'objectif était de présenter les données du recensement, et de permettre de les trier selon des requêtes. Le site devrait comporter un volet commercial. Il va sans dire que le service se devait d'être irréprochable : un site commercial ne peut pas se permettre une indisponibilité de service ou un temps d'accès médiocre".

La barre a donc été placée haut : avec 200 utilisateurs simultanés, l'objectif était d'arriver à un temps de chargement de 8 secondes pour les pages les plus lourdes - qui comprennent de très longues suites de données. Ce qui supposait d'aller puiser ces données dans une immense base - comprenant près d'un milliard d'entrées - et de les hiérarchiser en un temps très court ; puis de les redistribuer à un grand nombre d'internautes. Un objectif qui "n'est sans doute pas exceptionnel dans l'absolu, mais qui était beaucoup plus complexe que tout ce que l'Insee avait déjà réalisé jusqu'alors".

Mercury appelé à la rescousse
L'Insee a donc sollicité une aide extérieure : "Nous sommes très marqués par notre culture maison, axée autour du mainframe. Et pour tout dire nous étions assez dubitatifs à l'idée de faire tourner une très grosse base de données sur un serveur NT". Il fallait donc avancer à pas de loup en utilisant à tous les stades du projet des outils de gestion de la performance : "Nous avions déjà des outils fournis par Mercury Interactive, puisque c'est le prestatire qui avait été retenu par le passé pour les tests de performance, mais nous ne disposions pas des compétences nécessaires pour les manipuler en interne".

Dés les premières heures de l'implantation, Mercury a donc été mis à contribution : "Dès que nous avons disposé d'un embryon de la base de données, nous avons demandé à Mercury de le tester". On entre alors dans la première phase du test : "Il s'agit ici de vérifier que l'applicatif est suffisamment solide pour supporter la montée en charge - explique Bruno Givelet, directeur technique de Mercury. Pour cela, il faut construire un programme qui simule des centaines de connexions, afin de pousser l'applicatif dans ses retranchements et de repérer ses faiblesses".

Créer un robot de test
Comment construit-on un tel outil de test ? "Nous faisons intervenir une dizaine d'internautes type. Nous leur demandons de réaliser des transactions différentes sur une préversion du site - explique Bruno Givelet. Leurs requêtes sont réunies dans le coeur d'un robot unique, et décuplées avec des outils qui permettent de les faire varier, en changeant par exemple la référence produit de ce que l'internaute test a acheté sur le site. Cette précaution permet de réintroduire l'aléatoire dans le robot." L'instrument de torture est prêt, il ne reste plus qu'à choisir la façon dont il lancera son attaque - requêtes concentrées ou étalées - et à le projeter sur un serveur de test.

Une fois cet assaut lancé, quelques modifications sur le code se sont imposées afin de tirer les conséquences du test. Puis Mercury intervient à la deuxième étape : "Il s'agissait cette fois-ci de lancer le robot sur plusieurs serveurs, avec des cadences de connexion réalistes, afin de choisir le bon modèle". Ce test s'est déroulé dans les locaux de Sun, et Jeannine Gérard est repartie avec un couple de serveurs idéal sous le bras : "Un quadri-processeur sous Unix équipé d'une base de données Oracle pour le gros des calculs, et un bi-processeur sous NT pour le serveur d'applications, qui prend en charge le frontal", liste Jeannine Gérard.

Des agents à chaque point de l'infrastructure
La clé de la réussite ? "Pas encore, précise Bruno Givelet de Mercury. Il restait encore une étape cruciale : le test en environnement de production, directement chez l'hébergeur, sur l'architecture définitive, et avec la présence des systèmes de sécurité. C'est seulement à ce moment là que l'on peut éliminer les derniers goulets d'étranglement, et éliminer les derniers problèmes."

C'est aussi l'étape qui demande le plus de moyens : "Nous plaçons des agents sur chaque point de l'infrastructure : serveur, base de données, réseau, systèmes de sécurité. Ce qui nous permet de diagnostiquer la provenance des ralentissements, et même de fournir des indications sur la méthode à employer pour les éradiquer". De quoi mettre en production un site très fiable, et satisfaire aux exigences du cahier des charges.

Satisfaction ?
L'intervention de Mercury a-t-elle donné entière satisfaction à l'Insee ? "Au début, le niveau de mes interlocuteurs n'était pas systématiquement convaincant, explique Jeannine Gérard de l'Insee. Mais les choses au changé. Au final, l'investissement s'est révélé très rentable : la prestation de Mercury ne nous a coûté que 3 % de notre budget global. Mais grâce à leur aide, le site fonctionne bien, et nous disposons aujourd'hui de l'infrastructure matérielle idéale pour nos besions. Nul doute que nous aurions vu plus grand - trop grand même - si Mercury n'avait pas été à nos côtés."