Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierinformatique général
  • ✇Korben
  • J'ai créé mon propre outil de stats sans tracking
    Un site sans cookie de mesure d'audience et sans bandeau de consentement, c'est reposant je trouve... Sauf qu'à cause de ça, bah je ne savais plus trop combien de gens venaient me lire tous les jours. Relou hein ? C'était ma situation depuis un moment déjà, vu que tout ce qui servait à mesurer l'audience a dégagé de korben.info il y a un bon bout de temps. Alors faute de mieux, je me suis rabattu sur AWStats, qui lit bêtement les logs Apache du serveur mais bon, c'est pas terrible, parce qu'avec

J'ai créé mon propre outil de stats sans tracking

Par : Korben ✨
21 juillet 2026 à 17:34

Un site sans cookie de mesure d'audience et sans bandeau de consentement, c'est reposant je trouve... Sauf qu'à cause de ça, bah je ne savais plus trop combien de gens venaient me lire tous les jours. Relou hein ?

C'était ma situation depuis un moment déjà, vu que tout ce qui servait à mesurer l'audience a dégagé de korben.info il y a un bon bout de temps. Alors faute de mieux, je me suis rabattu sur AWStats, qui lit bêtement les logs Apache du serveur mais bon, c'est pas terrible, parce qu'avec le cache de Cloudflare, il y a une grosse partie de mon trafic qui n'est pas pris en compte.

En effet, quand Cloudflare possède une copie valide de la page dans son cache, il peut la renvoyer directement sans contacter le serveur d'origine. Vous êtes donc bien un visiteur réel, mais Apache ne voit aucune requête et AWStats ne vous comptabilise pas. Du coup, tous les outils fondés exclusivement sur les logs d'origine sous-estiment la part du trafic absorbée par le cache.

Après il y a bien le classique Google Analytics, mais bon même configuré en mode full RGPD, ça reste Google et ça appelle quand même un service tiers aux US... Vous connaissez aussi déjà des alternatives propres, puisque je vous ai parlé de Matomo, Plausible et de Vince Analytics , mais elles ajoutent toutes une mesure côté navigateur, avec un script, un pixel ou un stockage local (le localstorage) et moi, je ne voulais aucun outil d'audience de plus dans vos pages !

De son côté, Cloudflare lui, voit chaque requête HTTP qui atteint son réseau, y compris celles auxquelles son cache répond. Ses chiffres couvrent donc beaucoup mieux le trafic HTTP que mes logs d'origine. Le souci, c'est que son dashboard, je ne l'aime pas. Je le trouve incomplet, mal foutu, chiant à utiliser, et il ne montre pas ce que j'ai envie de voir.

Donc, histoire d'avoir ce que je voulais, j'ai fini par coder le mien. Enfin, entièrement vibe codé et ça tourne aussi bien sur un serveur qu'en local sur une machine de bureau.

Petite parenthèse pendant que j'y suis, vous ne le savez peut-être pas mais depuis que ChatGPT a débarqué dans nos vies fin 2022, tout ce que je développe moi-même sur ce site et l'ensemble de mes outils internes sont vibes codés avec des LLMs comme ceux d'OpenAI et d'Anthropic. C'était une purge au tout début et maintenant ça s'est tellement amélioré et je me suis tellement spécialisé là-dedans, que le code n'est devenu qu'une formalité. Ne hurlez pas, mon site est statique et j'envoie pas de fusée dans l'espace !

Mon collecteur s'exécute en local, cause à une API, et il n'envoie pas une seule ligne de mesure dans votre navigateur. Bref, que mon backend soit écrit avec un LLM, à la main ou en Brainfuck, vous chargez exactement la même chose de mon outil de stats, c'est-à-dire rien du tout. La garantie est donc architecturale et pas une question de talent.

