Choisir un outil analytics : la grille de gouvernance en 15 questions

Les comparatifs analytics commencent souvent par une liste de fonctionnalités. Ils se terminent par une note globale qui suppose que toutes les équipes cherchent la même chose.

Ce n’est pas le cas.

Une PME B2B qui veut suivre trois sites, partager un reporting avec une agence et limiter la collecte n’a pas les mêmes contraintes qu’un groupe e-commerce connecté à une régie publicitaire. Une équipe technique qui accepte d’exploiter une instance auto-hébergée ne fait pas le même arbitrage qu’une équipe marketing sans administrateur système.

Le bon outil n’est donc pas celui qui possède le plus de fonctions. C’est celui dont les fonctions, les défauts de configuration et le modèle de gouvernance correspondent au besoin.

Le comparatif général entre Google Analytics, Matomo et les analytics frugales présente les grandes familles. La grille suivante sert à conduire la décision dans une organisation réelle, sans dépendre d’un classement figé ni de tarifs susceptibles de changer.

Avant de noter les outils, écrire le problème

Une sélection sérieuse tient sur une page avant la première démonstration.

Les décisions attendues

Listez cinq à dix décisions que l’analytics doit soutenir :

• quels canaux amènent des demandes qualifiées ?
• quelles pages d’entrée contribuent aux conversions ?
• quels contenus sont consultés ?
• quels sites progressent ou décrochent ?
• quels événements produit doivent être suivis ?
• où une rupture de collecte s’est-elle produite ?

Une demande comme « avoir toutes les données » n’est pas exploitable.

Les utilisateurs

Identifiez les rôles :

• marketing ;
• produit ;
• direction ;
• agence ;
• analyste ;
• développeur ;
• DPO ou privacy ;
• clients externes.

Le nombre d’utilisateurs importe moins que leurs droits, leurs compétences et la fréquence d’usage.

Les contraintes

Documentez :

• nombre de sites ;
• volume attendu ;
• pays ;
• besoins de consentement ;
• données interdites ;
• durée ;
• intégrations ;
• budget ;
• capacité d’exploitation ;
• délai de migration ;
• exigences contractuelles.

Cette page évite qu’une démonstration impressionnante remplace l’analyse.

La scorecard en 15 questions

Notez chaque outil de 0 à 3 :

• 0 : non couvert ou incompatible ;
• 1 : possible avec contournement important ;
• 2 : couvert avec configuration ou limite acceptable ;
• 3 : couvert naturellement et documenté.

Appliquez ensuite un poids de 1 à 3 selon l’importance pour votre équipe.

1. Quelles questions métier l’outil répond-il sans reconstruction lourde ?

Testez cinq scénarios concrets, pas une liste de menus.

Exemple :

1. afficher les pages d’entrée d’une campagne ;
2. isoler les demandes de démo ;
3. comparer trois sites ;
4. exporter un rapport mensuel ;
5. expliquer une chute de trafic.

Un outil puissant mais incompréhensible pour ses utilisateurs réels a un coût élevé.

2. Quelle granularité est réellement nécessaire ?

Distinguez :

• statistiques agrégées ;
• événements ;
• parcours ;
• cohortes ;
• funnels ;
• identifiants utilisateurs ;
• données publicitaires ;
• session replay.

Chaque niveau ajoute des possibilités et une charge de gouvernance. Une équipe qui n’utilise que pages, sources et conversions ne doit pas sélectionner un produit principalement pour des fonctions d’analyse comportementale détaillée.

3. Que collecte la configuration par défaut ?

Le défaut compte plus que la fiche produit.

Vérifiez :

• cookies ou autres identifiants ;
• adresse IP ;
• URL complète ;
• user-agent ;
• géolocalisation ;
• identifiant publicitaire ;
• événements automatiques ;
• paramètres de requête ;
• signaux inter-sites.

Appliquez l’audit des paramètres d’URL et demandez un payload de test.

Notez mieux un outil dont le défaut correspond à votre politique, car chaque option à désactiver est une dette de configuration.

