Débat : Le lancement manqué de France.fr a provoqué beaucoup de réactions du monde du Web. Pour ZDNet.fr, les hébergeurs Gandi, Octopuce, Claranet et le prestataire de service en disponibilité Liazo reviennent sur l’affaire et donnent leurs conseils pour le lancement de sites d’envergure.

Le site France.fr, lancé le 13 juillet au soir, est tombé sous le poids de seulement 25 000 visiteurs quelques heures après sa mise en ligne. Selon ses initiateurs, le Service d’information du gouvernement (SIG), il ne reviendra pas en ligne avant fin août, avec changement d'hébergeur à la clé.



Les experts du Web n’ont pas tardé à railler le site et proposer leur vision du ratage. Quatre experts de l’hébergement et de l’infrastructure nous exposent leurs vision et solution au problème France.fr.

publicité

Stephan Ramoin, Gandi : « C’est un gâchis »

Pour Stephan Ramoin, pdg de l’hébergeur Gandi, ce projet a avant tout souffert du manque de connaissances techniques. « C’est typique de projets lancés avec insuffisamment de connaissances techniques, ce qu’on voit relativement souvent » se lamente-t-il.

Il regrette le manque de soutien de l’Etat, notamment sur des projets d’une telle importance. « On est dans le domaine du jamais vu. C’est un projet important pour la France et ils ne sont même pas capables de voir qu’ils ont sous les yeux une solution. »

« France.fr aurait été l’occasion de montrer quelques bonnes technologies françaises. C’est un gâchis ! »

Le responsable prêche évidemment pour sa paroisse : « s’ils ont besoin de conseil, d’aide, on est là pour les aider, comme pour tous les clients que nous avons le plaisir de servir ».

La partie technique est pour lui le parent pauvre de ce portail. « Souvent ces projets n’ont pas de responsable ou de référent technique. Il y a un problème de professionnalisme : les projets sont souvent gérés par le marketing, le commercial, pas la technique. »

Pour Stephan Ramoin, « c’est un problème de choix technologiques. On a dû payer 10 à 20 fois trop par rapport à ce que cela aurait dû coûter ». Selon différentes sources, le budget du site avoisinerait le million et demi d'euros, la moitié ayant déjà été dépensée.



Pour lui, ce type de projet requiert de bons tests de charge (charge initiale et évolution) tout en prenant compte de nombreux paramètres, dont l’interactivité, les types de contenu (texte, images, vidéo...) ou le nombre de rédacteurs. Ce qui aurait été sous-estimé ici.

Benjamin Sonntag, Octopuce : « Un manque de professionnalisme »

Même tonalité du côté de Benjamin Sonntag d’Octopuce, hébergeur de nombreux sites Drupal (un CMS Open Source à la base de France.fr), dont Mediapart, pour qui la partie technique a en effet été négligée.

« Sur les projets lourds avec de gros appels d’offres, les budgets développement, conception et communication existent mais il n’y a pas de budget pour l’infrastructure et la technique » regrette-t-il.

« On est à la limite de l’entendement. J’ai entendu qu’il y a 12 serveurs de milieu de gamme pour France.fr. Pour qu'ils saturent, chaque visiteur de France.fr aurait dû consommer 20 fois plus de puissance qu’un visiteur de Mediapart ! »

Il estime que trois serveurs, deux Apache et un MySQL masqués par des serveurs de cache auraient suffi à tenir la charge du 14 juillet.

« 12 serveurs, c’est beaucoup sur un site qui n’était pas a priori dynamique. Les 50 000 visiteurs auraient dû tenir sur une fraction de ces serveurs en mettant un proxy cache statique devant le CMS pour le soulager de la charge ».

« Ce site a sûrement été développé par une équipe qui ne connaît pas bien Drupal. Il y a eu un manque de professionnalisme dans le développement et l’infrastructure. »

Drupal aurait été un mauvais choix selon lui. « Il n’y a sûrement pas eu d’étude d’architecture. Le choix du CMS doit se faire sur les fonctionnalités. Drupal est parfait pour les communautés. Spip serait plus recommandé pour de la publication pure. »

