France.fr, pourquoi un tel fiasco ?

En jetant un œil sur les actualités de zdnet j’ai été sidéré par le contenu de l’article France.fr : « On est dans le domaine du jamais vu », selon les experts de l’hébergement. Info relayée sur d’autre sites tels que 20minutes (Le site France.fr toujours hors-service 24 heures après son ouverture) ou encore ITespresso.fr.
Analysons le contenu des ces articles, et de la page d’accueil du site france.fr :
L’équipe avoue être confrontée à un problème de serveur – ou plutôt de serveurs – et à des défaillances technologiques.
Les commentaires des divers analystes externes font état de mauvais choix concernant la plateforme logicielle (Drupal), de serveurs mal configurés, du manque de connaissances techniques des équipes en charge du développement, et j’en passe.
Qu’en est-il réellement ? Probablement nous ne connaîtrons jamais le fin mot de l’histoire, la ou les sociétés incriminées ne souhaitant certainement pas communiquer sur ce fiasco.
Quoi qu’il en soit, certains points méritent d’être soulignés :

• Les sommes avancées pour ce contrat (1,6 million d’euros, dont la moitié est à priori déjà dépensée) sont exorbitantes et sans commune mesure avec le coût réel de développement d’un site statique. Quel critère a prévalu pour l’attribution du contrat ? Une rencontre dans un club huppé ? Le costume italien - sur mesure - très chic et si seyant du « directeur adjoint chargé des relations publiques » ? La façade verre et acier au cœur du VIIIe de l’agence de communication ? Ou les compétences réelles de l’équipe chargée du développement ? Le dernier club privé n’est pas le lieu idéal pour choisir une SSII ou une web agency. On y trouve généralement plus de dandies soucieux d’exhiber leur dernier accessoire bling-bling que de geeks dévoués à leur métier.
• Le choix d’une plateforme logicielle (framework, CMS, moteur de templates, base de données, serveurs applicatifs…) se fait en fonction de l’application à développer et des compétences réelles de l’équipe en charge du développement, et non en fonction d’une mode ou des préférences affectives d’un décideur.
• Un framework (ou un CMS) aussi bien conçu soit-il, n’est jamais qu’une base de développement. Il est souvent nécessaire de l’adapter aux besoins propres à l’application développée.
• Un framework (ou un CMS) aussi bien conçu soit-il, est un outil complexe que l’on ne met pas entre les mains de développeurs ne l’ayant pas déjà pratiqué, tout au moins sans encadrement sérieux.
• La montée en puissance des serveurs ne suffit pas à compenser une application mal pensée ou mal développée. Utiliser de bonnes pratiques et optimiser / profiler le code produit s’avère indispensable sur des projets critiques, que ce soit en termes d’audience ou de fiabilité.
• Le test unitaire n’est pas la panacée. Sans tests fonctionnels et sans profilage, le test unitaire est… inutile.
• Les décideurs (directeurs et chefs de projet) se doivent de se tenir constamment informés de l’actualité technologique. Il y a d’ailleurs une expression toute faite pour cette activité : la veille technologique, et il est peu recommandé de s’en occuper entre deux cocktails.
• Le freelance appelé à la rescousse la veille de la première livraison n’est pas un faiseur de miracle. Économisez sur les séminaires aux Maldives plutôt que sur la durée de mission et le tarif payé à ce prestataire.

Ces quelques principes simples auraient sans aucun doute permis le développement d’un site fluide qui ne serait pas tombé, même avec des pics de fréquentation nettement supérieurs à ceux enregistrés. Quelques solutions qui auraient pu être envisagées :

• opter pour un serveur web alternatif : NGINX par exemple, est un serveur pensé pour résoudre le problème des C10K. Vous trouverez des informations complémentaires sur NGINX sur le Wiki officiel et dans l’article Installer NGINX, PHP5-FPM, Xcache et MySQL sur une Debian Lenny.
• compiler soi-même PHP en n’incluant que les extensions nécessaires à l’application, en l’optimisant pour un processeur, avec un niveau d’optimisation de compilation supérieur, via la variable d’environnement CFLAGS.
• développer une extension PHP en C peut être une alternative intéressante dans le cas de traitements lourds récurrents. Cette solution a un coût, n’est pas adaptée à tous les hébergements ni à toutes les problématiques, mais peut alléger sensiblement la charge du serveur, avec un gain pouvant atteindre 35%. Des outils open source tels que rphp ou PHC permettent de créer une extension à partir du code PHP natif.
• l’utilisation d’un cache d’opcode tel que Xcache ou eAccelerator peut également amener un gain de performances non négligeable.
• Facebook, site à très fort trafic s’il en est, a mis à disposition de tous son compilateur PHP / C++ hiphop-php. Compilateur qui peut d’ailleurs être couplé à NGINX comme le montre l’article Using nginx as front server to HipHop.
• pour un site statique à fort trafic, pourquoi ne pas développer un framework ultra-léger, sur-mesure, optimisé, couplé à un moteur de templates tel que SMARTY ?

Dernier point à prendre en considération : tout ce que veut le client n’est pas forcément possible dans un temps et un budget définis. Au prestataire de le faire entendre au client.
Bien sûr, le client final, lui, se soucie fort peu des technologies mises en œuvre pour réaliser le projet, seul le résultat - et le prix parfois - importent pour lui. A lui de choisir le prestataire qui saura le conseiller et l’accompagner tout au long de son projet.
D’autre part, il est facile de critiquer et de dire à posteriori « j’aurais fais mieux », même si - pour ma part - les conseils vus plus haut sont ceux que je donne généralement à mes clients et prospects. De là à dire qu’ils m’écoutent…

Tweet #WordPress Tweeter Suivre @pcescato