Événements GA4 : structurer le plan de taggage sans bruit

Un plan de taggage GA4 n’est pas une liste d’événements, c’est un système de décision

La plupart des problèmes de mesure dans Google Analytics 4 ne viennent pas d’un manque de tags. Ils viennent d’un excès de signaux mal hiérarchisés. Une équipe ajoute un événement pour chaque clic, chaque scroll, chaque ouverture de bloc, chaque interaction avec un filtre, chaque impression de module, puis découvre six mois plus tard que personne ne sait distinguer les événements réellement utiles des événements simplement disponibles. GA4, Google Analytics 4, plateforme d’analytics orientée événements utilisée pour mesurer les parcours web et app, a rendu cette dérive plus facile : tout peut devenir événement, donc tout finit souvent taggé.

Pour une équipe CRO, conversion rate optimization, discipline qui vise à améliorer la capacité d’un parcours digital à transformer le trafic en valeur business mesurable, cette inflation est coûteuse. Un plan de taggage bruité dégrade la lecture du funnel, parcours allant de la première exposition marketing à la conversion puis à la fidélisation. Il complique l’attribution, méthode qui assigne une conversion à un ou plusieurs points de contact marketing. Il entraîne les plateformes média sur des micro-conversions faibles. Il fausse le CPA, coût par acquisition, soit le coût marketing nécessaire pour générer un client ou une conversion qualifiée, et peut embellir artificiellement le ROAS, return on ad spend, ratio entre chiffre d’affaires attribué et dépenses publicitaires, si des événements intermédiaires sont confondus avec de la valeur.

Structurer un plan de taggage sans bruit exige donc une discipline inverse à celle que l’on observe souvent. Il ne faut pas partir de ce que l’on peut mesurer, mais de ce que l’on doit décider. Le bon plan GA4 répond à des questions opérationnelles : où le parcours perd-il de la valeur ? Quels segments convertissent ou décrochent ? Quelles micro-conversions prédisent réellement une conversion finale ? Quels signaux doivent être transmis aux algorithmes publicitaires ? Quelles données doivent être exportées dans BigQuery, entrepôt de données cloud souvent utilisé pour analyser les données GA4 à un niveau plus granulaire ?

L’enjeu n’est pas seulement analytique. Un taggage propre réduit le temps d’analyse, améliore la fiabilité des tests A/B, clarifie les arbitrages média et évite de construire des dashboards qui rassurent plus qu’ils n’éclairent. Dans une organisation mature, le plan de taggage devient une infrastructure de décision : il relie acquisition, UX, CRM, produit, data et finance autour d’un langage commun de la performance.

Partir des décisions business avant de nommer les événements

La première erreur consiste à concevoir le plan de taggage comme un inventaire fonctionnel du site. Page produit, bouton ajouter au panier, menu, carrousel, filtre, formulaire, footer, vidéo, FAQ : chaque élément devient une opportunité de tag. Cette approche produit beaucoup de données, mais peu de décisions. Elle répond à la question que fait l’utilisateur ?, alors qu’un plan robuste doit d’abord répondre à la question quelle décision allons-nous prendre si cette mesure change ?

Un framework simple consiste à partir de trois niveaux de décision. Le premier niveau est stratégique : allocation budgétaire, arbitrage entre canaux, priorités CRO, investissement produit, segmentation client. Le deuxième est tactique : optimisation des landing pages, simplification du checkout, amélioration des formulaires, qualification des audiences. Le troisième est opérationnel : vérification d’un bug, suivi d’une campagne, contrôle d’un composant spécifique. Tous les événements ne doivent pas être traités au même niveau. Un purchase ou un generate_lead appartient au cœur de la mesure. Un clic sur une icône secondaire peut être utile ponctuellement, mais ne devrait pas encombrer les rapports standards.

Concrètement, avant de créer un événement, l’équipe devrait documenter quatre éléments : la décision liée, la population concernée, la métrique dérivée et la durée de vie attendue du signal. Si un événement ne sert à aucune décision identifiée, il doit rester hors du plan principal. Si le besoin est exploratoire, il peut être taggé temporairement via un événement de diagnostic, avec une date de revue. Le problème n’est pas de mesurer un clic secondaire pendant une refonte UX ; le problème est de le conserver indéfiniment jusqu’à ce qu’il devienne une colonne morte dans les analyses.

