Module Management tient un registre vivant de chaque module que la plateforme peut offrir et contrôle l'état d'activation de chacun par déploiement. Les administrateurs activent un module pour intégrer l'ensemble de sa surface dans le système en fonctionnement, ou le désactivent pour retirer proprement cette surface, et le changement prend effet dans toute la suite en une seule fois. Lorsqu'un module est désactivé, ses entrées de navigation disparaissent de la barre latérale, ses routes cessent de répondre et ses points d'accès programmatiques refusent l'accès : une capacité désactivée est donc véritablement absente plutôt que simplement masquée derrière un menu.

Le registre porte l'identité descriptive de chaque module : son nom d'affichage et sa description, l'icône et le chemin de base qui l'ancrent dans la navigation, l'ordre qui fixe sa position dans la barre latérale, et l'indicateur signalant s'il est fondamental pour la plateforme. Il détient également les dépendances déclarées de chaque module, à savoir les autres capacités qui doivent être présentes pour qu'il fonctionne. Par-dessus cela, le module distingue les capacités fondamentales, telles que les socles d'administration système et de dashboard, dont la plateforme a besoin pour fonctionner et qu'il protège par conséquent de toute désactivation. Il en résulte une couche de composition qui permet à une organisation d'adapter la suite à sa structure tout en garantissant que la plateforme ne descende jamais en dessous du minimum nécessaire à son fonctionnement.

Au centre de ce domaine se trouve la notion de module : une capacité métier autonome dotée d'une identité stable, d'une place dans la navigation et d'une frontière définie pour les données et les actions qu'elle gouverne. Chaque module est désigné par un nom court unique qui ne change jamais, de sorte que le reste de la plateforme puisse s'y référer de façon fiable même à mesure que sa description, son icône ou sa position sont affinées au fil du temps. Autour de cette identité gravitent le détail de présentation qui donne au module son visage dans l'interface, et l'ordre qui décide de son emplacement par rapport à ses pairs.

Le deuxième concept organisateur est l'état d'activation, le fait simple mais lourd de conséquences de savoir si une capacité fait actuellement partie du déploiement. L'état n'est pas cosmétique : il détermine d'un seul coup la navigation, le service des routes et l'accès, raison pour laquelle le registre le traite comme la source de vérité faisant autorité sur ce que la plateforme offre à l'instant présent. Le troisième concept est la dépendance, la relation que chaque module déclare envers les autres dont il dépend. Une capacité qui s'appuie sur l'infrastructure de connecteurs ou sur le socle système nomme ces besoins de façon explicite, et le registre lit ces déclarations comme un graphe plutôt que comme une liste à plat, si bien que l'activation ou la désactivation d'une capacité est toujours évaluée au regard de l'ensemble des relations qui l'entourent. Une quatrième distinction, celle de savoir si un module est core, met à part les socles sans lesquels la plateforme ne peut fonctionner, et ces socles sont maintenus activés en permanence. Ensemble, ces concepts décrivent un système qui se compose plutôt qu'il ne se fige, où la forme de la suite est une configuration explicite et gouvernée.

Le workflow déterminant est la composition. Un administrateur passe en revue le registre, voit chaque module avec son état actuel, sa description et ses dépendances, puis active ou désactive des capacités pour répondre aux besoins de l'organisation. Lorsqu'un module est activé, ses dépendances déclarées sont vérifiées afin qu'il ne soit jamais mis en service sans les capacités dont il a besoin ; le registre fait remonter toute condition préalable manquante et active la chaîne dans le bon ordre. Lorsqu'une capacité est désactivée, le registre vérifie dans l'autre sens, en identifiant les modules qui dépendent de celle qui est retirée, de sorte que rien ne reste pointé vers une capacité absente. Cette évaluation bidirectionnelle transforme ce qui pourrait être un exercice manuel fragile en une opération guidée et sûre.

Au-delà de l'activation et de la désactivation, les administrateurs entretiennent les métadonnées des modules, en ajustant les descriptions, les icônes et l'ordre dans la barre latérale afin de maintenir une navigation cohérente à mesure que le déploiement évolue. Ils gouvernent le registre lui-même, en examinant quelles capacités sont actives, lesquelles sont maintenues inactives et comment l'ensemble de l'empreinte est agencé. Chacune de ces actions est une opération administrative protégée par permission : composer la plateforme est donc un acte délibéré accompli par ceux qui y sont habilités, et le registre en vigueur reflète toujours une configuration réfléchie plutôt qu'une dérive accumulée.

