PIL OS, mon dashboard et mon portfolio ne partagent presque rien techniquement.
Le premier tourne en Lua dans Minecraft. Le deuxième est une page d’accueil Next.js que j’ouvre des dizaines de fois par jour. Le troisième mélange site public, base SQLite et panneau d’administration.
Pourtant, je retrouve le même problème dans les trois : définir une interface qui ne laisse pas sa complexité déborder sur celui qui l’utilise.
## Une API n’est pas le câble
Avec PIL OS, j’ai commencé par relier des ordinateurs ComputerCraft avec des modems sans fil. Un serveur central fait autorité. Les téléphones, les bornes ATM et la console d’administration lui envoient des messages.
Le modem permet de transporter ces messages. Il ne décide pas de leur sens.
La distinction paraît évidente maintenant. Elle l’était moins quand je construisais mon premier vrai système client-serveur sans framework. La documentation des modems de CC:Tweaked les présente comme une couche assez basse : des canaux, une émission et des événements à la réception. Même rednet, qui ajoute une abstraction au-dessus, précise qu’un envoi réussi ne garantit pas que le message a été reçu.
Il fallait donc définir le reste moi-même : le rôle de chaque machine, les demandes possibles, la forme des réponses et l’endroit où vit l’état partagé.
C’est ce qui a changé ma façon de penser une API. Je ne la vois plus seulement comme une liste de routes ou de fonctions. C’est une frontière. De chaque côté, le code doit pouvoir évoluer sans obliger l’autre côté à connaître tous ses détails.
Dans PIL OS, un téléphone ne doit pas reproduire les règles du serveur. Il formule une demande. Le serveur décide et renvoie un résultat. Cette séparation évite que chaque appareil devienne une petite copie incomplète du système entier.
## Le dashboard a ajouté une limite plus brutale
Le réseau Lua m’a appris où placer la complexité. Mon dashboard m’a appris qu’une complexité bien placée peut quand même être inutile.
Cette page remplace le nouvel onglet de mon navigateur. Je l’ai construite avec des widgets indépendants, dans Next.js. Elle est ouverte des dizaines de fois par jour. À cette fréquence, quelques secondes ou un geste superflu ne sont plus des détails.
Un widget peut être propre, bien isolé et intéressant à coder. S’il ralentit la page ou demande trop d’attention, il perd sa place.
Ce projet m’a donné un seuil simple : une fonctionnalité récurrente doit rembourser la friction qu’elle ajoute. Je ne mesure pas seulement ce qu’elle permet de faire. Je regarde aussi ce qu’elle m’oblige à attendre, à chercher ou à répéter.
C’est différent de PIL OS, mais complémentaire. Le réseau pose la question de la responsabilité. Le dashboard pose celle du coût d’usage.
## Les deux se retrouvent dans le portfolio
Mon portfolio utilise le Next.js App Router, TypeScript, une base SQLite reliée avec Prisma et un panneau d’administration maison.
PIL OS influence la séparation entre ces parties. Le site public n’a pas besoin de connaître le fonctionnement de l’administration. L’admin manipule du contenu à travers des actions définies, avec authentification, validation et gestion des fichiers. La base reste derrière cette frontière.
Le dashboard influence une autre décision : cette séparation technique ne suffit pas si l’interface reste pénible.
Je peux construire un formulaire complet, le protéger correctement et valider toutes ses entrées. Si modifier un contenu demande encore trop d’étapes, le problème n’est pas réglé. À l’inverse, je peux pousser très loin la direction terminal du site public. Si elle ralentit l’accès aux projets, elle devient un décor payé à chaque visite.
Je ne cherche donc pas à transférer du Lua vers TypeScript ou des widgets vers le portfolio. Je transfère deux questions : qui doit prendre cette décision, et combien de gestes faut-il pour l’obtenir ?
La prochaine étape est concrète : reprendre un parcours de l’admin et un parcours du site public, noter chaque action, chaque attente et chaque passage serveur. Puis en retirer un avant d’ajouter la prochaine fonctionnalité.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.