Aiguillage des couches — où va une nouvelle donnée analytique

Vous êtes ici : Comprendre — les fondations : la question qu’on se pose avant de créer une table analytique. Les quatre couches, et la règle qui dit dans laquelle une nouvelle donnée doit naître. Lecture 8 min. Audience : devs, architectes, analystes. Date : 2026-08-11 | Version : 1.1 — la doctrine d’aiguillage est passée de proposée à acceptée le jour même (six arbitrages, dont un renversement)

État : doctrine acceptée le 2026-08-11

Les couches décrites ici étaient déjà établies. La règle d’aiguillage entre elles — l’objet principal de cette page — a été formulée par un audit du 11 août 2026 puis tranchée le même jour : six questions arbitrées, dont une renversée par rapport à la recommandation de l’audit (voir § Ce qui a été tranché).

Elle fait donc désormais règle. Le document de décision porte le détail des motifs ; c’est lui qui fait foi : voir l’index des décisions.

TL;DR

Question	Réponse	Détail
Combien de couches ?	Quatre couches logiques — la dernière a trois formes	§ Les quatre couches
Pourquoi une doctrine d’aiguillage ?	Deux modèles cohabitaient sans articulation écrite	§ Le trou
Où va ma nouvelle table ?	Quatre questions dans l’ordre	§ L’arbre
Peut-on court-circuiter une couche ?	Oui, sous conditions strictes et déclarées	§ Le chemin direct
C’est décidé ?	Oui — tranché le 2026-08-11, six arbitrages	§ Ce qui a été tranché

1 · Les quatre couches

Les trois formes de la couche servie ne sont ni concurrentes ni successives : ce sont trois presentations du meme rang de maturite de la donnee.

2 · Le problème — deux modèles sans articulation

Deux modèles de référence coexistent dans la plateforme, chacun correctement appliqué :

• le médaillon, qui décrit la maturité d’une donnée — brute, puis nettoyée, puis servie ;
• l’étoile dimensionnelle, qui décrit la structure de présentation — des faits au grain fin entourés de dimensions partagées.

Chacun était documenté. Ce qui manquait, c’est leur articulation : rien ne disait si les dimensions et les faits appartenaient au médaillon, ni à quelle couche, ni quand les emprunter plutôt que de passer par la couche nettoyée.

Un vide doctrinal ne reste pas théorique. Il produit des écarts mesurables : des conventions de nommage divergentes selon la couche, des règles de complétude différentes pour un même besoin, et un catalogue interne qui qualifiait de « en retrait » une famille de tables qui recevait au contraire les créations les plus récentes.

Ce que dit l'état de l'art

Les deux modèles sont complémentaires, pas concurrents. Le patron courant consiste à faire de la couche servie du médaillon une étoile : faits et dimensions sont la couche servie, les agrégats pré-calculés en étant une commodité de consommation. C’est la lecture retenue par la proposition.

3 · L’arbre de décision proposé

Pour toute nouvelle donnée analytique, quatre questions dans l’ordre :

1. Est-ce un axe d’analyse partagé — une entité à laquelle plusieurs mesures ou plusieurs applications se rapportent (qui, quoi, où, quand) ? → une dimension.
2. Est-ce un enregistrement d’événements ou de mesures au grain fin — une ligne par occurrence, des mesures additionnables, des axes qui pointent vers des dimensions ? → un fait, dont le grain doit être déclaré et contraint.
3. Est-ce un agrégat pré-calculé — un indicateur par période ou par entité, re-dérivable depuis les couches inférieures ? → un agrégat.
4. Une étape par la couche nettoyée est-elle obligatoire ? Oui dès qu’un seul de ces critères est vrai :
   • la donnée consolide plusieurs sources en une même entité métier ;
   • elle applique une règle de transformation réutilisable dont un autre consommateur pourrait avoir besoin ;
   • elle réalise un nettoyage qui change des valeurs (pas un simple filtre de plausibilité).

Ce que l'arbre protège réellement

La question n’est pas « combien de couches traverser ». Empiler des copies ne protège rien par soi-même — chaque copie coûte du calcul et de la maintenance.

