XtremCache - Cache Varnish

L'outil XtremCache est un outil qui permet d'améliorer la vitesse de chargement de votre site internet grâce à l'activation d'un mécanisme de cache avancé, configuré directement au niveau du serveur web : Varnish.

Varnish est un mécanisme de cache, qui se gère au niveau serveur et qui permet d'améliorer les performances de votre site internet en gardant les pages et ressources générées en mémoire. Cela permet d'éviter toute la partie de traitement dynamique (PHP par exemple) qui sert à générer la page et qui est consommateur en ressources. Les pages sont générées une première fois puis sont gardées en mémoire pour les futures visites.

Varnish est très utilisé sur les sites ayant un trafic important, comme les sites de presse par exemple.

Habituellement cet outil n'est pas proposé sur des offres de type mutualisé car la configuration de l'outil dépend fortement du site internet hébergé et du CMS utilisé. Dans une offre mutualisée, les sites hébergés sont très différents et utilisent des technologies hétérogènes. C'est à cela que sert cet outil : il permet d'activer un cache Varnish, avec une configuration optimisée pour le site internet que vous avez. Les hébergements web varnish sont donc plutôt rares.

Pour comprendre le fonctionnement du système de cache Varnish, il faut d'abord voir comment cela fonctionne sans cache.

Lorsqu'il n'y a pas de cache serveur, voici les différentes étapes qui sont suivies pour l'affichage d'une page

1. Le navigateur web du visiteur demande au serveur une page particulière, dans cet exemple, index.php
2. Le serveur, voyant qu'il s'agit d'une page PHP, va lancer l'exécution de la page PHP pour obtenir une réponse (par exemple, une page HTML)
3. Le moteur PHP va renvoyer la réponse au serveur
4. Le serveur va renvoyer la réponse, la page générée, au visiteur

Lorsque le cache Varnish est activé, Varnish se place devant le serveur web pour intercepter les appels des navigateurs web ainsi que les réponses du serveur web. Pour chaque appel, il va regarder si la ressource demandée est en cache ou s'il faut transmettre la demande au serveur web. Pour chaque réponse du serveur web, il va regarder s'il est possible de la placer en cache.

Avec Varnish, l'idée est d'éviter toute la partie de génération de la page au niveau du serveur, par exemple, dans le cas d'un site conçu en PHP, on cherche à éviter tous les traitements PHP car c'est ce qui consomme des ressources et c'est également ce qui est le plus lent (comparativement aux autres traitements effectués).

Lorsque le cache Varnish est activé, voici ce qu'il se passe (de manière simplifiée) :

