Matomo 6 beta faut-il préparer la mise à jour ?

Matomo 6 beta se prépare avant de cliquer sur mise à jour. Le vrai sujet, c’est votre socle technique : PHP, base de données, migration log_visit, filtrage bots et impacts UI. Je vous résume quoi vérifier, où ça peut coincer et comment sécuriser le passage.

Qu’est-ce qui change vraiment ?

Matomo 6 beta ne change pas juste deux boutons et une couleur dans l’admin. Ce que je vois surtout, c’est une remise à niveau du socle. Et c’est exactement le genre de mise à jour qui mérite un vrai check avant de cliquer sur “upgrade”.

Le premier point, c’est la compatibilité serveur. Matomo 6 impose PHP >= 8.1, MySQL 8.0 ou MariaDB 10.6. Si votre instance tourne encore sur un hébergement un peu ancien, ça peut bloquer net. J’ai déjà vu ça chez un client avec un Matomo “qui marche depuis des années”, sauf que personne n’avait touché à PHP depuis 2019. La mise à jour applicative était prête, le serveur non.

Le deuxième point, plus sensible côté données, c’est le filtrage intégré des spams et des bots. Il est activé par défaut. C’est une bonne chose, surtout avec le trafic headless, les crawlers IA, les faux navigateurs et tout le bruit qui pollue les rapports. Mais ça veut aussi dire une chose simple : vos chiffres peuvent baisser après migration. Pas forcément parce que vous perdez du trafic. Peut-être parce que Matomo compte enfin moins de faux trafic.

Donc je surveillerais surtout les écarts sur 7 à 14 jours après migration. Sessions, pages vues, taux de rebond, pays, devices, pages d’entrée. Si tout baisse brutalement, il faut comprendre pourquoi avant de paniquer.

Matomo

Quels outils IA éthiques pour un marketing privacy-first ?

12/09/2026

À mes yeux, Matomo 6 beta est intéressante, mais pas anodine. Le risque n’est pas juste esthétique. Le vrai sujet, c’est la compatibilité technique et la lecture des données après filtrage.

Votre serveur est-il prêt ?

Avant de toucher à Matomo 6 beta, je regarde d’abord le serveur. C’est le point qui évite les mauvaises surprises. Le serveur est prêt uniquement si l’environnement respecte les nouvelles exigences : PHP >= 8.1, MySQL 8.0 ou MariaDB 10.6. Si votre installation tourne avec une version plus ancienne, je ne mets pas Matomo à jour. Je mets d’abord à jour l’environnement.

Je commence par les commandes simples côté serveur. Ça donne déjà une bonne idée de l’état réel de la machine.

php -v

Cette commande contrôle la version PHP disponible en ligne de commande. C’est utile, mais ce n’est pas suffisant.

mysql --version

Cette commande indique la version du client MySQL ou MariaDB installé sur le serveur. Là aussi, je garde un peu de prudence, parce que le client ne garantit pas toujours la version exacte du serveur de base utilisé par Matomo.

SELECT VERSION();

Matomo

Comment Matomo MCP accélère vos décisions data ?

12/09/2026

Cette requête, lancée dans MySQL ou MariaDB, donne la version côté base. C’est celle qui compte vraiment pour valider la compatibilité.

Le piège classique, c’est PHP. La version en terminal peut être correcte, pendant que le serveur web utilise autre chose. La CLI PHP, donc PHP lancé en ligne de commande, et PHP-FPM, donc le service PHP utilisé par Nginx ou parfois Apache, peuvent pointer vers deux versions différentes. J’ai déjà vu ça chez un client : tout semblait bon avec php -v, mais Apache appelait encore une vieille version de PHP. Résultat, Matomo refusait de tourner correctement alors que “sur le papier” tout était prêt.

Avant migration, je vérifie donc aussi la configuration réelle du vhost, du pool PHP-FPM, ou du module Apache actif. C’est moins sexy qu’un clic sur “mettre à jour”, mais c’est là que les migrations propres se gagnent.

• Version PHP : PHP >= 8.1 confirmé côté serveur web.
• Version base : MySQL 8.0 ou MariaDB 10.6 minimum confirmé avec SELECT VERSION();
• Sauvegarde disponible : Fichiers Matomo et base de données exportés.
• Accès administrateur : Accès Matomo, SSH, base de données et hébergement disponibles.
• Fenêtre de maintenance : Créneau prévu, même court.
• Possibilité de rollback : Retour arrière testé ou au moins réaliste.

