Pourquoi j’ai créé un analyseur de disque

Les applications les plus utiles naissent de la frustration.

Mon Mac était plein. Pas « il reste quelques gigaoctets ». Plein pour de vrai. Le genre de saturation où Xcode refuse de compiler faute de place pour un fichier temporaire, et où l’on passe vingt minutes à effacer des captures d’écran de choses dont on ne se souvient même plus.

Il fallait que je comprenne où l’espace était passé.

Il existe déjà de très bons analyseurs de disque. DaisyDisk est soigné, GrandPerspective gratuit et solide. Je n’essayais de remplacer ni l’un ni l’autre, et Renala est gratuit de toute façon. (Le nom vient du malgache reniala, le baobab, de reny, « mère », et ala, « forêt », en écho à la palette terreuse et à la métaphore arborescente du treemap.) Ça n’a jamais été le but.

Je voulais en coder un moi-même. C’est tout. Je me suis lancé, persuadé que quelques week-ends suffiraient.

Il en a fallu bien plus. Et, pour une fois, m’être trompé m’a rendu service.

Un analyseur de disque, c’est un problème bien borné : un répertoire en entrée, une carte visuelle de ce qui mange l’espace en sortie. Ni comptes utilisateurs, ni requêtes réseau, ni schémas de base de données. Les difficultés sont identifiées d’avance : lire le système de fichiers, calculer une disposition, l’afficher.

Et au centre du projet, il y a aussi un algorithme très satisfaisant. Un treemap transforme chaque fichier en un rectangle dont la surface est proportionnelle à sa taille. Le dossier Docker de 30 Go est visuellement trente fois plus grand que le cache Xcode de 1 Go juste à côté. Ben Shneiderman a décrit le concept au début des années 1990 ; la variante « squarified », qui produit des rectangles plus proches du carré, est arrivée ensuite et reste la variante la plus utilisée. Quand j’ai lu l’article original, j’ai tout compris d’un coup : le signe d’un bon algorithme, c’est une idée qui paraît évidente a posteriori, même si la mise en œuvre exige du soin.

L’essentiel du travail backend est invisible : écrire du code, déployer un service, regarder des métriques bouger sur un graphe. Un analyseur de disque, lui, montre quelque chose de concret en secondes. On scanne un dossier, les rectangles apparaissent, et cet énorme bloc violet dans le coin, c’est Docker qu’on avait oublié là depuis trois mois. Pour apprendre, avoir un résultat concret en quelques secondes, ça vaut de l’or.

Je fais du backend et du web : TypeScript, .NET, Java, bases de données, APIs, pipelines de déploiement. Je n’avais jamais écrit une ligne de Swift, ni ouvert Xcode autrement que pour installer les outils en ligne de commande : tout le modèle applicatif de macOS, avec ses bundles, ses entitlements, son code signing et ses provisioning profiles, était pour moi une boîte noire. Je savais que ça existait de la même manière qu’on sait que la plomberie existe : ça fonctionne, on n’y pense pas, et on est profondément démuni le jour où l’on ouvre le mur.

J’aurais pu faire ça en Electron, un terrain que je connais déjà bien. Electron m’aurait donné un prototype fonctionnel dans l’après-midi, un binaire distribuable le lendemain, et 300 Mo de Chromium embarqués avec un navigateur de fichiers. Tout l’intérêt était de construire quelque chose de natif. Pas par conviction philosophique sur la qualité logicielle, même si ça a pesé dans la balance ; plus concrètement, j’utilisais macOS depuis des années sans avoir jamais compris comment la plateforme fonctionnait réellement. La signature, la sandbox, le processus de revue App Store, les recommandations d’interface : je voulais comprendre la plateforme que j’utilise au quotidien, pas simplement m’en servir.

Apprendre Electron ne m’aurait rien appris que je ne savais déjà ; apprendre Swift, SwiftUI et le SDK macOS m’ouvrirait des portes qu’on ne trouve nulle part ailleurs.

Au fond, j’ai créé Renala pour une raison simple : mon disque était plein, j’étais curieux, et je voulais fabriquer un outil dont je me servirais vraiment.

On ne publie pas un analyseur de disque avec un treemap cassé, on ne soumet pas à l’App Store une interface dont on a honte. Rien ne pousse autant à bien coder que d’être obligé de se servir de son propre outil.

Je me suis aussi fixé quelques principes non négociables dès le départ. L’application respecterait Don’t Make Me Think (chaque interaction évidente, aucun doute sur ce que fait un bouton), serait accessible dès le départ (VoiceOver, navigation au clavier, aucune information transmise uniquement par la couleur) et localisée dès le premier jour : onze langues, dont l’arabe avec sa disposition droite-à-gauche et ses formes plurielles. Ce ne sont pas des fonctionnalités qu’on affiche sur une page marketing : c’est le minimum syndical.

Au bout de quelques semaines, ça marchait. J’utilisais mon propre outil.

C’est là qu’un projet personnel devient un produit : pas quand il arrive sur l’App Store, ni quand quelqu’un d’autre le télécharge, mais quand on commence soi-même à l’utiliser.

Le disque était plein. Il ne l’est plus. Le reste, ce sont des détails.