Comment fonctionne la mesure

Les analyses de documentation mentent généralement de quatre façons : les robots d’exploration comptés comme des lecteurs, les onglets en arrière-plan comptés comme de la lecture, les propres visites du propriétaire comptées comme une audience et les pourcentages annoncés sur quelques visites seulement. Cette page expose le mécanisme afin que vous puissiez vérifier chacune de ces affirmations vous-même avant de vous fier à un chiffre.

Ce que vous obtenez#

Chaque graphique du panneau d’analytique de Docsbook est dérivé d’un seul flux d’événements, selon une seule définition d’une visite et une seule définition d’un humain — et non d’un ensemble de compteurs indépendants susceptibles de diverger. Lorsqu’un nombre ne peut pas être présenté honnêtement, vous obtenez un tiret, le libellé « non mesuré » ou un pourcentage masqué, jamais un 0 affiché avec assurance. Et rien n’est stocké dans les navigateurs de vos lecteurs pour produire quoi que ce soit de tout cela.

Ce qui est collecté et ce qui ne l’est délibérément pas#

Docsbook enregistre 36 événements docs.* nommés sur votre site de documentation — consultations de pages, segments de temps de lecture, titres parcourus jusqu’à leur apparition à l’écran, recherches, actions de chat IA, copies, clics de navigation, clics sortants, votes de feedback et sorties. La référence complète des événements suivis en fournit la liste.

Chaque événement indique le projet auquel il appartient, le chemin de la page et, selon le cas : les secondes, l’ancre du titre, le référent, l’hôte de destination, la langue, l’agent utilisateur, ainsi que le pays/la région/la ville/les coordonnées que le serveur edge a déduits de la requête. L’adresse IP du lecteur est ajoutée côté serveur, au point de terminaison d’ingestion, jamais par le navigateur.

Comment sont définis un visiteur et une visite#

Un visiteur est sha256(secret salt + project + IP), tronqué à 16 caractères hexadécimaux. C’est toute l’identité. Elle est stable — la même personne la semaine prochaine obtient le même identifiant — et elle est isolée : le sel est un secret côté serveur et le nom du projet fait partie de l’entrée, de sorte que l’identifiant ne peut pas être associé au trafic d’un autre site, y compris celui d’un autre projet Docsbook.

Une visite est reconstruite à partir des événements, et non suivie à l’aide d’un cookie de session. Les événements d’un visiteur sont triés par heure et découpés dès qu’un intervalle de plus de 30 minutes survient. Il s’agit volontairement d’un intervalle d’inactivité, et non d’un créneau horaire fixe : le découpage en créneaux fractionne une visite qui chevauche une limite, de sorte qu’un lecteur actif de 12:29 à 12:31 serait sinon comptabilisé comme deux visites.

Comment les bots et les robots d’exploration sont filtrés#

Le filtrage s’effectue en deux couches indépendantes, car chacune d’elles est connue pour échouer seule.

1. Agent utilisateur. Une expression régulière couvrant les robots d’exploration, les robots, les navigateurs sans interface, les clients HTTP scriptés, les suites SEO et les récupérateurs d’aperçus de liens, ainsi que chaque bot d’IA présent dans le tableau du classifieur. Deux chaînes UA littérales sont épinglées, car elles ont été observées en train d’explorer à grande échelle tout en se faisant passer pour des téléphones ordinaires — un appareil de référence Googlebot Smartphone et une ancienne version d’iOS.
2. Comportement. Une visite qui n’a produit aucun événement qu’un environnement d’exécution JavaScript peut émettre — aucun segment de temps de lecture, aucune consultation de titre, aucune sortie, aucun clic — n’a pas exécuté JavaScript et est donc celle d’un robot d’exploration, quel que soit son agent utilisateur.

En outre, votre propre équipe est exclue de toutes les statistiques de lecteurs. Un visiteur dont l’adresse IP a également envoyé une balise de session d’administration pour ce projet au cours des 30 derniers jours est identifié comme le propriétaire et exclu des statistiques de lecture — séparé du statut de bot, car il s’agit bien d’un humain, mais pas de votre audience. En option, une liste d’autorisation d’adresses IP côté serveur exclut le trafic interne avant même qu’il soit enregistré.

Les visites de bots et de propriétaires sont conservées et étiquetées, et non supprimées, afin que l’interface puisse vous montrer la répartition plutôt que de réduire silencieusement vos chiffres.

Comment le temps de lecture est réellement calculé#