Exemple : une marque e-commerce veut comprendre pourquoi le taux de conversion mobile baisse de 2,8 % à 2,3 % sur trois mois. Une réponse bruitée consisterait à tagger tous les clics de la page produit. Une réponse structurée consiste à poser l’hypothèse : la friction se situe peut-être entre la sélection de variante, la compréhension des délais de livraison et l’ajout panier. Le plan de mesure devrait alors prioriser quelques événements : select_item_variant, view_delivery_info, add_to_cart, begin_checkout, avec des paramètres utiles comme device, stock_status, delivery_delay_bucket, product_category et user_type. L’objectif n’est pas de tout observer ; il est de confirmer ou d’invalider un mécanisme.

Cette logique protège aussi contre la surproduction de conversions dans GA4. Déclarer dix événements comme conversions parce qu’ils semblent positifs dilue la hiérarchie de valeur. Une vue FAQ, un clic téléphone, un téléchargement de brochure et une demande de devis ne devraient pas être mis au même niveau. Pour piloter correctement le marketing, il faut distinguer macro-conversions, micro-conversions prédictives et simples interactions explicatives.

Construire une taxonomie d’événements lisible, stable et exploitable

GA4 impose une architecture événementielle, mais n’impose pas une discipline sémantique. C’est à l’organisation de définir une taxonomie. Une taxonomie est un système de nommage et de classification permettant de rendre les événements comparables dans le temps. Sans taxonomie, les noms prolifèrent : lead_submit, form_sent, contact_form_success, submit_lead, parfois pour le même comportement. À court terme, cela semble anodin. À long terme, cela détruit la capacité à analyser des tendances.

Un bon nom d’événement doit être actionnable, générique lorsque c’est pertinent, et enrichi par des paramètres plutôt que par une multiplication de variantes. Par exemple, il est préférable d’utiliser un événement form_submit avec des paramètres form_type, form_location, lead_intent et business_unit, plutôt que de créer demo_form_submit, contact_form_submit, newsletter_footer_submit et pricing_demo_submit sans cohérence. Les paramètres permettent de segmenter ; les noms d’événements doivent rester suffisamment stables pour structurer les rapports.

La convention recommandée par Google privilégie des noms en minuscules avec underscores, sans espace ni caractères spéciaux. Mais la vraie question est moins syntaxique que conceptuelle. Un événement doit décrire une action utilisateur ou système clairement définie. lead est ambigu. generate_lead est plus précis si l’événement correspond à une soumission validée. lead_qualified ne doit être déclenché que si le CRM ou un backend confirme la qualification. Cette distinction est critique : tagger un clic sur le bouton envoyer comme lead revient à compter des intentions, pas des soumissions valides.

La hiérarchie peut être structurée en cinq familles :

• Événements de valeur : achat, lead validé, rendez-vous confirmé, abonnement, création de compte activée.
• Événements de progression : ajout panier, début checkout, étape formulaire, consultation pricing, sélection d’offre.
• Événements de qualification : statut nouveau client, segment B2B ou B2C, type de demande, score lead, catégorie de panier.
• Événements d’expérience : erreur formulaire, temps de chargement critique, refus de paiement, rupture de stock, recherche sans résultat.
• Événements de diagnostic : interactions temporaires nécessaires à une enquête UX ou à un test spécifique.

Cette classification évite de mélanger les événements qui pilotent l’entreprise avec ceux qui expliquent un comportement ponctuel. Elle facilite aussi la gouvernance : les événements de valeur doivent être très stables, audités et idéalement validés côté serveur. Les événements de diagnostic peuvent être plus flexibles, mais doivent être revus régulièrement.

Un exemple de mauvais design serait de tagger click_cta_home, click_cta_top, click_cta_blue et click_cta_mobile. Le nom mélange emplacement, design et device. Une structure plus propre serait cta_click avec des paramètres cta_location, cta_label, page_type, device_category et experiment_variant. L’analyse devient plus souple et la nomenclature reste stable lorsque le design change.

Définir les paramètres qui réduisent l’ambiguïté, pas ceux qui décorent les rapports

Dans GA4, les paramètres sont souvent plus importants que l’événement lui-même. Un add_to_cart sans catégorie produit, marge estimée, statut de stock, prix, remise et type d’utilisateur peut suffire à un reporting basique. Il devient insuffisant pour une analyse CRO ou média avancée. À l’inverse, ajouter vingt paramètres mal renseignés crée du bruit, consomme des ressources et complique l’export.

