Les interfaces de gestion d’un site (ou CMS pour Content Managment System) sont indissociables de la création d’un site Internet. Le gain qu’apporte un CMS est indubitable et il est rare aujourd’hui de produire un site sans faire appel à un de ces systèmes. La question du choix du CMS constitue ainsi un élément structurant pour la suite du projet : il s’agit de la clef de voûte du futur site qui définira les possibilités mais aussi les contraintes et les faiblesses de ce dernier.
Le choix d’un CMS est souvent motivé par les fonctionnalités nécessaires au futur site mais aussi, il faut bien le reconnaitre, par la « mode » du moment ou en tout cas par l’expérience des équipes WEB en charge du projet. Mes collègues le subissent : j’avoue avoir un faible pour SPIP. J’ai découvert ce CMS en 2001 et je l’exploite avec bonheur depuis cette date. Cependant, j’aurai pu avoir des expériences positives avec Joomla mais (heureusement !), j’ai créé une affinité particulière avec la logique de fonctionnement de ce CMS. Toutefois, je ne suis pas resté sur cette love-story et j’ai embrassé d’autres CMS, le travail m’y contraignant. J’ai donc réalisé des projets avec Typo3, Joomla, WordPress, DotClear et Drupal. Drupal justement. Il est considéré comme le CMS-killer, celui qui va imposer sa puissance et devenir le CMS référant… Tout du moins pour ses partisans les plus convaincus (Bruno, si tu nous regardes…).
Mais revenons à nos moutons, le choix d’un CMS pour un site devant faire face à de fortes affluences s’oriente intangiblement vers des systèmes plus lourds comme Typo3 ou, dans notre exemple si après, Drupal. Cependant, j’ai pu observer des sites soutenant des pics de trafics monstrueux et je ne pense pas que le CMS soit dans ces cas là le talon d’Achille. Bien configuré et surtout bien soutenu, j’aurai tendance à affirmer que n’importe quel CMS pourrait absorber un volume important de requêtes. Selon mon expérience, le maître-mot est anticipation. Bref, il existe des solutions graduelles à mettre en place pour se prémunir d’un déni de réponse de votre site. Je les listerai sitôt exposé l’exemple du moment : france.fr
Cet article est en effet né de mon désarroi face au portail France.fr. Lancé le 14 juillet 2010, ce site n’a pas tenu la journée ! Avec 50 000 visites lors de la première journée d’exploitation, le serveur a mis genou à terre. Depuis, le site est fermé : l’équipe WEB en charge de ce projet doit repenser entièrement les accès réalisés par le CMS à la base de donnée. En effet, lors de cette journée d’exploitation, ils se sont aperçu que la logique de construction du site ne correspondait pas à celle des visiteurs, générant ainsi des requêtes croisées peu propices à la réactivité du site. Le volume de visite aidant, le serveur n’a pu faire face à toutes ces tâches.
Sur la toile, le débat contre l’utilisation du CMS pour ce projet fait rage. Les pro-Drupal et les antes ont pourtant eut tendance à arriver au constat suivant : l’équipe WEB en charge du développement du site ont mal pensé ce dernier. Malheureusement, cela semble effectivement être la cause la plus probable. Je profite d’ailleurs de cette occasion pour insister sur le fait que les développeurs WEB doivent impérativement travailler sous la direction d’ergonomes WEB, garants de la conformité de l’architecture des sites avec la réalité qui les attendents (en terme d’utilisation et de sollicitation). Nonobstant, je me souviens bien d’un site développé sans CMS (heu, oui, c’était en 2001 !), proposant seulement 6 pages HTML, avait explosé les serveurs de notre hébergeur qui avait pourtant prévu un pic de trafic à venir. De cette expérience, je tire cette constatation : avec ou sans CMS, avec ou sans serveur surdimensionné, un site à fort trafic doit avoir un système de mise en cache performant comme le site gynécologue tunis . Le « cache » est la résultante du calcul par le CMS des pages constituant le site. Les pages d’un site sous CMS sont créées à partir d’un gabarit et du contenu résidant dans la base de donnée. Aussi, pour obtenir une page, le CMS fait appel à ces deux éléments puis, une fois le calcul réalisé, conserve la page dans un répertoire volatil : le cache. De cette façon, lors de la prochaine requête sur cette page, le CMS n’aura pas à la recalculer mais la délivrera directement à partir de la version calculée dans le cache. Cela prend donc moins de ressource au serveur hébergeant le CMS.
Bien sûr, les CMS ont un système de cache, bien sûr un CMS doit être correctement pensé et configuré, bien sûr un système de caching externe tel CDN coûte cher… Aussi, j’aurai plutôt tendance à dire qu’il faut étager ces solutions pour les activer en fonction des besoins. Bref, anticiper sans vouloir pour autant surdimensionner. Voici deux conseils issus de ma modeste expérience :
Penser, configurer le CMS et le serveur en fonction de son utilisation :
Il convient d’abord de bien penser l’utilisation du site. Quitte, pour les gros projets, à réaliser des maquettes fonctionnelles et faire réagir des utilisateurs via un test. Il n’est pas possible de mettre en cache toutes les requêtes envisageables sur un site à fort contenu (cela saturerai à coup sûr le serveur). Par exemple, des requêtes complexes nécessaires à un formulaire de recherche peuvent générer des pointes d’activité du serveur ralentissant alors l’ensemble des tâches. Une combinaison de critères dans un formulaire de recherche peut mettre en indisponibilité le serveur pendant quelques poignées de secondes. Je l’ai fréquemment constaté notamment sur deux de mes projets d’envergure avec Typo3 comme CMS. Avec une pointes d’activités du serveur, c’est le site entier qui tombe. Donc, il convient de travailler les filtres de recherche par couche. Deux avantages : cela nécessite de se positionner du point de vue utilisateur afin de ne proposer que des champs intelligibles et utiles (et non une liste des critères disponibles dans la BDD) ; cela permet de construire les requêtes serveurs de manière intelligente et donc d’éviter des tirs croisés de données trop importants et des fuites de mémoires.
Prévoir des solutions de montée en gamme :
Si le lien avec BDD est souvent la cause de déni de service lors d’une montée en charge du serveur, cela ne remet pas en question l’utilisation de tel ou tel CMS. En effet, tous les CMS utilisent des procédures de gestion des pages HTML à la volée en provenance d’une base de donnée. Personnellement, je ne pense pas que ce soit le type de CMS qui peut ou ne peut pas accepter de gros trafic, mais plutôt le serveur et l’utilisation ou non d’un système de cache. Voici des solutions a envisager pas ordre d’importance en fonction de l’envergure du site (plus de 30 000 visiteurs/mois) :
– Le serveur sur lequel tourne le CMS est important : entre le mutualisé et les dédiés, le serveur en propre en hosting ou chez un hébergeur web professionnel, une version non graphique tel Linux ou sous Windows, les configurations sont bien différentes. Il convient donc de choisir un serveur dimensionné pour l’audimat prévu du site. Et si possible, toujours opter pour la version supérieure à celle pressentie.
– Lors de pics de connexion prévus (ou espérés !), prévenir l’hébergeur 72h avant afin qu’il puisse surveiller la bande passante et la charge du serveur. Il pourra ainsi à la volée octroyer plus de débit et de ressources serveur au site.
– Configurer le serveur de développement en copie conforme du site de production afin de pouvoir faire une bascule si un problème grave intervient ou une bascule partielle pour partager les requêtes (/ sur le serveur de développement et www sur le serveur de production). Si ce système n’est pas forcément bon pour le référencement, il permet au moins de pouvoir délivrer un service sur un serveur en surchauffe durant quelques heures en attendant d’augmenter la capacité du serveur principal.
– Séparer le back-office du front-office, via des URLs différentes et si possible, sur des serveurs différents.
Au delà de 100.000 visites/mois, il indispensable de prévoir des solutions de caching tel CDN. En démultipliant le cache du CMS sur d’autres serveurs, les systèmes de caching permettent d’avoir des taux de réponse de votre site proche de 100%. Cette solution évite l’utilisation de serveurs redondant (laad balancing) assez onéreux et lourds à maintenir. De plus ce système permet d’ajuster la capacité de réponse d’un site au jour le jour notamment lors du lancement d’une opération.
En guise de conclusion, l’anticipation de la conception à l’exploitation d’un site est le maître mot. Je suis cependant conscient qu’il est souvent difficile de prévoir le succès d’un site et que les solutions envisagées sont coûteuses. Toutefois, il convient selon moi de les évoquer, voire de les prévoir même si l’on ne les utilise finalement pas. Cela permettra de dormir plus sereinement la veille du lancement d’un site à fort trafic.
A bon entendeur… bon courage !
