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é.

De bons analyseurs de disque existent déjà. DaisyDisk est soigné, élégant. GrandPerspective est gratuit et solide. Je ne cherchais pas à les concurrencer, et Renala est gratuit de toute façon. Ça n’a jamais été le but.

Je voulais en construire un moi-même. Point. Je me suis lancé, persuadé que quelques week-ends suffiraient.

Il en a fallu considérablement plus. Mais cette erreur d’estimation a été salutaire.

Un analyseur de disque a un périmètre bien délimité. Une entrée claire : un répertoire. Une sortie claire : une carte visuelle de ce qui dévore l’espace. Pas de comptes utilisateurs, pas de requêtes réseau, pas de 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.

Il y a aussi, au cœur du projet, un algorithme satisfaisant. Un treemap transforme chaque fichier en un rectangle dont la surface est proportionnelle à sa taille. Votre 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 référence. Quand j’ai lu l’article original, j’ai tout compris d’un coup. C’est le signe d’un bon algorithme : l’idée paraît évidente a posteriori, même si la mise en œuvre exige du soin.

L’essentiel du travail backend est invisible. On écrit du code, on déploie un service, on regarde des métriques bouger sur un graphe. Un analyseur de disque, lui, montre quelque chose de concret en quelques secondes. On scanne un dossier, des rectangles apparaissent, et cet énorme bloc violet dans le coin se révèle être des images Docker oubliées depuis trois mois. Pour un projet d’apprentissage, des résultats visibles et rapides, ça vaut de l’or.

Je suis développeur backend et web. TypeScript, .NET, Java, bases de données, APIs, pipelines de déploiement. Je n’avais jamais écrit une ligne de Swift. Je n’avais jamais ouvert Xcode autrement que pour installer les outils en ligne de commande. Le modèle applicatif macOS, avec ses bundles, ses entitlements, son code signing et ses provisioning profiles, m’était totalement opaque. 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. Je connais JavaScript. 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.

La vraie raison pour laquelle j’ai créé Renala : mon disque était plein, j’étais curieux, et je voulais fabriquer quelque chose que j’utiliserais 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 à mieux coder que d’être obligé d’utiliser son propre logiciel.

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 devait être évidente, aucun utilisateur ne devrait avoir à se demander ce que fait un bouton. Elle serait accessible : prise en charge de VoiceOver, navigation au clavier, aucune information transmise uniquement par la couleur. Et elle serait localisée dès le premier jour, pas adaptée après coup : 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 à ce moment-là qu’un projet personnel devient un produit. Pas quand on le soumet à l’App Store. Pas quand quelqu’un d’autre le télécharge. Quand on commence à s’en servir soi-même.

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