studio

studio est un outil de développement de bureau qui gère le travail avec les moodboards, les coupes et les sessions - le genre de travail où un accès constant et rapide aux fichiers sur le disque compte. Cette étude de cas porte sur la manière de construire un tel outil nativement sans multiplier le code pour chaque système d'exploitation.

La prémisse était à double face. D'un côté, l'outil doit se comporter comme un programme natif : fichiers à portée de main, fonctionnement sans réseau, fluidité même sur une grosse session. De l'autre, il doit rester un seul repository et un seul cœur, pas trois applications séparées qu'il faut ensuite maintenir trois fois.

Travailler avec des moodboards et des coupes signifie tendre la main vers les disques en permanence : des centaines de fichiers, des répertoires de projet, des aperçus qui doivent apparaître instantanément. Un navigateur garde tout cela derrière un mur de bac à sable. Chaque accès à un fichier est un dialogue, pas de réseau signifie pas d'application, et sur une session plus grande l'interface commence à s'étouffer.

Nous voulions un outil qui a les fichiers à portée de main comme un programme natif, fonctionne sans réseau et ne ralentit pas sur une grosse session. Mais sans le piège dans lequel il est facile de tomber en écrivant nativement : du code séparé pour Windows, macOS et Linux qui ensuite dévie entre les plateformes et multiplie le travail à chaque changement.

Tauri inverse la disposition connue d'Electron. Vous écrivez l'interface une fois, sur le web, mais vous ne transportez pas tout un navigateur avec vous - la fenêtre utilise le moteur de rendu du système, tandis que tout le travail plus lourd, l'accès aux fichiers et la logique se trouvent dans un cœur Rust. Le résultat est un binaire mesuré en mégaoctets, pas en centaines de mégaoctets, et un accès réel au système qu'une page empaquetée n'a jamais eu.

La différence n'est pas cosmétique. Electron livre sa propre copie du moteur du navigateur avec chaque application, si bien que chaque outil paie à nouveau pour le même Chromium. Tauri utilise ce que le système a déjà et n'ajoute qu'une fine couche à lui. Pour un outil censé être rapide et léger, c'est la différence entre fonctionne et fonctionne instantanément.

La séparation est nette, et c'est elle qui tient toute l'architecture en bride : le web dessine, Rust fait. Les vues des moodboards et des coupes sont écrites une fois, sur le web, tandis que les opérations sur les fichiers, l'indexation et tout ce qui doit être rapide et hors ligne passent par des commandes Tauri vers un cœur qui ne sait rien de l'apparence.

Le cœur Rust est une bibliothèque autonome : chargement de fichiers, indexation, modèle de session. Ils ne dépendent pas de qui les dessine, si bien que la même logique peut se tester sans interface et s'exposer par le même contrat sur chaque plateforme. La vue est une fine couche par-dessus, et non l'endroit où habite la connaissance du projet.

La séparation nette a encore un avantage : il n'y a qu'un seul endroit où les erreurs doivent être gardées sérieusement. À l'intérieur du cœur, nous faisons confiance à nos propres types - si une session est chargée, son modèle est valide. Mais un chemin de fichier arrivant de la vue est une entrée de l'extérieur. Il peut ne pas exister, il peut pointer vers un fichier corrompu, il peut être un reste d'un projet déplacé.

C'est pourquoi la validation se trouve exactement à la frontière - à la commande Tauri - et n'est pas étalée sur tout le cœur au cas où. Là où le web rencontre Rust, une erreur se transforme en un message lisible pour l'utilisateur ; plus en profondeur, nous n'avons plus à vérifier la même chose une seconde fois.

L'outil démarre vite, a les fichiers à portée de main et n'a pas besoin de réseau pour fonctionner - et ne multiplie tout de même pas le code par système. Un repo, un cœur Rust, une fine couche de vue par-dessus et des applications séparées à la sortie, construites depuis la même source.

Pour la personne qui l'utilise, cela signifie que l'outil se comporte comme un programme natif, et non comme une page faisant semblant d'être une application : vous pointez les fichiers directement depuis le disque, le travail continue sans réseau, et l'interface ne s'étouffe pas sur une grosse session. Pour la maintenance, cela signifie qu'une nouvelle fonctionnalité ajoutée dans le cœur atteint les trois plateformes à la fois, au lieu d'être écrite et cassée trois fois séparément.