## Une requête n’est jamais gratuite
PIL OS et mon dashboard n’utilisent ni le même langage, ni la même interface, ni le même environnement. Le premier est un réseau de téléphones, de bornes ATM et de serveurs écrit en Lua dans Minecraft. Le second est une page Next.js que j’ouvre des dizaines de fois par jour.
Pourtant, ils m’ont appris à regarder la même chose : le nombre d’allers-retours nécessaires pour obtenir un résultat.
Dans PIL OS, l’aller-retour est visible. Un téléphone envoie un message au serveur central. Le serveur traite la demande et répond. La documentation de `rednet` précise d’ailleurs qu’un envoi réussi signifie seulement que le réseau était ouvert, pas que le destinataire a réellement reçu le message.
Cette limite m’a obligé à séparer plusieurs étapes que j’aurais facilement mélangées ailleurs :
- la demande a été construite ;
- elle a été envoyée ;
- le serveur l’a comprise ;
- l’opération a été acceptée ;
- le client a reçu le résultat.
Une API ne se résume donc pas à appeler une fonction distante et attendre du JSON. C’est un échange avec plusieurs endroits où perdre l’information. Même quand tout tourne sur une seule machine, je garde cette décomposition en tête.
## Le protocole avant l’implémentation
Dans ComputerCraft, je n’avais pas de framework pour décider à ma place de la forme des échanges. Le modem transportait les messages. Le reste dépendait de mon protocole.
Il fallait que le téléphone et le serveur donnent le même sens aux données envoyées. Il fallait aussi décider où vivait l’état partagé. Dans PIL OS, le serveur central fait autorité. Les téléphones et les bornes demandent, puis affichent le résultat.
C’est ce que ce projet a changé dans ma manière de penser une API. Je commence moins par la route ou la fonction à écrire. Je regarde d’abord le contrat entre les deux côtés : ce qui entre, ce qui peut sortir et qui prend la décision.
Next.js fournit des Route Handlers basés sur les API Web Request et Response. C’est plus confortable que mon réseau Lua. Mais le confort du framework ne retire pas la question principale : que doit comprendre le client à la fin de l’échange ?
Sur mon portfolio, cette réflexion revient dans le panneau d’admin. Le contenu vit dans SQLite via Prisma. L’interface permet de le modifier. Entre les deux, j’ai de l’authentification, des sessions, de la validation et des uploads. Chaque action traverse plusieurs couches, même si elles sont regroupées dans la même application Next.js.
PIL OS m’a appris à ne pas confondre proximité du code et simplicité de l’échange.
## Le dashboard ajoute l’utilisateur dans la boucle
Le dashboard m’a fait regarder l’autre moitié du problème.
Je l’ai construit pour remplacer le nouvel onglet de mon navigateur. Il rassemble mes raccourcis, mes informations et mes outils quotidiens. Comme je l’ouvre constamment, un détour minuscule devient rapidement pénible. Un widget lent ou inutile ne reste pas parce que son code est intéressant. Il saute.
Dans PIL OS, je compte les échanges entre machines. Dans le dashboard, je compte les actions entre mon intention et le résultat.
Un clic supplémentaire est aussi un aller-retour. Une information rangée trop loin oblige à relancer une recherche. Une interface qui demande de comprendre son organisation avant d’agir ajoute son propre protocole, mais sans documentation.
C’est ce que j’ai réinvesti dans le portfolio. La première version était une vitrine générique. Pour la seconde, je ne voulais pas seulement améliorer l’apparence publique. Je voulais aussi pouvoir gérer le contenu depuis une interface dédiée, au lieu de traiter chaque modification comme un changement de code.
Le panneau d’admin ne sert donc pas uniquement à prouver que je sais construire un CRUD. Il réduit la distance entre « je veux modifier ce contenu » et « le contenu est modifié ». La base SQLite, Prisma, l’authentification JWT avec jose, les mots de passe avec bcrypt et la validation avec zod existent derrière ce trajet. L’interface, elle, doit éviter de me les faire traverser mentalement à chaque action.
## Deux formes du même coût
PIL OS m’a appris qu’une demande peut partir sans produire de réponse exploitable. Le dashboard m’a appris qu’une demande parfaitement traitée peut quand même être mauvaise si elle exige trop d’effort.
Je regarde maintenant une API et une interface avec une question proche : combien d’étapes séparent l’intention du résultat, et lesquelles peuvent échouer sans l’expliquer ?
Ce n’est pas une règle d’architecture que j’applique partout. C’est un réflexe venu de deux projets que je n’avais pas prévus pour apprendre la même chose.
La suite, sur le portfolio, consiste à continuer de passer mes actions d’administration au même test : si une modification courante demande un détour, soit je retire le détour, soit je rends sa raison visible.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.