Dans Minecraft, casser un bloc est une action assez simple. Le bloc est là, je frappe, il disparaît.
Avec CC:Tweaked, le jeu permet d’aller beaucoup plus loin. Il ajoute des ordinateurs programmables, des téléphones de poche et des modems. J’ai donc fait ce que toute personne raisonnable ferait avec ça : construire un réseau de téléphones, des comptes, des bornes ATM et une console d’administration.
Le projet s’appelle PIL OS. Tout est écrit en Lua. Mais la décision importante n’était pas le langage, l’interface du téléphone ou la forme des messages.
C’était de choisir qui a le droit de décider.
## Le téléphone demande, le serveur tranche
Dans PIL OS, le serveur central fait autorité. Les téléphones, les bornes ATM et la console d’administration sont des clients. Ils peuvent envoyer une demande et afficher une réponse. Ils ne possèdent pas la vérité globale du système.
Cette différence paraît évidente une fois écrite. Elle l’était beaucoup moins quand je construisais le réseau dans Minecraft.
Un téléphone connaît forcément certaines informations pour fonctionner. Il doit afficher une interface, conserver ce dont son OS a besoin et réagir aux entrées du joueur. La tentation est donc de lui laisser prendre davantage de décisions localement. C’est plus direct. Il n’a pas besoin d’attendre le serveur pour tout.
Mais dès qu’une information concerne plusieurs machines, la question change. Si deux téléphones peuvent agir sur le même compte, leur état local ne peut pas être la référence. Sinon, j’ai plusieurs versions possibles de la même réalité.
Le client peut dire :
Voilà ce que l’utilisateur veut faire.
Le serveur doit répondre :
Voilà ce qui a réellement été accepté.
C’est cette séparation qui a donné une structure au projet.
## Client et serveur ne décrivent pas seulement deux programmes
Avant PIL OS, je voyais surtout le modèle client-serveur comme un découpage technique. D’un côté, une interface. De l’autre, une API et des données.
Dans Minecraft, le découpage est devenu physique. Le téléphone est littéralement dans ma main. La borne ATM est posée ailleurs. Le serveur est une autre machine, avec son propre écran, son propre programme et son propre état.
Quand je coupe un ordinateur, les autres continuent d’exister. Quand une machine décroche, le réseau ne disparaît pas avec elle. Cette matérialisation rend les responsabilités beaucoup plus visibles qu’avec deux dossiers dans un projet web.
Les modems de CC:Tweaked travaillent avec des canaux et déclenchent un événement lorsqu’un message arrive. La documentation précise aussi que l’API `rednet` est une couche d’abstraction au-dessus de ces modems. Elle simplifie l’envoi et la réception, mais elle ne transforme pas le réseau en vérité magique.
Un retour positif de rednet.send indique que le réseau est ouvert côté émetteur. Il ne garantit pas que le destinataire a reçu le message. C’est un détail de documentation, mais il change la manière de penser tout le système : envoyer n’est pas valider.
## L’autorité n’empêche pas les clients d’être utiles
Mettre la vérité sur le serveur ne signifie pas rendre les clients idiots.
PIL OS reste un OS embarqué sur chaque téléphone. Le client gère son interface et son interaction avec le joueur. Une borne ATM n’a pas le même rôle qu’un téléphone. La console d’administration n’expose pas les mêmes actions non plus.
Le serveur n’a pas besoin de connaître chaque détail visuel. Le téléphone n’a pas besoin de décider seul de l’état partagé. La frontière utile se situe entre la présentation d’une intention et la validation de son résultat.
C’est une distinction que je garde maintenant quand je retourne sur mes projets TypeScript. Un composant React peut afficher immédiatement quelque chose. Cela ne signifie pas que cette chose est devenue vraie dans SQLite ou sur le serveur. Une interface peut anticiper. Elle ne doit pas confondre anticipation et confirmation.
Minecraft m’a donné une image simple pour m’en souvenir : si je peux poser deux téléphones côte à côte, les allumer et leur faire demander la même chose, il faut une troisième machine capable de répondre sans ambiguïté.
Il reste une limite importante. La documentation de rednet indique clairement que les messages peuvent être écoutés ou imités par une autre machine. Le serveur peut être l’autorité fonctionnelle sans que le transport soit automatiquement digne de confiance.
Si je reprends le protocole de PIL OS, c’est le premier endroit que je relirai : non pas ce que le téléphone demande, mais ce qui permet au serveur de croire cette demande.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.