La bonne question est : quel paramètre change l’interprétation de l’événement ? Pour un formulaire B2B, form_type, company_size, country, industry, lead_source et qualification_status peuvent être déterminants. Pour un e-commerce, item_category, price, discount, margin_bucket, availability, shipping_delay et customer_type peuvent expliquer pourquoi un taux de conversion global progresse alors que la rentabilité se dégrade.

Il faut distinguer trois types de paramètres. Les paramètres descriptifs qualifient l’objet ou le contexte : page_type, product_category, form_type, cta_location. Les paramètres économiques qualifient la valeur : revenue, margin, discount, basket_size, subscription_plan. Les paramètres analytiques qualifient l’interprétation : user_type, consent_status, traffic_type, experiment_id, funnel_step. Les paramètres économiques sont les plus souvent négligés, alors qu’ils permettent d’éviter une CRO obsédée par le volume au détriment de la marge.

Exemple concret : un site SaaS observe une hausse de 18 % des demandes de démo après simplification d’une landing page. GA4 confirme l’augmentation de generate_lead. Mais si le plan de taggage ne remonte pas le type d’entreprise, la taille de compte ou le statut SQL, sales qualified lead, lead accepté par les ventes comme opportunité potentielle, l’équipe peut conclure trop vite. Le CRM révèle ensuite que les leads SMB, small and medium business, petites et moyennes entreprises, ont fortement progressé, mais que les leads enterprise ont reculé. Le test est-il gagnant ? Cela dépend de la valeur cible. Sans paramètre de qualification, GA4 n’aide pas à répondre.

La limite à garder en tête est la cardinalité. Une dimension à forte cardinalité contient trop de valeurs distinctes, par exemple un identifiant utilisateur, une URL complète avec paramètres, un libellé libre ou un nom de recherche interne non normalisé. Dans GA4, une cardinalité excessive peut rendre les rapports moins lisibles et créer des lignes regroupées sous des valeurs agrégées. Les paramètres doivent donc être normalisés. Plutôt que de remonter chaque délai exact de livraison, on peut utiliser des buckets : 0-2 jours, 3-5 jours, 6-10 jours, plus de 10 jours. Plutôt que de remonter tous les messages d’erreur, on peut créer des familles : validation, paiement, stock, technique, consentement.

Un plan de taggage mature documente aussi les paramètres obligatoires et facultatifs par événement. Pour purchase, transaction_id, value, currency, items et customer_type devraient être obligatoires. Pour form_submit, form_type, form_location et submission_status doivent être fiables. Si un paramètre critique manque dans plus de 5 % à 10 % des occurrences, il faut traiter le problème comme un défaut de mesure, pas comme une note de bas de page.

Relier GA4, GTM, serveur et CRM pour mesurer des faits plutôt que des intentions

Le plan de taggage ne se limite pas à GA4. Il dépend de la façon dont les événements sont déclenchés. GTM, Google Tag Manager, outil permettant de gérer des balises marketing et analytics sans redéployer systématiquement le code applicatif, est souvent utilisé pour accélérer la mesure. Mais un tag déclenché uniquement côté navigateur peut être fragile : bloqueurs, consentement, latence, erreurs JavaScript, navigation rapide, doublons, événements déclenchés au clic avant validation serveur.

La règle est simple : plus l’événement a de valeur business, plus il doit être proche d’un fait backend. Un clic sur soumettre un formulaire n’est pas un lead. Une page de confirmation chargée n’est pas toujours un paiement validé. Une intention de paiement n’est pas une transaction encaissée. Pour les événements critiques comme purchase, generate_lead, subscription_start ou qualified_lead, la source de vérité devrait idéalement être le serveur, le système de paiement ou le CRM.

Le server-side tagging, taggage côté serveur, consiste à faire transiter certains événements via un environnement serveur contrôlé avant envoi vers GA4 ou d’autres plateformes. Il peut améliorer la fiabilité, la gouvernance, la sécurité et le contrôle des données envoyées. Il ne résout pas tout : il nécessite une architecture, une maintenance, une politique de consentement claire et une surveillance des écarts. Mais il permet de réduire certains biais liés au navigateur et de mieux filtrer les paramètres sensibles.

