Il y a une vérité inconfortable que tout architecte de système extensible doit accepter tôt : plus ton système peut faire, plus il peut se casser. L'extensibilité n'est pas une propriété neutre. C'est une amplificateur — elle amplifie le meilleur de tes décisions architecturales, et le pire aussi. La sécuriser n'est pas optionnel. C'est la condition de sa survie.
J'ai fait cette erreur dans les premières itérations de CAKE. J'étais tellement focalisé sur la capacité du système — sur tout ce qu'il pouvait accueillir, intégrer, orchestrer — que j'ai sous-estimé ce que ça impliquait de laisser entrer des composants que je n'avais pas écrits moi-même. Des extensions tierces avec leurs propres hypothèses. Des runtimes avec leurs propres gestions mémoire. Des pipelines avec leurs propres définitions du succès et de l'échec.
Le résultat était spectaculaire dans les démos et fragile en production. J'ai dû tout reprendre avec une question différente : non plus qu'est-ce que ce système peut faire ? — mais qu'est-ce que ce système peut tolérer sans se briser ?
Après plusieurs cycles de refactoring douloureux, j'ai distillé la sécurité d'un système extensible en trois règles fondamentales. Pas des guidelines — des invariants. Des propriétés que le système doit garantir en toutes circonstances, peu importe ce que les extensions lui demandent de faire.
Ces trois règles semblent simples. Elles sont profondément difficiles à maintenir sous la pression du développement — quand un délai approche, quand une fonctionnalité est urgente, quand quelqu'un dit "juste pour cette fois, on court-circuite la validation". La discipline architecturale, c'est précisément de ne jamais céder à ce genre d'arguments.
Le concept d'isolation dans CAKE va plus loin que le simple sandboxing. C'est une philosophie de conception : chaque moteur du système doit être capable de mourir proprement. De tomber en panne, de produire une erreur, de crasher — sans que cette mort contamine ses voisins.
Cette architecture en couches n'est pas une curiosité théorique. Elle a des conséquences pratiques immédiates : quand un runtime expérimental échoue dans CAKE, le pipeline continue. Quand une extension produit un output malformé, la couche d'interface l'intercepte avant qu'il ne propage. Quand un module consomme trop de ressources, le système peut l'isoler sans arrêter l'ensemble.
J'appelle ça le principe du verre feuilleté : une vitre ordinaire, quand elle se brise, envoie des éclats partout. Une vitre feuilletée se fissure, se déforme, mais reste en place. Elle contient ses propres dégâts. Les architectures extensibles bien conçues se comportent de la même façon.
Dans CAKE, la validation d'une extension n'est pas un simple check de compatibilité de version. C'est un dialogue entre le système et le composant entrant. Le système pose des questions : quelles sont tes dépendances ? quelles interfaces tu exposes ? quel est ton comportement attendu en cas d'erreur ? quelles ressources tu consommes ?
Un composant qui ne peut pas répondre à ces questions — qui n'a pas de dépendances déclarées, pas d'interfaces explicites, pas de stratégie d'erreur — n'entre pas dans le système. Pas parce qu'il est mauvais, peut-être. Mais parce qu'il est inconnaissable. Et un composant inconnaissable est plus dangereux qu'un composant défaillant.
Le danger dans un système complexe ne vient presque jamais de ce qu'on sait être défaillant. Il vient de ce qu'on croit correct sans l'avoir vérifié. La validation n'est pas de la méfiance — c'est de l'hygiène architecturale. — Sébastien Roy, CEO Unibool Inc.
Un système extensible non traçable est un système dont vous avez perdu le contrôle sans vous en rendre compte. Vous pouvez encore le faire tourner — mais vous ne savez plus vraiment pourquoi il tourne. Et quand il s'arrête, vous ne saurez pas non plus pourquoi il s'est arrêté.
Dans CAKE, la traçabilité n'est pas une fonctionnalité de débogage ajoutée après coup. C'est une propriété première de l'architecture. Chaque extension active laisse une empreinte dans le registre du système. Chaque moteur exécuté est loggé avec son contexte d'activation. Chaque pipeline tracé peut être rejoué, inspecté, audité.
Cette traçabilité a un coût en performance — léger, mais réel. J'ai fait le choix délibéré de l'accepter. Parce que la vraie question n'est pas est-ce que ce log ralentit mon système de 2% ? La vraie question est : quand ce système tombe à 3h du matin, est-ce que j'ai les informations pour le relever en 10 minutes ou en 10 heures ?
Sécuriser un système extensible, ce n'est pas le fermer. C'est construire les conditions dans lesquelles il peut rester ouvert sans se mettre en danger. Validation, isolation, traçabilité — ces trois piliers ne contraignent pas l'innovation. Ils lui donnent un sol sur lequel tenir debout.
Un système extensible sans sécurité n'est pas puissant. Il est simplement fragile à grande échelle.