PIL OS tourne dans Minecraft, en Lua. Mon dashboard remplace le nouvel onglet de mon navigateur, en Next.js. Ils ne partagent ni leur stack, ni leur interface, ni leur usage.
Pourtant, ce sont les deux projets qui influencent le plus la manière dont je construis l’administration de mon portfolio.
Pas par du code réutilisé. Par deux questions que je me pose maintenant presque automatiquement : est-ce que l’échange peut échouer ? Et combien d’efforts demande l’action ?
## PIL OS m’a appris à ne pas confondre envoi et résultat
PIL OS est mon premier vrai système client-serveur. Un serveur central fait autorité. Les téléphones, les bornes ATM et la console d’administration lui envoient des demandes par modem sans fil.
Au départ, le mécanisme semble simple : une machine envoie un message, une autre le reçoit, puis répond. Mais le transport ne définit pas ce que signifie le message. Il ne garantit pas non plus que l’action attendue a réellement eu lieu.
La documentation de `rednet` le dit directement : rednet.send peut indiquer que le message a été envoyé sans garantir sa réception. Dans PIL OS, je devais donc penser au-delà de l’appel réseau. Quel type de demande part ? Qui a le droit de décider ? Quelle réponse le client attend-il ? Que fait-il si cette réponse n’arrive pas ?
Cette contrainte a changé ma manière de voir une API web. HTTP, JSON et TypeScript rendent l’échange plus confortable, mais ils ne suppriment pas la frontière entre le client et le serveur.
Sur mon portfolio, le panneau d’admin ne modifie pas directement le contenu affiché. Il demande une modification. Derrière, il reste l’authentification, la validation avec Zod, l’écriture en SQLite via Prisma et la réponse renvoyée à l’interface. Les Route Handlers de Next.js fournissent le point d’entrée HTTP. Ils ne définissent pas seuls le contrat de l’opération.
PIL OS m’a appris à regarder cette chaîne comme une succession d’états incertains, pas comme un bouton relié magiquement à une base de données.
## Le dashboard m’a appris que le bon chemin peut rester pénible
Le dashboard m’a apporté une contrainte différente. Je l’ouvre des dizaines de fois par jour. Il n’a pas besoin de me convaincre : il doit juste me faire gagner du temps.
À cette fréquence, une petite friction devient vite visible. Un widget lent n’est pas « presque pratique ». Il finit par sauter. Un outil qui demande trop d’actions perd face à l’onglet ou au raccourci qu’il devait remplacer.
C’est là que j’ai commencé à séparer deux questions : est-ce que la fonctionnalité marche, et est-ce que j’ai réellement envie de l’utiliser ?
J’ai réinvesti cette distinction dans le portfolio. J’aurais pu stocker les projets et les articles en fichiers, puis modifier le dépôt à chaque changement. Techniquement, cela aurait fonctionné. Mais chaque correction aurait demandé de passer par l’éditeur, Git et le déploiement.
J’ai préféré une base SQLite et un panneau d’admin maison. Prisma prend en charge SQLite, ce qui me permet de garder une base sous forme de fichier tout en manipulant le contenu depuis mon application TypeScript.
Ce choix ajoute du travail : authentification JWT, mots de passe avec bcrypt, validation, sessions, CSRF et uploads. Je n’ai pas construit cette couche parce qu’un portfolio exige forcément une administration. Je l’ai construite parce que le dashboard m’a montré qu’un outil personnel ne reste utile que si son chemin principal est assez court pour être emprunté.
## Le point commun est dans l’admin
PIL OS me pousse à rendre les frontières explicites. Le dashboard me pousse à réduire le nombre de fois où je les traverse.
Ces deux réflexes se rencontrent dans l’admin du portfolio. Une action doit rester simple depuis l’interface, sans faire semblant que le serveur, la validation et la base n’existent pas. Cacher la complexité à l’usage ne veut pas dire l’ignorer dans le code.
C’est aussi ce que j’aime dans le passage d’un projet à l’autre. Mon réseau Lua n’a pas produit une librairie réutilisable pour Next.js. Mon dashboard n’a pas fourni un composant prêt à copier. Ils m’ont donné des critères.
La prochaine fois que je touche à l’admin, je regarderai d’abord ces deux points : le moment où l’interface attend une décision du serveur, puis chaque action demandée avant d’obtenir cette décision. C’est là que les problèmes de PIL OS et ceux du dashboard finissent par devenir les mêmes.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.