Le lien avec le CRM est particulièrement critique pour les entreprises B2B ou les parcours à cycle long. GA4 mesure très bien les interactions digitales, mais il ne sait pas seul si un lead devient MQL, marketing qualified lead, prospect jugé suffisamment pertinent par le marketing, SQL, puis opportunité signée. Si l’événement generate_lead est optimisé en média sans retour de qualité, les algorithmes peuvent apprendre à générer des formulaires faciles, pas des revenus. Dans les plateformes RTB, real-time bidding, mécanisme d’enchères en temps réel permettant d’acheter une impression publicitaire disponible, et via une DSP, demand-side platform, plateforme utilisée pour acheter des impressions programmatiques, ce mauvais signal peut orienter les budgets vers des audiences qui convertissent en apparence mais créent peu de valeur.

Un exemple fréquent : une landing page de téléchargement livre blanc génère 4 000 leads mensuels avec un CPA de 18 euros. Une page demande de démo génère 600 leads avec un CPA de 95 euros. Si le plan GA4 ne remonte que generate_lead, la première semble imbattable. Si le CRM indique que 3 % des leads livre blanc deviennent SQL contre 38 % des demandes de démo, le coût par SQL est de 600 euros pour le livre blanc et 250 euros pour la démo. Le signal pertinent n’est pas le formulaire soumis, mais la progression qualifiée dans le funnel.

La bonne architecture consiste à définir une source de vérité par événement. GA4 peut être la source d’analyse comportementale. Le backend peut être la source de transaction. Le CRM peut être la source de qualification. Le data warehouse peut consolider. Cette clarification évite les débats stériles lorsque GA4 affiche 1 240 achats, la plateforme e-commerce 1 263 et le système de paiement 1 251. L’objectif n’est pas que tous les outils affichent exactement le même chiffre ; l’objectif est de savoir quel outil sert à quelle décision et pourquoi les écarts existent.

Limiter le bruit dans les conversions et les audiences publicitaires

Dans GA4, marquer un événement comme conversion est une décision stratégique. Trop d’équipes transforment des micro-interactions en conversions pour donner plus de volume aux rapports ou aux plateformes publicitaires. Cette pratique peut être utile pour certains algorithmes en phase d’apprentissage, mais elle devient dangereuse si la valeur relative des signaux n’est pas maîtrisée.

Une conversion GA4 devrait répondre à l’un de trois critères : elle représente une valeur business directe, elle est statistiquement prédictive d’une valeur future, ou elle sert explicitement une optimisation média avec un garde-fou de qualité. Un achat est une conversion directe. Un lead validé peut l’être. Un début de checkout peut être une micro-conversion utile, mais il ne devrait pas être interprété comme un résultat business final. Un scroll à 75 % ou un clic sur une FAQ sont rarement des conversions ; ce sont des signaux explicatifs.

Le risque est particulièrement fort dans les environnements média automatisés. Si une campagne paid social optimise sur view_pricing parce que les achats sont trop rares, elle peut apprendre à trouver des visiteurs curieux du prix mais peu enclins à acheter. Si une campagne optimise sur add_to_cart sans intégrer la marge, elle peut favoriser des produits fortement remisés. Si une campagne optimise sur form_start, elle peut réduire le CPA apparent tout en dégradant le taux de qualification. Le plan de taggage doit donc distinguer les signaux de pilotage interne des signaux envoyés aux plateformes.

Un framework pratique consiste à classer les événements selon une échelle de valeur de 0 à 4. Niveau 0 : interaction informative, comme scroll ou clic secondaire. Niveau 1 : engagement faible, comme consultation pricing ou vue vidéo complète. Niveau 2 : intention moyenne, comme ajout panier ou début formulaire. Niveau 3 : conversion validée, comme achat ou lead soumis. Niveau 4 : valeur confirmée, comme marge positive, lead qualifié, rendez-vous tenu, abonnement actif après période d’essai. Les conversions GA4 standard peuvent inclure les niveaux 3 et 4 ; les niveaux 1 et 2 doivent être utilisés avec prudence, souvent comme audiences ou métriques explicatives.