4. Les modes stricts et étendus sont-ils séparés clairement ?

Certaines équipes veulent un socle minimal sans consentement dans les cas où le cadre le permet, puis des fonctions étendues après choix.

Évaluez :

• séparation des configurations ;
• comportement avant consentement ;
• propagation du signal ;
• possibilité d’activer une fonction par erreur ;
• traçabilité des changements ;
• documentation des modes.

Un bouton « privacy » vague ne suffit pas.

5. Pouvez-vous expliquer le flux de données ?

L’outil doit permettre de répondre à :

• où arrive la requête ?
• quelles transformations ont lieu ?
• où sont stockées les données ?
• quels sous-traitants interviennent ?
• le fournisseur réutilise-t-il les données ?
• quels accès support existent ?
• quels transferts s’appliquent ?

Utilisez le data collection summary comme format d’évaluation.

6. La localisation et les transferts correspondent-ils à vos contraintes ?

Évaluez séparément :

• région d’hébergement ;
• entité contractante ;
• sous-traitants ;
• accès à distance ;
• mécanismes de transfert ;
• options d’auto-hébergement.

« Hébergé dans l’UE » est un élément, pas une analyse complète. L’auto-hébergement offre du contrôle mais transfère aussi des responsabilités opérationnelles à l’équipe.

7. La rétention, la suppression et les sauvegardes sont-elles maîtrisables ?

Demandez :

• périodes disponibles ;
• différence entre événements et rapports agrégés ;
• suppression automatique ;
• suppression par propriété ;
• délai de purge des sauvegardes ;
• traitement des exports ;
• suppression à la fin du contrat ;
• preuve ou journal d’opération.

Une rétention illimitée par défaut n’est pas une fonctionnalité neutre.

8. Les accès multi-sites sont-ils adaptés ?

Pour plusieurs propriétés, vérifiez :

• rôles par site ;
• groupes ;
• invitation d’agences ;
• accès lecture seule ;
• export ;
• journal d’administration ;
• SSO si nécessaire ;
• retrait d’accès ;
• vue portefeuille.

Le modèle de dashboard multi-sites aide à transformer ces critères en scénarios de test.

9. Comment l’outil gère-t-il la qualité des données ?

Vérifiez :

• filtrage des bots ;
• environnements de test ;
• doublons ;
• événements invalides ;
• paramètres inconnus ;
• délais d’ingestion ;
• changements de définition ;
• alertes ;
• fuseaux horaires ;
• cardinalité.

Un rapport simple sans mécanisme de diagnostic peut être trop pauvre pour une équipe multi-sites. À l’inverse, une plateforme riche qui masque ses transformations peut être difficile à auditer.

10. Les événements et conversions restent-ils gouvernables ?

Testez la création, modification et dépréciation d’un événement.

Questions :

• le schéma est-il validé ?
• les propriétés libres sont-elles contrôlables ?
• peut-on interdire un champ ?
• un changement est-il versionné ?
• les objectifs historiques restent-ils compréhensibles ?
• une agence peut-elle modifier la collecte sans approbation ?

La facilité d’ajouter un événement n’est pas toujours un avantage. Une absence de garde-fou crée rapidement une taxonomie illisible.

11. L’acquisition est-elle lisible sans configuration excessive ?

Testez :

• source et medium ;
• campagnes UTM ;
• referrers ;
• direct ;
• pages d’entrée ;
• conversions par source ;
• canaux personnalisés ;
• modèles d’attribution si réellement nécessaires.

Deux outils peuvent classer différemment le même parcours. Demandez comment les règles sont définies et si elles sont modifiables.

12. L’historique est-il migrable et comparable ?

Vérifiez :

• import disponible ;
• format ;
• granularité ;
• métriques supportées ;
• coût ;
• durée ;
• différence de définitions ;
• conservation des données sources ;
• marquage de la date de rupture.

Un import n’efface pas les différences de session, visiteur ou conversion. Le reporting doit souvent présenter une rupture méthodologique.