Et surtout, mon outil de stats n'ajoute aucune mesure dans votre navigateur. Aucun JavaScript ni cookie supplémentaire n'est posé par mon outil. À la place, il lit l'API GraphQL Analytics de Cloudflare, en lecture seule et récupère des compteurs déjà agrégés par jour et par dimension. Cela veut dire par exemple, que quand je récupère le nombre "nombre d'IP distinctes par jour", je ne récupère pas les IPs en tant que telles mais juste un total que Cloudflare me communique et qu'il a déjà traité en amont.

Et vous n'êtes pas obligés de me croire sur parole, parce que c'est vérifiable en 10 secondes... Ouvrez l'inspecteur de votre navigateur, onglet Réseau, et rechargez cette page. Vous ne verrez aucun script de mesure d'audience, aucun appel vers un domaine tiers et aucune iframe. Même les vidéos YouTube ne se chargent qu'au moment où vous cliquez sur la vignette. Le seul truc qui bouge, c'est le compteur du footer qui télécharge un nombre, sans rien renvoyer derrière.

Attention, ce n'est pas à confondre avec Cloudflare Web Analytics et ses mesures RUM (Real User Monitoring) puisque cette fonctionnalité injecte un bout de JavaScript pour mesurer les performances ressenties dans le navigateur. Chez moi, c'est désactivé tout ça.

Maintenant soyons clairs sur un point, parce que c'est l'objection évidente et qu'elle est parfaitement légitime... Cloudflare, lui, voit bien votre adresse IP. Pas à cause de mon outil de stats, mais parce que c'est un reverse proxy et que c'est mécaniquement ce qui se passe dès qu'un site est derrière un CDN. Votre requête arrive chez eux avant d'arriver chez moi, sinon ils ne pourraient ni router, ni mettre en cache, ni bloquer une attaque. Mon outil ne change rien à ça, il se contente de lire des totaux déjà calculés et je ne récupère jamais la moindre IP. Tout est détaillé dans mes CGU, avec les bases légales, les durées et la liste des cookies de sécurité, si vous voulez le détail complet.

Mon outil et le compteur que vous pouvez retrouver dans le footer de mon site reposent sur les requêtes collectées côté serveur chez Cloudflare et sans l'analyse web, je ne peux juste pas suivre par exemple un parcours utilisateur, connaitre un taux de rebond ou évaluer les temps de chargement mesurés chez les lecteurs. Rien de grave donc...

Maintenant, il y a un souci chez Cloudflare, c'est que selon le jeu de données et le forfait que vous payez ou non, le détail ne reste interrogeable que durant une fenêtre limitée de temps. Mon outil doit donc passer chaque jour récupérer les agrégats encore disponibles et les stocker dans une base SQLite sur mon serveur ou en local, selon la façon dont on l'a déployé.

Ça me permet de garder mon propre historique agrégé. J'ai aussi activé le Super Bot Fight Mode de Cloudflare, qui réduit une large partie du trafic automatisé, mais attention, ça ne me donne pas pour autant des stats sans aucun bot. Les crawlers autorisés comme Googlebot et ceux qui passent entre les mailles du filet restent comptabilisés dans mes chiffres, exactement comme avec tous les autres outils de mesure web. Et je préfère le dire clairement plutôt que de vous vendre des chiffres "propres" qui ne le sont jamais totalement, vu qu'un filtre anti-bot ne peut retirer que les bots qu'il a détectés.

À côté de ça, j'ai aussi branché ma Google Search Console, et là non plus sans installer la moindre bibliothèque tierce... Je signe moi-même un JWT en RS256 avec le module crypto natif de Node, je l'échange contre un jeton d'accès chez Google, et le compte de service que j'utilise est restreint au scope lecture seule. Ça m'apporte des statistiques agrégées sur les impressions, les positions, les requêtes de recherche et surtout Discover !!

Si je devais résumer ça, je dirais que Cloudflare estime le volume de trafic et que Search Console montre quelles recherches produisent des impressions et des clics, même si sans aucun tracking en place, ça n'explique évidemment pas la motivation de chaque lecteur. Mais osef ! Et comme Cloudflare embarque aussi son pare-feu, j'en profite pour rapatrier des statistiques sur les événements de sécurité et les routes attaquées, comme ça, je peux tout voir au même endroit.

