Architecture de valeur

1) Principes et rôles

Cost as a Feature. Prix - partie UX/produit et solutions architecturales.
Responsabilité partagée. Ingénieurs, plateforme/DevEx, finance, produit - une seule boucle de rétroaction.
Une seule source de vérité. Catalogue des étiquettes/étiquettes, dictionnaire des coûts et sources de données.
Boucle « Observez → Optimisez → Gérez ». Dashboards intégrés, gates automatiques et politiques.

Rôles : Architecte de valeur, analyste FinOps, Propriétaire du produit, Équipe de plateforme.

2) Modèle de données de valeur

• Pour l'API : '$/1000 requêtes', '$/milliseconde CPU', '$/Go egress'.
• Pour les données : '$/GB-mois de stockage', '$/demande de base de données', '$/millions de messages'.
• Par utilisateur : 'CAC', 'ARPU/ARPPU', 'Gross Margin', 'LTV : CAC'.
• Par flux : '$/transaction', '$/deploy', '$/test'.

cost_record {
ts, provider, account, region, service, usage_qty, usage_unit,
list_price, net_price, discounts,
tags: { env, team, product, feature, tenant, cost_center, pii, tier },
resource_id, allocation_keys: {req_id?, tenant_id?, dataset?}
}

Tags dorés (obligatoires) : « bou », « team », « product », « feature », « cost _ center », « owner », « pii », « tier (hot/warm/cold) », « region ».

3) Attribution : showback/chargeback

Showback : rapports transparents par équipe/fiches sans facturation des transferts internes.
Chargeback : répartition selon les règles : coûts directs → le propriétaire ; ressources partagées - par clés : RPS, CPU-secondes, horloge GB, volume d'événements.

cluster_cost = sum(provider_cost where resource in "k8s-node:")
weights = { service: cpu_seconds(service)/total_cpu_seconds }
for service in services:
charge[service] = direct_cost(service) + cluster_cost weights[service]

4) Politiques et jeux de valeur (Policy as Code)

Règles budgétaires : limites par « bou/team/feature » ; auto-alert/bloc de dégagement en cas de dépassement prévu.
Exigences d'étiquette : ressources sans étiquettes obligatoires - deny dans le contrôleur d'admission.
Limites du profil : interdiction des grandes machines en 'dev', TTL sur les ressources ephemeral, réserves minimales.

yaml policy: require-tags-and-limits deny_if_missing_tags: [team, product, env, cost_center, owner]
constraints:
env==dev:
max_instance_type: "c6i. large"
ttl_hours: 72

5) Calculs : modèles de réduction des coûts

Taille correcte (rightsizing) : Auto-sélection vCPU/RAM basée sur p95/p99, saisonnalité et headroom.
Auto-mise à l'échelle : target-based (CPU/RPS/lag), step-fonctions ; protection contre le thrash par hystérésis.
Choix du modèle de prix : on-demand vs spot/preemptible, Reserved Instances/Savings Plans ; mélange pour critique et fond.
Convoyeurs Batch : fenêtres de charge « bon marché », compression batch, files d'attente prioritaires.
Cashing et coalessing de demandes : réduction des lectures de sources coûteuses.
Edge/optimisation du réseau : HTTP/2/3, keep-alive, compression, CDN.

if rps > target1. 2 for 3m: replicas += ceil(rps/target); cool_down 5m if rps < target0. 6 for 10m: replicas = max(min_replicas, replicas-1)

6) Stockage et données : chaud/chaud/froid

Tyring : données chaudes (accès instantané), chaudes (demandes rares), froides/archives.
Formats : colonnes (Parquet/ORC) pour l'analyse, la compression et le lot par date/clé.
TTL/ILM : politique de vie de recrutement : 'hot 7d → warm 90d → cold 365d → delete'.
Couche cache : Redis/Memcached avec request coalescing, protection contre les tempêtes miss.
Quotas et budgets de demande : limites prévisibles pour les joyaux/scans coûteux.

yaml dataset: events_main lifecycle:
- phase: hot; duration: 7d; storage: nvme
- phase: warm; duration: 90d; storage: ssd; compress: zstd
- phase: cold; duration: 365d; storage: object; glacier: true
- phase: purge; duration: 0d

7) Réseau et egress

Minimisez le trafic interrégional : copies locales et agrégation sur le bord.
CDN et caches : origin-shield, TTL raisonnable, validation/invalidité.
Protocoles : binaires (gRPC) pour la commodité, compression uniquement là où elle est avantageuse.
Dedup des événements et filtrage sur le producteur : « on ne transporte pas les ordures ».

8) Observabilité et coût SRE

Cartes de coût de télémétrie : '$/log-Go', '$/série métrique', '$/piste'.
Sample et agrégation : tail-based sampling, downsampling métriques, rétention par importance (SLO-métriques - priorité supérieure).
Dedup des loges et de l'assainissement : interdiction des PD, réduction des champs fantômes, limites sur la taille de l'événement.