13. Le coût est-il prévisible à votre échelle ?

Ne comparez pas uniquement le prix affiché.

Calculez :

• abonnement selon volume ;
• dépassements ;
• sites supplémentaires ;
• utilisateurs ;
• modules ;
• stockage ;
• hébergement ;
• maintenance ;
• support ;
• consent management ;
• temps de configuration ;
• reporting manuel ;
• coût de migration et de sortie.

Pour l’auto-hébergement, incluez mises à jour, sauvegardes, supervision, sécurité et disponibilité. Pour un SaaS, incluez la croissance du trafic et les fonctions nécessaires dans les plans supérieurs.

Les tarifs doivent être vérifiés au moment de la décision.

14. Quelle charge opérationnelle l’équipe accepte-t-elle ?

Classez les tâches :

• installation ;
• configuration ;
• tests ;
• maintenance ;
• accès ;
• conformité ;
• alertes ;
• sauvegardes ;
• support ;
• formation ;
• documentation.

Un outil « gratuit » peut être coûteux en administration. Un outil simple peut être coûteux si l’équipe doit exporter chaque semaine pour répondre à une question absente.

Le bon niveau de complexité est celui que l’organisation peut exploiter durablement.

15. Pouvez-vous sortir proprement ?

Évaluez la réversibilité avant la signature :

• export complet ;
• formats ouverts ;
• API ;
• délai d’accès après résiliation ;
• suppression ;
• portabilité des configurations ;
• récupération des événements ;
• historique des définitions ;
• dépendance à des identifiants propriétaires.

Une plateforme qui répond au besoin aujourd’hui mais enferme la mesure dans un format inexploitable crée une dette future.

Un modèle de pondération

Pour une PME SaaS multi-sites, les poids peuvent ressembler à ceci :

Critère	Poids
Questions métier	3
Granularité	2
Collecte par défaut	3
Séparation strict/étendu	3
Flux et fournisseurs	3
Localisation et transferts	2
Rétention et suppression	3
Accès multi-sites	3
Qualité des données	2
Gouvernance des événements	2
Acquisition	2
Migration	2
Coût total	3
Charge opérationnelle	3
Réversibilité	2

La note pondérée est :

somme(note × poids) / somme(3 × poids)

Le résultat peut être exprimé en pourcentage, mais ne transformez pas un écart de deux points en vérité scientifique. La discussion sur les critères compte plus que le classement final.

Ajouter des critères éliminatoires

Certains critères ne se compensent pas.

Exemples :

• contrat ou DPA indisponible ;
• absence de suppression ;
• export impossible ;
• données interdites collectées sans contrôle ;
• accès multi-sites incompatibles ;
• transfert non acceptable ;
• coût hors budget ;
• charge d’exploitation impossible ;
• fonction indispensable absente.

Un outil peut obtenir 85 % et être éliminé par un seul point critique.

Comment lire les grandes familles d’outils

Suites publicitaires et analytics riches

GA4 s’intègre profondément à l’écosystème Google et propose de nombreuses dimensions, explorations et connexions publicitaires. Cette profondeur peut être cohérente pour des équipes équipées, ayant un besoin réel d’attribution et d’activation.

Elle implique aussi une configuration, une gouvernance des événements et une lecture des scopes plus exigeantes. L’outil ne doit pas être choisi par défaut uniquement parce qu’il est connu.

Plateformes contrôlables et auto-hébergeables

Matomo offre des options cloud et auto-hébergées, avec un périmètre fonctionnel large. Umami et d’autres projets open source proposent des approches plus compactes.

L’auto-hébergement donne du contrôle sur l’infrastructure, mais l’organisation devient responsable de l’exploitation. Demandez qui installe les mises à jour, restaure une sauvegarde et surveille les accès.

Analytics SaaS privacy-first

Plausible, Fathom, Simple Analytics et d’autres solutions privilégient des rapports plus lisibles et une collecte souvent plus limitée. Elles peuvent réduire la charge de configuration pour les besoins essentiels.

