Dans Minecraft, installer une machine commence par poser un bloc.
Avec CC:Tweaked, ce bloc devient un ordinateur programmable en Lua. Il possède ses fichiers, son écran et ses périphériques. Une fois équipé d’un modem, il peut échanger des messages avec les autres machines du monde.
C’est assez limité pour rester compréhensible. Et assez ouvert pour construire beaucoup trop de choses.
Je ne voulais pas seulement afficher du texte sur un écran. Je voulais un réseau avec des téléphones, des comptes, des bornes ATM et une console d’administration. C’est devenu PIL OS.
Le jeu était le prétexte. Le vrai problème est arrivé quand j’ai voulu ajouter une nouvelle machine au réseau.
## Un bloc neuf ne sait rien faire
Poser un ordinateur ne suffit pas. Au départ, il ne connaît pas son rôle. Il ne possède ni les bons fichiers, ni la bonne configuration, ni le bon comportement au démarrage.
Je pouvais copier manuellement les programmes sur chaque appareil. Pour un test, cela fonctionne. Pour un réseau composé de plusieurs types de machines, cela devient vite une mauvaise interface d’installation.
Une borne ATM n’est pas un téléphone. Un téléphone n’est pas une console d’administration. Le serveur central n’a pas non plus les mêmes responsabilités que les trois autres.
J’ai donc construit install-all.lua, un installeur unique qui configure chaque ordinateur selon son rôle. Le même point d’entrée sert à transformer une machine vide en serveur, téléphone, borne ou console.
Le détail important n’est pas le téléchargement des fichiers. C’est la question posée avant celui-ci : quelle machine suis-je en train de créer ?
À partir de cette réponse, l’installation peut décider quoi placer sur le disque et comment préparer l’appareil. Ajouter un équipement ne consiste plus à me souvenir d’une série de manipulations. Je lance une commande et je choisis un rôle.
Le dépôt de PIL OS tient aujourd’hui autour de cette entrée unique.
## Le rôle est devenu une frontière
Dans Minecraft, les différences sont visibles. Une borne reste posée à un endroit. Un téléphone est transporté. Le serveur central tourne de son côté. La console d’administration n’est pas destinée au même usage que les appareils ordinaires.
Cette séparation physique m’a forcé à éviter une application unique qui ferait tout partout.
Chaque rôle définit un sous-ensemble du système. Il indique les fichiers nécessaires, les interactions disponibles et la manière dont la machine participe au réseau. Les modems de CC:Tweaked ne donnent qu’un moyen d’envoyer et de recevoir des messages. Ils ne décident pas de la structure de l’ensemble.
C’était à moi de la poser.
Le redémarrage fait aussi partie du problème. Une machine correctement installée doit retrouver son comportement sans intervention manuelle. CC:Tweaked prévoit pour cela des fichiers exécutés au démarrage, notamment `startup.lua`. À partir du moment où plusieurs appareils existent, le lancement n’est plus un détail de développement. Il appartient au rôle de la machine.
C’est là que mon petit réseau Minecraft a commencé à ressembler moins à un script et davantage à un système déployé.
## Installer fait partie du produit
Avant PIL OS, j’aurais facilement considéré l’installation comme une étape extérieure au projet. Le code était le produit. Le reste servait seulement à le lancer.
Ce réseau m’a montré l’inverse.
Si je dois ouvrir un éditeur, retrouver plusieurs fichiers et modifier chaque ordinateur à la main, mon système n’est pas vraiment reproductible. Il fonctionne surtout parce que je me souviens encore de sa construction.
L’installeur encode cette mémoire. Il relie une machine vide à un état attendu. Il réduit aussi l’écart entre le premier appareil, installé pendant le développement, et le suivant, posé plus tard dans le monde.
Je retrouve maintenant cette question sur mon VPS. Déployer mon portfolio ne consiste pas uniquement à transférer une application Next.js. Il faut savoir quel processus lancer, avec quelle configuration et derrière quelle origine publique. Le décor a changé, mais la question reste proche : comment passer d’une machine disponible à une machine qui remplit précisément son rôle ?
PIL OS m’a donné une première réponse très simple : commencer par nommer ce rôle, puis faire de l’installation une partie du code.
Si j’ajoute un nouveau type de machine au réseau, je ne commencerai pas par copier un dossier existant. Je commencerai par définir ce qui la distingue assez clairement pour que l’installeur puisse la construire sans moi.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.