Maintenant, le vrai plaisir, c'est de pouvoir afficher ce que je veux dans mon propre dashboard. Par exemple, la répartition par langue, les navigateurs, d'où provient le trafic avec un joli petit camembert, les pays, l'état de mon cache, la bande passante, etc. Et quand j'ai un nouveau besoin qui me pête dans le cerveau, je peux ajouter une vue rapidement et je ne m'encombre pas de ce qui ne me sert pas.

Sans traceur placé chez vous, je ne connais donc pas les sessions, le taux de rebond, le parcours de lecture, les entonnoirs de conversion, donc impossible de savoir si vous êtes revenu hier, ni dans quel ordre vous avez lu 3 articles. Mais je m'en tape complètement puisque ces métriques ne m'ont jamais servi à rien.

Ce que je veux connaitre, c'est surtout l'ordre de grandeur de l'audience et le nombre de pages demandées. Le parcours individuel et les entonnoirs de conversion, c'est surtout un besoin de régie publicitaire ou de site e-commerce, et pas d'un site comme le mien. Quand on sait que les bandeaux de cookies nous coûtent 575 millions d'heures perdues collectivement, et que l'Europe réfléchit enfin à les alléger , s'en passer n'est pas vraiment une punition.

Bref, mes stats sont maintenant plus digestes que celles d'AWStats, sans avoir à vous tracker ou vous faire charger quoi que ce soit. Ça me va donc très bien. Et si vous voulez un avant-goût de la technique derrière l'outil, j'ai montré récemment comment vous faire un compteur de fréquentation gratuit , donc n'hésitez pas à y jeter un œil...

  • ✇LinuxFr.org : les dépêches
  • Deno 2.0 est là
    Le temps où Node.js régnait en maître comme la solution incontournable pour exécuter du code JavaScript côté serveur est-il révolu ? En tout cas, il a aujourd’hui des challengers de taille comme Bun (qui pourrait lui aussi mériter une dépêche) ou Deno. C'est donc de ce dernier qu'il sera question dans cette dépêche, à l'occasion de la sortie de sa version 2.0 lien nᵒ 1 : Annonce sur le blog officiellien nᵒ 2 : Site officiel de Denolien nᵒ 3 : JSRSommaire Pour rappel La mascotte ! Deno 1.x, de

Deno 2.0 est là

Le temps où Node.js régnait en maître comme la solution incontournable pour exécuter du code JavaScript côté serveur est-il révolu ? En tout cas, il a aujourd’hui des challengers de taille comme Bun (qui pourrait lui aussi mériter une dépêche) ou Deno. C'est donc de ce dernier qu'il sera question dans cette dépêche, à l'occasion de la sortie de sa version 2.0

Sommaire

Titre de l'image

Pour rappel

Deno est un runtime JavaScript et TypeScript. Il a vu le jour suite au constat de Ryan Dahl (créateur aussi de Node.js), que Node avait des problèmes de conceptions, et qu'il était nécessaire de repartir de zéro en tenant compte de l'expérience de Node pour ne pas refaire les mêmes erreurs. Il imagine Deno comme un runtime avec un modèle de sécurité par défaut plus strict. Les programmes Deno n'ont pas accès au système de fichiers, au réseau ou à l'environnement, sauf si on leur accorde explicitement ces permissions. Deno est écrit en Rust, et se base sur le moteur JavaScript V8 de Google. Deno se distingue également de Node en offrant la possibilité d'importer les dépendances via des URL, mettant en cache chaque module lors de l’importation pour améliorer la vitesse d’exécution.

La mascotte !