Ce qui protège, c’est que la règle métier ait un seul domicile. La couche nettoyée devient obligatoire précisément quand une règle mérite d’être partagée : sans elle, chaque consommateur la réimplémente, et les versions divergent.

4 · Le chemin direct — admis sous conditions

Aller de la couche brute directement à un fait, sans étape intermédiaire, est admis — mais seulement si les quatre conditions tiennent ensemble :

Condition	Ce qu’elle garantit
Transformation purement structurelle, ou règle métier entièrement assertée par un test de qualité versionné	La règle est vérifiée, pas seulement écrite
Grain déclaré au catalogue et contraint en base	Deux lignes ne peuvent pas décrire la même occurrence
Résolution des axes faite au chargement, selon une doctrine unique	Une référence absente ne disparaît pas en silence
Chemin déclaré explicitement au catalogue, avec sa justification	L’exception est visible, donc révisable

Le principe : une exception qui ne se déclare pas devient la règle par accumulation. Une exception déclarée reste une exception.

Les chemins existants n'ont pas tous le même statut

La proposition ne se contente pas d’énoncer une règle pour l’avenir : elle statue sur l’existant. Certains chemins directs sont jugés conformes et le restent ; d’autres sont tolérés à charge de converger — soit en satisfaisant les conditions ci-dessus, soit en étant reconstruits lors du prochain chantier qui les touche.

C’est ce qui distingue une doctrine d’un vœu : elle qualifie ce qui existe déjà, avec une échéance.

5 · Ce qui a été tranché

Deux arbitrages structurants méritent d’être connus, parce qu’ils changent des choses visibles.

Une référence absente ne disparaît plus

Chaque dimension reçoit désormais une ligne sentinelle « inconnu ». Les cas non résolus y pointent au lieu de produire une valeur nulle — et les jointures qui rejetaient silencieusement une ligne source la résolvent désormais vers cette sentinelle.

L’option inverse (assumer la valeur nulle et la mesurer par des seuils) était défendable, mais l’expérience interne l’a écartée : une valeur nulle silencieuse peut persister des mois sans que personne ne s’en aperçoive, alors qu’une ligne « inconnu » apparaît dans tout rapport et se fait remarquer.

Conséquence à anticiper — des chiffres vont bouger, à la hausse

Les lignes aujourd’hui rejetées par les jointures strictes vont réapparaître. Les comptes des tables concernées augmenteront.

C’est une correction, pas une régression — ces lignes existaient à la source et étaient perdues en chemin. Mais la conséquence pratique est nette : les références des assertions de qualité concernées doivent être re-mesurées dans le même lot que le changement, sinon elles rougiront toutes en signalant un progrès.

Une seule convention de nommage sur toute la couche servie

La couche servie et analytique — nettoyée, dimensions, faits, agrégats — porte une seule convention : snake_case en anglais.

C’est l’arbitrage qui a été renversé par rapport à la recommandation de l’audit. Celui-ci proposait de geler l’existant et de n’imposer la convention qu’aux nouvelles tables, pour éviter des renommages. L’uniformité l’a emporté sur l’économie de court terme.

La frontière à ne pas confondre

Cette convention s’arrête à l’analytique. Les tables transactionnelles des modules applicatifs conservent leur propre convention. Il n’y a pas une convention unique pour toute la base : il y en a deux, et la frontière entre elles est précisément la frontière de couche — ce qui la rend lisible plutôt qu’arbitraire.

Toute nouvelle table de la couche servie naît directement dans la convention cible, pour ne pas grossir le lot de renommages.

Pour aller plus loin

• Architecture de données — la carte réelle des schémas et l’isolation par compagnie.
• Modélisation dimensionnelle — faits, dimensions, grain et historisation en détail.
• Ingestion et fraîcheur — ce qui alimente la couche brute.
• Qualité des données — les assertions qui rendent une règle métier vérifiable.
• Comment GS-Apps décide — pourquoi une proposition reste visible tant qu’elle n’est pas tranchée.