Retour au projet dans le portfolio
Schéma d'architecture

Refonte modulaire Terraform — modules v2

Passage d'un socle Terraform monolithique à une plateforme Infrastructure as Code modulaire et multi-cloud : briques communes mutualisées, control plane isolé, couche de management, et une implémentation par fournisseur (AWS, GCP, Scaleway) derrière un contrat unique. La migration s'appuie sur des blocs moved pour déplacer les ressources sans les détruire.

Schéma générique : instances, dépôts, canaux et modules sont désignés par leur fonction. L'architecture est présentée à titre illustratif, indépendamment de toute organisation.

Module ou étape AWS GCP · service externe Scaleway État cible Destruction Périmètre du dépôt
01 — du monolithe v1 aux modules v2

Architecture cible du dépôt

Ce que la refonte déplace : la logique dupliquée d'un cloud à l'autre remonte dans common/, et chaque fournisseur ne garde que son implémentation. Le passage se fait par blocs moved, sans destruction de ressources.

Avant — socle v1 terraform-modules/ Modules monolithiques State partagé entre environnements Logique dupliquée d'un cloud à l'autre Interfaces implicites, peu de contrats typés Ajout d'un cloud = recopie du socle 104 blocs moved migration d'état sans destruction modules terraform v2 control/ — plan de contrôle partagé Socle du stage VM de contrôle Réseau de contrôle auth et clés JWT, coffre de secrets, load balancer, Lambda de métriques, observabilité instance et image VPC dédié Base managée, PKI, DNS et CDN sont rattachés à cette couche. management/ — pilotage Gestionnaire d'environnements Générateur de stacks Outillage de déploiement interroge l'API de contrôle : liste et statut des environnements génère les stacks Terraform, sépare legacy et split-state VM et scripts de déploiement, release, reprise de jobs common/ — briques partagées entre clouds réseau d'environnement configuration de cluster appels à l'API de contrôle transitions de statut génération d'environnement cluster de métriques workflows de déploiement collecte de logs tags helpers de chaînes repli de type d'instance images cloud-init Une seule implémentation par responsabilité, consommée par les trois fournisseurs. images cloud-init base de données observabilité orchestrateur métriques base vectorielle Recouvrement connu avec la couche commune : les deux variantes ont déjà divergé. providers/ — un contrat, trois clouds aws base de données environnement socle de cluster suppression kubernetes observabilité store objet réseau base vectorielle métriques collecte de logs machines virtuelles en ambre : modules propres à AWS gcp base de données environnement socle de cluster suppression kubernetes observabilité store objet réseau base vectorielle scaleway base de données environnement socle de cluster suppression kubernetes observabilité store objet réseau base vectorielle
Les trois fournisseurs exposent le même jeu de modules ; ce qui diffère tient dans les trois lignes ambre de la carte AWS. Volumétrie du socle relevée en juillet 2026.
325fichiers .tf
24 729lignes Terraform
64répertoires de modules
453ressources
154data sources
1 021variables
228outputs
104blocs moved
52README de modules
02 — de l'API de contrôle à la destruction

Cycle de vie d'un environnement

L'API de contrôle est la source de vérité : elle décrit les environnements à créer, et chaque transition de statut lui est renvoyée. Le socle cloud est toujours posé avant la couche applicative, et la destruction emprunte un chemin dédié.

transitions de statut API de contrôle source de vérité des environnements auth Gestionnaire d'environnements récupère liste et statuts Générateur de stacks produit les stacks Terraform Environnements legacy state partagé — mode transitoire Environnements split-state un state par environnement — cible socle cloud de l'environnement Réseau / VPC Cluster Kubernetes (EKS / GKE / Kapsule) Stores objet (S3 / GCS / Object Storage) Observabilité Base vectorielle (optionnel) Créé avant toute couche applicative. couche applicative Orchestrateur PostgreSQL Workflows de déploiement Prometheus / Grafana Collecte des logs Déployée sur le socle cloud produit à l'étape précédente. Retour de statut vers l'API de contrôle Suppression purge puis cluster découpage en couches terraform Trois couches indépendantes, appliquées dans cet ordre. Outillage du stage outillage et control plane du stage Liste des environnements apply qui expose la liste des envs Stack générée par environnement une par environnement actif
Le chemin vert est le seul retour d'information vers l'API de contrôle ; le chemin rouge est le seul qui détruit.
03 — même contrat, trois implémentations

Matrice de parité multi-cloud

Ce que chaque fournisseur substitue derrière le contrat commun — et les trois briques qui restent transverses quel que soit le cloud.

FonctionAWSGCPScaleway
KubernetesEKSGKEKapsule
ComputeEC2Compute EngineInstances
Base de donnéesRDSCloud SQLRDB
Stockage objetS3GCSObject Storage
RéseauVPCVPC / NATPrivate Network
DNS transverseRoute53 pour les trois fournisseurs
Secrets applicatifsBitwarden pour les trois fournisseurs
ObservabilitéOpenObserve et Prometheus pour les trois fournisseurs
Les trois colonnes exposent le même contrat : c'est ce qui permet d'ajouter un fournisseur sans toucher aux couches supérieures.

Tous les schémas d'architecture