🎯 OLTP, OLAP ou Lakehouse : comment choisir son architecture data selon ses usages ?

Quand on parle d’architecture data, on peut vite se perdre tant les terminologies sont nombreuses: Medallion, OLAP, OLTP, deltalake, etc.. Pourtant, un modèle transactionnel, un entrepôt analytique et un lakehouse hybride répondent à des usages radicalement différents.

Voici un tour d’horizon 👇

---

🔹 OLTP (OnLine Transaction Processing)

👉 Usage : applications web & mobiles, CRM, ERP, systèmes bancaires ou assurantiels.
👉 Caractéristiques : modèle relationnel normalisé (3FN), cohérence ACID, temps de réponse <100 ms.

Exemple type :

• PostgreSQL ou Oracle pour, par exemple, un système de gestion des clients et commandes
• Tables normalisées, index optimisés, réplication pour tolérance de panne.
• modélisation type:

✅ Idéal quand les mises à jour fréquentes et la cohérence immédiate sont critiques.

---

🔹 OLAP (OnLine Analytical Processing)

👉 Usage : analyse historique, reporting réglementaire, BI, dashboards de pilotage.
👉 Caractéristiques : modèle étoile/flocon, tables dénormalisées, requêtes complexes, agrégations massives.

Exemple type :

• Snowflake, BigQuery, Teradata.
• Alimentation via ETL/ELT (Airbyte/Fivetran + dbt par exemple).
• Tables partitionnées et clusterisées pour optimiser le coût/performance.
• modélisation type:

✅ Idéal quand le volume dépasse le To et que la gouvernance (KPI certifiés, SCD, RLS) est un impératif.

---

🔹 Lakehouse/HTAP (Hybrid Transactional & Analytical Processing)

👉 Usage : cas hybrides, besoin transactionnel et analytique en temps quasi-réel.
👉 Caractéristiques : approche d’organisation des données de type Medallion (Bronze–Silver–Gold), ingestion batch + streaming, ACID.

Exemple type :

• Delta Lake (databricks), Cloudera
• Bronze (brut), Silver (nettoyé), Gold (prêt pour BI ou ML/IA).
• Feature Store possible pour alimenter du machine learning.

✅ Idéal quand on veut des KPIs temps-réel (fraude, churn, opérations 24/7) sans répliquer la donnée partout.

---

🎯 Critères de choix

Choisir OLTP quand :

• Applications transactionnelles critiques
• Cohérence immédiate (ACID)
• Mises à jour fréquentes
• SLA < 100 ms

Choisir OLAP quand :

• Analyse historique et agrégations lourdes
• Reporting et dashboards
• Volumétrie > 1 To
• Gouvernance et auditabilité

Choisir HTAP/Lakehouse quand :

• Usages mixtes transactionnel + analytique
• Besoin avancé de near real-time analytics
• Standardisation de l’architecture

---

💡Il n’y a pas une architecture idéale, mais un panier de choix à adapter. Dans mes expériences passées, j’ai souvent vu des bases OLTP poussés au-delà de leur mission (usages final de type analytique), ou des bases OLAP rendus inutilisables faute de gouvernance (le client voulait à tout prix passer dans le cloud).

Aujourd’hui, la nuance devient plus floue avec l’évolution des solutions (postgreSQL doté de certaines extensions peut gérer des pattern analytiques) et la maturité croissante des solutions cloud-native… à condition de maîtriser coûts et complexité.

#DataArchitecture #OLTP #OLAP #Lakehouse #BigQuery #Postgres #AnalyticsEngineer #BusinessDataAnalyst