Cette logique doit aussi guider la construction des audiences. Une audience de retargeting basée sur tous les visiteurs pricing peut être trop large. Une audience basée sur visiteurs pricing ayant consulté une intégration, passé plus de 45 secondes sur la page et n’ayant pas soumis de formulaire peut être plus pertinente, mais attention à la complexité : plus l’audience est fine, plus elle peut devenir instable, difficile à scaler et sensible aux trous de consentement. Le bon compromis dépend du volume. Une règle empirique utile : si une audience contient moins de quelques milliers d’utilisateurs actifs sur une période pertinente, elle risque d’être peu exploitable en média, sauf dans des dispositifs très ciblés.

Enfin, les événements utilisés pour créer des audiences doivent être audités après lancement. Une hausse brutale de 300 % d’une audience peut signaler une campagne réussie, mais aussi un tag déclenché deux fois ou un changement de page. Les audiences média ne sont pas des entités abstraites ; elles sont directement dépendantes de la qualité du plan de taggage.

Mettre en place une gouvernance pour éviter la dérive événementielle

Un plan de taggage se dégrade rarement d’un coup. Il se dégrade par ajouts successifs. Une campagne urgente demande un événement temporaire. Une refonte ajoute de nouveaux composants. Une équipe CRM veut un nouveau segment. Une agence média demande un signal d’optimisation. Un product owner ajoute un tracking pour une fonctionnalité. Chacun a une raison valable localement ; collectivement, le système devient illisible.

La gouvernance doit donc être explicite. Elle peut reposer sur un comité léger réunissant analytics, marketing, produit, CRO, CRM et, lorsque les données sont sensibles, juridique ou DPO. Le DPO, data protection officer, délégué à la protection des données, veille notamment à la conformité des traitements de données personnelles. L’objectif n’est pas de ralentir chaque tag, mais de protéger la cohérence globale.

Chaque nouvel événement devrait passer par une fiche de demande comprenant : nom proposé, définition exacte, déclencheur, source de données, paramètres, finalité, décision associée, durée de conservation analytique, niveau de valeur, besoin de consentement, propriétaire métier et méthode de QA. QA, quality assurance, désigne le processus de vérification avant mise en production. Sans propriétaire, un événement devient orphelin ; personne ne saura quand le supprimer ou le corriger.

Le plan doit aussi inclure un registre de versions. Un changement de définition est plus dangereux qu’un nouveau tag. Si generate_lead correspondait hier à un formulaire validé et correspond demain à un clic sur envoyer, les tendances deviennent fausses. Chaque modification doit être datée, documentée et communiquée aux utilisateurs des dashboards. Dans les analyses longues, notamment en CRO ou en marketing mix modeling, méthode statistique utilisée pour estimer l’impact des leviers marketing sur les ventes, les ruptures de définition peuvent être confondues avec des effets business.

Un audit trimestriel est souvent suffisant pour les organisations de taille moyenne. Il doit répondre à cinq questions : quels événements n’ont pas été utilisés dans les 90 derniers jours ? Quels événements ont un volume anormalement faible ou élevé ? Quels paramètres critiques sont souvent vides ? Quels événements doublonnent une même action ? Quelles conversions GA4 ne correspondent plus aux objectifs business ? Cette revue permet de supprimer, fusionner ou reclasser les signaux inutiles.

Les seuils chiffrés aident à objectiver. Par exemple, tout événement de diagnostic doit avoir une date d’expiration. Tout événement avec moins de 100 occurrences mensuelles et aucune décision associée doit être revu. Tout paramètre critique manquant dans plus de 10 % des cas doit déclencher une correction. Toute conversion GA4 doit être reliée à un niveau de valeur documenté. Ces règles ne sont pas universelles, mais elles transforment la propreté analytics en pratique opérationnelle.

Tester la qualité du plan avec des cas d’usage réels, pas avec une checklist technique

Un plan de taggage peut sembler propre dans un document et échouer dès qu’une équipe tente de répondre à une question concrète. La validation doit donc passer par des cas d’usage. La checklist technique vérifie que les événements se déclenchent. Le test analytique vérifie qu’ils permettent de décider.

Premier cas d’usage : analyser un funnel de conversion. L’équipe doit pouvoir reconstituer les étapes clés, segmenter par canal, device, type d’utilisateur et catégorie produit, puis identifier où la valeur décroche. Si les étapes ne sont pas comparables, si les événements se déclenchent à des niveaux différents de validation, ou si les paramètres essentiels manquent, le plan n’est pas prêt.

