Mes projets ne restent pas vraiment séparés. Je change de langage, d’interface ou de contexte, mais certains problèmes me suivent.
PIL OS tourne dans Minecraft, en Lua. Mon dashboard remplace le nouvel onglet de mon navigateur. Mon portfolio est une application Next.js avec une base, un panneau d’admin et son propre déploiement.
Sur le papier, ce sont trois projets assez éloignés. En pratique, les deux premiers ont directement changé ma manière de construire le troisième.
## Un appel de fonction qui traverse un modem
Avant PIL OS, une API restait surtout pour moi une route appelée depuis un front. Une URL, des données envoyées, une réponse reçue. Le réseau de ComputerCraft a rendu cette séparation beaucoup plus concrète.
Dans PIL OS, le serveur central fait autorité. Les téléphones, les bornes ATM et la console d’administration lui envoient des messages par modem sans fil. La documentation de rednet fournit les briques pour envoyer, recevoir et filtrer ces messages par protocole. Elle précise aussi qu’un envoi réussi ne garantit pas que le message a réellement été reçu.
Cette phrase change beaucoup de choses quand on construit le système autour.
Une machine peut décrocher. Un message peut ne pas revenir. Le client ne possède pas forcément l’état qu’il affiche. Il faut décider ce que signifie chaque demande et ce que le serveur accepte de croire.
Je n’avais ni framework ni bibliothèque pour cacher ces questions. J’avais des tables Lua, des identifiants de machines et un protocole à définir. C’est là que j’ai commencé à voir une API comme un contrat entre deux programmes qui ne partagent rien par défaut.
Quand j’ai construit l’admin du portfolio, je n’ai pas copié l’architecture de PIL OS. J’ai gardé le réflexe.
Les Route Handlers de l’App Router me donnent une structure HTTP bien plus confortable que mes messages Lua. Mais les questions restent proches : qu’est-ce qui entre, qui a le droit de demander l’action, quelles données peuvent être acceptées et que se passe-t-il si elles ne le sont pas ?
L’admin manipule de vrais contenus. Il gère l’authentification avec JWT, les sessions, les articles, les projets et les uploads. J’utilise Zod pour valider les données plutôt que de considérer qu’un objet reçu possède forcément la forme attendue.
PIL OS ne m’a pas appris une syntaxe réutilisable en TypeScript. Il m’a appris à me méfier de la frontière. Une donnée qui arrive d’un autre composant n’est pas encore une donnée valide.
## Cinquante ouvertures rendent chaque gêne visible
Le dashboard m’a appris autre chose.
Je l’ouvre des dizaines de fois par jour. À cette fréquence, une petite friction ne reste jamais petite. Un widget lent finit par sauter. Une information mal placée devient pénible. Une fonction amusante à développer mais inutile à l’usage prend juste de la place.
C’est le projet qui m’a forcé à arrêter de juger une idée uniquement sur son intérêt technique. Le vrai test est plus simple : est-ce que cette interface me fait gagner du temps quand je l’utilise réellement ?
J’ai réinvesti ce filtre dans le portfolio, surtout dans son administration.
Au départ, l’édition des articles se faisait directement dans l’onglet blog. L’espace était trop étroit. J’ai déplacé la création et l’édition vers des pages dédiées, avec l’éditeur markdown d’un côté et l’aperçu de l’autre. Ce n’est pas une fonction plus impressionnante. C’est juste une tâche existante devenue moins pénible.
Même correction pour l’abonnement au blog. Le formulaire placé sous le hero repoussait la liste des articles. Je l’ai descendu en fin de page. En haut, il ne reste qu’un bouton qui pointe vers lui avec une ancre. La fonction est toujours là, mais elle n’impose plus sa place à chaque visite.
Le dashboard m’a appris que la friction se mesure souvent en répétitions. Sur le portfolio, il y a deux répétitions différentes : celles du visiteur qui parcourt le site, et les miennes quand je retourne dans l’admin pour modifier du contenu.
## Deux frontières à surveiller
PIL OS m’a appris à rendre explicite la frontière entre deux machines. Le dashboard m’a appris à réduire la frontière entre une intention et l’action qui la réalise.
Je retrouve les deux dans le portfolio.
Une route d’admin doit recevoir quelque chose de clair et refuser ce qui ne l’est pas. Une interface doit permettre l’action sans ajouter de détour inutile. Dans les deux cas, le problème apparaît à l’endroit où deux parties se rencontrent : client et serveur, utilisateur et écran, éditeur et contenu.
La suite, ce n’est pas d’ajouter une couche d’architecture ou un nouveau widget pour le principe. Je vais continuer à publier depuis l’admin et à parcourir le site comme un visiteur. La prochaine modification partira du prochain endroit où le contrat reste flou ou où un geste accroche encore.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.