Aller au contenu
GS-Apps

Lexique technique — les acronymes du parc

Vous êtes ici : Démarrer — l’aide-mémoire des acronymes qui reviennent partout dans la documentation. Chaque sigle : son expansion, une phrase de sens, un lien pour approfondir. Lecture 5 min (ou consultation ponctuelle). Audience : tous publics. Date : 2026-07-17 | Version : 1.0 — création (MASTER-DOCS-LEXIQUE-DIMENSIONNEL)

Accès et sécurité

Section intitulée « Accès et sécurité »
Terme Nom complet En une phrase
RLS Row-Level Security Isolation par ligne directement en base : un prédicat sur company_id borne chaque requête à la compagnie courante, fail-closed (aucun contexte, aucune ligne). Détail : Architecture de données §3.
RBAC Role-Based Access Control Contrôle d’accès par rôles : les droits viennent du rôle porté par compagnie et par module, jamais de l’individu en dur. Détail : Modèle d’accès.
SESSION_CONTEXT — Mécanisme SQL Server qui porte le contexte de la requête (compagnie courante, flags de service) ; c’est lui que lit le prédicat RLS. Détail : Architecture de données §3.
TVF Table-Valued Function (fonction table) La forme SQL du prédicat RLS : une seule fonction, fn_company_predicate, appliquée par une politique par schéma — jamais un prédicat par table. Détail : Architecture de données §3.
PII Personally Identifiable Information (renseignements personnels) Toute donnée qui identifie une personne (courriel, adresse, salaire) ; classée par sensibilité et protégée par la Loi 25 (Québec). Détail : Sécurité.
A3 Sélecteur de contexte (chantier A3) Le mécanisme par lequel un administrateur corporatif bascule explicitement dans le contexte d’une compagnie administrée — scopé à une compagnie, re-validé par le serveur à chaque requête, audité.
Modèle B — Le modèle d’administration corporative : un admin corporatif a une compagnie d’attache (home) plus un « chapeau » d’administration sur les compagnies déléguées — le chapeau ne donne aucun accès aux données sans contexte porté. Détail : Modèle d’accès.
bind-to-fetch — Règle du standard de contrôle d’accès : l’autorisation est résolue au moment de la lecture, dans le dépôt de données — jamais un booléen calculé par l’appelant, jamais un paramètre client pris de confiance.
isCorporateAdmin — Propriété de l’utilisateur résolu, dérivée de la donnée ug (jamais codée en dur) ; elle correspond au bypass corporatif du prédicat RLS. Détail : Modèle d’accès.
FF-PII-05 Fitness function PII no 5 Garde CI qui impose un chemin de lecture unique pour les données de rémunération : toute lecture passe par le dépôt dédié qui journalise l’accès — un contournement fait rougir le CI.
GDAP Granular Delegated Admin Privileges Délégation d’administration granulaire consentie à un fournisseur d’infogérance sur le tenant Microsoft 365 : des rôles précis, une durée limitée — remplace l’ancien accès délégué global.
JWT JSON Web Token Jeton signé émis par Entra ID que les backends valident à chaque requête ; il porte l’identité et le tenant d’origine. Détail : Stratégie d’authentification.
MSAL Microsoft Authentication Library Bibliothèque Microsoft utilisée côté client pour la connexion Entra ID et l’obtention des jetons. Détail : Azure AD / Entra ID.
CSP Content Security Policy En-tête HTTP qui déclare ce que le navigateur a le droit de charger (scripts, images, iframes) — première défense contre l’injection de contenu. Détail : Sécurité.
SAS Shared Access Signature URL signée à durée limitée pour accéder à un blob Azure Storage sans exposer le compte — le serveur signe, le client consomme.

Données