Deuxième cas d’usage : évaluer un test A/B. Un test de simplification formulaire ne doit pas seulement mesurer le taux de soumission. Il doit suivre l’exposition à la variante, le début de formulaire, les erreurs par champ, la soumission validée, la qualification CRM et les garde-fous comme le taux de spam ou le taux de no-show commercial. Si l’événement d’exposition n’est pas fiable, l’analyse sera contestable. Si la qualification n’est pas reliée, l’équipe optimisera une micro-conversion.

Troisième cas d’usage : piloter une campagne média. Pour une campagne d’acquisition, il faut vérifier que les UTM, paramètres ajoutés aux URL pour identifier la source, le medium, la campagne et parfois le contenu publicitaire, sont cohérents, que les événements de conversion sont dédupliqués et que les audiences ne mélangent pas prospects et clients existants. Une convention UTM instable peut créer autant de bruit qu’un mauvais événement. paid_social, paidsocial et social_paid peuvent fragmenter les rapports et fausser les analyses de performance.

Quatrième cas d’usage : relier marge et conversion. En e-commerce, une hausse de 12 % du taux de transaction peut être négative si elle provient d’une surreprésentation de produits à faible marge ou de promotions agressives. Le plan doit permettre de segmenter par marge estimée, remise et type de client. Sinon, la CRO risque d’optimiser le chiffre d’affaires attribué plutôt que la rentabilité incrémentale.

Un exemple synthétique illustre l’intérêt. Une enseigne observe 1,2 million de sessions mensuelles, un taux d’ajout panier de 8 %, un début checkout de 5 % et un achat de 2,1 %. Le dashboard global suggère un problème de checkout. Mais le plan GA4 propre montre que le décrochage est concentré sur mobile, nouveaux clients, produits volumineux, délai de livraison supérieur à 6 jours. L’événement view_delivery_info est consulté par 64 % de ce segment avant abandon. L’hypothèse CRO devient précise : l’incertitude logistique bloque les nouveaux clients avant paiement. Le test pertinent n’est pas de raccourcir le checkout, mais d’afficher plus tôt les conditions de livraison et les alternatives. Sans paramètres de contexte, l’équipe aurait travaillé sur la mauvaise friction.

Conclusion : une méthode actionnable pour un plan de taggage GA4 sans bruit

Structurer les événements GA4 sans bruit ne consiste pas à réduire artificiellement la mesure. Il s’agit de construire une donnée plus utile, plus stable et plus décisionnelle. Dans un environnement où les signaux utilisateurs sont fragmentés par le consentement, les bloqueurs, le cross-device et les limites d’attribution, la qualité du plan de taggage devient un avantage compétitif. Les équipes qui savent distinguer valeur, progression, qualification, expérience et diagnostic analysent plus vite et décident mieux.

Une méthode opérationnelle tient en huit étapes. Premièrement, partir des décisions business et non de l’inventaire des composants du site. Deuxièmement, classer les événements par niveau de valeur : macro-conversions, micro-conversions prédictives, signaux explicatifs et diagnostics temporaires. Troisièmement, définir une taxonomie stable avec des noms génériques et des paramètres normalisés. Quatrièmement, limiter les paramètres à ceux qui changent réellement l’interprétation, en surveillant la cardinalité et les valeurs manquantes. Cinquièmement, rapprocher les événements critiques des sources de vérité serveur, paiement ou CRM. Sixièmement, sélectionner avec prudence les conversions GA4 et les signaux envoyés aux plateformes média. Septièmement, installer une gouvernance avec propriétaire, documentation, QA, versioning et audit trimestriel. Huitièmement, valider le plan sur des cas d’usage réels : funnel, test A/B, campagne média, marge et qualification.

La règle finale est simple : chaque événement doit mériter sa place. S’il ne modifie aucune décision, s’il n’explique aucun mécanisme important, s’il n’est pas fiable ou s’il duplique un signal existant, il ajoute du bruit. À l’inverse, un petit nombre d’événements bien définis, enrichis par des paramètres utiles et reliés aux systèmes de valeur, peut transformer GA4 en véritable infrastructure CRO. La performance ne vient pas de la quantité de données collectées, mais de la capacité à produire des preuves comparables, interprétables et suffisamment robustes pour déplacer un budget, modifier un parcours ou arrêter une fausse bonne idée.