La Gestion du système rassemble la surface opérationnelle de la plateforme en un seul endroit. La santé du système rend compte de l'état en direct de l'hôte et du runtime : système d'exploitation, charge du processeur, pression sur la mémoire, temps de fonctionnement et runtime qui alimente l'application, aux côtés du statut et de la taille physique de chaque base de données du parc ainsi que d'un décompte courant des enregistrements qu'elles contiennent. Un inventaire des composants liste les paquets installés et leurs versions, offrant aux administrateurs une image exacte de ce qui est déployé. Les statistiques de cache exposent les caches en mémoire qui accélèrent la plateforme, et une seule action les vide lorsque la configuration doit être rechargée immédiatement.

Deux journaux ancrent la traçabilité. Le journal d'audit est un historique consultable et filtrable des actions à conséquence, filtrable par type d'action et par entité concernée, et exportable vers un tableur pour une revue hors ligne ou à titre de preuve. Le journal d'erreurs capture les défauts et les avertissements de l'application avec leur gravité, leur message, leur pile d'exécution et la route sur laquelle ils sont survenus, de sorte qu'un défaut peut être retracé jusqu'à son origine en quelques secondes. Les paramètres régionaux régissent la locale, le fuseau horaire ainsi que le formatage des dates, des nombres et des devises pour l'ensemble de la plateforme. Le style et l'image de marque contrôlent les couleurs, le logo, le favicon et le nom de marque qui s'affichent sur chaque mise en page. Le mode maintenance, les indicateurs de développement et le mode de fonctionnement de la plateforme complètent l'ensemble, permettant aux administrateurs de signaler sans ambiguïté la posture de l'environnement à chaque utilisateur.

Conceptuellement, la Gestion du système s'organise autour de quatre idées qui se retrouvent rarement ensemble dans un même module mais qui ont ici toute leur place. La première est l'état de la plateforme : la vérité momentanée et mesurée sur la façon dont le système fonctionne. L'état est observé plutôt que rédigé, recueilli en direct depuis l'hôte, le runtime et chaque base de données, et il n'est jamais quelque chose qu'un administrateur modifie, seulement quelque chose qu'il lit et sur lequel il agit.

La deuxième idée est l'enregistrement d'activité. Chaque action significative laisse une trace durable : ce qui a été fait, sur quelle entité, par qui, depuis quelle adresse et à quel moment, avec un détail structuré du changement. Les défaillances forment un enregistrement parallèle, classé par gravité et rattaché au contexte dans lequel elles se sont produites. Les deux sont enrichis au moment de la lecture, si bien qu'un acteur consigné uniquement sous forme d'identifiant est résolu en un utilisateur réel et nommé, issu du domaine de l'identité. Cette séparation, un registre immuable de l'activité tenu à l'écart des données opérationnelles en direct qu'il décrit, est ce qui permet de faire confiance à l'enregistrement.

La troisième idée est la configuration de la plateforme : les choix durables qui façonnent le comportement partout. Les conventions régionales et l'identité visuelle sont chacune conservées sous la forme d'un unique paramètre faisant autorité, lu en permanence par le reste de la suite et écrit uniquement au travers de ce module. La quatrième idée est le parc protégé : l'ensemble des bases de données traité comme un tout récupérable, de sorte qu'une sauvegarde capture un instant cohérent à travers chaque stockage et qu'une restauration ramène la plateforme à cet instant intact. Ensemble, ces quatre concepts décrivent tout ce que la salle de contrôle régit sans exposer aucune de la mécanique qui les sous-tend.

Le rythme quotidien commence par le dashboard de santé. Un administrateur l'ouvre pour confirmer que les services répondent, que la marge de mémoire et de processeur est confortable, et que chaque base de données est en ligne et dimensionnée comme prévu. Lorsqu'un chiffre semble anormal, le même écran propose les remèdes immédiats : vider les caches pour forcer une configuration fraîche, ou inspecter l'inventaire des composants pour confirmer exactement ce qui tourne.

L'investigation passe par les deux journaux. Un problème signalé est retracé en filtrant le journal d'erreurs sur la gravité pertinente et en recherchant le message ou la route, puis en recoupant le journal d'audit pour voir quelle action a précédé la défaillance et quel utilisateur l'a réalisée. Lorsqu'une piste d'audit est requise à des fins de gouvernance ou de litige, l'administrateur filtre sur la période et l'entité concernées et exporte le résultat vers un tableur. Les flux de configuration sont délibérés et vérifiables : un administrateur ouvre les paramètres régionaux ou l'image de marque, effectue un changement, et la plateforme l'adopte globalement, le changement lui-même étant inscrit dans le journal d'audit. La protection intervient de façon planifiée et à la demande : les sauvegardes sont créées et listées comme des points agrégés dans le temps, et une restauration sélectionne l'un de ces points et y ramène le parc. Le mode maintenance encadre toute opération perturbatrice, présentant un signal clair aux utilisateurs pendant que les travaux se déroulent.

