PIL OS et mon dashboard n’ont presque rien en commun à première vue.
Le premier est un réseau de téléphones, de bornes ATM et de machines ComputerCraft, écrit en Lua dans Minecraft. Le second est une page Next.js que j’ouvre des dizaines de fois par jour dans mon navigateur.
Pourtant, les deux ont changé la façon dont je construis mon portfolio. PIL OS m’a appris qu’une API est une interface. Le dashboard m’a appris qu’une interface techniquement correcte peut quand même être trop pénible pour servir.
## Le modem ne fournit pas le vocabulaire
Dans ComputerCraft, le modem permet de faire circuler des messages entre les machines. La couche `rednet` fournit ensuite des opérations comme send, receive et les noms de protocoles. Sa documentation précise même qu’un envoi réussi ne garantit pas que le destinataire a réellement reçu le message. (tweaked.cc)
Mais aucune de ces fonctions ne décide de ce que signifie un message pour PIL OS.
C’était à moi de définir ce qu’un téléphone pouvait demander, ce que le serveur devait répondre et quelles informations chaque échange devait contenir. Le transport était disponible. Pas le contrat.
C’est là que ma vision d’une API a changé. Avant, je l’associais surtout à des routes HTTP et à du JSON. Avec PIL OS, j’ai dû penser à l’étape précédente : deux programmes séparés doivent partager un vocabulaire suffisamment clair pour travailler ensemble.
Une requête ambiguë crée du travail ailleurs. Le serveur doit deviner. Le client doit conserver du contexte. Une nouvelle machine risque d’interpréter le même message autrement.
Je n’avais pas de framework pour masquer ça. Seulement des tables Lua, des modems et plusieurs rôles de machines. L’API était donc visible pour ce qu’elle était vraiment : une interface destinée à un autre programme.
## Le dashboard m’a montré l’autre moitié
Mon dashboard m’a appris presque la même chose, mais du côté humain.
Il remplace le nouvel onglet de mon navigateur. Je ne l’ouvre pas pour admirer son architecture. Je l’ouvre pour accéder rapidement à mes raccourcis, mes informations et mes outils.
Dans ce contexte, une petite friction devient énorme parce qu’elle se répète. Un widget peut être propre, indépendant et intéressant à coder. S’il ralentit l’ouverture ou demande trop d’attention, il perd sa place.
Ce projet m’a obligé à arrêter de confondre fonctionnalité disponible et fonctionnalité utile. Si une action me fait gagner dix secondes mais qu’elle en demande huit pour être trouvée ou comprise, le calcul n’est pas bon.
PIL OS m’avait appris à retirer l’ambiguïté entre deux machines. Le dashboard m’a appris à retirer l’hésitation entre une personne et son outil.
## L’admin du portfolio réunit les deux
Le panneau d’administration de mon portfolio est l’endroit où ces deux réflexes se rencontrent.
Il ne sert pas seulement à afficher des formulaires. Il manipule le contenu stocké en SQLite, passe par l’authentification, la validation et les uploads. Derrière l’écran, il faut donc des opérations compréhensibles par le serveur. Devant l’écran, il faut que je puisse réellement m’en servir sans transformer chaque modification en corvée.
Avec l’App Router, les `Route Handlers` de Next.js permettent d’exposer des endpoints HTTP avec les API Request et Response du Web. La documentation rappelle aussi que ces endpoints sont publics et doivent être protégés comme tels. (nextjs.org)
La mécanique existe. Comme avec le modem, elle ne choisit pas le contrat à ma place.
Quand je travaille sur une action de l’admin, je la regarde maintenant depuis les deux côtés.
Côté serveur, je cherche ce qui doit être demandé explicitement, validé puis accepté ou refusé. Côté interface, je regarde ce que je vais devoir comprendre et répéter pour déclencher cette action.
Une API peut ajouter de la friction sans afficher le moindre bouton. Elle le fait quand son consommateur doit reconstruire du contexte, enchaîner des appels inutiles ou interpréter une réponse floue. Une interface peut faire exactement la même chose avec des champs, des écrans et des clics.
Je ne sépare donc plus vraiment conception d’API et conception d’interface. Dans les deux cas, je construis une frontière entre deux parties qui ne doivent pas avoir à deviner.
Pour chaque prochaine action ajoutée à l’admin, je garde deux tests simples : est-ce qu’une machine peut la comprendre sans connaître l’écran, et est-ce que j’accepterais de la répéter cinquante fois dans mon dashboard ? Si l’une des réponses est non, l’action n’est pas encore prête.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.