Demander un devis
Accueil/Blog/Installer et sécuriser Matomo auto-hébergé sur un serveur LiteSpeed (ServerAvatar)

Installer et sécuriser Matomo auto-hébergé sur un serveur LiteSpeed (ServerAvatar)

Grands formats 05/12/20258 min de lecture

Dernière mise à jour : septembre 2026

Google Analytics est gratuit — en échange des données de navigation de tous les visiteurs du site, envoyées aux serveurs de Google, traitées selon ses propres règles, et soumises à une législation qui n’est pas celle de l’Union européenne. Pour un site WordPress professionnel soumis au RGPD, c’est un compromis que de plus en plus de propriétaires de sites refusent de faire.

Matomo est l’alternative la plus mature : open source, fonctionnellement comparable à GA4 pour l’essentiel des besoins, et surtout auto-hébergeable — les données restent sur le serveur, sous le contrôle du propriétaire du site. Mais sur un stack OpenLiteSpeed + ServerAvatar, l’installation par défaut laisse des trous de sécurité et des problèmes de performance que ce guide corrige point par point.

Pré-requis

Avant de commencer :

  • Un serveur avec OpenLiteSpeed (par exemple via ServerAvatar)
  • PHP 8.2 ou supérieur (8.3 recommandé — les versions antérieures sont en fin de vie ou ne reçoivent plus que les correctifs de sécurité critiques)
  • MySQL ou MariaDB
  • Un sous-domaine dédié, par exemple analytics.mon-domaine.fr
  • Accès SSH et accès à la base de données (phpMyAdmin ou ligne de commande)

Installation de Matomo sur le serveur

Créer le site dans ServerAvatar

Dans ServerAvatar, créez un nouveau site ou ajoutez un domaine :

  • Domaine : analytics.mon-domaine.fr
  • Dossier racine : /home/UTILISATEUR/analytics/public_html

Activez le SSL Let’s Encrypt pour ce domaine.

Téléchargement et déploiement

En SSH sur le serveur :

cd /home/UTILISATEUR/analytics/public_html

# Télécharger la dernière version
wget https://builds.matomo.org/matomo.zip