Le dispositif de suivi démarre un chronomètre lorsqu’une page est montée et l’arrête lorsque le lecteur la quitte — sur pagehide, sur visibilitychange → hidden sur iOS (où pagehide n’est pas fiable), ainsi que lors de la navigation sur le site. Chaque lecture génère un docs.read_time segment et réinitialise le chronomètre, de sorte qu’une page consultée à nouveau produit deux segments plutôt qu’une seule durée comptée deux fois. Les segments de moins de 3 secondes ne sont pas générés.

Les données sont envoyées via navigator.sendBeacon vers un point de terminaison de même origine, par lots de 100 événements au maximum par beacon. Le transport de journalisation ordinaire applique une temporisation de deux secondes via fetch, ce qui ne résiste pas à la fermeture d’un onglet — le temps de lecture, les consultations de titres et les sorties sont les événements qui doivent y survivre ; ils empruntent donc le chemin beacon.

Chaque segment est ensuite limité à 300 secondes avant toute addition. C’est le nombre le plus important de cette page. L’émetteur continue de compter lorsqu’un onglet de bureau reste en arrière-plan et, lors d’un examen de 11 176 sessions réelles réparties sur 7 espaces de travail, 40 segments individuels dépassaient deux heures, le 99e percentile était de 81 342 secondes et la somme des segments bruts gonflait le temps de lecture total d’environ trente fois — 1 268 422 secondes contre 42 160 une fois la limite appliquée. Cette même limite est appliquée par chaque interface qui affiche une durée, si bien que le panneau, la colonne par page, la couche des objectifs et les outils MCP ne peuvent pas diverger.

Le temps de lecture moyen par page divise le total limité par le nombre de segments, et non par le nombre de visites : un lecteur qui s’éloigne d’un onglet puis y revient contribue deux segments à une même visite, et une moyenne calculée par visite créditerait cette visite deux fois.

Comment le trafic des assistants IA est distingué du trafic humain#

Les requêtes sont classées en trois groupes qui ne sont jamais fusionnés :

Un nom de bot IA non reconnu est traité comme de l’entraînement — l’affirmation qui vous promet le moins. La classification se fait selon le User-Agent, dans l’ordre où le premier résultat l’emporte, de sorte que Applebot-Extended n’est jamais absorbé par Applebot.

Échantillonnage, plafonds et conservation#

Il n’y a pas d’échantillonnage. Aucun chiffre du panneau n’est extrapolé à partir d’un sous-ensemble du trafic. À la place, il existe un plafond strict : la reconstruction de session lit au maximum 50 000 événements par fenêtre, et lorsqu’elle atteint ce plafond, le résultat contient un truncated indicateur que les consommateurs doivent afficher, car les taux calculés sur une fenêtre tronquée sont incorrects. Une requête qui échoue est également signalée comme ayant échoué plutôt que comme valant zéro — un tableau de bord vide et une lecture défaillante sont deux réponses différentes.

Les événements des lecteurs sont conservés pendant 30 jours, quelle que soit l’offre. Trente jours, c’est là que les données s’arrêtent, et non un niveau d’offre : il s’agit de la durée de conservation du magasin d’événements. Chaque sélecteur de période du produit lit la même constante, de sorte qu’aucun contrôle ne puisse proposer une fenêtre que les données ne peuvent pas couvrir. Le registre d’utilisation de l’IA est stocké séparément et conservé plus longtemps — 90 jours, avec une purge quotidienne — afin qu’une facture contestée puisse encore être reconstituée après que les rapports ont cessé de l’afficher ; de toute façon, aucun rapport ne propose plus de 30 jours de données.

Où résident les données#

Les chiffres de Search Console affichés dans le panneau sont récupérés auprès de Google via la connexion que vous autorisez, et constituent les données de Google, pas celles de Docsbook.

Confidentialité et RGPD — quels sont les faits techniques et quelle est votre décision#

Faits techniques, vérifiables dans le comportement du site :

• Les outils d’analyse du site de documentation de Docsbook n’écrivent rien sur l’appareil du lecteur et ne lisent rien à partir de celui-ci. Il n’y a aucun cookie d’analyse ni identifiant stocké par le navigateur.
• L’identité du lecteur est dérivée de l’adresse IP au moyen d’un hachage avec clé, côté serveur, limité à votre projet. Le hachage est à sens unique ; l’adresse IP brute n’est exposée dans aucun rapport, aucune exportation ni aucun outil MCP.
• Aucun identifiant n’est partagé entre les projets, et aucun n’est vendu, syndiqué ou utilisé pour constituer un profil intersites.
• La conservation est de 30 jours et est appliquée par le stockage, et non par un filtre de rapport.

