Dans Minecraft moddé, je peux poser un ordinateur, lui coller un modem et décider qu’il devient un téléphone. Un autre bloc devient une borne ATM. Un troisième sert de console d’administration.
Visuellement, ce sont trois machines différentes. Dans mon code, la séparation est moins évidente.
Avec PIL OS, je ne voulais pas seulement afficher de fausses applications sur des écrans. Je voulais des téléphones, des comptes, des bornes et un serveur central capables de former un seul système. C’est ce qui m’a fait passer d’un assemblage de programmes Lua à un problème de modélisation de règles.
## Le jeu commence par des objets
CC:Tweaked ajoute des ordinateurs programmables dans Minecraft. Le jeu pousse naturellement à raisonner avec des objets physiques. Je pose une machine, je lui donne un rôle, puis j’écris le programme correspondant.
Au début, ce découpage paraît suffisant :
- le téléphone possède son interface ;
- la borne ATM possède la sienne ;
- la console d’administration possède la sienne ;
- le serveur relie le tout.
Le problème apparaît quand plusieurs machines touchent au même concept. Un compte ne devient pas différent selon qu’il est consulté depuis un téléphone ou une borne. Pourtant, si je pense d’abord en écrans, je peux facilement finir avec une version de la règle par appareil.
Le jeu me montre des blocs séparés. Le logiciel, lui, doit reconnaître ce qu’ils partagent.
## La borne n’est pas la règle
Une borne ATM représente une manière d’interagir avec un compte. Elle n’est pas le compte. Le téléphone non plus.
Cette distinction paraît évidente une fois écrite. Elle l’était beaucoup moins quand je construisais le système directement dans Minecraft. Chaque nouvel appareil donnait envie d’ajouter son propre comportement complet : son affichage, ses messages réseau et sa logique.
Pourtant, les différences utiles concernent surtout les capacités de chaque rôle. Le téléphone, la borne et la console d’administration ne proposent pas les mêmes actions. Ils manipulent néanmoins un état partagé, sous l’autorité du même serveur.
J’ai donc commencé à regarder le système autrement. Au lieu de demander « que fait cet écran ? », je préfère demander :
- quelle action est demandée ;
- sur quelle donnée elle agit ;
- quel rôle peut la demander ;
- quelle règle peut la refuser.
Le changement est petit dans la formulation. Il évite pourtant d’attacher une règle métier à l’appareil qui l’a affichée en premier.
## Le réseau transporte une intention
La documentation de `rednet` fournit de quoi envoyer et recevoir des messages entre ordinateurs. Cela règle le transport. Pas le sens de l’action.
Dans PIL OS, les clients parlent au serveur central par modem sans fil. Je peux donc voir un message comme la description d’une intention : un appareil demande quelque chose, puis le serveur applique ou refuse les règles correspondantes.
Ce qui m’intéresse ici n’est pas seulement l’architecture client-serveur. C’est le vocabulaire qu’elle m’oblige à choisir.
Si un message décrit uniquement un bouton ou un écran, le modèle dépend déjà trop de l’interface. Si le message décrit une action du système, une autre machine peut éventuellement la demander sans réécrire toute sa signification.
Je ne cherche pas à rendre chaque action disponible partout. Au contraire. Le rôle de la machine fait partie des données à considérer. Mais je veux séparer deux questions : « cette action existe-t-elle ? » et « cet appareil a-t-il le droit de la demander ? »
## Ce réflexe sort de Minecraft
Je retrouve maintenant ce problème dans mon portfolio. La partie publique affiche du contenu. Le panneau d’administration permet de le modifier. Là encore, un champ de formulaire n’est pas une règle.
J’utilise Zod pour valider les données reçues. Cette validation peut contrôler leur forme. Elle ne remplace pas la décision sur ce que mon application accepte réellement de faire avec elles.
Minecraft m’a donné une représentation très concrète de cette séparation. Une borne reste une borne. Un téléphone reste un téléphone. Mais aucun des deux ne devrait devenir le propriétaire accidentel d’une règle simplement parce qu’il possède le bouton qui la déclenche.
PIL OS est stable. La prochaine fois que je touche à son modèle, je veux surtout relire les noms des actions et des messages. Si l’un d’eux décrit un appareil alors qu’il devrait décrire une intention, je saurai où regarder.