Vous êtes ici : Référence — les faits : de quoi la plateforme est composée, module par module.
Le parc réel : conteneurs (les backends) et modules (le grain auquel un accès s’accorde).
Lecture : consultation. Audience : devs, administrateurs, auditeurs.
Date : 2026-08-11 | Version : 1.0 — page générée, créée par la refonte de l’architecture d’information
Le principe central — deux niveaux, et un seul est grantable
La distinction est la racine d’une confusion historique, et elle vaut d’être posée nettement :
un conteneur est un backend déployé, qui regroupe plusieurs capacités. Il porte la frontière technique et la frontière de données ;
un module est une capacité dans un conteneur. C’est le grain auquel un accès s’accorde : on donne accès à un module, jamais à un conteneur.
La hiérarchie conteneur → module est un sens de lecture , pas une structure stockée : la liste des modules est plate, et l’appartenance est un attribut.
Cette page est générée, et gardée par un test
Le tableau ci-dessous est dérivé du catalogue exécutable qui sert déjà de source unique au code applicatif, aux écrans d’administration et aux contraintes en base. Un test d’intégration continue vérifie que ces trois usages restent identiques : ajouter un module sans mettre le catalogue à jour est détecté.
Recopier ce tableau à la main sur ce site aurait créé un quatrième exemplaire, celui-là non gardé — exactement la deuxième vérité que la règle de canonicité interdit.
Colonne
Ce qu’elle signifie
Module
Le code court — c’est lui qui apparaît dans un accès accordé
Rôle
Ce que le module fait, en une phrase
Préfixe
Le préfixe des objets de données du module — la frontière de données, visible dans les noms
Statut
L’état de mise en service (voir ci-dessous)
Statut
Ce qu’il veut dire
actif
En service, la donnée circule
en cours
En construction, partiellement livré
renaissance
Existant, en cours de réécriture sur les standards courants
planifié
Décidé et catalogué, pas encore construit
Un module catalogué n'est pas un module livré
La majorité des modules ci-dessous sont planifiés : ils existent dans le catalogue pour que la frontière de données et le vocabulaire d’accès soient réservés d’avance, pas parce qu’ils tournent.
C’est délibéré — réserver le préfixe et la clé d’accès avant de construire évite les renommages ultérieurs, qui sont coûteux en base. Mais la lecture doit être faite : le catalogue décrit la carte, pas le territoire livré .
Administration Module Rôle Préfixe Statut ADM — Admin / back-office / configBack-office, configuration et paramètres système. ADM_actif HUB — Hub (nav, dashboard)Navigation centrale et tableau de bord d'accueil. HUB_actif BIL — Facturation (Ville de Québec)Facturation B2B — pilote Ville de Québec. BIL_en cours GEST — GS GestionPortail de gestion interne — équipes, rencontres, pulse, finance, rémunération, publications. GEST_en cours
Opérations Module Rôle Préfixe Statut INV — InventaireSuivi de l'inventaire et des stocks. INV_actif EXP — DépensesGestion et suivi des dépenses. EXP_planifié FLT — FlotteGestion de la flotte de véhicules. FLT_planifié PLT — PalettesSuivi des palettes et de leurs mouvements. PLT_planifié MNT — MécaniqueEntretien mécanique et garages internes. MNT_planifié
Loisirs Module Rôle Préfixe Statut FIT — FitActivités et loisirs (Fit). FIT_renaissance RCP — RecettesCatalogue de recettes. RCP_planifié TRI — TriviaTrivia — quiz et jeux-questionnaires. TRI_planifié
SST Module Rôle Préfixe Statut HSE — Salus / santé-sécuritéRéservée : Salus, plateforme externe ingérée par ZoneSecur, sans application. HSE_planifié TRN — FormationRéservée : SOFI Formation, application distincte hors du dépôt. TRN_planifié ZSC — Zone SécurSanté-sécurité : dossiers de lésion et CNESST, incidents, prévention et formulaires SST. ZSC_en cours
Portail Module Rôle Préfixe Statut PTL — Portail (QR véhicules)Portail public — QR codes véhicules. PTL_actif
Chaque module possède ses propres objets de données, reconnaissables à leur préfixe. Deux règles en découlent, et elles ne souffrent pas d’exception :
Un module écrit ses propres données. Deux modules n’écrivent jamais dans le même objet : il y a toujours un propriétaire unique, les autres lisent.
Une lecture entre modules passe par un contrat explicite — une vue dédiée, en lecture seule — jamais par une jointure directe qui traverserait la frontière.
L’intérêt est de rendre un module décommissionnable : on peut retirer une capacité sans démêler ses données de celles des autres. Une frontière qu’on ne voit pas dans les noms est une frontière qu’on franchit sans s’en apercevoir.