Leur simplicité peut devenir une limite pour des analyses avancées, des schémas d’événements complexes ou certaines consolidations. Vérifiez les fonctions présentes, pas seulement la philosophie.

Produits émergents

Un produit en bêta ou en lancement peut proposer une approche mieux alignée avec votre gouvernance, mais il faut évaluer maturité, documentation, support, export, stabilité et roadmap démontrée.

Ne notez jamais une promesse de roadmap comme une fonction disponible.

Organiser le test en deux semaines

Jour 1 : valider les scénarios

Choisissez cinq questions, trois rôles et deux propriétés représentatives.

Jours 2 à 4 : déployer un périmètre réduit

Installez chaque candidat sur un environnement de test ou une propriété pilote. Utilisez les mêmes pages et événements.

Jours 5 à 7 : auditer la collecte

Comparez réseau, stockage documenté, consentement, paramètres d’URL et accès.

Jours 8 à 10 : faire tester les utilisateurs

Demandez à une personne marketing, une personne produit et un administrateur de réaliser les mêmes tâches sans assistance excessive.

Jours 11 à 12 : tester export et suppression

Exportez, révoquez un accès, modifiez la rétention et demandez la procédure de suppression.

Jours 13 à 14 : noter et documenter

Remplissez la scorecard, listez les critères éliminatoires et écrivez les compromis acceptés.

Les erreurs de sélection les plus fréquentes

Choisir sur une démonstration

Une démonstration montre le meilleur parcours, pas les opérations quotidiennes.

Choisir uniquement sur la privacy

La privacy est une contrainte de conception majeure, mais l’outil doit aussi répondre aux décisions. Une solution inutilisée n’améliore pas la gouvernance.

Choisir uniquement sur les fonctions

Une fonction qui élargit la collecte ou exige une équipe dédiée peut être un coût, pas une valeur.

Comparer les tarifs sans volume futur

Calculez les scénarios à douze et vingt-quatre mois.

Oublier les personnes

Le meilleur outil théorique échoue si personne ne comprend les rapports ou ne maintient les règles.

Conclusion

Un comparatif utile ne demande pas « quel outil est le meilleur ? ». Il demande « quel outil crée le meilleur compromis pour cette organisation ? »

La scorecard doit rendre visibles :

• les décisions attendues ;
• la collecte par défaut ;
• la gouvernance ;
• les droits ;
• la rétention ;
• le multi-sites ;
• le coût total ;
• la charge opérationnelle ;
• la capacité de sortie.

Le résultat n’est pas une note universelle. C’est une décision explicable, révisable et documentée.

FAQ

Combien d’outils faut-il tester ?

Trois candidats bien choisis suffisent souvent : un outil de référence riche, une option plus contrôlable et une option privacy-first simple. Ajoutez un quatrième uniquement s’il représente un modèle réellement différent.

Une solution auto-hébergée est-elle toujours plus conforme ?

Non. Elle augmente le contrôle potentiel, mais la conformité dépend de la configuration, de la sécurité, des accès, des finalités, de la rétention et de l’exploitation réelle.

Peut-on comparer les prix une fois pour toutes ?

Non. Les tarifs, plans et limites évoluent. Vérifiez-les au moment de la décision et modélisez plusieurs volumes.

Comment traiter une fonctionnalité annoncée sur la roadmap ?

Notez-la comme absente tant qu’elle n’est pas disponible et vérifiable. Une roadmap peut influencer le risque, mais ne doit pas remplacer un besoin actuel.

Quelle différence entre un critère pondéré et un critère éliminatoire ?

Un critère pondéré peut être compensé par d’autres forces. Un critère éliminatoire rend l’outil incompatible, même avec une excellente note globale.

Sources

• CNIL, Cookies : solutions pour les outils de mesure d’audience
• Règlement (UE) 2016/679, principes de minimisation, transparence et responsabilité
• Google Analytics, Analytics account structure
• Google Analytics, Data retention
• Matomo, Privacy
• Plausible, Data policy
• Fathom Analytics, Data policy
• Umami, Documentation