Le logiciel personnel

Il existe une catégorie de logiciels que personne ne commercialise, que personne ne met en avant et que personne ne teste : les logiciels qu’on construit pour soi-même. Un public d’une seule personne. La communauté a commencé à appeler ça le logiciel personnel, et je crois que c’est en train de devenir la catégorie la plus intéressante qui soit.

Voici l’histoire du mien. Il s’appelle data, il tient sur une seule page sombre, et il affiche le trafic de tous mes projets côte à côte.

Le point de départ

Je fais tourner plusieurs petits produits, Posture, StoreScreenshot, Keto Life, mon portfolio, et la liste continue de s’allonger. Chacun envoie ses événements à PostHog, qui fait un travail remarquable pour tout collecter : pages vues, événements custom, session replays, géolocalisation, tout y est.

Mais chaque matin, prendre des nouvelles signifiait ouvrir un projet PostHog par produit, autant de dashboards, et une interface pensée pour servir toutes les entreprises de la planète. PostHog a des centaines de fonctionnalités. J’en utilise peut-être douze. Les autres ne sont pas un bonus : elles sont du bruit entre mes chiffres et moi.

Ce que je voulais vraiment tient en une phrase : une page privée, tous mes projets, les visiteurs par jour, d’où ils viennent, et qui ils sont.

J’ai donc construit exactement ça, et rien d’autre.

La forme de la solution

L’architecture est presque gênante de simplicité :

PostHog Cloud   (le cerveau : chaque événement, chaque replay)
     ▲
     │  HogQL via HTTPS, clé API personnelle
     │
Serveur Hono    (un processus Node, bundlé en un seul fichier)
     ▲
     │  JSON, mis en cache agressivement
     │
React + Vite    (le visage : une page, tous mes projets)

PostHog est le cerveau. Il continue de faire ce qu’il fait le mieux : capturer tout de manière fiable, le stocker dans ClickHouse, l’exposer via HogQL, leur dialecte SQL. Je n’ai pas reconstruit une goutte d’infrastructure analytics.

Mon application n’est que le visage. Un petit serveur Hono pose à PostHog des questions comme celle-ci :

SELECT toString(person_id) AS personId,
       min(timestamp)      AS firstSeen,
       max(timestamp)      AS lastSeen,
       count()             AS pageviews,
       argMax(properties.$geoip_country_name, timestamp) AS country
FROM events
WHERE event = '$pageview'
  AND timestamp >= now() - INTERVAL 7 DAY
GROUP BY personId
ORDER BY lastSeen DESC

… et une page React affiche les réponses comme je les aime : sombres, avec des graphiques en pixels tramés, et zéro écran de configuration.

Et la sécurité ?

Le dashboard n’a aucune authentification, et c’est un choix assumé, pas un oubli. Il est rendu possible par une seule décision : l’application n’existe qu’à l’intérieur de mon tailnet.

Un tailnet, c’est le réseau privé que Tailscale tisse entre vos appareils : mon laptop, mon téléphone et mon serveur détiennent des clés WireGuard et se parlent à travers un maillage chiffré, quel que soit le réseau où ils se trouvent. Le dashboard écoute sur l’adresse tailnet du serveur, jamais sur une adresse publique. Vu d’Internet, il n’y a aucun port à scanner, aucune URL à deviner, aucune page de login à forcer. Le service n’existe tout simplement pas.

Cette seule propriété remplace toute la couche login/permissions/réglages qui dévore la moitié du code de n’importe quel vrai produit. Un produit doit authentifier des inconnus ; mon dashboard ne répond qu’à des appareils que j’ai enrôlés moi-même. Le logiciel personnel a le droit de tricher comme ça.

Deux lignes de défense supplémentaires, au cas où un appareil du tailnet serait un jour compromis. La clé API PostHog vit sur le serveur et n’atteint jamais le navigateur, qui ne reçoit que des chiffres agrégés. Et chaque valeur interpolée dans une requête HogQL est d’abord strictement validée par motif, si bien que même un client malveillant sur le réseau ne pourrait pas transformer un paramètre en injection.

Ce qui a changé : le coût d’une fonctionnalité

Cet outil n’est jamais terminé, et c’est exactement le but. Chaque fois qu’une question me traverse l’esprit, je la décris à un agent IA, et la vue existe peu après. Pas une maquette : livrée, typée, vérifiée contre les données de production.

Une vraie journée avec lui, cette semaine :

• « J’aimerais un accès rapide à mes derniers visiteurs, cinquante par page. » → Une heure plus tard : une liste de visiteurs paginée. L’agent a même découvert en route que PostHog interdit OFFSET avec une clé API personnelle, et a silencieusement basculé l’implémentation vers une pagination par curseur.
• « Est-ce que je peux cliquer sur un événement et voir qui l’a déclenché, avec quel lien ? » → Le même après-midi : une modale plein écran, qui monte depuis le bas comme l’overlay de ce portfolio, listant chaque occurrence avec son visiteur et ses propriétés custom.
• « Pourquoi mes visiteurs apparaissent-ils en direct ? » → L’agent a fouillé le dashboard, le code de mon portfolio et l’historique git, et a trouvé que mes liens produits portaient rel="noreferrer", et que mes tags UTM avaient un jour d’existence.

Il y a un an ou deux, chacune de ces demandes aurait coûté une soirée que je n’avais pas. Le backlog aurait grossi, l’outil aurait stagné, et je serais retourné penaud vers l’interface généraliste. À l’ère agentique, mon outil d’analytics grandit à la vitesse de ma curiosité.

Pourquoi le privé bat le généraliste

Un outil généraliste doit servir tout le monde, il doit donc embarquer toutes les fonctionnalités dont quelqu’un pourrait avoir besoin, derrière des menus assez profonds pour toutes les contenir. Le logiciel personnel inverse le contrat : il fait exactement votre travail, avec une surface si petite qu’elle se lit d’une traite.

Et il y a un bénéfice notable. Ce dashboard sait des choses que je préfère garder pour moi : quel produit décolle et lequel non. Il tourne sur mes machines, sur mon tailnet, pour moi. Du logiciel privé pour des données privées.

Conclusion ?

Le geste intéressant n’était pas de construire un dashboard. C’était de remarquer que l’équation “construire ou acheter” s’est inversée le jour où le coût de construction s’est effondré.

PostHog reste, parce que collecter et stocker des événements de manière fiable est authentiquement difficile, et qu’il y excelle. Tout ce qui vit au-dessus, la partie qui n’est que mes préférences projetées sur mes données, coûte désormais moins cher à posséder qu’à configurer.

Je l’écrivais déjà à propos de mes scripts de déploiement, et c’est encore plus vrai ici : posséder ses outils, c’est posséder son temps. Le logiciel personnel, c’est ce que devient cette possession quand elle se cumule.