• Le navigateur web du visiteur demande une page particulière. Cette demande arrive sur le cache Varnish dans un premier temps, plutôt que d'arriver sur le serveur web.
• Varnish regarde si la ressource est en cache
  • Si oui, alors Varnish renvoie la réponse qu'il a en cache au navigateur web (sur l'image étape 3 en vert et 4)
  • Si non, alors Varnish transmet la demande au serveur web pour avoir la page à renvoyer (sur l'image, étape 3 en rouge)
    • Le serveur web constate qu'il s'agit d'une page PHP donc lance le traitement PHP (étape 4)
    • Le moteur PHP retourne la page générée au serveur web (étape 5)
    • Le serveur web retourne la page générée à Varnish, Varnish regarde si cette page peut être mise en cache ou non (étape 6)
      • Si oui, Varnish place la page en cache puis retourne la réponse au visiteur (étape 7)
      • Si non, Varnish retourne la réponse sans la mettre en cache (étape 7)

On constate donc que lorsqu'une page est en cache, plusieurs étapes sont évitées :

• L'appel vers le serveur web
• Toute la partie de traitement PHP utilisée pour générer la page. Dans cet exemple, le langage de programmation pour la création du site est PHP mais le principe est identique pour d'autres langages (Python, Ruby, etc…)

Le cache Varnish étant directement en mémoire RAM, ce qu'il y a de plus rapide, la page est servie très rapidement.

Afin d'avoir un bon ratio de HIT/MISS, c'est-à-dire le ratio des pages servies depuis le cache (HIT) par rapport aux pages qui ne sont pas servies depuis le cache (MISS), il est important de comprendre comment Varnish s'y prend pour déterminer si une page peut être gardée en mémoire (cache) ou non.

Toutes les pages ne peuvent pas être conservées en mémoire cache. Certaines pages sont générées de manière totalement dynamique et il n'est pas pertinent de garder cela en cache. Par exemple, des pages qui sont générées en fonction d'un utilisateur connecté sur le site internet. Le contenu dépendant de l'utilisateur connecté, il n'est pas possible de garder cette page en mémoire pour la transmettre à d'autres visiteurs.

Voici les cas où Varnish ne peut pas garder en mémoire une page donnée :

• Toutes les requêtes différentes des requêtes HEAD/GET ne sont pas mises en cache. Dans le cas d'une requête POST, la page générée peut très probablement varier en fonction du contenu du POST.
• Si un cookie, qui n'est pas dans la liste des cookies à exclure, est présent. La page générée peut varier en fonction de la valeur de certains cookies, un cookie peut contenir la langue de préférence du site par exemple.
• Certaines parties ou fichiers des sites spécifiques, par exemple, dans le cas de WordPress, le dossier wp-admin va être exclu du cache
• Toutes les requêtes AJAX, que cela soit GET ou POST
• Les pages ayant des headers “Authorization” ou “Authenticate”, ce sont des pages privées et protégées par des authentifications (authentification basique avec .htacess par exemple)
• Le serveur va également respecter la politique de cache renvoyée par le site internet, notamment via les header cache-control par exemple

C'est en partie dû à l'algorithme qui sert à déterminer si une page peut être en cache ou non, que la configuration de Varnish dépend fortement du type de CMS utilisé. C'est pour cette raison qu'il y a différents templates de cache proposés, ce sont des configurations adaptées au CMS utilisé par votre site internet.

Par exemple, dans le cas de WordPress, il y aura des règles pour exclure le dossier wp-admin, dans le cas de Joomla, ça sera administrator, etc.

L'outil XtremCache est découpé en plusieurs parties / sous outils. Il y a également un vocabulaire, spécifique à l'outil et au mécanisme de cache Varnish qu'il faut connaître pour comprendre l'outil.

Lorsqu'on se rend sur l'outil, la page d'accueil va lister tous les domaines configurés sur l'hébergement. Pour le moment, seul les domaines supplémentaires et le domaine principal sont listés.

Différentes actions sont possibles pour chaque nom de domaine listé :

• Le cache n'est pas actif sur le domaine
  • Le bouton Activer le cache lance l'outil permettant de configurer un cache sur le nom de domaine concerné
• Le cache est actif sur le domaine
  • Le bouton Vérifier affiche un outil qui permet de vérifier si le cache est bien actif sur le site ou une page en particulier. C'est un outil de debug
  • Le bouton Vider le cache permet de vider l'intégralité du cache associé au domaine
  • Le bouton Désactiver temporairement permet de désactiver temporairement le cache, le temps de faire un test par exemple. Le cache peut être réactivé très rapidement, sans coupure.
  • Le bouton Désactiver totalement enlève toutes les personnalisations effectuées sur le domaine, comme le cache mais également ipxtender (les deux outils étant compatibles l'un avec l'autre)
• Le cache est désactivé temporairement sur le domaine
  • Les boutons, Vérifier et Désactiver totalement font la même chose que lorsque le cache est actif (cf. ci-dessus)
  • Le bouton Réactiver le cache permet de réactiver le cache pour le domaine concerné. La réactivation est assez rapide.

L'outil xtremCache est compatible avec l'outil ipXtender (cf. documentation de l'outil ipXtender). La colonne Informations permet de voir cela, cette colonne affiche les personnalisations effectuées sur le nom de domaine, il y a plusieurs cas possibles :

• Cache (actif) : indique que le cache xtremCache est actif pour le domaine mais pas ipXtender
• Cache (inactif) : le cache xtremCache a été désactivé temporairement pour le nom de domaine. L'outil ipXtender n'est pas actif pour le domaine
• Cache (actif) + ipXtender : le domaine pointe sur l'adresse IP sélectionnée dans ipXtender et le cache xtremCache est actif
• Cache (inactif) + ipXtender : le domaine pointe vers l'adresse IP sélectionnée dans ipXtender mais le cache xtremCache est désactivé (temporairement)
• ipXtender : ipXtender est actif donc le domaine pointe vers une adresse ip personnalisée, il n'y a pas de cache xtremCache actif
• non personnalisé : c'est la configuration par défaut d'un domaine configuré sur l'hébergement, il n'y a pas de personnalisation ipXtender ou xtremCache

La page d'activation de cache permet d'activer un cache sur un nom de domaine particulier et de choisir puis personnaliser la configuration en fonction du site internet.

Dans la page d'activation du cache Varnish, à cet instant, il est possible de configurer deux éléments :

• Le Template : sert à définir quelle est la configuration Varnish à activer pour le nom de domaine. Plusieurs templates sont proposés, la plupart correspondent à un CMS ou Framwork particulier. Le bouton de détection automatique permet de choisir le template automatiquement, l'outil va essayer de détecter le CMS utilisé puis remplir le champs en fonction du résultat trouvé.
• Nom du cookie : sert à définir une liste de cookie à ignorer, pour améliorer la mise en cache et le ratio HIT/MISS comme vu dans la partie cachable ou pas ?

L'outil est compatible avec ipXtender, en fonction de la configuration détectée, l'adresse IP d'ipXtender est conservée :

• Le domaine n'est pas sur ipXtender : l'adresse IP associée au domaine sera 109.234.164.18
• Le domaine est sur ipXtender : l'adresse IP sélectionnée dans ipXtender est conservée

Lorsque la configuration est terminée, un résumé des opérations effectuées s'affiche. Il est conseillé de le vérifier pour contrôler l'absence d'erreurs. La configuration modifiant l'adresse IP associée au domaine, nous vous recommandons de tester le bon fonctionnement de vos comptes emails également (l'outil effectuera une vérification, mais c'est toujours mieux de le vérifier vous-même également).

L'outil Vérifier permet de faire des requêtes sur la page d'accueil du site internet ou une page spécifique afin de vérifier si la page en question est dans le cache.

Pour cela, l'outil va faire deux requêtes :

• une première requête HEAD pour s'assurer que la page a été visitée au moins une fois (afin de lui laisser une chance d'être dans le cache)
• une deuxième requête, de type GET pour vérifier si la page servie vient du cache ou non

L'outil liste aussi les cookies détectés, cela peut être utile pour ajuster les règles de cache.

L'outil va afficher un rapport similaire au rapport suivant :

Le rapport contient plusieurs éléments :

• La première phrase du rapport indique si la page a été servie depuis le cache ou non
• La deuxième phrase du rapport indique si la page a défini des cookies, si c'est le cas, ces derniers sont affichés (nom : valeur)
• Ensuite, s'affichent les entêtes (headers) renvoyés par la réponse du serveur, certains headers sont plus intéressants que d'autres
  • X-Storage : affiche la stratégie de cache utilisée pour la ressource. Les pages et certains fichiers statiques sont stockés en mémoire RAM (memory), d'autres types de ressources peuvent être stockés sur un cache SSD NVMe local (les images)
  • X-Cache : peut contenir les valeurs HIT, qui signifie que la page a été servie depuis le cache, ou MISS qui signifie que la page n'a pas été servie depuis le cache
  • X-Cache-Hits : affiche le nombre de fois que la ressource a été chargée depuis le cache

Cet outil permet de vider le cache associé au domaine. Cette option vide l'intégralité du cache associé au domaine.

Un message s'affiche lorsque le cache est vidé :

Cet outil permet de désactiver temporairement le cache associé au site internet. La désactivation temporaire du cache est assez rapide à être prise en compte et n'engendre pas de coupure du site internet.

Contrairement à la désactivation totale, la désactivation temporaire ne change pas l'adresse IP liée au domaine donc il n'y a pas de coupure/délai de propagation DNS à prévoir.

Cette option est adaptée pour faire des tests, par exemple, si vous soupçonnez que le cache peut être à l'origine d'un comportement anormal sur votre site.

Un rapport s'affiche lorsque le cache est désactivé temporairement sur le site internet :

La désactivation totale remet à zéro l'ensemble des configurations effectuées sur le nom de domaine, c'est-à-dire les configurations de cache mais également les configurations ipXtender.

En résumé, cela permet de remettre le domaine à son état d'origine.

Un message s'affiche suite à la désactivation totale :

Cette option permet de réactiver un cache, qui a été précédemment désactivé temporairement. La réactivation du cache est assez rapide à être prise en compte. Il n'y a pas de perturbation à prévoir, l'adresse IP liée au domaine n'est pas changée.

Un message s'affiche suite à la réactivation du cache :

Les Templates correspondent aux configurations de cache disponibles, ces configurations là sont gérées au niveau du serveur et sont maintenues par o2switch.

Les Templates définissent les règles de caches. Le rôle d'un template est d'optimiser le ratio HIT/MISS (autrement dit, avoir le plus d'éléments possible en cache) pour une technologie de création de site donnée, tout en évitant les erreurs.

Par exemple, un template va :

• définir des listes d'URL exclues comme les pages d'administrations, pour éviter les erreurs
• définir une liste de cookies à ignorer, pour améliorer la mise en cache
• faire des exceptions sur des extensions et thèmes qui peuvent être utilisés et à l'origine de problèmes

Plusieurs templates sont proposés, Vous en trouverez certains adaptés aux CMS les plus utilisés et d'autres plus génériques qui peuvent être utilisés pour des sites “fait main”.

Les pages suivants donnent plus d'indications sur ce que font ces templates :

• WordPress
• Fichiers statiques uniquement
• Joomla
• PHP générique
• PrestaShop
• Symfony

A venir dans un futur proche : Magento, WordPress + WooCommerce, Joomla + Hikashop

Il existe différentes manières de purger le cache :

• depuis l'outil pour vider le cache dans cPanel
• manuellement ou avec un script PHP en effectuant des requêtes de purges
• (à venir) depuis une extension WordPress

Dans cette partie, nous allons voir toutes les méthodes de purge de cache proposées à l'exception de l'outil proposé dans cPanel qui est expliqué dans la partie ci-dessus.

Pour vider le cache, il faut envoyer une requête de type PURGE sur la page à purger (c'est-à-dire la page pour laquelle nous souhaitons vider le cache).

Donc par exemple, en utilisant curl cela donne la requête suivante :

curl -X 'PURGE' mon-dev.xyz

La requête ci-dessus ne purge que la page d'accueil du site internet, c'est la forme la plus simple de purge proposée. Il est également possible de purger une page spécifique, par exemple :

curl -X 'PURGE' mon-dev.xyz/ma-page

Si le domaine se trouve derrière une solution comme Cloudflare (il n'est pas recommandé de mixer les deux) ou si le domaine ne pointe pas directement vers l'adresse IP du cache (pour une raison ou pour une autre) alors il faut générer l'entête host manuellement et indiquer l'adresse IP du serveur de cache. Ce cas est très rare et c'est un usage avancé, par exemple :

# pour connaitre l'adresse IP du serveur de cache
dig +short @ns1.o2switch.net mon-dev.xyz
# requête de purge en précisant l'host manuellement
curl -X 'PURGE' -H 'Host:mon-dev.xyz' http://109.234.164.18/ma-page

Le mécanisme de cache supporte un autre type de purge, les purges en utilisant une regex. Cette méthode de purge est très pratique car elle permet de vider le cache de manière rapide et précise :

• il est possible de vider tout le cache lié au domaine en une seule requête
• ou de vider le cache de certains types de fichiers spécifiques ou d'adresses, par exemple, tous les fichiers png

Pour utiliser cette méthode, il faut faire une requête de purge comme vu dans les exemples précédents puis ajouter une entête X-Purge-Regex qui contient l'expression régulière (regex) à utiliser pour vider le cache.

Par exemple, pour vider tout le cache associé au domaine :

curl -X 'PURGE' -H 'X-Purge-Regex:.*' mon-dev.xyz

Pour ne vider que le cache du répertoire wp-content/uploads (donc les images pour WordPress) :

curl -X 'PURGE' -H 'X-Purge-Regex:wp-content/uploads/.*' mon-dev.xyz

Pour ne vider que les images se terminant par .jpg:

curl -X 'PURGE' -H 'X-Purge-Regex:.*\.jpg$' mon-dev.xyz

L'outil retourne un code HTTP 200 si la purge s'est bien passée.

L'outil affiche également un retour HTML simple, le message varie légèrement si la méthode par regex est utilisée :

<!-- Retour lorsque c'est une purge simple -->
<!DOCTYPE html>
<html>
  <head>
    <title>200 Purged.</title>
  </head>
  <body>
    <h1>Error 200 Purged.</h1>
    <p>Purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 62717987</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>
 
<!-- Retour lorsque la méthode REGEX est utilisée -->
<!DOCTYPE html>
<html>
  <head>
    <title>200 Purged using the Purge Regex Method</title>
  </head>
  <body>
    <h1>Error 200 Purged using the Purge Regex Method</h1>
    <p>Purged using the Purge Regex Method</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 62849276</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>

L'erreur 502 peut venir de plusieurs raisons mais si l'erreur s'affiche suite à l'activation du cache, la désactivation totale du cache ou l'activation d'ipXtender, cela signifie l'une des trois choses suivantes :

• L'erreur est liée au délai de propagation DNS. Toutes les opérations listées ci-dessus change l'adresse IP associée au domaine. Ce changement d'IP peut prendre du temps, tant que la bonne adresse IP n'est pas prise en compte, vous risquez d'avoir une erreur de type HTTP 502, cela est normal (temporairement du moins)
• Le nom de domaine ne pointe pas vers la bonne adresse IP. Cela peut arriver si vous utilisez des serveurs DNS tiers, la mise à jour de l'IP associée au domaine n'est pas automatique. Dans ce cas, il faut configurer la bonne adresse IP (listée dans la page d'accueil de l'outil) dans votre zone DNS
• Peu probable, même erreur que précédemment, l'adresse IP ne pointe pas au bon endroit mais la cause est différente. Cela peut être lié à votre environnement local, par exemple, si vous avez fait des tests en modifiant votre ficher hosts

Pour le délai de propagation DNS, vous ne pouvez pas faire grand chose, sauf vider votre cache DNS local. Cela peut vous faire gagner quelques heures mais ce n'est pas forcément suffisant ! Pour vider votre cache DNS local, vous pouvez suivre la procédure expliquée sur la page de l'outil ipXtender.

Pour vérifier si le domaine pointe vers la bonne adresse IP, si vous disposez de la ligne de commande et de la commande dig, vous pouvez lancer les deux commandes suivantes :

# l'ip côté o2switch, celle du cache donc 
dig +short @ns1.o2switch.net mon-domaine.fr
# l'ip depuis un DNS tiers, celui de Google dans ce cas
dig +short @8.8.8.8 mon-domaine.fr
# les deux IPs doivent être identiques, si elles sont différentes, il y a un problème

Ou vous pouvez utiliser un outil en ligne comme Dig sur Kloth.net :

Sur l'outil en ligne de Kloth.net, il faut faire deux requêtes :

• la première avec locahost ou 8.8.8.8 comme adresse de serveur, pour trouver l'adresse IP associée au domaine
• la deuxième avec ns1.o2switch.net comme adresse de serveur DNS pour comparer cela avec l'adresse IP que devrait avoir le site internet

Les deux IPs devraient être identiques, sinon cela signifie qu'il y a probablement un problème.

Certaines configurations de .htaccess peuvent générer des boucles de redirections à l'infini et empêcher le chargement du site internet.

Généralement, cela arrive lorsque les règles du .htaccess vérifient si la requête est en HTTPS ou non en se basant sur le port d'écoute du serveur web. Voici un exemple de règle :

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Le code ci-dessus ne fonctionne pas à tous les coups car cela suppose que le serveur web utilise le port 80 pour le traitement d'une requête HTTP, c'est souvent vrai mais il y a certains cas où ce n'est pas le cas.

Cette méthode de détection du https ne fonctionnera pas car le port 80 n'est jamais utilisé par le serveur web apache de nos hébergements, ceci est lié à la manière dont sont configurés les serveurs.

Ce code peut être remplacé par l'équivalent suivant qui fonctionne correctement :

RewriteEngine On 
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Dans certains cas, l'outil xtremCache ou même ipXtender ne détecte pas correctement le certificat SSL lié au nom de domaine à personnaliser.

Cela arrive lorsque le certificat SSL n'est pas installé correctement sur l'hébergement.

Cela s'affiche dans le rapport des actions effectuées pour faire la configuration, il y a une ligne indiquant qu'aucun SSL n'est détecté. Si vous savez que c'est une erreur et qu'un certificat SSL est bien actif, vous pouvez corriger cela en forçant la réinstallation du certificat SSL puis en relançant l'outil d'activation du cache ou de changement d'ip.

Cela peut être fait de deux manières différentes :

• Depuis l'outil Let's Encrypt qui se trouve dans la catégorie sécurité de cPanel : il suffit de cliquer sur réinstaller
• Depuis l'outil SSL/TLS de cPanel, toujours dans la catégorie sécurité : il faut cliquer sur Gérer les sites SSL puis sélectionner le domaine, cliquer sur remplir automatiquement puis valider.

N'activez pas Cloudflare en complément d'xtremCache, cela est inutile et contre productif. En faisant cela, vous cumulez plusieurs niveaux de caches et cela va bloquer le mécanisme interne de purge d'xtremcache.

Au niveau d'xtremCache il n'y a pas de réglage de compatibilité avec CloudFlare. Il faut activer l'une ou l'autre de ces technologies mais pas les deux à la fois. Testez les deux, choisissez ce qui vous convient le mieux.

XtremCache n'est pas compatible avec les sous-domaines, vous ne pourrez pas l'activer dessus.

26/08/2021

• Mise à jour interne de l'outil
• Quelques changements dans l'affichage + mise en place de d'ajax
• Simplification de l'outil : clé de purge enlevée, compatibilité avec des plugins de caches courant à venir
• Compatibilité avec les règles de sécurités personnalisées de TigerProtect

07/05/2020

• Mise à jour pour rendre l'activation du cache beaucoup plus rapide depuis cPanel
• Changement interne à la gestion du cache

08/03/2019

• Mise à jour de l'outil pour l'intégrer avec lscache (lscache & xtremcache étant incompatibles l'un avec l'autre)
• Correction d'un bug sur le vérification du cache sur la version sans les “www” du domaine
• Amélioration de la détection du SSL lors de l'activation et le renouvellement des certificats
• Amélioration de l'ajax de l'outil

13/11/2018

• Grosse mise à jour de l'outil qui corrige plusieurs bug et apporte des nouvelles fonctionnalités
• Amélioration de la détection du SSL lors de l'activation de l'outil
• Ajout d'une option pour choisir les www ou non dans l'outil de test de cache
• Simplification de l'ensemble des messages renvoyés par l'outil
• L'outil permettant de vider le cache vide le cache pour les 4 versions du domaine, c'est-à-dire : http, http + www, https, https + www
• Rectification d'un bug concernant l'exclusion des cookies, c'est bien pris en compte également. Les cookies avec un _ sont autorisés à présent.
• Un bug affichait les sous-domaines comme configurables avec l'outil de cache alors que cela n'est pas encore possible à cause d'une limitation de cPanel
• Ajout d'une option permettant d'ignorer certains headers renvoyés (à tort) par des sites internet, comme cache-control:max-age=0. Permet de forcer le cache.
• Modification de l'infrastructure pour éviter le problème des redirections infinies et des règles de redirections dans les .htaccess invalides.
• Code permettant de gérer les hooks cPanel pour la mise à jour de certificat SSL plus robuste
• Changement de méthode de gestion au niveau de Varnish : permet une prise en compte beaucoup plus rapide. Le temps de chargement est fortement diminué, pour passer de plusieurs minutes à 20-30 secondes à présent. L'activation / désactivation / réactivation est beaucoup plus rapide et flexible à présent.
• Mise à jour de l'UX (breadcrumb)
• Correction de bug en rapport avec ipxtender dans des cas très spécifiques de désactivation/réactivation du cache

05/09/2018

• Mise à jour qui corrige quelques bugs en rapport avec les erreurs E010, E012
• Amélioration de l'ux du loader de chargement
• Mise à jour des templates de cache
• Correction d'un bug concernant l'adresse IP du visiteur qui est remontée dans les logs de connexion

06/06/2018

• Mise en place de la version 1 de l'outil de cache