Dans l'architecture logicielle classique, le runtime est une donnée fixe. On choisit un langage, on hérite de son runtime — sa gestion mémoire, son modèle d'exécution, ses contraintes de performance. C'est un contrat implicite, rarement questionné. J'ai passé des années à le questionner. Parce que ce contrat, aussi commode qu'il soit, plafonne l'architecture exactement là où elle devrait pouvoir s'étendre.
Le runtime n'est pas le langage. C'est facile à dire, difficile à vraiment intérioriser. Le langage décrit l'intention — le runtime l'exécute. Ce sont deux niveaux d'abstraction distincts, et les traiter comme inséparables est une décision de convenance, pas une nécessité architecturale. CAKE est né, en partie, de la décision de les séparer délibérément.
Quand le runtime devient un composant comme un autre — déclarable, remplaçable, extensible — l'architecture entière change de nature. Elle cesse d'être une prison dorée et devient un espace de possibles.
La relation traditionnelle langage-runtime est une relation de dépendance verticale : le langage appelle le runtime, le runtime exécute. Cette relation est efficace, optimisée, profondément enracinée dans des décennies d'outillage. Elle est aussi fondamentalement rigide.
La colonne de droite n'est pas une liste de runtimes différents — c'est une liste de positions architecturales. Chaque entrée dit : pour ce type de problème, voici le moteur qui lui correspond. Et si ce moteur n'existe pas encore, le système fournit l'infrastructure pour l'introduire sans déstabiliser l'ensemble.
La déclaration d'un runtime dans CAKE n'est pas une simple configuration. C'est un acte architectural — une décision formalisée qui engage le système sur la façon dont un certain type de code sera exécuté, quelles ressources il peut consommer, comment il interagit avec les autres moteurs.
Ce bloc CXML fait plusieurs choses simultanément. Il déclare les types que le moteur accepte et produit — définissant ainsi son contrat d'interface. Il spécifie son modèle d'isolation — le moteur ne peut pas contaminer d'autres composants. Il définit sa politique d'erreur — les pannes sont isolées et loggées, pas propagées. Et il hérite automatiquement de toute l'infrastructure CAKE sans avoir à la réécrire.
C'est l'idée centrale : un nouveau runtime n'est pas un nouveau système. C'est un nouveau composant dans un système existant — avec tous les bénéfices de l'infrastructure déjà construite.
Dans les architectures CAKE, les moteurs ne sont pas des boîtes noires auxquelles on délègue en espérant le meilleur. Ce sont des composants de première classe — observables, remplaçables, versionnables, testables indépendamment du reste du système.
La colonne "core / runtime / extensible" n'est pas une hiérarchie de valeur — c'est une hiérarchie de stabilité. Le core ne change jamais sans un cycle complet de validation. Les runtimes évoluent dans leurs propres cycles. Les moteurs extensibles peuvent être remplacés à tout moment sans impact sur le reste du système. Cette stratification est ce qui rend l'architecture durable sans la rendre statique.
Avoir plusieurs runtimes dans un système ne crée pas automatiquement de la valeur. Ce qui crée de la valeur, c'est la qualité de leur coordination. Un système avec cinq moteurs mal coordonnés est plus fragile qu'un système avec deux moteurs bien orchestrés.
C'est pour ça que j'ai investi autant dans le pipeline d'orchestration de CAKE — les sept étapes qui gouvernent comment les moteurs reçoivent leurs instructions, produisent leurs résultats et communiquent entre eux. Ce pipeline n'est pas de la plomberie. C'est la partition que tous les moteurs lisent. Changer un moteur ne nécessite pas de réécrire la partition — juste de s'assurer que le nouveau moteur sait lire la même notation.
Un runtime n'est pas un destin. C'est un choix architectural qui devrait rester réversible. Dès qu'un runtime devient impossible à remplacer, l'architecture a déjà perdu une partie de sa liberté — sans que personne n'ait signé cette capitulation. — Sébastien Roy, CEO Unibool Inc.
Un système extensible ne choisit pas son runtime une fois pour toutes. Il construit l'infrastructure qui permet d'en introduire de nouveaux au fur et à mesure que les besoins évoluent — sans réécriture, sans rupture, sans capitulation architecturale.
Quand le moteur lui-même devient programmable, l'architecture cesse d'être une contrainte. Elle devient une capacité.