Ce que nous ne prétendons pas. Docsbook n’affirme pas que son utilisation rend votre site exempt de consentement, conforme au RGPD ou exempt de toute règle nationale. Deux éléments que votre propre conseil juridique doit déterminer :

1. La règle du consentement au titre de l’ePrivacy s’applique-t-elle ? L’article 5(3) de la directive 2002/58/CE (telle que modifiée) subordonne « le stockage d’informations ou l’accès à des informations déjà stockées dans l’équipement terminal » au consentement. Docsbook ne stocke et ne lit rien sur l’appareil, ce qui constitue le déclencheur mentionné par cette disposition — mais les Orientations 2/2023 de l’EDPB sur le champ d’application technique de l’article 5(3) consacrent une section spécifique au « suivi fondé uniquement sur l’adresse IP ». Considérez donc « pas de cookie, donc pas de consentement » comme un argument, et non comme une réponse définitive.
2. Avez-vous malgré tout besoin d’une base juridique au titre du RGPD ? Une adresse IP qui identifie un lecteur constitue une donnée à caractère personnel, indépendamment de la question des cookies. Votre notice, votre base juridique et vos conditions applicables aux sous-traitants avec les fournisseurs ci-dessus sont donc de votre ressort. Les propres critères d’exemption de la CNIL pour la mesure d’audience constituent ici une liste de contrôle utile, et Docsbook en respecte plusieurs (éditeur unique, absence de mise en relation intersites, finalité limitée à la mesure d’audience) mais pas tous — notamment, il ne tronque pas le dernier octet de l’adresse IP avant de la stocker.

Pourquoi c’est la bonne méthode#

Limites et questions ouvertes#

• Chaque décompte de visiteurs est une estimation, et le produit le précise dans ses propres réponses. Une adresse IP hachée regroupe tous les utilisateurs derrière un même NAT d'entreprise en un seul lecteur et divise un même navetteur entre plusieurs lecteurs. Considérez les chiffres de visiteurs comme une tendance ; ne les citez jamais comme un nombre de personnes.
• Le temps de lecture est tronqué, et non conditionné par la visibilité. Sur ordinateur, un onglet laissé ouvert en arrière-plan continue d'accumuler des secondes jusqu'à ce que la limite de 300 secondes l'arrête. Cela décrit honnêtement le sens de son erreur — le temps de lecture est biaisé à la hausse, mais plafonné — mais il ne s'agit pas de la même mesure que le temps d'engagement fondé sur le focus de GA4, et cette documentation ne prétend pas le contraire.
• Les filtres anti-robots sont des heuristiques sans étape de vérification. Docsbook n'effectue aucune vérification par DNS inversé ni des plages d'adresses IP publiées pour contrôler l'identité déclarée par un robot d'exploration, de sorte qu'un User-Agent usurpé est classé tel quel. La couche comportementale détecte le cas courant qu'une expression régulière d'UA ne repère pas ; aucune des deux couches ne constitue un contrôle de sécurité.
• L'exclusion des propriétaires dépend d'un seul beacon. Un membre de l'équipe qui consulte la documentation mais n'a jamais ouvert le panneau d'administration depuis cette adresse IP au cours des 30 derniers jours est compté comme un lecteur.
• La géolocalisation IP identifie le réseau, pas la personne. Un VPN d'entreprise situe un lecteur dans la ville où le tunnel se termine ; un réseau mobile peut le localiser à une centaine de kilomètres.
• Question en suspens : « pas de cookie » ne signifie pas « aucun consentement requis ». Ce qui est vérifiable, c'est que l'analytique du site de documentation de Docsbook ne stocke ni ne lit rien dans le navigateur, et que l'identité du lecteur est un hachage côté serveur salé. Ce qui n'est pas tranché, c'est la conséquence juridique : l'EDPB a explicitement ouvert la question du suivi fondé uniquement sur l'adresse IP au titre de l'art. 5(3), et aucune source publique ne la résout pour un cas haché, first-party, de 30 jours. Considérez la conclusion en matière de conformité comme relevant de votre conseil juridique.
• Trente jours est un plafond strict. Aucune comparaison d'une année sur l'autre, aucune lecture saisonnière et aucun cohorte de plus de quatre semaines ne sont possibles à partir de ces données.

Articles associés#

• Référence des événements suivis — les 36 événements décrits sur cette page
• Vue d’ensemble des analyses — le panneau alimenté par ces définitions
• Temps de lecture — l’extrait appliqué à un rapport
• Objectifs et entonnoirs — ce qu’une visite est réputée avoir accompli
• Pays — la résolution géographique et ses limites en pratique