La première chose notable quand on passe de Node.js à Deno, c'est sa mascotte ! En effet, même si Node.js possède bien une petite tortue comme mascotte, celle-ci n'est utilisée nulle part ! Personnellement, j'ai toujours trouvé bien plus chouettes les projets qui ont des petites bestioles comme mascotte (Mozilla, Tux …). Et chez Deno, le dinosaure mascotte est omniprésent sur tout le site. Et en plus, à l'occasion de la version 2.0, on peut habiller notre dino sur la home page du projet ! Et ça c'est cool ! Voici le mien, qui est en compagnie de Ferris, la mascotte officieuse de Rust !

Mon dino

Bon, comme je ne suis pas sûr que tout le monde partage ma passion pour les mascottes, on va passer au côté plus technique ! 🤣

Deno 1.x, des débuts difficiles !

La version 1.0 sortie en mai 2020 a du mal à se faire une place et reste dans l'ombre de son grand frère. En effet, même si Deno offre un grand lot de nouveautés et est plus sécurisé par défaut, la très large adoption de Node et le fait que les projets développés pour Node ne sont pas forcément compatibles avec Deno rend l’adoption de ce dernier difficile. De plus, l'utilisation de CDN plutôt que d'installer les dépendances localement (dans le répertoire node_modules) a certes de nombreux avantages, mais cela rend votre projet dépendant de disponibilité du réseau ou peut entraîner des problèmes de performances si le CDN est éloigné géographiquement.

Les nouveautés de la version 2.0

Deno est désormais 100% compatible avec Node.js, et un gestionnaire de paquets officiel a vu le jour. Vous pouvez maintenant utiliser deno add et deno removepour ajouter ou retirer un paquet à votre projet.

Autour du projet Deno, JavaScript Registry (JSR) un dépôt de paquets JavaScript universel !

Le registre NPM s'est construit autour de Node.js afin de gérer facilement les dépendances de nos projets. Il a donc été développé pour Node.js à une époque où Node était la seule solution pour exécuter du code JavaScript côté serveur. En près de 15 ans, le registre NPM a rassemblé un peu moins de 3 millions de paquets et a très largement rempli sa mission toutes ces années. Mais aujourd'hui, la situation a changé, il existe plusieurs runtimes pouvant exécuter du code JavaScript (ou TypeScript) côté serveur. Et du côté front-end, les frameworks se sont multipliés et sont devenus de plus en plus complexes et nécessitent aussi l'utilisation d'un gestionnaire de paquets. Un registre de paquets fondé autour de Node.js uniquement est donc beaucoup moins pertinent qu'en 2010.
C'est donc pourquoi, à l'initiative du projet Deno, un nouveau registre de paquets JavaScript et TypeScript universel pointe aujourd'hui le bout de son nez. Il s'agit donc de JSR (JavaScript Registry).

Dans JSR, quand on va sur la page d'un paquet, en haut à droite, on a les logos des environnements compatibles avec le paquet :

Titre de l'image

Performances du runtime

Niveau performance, ça donne quoi ?

On voit souvent l'affirmation que Deno serait plus rapide que Node.js. Mais ça donne quoi en réalité ?

J'ai voulu faire un petit test sans prétentions pour voir ce que ça donne. Je voulais faire des tests plus poussés sur différents systèmes d'exploitation et architectures, mais par manque de temps, le test sera donc fait sur un seul système et un seul ordinateur et il s'agit d'un Mac… Un comble pour LinuxFr.org, mais c'est l'ordinateur que j'avais à disposition à ce moment-là. Mais sinon, je ne porte pas spécialement Apple dans mon cœur, bien au contraire !

J'ai testé l’exécution d'une même API sur Node. et Deno pour voir les différences de performance entre ces solutions. Pour ce test, j'ai utilisé une API Rest que j'ai développée pour le site de la société AudioSoft. J'ai fait la même requête POST 10 fois sur la même route avec les mêmes données. Il est important de préciser que c'est la première fois que je fais ce genre de tests, et que je ne fais peut-être pas tout dans les règles de l'art. Il y a des éléments extérieurs à Node et Deno qui peuvent influencer les scores. Notamment, la base de données utilisée pour le test était accessible via Internet, et des différences de débit ont pu fausser les tests.

