L'ingénierie cloud pour le secteur public : ce que nous avons appris en exploitant AWS, Azure et GCP en parallèle

Le « multi-cloud » est souvent présenté comme une stratégie. Ce n’en est généralement pas une — c’est une conséquence. Un ministère dispose déjà d’un tenant Azure issu de son parc M365, un partenaire de mise en œuvre a construit le dernier service sur AWS, et une équipe data science veut BigQuery. Personne n’a planifié cela. Quelqu’un doit néanmoins le faire fonctionner.

Après une décennie à concevoir des plateformes sur AWS, Azure et Google Cloud pour des clients du secteur public, voici ce qui compte réellement une fois dépassé le débat « quel cloud est le meilleur », lorsqu’il s’agit de maintenir des charges de travail en production sécurisées, conformes et maîtrisées en coût.

1. La souveraineté et la classification précèdent l’architecture

Sur des projets commerciaux, le choix de la région est une décision de performance. Sur des projets gouvernementaux, c’est d’abord une décision juridique.

Avant qu’un seul module Terraform ne soit écrit, nous établissons :

• Quelle classification porte cette donnée — OFFICIAL, OFFICIAL-SENSITIVE, ou plus élevée ?
• Quelle(s) région(s) satisfont l’exigence de résidence, et le modèle de responsabilité partagée du fournisseur la respecte-t-il réellement, ou se contente-t-il de l’affirmer ?
• Qui détient les clés de chiffrement — le fournisseur, ou l’engagement exige-t-il des clés gérées par le client (CMK/BYOK) ?

# La propriété des clés de chiffrement est une décision, pas un défaut
resource "aws_kms_key" "official_sensitive" {
  description             = "CMK pour les charges de travail OFFICIAL-SENSITIVE"
  deletion_window_in_days = 30
  policy                  = data.aws_iam_policy_document.key_admins.json
  # La clé ne quitte jamais le contrôle du client — aucun repli géré par le fournisseur
}

Se tromper ici, et aucune qualité d’ingénierie ne le corrige ensuite. Nous avons vu des migrations suspendues pendant des mois parce que la résidence des données avait été supposée plutôt que vérifiée.

2. Choisir le bon cloud par charge de travail, pas un seul cloud pour tout

Les équipes qui peinent avec le multi-cloud sont celles qui tentent de rendre chaque charge de travail portable partout. Celles qui réussissent choisissent un fournisseur principal par charge de travail selon ce pour quoi il est réellement performant, et standardisent les points de jonction entre eux.

L’erreur n’est pas d’utiliser trois clouds. C’est de les utiliser sans avoir décidé pourquoi pour chacun.

3. Kubernetes est ce qui rend le multi-cloud supportable

Les API de calcul, d’IAM et de réseau diffèrent entre AWS, Azure et GCP d’une manière qui ne s’abstrait jamais complètement. Kubernetes est ce qui se rapproche le plus d’un substrat commun, et c’est l’investissement qui porte ses fruits quels que soient les fournisseurs sur lesquels vous finissez par exploiter vos charges.

# Le même manifeste, trois control planes managés
# EKS, AKS et GKE l'acceptent tous sans modification
apiVersion: apps/v1
kind: Deployment
metadata:
  name: claims-api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: claims-api
          image: registry.internal/claims-api:1.4.2
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits:   { cpu: "500m", memory: "512Mi" }

Nous continuons à utiliser des services natifs des fournisseurs en dessous — RDS, Cosmos DB, Cloud SQL — car réimplémenter des bases de données managées sur Kubernetes vaut rarement le coup. Mais la couche applicative reste portable, et cette portabilité est ce qui permet à un ministère de déplacer une charge de travail lorsqu’un contrat-cadre change.

4. Le FinOps est une habitude hebdomadaire, pas une revue annuelle

Les dépassements de coûts cloud dans le secteur public viennent rarement d’une seule mauvaise décision. Ils viennent du fait que personne ne regarde avant que la facture n’atterrisse sur le bureau d’un directeur.

# À quoi ressemble réellement une facture multi-cloud non maîtrisée après 12 mois
AWS :   prévision 18 k£/mois → réel 31 k£/mois  (volumes EBS orphelins, RDS surdimensionné)
Azure : prévision 9 k£/mois  → réel 14 k£/mois  (ressources dev/test jamais démantelées)
GCP :   prévision 4 k£/mois  → réel 4,2 k£/mois (étiqueté et alerté sur budget dès le premier jour)

La ligne GCP est l’exception, et pour une raison précise — des alertes budgétaires et un étiquetage obligatoire ont été appliqués par politique dès le lancement. Les deux autres non, jusqu’à ce que nous les ajoutions.

# Application des étiquettes au niveau de la politique, pas sur la bonne foi
resource "aws_organizations_policy" "require_cost_tags" {
  content = jsonencode({
    tags = {
      "cost-centre" = { tag_key = { "@@assign" = "cost-centre" }, enforced_for = { "@@assign" = ["ec2:instance", "rds:db"] } }
    }
  })
}

L’application des étiquettes, les alertes budgétaires et une revue de coûts hebdomadaire font la différence entre une prévision et un fantasme.

5. L’infrastructure as code est la seule source de vérité — ou elle n’est rien

Le multi-cloud sans IaC signifie trois consoles, trois savoirs tribaux, et un historique des changements qui ne vit dans la tête de personne une fois qu’ils sont partis. Terraform (ou OpenTofu) avec des modules par fournisseur derrière une interface commune est ce qui rend les audits supportables.

module "network" {
  source   = "./modules/network/${var.cloud_provider}"
  cidr     = var.network_cidr
  env      = var.environment
}

Chaque changement passe par la même revue de pull request, la même validation avant application, la même piste d’audit — quel que soit le cloud ciblé. Cette cohérence compte davantage pour un auditeur ISO 27001 ou Cyber Essentials Plus que le fournisseur choisi.

Points clés à retenir

• Classifiez avant de concevoir l’architecture — la souveraineté et la propriété des clés sont des décisions juridiques, pas des décisions d’infrastructure
• Choisissez délibérément par charge de travail — le multi-cloud par accident est un risque ; le multi-cloud par conception est un atout
• Kubernetes est la couche de portabilité — investissez là, plutôt que de poursuivre une agnosticité cloud totale partout
• Le FinOps est continu — l’application des étiquettes et les alertes budgétaires valent mieux qu’un tableur trimestriel
• L’IaC est votre piste d’audit — si ce n’est pas dans le code et revu, cela n’a pas eu lieu

Le multi-cloud n’est en soi ni une bonne ni une mauvaise stratégie. C’est un ensemble de contraintes que quelqu’un d’autre vous a déjà imposées. Le travail d’ingénierie consiste à rendre ces contraintes ennuyeuses — prévisibles, auditables, et économiques à exploiter.