Schéma de données — modèle et patterns
Cette référence décrit le modèle de données au niveau architecture : ses domaines, sa répartition entre bundles et ses patterns. Elle ne publie pas le détail des colonnes (discipline airlock : la structure d'une base est une information de reconnaissance, on en documente la conception, pas la surface d'attaque).
Deux moteurs de stockage, rĂ´les disjoints
| Moteur | Usage |
|---|---|
| SGBD relationnel | Données applicatives (tous les domaines ci-dessous) |
| Base embarquée + extension vectorielle | Index RAG (recherche kNN par similarité cosinus) |
Le modèle par domaine
Les entités sont réparties entre quatre bundles plus le cœur applicatif. Chaque bundle déploie ses entités de façon autonome (auto-mapping, sans fichier de mapping ni migration au bootstrap). L'application ne maintient que ses propres entités et résout les entités cibles que les bundles réclament par interface (voir patterns).
| Domaine | Porté par | Rôle |
|---|---|---|
| Identité & accès | cœur applicatif | Comptes, authentification, second facteur, appareils de confiance, réinitialisation. Aucun secret n'est stocké en clair : mots de passe hachés, jetons et secrets 2FA hachés ou chiffrés. |
| CMS multisite | bundle socle | Sites (résolution par host), contenus éditoriaux (slug unique par site), étiquettes, médias (validation MIME réelle), extensions SEO en entités compagnons. |
| Veille | bundle produit | Sources planifiées, items collectés avec déduplication par empreinte de contenu, journal de tentatives pour diagnostic, cycle de vie de proposition (statuts), état de lecture par utilisateur. |
| Métriques | bundle produit | Usage et coûts d'appels LLM agrégés par dimension, alertes de seuil, cache local des identifiants de clés. |
| Tenancy MCP | bundle MCP | Locataires, clients API (jeton jamais stocké — uniquement son empreinte), projets (racine de corpus), journal d'audit des appels d'outils. |
Le détail des champs de chaque entité vit dans la doc de production de chaque repo (-doc), pas dans la vitrine.
Patterns Doctrine notables (le cœur du savoir-faire)
- Auto-mapping — toutes les entités des bundles sont auto-mappées : aucun fichier de mapping XML/YAML, aucune migration au bootstrap. Un bundle apporte ses tables sans configuration côté hôte.
- Entité compagnon — pour étendre une entité d'un bundle sans modifier sa table (ex. champs SEO sur un contenu CMS), on l'associe en
OneToOneà une table satellite portée par l'hôte. Le bundle reste maître de sa table ; l'application l'enrichit par le côté. resolve_target_entities— les bundles ne dépendent pas d'une classeUserconcrète : ils déclarent leurs interfaces (utilisateur du CMS, lecteur de veille…) et l'application résout l'entité cible en configuration. Découplage → testabilité et réutilisabilité des bundles.- Dénormalisation d'audit — le journal d'audit stocke ses identifiants en colonnes scalaires plutôt qu'en clés étrangères : choix délibéré pour conserver l'historique même après suppression du tenant ou du client audité.
- Lifecycle callbacks — horodatages
created_at/updated_atgérés par callbacks d'entité (PrePersist/PreUpdate), sans listeners globaux. - Singleton par clé naturelle — certains stores clé/valeur utilisent une clé métier comme clé primaire plutôt qu'un auto-increment.
Index vectoriel (RAG)
En dehors du SGBD relationnel, le moteur RAG utilise une base embarquée dotée d'une extension vectorielle pour la recherche kNN : des fragments (chunk) porteurs de leur provenance et de leur vecteur, interrogés par proximité cosinus. Ce store est géré par le composant RAG, pas par l'ORM.
Pour aller plus loin
- Socle Symfony — référence — le multisite et le CMS.
- Serveur MCP — référence — tenancy, clients, audit.
- Moteur RAG — référence — l'index vectoriel et la récupération.