SystimaNX intervient sur AWS, Azure et GCP avec les mêmes habitudes d’ingénierie : état désiré déclaratif, changements audités et réconciliation observable. L’histoire n’est pas « une abstraction qui cache tout »—c’est une discipline portable avec des ancrages natifs quand ils réduisent le risque.
Couche portable. Structure de dépôt, règles de promotion, garde-fous policy-as-code et contrats d’identité de service voyagent bien. Une PR doit suffire à comprendre la surface d’impact sans ouvrir trois consoles.
Couche spécifique fournisseur. Load balancers, bases managées, identité et résilience régionale diffèrent. Nous les encapsulons dans des adaptateurs fins ou modules nommés pour que le chart applicatif reste ennuyeux.
Mécanique GitOps. Flux, Argo CD ou équivalents managés : les métriques de succès restent dérive visible, temps de rollback, corrélation merges ↔ état cluster. Les contrôleurs sont des charges de première classe à observer.
Réalité multi-cloud. Beaucoup d’organisations le sont par accident—acquisitions, résidence des données, meilleures API IA—plus que par stratégie. Nous dessinons pour ce chaos : confiance explicite, rôles d’automation moindre privilège et tagging qui rend la facturation honnête.
La preuve bat la feuille de route. Nous aimons poser un vertical étroit—un type de service, une échelle d’environnements—puis étendre quand déploiements et incidents bougent dans le bon sens.
À lire aussi : conseil DevOps, réseau & cloud et ressources.
Un exemple concret : promouvoir un service sur trois clusters
Imaginez un service proche des paiements qui doit tourner sur un cluster AWS EKS pour la région principale, un cluster Azure AKS pour une contrainte de résidence des données en UE, et un cluster GCP GKE parce qu’une acquisition récente s’y était déjà standardisée. Le chart Helm est un artefact unique, versionné une seule fois. Ce qui change par cluster tient dans une petite surcouche : classe d’ingress, nom de storage class, et quelques annotations pour brancher le contrôleur de load balancer du fournisseur. Tout le reste—sondes de vivacité, requêtes de ressources, PodDisruptionBudgets, NetworkPolicy—reste identique, car le comportement sous charge ne devrait pas dépendre du cloud hébergeur.
Le pipeline de promotion se lit de la même façon dans les trois environnements : un merge sur la branche de release met à jour un tag d’image dans un fichier de values, le contrôleur GitOps de chaque cluster capte le changement indépendamment, et la réconciliation converge selon son propre SLA. Nous évitons volontairement un orchestrateur central qui pousserait vers les trois clusters en lockstep—cela transforme un montage multi-cloud en point de défaillance unique portant trois noms. Si le contrôleur du cluster AWS est dégradé, les déploiements Azure et GCP ne doivent pas en pâtir.
Là où ça casse en pratique, c’est sur les secrets. Chaque fournisseur a son coffre préféré—Secrets Manager, Key Vault, Secret Manager—et la tentation est d’écrire trois intégrations différentes. Nous standardisons plutôt sur un seul déploiement d’External Secrets Operator par cluster, configuré avec un backend spécifique au fournisseur mais un contrat de CRD identique dans les manifestes applicatifs. Le chart applicatif ignore quel coffre se cache derrière l’objet ExternalSecret qu’il référence.
Où le GitOps multi-cloud dérape le plus souvent
L’échec le plus fréquent : des politiques qui partaient identiques sur tous les clusters et ont dérivé en silence sur dix-huit mois, chaque cluster ayant été patché sous pression par un astreint différent. Les politiques OPA Gatekeeper ou Kyverno méritent le même traitement GitOps que le code applicatif : versionnées, revues et comparées entre clusters sur un calendrier régulier, pas seulement appliquées une fois au bootstrap puis oubliées.
Le deuxième échec consiste à traiter le tagging de coûts comme un détail. Quand trois clouds appliquent chacun leurs tags par défaut plus ce qu’une équipe a pensé à ajouter à la main, la finance finit par réconcilier les dépenses au tableur chaque mois. Nous imposons les schémas de tags via une politique d’admission—si un manifeste de charge n’a pas les labels centre-de-coût et environnement requis, il est rejeté au niveau du cluster, pas signalé plus tard dans un tableau.
Le troisième est de croire que les contrôleurs GitOps eux-mêmes n’ont pas besoin de maintenance. Flux et Argo CD nécessitent tous deux des mises à jour, et une montée de version du contrôleur sur un cluster change parfois le comportement de réconciliation d’une façon qui ne se voit que sur certaines versions de CRD. Nous échelonnons les montées de version des contrôleurs entre clusters de la même manière que les déploiements applicatifs, en commençant par l’environnement le moins critique.
Que standardiser, que laisser natif
Les équipes qui découvrent le multi-cloud demandent souvent une checklist : qu’est-ce qui doit rester identique partout, et qu’est-ce qui peut diverger sans souci ? Notre règle empirique : tout ce qu’un développeur touche chaque semaine—structure du chart, nommage des variables d’environnement, chemins de health check, format des logs—doit être identique, car l’incohérence y taxe chaque ingénieur, chaque jour. Tout ce qu’un spécialiste infra touche chaque trimestre—la variante exacte de base managée, l’algorithme d’autoscaling précis, le protocole de health check du load balancer—peut différer, car les personnes qui s’en occupent portent déjà le contexte spécifique au fournisseur.
Nous pesons aussi le coût d’une abstraction contre le coût de la divergence. Un module Terraform fin qui encapsule trois offres Postgres managées derrière une interface unique vaut le coup si vous provisionnez des bases souvent et que les différences sont surtout cosmétiques. Il ne vaut pas le coup si vous provisionnez une nouvelle base deux fois par an et que les trois fournisseurs ont des sémantiques de sauvegarde, de failover et de réplicas en lecture significativement différentes que les développeurs doivent comprendre directement. Forcer une abstraction sur des primitives réellement différentes ne fait que déplacer la complexité dans les cas limites de l’abstraction, là où elle est plus dure à déboguer.
En pratique, cela signifie que nos dépôts GitOps multi-cloud ont une structure de premier niveau cohérente—apps, clusters, policies—mais le contenu du dossier clusters diffère bel et bien entre AWS, Azure et GCP une fois qu’on l’ouvre. Cette asymétrie est voulue. La portabilité est une propriété des interfaces et des workflows, pas une exigence que chaque fichier se ressemble.
Une dernière chose mérite d’être dite sans détour : le bénéfice de cette discipline ne se voit pas le premier jour. Le premier cluster monté de cette façon prend souvent plus de temps qu’une installation rapide et spécifique au cloud. Le bénéfice apparaît au troisième cluster, quand un nouvel ingénieur reconnaît la même structure de dépôt qu’il connaît déjà et devient productif en une journée plutôt qu’en une semaine, et quand une demande d’audit du type « montrez-moi tous les services ayant accès à la base en UE » devient un grep sur une structure de dépôt cohérente plutôt qu’une semaine de captures d’écran glanées sur trois consoles différentes.