Socle PostgreSQL dédié
L'entrepôt là où l'équipe sait déjà opérer
- Mise en œuvre
- 4 à 6 semaines
- Infrastructure
- Une VM 4 vCPU / 16 Go + disque SSD
- Charge humaine
- 0,3 ETP en régime établi
Le recensement décrit 55 tables sur une seule instance PostgreSQL et 11 collections MongoDB. À cette échelle, la première cause de douleur n'est pas le volume : c'est que l'analytique et la production partagent le même moteur. Cette architecture ne change pas de technologie, elle change de frontière.
La pile, couche par couche
- 01
Capture PostgreSQL
Réplication logique native (pgoutput) sur une publication dédiée
Aucune brique tierce, aucune charge de requêtage sur la production, et la latence descend à la seconde. La publication liste explicitement les tables : les binaires d'artifacts et les vecteurs pgvector restent dehors.
- 02
Capture MongoDB
dlt ou Airbyte en incrémental sur _id / last_update
Les 11 collections n'ont pas de schéma. On aplatit à l'ingestion, pas dans le BI. chats.messages[] est éclaté en une table fille dès le staging.
- 03
Moteur
PostgreSQL 16 + PostGIS, instance séparée, 4 vCPU / 16 Go
PostGIS est indispensable : zones porte l'assiette de la facturation à l'hectare. Une instance séparée rend enfin possible un index analytique qui n'a pas de sens en production.
- 04
Volumétrie
Partitionnement déclaratif mensuel sur api_logs, activity_log, llm_call_logs, usages
Les quatre tables à croissance forte deviennent purgeables par DETACH PARTITION, en O(1). C'est le mécanisme qui rend la politique de rétention applicable sans script de suppression ligne à ligne.
- 05
Transformation
dbt-core, trois couches raw / staging / marts
Les tests unique, not_null et relationships rattrapent en aval les contraintes absentes en amont. Les snapshots donnent l'historique SCD2 que pricings n'a pas.
- 06
Restitution
Metabase reconnecté aux seuls schémas marts
C'est la correction du défaut principal relevé par le recensement : le schéma transactionnel cesse d'être une interface publique.
Pour l'agent TEIA
Des vues de service stables pour le contexte
L'agent lit quotas, zones, catalogue produit et historique de consommation dans un jeu de vues rafraîchies par lot, au lieu de recomposer le contexte par appels successifs à la gateway. Latence de la minute : suffisant pour un tour de conversation, insuffisant pour un affichage temps réel.
Le coût d'une conversation devient un chiffre
Le mart de réconciliation confronte llm_call_logs, quota_usage_logs et chats.messages[]. Le coût réel d'une conversation TEIA cesse d'être une estimation, et l'écart entre consommé et facturé devient une métrique suivie.
Le corpus RAG reste hors périmètre
Les six collections pgvector continuent d'être indexées à la main, sans source versionnée. C'est la principale limite d'A1 du point de vue de l'agent : elle règle la facturation et l'observabilité, pas la gouvernance du contexte.
Règles d'exploitation
Le contrat d'ingestion est une liste blanche
La publication PostgreSQL et la configuration dlt énumèrent les objets répliqués. Une nouvelle table de production n'entre pas dans l'entrepôt par accident : elle y entre par une revue.
Rien ne se transforme à la capture
raw est une copie fidèle, horodatée, jamais modifiée. Toute correction se rejoue depuis raw. C'est ce qui rend une erreur de modélisation réparable sans re-synchroniser la production.
La conversion UUID → texte se fait une fois
Le glossaire du recensement documente le piège : Mongo stocke str(uuid), PostgreSQL stocke un UUID natif. La conversion appartient au staging, jamais à la requête de l'analyste.
Résolu
- RestitutionMetabase quitte le schéma transactionnel. Les requêtes analytiques n'entrent plus en concurrence avec la facturation.
- Facturationusages.result est laissé en production : l'entrepôt n'ingère que les colonnes de facturation. L'agrégation cesse de balayer la charge utile.
- Coût de l'agentUn mart de réconciliation confronte llm_call_logs, quota_usage_logs et chats.messages[] et publie l'écart. Le désaccord devient une métrique suivie.
- RétentionLe partitionnement mensuel rend la purge instantanée. La production peut enfin purger : l'historique vit dans l'entrepôt.
- Documentationdbt docs génère le dictionnaire de données à chaque exécution. Il ne peut plus diverger du modèle.
Non résolu
- Plafond volumétrique réel. langchain_pg_embedding, checkpoints et yjs_updates croissent sans borne ; les faire entrer dans un PostgreSQL analytique déplace le problème sans le résoudre.
- Pas de séparation stockage / calcul : une requête lourde et un rafraîchissement dbt se disputent la même machine.
- Pas de palier d'archivage bon marché. Au-delà de 12 à 18 mois d'historique, le disque devient le poste de coût.
- Le non structuré reste dehors. Les documents, images et vecteurs de la plateforme ne sont pas analysables ici.
À retenir si
- Le volume analytique utile reste sous quelques centaines de gigaoctets.
- L'équipe data compte deux à trois personnes, déjà compétentes en PostgreSQL.
- La priorité du trimestre est de rendre les chiffres de facturation fiables, pas d'ouvrir un nouveau chantier.
À écarter si
- Si l'ambition à douze mois inclut l'analyse des documents, des images et des embeddings.
- Si la croissance des tables qualifiées de TRÈS FORTE est déjà mesurée en dizaines de gigaoctets par mois.
L'option qui donne le plus de valeur par semaine investie. Elle corrige le défaut le plus coûteux du recensement — l'analytique sur le moteur de production — sans rien apprendre de nouveau à l'équipe.