Ce que la mesure d’audience en temps réel peut — et ne peut pas — m’apprendre

Je voulais mieux comprendre le comportement de mon site dans de vrais navigateurs. Les journaux du serveur montrent les requêtes et aident à estimer les pages vues probablement humaines, mais ils ne décrivent pas toute l’expérience sur l’appareil d’un visiteur.

C’est ce qui m’a amené à préparer Amazon CloudWatch Real User Monitoring (RUM). Le nom paraît plus catégorique que ne le justifient les données ; il me semble donc utile de préciser ce que cette configuration peut et ne peut pas dire.

Un signal limité, recueilli avec consentement

L’intégration prévue dans le navigateur est volontairement limitée. Le site demande d’abord l’accord du visiteur ; le client AWS ne se charge qu’après un clic sur « Autoriser ». En cas de refus, aucune donnée RUM n’est envoyée. Le choix est enregistré dans le navigateur et le visiteur peut retirer son consentement par la suite.

Seule une partie des sessions ayant donné leur consentement est sélectionnée : 5 %. C’est un paramètre d’échantillonnage, pas la promesse que 5 % des personnes seront comptabilisées. L’échantillonnage est probabiliste, et les personnes qui ne consentent pas sont totalement absentes des données RUM.

La configuration porte sur les événements de consultation de page et de session. La relecture des sessions, les cookies RUM, X-Ray, ainsi que les collecteurs d’erreurs, HTTP et de performances sont désactivés. AWS conserve les événements pendant 30 jours dans la région USA Est (Virginie du Nord). La requête réseau révèle nécessairement une adresse IP ; les événements peuvent également contenir le chemin de la page, un horodatage, des informations techniques sur le navigateur et l’appareil, ainsi que des identifiants pseudonymes de session ou Cognito. Le chemin de la page ne contient pas les paramètres de requête.

Ce signal ne compte pas les visiteurs

L’échantillonnage à 5 % associé au consentement volontaire produit un signal parcellaire et sélectif. Il ne représente pas tous les visiteurs et ne permet pas de savoir combien de personnes uniques utilisent le site. Les sessions du navigateur, les pages vues comptées côté serveur et les requêtes CDN sont des mesures différentes, chacune avec ses angles morts.

Je garderai ces mesures séparées. RUM pourra m’aider à observer l’activité des navigateurs dans l’échantillon. Les compteurs côté serveur existants resteront des estimations fondées sur le filtrage des requêtes, pas des identités vérifiées. Le total des requêtes CDN inclut aussi les ressources et le trafic automatisé. Les réunir sous un seul chiffre de « visiteurs » rendrait le résultat moins honnête, pas plus utile.

Les garde-fous de coûts ont leurs limites

Les événements RUM et les services AWS associés peuvent engendrer des frais. L’échantillonnage de 5 % réduit le volume attendu, mais ne constitue pas un quota : un client autorisé peut être appelé directement, et un attaquant pourrait envoyer des événements en contournant la logique d’échantillonnage du navigateur.

La conception prévoit une alarme qui surveille les pics d’événements ingérés et une fonction Lambda qui ajoute un refus IAM explicite au rôle invité. Cela me donne un moyen d’arrêter l’ingestion après la prise d’effet de l’alarme et des changements IAM. En revanche, les événements déjà acceptés ne peuvent pas être retirés, et la surveillance comme la coupure ont des délais de propagation. C’est une mesure de protection, pas un plafond de dépenses garanti.

Je conserve aussi le mécanisme existant qui suspend les changements AWS à l’échelle du compte chaque mois, et j’exige un nouvel examen des coûts avant toute modification AWS. Ces contrôles sont utiles, mais aucun ne peut garantir en temps réel le montant exact de la facture. Un pic soudain peut coûter davantage avant que l’alarme ne réagisse. Ce risque résiduel fait partie de la décision ; un tableau de bord rassurant ne peut pas le faire disparaître.

Activé, mais il reste des éléments à vérifier

Le client de consentement et la notice de confidentialité localisée sont déjà en place sur le site. Le client demande d’abord l’accord du visiteur et ne charge le SDK AWS qu’après un clic sur « Autoriser ». Le runbook d’activation indique que l’autorisation limitée d’ingestion RUM a été déverrouillée le 11 novembre 2026. L’échantillonnage de 5 % des sessions ne s’applique qu’après consentement ; il ne constitue pas un décompte de tous les visiteurs.

Le chemin est donc ouvert, mais cela ne me dit pas encore à quoi ressemble le signal en production. Je n’ai pas confirmé la réception d’événements provenant de vrais navigateurs ni vérifié la facture correspondante. Je n’ai pas non plus testé le seuil réel de l’alarme. Le seuil configuré surveille l’ingestion d’au moins 20 événements en 60 secondes et demande à une fonction Lambda d’ajouter un refus IAM au rôle invité. Il ne peut pas retirer les événements déjà acceptés, et la surveillance, la notification ainsi que les changements IAM prennent du temps à se propager. Un pic soudain peut coûter davantage avant que l’arrêt ne prenne effet.

Ce seuil est un mécanisme de réaction, pas un plafond de dépenses strict. Le mécanisme mensuel de sécurité du compte bloque les changements supplémentaires effectués par l’agent lorsque son seuil est atteint ; il ne garantit pas le montant exact de la facture et n’arrête pas les services existants. Ces limites doivent accompagner tout résultat RUM, d’autant que le volume réel d’événements et les coûts restent à vérifier.

Je veux que la mesure reste limitée et compréhensible : demander d’abord le consentement, n’échantillonner qu’une petite part des sessions consentantes, garder séparées les mesures côté serveur et CDN, et dire clairement ce que les données et les garde-fous ne peuvent pas garantir.