Il y a un monolinguisme technique qui persiste dans l'industrie, plus idéologique que pragmatique. L'idée qu'un bon système devrait être écrit dans un seul langage — par souci de cohérence, de recrutement, de simplicité opérationnelle. J'ai longtemps compris cet argument. Je ne l'ai jamais accepté. Parce qu'il confond la cohérence de l'architecture avec l'uniformité des outils. Ce sont deux choses radicalement différentes.
Un orchestre symphonique n'est pas incohérent parce qu'il contient des violons, des cuivres et des percussions. Il est cohérent parce que chaque instrument joue sa partie au bon moment, guidé par une partition commune et un chef qui comprend comment les timbres se combinent. Retirer les cuivres pour ne garder que les cordes, au nom de la simplification, ne produit pas un meilleur orchestre. Ça produit un orchestre appauvri.
CAKE est construit sur cette conviction : la richesse d'un système ne vient pas de la pureté de son langage unique, mais de la qualité de la coopération entre les langages qu'il orchestre.
L'argument pour le monolinguisme est séduisant : une seule équipe, une seule toolchain, une seule culture de code. Moins de frictions à la frontière entre composants. Moins de context-switching pour les développeurs. En théorie, ça tient.
En pratique, ça produit des systèmes où tout est fait dans le même langage — y compris les parties pour lesquelles ce langage est fondamentalement mal adapté. Du JavaScript pour du calcul intensif. Du Python pour de l'orchestration temps réel. Du Java pour des scripts de déploiement. Le résultat n'est pas de la cohérence — c'est de l'uniformité imposée au détriment de la performance.
J'ai vu des équipes passer des mois à optimiser du code dans un langage mal choisi, alors qu'une couche de 200 lignes dans le bon langage aurait résolu le problème en une semaine. Le coût du monolinguisme est réel, il est mesurable, et il est presque toujours invisible dans les décisions d'architecture initiales.
Dans une architecture multi-langages mature, chaque couche du système est confiée au langage le mieux positionné pour la servir. Pas le langage que tout le monde connaît déjà. Pas le langage à la mode. Le langage dont les propriétés fondamentales — modèle mémoire, paradigme, écosystème — correspondent au profil de la couche en question.
Ce tableau n'est pas une prescription universelle. C'est une illustration d'un principe : les décisions de choix de langage devraient être des décisions architecturales, pas des habitudes d'équipe. Chaque couche mérite qu'on se pose la question honnêtement : quel est le langage qui sert le mieux ce rôle précis ?
La promesse des architectures multi-langages ne se tient que si les composants peuvent communiquer sans friction excessive. L'interopérabilité n'est pas un détail d'implémentation — c'est une décision architecturale de premier ordre qui doit être prise avant d'écrire la première ligne de chaque composant.
Dans CAKE, j'ai fait un choix délibéré : les interfaces entre couches sont définies en CXML — le langage de structure du système. Ce n'est ni du JSON, ni du Protobuf, ni du OpenAPI, bien qu'il puisse générer vers ces formats. C'est une déclaration d'intention dans le langage du système lui-même. Chaque contrat entre composants est un artefact CAKE — versionné, validé, traçable dans le pipeline.
Cela change profondément la nature de l'interopérabilité. Elle n'est plus un pont improvisé entre deux systèmes qui ne se connaissaient pas. Elle devient une conversation structurée entre des composants qui ont été conçus pour se parler.
C% n'est pas le langage dans lequel on écrit la logique métier de CAKE. C'est le langage dans lequel on décrit comment les autres langages coopèrent. C'est une distinction fondamentale. Un chef d'orchestre ne joue pas de tous les instruments — il comprend suffisamment chacun d'eux pour savoir quand et comment les faire sonner ensemble.
Cette position d'orchestrateur est à la fois plus humble et plus puissante que celle d'un méta-langage universel. Elle reconnaît que chaque composant a son domaine de souveraineté. Elle ne cherche pas à l'absorber — elle cherche à le coordonner. Et c'est précisément cette retenue qui rend l'architecture extensible sans la rendre ingouvernable.
Un système multi-langages mal conçu est une tour de Babel. Un système multi-langages bien conçu est un orchestre. La différence n'est pas dans le nombre de langages — elle est dans la qualité de la partition qui les unit. — Sébastien Roy, CEO Unibool Inc.
Les architectures multi-langages ne sont pas un compromis face à la complexité. Elles sont une réponse mature à la réalité des systèmes modernes — où chaque domaine mérite l'outil conçu pour lui, et où la cohérence vient de l'orchestration, pas de l'uniformité.
Utiliser le bon langage au bon endroit n'est pas de l'indiscipline. C'est du respect envers le problème qu'on cherche à résoudre.