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.

Aujourd’hui, l’industrie revient à l’idée d’objets autonomes, qui portent leurs propriétés et fonctionnent sans dépendre en permanence de l’infrastructure où ils ont été créés. Cette idée figurait déjà dans un mémoire d’ingénieur en 1997, accompagné d’une première implémentation qui en démontrait le fonctionnement. Elle a depuis évolué pour devenir PanglotOS.

Trois boîtes pour dire la confiance

Le mémoire reposait sur une classification en 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

L’une des idées fortes de CORBA était le contrat d’interface : écrit dans un langage neutre, il permet à des systèmes indépendants 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 un objet CORBA dépendait toujours d’un bus, d’un serveur et d’une infrastructure lourde pour fonctionner. 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 : au lieu d’attendre que l’industrie réunisse ces éléments, il fallait construire le système annoncé par le mémoire de 1997 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, car des objets logiciels autonomes ont besoin d’un environnement qui garantit leur fonctionnement : un micro-noyau, une isolation nette des processus, une sécurité où rien n’est permis par défaut et une faible empreinte, pour que chaque objet ne mobilise que les ressources qu’il consomme.

La couche OS fournit ce socle ; le sujet principal est ce qui s’y construit. 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.

Comme dans le mémoire, le contrat ne suffit pas : l’objet doit aussi porter ses règles de transformation. Les trois boîtes réapparaissent ici.

Les trois boîtes dans l’héritage des conteneurs

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’aboutissement, mais une étape. 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é.