La migration peut-elle prendre du temps ?

La partie à ne pas sous-estimer dans Matomo 6 beta, c’est la migration de la table log_visit. Cette table stocke les visites, donc sur une instance qui tourne depuis des années, elle peut vite devenir énorme. Et quand Matomo ajoute une colonne consent dedans, ça veut dire une opération de type ALTER TABLE. Sur une petite base, ça passe souvent sans histoire. Sur une grosse base de tracking, ça peut prendre du temps, voire provoquer des ralentissements.

Je commencerais par regarder le volume réel de la table avant de planifier quoi que ce soit :

SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE()
AND table_name = 'log_visit';

Matomo

Matomo 5.10.0 quelles améliorations visuelles ?

12/09/2026

Le chiffre table_rows reste une estimation selon le moteur MySQL ou MariaDB, mais ça donne déjà une bonne idée. Si vous voyez plusieurs millions ou dizaines de millions de lignes, je ne lancerais pas la mise à jour entre deux réunions. J’ai déjà vu des migrations analytics bloquer plus longtemps que prévu juste parce que personne n’avait regardé la taille des logs avant.

La sauvegarde reste le minimum syndical avant une migration :

mysqldump nom_base > backup_matomo.sql

Et pour bien comprendre le type d’opération concernée, Matomo pourrait devoir faire quelque chose dans cet esprit :

ALTER TABLE log_visit ADD COLUMN consent TINYINT NULL;

Attention, je le mets uniquement comme exemple pédagogique. Je ne lancerais pas cette requête à la main sans suivre le processus officiel de migration Matomo. Le risque, c’est de désynchroniser l’état de la base avec ce que Matomo croit avoir appliqué.

Voilà comment je préparerais selon la taille de l’installation :

Le point clé, c’est d’éviter la surprise. Une migration peut être techniquement simple, mais longue à cause du volume. Si Matomo est critique pour vos équipes marketing, produit ou conformité, je testerais d’abord sur une copie de la base. Et pendant la migration, je surveillerais surtout les verrouillages de table, les ralentissements d’écriture et la charge disque.

Que faut-il tester après l’upgrade ?

Je fais toujours la recette Matomo en partant des rapports les plus consultés. C’est là que les écarts sautent aux yeux. Je compare le trafic global, les pages vues, les sources de provenance, les visiteurs, puis les cartes visiteurs sur une période connue, idéalement les 7 ou 30 derniers jours avant migration.

Les cartes visiteurs méritent un vrai contrôle. Matomo 6 régénère les cartes avec de meilleures données géographiques, donc il peut y avoir de petites différences. Ce n’est pas forcément un bug. C’est souvent une donnée plus propre. Même chose côté rapports de pages : l’archivage est optimisé pour les nouvelles installations, mais certaines instances qui gardent un comportement d’archivage plus ancien ne profiteront pas tout de suite du gain. Là, je vérifie surtout que les rapports se chargent bien, que les volumes restent cohérents, et que les segments habituels répondent normalement.

Côté interface, je teste les usages simples. Les menus déroulants, les champs select, les listes réordonnables, le composant de recherche unifié. Ça paraît basique, mais c’est exactement ce que vos équipes utilisent tous les jours. Je vérifie aussi le copier-coller dans les champs, surtout avec des textes longs, et la prise en charge des IME, les méthodes de saisie utilisées pour certaines langues comme le japonais ou le chinois. Les en-têtes de rapports sont aussi plus cohérents, avec parfois un lien More details vers des guides en ligne. Je clique dessus, juste pour éviter un lien cassé en prod.

Je regarde ensuite les changements qui peuvent casser des habitudes plus discrètes. Le plugin SEO est retiré. L’API SEO.getRank aussi. Si un dashboard interne appelait cette route, il va tomber. L’option de retry HTTP pour One Click Update disparaît également. La validation du hostname derrière proxy est plus stricte, donc je teste l’accès via l’URL publique réelle, pas seulement en local. Et je vérifie les réponses API, car certaines ajoutent des colonnes de pourcentages. C’est utile, mais un script fragile peut mal parser la réponse.