La valeur d'une couche de composition réside dans la rigueur avec laquelle elle impose la cohérence, et Module Management se montre exigeant à cet égard. La gestion des dépendances est transitive : puisque les dépendances forment un graphe, le registre les résout le long de leurs chaînes complètes, de sorte que l'activation d'une capacité fait remonter tout ce qui se trouve en dessous d'elle, et que la désactivation de l'une est bloquée ou propagée en cascade selon ce qui en dépend encore. Cela évite l'échec classique d'une plateforme où une fonctionnalité est nominalement présente mais silencieusement défaillante parce qu'un élément dont elle avait besoin n'a jamais été activé.

La protection du core est absolue. Les modules fondamentaux dont la plateforme dépend pour fonctionner sont marqués comme core et ne peuvent en aucun cas être désactivés, ce qui écarte toute une catégorie de pannes auto-infligées. L'application des règles relève de la défense en profondeur plutôt que d'un contrôle unique : désactiver un module le retire de la navigation, arrête ses routes et refuse ses points d'accès, de sorte que la frontière tient, qu'une requête arrive par l'interface ou directement contre la surface programmatique de la plateforme. Parce que l'état d'activation et la frontière d'accès ne font qu'un, il n'existe aucun écart entre ce qu'un utilisateur peut voir et ce qu'il peut atteindre. Le registre préserve également une identité stable pour chaque module, si bien que les permissions, les enregistrements d'audit et les intégrations qui référencent une capacité restent valides à travers chaque changement de sa présentation, et que la composition de la suite demeure lisible et gouvernable quel que soit le nombre de fois où elle est remodelée.

Module Management est la couche par laquelle chaque autre partie de la suite devient disponible. Il agit de concert avec le socle de permissions et de contrôle d'accès : le registre décide si une capacité existe dans un déploiement, et le contrôle d'accès décide qui peut l'utiliser, les deux formant ensemble la réponse complète à ce que tel ou tel utilisateur peut faire. Il s'appuie directement sur Connector Management, puisque les modules d'intégration de données déclarent leur dépendance à l'infrastructure de connecteurs et que le registre honore cette relation lorsqu'il les compose. Des capacités telles que Content Management se situent en aval, ne se mettant en service que lorsque leurs conditions préalables système et connecteurs sont satisfaites.

Parce que le registre gouverne la barre latérale, il façonne l'expérience offerte par le Dashboard et la navigation dont hérite chaque module opérationnel, de la finance et des achats jusqu'aux capacités relatives aux effectifs et aux actifs. La couche d'audit et d'activité de la suite consigne les changements apportés au registre au même titre que tout autre événement administratif, de sorte que l'historique de la façon dont la plateforme a été composée réside au même endroit que le reste du dossier opérationnel de l'organisation. En pratique, Module Management est la couture qui permet à une suite unique de se présenter sous la forme d'autant de plateformes différentes, chacune ajustée avec précision à la division ou à l'entité qui l'exploite, tout en restant un seul système cohérent en dessous.

Les AI Workers sont des utilisateurs de plein droit de Module Management, opérant à travers le même registre et la même frontière de permissions que n'importe quel administrateur. Un administrateur peut demander à un Worker, en langage naturel, quelles capacités sont activées dans un déploiement, ce dont dépend un module donné, ou quels modules seraient affectés par le retrait d'une capacité particulière, et le Worker répond en lisant le registre en direct et en parcourant le graphe des dépendances. Cela fait de la composition de la plateforme quelque chose qu'un administrateur peut interroger de façon conversationnelle plutôt que de reconstituer à la main.

Les Workers agissent également. Dans les limites des permissions qui leur sont accordées, un Worker active ou désactive des modules, résout la chaîne de dépendances qu'un changement requiert et ajuste les métadonnées des modules, réalisant ainsi la composition qu'un administrateur décrit. Ils surveillent le registre à la recherche d'anomalies et d'exceptions : une capacité activée sans une dépendance qu'elle devrait avoir, une configuration qui s'écarte d'un standard gouverné, une tentative de perturber un socle core, et ils les signalent sous forme d'alertes avant qu'elles ne deviennent des défaillances. Lorsque les déclarations d'un module ou une configuration proposée arrivent sous la forme d'un document ou d'une définition externe, les Workers en extraient la structure pertinente et la rapprochent du registre. En aide à la décision, ils pèsent l'impact en aval d'un changement et en exposent les conséquences, et dans les workflows gouvernés, ils participent en tant que nœud d'approbation ou de revue, examinant un changement proposé de la composition de la plateforme et l'approuvant ou le suspendant selon les règles que l'organisation a fixées, de sorte que le remodelage de la suite soit à la fois plus rapide et plus discipliné.