En 1997, un mémoire d'ingénieur à l'EPITA proposait des objets répartis porteurs de leurs propres règles d'usage et de transformation, classées en trois boîtes : blanche, grise, noire. Vingt-neuf ans plus tard, cette intuition est devenue PanglotOS, un micro-noyau et un écosystème de plus de cent cinquante services polyglottes — et son prochain chapitre s'appelle KARL core.
1997, un mémoire et une intuition
En 1997, à l'EPITA, je terminais mes études d'ingénieur avec un mémoire consacré à un sujet qui passionnait alors les chercheurs en systèmes répartis : les objets distribués. CORBA était partout dans les cours et dans les papiers de recherche. L'idée de l'époque était séduisante : un objet installé sur une machine pouvait être appelé depuis une autre machine, éventuellement écrite dans un autre langage, grâce à un contrat d'interface qui décrivait ce que l'objet savait faire.
Le mémoire allait plus loin que l'exercice habituel. Il proposait un environnement d'objets répartis dans lequel chaque objet portait sur lui, de façon déclarative, ses propriétés d'utilisation et de modification. L'objet n'était plus seulement un paquet de code derrière une interface. C'était une entité autonome qui transportait avec elle les règles du jeu : qui peut m'utiliser, comment, et surtout, dans quelle mesure on peut me transformer.
Vingt-neuf ans plus tard, l'industrie redécouvre avec enthousiasme l'idée d'objets autonomes, porteurs de leurs propriétés, capables de fonctionner sans dépendre en permanence de l'infrastructure qui les a vus naître. Cette idée n'est pas neuve. Elle était déjà couchée sur papier dans un mémoire d'école d'ingénieur, avec un début d'implémentation pour prouver que ça marchait. Et elle n'a jamais cessé de mûrir depuis. C'est elle qui est devenue PanglotOS.
Trois boîtes pour dire la confiance
Le cœur du mémoire tenait dans une classification simple, presque enfantine à énoncer : trois boîtes.
La boîte blanche. L'objet est livré avec son code source. Celui qui le reçoit peut l'ouvrir, le lire, le modifier, le recompiler. C'est la confiance totale, la transmission complète.
La boîte grise. L'objet est livré sans son code, mais il reste modifiable : on peut le spécialiser, surcharger certains de ses comportements, le dériver en un objet plus fin, sans jamais toucher à l'original. La modification passe par l'héritage, pas par la réécriture.
La boîte noire. L'objet est intangible. On l'utilise tel quel, point. Son contrat dit ce qu'il fait, et personne ne peut le dénaturer.
Cette gradation n'était pas un gadget théorique. Elle répondait à une question très concrète que se posaient déjà les entreprises : comment distribuer des composants logiciels à des partenaires sans perdre le contrôle sur ce qu'ils en font ? La propriété de modifiabilité, portée par l'objet lui-même et non par un contrat papier ou par la configuration d'un serveur, était la réponse. L'objet savait lui-même dans quelle boîte il vivait.
Ce que CORBA avait compris, et ce qu'il manquait
CORBA avait apporté une intuition géniale : le contrat d'interface, écrit dans un langage neutre, permet à des mondes qui ne se connaissent pas de coopérer. Un client n'a pas besoin de savoir dans quel langage l'objet est écrit pour l'appeler. Il a besoin de connaître le contrat.
Mais l'objet CORBA restait prisonnier de son orbite. Son existence dépendait d'un bus, d'un serveur, d'une infrastructure lourde qui le portait. Ses propriétés — ce qu'il avait le droit de faire, comment on pouvait l'étendre — vivaient à l'extérieur de lui, dans la documentation, dans la tête des développeurs, dans la configuration du système. Retirez l'infrastructure, et l'objet n'était plus rien.
L'intuition du mémoire était de rapatrier tout cela dans l'objet : son contrat, ses propriétés, ses règles de transformation, son identité. Un objet qui se porte tout seul. Un objet dont on peut vérifier ce qu'il est et ce qu'il permet sans avoir à interroger le système qui l'héberge.
Vingt ans de maturation
Entre le mémoire et PanglotOS, il y a eu de longues années de pratique industrielle, et l'observation patiente des modes qui passaient : les EJB, les web services, SOAP, puis REST, puis les microservices, puis les conteneurs. Chaque vague reprenait un morceau de l'idée, jamais l'idée entière. Les microservices ont réhabilité l'autonomie. Les conteneurs ont réhabilité la portabilité. Les API ont réhabilité le contrat. Mais nulle part on ne voyait un objet qui porte à la fois son contrat, ses propriétés d'usage et ses règles de modification, de façon déclarative et vérifiable.
PanglotOS est né de ce constat : plutôt que d'attendre que l'industrie recouse les morceaux, autant construire le système que le mémoire de 1997 annonçait, avec les moyens d'aujourd'hui.
PanglotOS : la couche OS, une nécessité, pas une fin
PanglotOS est d'abord un système d'exploitation, parce qu'il le fallait. Pour que des objets logiciels vivent en toute autonomie, il faut un sol qui les respecte : un micro-noyau, une isolation franche des processus, une sécurité où rien n'est permis par défaut, une empreinte minuscule pour que chaque objet ne paie que ce qu'il consomme.
Mais la couche OS n'est pas le sujet. Elle est le socle. Un conteneur PanglotOS, c'est un binaire, un manifeste qui le décrit, et une politique de sécurité explicite : il démarre en quelques dizaines de millisecondes, il pèse moins de deux mégaoctets au repos, et il ne peut rien faire qui n'ait été déclaré. Ce socle garantit que les objets qu'on posera dessus resteront ce qu'ils prétendent être. Sans ce socle, les propriétés portées par l'objet ne seraient que des promesses. Avec lui, elles deviennent des faits vérifiables.
Le vrai sujet commence au-dessus : les modules.
Des modules polyglottes qui s'ignorent
Le marketplace PanglotOS compte aujourd'hui plus de cent cinquante microservices écrits en Go, Rust, Python, TypeScript, Ada et C. Certains sont minuscules, d'autres sont des briques entières de gestion, de finance ou d'intelligence artificielle. Tous partagent une propriété venue directement de 1997 : on les appelle sans savoir, et sans avoir besoin de savoir, dans quel langage ils sont écrits.
Chaque module porte son contrat : ses points d'entrée, ses entrées et sorties, sa version, ses capacités déclarées. Un service écrit en Ada peut être consommé par un client écrit en Python, lui-même appelé depuis un service Go, sans qu'aucun des trois ne connaisse l'existence des deux autres. Ce que CORBA cherchait à obtenir avec un bus d'objets et des générateurs de stubs, PanglotOS l'obtient avec un contrat lisible par tous et un runtime qui fait respecter les règles. Le langage d'implémentation redevient un détail privé, comme il aurait toujours dû l'être.
Et comme dans le mémoire, le contrat ne suffit pas : il faut que l'objet porte aussi ses règles de transformation. C'est là que les trois boîtes reviennent sur scène.
Le retour des trois boîtes : l'héritage de containers
La première incarnation concrète des boîtes de 1997 dans PanglotOS, c'est l'héritage de services, ce mécanisme qu'on appelle SOX. Un service racine peut autoriser d'autres services à dériver de lui, et il déclare dans quelles conditions : en boîte blanche, le dérivé reçoit tout et peut tout modifier ; en boîte grise, il surcharge certains comportements précis — une règle de validation, un calcul de score — sans jamais toucher au parent ; en boîte noire, il consomme le service tel quel, sans rien pouvoir y changer.
Concrètement, un service de gestion de la relation client peut ainsi exister en version générique, puis être dérivé pour un secteur d'activité, puis re-dérivé pour une région du monde, chaque étage ne modifiant que ce que la boîte de l'étage précédent l'autorise à modifier. Quand le dérivé ne sait pas répondre, il délègue à son parent, qui délègue au sien, exactement comme un objet qui remonte sa chaîne d'héritage. L'arbre généalogique des services est lisible, gouverné, et chaque maillon sait dans quelle boîte il vit.
Ce qui était, dans le mémoire, une propriété d'objets répartis est devenu une propriété de services en production. La gradation blanche, grise, noire n'a pas changé d'un iota en vingt-neuf ans. Elle a juste trouvé son échelle.
Cortex : l'objet de 1997 devenu service autonome
Puis est venu Cortex, et avec lui la deuxième incarnation, plus profonde. Cortex est le runtime universel de PanglotOS : chaque service du système, du plus petit utilitaire au plus gros moteur métier, vit dans une instance de Cortex. Et Cortex reprend les propriétés de l'objet du mémoire, en en ajoutant de nouvelles qui n'existaient pas en 1997 parce que personne n'en avait encore besoin.
L'objet de 1997 portait son contrat et ses règles de modification. Le service sous Cortex porte, en plus :
Son identité autodécrite. Chaque service sait se présenter : qui il est, sa version, ce qu'il sait faire, comment il a été construit. On n'interroge pas un registre central pour savoir à qui l'on parle ; on le demande au service lui-même.
Son autonomie énergétique. Un service peut s'endormir à plusieurs niveaux quand on ne l'utilise pas, rester dormant mais prêt, ou tourner à plein régime. Il gère sa propre vie au lieu d'être maintenu artificiellement éveillé par l'infrastructure.
Sa mobilité. Un service peut être délégué d'une instance à une autre, migrer d'une machine vers une machine plus puissante ou plus proche de ses utilisateurs, sans que ses clients s'en aperçoivent. L'objet n'est plus amarré à son serveur ; il porte assez de lui-même pour vivre ailleurs.
Sa citoyenneté. Un service s'inscrit, obtient une adresse, un nom, un port, se déclare au registre du cluster. Le système n'a pas besoin d'une configuration centrale figée pour savoir ce qui tourne : les objets se présentent d'eux-mêmes.
Sa discipline. Capacités explicites, quotas, supervision : le service ne peut pas faire plus que ce qu'on lui a accordé, et il rend compte de sa santé à qui lui demande.
Autrement dit, là où l'objet de 1997 était autonome en théorie, le service Cortex l'est en actes : il se décrit, se gouverne, se déplace, dort, se réveille et rend des comptes, sans qu'aucune de ces propriétés ne dépende d'une plateforme centrale qui les tiendrait à sa place.
KARL core : le chapitre suivant
PanglotOS n'est pas l'arrivée, c'est la maturation. Le chapitre suivant s'appelle KARL core. L'idée reste la même, poussée un cran plus loin : si un objet peut porter son contrat, ses propriétés et ses règles de vie, il peut aussi porter son histoire. KARL core prolonge la lignée ouverte en 1997 vers des objets dont l'existence, l'état et le passé restent vérifiables même lorsque l'infrastructure qui les a vus naître n'est plus là pour en témoigner. L'objet, une fois de plus, se porte tout seul.
Ce n'est pas une rupture. C'est la même phrase, écrite depuis vingt-neuf ans, qui trouve enfin toute sa ponctuation.
Épilogue
Quand on regarde l'industrie redécouvrir aujourd'hui, sous des vocabulaires toujours nouveaux, qu'un logiciel devrait porter ses preuves, ses propriétés et ses droits avec lui plutôt que de les déléguer aux plateformes qui l'hébergent, il est tentant de sourire. Ces idées ont un âge. Elles ont une généalogie. Dans mon cas, elle commence dans un amphithéâtre de l'EPITA en 1997, avec trois boîtes de couleurs et une intuition : un objet qui sait qui il est, ce qu'il permet et comment on peut le transformer n'a besoin de personne pour exister.
Le mémoire est devenu un système d'exploitation. Le système est devenu un écosystème de services polyglottes. L'écosystème devient un noyau. Les boîtes, elles, n'ont pas bougé.