Les besoins spécifiques de France.fr auraient d’ailleurs dû mener à la création d’un site en partant de zéro, ou du moins à l’utilisation d’un framework, bien plus léger et flexible qu’un CMS préconstruit.

Selon Benjamin Sonntag, la marche à suivre aurait été de calculer le nombre de requêtes par page et leur consommation et d’effectuer des tests de montée en charge sur des serveurs de milieu de gamme.

Une étude du dynamisme du site, une bonne répartition et un système de redondance auraient permis d’éviter ce mauvais lancement et cette catastrophe pour l'image de la France.



Olivier Beaudet, Claranet France : « Acceptable il y a dix ans »

Le président de Claranet France, Olivier Beaudet, parle d’un « problème de préparation. Ça aurait été acceptable il y a dix ans, mais ce sont des choses parfaitement maîtrisées aujourd’hui. Il n’y a aucun choix technique exotique ou nouveau ».

Même si « l’hébergeur a la meilleure connaissance de la charge, [...] le vrai responsable est l’éditeur du contenu. Il est essentiel d’avoir un couple développeur et hébergeur qui se connaisse pour un projet de cette importance. Prendre un couple qui ne se connaît pas, c’est prendre un grand risque ».

Il rejoint Benjamin Sonntag sur la marche à suivre pour les sites statiques à administration en PHP : mettre en avant un cache mis à jour à partir du CMS auquel l’utilisateur ne doit pas avoir accès.

« Pour un site à fort trafic, il faut séparer le plus possible les flux front et back office, ce qui n’est pas natif dans Drupal. Il faut aussi effectuer des tests de montée en charge, ce qui n’a pas dû être fait. »

Dernier point, que France.fr a complètement manqué : le soft launch. « Il faut éviter le lancement en grandes pompes mais démarrer sur une partie de la cible. Le lancement à la planète entière est extrêmement risqué. » Preuve en a été faite.

Arthur Fernandez, Liazo : « Installable en une journée »

Arthur Fernandez, du prestataire de service en disponibilité Liazo, estime que mettre en place une infrastructure adaptée à ce site était pourtant simple pour un professionnel.

« Il n’y avait semble-t-il pas de cache, des serveurs SQL chargés par le front end, peu de sécurité et trop de serveurs. Le choix de Drupal sans mécanisme de cache sérieux est aussi une erreur de débutant. Il aurait fallu construire un proxy cache ou un cache applicatif au-dessus ».

Pour un site statique comme France.fr, il conseille la mise en place de deux sites physiques en redondance pour assurer le « failover », la reprise du trafic d’un site vers l’autre si le premier tombe.

« Sur chaque site, un serveur est dédié au back office qui génère le contenu et le cache. Le cache est aussi transféré sur les trois serveurs frontaux de chaque site. »

« Il faut aussi une protection anti-flood sérieuse, comme pour la sécurité, celle-ci implique de ne laisser au dépourvu aucun des point de la plateforme. »

« Une forte charge peut se répartir de plusieurs manières, notamment via un DNS aléatoire et/ou de manière applicative avec un répartiteur de charge. Lorsque les reverse-proxy/caches qui reçoivent les visiteurs n'ont pas le cache à jour, ils peuvent le charger sur le serveur back end hébergeant le Drupal. »

Pour lui, ce type d'infrastructure « s’installe en une journée, trois pour bien faire ». Le temps n’aurait donc pas été le problème.

Pour Arthur Fernandez, l’hébergeur serait aussi bel et bien en faute. « C’est à l’hébergeur de dire « Non ça ne tiendra pas » et d’assurer la disponibilité. Gérer un cache sur un Drupal n’est pas raisonnable sans ajout applicatif pour une telle audience ».

A titre d’exemple, l’hébergeur associatif Toile-Libre qu’Arthur Fernandez cogère, accueille 550 000 sessions quotidiennes pour les 5 000 utilisateurs hébergés sur ses six serveurs mutualisés.

