Topologie multi-cloud

1) Quand le multicloud est justifié

• Fiabilité/disponibilité : zones de défaillance indépendantes au niveau des fournisseurs.
• Souveraineté/conformité : stockage/traitement par pays (résidence de données).
• Gestion des risques : réduction de la disponibilité, leviers achats/prix.
• Géographie/performance : plus proche de l'utilisateur et des sources de données.
• Services spéciaux : accès aux meilleures capacités de niche de différents nuages.

• Complexité considérable du SDLC/observation/opérations.
• Augmentation du coût egress et de la latence entre les fournisseurs.
• Différents modèles/quotas/limites IAM/réseau → plus de risques opérationnels.

2) Modèles topologiques

3) Couche réseau et routage

3. 1 Entrée mondiale

GSLB/DNS : latincy-/health-based ; TTL courts dans les fenêtres de migration.
Anycast + L7-proxy : IP unique, routage sur la santé des régions.
Politiques par pays : Géo-blocage/géo-accrochage du trafic.

python def pick_cluster(client, intent):
вход: ip, geo, tenant, feature allowed = filter_by_compliance(client. geo) # sovereignty healthy = [c for c in allowed if sdo (c). ok and slo(c). ok]
return argmin(healthy, key=lambda c: latency_estimate(client, c))

3. 2 Connectivité intercalaire

Canaux privés/peering si possible ; sinon, TLS + mTLS via Internet.
Contrôle egress : agrégation/compression, caches/agrégateurs locaux.
Réseaux en tant que code : Terraform/Blueprints, politiques du CIDR, itinéraires et passerelles egress.

4) Données et consistance

4. 1 Modèles

La consistance globale forte est rarement réaliste (latence/maillage/coût).
Pragmatic eventual : CDC bidirectionnel (changement de capture de données) avec résolution de conflit.
CRDT/idempotence : pour les compteurs/réseaux/logs - structures commutatives.

4. 2 Modèles

Dual-write c outbox : enregistrement transactionnel de l'événement → courtier → réplication dans le cloud voisin.
Read-local/Write-home : les entrées sont dans la région « home »/cloud, les lectures sont locales (avec des versions et stale-policy).
Split-brain défense : détail de divergence, « compensation » (saga), arbitrage manuel pour les invariants monétaires.

DB → Debezium/stream → Events(topic@vN) → Cross-cloud relay → Apply w/ resolver resolver: prefer_higher_version          prefer_home          business_rule()

4. 3 Stockage d'objets

Réplication asynchrone des réservoirs, hachages/manifestes, déduplication.
Les politiques ILM (hot/warm/cold) sont indépendantes dans les nuages.
Règles de souveraineté : « PII ne quitte pas l'UA/EEE » - sont validés comme code.

5) Identité, secrets et clés

Fédération identitaire : IdP unique, tokens à courte durée de vie, OIDC-trust sur les piplines.
Secrets : KMS/HSM de chaque nuage + abstraction de classe Vault ; double-clé pour les rotations/commutations.
PoLP/ABAC : droits basés sur les attributs (cloud, region, bou, data_class).
Domaines crypto : différentes clés racines pour les juridictions → crypto-érasure par région.

6) Environnement exécutif : clusters et interférences

Multiplaster (K8s) : un cluster par nuage/région ; fleet-control via GitOps (ArgoCD/Fleet).
Сервис-меш: mTLS, retries, circuit-breakers, failover policies cross-cluster.

• Les services statiques → par endroit de données.
• API interactives → dans chaque nuage (Active/Active).
• Batch/ETL → fenêtres « vertes »/région bon marché (carbon/cost aware).

rego package placement

allow[cloud] {
input. service. pii == false cloud:= input. clouds[_]
cloud. features. contains("cheap_gpu")
}

deny["PII outside allowed region"] {
input. service. pii == true not input. target_region in {"eu-central","eu-north","eu-west"}
}

7) Observability et SLO dans le multi-cloud

Étiquettes multi-classes : 'cloud', 'region', 'tenant', 'data _ domain'.
SLI/SLO par nuage et globalement : « disponible globalement si un nuage ≥1 est disponible ».
Collecte de télémétrie : agrégation locale + avec contrôle egress.
Tracing : global trace-id, promotion du contexte, sample tail-based par « queues ».
Dashboards de comparaison : A vs B per endpoint/p99/error-budget burn.

8) SDLC/IaC et « politiques en tant que code »

Répertoire mono IaC unique : fournisseurs-modules/staks, invariants (balises, réseaux, cryptage).
GitOps : manifestes déclaratifs, drift-detect, promo des environnements.
Tests de conformité : contrats API/événements, Canaries pour les deux clouds.
Release-gate : bloc au risque de perturber le SLO dans un seul nuage (prévisions de taux de burn), en l'absence de conformité avec la souveraineté.

yaml gate: multi-cloud-slo-and-compliance checks:
- slo_burn_rate(global) < 1. 0
- slo_burn_rate(cloud:A) < 2. 0
- compliance_rule("pii_in_region") == pass
- egress_forecast < budget on_fail: block_release