La profondeur de ce module réside dans sa rigueur. L'agrégation de santé est véritablement multi-bases : le stockage transactionnel, le stockage de données opérationnelles, le stockage de journalisation, le stockage de configuration, le stockage binaire et l'entrepôt analytique sont chacun mesurés en taille et en nombre de tables et rapportés côte à côte, de sorte que la planification de capacité repose sur des chiffres réels plutôt que sur des estimations. La couverture d'audit est exhaustive par conception. Les changements de mode de fonctionnement, les mises à jour de l'image de marque, les purges du journal d'erreurs et chaque opération de sauvegarde écrivent leurs propres entrées d'audit, ce qui signifie que même les actes d'administration sont eux-mêmes redevables de comptes, et que l'enregistrement ne peut pas être discrètement vidé sans laisser une trace de la purge.

La gestion régionale est traitée comme une question d'exactitude plutôt que comme une question cosmétique. La locale, le fuseau horaire et le formatage des dates, des nombres et des devises sont résolus de façon centralisée afin qu'une valeur soit stockée une seule fois et rendue de manière cohérente partout où elle apparaît, ce qui élimine toute une catégorie d'ambiguïté des opérations transfrontalières. L'image de marque est appliquée comme une lecture globale : chaque mise en page, barre latérale et composant consomme l'identité courante sans avoir besoin d'un accès en écriture, si bien qu'un seul changement se propage partout d'un coup. La journalisation est structurée de bout en bout, avec le trafic des connecteurs capturé dans les deux sens, complet avec la méthode, le statut, la latence et les payloads, offrant aux défaillances d'intégration la même clarté forensique qu'aux défaillances internes. Les sauvegardes sont cohérentes entre les stockages et les restaurations sont à un instant précis, si bien que la reprise est exacte plutôt qu'approximative.

La Gestion du système est la couche sur laquelle repose le reste de la suite. Elle travaille de la façon la plus étroite avec les Utilisateurs et rôles et le cadre de permissions : chaque entrée d'audit et d'erreur est enrichie de détails réels sur l'utilisateur issus de l'identité, et chaque capacité de ce module, de la consultation de la santé à la purge des erreurs en passant par la création de sauvegardes, est encadrée par un sujet de permission à granularité fine. Elle soutient la Gestion des modules, en lisant le registre des modules pour rendre compte des versions et des statuts et en vidant son cache lorsque le registre change.

Sa configuration atteint partout. Les paramètres régionaux alimentent le formatage de la Finance et comptabilité, des Ventes, des Achats et de chaque module qui affiche une date, un montant ou une devise, de sorte qu'un seul choix de locale régit toute la plateforme. L'image de marque est consommée par la mise en page partagée qui encadre chaque écran de la suite. Le journal du trafic des connecteurs donne aux Intégrations un enregistrement précis des entrées et des sorties, et la couverture de sauvegarde agrégée protège les données détenues par chaque module opérationnel en une seule opération cohérente. Parce que la livraison des e-mails et des notifications, la génération de numéros et le flux d'événements acheminent tous leurs actions administratives au travers de la journalisation d'audit et d'erreurs de ce module, la Gestion du système est la couche commune de redevabilité sous l'ensemble du produit.

Les AI Workers opèrent à l'intérieur de la Gestion du système en tant qu'administrateurs de premier plan dotés de leurs propres permissions cadrées. Un administrateur interroge la plateforme de manière conversationnelle, en demandant quelle base de données a le plus grandi ce mois-ci, quelles routes produisent le plus d'erreurs, ou qui a changé l'image de marque la semaine dernière, et le Worker répond directement à partir des métriques de santé et des enregistrements d'audit et d'erreurs plutôt qu'à partir d'un rapport statique. Les Workers exécutent des actions administratives sur instruction : vider les caches, exporter une période d'audit ou lancer une sauvegarde, chaque action étant elle-même auditée exactement comme le serait celle d'un humain.

Leur valeur permanente est la vigilance. Les Workers surveillent en continu la télémétrie de santé et le flux d'erreurs, déclenchant une alerte lorsque la pression sur la mémoire augmente, lorsqu'une base de données approche d'un seuil de capacité, lorsque les taux d'erreurs s'envolent sur une route particulière, ou lorsqu'un schéma anormal d'actions privilégiées apparaît dans la piste d'audit. Ils extraient de la structure des journaux bruts, distillant une salve de traces de pile en une cause racine unique et expliquée, et ils offrent une aide à la décision en corrélant une défaillance avec le changement de configuration ou le déploiement qui l'a précédée. Là où une opération sensible exige une supervision, comme la purge du journal d'erreurs ou la restauration du parc, un Worker fait office de nœud de revue ou d'approbation dans le workflow, vérifiant la demande au regard de la politique et de l'état de santé courant avant que l'action ne soit autorisée à se poursuivre.