Section intitulée « Données »
Terme Nom complet En une phrase
OLTP Online Transaction Processing Le traitement transactionnel : les apps lisent et écrivent au fil de l’eau (créer un bon, accorder un rôle). Détail : Architecture de données.
OLAP Online Analytical Processing Le traitement analytique : on agrège l’historique pour décider (coût par véhicule, taux de conformité). Détail : Architecture de données.
Médaillon (architecture medallion) Le patron de raffinage par couches de la plateforme analytique : bronze (brut, un schéma stg_ par source), silver (nettoyé, conformé), gold (agrégats servis). Détail : Architecture de données §2.
dim / fact dimensions / faits Les deux familles du modèle dimensionnel : les dimensions sont les objets (employés, véhicules, calendrier), les faits sont les événements mesurables (factures, plans). Détail : Modélisation dimensionnelle.
Star schema schéma en étoile La forme canonique du modèle dimensionnel : une table de faits au centre, ses dimensions autour. Détail : Modélisation dimensionnelle.
Grain — La définition exacte de ce que représente une ligne d’une table de faits (« une ligne = une facture ») — la première décision de toute modélisation. Détail : Modélisation dimensionnelle.
Surrogate key clé de substitution Clé technique générée par la plateforme (plutôt que la clé du système source) qui identifie une ligne de dimension ou de fait — elle découple le modèle des identifiants source. Détail : Modélisation dimensionnelle.
SCD Slowly Changing Dimension Les stratégies de gestion du changement dans une dimension : type 1 (écraser), type 2 (historiser par versions), type 3 (colonne « valeur précédente »). Détail : Modélisation dimensionnelle.
Dimension conforme conformed dimension Une dimension partagée par plusieurs tables de faits — et, chez GS-Apps, par les apps elles-mêmes comme donnée de référence. Détail : Modélisation dimensionnelle.
FK Foreign Key (clé étrangère) Colonne qui référence la clé d’une autre table ; c’est le lien fait-vers-dimension et le lien entre domaines OLTP.
ETL Extract, Transform, Load La chaîne qui extrait les données des sources, les transforme et les charge dans la plateforme — chez GS-Apps, un worker dédié, jamais un backend web. Détail : Cycle de vie des données.
Watermark — Le repère d’avancement d’une synchronisation incrémentale ; chez GS-Apps il est métier (basé sur le statut des données), pas temporel. Détail : Cycle de vie des données.
SOFI — L’ERP opérationnel de Groupe Signalisation (on-prem), première source de la plateforme de données — lu en lecture seule, jamais écrit. Détail : Architecture de données.
BC Bounded Context (contexte borné) Frontière d’un domaine métier : un schéma SQL et un module applicatif par domaine (inv, bil, fbk…), pas de jointure sauvage entre domaines. Détail : Architecture de données §1.
BI Business Intelligence L’informatique décisionnelle : tableaux de bord, rapports et KPI construits sur la couche servie (gold, fact).
KPI Key Performance Indicator Indicateur clé de performance — chez GS-Apps, une table gold pré-calculée par la plateforme plutôt qu’une formule recalculée par chaque écran.

Architecture et code

Section intitulée « Architecture et code »
Terme Nom complet En une phrase
ADR Architecture Decision Record Document court qui fige une décision d’architecture, son contexte et ses conséquences — la source de vérité citée partout dans ce site (ADR-056, ADR-061…).
DTO Data Transfer Object Objet façonné pour le transport entre serveur et client : on expose le DTO, jamais la ligne SQL brute — c’est lui qui décide ce que le client a le droit de voir.
MCP Model Context Protocol Protocole qui expose des outils (requêtes en lecture, statut CI, santé des apps) aux assistants IA — GS-Apps opère son propre serveur MCP.
Monorepo — Un seul dépôt Git pour toutes les apps et tous les packages partagés — une version, un build, une CI.
Turbo Turborepo L’orchestrateur de build du monorepo : il ne reconstruit que ce qui a changé et met le reste en cache.
CI/CD Continuous Integration / Continuous Deployment La chaîne automatique qui valide (build, tests, gates) puis déploie chaque changement poussé sur la branche principale.
RLS gate — Le verrou CI qui prouve l’isolation entre compagnies à chaque exécution : un test comportemental rejoue la lecture sans contexte et exige zéro ligne — une politique RLS supprimée fait rougir le CI. Détail : Architecture de données §3.
KW Known Warning Registre interne des avertissements connus et numérotés (KW-017, KW-049…) : un comportement piégeux documenté avec sa parade, pour ne pas re-payer le même diagnostic.
IaC Infrastructure as Code L’infrastructure décrite dans des fichiers versionnés plutôt que cliquée dans un portail — toute commande manuelle doit avoir sa contrepartie dans le code.
Bicep — Le langage IaC d’Azure utilisé par GS-Apps pour décrire ses ressources (App Services, SQL, storage).
MI Managed Identity (identité managée) Identité portée par la ressource Azure elle-même : l’app s’authentifie à SQL ou au storage sans secret à stocker ni faire tourner. Détail : Managed Identity.
Entra ID (anciennement Azure AD) Le service d’identité de Microsoft : comptes, tenants, App Registrations — la porte d’entrée de toute authentification GS-Apps. Détail : Azure AD / Entra ID.
VNet Virtual Network (réseau virtuel) Réseau privé Azure qui isole les ressources ; c’est par lui que la plateforme atteint SOFI on-prem sans exposition publique.
SPA Single-Page Application Application web chargée une fois puis pilotée côté navigateur — le modèle de la plupart des apps de la suite.
SSR Server-Side Rendering Rendu des pages côté serveur avant l’envoi au navigateur — le modèle du portail public, où le premier affichage doit être immédiat.

Pour aller plus loin

Section intitulée « Pour aller plus loin »