9) CI/CD et environnements de test

Ephemeral-stand avec auto-TTL, environnement « par PR ».
Perf-smoke en PR : courtes courses pour une estimation précoce du « coût de la demande ».
Cache/artefacts : réutilisation des conteneurs, compilations.
Gates : Bill/deploy est rejeté si le « prix de latence »/RPS s'est détérioré par rapport à la base> X %.

10) Prévisions, budgets et anomalies

Forecasts : saisonnalité/tendance, événements (campagnes, sorties), corrélation « fiches → coût ».
Budgets par niveau : team/product/feature/tenant ; escalade à 80/90/100 %.
Anomalies : pics soudains par service/région/compte ; « bisect » automatique et le retrait du drapeau.

if forecast(month_end_cost) > budget0. 9 and variance ↑:
alert(team_owner)
suggest: rightsizing + RI/SP coverage + ILM tighten

11) Achats et commerce

RI/Savings Plans/Committed Use : couvrir une base stable ; surveiller la couverture et les intérêts « unifiés ».
Spot/Preemptible : tâches de fond et tolerant-workflow ; checkpointing et redémarrage rapide.
Licences et SaaS : matrice ROI, benchmarking des alternatives, périodique « vendor fitness review ».

12) Polyvalence et facturation

Partitioning by tenant : séparation logique/physique, limites et quotas.
Tenant-aware limiteurs/rankeps : empêcher le « voisin bruyant ».
Modèles d'utilisation : facturation par événement, RPS, volume de données ; métriques transparentes pour les clients.

13) La sécurité et la conformité comme facteur de coût

Crypto et stockage : FPE/clés - dépenses pour KMS/HSM ; optimiser la fréquence des opérations.
Copies réglementaires : séparez les copies « légales » des copies opérationnelles ; les archives sont moins chères que le stockage « tiède éternel ».
Minimisation des données : moins de données - moins de comptes et de risques.

14) Ingénierie anti-modèles (cher !)

API de chat sans trampoline ni cache.
Files illimitées et parallèles illimités - augmentation de la latence et des comptes.
TTL zéro et clés chaudes sans coalessing.
Dashboards « omniscients » avec des millions de mesures de la série.
Ressources sans étiquettes → dépenses « grises » sans propriétaire.
L'absence d'ILM/TTL → la croissance éternelle du stockage.

15) Outils et artefacts (vendor-neutral)

Catalogue des étiquettes (schema + linter dans CI).
Extracteur Cost (agrégation utilisation/billing, normalisation en format unique).
Dashboards unit economics (coût API, coût dataset, coût tenant).
Auto-édition (rightsizer, RI/SP, ILM-enforcer).
Politiques de valeur (admission/OPA/Kyverno) et « lignes rouges » du budget.

16) Mini recettes

Formule « prix de la demande » (HTTP)

request_cost = (cpu_ms $/cpu_ms) +
(mem_mb_s $/mb_s) +
(egress_mb $/mb) +
(db_calls $/call) +
(cache_ops $/op miss_penalty)

Audit rapide du service

Top 3 des endpoints de voyage à $/1000 req.
Hit/miss cache et clés « tempête ».
Listes de ressources sans étiquettes.
ILM et la rétention des datacets.
Couverture RI/SP (%).

Politique de retri économique

retry = min(3, floor(budget_ms / (base_timeout_ms 1. 5^attempt)))
jitter = uniform(0. 5..1. 5)

17) Chèque d'architecte de valeur

1. Les métriques unitaires ('$/req', '$/GB-month', '$/txn') et les propriétaires ont-ils été définis ?
2. Politique enforcée ? Les ressources sans étiquettes sont-elles bloquées ?
3. Showback/chargeback et rapports produits/fiches mis en œuvre ?
4. Auto Skale et rightsizing configurés, headroom défini ?
5. Données teintées (hot/warm/cold), ILM/TTL s'appliquent ?
6. Egress et flux interrégionaux minimisés ? CDN/caches inclus ?
7. Observability optimisée (sampling, retraite, downsampling) ?
8. Les gates CI/CD sur la régression des coûts et les policy-checks sont-ils actifs ?
9. Prévisions/budgets/analyse des anomalies automatisées ?
10. Le mélange RI/SP/Spot couvre-t-il les charges de base ?
11. Pour les multi-tenants, y a-t-il des quotas, des limites et des métriques d'utilisation transparentes ?
12. Documenté par FinOps runbook et un plan de cost-review mensuel ?

Conclusion

L'architecture de la valeur n'est pas une « économie à tout prix », mais une gestion de la valeur : combien coûte chaque milliseconde et quels revenus elle génère. En intégrant le coût dans l'architecture, les processus et les outils (étiquettes, politiques, gates, dashboards, ILM, auto-skale), vous obtenez une plate-forme où les décisions sont prises en fonction des métriques et de l'économie plutôt que de l'intuition. Cela accélère le produit, réduit les risques et rend l'entreprise prévisible rentable.