• Rapports clés : Comparer trafic global, pages, provenance, visiteurs et cartes avec l’ancienne version.
• Archivage : Lancer ou vérifier les archives, surtout sur les rapports de pages.
• Interface : Tester menus, selects, recherche, listes réordonnables, collage et saisie IME.
• SEO : Confirmer qu’aucun usage ne dépend du plugin SEO ou de SEO.getRank.
• Proxy : Tester l’accès via le hostname public et la configuration proxy.
• Automatisations et dashboards API : Rejouer les appels Matomo utilisés en production et vérifier le parsing des nouvelles colonnes.

Faut-il passer sur la beta maintenant ?

Oui, je testerais Matomo 6 beta cette semaine. Mais je ne la mettrais pas en production sur une instance critique sans filet. La beta sert surtout à éviter la migration subie plus tard, celle qu’on lance un vendredi soir parce qu’une version devient obligatoire ou qu’un serveur n’est plus compatible.

Mon approche est simple : je clone l’instance, je restaure une copie récente de la base, je vérifie PHP et MySQL ou MariaDB, puis je lance la mise à jour dans un environnement de test. Pas besoin d’en faire un chantier énorme au départ. Le but, c’est de savoir ce qui casse, ce qui ralentit, ce qui change dans les rapports, et combien de temps la migration prend vraiment.

Je regarderais surtout ces points :

• La compatibilité PHP, parce que c’est souvent là que les vieilles instances coincent.
• La version MySQL ou MariaDB, surtout si l’installation traîne depuis plusieurs années.
• Les plugins installés, y compris ceux qu’on a oubliés mais qui tournent encore.
• Les appels API utilisés par vos dashboards, exports, automatisations ou outils internes.
• Les rapports que l’équipe consulte tous les jours, parce qu’un petit changement d’affichage peut vite devenir un irritant.

J’ai déjà vu des migrations analytics bloquées non pas par le cœur de l’outil, mais par une vieille automatisation branchée sur une API, ou par un plugin plus maintenu. C’est exactement ce que la beta permet de repérer sans pression.

Donc ma réponse est claire : oui pour l’audit et le test maintenant. Prudence pour la production. Une beta doit servir à apprendre, pas à découvrir les problèmes en direct devant toute l’équipe.

Alors on la prépare maintenant ?

Matomo 6 beta mérite clairement d’être préparée maintenant. Pas parce qu’il faut courir après la nouveauté, mais parce que les impacts sont très concrets : PHP 8.1 minimum, MySQL 8 ou MariaDB 10.6, migration de la table log_visit, filtrage bots activé par défaut, changements d’interface, évolutions API et retrait du plugin SEO. Mon conseil reste simple : je teste sur une copie, je mesure la durée de migration, je vérifie les rapports et les automatisations, puis seulement je décide pour la production. Le bénéfice pour vous, c’est une mise à jour maîtrisée au lieu d’un incident subi.

FAQ

• Matomo 6 beta impose quelles versions serveur ?
  Matomo 6 beta exige PHP >= 8.1 et une base MySQL 8.0 ou MariaDB 10.6. Si votre instance tourne sur une version plus ancienne, je commencerais par mettre à niveau l’environnement avant de toucher à Matomo.
• Pourquoi la migration de Matomo 6 peut être longue ?
  Le point sensible est l’ajout de la colonne consent dans la table log_visit. Sur une grosse instance, cette table peut contenir énormément de lignes. L’opération ALTER TABLE peut donc prendre du temps et mérite une fenêtre de maintenance.
• Le filtrage des bots change quoi dans les rapports ?
  Le filtrage des spams et bots est intégré et activé par défaut, avec prise en compte du trafic headless ou IA. C’est utile pour réduire le bruit, mais je vérifierais quand même les écarts de trafic après upgrade.
• Qu’est-ce qui disparaît avec Matomo 6 ?
  Le plugin SEO est retiré, tout comme l’API SEO.getRank. L’option de retry HTTP pour One Click Update disparaît aussi. Si vos dashboards ou automatisations utilisent ces éléments, il faut les contrôler avant migration.
• Faut-il installer Matomo 6 beta en production ?
  Je testerais d’abord sur une copie, surtout si l’instance est critique ou volumineuse. La bonne approche, c’est d’auditer le serveur, mesurer la migration, vérifier les rapports et valider les intégrations API avant de décider pour la production.

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’IA appliquée au business et le SEO/GEO. J’ai travaillé avec des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous devez sécuriser une migration analytics, fiabiliser vos données ou automatiser vos contrôles, contactez-moi, je peux vous aider.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐

• Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

• Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
• Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
• Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.