Test sur un MacBook Pro (2,6 GHz Intel Core i7 6 cœurs, AMD Radeon Pro 5300M 4 Go Intel UHD Graphics 630 1536 Mo, 16 Go 2667 MHz DDR4) sous macOS Sonoma

Node: Le temps moyen pour exécuter le test de 126 millisecondes
Deno: Le temps moyen pour exécuter le test de 93 millisecondes

Performances du gestionnaire de paquets

Comme dit précédemment, Deno c'est aussi un gestionnaire de paquets. J'ai donc trouvé intéressant de tester les principaux gestionnaires de paquets sur différents environnements.
Pour ce test je me base sur la même API Rest que pour le test précédant, les dépendances à installer pour cette API sont : bcrypt, body-parser, dotenv, express, jsonwebtoken, mariadb, multer, mysql2, nodemailer, et sequelize. Le test a été fait sur un MacBook Pro. Pour effectuer ce test, le cache des gestionnaires de paquets ont été nettoyés et les fichiers-verrous supprimés.

Avec NPM, l'installation a mis 10 secondes.

Avec Deno, l'installation a mis 1 seconde.

Avec Bun, l'installation a mis 3 secondes.

On voit très clairement que NPM est beaucoup plus lent que ses deux concurrents. L'écart est plus faible entre Deno et Bun. Mais Deno est bien le plus rapide des trois.

Avant de réaliser ce test, j'en ai effectué un en oubliant de nettoyer le cache et de supprimer package-lock.json. Les résultats étaient alors 8 secondes pour NPM, 5 secondes pour Deno et 4 secondes pour Bun. Il est logique de constater que NPM est plus rapide, en revanche, je trouve surprenant que Deno et Bun aient été ralentis. Il est possible que les gestionnaires de paquets aient parcouru package-lock.json pour garder les versions présentes dans ce fichier, ce qui les aurait tous les trois ralentis. Et NPM a peut-être pu bénéficier de son cache (car je l'utilise bien plus que les deux autres sur mon ordinateur), Deno et Bun eux n'avaient peut-être pas grand-chose dans leurs caches, ont donc été ralentis. Il est donc important de supprimer les lockfile en cas de migration d'un projet.

Comme je le disais plus haut, c'est la première fois que j'effectue ce genre de test comparatif. Si vous avez des conseils sur les bonnes méthodes pour faire des tests plus fiables, ça m’intéresse !

Deno 2.1 est là

Étant donné que j'ai mis environ un siècle pour rédiger cette dépêche, Deno 2.1 est sortie entre temps ! 🤣
Je vous liste donc les principales nouveautés apportées à la version 2.1 sans les commenter 😉

  • Support natif de WebAssembly (Wasm) : Il est désormais possible d'importer directement des modules Wasm, simplifiant leur utilisation et améliorant les performances.
  • Version Long Term Support (LTS) : Deno 2.1 inaugure la première version LTS, garantissant des correctifs de bugs et des améliorations de performance pendant… Six mois… On n'est pas encore aux 30 mois des versions LTS de Node.js… Cela viendra peut-être plus tard. 🙂
  • Commande deno init --npm vite : Cette commande simplifie la création de nouveaux projets en utilisant des outils comme Vite, en automatisant l'initialisation et en réduisant la configuration manuelle.
  • Gestion des dépendances : Introduction de la commande deno outdated pour gérer les mises à jour des dépendances JSR et npm.

Conclusion

Si vous êtes développeur Node.js, je vous conseille de vous intéresser à Deno, et même à Bun. Je ne sais pas si ces deux runtime sont totalement prêts pour des projets en production (par exemple, Deno 2.1 n'a que 6 mois de durée de vie, ce qui est plutôt contraignant pour les serveurs.). Mais peut-être que dans un futur proche, il sera cohérent de migrer vers l'un de ces deux-là.

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌
❌