# Décompresser
unzip matomo.zip
mv matomo/* .
mv matomo/.* . 2>/dev/null || true
rmdir matomo
rm matomo.zip

Attribuer les bons droits :

chown -R UTILISATEUR:UTILISATEUR /home/UTILISATEUR/analytics/public_html

Lancer l’installateur web

Ouvrir https://analytics.mon-domaine.fr dans le navigateur et suivre les étapes : vérification du système, configuration de la base de données, création du super administrateur, ajout du premier site à suivre.

À ce stade, Matomo est installé mais la vérification du système affichera probablement des avertissements — surtout sur OpenLiteSpeed, qui ne gère pas les fichiers .htaccess de la même manière qu’Apache.

Corriger les alertes de sécurité sur OpenLiteSpeed

Par défaut, Matomo signale plusieurs fichiers et répertoires accessibles publiquement qui ne devraient pas l’être :

  • config/config.ini.php — contient les identifiants de base de données
  • tmp/ — répertoire temporaire avec des données de session
  • lang/en.json — fichier de langue qui ne devrait pas être exposé

Sur un serveur Apache, Matomo se repose sur des fichiers .htaccess intégrés. Avec OpenLiteSpeed, il faut s’assurer que ces fichiers sont pris en compte — et ajouter des règles si nécessaire.

Protéger config, tmp et lang via .htaccess

Dans le dossier racine de Matomo :

cd /home/UTILISATEUR/analytics/public_html
nano .htaccess

Ajouter ou compléter avec :

RewriteEngine On

# Bloque l'accès au répertoire config/
RewriteRule ^config/.*$ - [F,L]

# Bloque l'accès HTTP à tmp/
RewriteRule ^tmp/.*$ - [F,L]

# Bloque l'accès au fichier de langue sensible
RewriteRule ^lang/en\.json$ - [F,L]

Tester depuis une machine externe :

curl -I https://analytics.mon-domaine.fr/config/config.ini.php
curl -I https://analytics.mon-domaine.fr/tmp/
curl -I https://analytics.mon-domaine.fr/lang/en.json

Chaque requête doit retourner un HTTP 403. Si le serveur renvoie un 200, vérifier que le paramètre autoLoadHtaccess est activé dans la configuration du vhost OpenLiteSpeed.

Retourner ensuite dans Matomo → Administration → Système → Vérification du système : les sections « Répertoires privés requis » et « Répertoires privés recommandés » doivent passer au vert.

Forcer HTTPS dans Matomo

Même si le domaine est déjà en HTTPS via Let’s Encrypt, Matomo doit être configuré pour forcer le protocole sécurisé dans sa propre logique interne.

Éditer le fichier de configuration :

nano /home/UTILISATEUR/analytics/public_html/config/config.ini.php

Dans la section [General], ajouter ou vérifier :

[General]
force_ssl = 1
assume_secure_protocol = 1

Matomo redirigera désormais vers HTTPS et considérera toutes les URL comme sécurisées — ce qui élimine les avertissements de contenu mixte dans les rapports.

Mettre en place le cron d’archivage

Par défaut, Matomo calcule les rapports au moment où quelqu’un consulte l’interface. Sur un site à trafic modéré, c’est acceptable. Sur plusieurs sites ou avec un volume de données conséquent, ça ralentit l’interface et génère des pics de charge imprévisibles.

La solution : pré-calculer les rapports via un cron qui tourne en arrière-plan.

Tester la commande d’archivage

cd /home/UTILISATEUR/analytics/public_html
/usr/bin/php console core:archive --url=https://analytics.mon-domaine.fr/

Exécuter cette commande une fois en SSH pour vérifier qu’elle s’exécute sans erreur avant de la planifier.

Créer la tâche cron dans ServerAvatar

Dans ServerAvatar, ajouter un cron job pour l’utilisateur du site, avec une fréquence adaptée au volume de données (toutes les heures est un bon point de départ) :

5 * * * * /usr/bin/php /home/UTILISATEUR/analytics/public_html/console core:archive --url=https://analytics.mon-domaine.fr/ > /home/UTILISATEUR/matomo-archive.log 2>&1

Le 5 * * * * lance l’archivage à la 5e minute de chaque heure. Le fichier matomo-archive.log permet de diagnostiquer les erreurs éventuelles.

Désactiver l’archivage via le navigateur

Dans Matomo → Administration → Paramètres généraux → section « Archiver les rapports » : désactiver l’archivage déclenché par les visites et indiquer que les rapports sont archivés via la ligne de commande (cron). L’interface sera plus réactive — les rapports sont déjà pré-calculés quand on les consulte.

Optimiser les performances MySQL (optionnel)

Dans la vérification du système, Matomo peut afficher un avertissement sur LOAD DATA INFILE. Ce paramètre MySQL accélère l’archivage en permettant le chargement de données en masse. Ce n’est pas indispensable — Matomo fonctionne sans — mais sur des sites à gros trafic (plus de 100 000 pages vues par mois), le gain de temps est notable.

Activer local_infile côté MySQL

Éditer la configuration MySQL :

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Ajouter dans la section [mysqld] :

[mysqld]
local_infile = 1

Redémarrer MySQL et vérifier :

sudo systemctl restart mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'local_infile';"

Le résultat doit afficher ON.

Accorder le privilège FILE à l’utilisateur Matomo

Ce privilège permet à l’utilisateur MySQL de Matomo d’accéder à des fichiers côté serveur via MySQL. Ne l’accorder que sur un environnement maîtrisé — c’est un point de sécurité serveur à évaluer en connaissance de cause.

GRANT FILE ON *.* TO 'UTILISATEUR_MATOMO'@'localhost';
FLUSH PRIVILEGES;

Relancer l’archivage pour vérifier que l’avertissement disparaît dans la vérification du système.

Vérifications finales

À la fin de cette procédure, le serveur doit répondre aux critères suivants :

  • Matomo accessible uniquement en HTTPS
  • config/config.ini.php inaccessible depuis le web (HTTP 403)
  • tmp/ et lang/en.json protégés
  • Cron d’archivage en place et fonctionnel
  • Vérification du système au vert (avec éventuellement le warning LOAD DATA INFILE si non activé — ce n’est pas bloquant)

Une fois Matomo en place, les données de fréquentation restent sur le serveur, les rapports sont générés automatiquement, et la conformité RGPD ne dépend plus d’un service tiers. C’est aussi une donnée de moins qui transite par un intermédiaire — et un argument concret dans le cadre d’une stratégie de maintenance qui prend en compte la souveraineté des données.

FAQ

Matomo auto-hébergé est-il vraiment conforme au RGPD sans bandeau de consentement ?

Matomo peut être configuré pour fonctionner sans consentement préalable, à condition de respecter plusieurs critères : anonymisation des adresses IP activée, pas de partage des données avec des tiers, données hébergées dans l’UE, durée de conservation limitée. La CNIL reconnaît Matomo comme un outil pouvant bénéficier de l’exemption de consentement — mais la configuration par défaut ne suffit pas. Il faut activer explicitement l’anonymisation IP et désactiver les fonctionnalités de tracking avancé (fingerprinting, User ID) pour rester dans le périmètre de l’exemption.

Peut-on suivre plusieurs sites WordPress avec une seule instance Matomo ?

Oui. Matomo gère nativement plusieurs sites depuis une seule installation. Chaque site reçoit un identifiant unique et un code de suivi distinct. Les rapports sont séparés par site, et les droits d’accès peuvent être configurés par utilisateur et par site. Sur un parc de sites WordPress managés, c’est un avantage opérationnel : une seule instance à maintenir, un seul cron d’archivage, une seule base de données à sauvegarder.

Matomo ralentit-il le site WordPress ?

Le script de tracking Matomo (matomo.js) pèse environ 25 Ko compressé et se charge de manière asynchrone — il n’a pas d’impact mesurable sur les Core Web Vitals du site. La charge se situe côté serveur Matomo (archivage, requêtes SQL), pas côté WordPress. C’est pourquoi le cron d’archivage est important : sans lui, les calculs de rapports se déclenchent à chaque consultation de l’interface et peuvent ralentir le serveur si Matomo et WordPress partagent la même machine.

Vous voulez installer Matomo sur votre infrastructure ou migrer depuis Google Analytics ?

← Tous les articles Parlons de votre projet