9) Coût et carbone (FinOps/GreenOps)

Métriques unitaires : '$/req', '$/GB-egress', 'gCO₂e/req'.
Rowting au coût/carbone pour une bataille non critique : horloge bon marché/« verte »/régions.
Egress-cap : budget pour le trafic intercalaire ; cache/agrégation/compression/TTL.
RI/SP/Committed Use dans chaque nuage + « couche élastique » sur spot/préemptable.

10) Tests et exercices de feel

Game-days : "rembourser le nuage Et", "tarder le BD", "percer les limites egress".
Checkpoint : RTO/RPO, temps de convergence DNS, brisez le drapeau fich, le comportement des caches.
Chaos-smouck dans les communiqués : la dégradation des dépendances ne doit pas conduire à une cascade de rétrogrades.

11) Sécurité, vie privée, conformité

Zero-Trust : mTLS entre les services/cloud, signature d'artefacts, SBOM.
DPA/souveraineté : répertoires d'ensembles de données, règles de localisation, Legal Hold au-dessus de l'ILM.
Secrets et clés : journal des rotations, playbooks compromise/kill-switch.
Webhooks et intégrations externes : signature, anti-replay, endpoints régionaux.

12) Modèles d'intégration de données/événements

12. 1 Pont Kafka bidirectionnel (idée) :

cloudA. topicX ⇄ relayA→B ⇄ cloudB. topicX cleanup. policy=compact,delete  key-based routing  idempotent producer

12. 2 Table de sortie et relais :

sql
-- outbox id uuid pk, aggregate_id, type, payload jsonb, version int, created_at timestamptz
-- transactional insertion with domain table change

Ensuite, le connecteur lit l'outbox et publie l'événement dans le courtier local + relais.

12. 3 Stratégie de conflit (pseudo) :

python def resolve(local, remote):
if local. version > remote. version: return local if remote. version > local. version: return remote equal versions: domain rules return business_tiebreak (local, remote)

13) Anti-modèles

« Faisons glisser les choses comme elles sont dans les deux nuages ». Doubler la difficulté sans gagner.
Transactions synchrones intercalaires sur chemin chaud.
Une clé de cryptage globale unique pour tous les clouds/régions.
Logs/remorques avec PII sans camouflage et sans règles de localisation.
L'absence de mesures externes (la disponibilité réelle n'est visible que par la page de statut du fournisseur).
Pas de playbooks/exercices - DR ne fonctionne pas au moment X.
Cascade de rétrogrades dans la dégradation d'un nuage (pas de limiteurs/shaders/breakers).
L'egress non comptabilisé est une facture inattendue.

14) Chèque de l'architecte

1. Les pilotes multi-cloud (SLO/DR/souveraineté/coût) ont-ils été formulés ?
2. Le modèle (AA/AP/DR-Only/Poly-Service) est-il sélectionné et enregistré par RTO/RPO ?
3. Plan réseau : GSLB/Anycast, échantillons de santé, egress-cap, canaux privés ?
4. Données : CDC/CRDT/dual-write, règles de résolution des conflits, outbox ?
5. Souveraineté : carte de données/régions, politiques comme code et leurs gates ?
6. IAM/secrets : fédération, tokens à courte durée de vie, KMS par domaine ?
7. Clusters/mesh : stratégie d'échec, limites/breaks/timouts ?
8. Observability : étiquettes « cloud/region », SLO per-cloud et globalement, synthétiques externes ?
9. SDLC/IaC/GitOps : catalogue unique, tests de conformité, gates de sortie ?
10. FinOps/GreenOps : métriques unitaires, budget egress, fenêtres de batch « vertes » ?
11. Exercices : jours-jeux réguliers, protocoles et retestes ?
12. Plan d'exportation : exportation de données/formats/délais, second-source pour les services clés ?

15) Mini-exemples de configurations

15. 1 Politique de routage par juridiction (pseudo-YAML) :

yaml route:
pii:
allowed_regions: ["eu-central","eu-north","eu-west"]
deny_cross_cloud: false analytics:
allowed_regions: ["eu-","us-"]
prefer_low_carbon: true weights:
eu-central@cloudA: 60 eu-central@cloudB: 40

15. 2 Échantillon de santé pour la GSLB :

http
GET /healthz
200 OK x-region: eu-central x-slo: ok    at-risk    breach

15. 3 Drapeau failover-ficha (pseudo-code) :

python if slo_at_risk("cloudA", "payments"):
route. weight["cloudA"] -= 20 route. weight["cloudB"] += 20 enable_stale_rates(ttl=1560)

Conclusion

Le multi-cloud est une discipline d'ingénierie, pas une étiquette. Il exige des motivations claires, un choix éclairé de la topologie, un travail réfléchi sur les données, une forte automatisation et des politiques strictes. Si vous mesurez les risques et les coûts, construisez des réseaux et des données « par tutoriel », formez des faussaires et gardez le cap sur la simplicité, une plate-forme multi-cloud vous donnera la résilience, la flexibilité et la liberté - sans surprises dans les comptes et sans compromis sur l'expérience utilisateur.