DEV Community: sylvainbruas

AWS European Sovereign Cloud (partie 2) : défis techniques, opérationnels et recommandations pratiques

sylvainbruas — Mon, 11 May 2026 12:14:57 +0000

Cet article est la seconde partie de notre analyse d'AWS European Sovereign Cloud. Dans la première partie, nous avons posé les fondations : ce qu'est la souveraineté numérique (et ce qu'elle n'est pas), l'architecture de l'ESC, les garanties offertes par Nitro, la stratégie de chiffrement, les enjeux sectoriels et la question de SecNumCloud.

Maintenant, passons aux choses concrètes. Quand on ouvre la console ESC pour la première fois, qu'est-ce qui change vraiment ? Quels sont les pièges à éviter et les patterns qui fonctionnent ?

Les défis techniques

Parité de services

L'un des défis techniques majeurs de l'ESC est la parité de services avec AWS commercial. Au lancement, seul un sous-ensemble des services AWS est disponible. Cela signifie que les architectures conçues pour AWS commercial ne sont pas nécessairement transposables telles quelles vers l'ESC.

Les équipes d'architecture doivent :

Inventorier les services utilisés et vérifier leur disponibilité dans l'ESC
Identifier des alternatives pour les services manquants
Adapter les patterns d'architecture en conséquence

Par exemple, si votre architecture repose sur Amazon OpenSearch Serverless, ce service n'est pas disponible au lancement de l'ESC. D'autres services comme Amazon Bedrock sont présents mais avec un catalogue de modèles et de fonctionnalités plus limité que dans la partition commerciale — il est donc essentiel de vérifier la couverture exacte avant de s'engager.

Gestion des identités et des accès

La séparation du plan de contrôle implique que les comptes AWS ESC sont distincts des comptes AWS commerciaux. L'ESC dispose de son propre service IAM, entièrement séparé de celui de la partition commerciale. IAM dans l'ESC est global au sein de la partition ESC, exactement comme IAM est global au sein de la partition commerciale. Mais les deux IAM sont cloisonnés : aucune identité, aucun rôle, aucune politique ne traverse la frontière entre partitions.

Cela a des implications majeures :

AWS Organizations : les organisations ESC sont séparées des organisations commerciales. Vous gérez deux hiérarchies de comptes indépendantes.
IAM séparé : les rôles, politiques et utilisateurs IAM créés dans la partition commerciale n'existent pas dans l'ESC et vice versa. Les endpoints IAM de l'ESC utilisent le domaine amazonaws.eu (par exemple iam.eusc-de-east-1.amazonaws.eu). L'ensemble des identités doit être recréé dans l'ESC.
SSO/Federation : les intégrations avec les fournisseurs d'identité doivent être reconfigurées. Il est possible de pointer les deux instances IAM Identity Center (commerciale et ESC) vers le même IdP d'entreprise (Entra ID, Okta, etc.), mais les permission sets, les assignments de comptes et les groupes doivent être gérés séparément dans chaque partition.
Cross-partition access : pas de possibilité d'accès croisé entre comptes ESC et comptes commerciaux. Un rôle dans arn:aws:iam::123456789012:role/MyRole ne peut pas assumer un rôle dans arn:aws-eusc:iam::987654321098:role/MyRole — les deux partitions ne se voient tout simplement pas. C'est le même cloisonnement qui existe entre AWS commercial et AWS GovCloud ou AWS Chine.

Réseau et connectivité

La séparation réseau entre l'ESC et AWS commercial pose des défis de connectivité :

Pas de VPC peering entre ESC et régions commerciales
Pas de Transit Gateway partagé
Les connexions Direct Connect doivent être dédiées
Les architectures multi-régions doivent être repensées

Liaison réseau entre l'ESC et la partition commerciale

La question de la connectivité entre l'ESC et AWS commercial est cruciale pour les entreprises en mode hybride. Puisque les deux partitions sont logiquement et physiquement séparées, il n'existe pas de mécanisme natif de peering interne — pas de VPC peering, pas de Transit Gateway peering, pas de PrivateLink entre partitions. Voici les options disponibles, détaillées dans l'article de référence d'AWS : Connectivity patterns between AWS European Sovereign Cloud and AWS commercial partition.

Option 1 : Connectivité via Internet avec chiffrement TLS natif

Si l'application utilise nativement le chiffrement TLS (par exemple, du trafic API sur HTTPS/443), il est possible d'utiliser des Elastic IP addresses pour communiquer entre les partitions. C'est le pattern le plus performant et le plus simple à opérer : il ne nécessite pas de maintenir des appliances VPN sur des instances EC2 ni de configurer un Direct Connect Gateway. En revanche, cette option ne fournit pas de chiffrement au niveau de la couche transport réseau — la responsabilité du chiffrement en transit repose sur l'application.

Option 2 : VPN IPSec site-to-site entre partitions (service managé côté ESC)

Ce pattern établit des tunnels VPN IPSec directement entre les deux partitions, sans passer par une infrastructure on-premises. Côté ESC, le tunnel est terminé par le service managé AWS Site-to-Site VPN, attaché à un Transit Gateway — aucune appliance tierce n'est nécessaire dans la partition souveraine. Côté AWS commercial, une appliance virtuelle tierce (Cisco CSR, Palo Alto, Fortinet, StrongSwan, etc.) fait office de Customer Gateway et termine l'autre extrémité du tunnel. Le débit maximum par tunnel VPN est de 1,25 Gbps ; pour des besoins supérieurs, activez le routage ECMP (Equal-Cost Multi-Path) pour agréger le débit sur plusieurs connexions VPN. Ce pattern est adapté aux applications qui ne supportent pas le chiffrement au niveau applicatif ou qui ne doivent pas être exposées via un Internet Gateway.

Option 3 : Connectivité via Direct Connect et infrastructure on-premises ou fournisseur de services

Ce modèle hub-and-spoke route le trafic inter-partition via une infrastructure client connectée par AWS Direct Connect. Deux variantes existent :

Via un datacenter on-premises : des connexions Direct Connect séparées relient chaque partition au datacenter, où des équipements réseau (firewalls, routeurs) contrôlent le trafic inter-partition.
Via un fournisseur de services cloud exchange (Equinix, Digital Realty, etc.) : pour les organisations sans datacenter, une infrastructure gateway virtuelle hébergée chez le fournisseur assure le même rôle.

Le trafic est « hairpinné » via l'infrastructure client, ce qui ajoute de la latence, des coûts de transfert de données sortantes (DTO) et des frais de traitement Transit Gateway. Le Direct Connect Gateway est un construct global qui permet la connectivité vers n'importe quelle région AWS, mais ne propage pas les préfixes BGP entre les Transit Gateways associés.

Option 4 : Transit VPC avec Transit Gateway Connect

Ce pattern utilise un Transit VPC avec des appliances virtuelles tierces redondantes dans différentes zones de disponibilité, connectées au Transit Gateway via des attachments Transit Gateway Connect. Cette approche utilise BGP over GRE (Generic Routing Encapsulation) pour simplifier la connectivité avec le Transit Gateway. À noter que GRE ne fournit pas de chiffrement — si le chiffrement est nécessaire, il faut utiliser un VPN IPSec entre les appliances et le Transit Gateway (comme dans l'option 2).

Option 5 : Pas de liaison directe (air gap logique)

Pour les workloads les plus sensibles, la meilleure option peut être de ne pas établir de liaison réseau du tout entre l'ESC et la partition commerciale. Les données sont transférées via des mécanismes asynchrones contrôlés (export/import chiffré, files de messages avec validation), ce qui garantit une séparation maximale.

Backbone AWS et trafic inter-partition

L'ESC dispose de son propre backbone séparé de celui de la partition commerciale (similaire à AWS Chine). Cette séparation d'infrastructure renforce le modèle de souveraineté de l'ESC.

Considérations importantes

Quelle que soit l'option choisie, gardez à l'esprit :

La latence sera plus élevée qu'entre deux régions commerciales
Vous devez documenter et justifier chaque flux de données entre les partitions pour des raisons de conformité
Les coûts de transfert de données s'appliquent dans les deux sens

Observabilité et monitoring

Les outils de monitoring centralisés (Amazon CloudWatch, AWS CloudTrail) fonctionnent de manière isolée dans l'ESC. Les entreprises qui ont investi dans des dashboards centralisés couvrant plusieurs régions AWS commerciales devront adapter leur approche pour intégrer les métriques de l'ESC.

Les défis opérationnels

Le mode hybride : la complexité au quotidien

C'est probablement le défi le plus sous-estimé. La plupart des entreprises ne migreront pas 100 % de leurs workloads vers l'ESC. Elles adopteront un mode hybride où certaines charges de travail (les plus sensibles) seront dans l'ESC, tandis que d'autres resteront dans AWS commercial.

Cette hybridation crée une complexité opérationnelle considérable :

Gestion de deux environnements distincts : les équipes doivent maîtriser deux écosystèmes qui, bien que similaires, ont des différences subtiles (services disponibles, versions, limites).

Infrastructure as Code : les templates Terraform ou CloudFormation doivent être adaptés pour gérer les deux environnements. Les modules doivent être conditionnels, les providers configurés différemment, et les pipelines CI/CD dupliqués ou paramétrés.

Exemple Terraform : déploiement sur la partition commerciale vs l'ESC

Pour illustrer concrètement la différence, voici un exemple de déploiement d'une instance EC2 avec un bucket S3 sur les deux partitions.

Déploiement sur AWS commercial (partition aws) :

# providers.tf - Partition commerciale
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-3" # Paris
}

# main.tf - Ressources sur la partition commerciale
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "commercial-vpc"
    Environment = "production"
    Partition   = "aws-commercial"
  }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "eu-west-3a"

  tags = {
    Name = "commercial-private-subnet"
  }
}

resource "aws_instance" "app_server" {
  ami           = "ami-0a1b2c3d4e5f67890" # Amazon Linux 2023 - eu-west-3
  instance_type = "m6i.large"
  subnet_id     = aws_subnet.private.id

  metadata_options {
    http_tokens   = "required" # IMDSv2 obligatoire
    http_endpoint = "enabled"
  }

  tags = {
    Name        = "app-server-commercial"
    Environment = "production"
  }
}

resource "aws_s3_bucket" "data" {
  bucket = "mon-entreprise-data-commercial"

  tags = {
    Name        = "data-bucket-commercial"
    Partition   = "aws-commercial"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data_key.arn
    }
  }
}

resource "aws_kms_key" "data_key" {
  description             = "Clé de chiffrement des données - Commercial"
  deletion_window_in_days = 30
  enable_key_rotation     = true
}

Déploiement sur AWS ESC (partition aws-eusc) :

# providers.tf - Partition ESC
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# Terraform 1.14+ avec le provider AWS 6.x résout nativement
# les endpoints ESC — il suffit de spécifier la région.
# Pas besoin de configurer les endpoints manuellement.
provider "aws" {
  region = "eusc-de-east-1" # Brandenburg, Allemagne
}

# Data source pour construire les ARN dynamiquement
# Retourne "aws-eusc" dans l'ESC, "aws" dans la partition commerciale
data "aws_partition" "current" {}
data "aws_caller_identity" "current" {}

# main.tf - Ressources sur la partition ESC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "sovereign-vpc"
    Environment = "production"
    Partition   = data.aws_partition.current.partition
    DataClass   = "sensible"
  }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "eusc-de-east-1a"

  tags = {
    Name = "sovereign-private-subnet"
  }
}

resource "aws_instance" "app_server" {
  ami           = "ami-0esc1a2b3c4d5e6f7" # AMI spécifique ESC
  instance_type = "m6i.large"
  subnet_id     = aws_subnet.private.id

  metadata_options {
    http_tokens   = "required"
    http_endpoint = "enabled"
  }

  tags = {
    Name        = "app-server-sovereign"
    Environment = "production"
    DataClass   = "sensible"
  }
}

resource "aws_s3_bucket" "data" {
  bucket = "mon-entreprise-data-sovereign"

  tags = {
    Name        = "data-bucket-sovereign"
    Partition   = data.aws_partition.current.partition
    DataClass   = "sensible"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data_key.arn
    }
  }
}

resource "aws_kms_key" "data_key" {
  description             = "Clé de chiffrement des données - Souverain"
  deletion_window_in_days = 30
  enable_key_rotation     = true

  # La clé reste exclusivement dans la partition ESC
  # Aucune réplication vers la partition commerciale
}

# Exemple d'ARN dynamique — fonctionne sur toute partition
output "kms_key_arn" {
  value = aws_kms_key.data_key.arn
  # Produit : arn:aws-eusc:kms:eusc-de-east-1:123456789012:key/...
}

Les différences clés à noter :

La région : eusc-de-east-1 (Brandenburg, Allemagne) au lieu de eu-west-3. Les noms de régions ESC suivent le format eusc-{pays}-{direction}-{numéro}.
Le domaine DNS : l'ESC utilise le domaine amazonaws.eu au lieu de amazonaws.com. Par exemple : ec2.eusc-de-east-1.amazonaws.eu, s3.eusc-de-east-1.amazonaws.eu. La console est accessible sur console.amazonaws-eusc.eu.
La partition ARN : les ARN utilisent aws-eusc au lieu de aws. Par exemple : arn:aws-eusc:s3:::mon-bucket vs arn:aws:s3:::mon-bucket. Utilisez data "aws_partition" "current" {} dans Terraform pour construire les ARN dynamiquement plutôt que de les hardcoder.
Les AMI : les images machine sont spécifiques à l'ESC et ne sont pas partagées avec la partition commerciale.
Les credentials : les identifiants IAM de la partition commerciale ne fonctionnent pas sur l'ESC et vice versa. Vous devez gérer deux jeux de credentials séparés. Si vous utilisez un pipeline CI/CD, configurez deux fournisseurs OIDC distincts, chacun pointant vers sa partition respective.
Terraform : à partir de Terraform 1.14+ avec le provider AWS 6.x (et OpenTofu 1.11+), les endpoints ESC sont résolus nativement — il suffit de spécifier la région, sans configuration manuelle des endpoints.

Gestion des secrets et du chiffrement : les clés KMS de l'ESC ne sont pas accessibles depuis AWS commercial et vice versa. Les données chiffrées dans un environnement ne peuvent pas être déchiffrées dans l'autre sans mécanismes de re-chiffrement.

Synchronisation des données : si certaines données doivent être partagées entre les deux environnements (par exemple, des données de référence non sensibles), il faut mettre en place des mécanismes de réplication qui respectent les contraintes de souveraineté.

Compétences et formation

L'ESC introduit de nouvelles contraintes que les équipes doivent intégrer :

Comprendre les différences entre ESC et AWS commercial
Adapter les pratiques DevOps aux contraintes de séparation
Former les équipes aux spécificités de la gouvernance souveraine
Mettre à jour les runbooks et procédures opérationnelles

Coûts et optimisation

Le mode hybride a un impact sur les coûts :

Duplication d'infrastructure : certains composants (monitoring, sécurité, réseau) doivent être déployés dans les deux environnements.
Licences : certains outils tiers peuvent nécessiter des licences séparées pour l'ESC.
Personnel : la complexité accrue peut nécessiter des ressources supplémentaires.
Prix de souveraineté : les prix dans l'ESC sont estimés à 10-15 % supérieurs à ceux de la région Francfort (eu-central-1) pour des services comparables, en raison des contraintes opérationnelles supplémentaires liées à la souveraineté.

Facturation et séparation financière

La facturation de l'ESC est entièrement séparée de celle de la partition commerciale. Voici les points clés :

Entité contractuelle distincte : la facturation ESC est gérée par AWS EMEA SARL (Luxembourg), et non par AWS Inc. (Seattle) comme pour la partition commerciale. Cela a des implications pour les équipes procurement et finance.
Facturation en euros : contrairement à la partition commerciale (facturée en USD), l'ESC est facturé en euros.
Savings Plans et Reserved Instances non transférables : les Enterprise Discount Programs (EDP), les Savings Plans et les Reserved Instances achetés dans la partition commerciale ne s'appliquent pas à l'ESC. Vous devez négocier et acheter des engagements séparés pour chaque partition.
Comptes et Organizations séparés : les comptes ESC ayant leur propre Organization, les tags d'allocation de coûts, les budgets et les rapports Cost and Usage Reports sont indépendants. Si votre équipe FinOps suit les dépenses cloud par account ID, elle devra adapter ses processus pour intégrer les deux partitions.

Gouvernance et conformité

La gouvernance d'un environnement hybride nécessite :

Des politiques claires de classification des données (quelles données vont dans l'ESC, lesquelles restent dans AWS commercial)
Des processus de validation pour tout nouveau déploiement
Un suivi continu de la conformité dans les deux environnements
Des audits réguliers pour vérifier que les données sensibles ne « fuient » pas vers l'environnement commercial

Recommandations pratiques

Évaluer son besoin réel de souveraineté

Avant de se lancer dans une migration vers l'ESC, il est essentiel de :

Classifier ses données : toutes les données n'ont pas le même niveau de sensibilité. Seules les données véritablement sensibles (données personnelles critiques, secrets industriels, données régulées) justifient le surcoût et la complexité de l'ESC.
Identifier ses obligations réglementaires : quelles réglementations s'appliquent réellement à votre organisation ? Êtes-vous soumis à la doctrine « Cloud au centre » ? À DORA ? À des exigences sectorielles spécifiques ?
Évaluer le risque géopolitique : quelle est la probabilité réelle que vos données soient impactées par des mécanismes extraterritoriaux ? Ce risque justifie-t-il la complexité supplémentaire ?

Adopter une approche progressive

Plutôt qu'une migration « big bang », privilégiez une approche incrémentale :

Commencez par un workload pilote bien délimité
Validez les patterns d'architecture et les processus opérationnels
Documentez les différences et les pièges rencontrés
Étendez progressivement à d'autres workloads

Investir dans l'automatisation

L'automatisation est la clé pour gérer la complexité du mode hybride :

Utilisez des abstractions dans votre Infrastructure as Code pour gérer les deux environnements
Automatisez les contrôles de conformité (données au bon endroit, accès correctement configurés)
Mettez en place des pipelines de déploiement qui gèrent nativement les deux cibles
Automatisez la détection de drift entre les environnements

Anticiper l'évolution du paysage

Le domaine de la souveraineté cloud évolue rapidement :

Le schéma EUCS va probablement redéfinir les standards au niveau européen
AWS va continuer à enrichir le catalogue de services de l'ESC
Les réglementations nationales et européennes vont continuer à évoluer
De nouvelles offres souveraines vont émerger

Construisez vos architectures de manière à pouvoir évoluer avec ce paysage changeant.

Conclusion

AWS European Sovereign Cloud représente une avancée significative dans la réponse aux enjeux de souveraineté numérique européenne. En proposant une infrastructure physiquement et logiquement séparée, opérée exclusivement par du personnel européen, AWS adresse une grande partie des préoccupations liées à la souveraineté des données.

Cependant, il est crucial de ne pas confondre souveraineté et cybersécurité. L'ESC répond à des enjeux de gouvernance et de contrôle, pas à des problématiques de protection contre les cybermenaces (même si les deux se complètent).

La question de SecNumCloud reste ouverte : pour les organisations soumises à la doctrine française, elle reste incontournable. Pour les autres, l'ESC offre un compromis pragmatique entre souveraineté et accès à l'écosystème AWS.

Le véritable défi réside dans l'opérationnel : gérer un mode hybride entre AWS commercial et l'ESC demande une maturité organisationnelle, des compétences spécifiques et des investissements en automatisation. Les entreprises qui réussiront cette transition seront celles qui auront pris le temps de bien classifier leurs données, d'adopter une approche progressive et d'investir dans l'outillage nécessaire.

La souveraineté numérique n'est pas une destination, c'est un chemin. Et ce chemin passe par des choix éclairés, une compréhension fine des enjeux, et une exécution rigoureuse.

AWS European Sovereign Cloud (partie 1) : souveraineté numérique, architecture et enjeux

sylvainbruas — Mon, 11 May 2026 12:14:42 +0000

La souveraineté numérique est devenue un sujet central dans les stratégies IT des entreprises européennes. Entre les réglementations de plus en plus strictes, les tensions géopolitiques et la dépendance croissante aux hyperscalers américains, les organisations doivent repenser leur approche du cloud. C'est dans ce contexte qu'Amazon Web Services a annoncé le lancement d'AWS European Sovereign Cloud (ESC), une infrastructure cloud dédiée, physiquement et logiquement séparée des régions AWS commerciales existantes.

Mais qu'est-ce que la souveraineté numérique exactement ? En quoi diffère-t-elle de la cybersécurité ? Quels sont les véritables enjeux pour les entreprises qui envisagent de migrer vers cette offre ? Et surtout, comment naviguer dans la complexité d'un mode hybride entre AWS commercial et l'ESC ?

Cette série de deux articles propose une analyse approfondie de ces questions. Dans cette première partie, nous abordons les fondamentaux : définition de la souveraineté, architecture de l'ESC, rôle de Nitro, stratégie de chiffrement, enjeux sectoriels et question de SecNumCloud. La seconde partie couvre les défis techniques, opérationnels et les recommandations pratiques.

Souveraineté numérique : de quoi parle-t-on ?

Définition et périmètre

La souveraineté numérique désigne la capacité d'un État, d'une organisation ou d'un individu à exercer un contrôle sur ses données, ses infrastructures numériques et ses processus de décision dans l'espace numérique. Elle englobe plusieurs dimensions :

La souveraineté des données : savoir où sont stockées les données, qui y a accès, et sous quelle juridiction elles tombent.
La souveraineté opérationnelle : garantir que l'exploitation des infrastructures est réalisée par du personnel soumis au droit européen, sans possibilité d'ingérence étrangère.
La souveraineté technologique : disposer de la maîtrise des technologies utilisées, ou a minima d'une indépendance suffisante pour ne pas être soumis à des décisions unilatérales d'un fournisseur étranger.

Ne pas confondre souveraineté et cybersécurité

C'est probablement la confusion la plus répandue dans les discussions autour du cloud souverain. La cybersécurité et la souveraineté numérique sont deux concepts distincts, bien qu'ils se recoupent partiellement.

La cybersécurité concerne la protection des systèmes d'information contre les menaces : attaques, intrusions, fuites de données, ransomwares, etc. Elle répond à la question « comment protéger mes données contre les attaquants ? ».

La souveraineté numérique concerne le contrôle et la gouvernance des données et des infrastructures. Elle répond à la question « qui a le pouvoir de décision sur mes données et mes systèmes ? ».

Un cloud peut être parfaitement sécurisé au sens cybersécurité (chiffrement, contrôle d'accès, détection d'intrusion) tout en posant des problèmes de souveraineté si, par exemple, un gouvernement étranger peut légalement contraindre le fournisseur à divulguer des données via des mécanismes comme le CLOUD Act américain.

Inversement, un cloud souverain mal configuré peut présenter des failles de sécurité béantes. La souveraineté ne garantit pas la sécurité, et la sécurité ne garantit pas la souveraineté. Les deux sont nécessaires, mais aucun ne suffit seul.

Le contexte réglementaire européen

Plusieurs textes législatifs européens encadrent désormais la gestion des données et poussent vers plus de souveraineté :

RGPD (2018) : protection des données personnelles, avec des restrictions sur les transferts hors UE.
NIS2 (2024) : renforcement des obligations de cybersécurité pour les entités essentielles et importantes.
DORA (2025) : résilience opérationnelle numérique pour le secteur financier.
Data Act (2025) : portabilité des données et conditions d'accès.
EUCS (en cours) : schéma européen de certification cloud, qui devrait définir des niveaux d'assurance pour les services cloud.

C'est dans ce paysage réglementaire dense que s'inscrit l'offre AWS ESC.

AWS European Sovereign Cloud : architecture et principes

Qu'est-ce que l'ESC ?

AWS European Sovereign Cloud est une infrastructure cloud complètement séparée des régions AWS commerciales. Contrairement à une simple région européenne d'AWS (comme eu-west-1 à Dublin ou eu-central-1 à Francfort), l'ESC repose sur :

Une séparation physique : des datacenters dédiés, situés exclusivement sur le territoire de l'Union européenne.
Une séparation logique : un plan de contrôle indépendant, des systèmes de facturation séparés, et aucune interconnexion avec l'infrastructure AWS globale.
Un personnel exclusivement européen : les opérations sont réalisées par des employés résidant dans l'UE et soumis au droit européen.
Une gouvernance européenne : les décisions opérationnelles sont prises au sein de l'UE, sans possibilité d'intervention depuis les États-Unis.

Les services disponibles

L'ESC propose progressivement les services AWS les plus utilisés, adaptés aux exigences de souveraineté. On y retrouve notamment Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3), Amazon Relational Database Service (RDS), AWS Lambda, Amazon Virtual Private Cloud (VPC), et les services de sécurité comme AWS Key Management Service (KMS) avec des clés gérées exclusivement dans l'ESC.

Cependant, tous les services AWS ne sont pas disponibles dans l'ESC. C'est l'un des défis majeurs que nous aborderons dans la seconde partie.

Pour suivre l'évolution des services disponibles et planifier vos architectures en fonction des capacités actuelles et à venir, AWS met à disposition un outil interactif : AWS Builder - Capabilities. Cet outil permet de visualiser les services disponibles par région et par partition, y compris l'ESC. Il est particulièrement utile pour les architectes qui doivent valider la faisabilité d'un déploiement sur l'ESC avant de s'engager dans une migration. Vous pouvez y filtrer par catégorie de service (compute, storage, database, analytics, etc.) et comparer la couverture entre la partition commerciale et la partition souveraine.

AWS Nitro System : la fondation sécuritaire de l'ESC

Un élément fondamental de l'architecture de sécurité d'AWS — et donc de l'ESC — est le système AWS Nitro. Comprendre Nitro est essentiel pour appréhender les garanties de sécurité offertes par l'infrastructure souveraine.

Qu'est-ce que Nitro ?

AWS Nitro System est l'architecture matérielle et logicielle sous-jacente à toutes les instances EC2 modernes. Il se compose de trois éléments principaux :

Les cartes Nitro : des composants matériels dédiés qui gèrent le réseau, le stockage (EBS) et le monitoring, en les déchargeant complètement de l'hyperviseur.
Le Nitro Security Chip : une puce dédiée qui contrôle l'accès au matériel serveur et fournit une racine de confiance matérielle (hardware root of trust).
Le Nitro Hypervisor : un hyperviseur minimaliste et durci, dont la surface d'attaque est considérablement réduite par rapport aux hyperviseurs traditionnels.

Ce que Nitro apporte à la souveraineté

Dans le contexte de l'ESC, Nitro offre des garanties de sécurité qui renforcent la posture de souveraineté :

Isolation cryptographique : chaque instance EC2 est isolée au niveau matériel. Même un employé AWS ayant un accès physique au serveur ne peut pas accéder à la mémoire ou au stockage d'une instance en cours d'exécution. Le Nitro Security Chip empêche physiquement toute lecture de la mémoire volatile.

Pas d'accès opérateur : contrairement aux architectures traditionnelles où un administrateur système peut potentiellement accéder aux données des machines virtuelles, Nitro élimine cette possibilité par conception. Il n'existe aucun mécanisme — ni SSH, ni console de debug, ni port de maintenance — permettant à un opérateur AWS d'accéder au contenu d'une instance client.

Attestation matérielle : Nitro Enclaves permet d'exécuter du code dans un environnement d'exécution de confiance (TEE - Trusted Execution Environment) avec une attestation cryptographique. Cela garantit que le code exécuté n'a pas été altéré et que les données traitées restent confidentielles, même vis-à-vis de l'opérateur de l'infrastructure.

Intégrité du firmware : le Nitro Security Chip vérifie l'intégrité du firmware à chaque démarrage. Toute modification non autorisée du firmware est détectée et empêche le démarrage du serveur.

Une architecture reconnue dans la littérature académique

Il est intéressant de noter que l'architecture Nitro n'est pas simplement un produit marketing. Elle est citée et étudiée dans des ouvrages de référence sur l'architecture des processeurs et la virtualisation matérielle. Le concept de déport des fonctions d'I/O vers des composants matériels dédiés (offloading), la séparation stricte entre le plan de données et le plan de contrôle au niveau silicium, et l'utilisation d'une racine de confiance matérielle sont des patterns architecturaux documentés dans la littérature sur les systèmes sur puce (SoC) et les architectures de sécurité matérielle.

Des ouvrages comme Computer Architecture: A Quantitative Approach (Hennessy & Patterson) abordent les principes fondamentaux sur lesquels repose Nitro : la spécialisation matérielle, les accélérateurs dédiés et l'isolation par le matériel. L'approche de Nitro — qui consiste à retirer l'hyperviseur du chemin critique des données et à confier les opérations sensibles à des puces dédiées — s'inscrit dans une tendance plus large de l'industrie vers les SmartNICs et les DPU (Data Processing Units), documentée dans les publications IEEE et ACM sur les architectures de datacenter modernes.

Cette reconnaissance académique renforce la crédibilité des garanties de sécurité offertes par Nitro : il ne s'agit pas d'une simple promesse contractuelle, mais d'une impossibilité technique vérifiable et documentée.

Nitro et la réponse au CLOUD Act

L'un des arguments les plus puissants de Nitro dans le contexte de la souveraineté est le suivant : même si, théoriquement, une autorité étrangère obtenait une injonction légale contre AWS, l'architecture Nitro rend techniquement impossible l'accès aux données en cours de traitement sur les instances. AWS ne peut pas fournir ce à quoi il n'a pas accès. Combiné à un chiffrement côté client avec des clés gérées par le client (Customer Managed Keys dans KMS ESC), cela crée une protection technique qui complète la protection juridique offerte par la séparation de l'ESC.

KMS, chiffrement au repos et souveraineté : faut-il des CMK pour être souverain ?

Le chiffrement au repos est souvent présenté comme la pierre angulaire de la protection des données dans le cloud. Mais dans le contexte de la souveraineté, la question n'est pas simplement « mes données sont-elles chiffrées ? » mais plutôt « qui contrôle les clés de chiffrement ? ».

Les options de chiffrement sur AWS

AWS propose plusieurs niveaux de chiffrement au repos :

SSE-S3 (Server-Side Encryption with S3 Managed Keys) : AWS gère entièrement les clés. Le chiffrement est transparent pour l'utilisateur. C'est le niveau par défaut depuis janvier 2023.
SSE-KMS avec clé gérée par AWS (aws/s3) : AWS KMS gère la clé, mais vous bénéficiez d'un audit via CloudTrail et de politiques de contrôle d'accès.
SSE-KMS avec CMK (Customer Managed Key) : vous créez et contrôlez la clé dans KMS. Vous définissez qui peut l'utiliser, vous pouvez la désactiver ou la supprimer, et vous contrôlez sa rotation.
SSE-C (Server-Side Encryption with Customer-Provided Keys) : vous fournissez la clé à chaque requête via les headers HTTPS. AWS l'utilise pour chiffrer/déchiffrer en mémoire puis la supprime immédiatement — elle n'est jamais stockée côté AWS. Cette option est pleinement compatible avec l'ESC puisqu'elle repose uniquement sur le protocole S3 standard, sans dépendance à un service de gestion de clés spécifique à une partition.
Chiffrement côté client (Client-Side Encryption) : vous chiffrez les données dans votre application avant de les envoyer à AWS. AWS ne voit jamais les données en clair et ne manipule aucune clé. C'est l'option la plus agnostique : elle fonctionne sur toute partition (commerciale, ESC, GovCloud) puisque le chiffrement est entièrement décorrélé de l'infrastructure AWS. C'est aussi l'option qui offre le niveau de souveraineté le plus élevé — même avec un accès physique aux disques ou aux HSM, les données restent illisibles sans vos clés.

Doit-on avoir des CMK pour être souverain ?

C'est une question qui revient systématiquement dans les discussions sur la souveraineté, et la réponse mérite d'être nuancée.

L'argument en faveur des CMK : avec une Customer Managed Key, vous avez le contrôle total sur le cycle de vie de la clé. Vous pouvez la révoquer à tout moment, rendant les données illisibles. C'est un mécanisme de « kill switch » qui vous donne un pouvoir concret sur vos données, indépendamment du fournisseur cloud.

Mais les CMK ne suffisent pas à garantir la souveraineté : une CMK dans KMS reste gérée par le service KMS d'AWS. Même si vous contrôlez la politique d'accès, c'est AWS qui opère le HSM (Hardware Security Module) sous-jacent. Dans la partition commerciale, un employé AWS aux États-Unis pourrait théoriquement avoir accès au plan de contrôle de KMS.

Dans l'ESC, la donne change : les HSM de KMS dans l'ESC sont opérés exclusivement par du personnel européen, dans des datacenters européens, avec un plan de contrôle séparé. Une CMK dans KMS ESC offre donc un niveau de souveraineté significativement supérieur à une CMK dans KMS commercial.

Quand les CMK sont-elles indispensables ?

Les CMK sont recommandées (voire obligatoires selon les contextes) dans les cas suivants :

Données régulées : si votre régulateur exige que vous démontriez un contrôle sur les clés de chiffrement, les CMK sont nécessaires.
Exigence de révocabilité : si vous devez pouvoir rendre des données illisibles rapidement (en cas de fin de contrat, de litige, ou de compromission), les CMK vous donnent ce pouvoir.
Audit et traçabilité : les CMK dans KMS génèrent des événements CloudTrail pour chaque utilisation, ce qui permet un audit complet de qui accède aux données et quand.
Séparation des responsabilités : dans une organisation où l'équipe sécurité doit contrôler les clés indépendamment de l'équipe applicative, les CMK permettent cette séparation via les key policies.

Quand les CMK ne sont pas nécessaires ?

Pour des données non sensibles ou des cas d'usage où la souveraineté n'est pas un enjeu (données publiques, caches, données temporaires), le chiffrement par défaut SSE-S3 ou SSE-KMS avec clé AWS est suffisant. Multiplier les CMK sans raison augmente la complexité opérationnelle (gestion de la rotation, risque de suppression accidentelle, coûts KMS) sans apporter de bénéfice réel.

La stratégie recommandée

Une approche pragmatique consiste à :

Classifier les données par niveau de sensibilité
Appliquer des CMK uniquement aux données sensibles et régulées
Utiliser le chiffrement par défaut pour les données non sensibles
Envisager le chiffrement côté client pour les données les plus critiques (secrets industriels, données de santé nominatives) — dans ce cas, même AWS avec un accès au HSM ne pourrait pas déchiffrer les données

Les enjeux de la souveraineté pour les entreprises

Enjeux stratégiques

Pour les entreprises européennes, la souveraineté numérique n'est pas qu'une question de conformité réglementaire. C'est un enjeu stratégique à plusieurs niveaux :

Continuité d'activité : en cas de sanctions internationales ou de tensions géopolitiques, une entreprise dépendante d'un cloud américain pourrait se voir couper l'accès à ses propres données.
Confiance des clients : dans des secteurs comme la santé, la finance ou le secteur public, la localisation et le contrôle des données sont des critères de choix déterminants.
Propriété intellectuelle : les données de R&D, les algorithmes propriétaires et les secrets industriels nécessitent un niveau de protection qui va au-delà de la simple cybersécurité.
Indépendance décisionnelle : ne pas être soumis aux conditions générales d'utilisation d'un fournisseur qui peut modifier unilatéralement ses termes de service.

Enjeux sectoriels

Certains secteurs sont particulièrement concernés par la souveraineté :

Secteur public et défense : obligation légale de traiter certaines données sur le territoire national, sous contrôle d'entités habilitées.
Santé : les données de santé sont soumises à des réglementations spécifiques (hébergement de données de santé en France, par exemple).
Finance : DORA impose des exigences strictes sur la résilience et le contrôle des prestataires cloud.
Énergie et infrastructures critiques : NIS2 renforce les obligations pour les opérateurs d'importance vitale.

Le défi législatif : SecNumCloud, nécessité ou superflu ?

Qu'est-ce que SecNumCloud ?

SecNumCloud est une qualification délivrée par l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) en France. Elle atteste qu'un prestataire de services cloud respecte un ensemble d'exigences de sécurité et de souveraineté définies par le référentiel de l'ANSSI.

La version 3.2 du référentiel, publiée en 2022, a introduit des critères de souveraineté stricts : le prestataire doit être une entité européenne, détenue majoritairement par des capitaux européens, et ne doit pas être soumis à des législations extraterritoriales (comme le CLOUD Act).

SecNumCloud est-il nécessaire ?

La réponse dépend fortement du contexte :

Pour les administrations françaises : la doctrine « Cloud au centre » de l'État français impose l'utilisation de clouds qualifiés SecNumCloud pour les données sensibles. C'est donc une obligation réglementaire dans ce contexte.

Pour les entreprises privées françaises : SecNumCloud n'est pas une obligation légale générale. Cependant, certains secteurs régulés (santé, finance) peuvent avoir des exigences qui convergent vers ce type de qualification.

Pour les entreprises européennes hors France : SecNumCloud est une qualification purement française. Elle n'a pas de valeur juridique en Allemagne, aux Pays-Bas ou en Italie. Chaque pays peut avoir ses propres exigences ou se référer au futur schéma EUCS.

SecNumCloud vs EUCS : le débat européen

Le schéma européen de certification cloud (EUCS) est en cours d'élaboration au niveau de l'ENISA. Il devrait définir trois niveaux d'assurance : basique, substantiel et élevé.

Le débat fait rage sur le niveau « élevé » : doit-il inclure des critères de souveraineté (immunité aux lois extraterritoriales) comme le fait SecNumCloud 3.2, ou doit-il se limiter à des critères techniques de sécurité ?

La France pousse pour inclure des critères de souveraineté au niveau élevé, tandis que d'autres pays européens (notamment les Pays-Bas et les pays nordiques) considèrent que cela exclurait de facto les hyperscalers américains et limiterait le choix des entreprises.

Position d'AWS ESC par rapport à SecNumCloud

AWS ESC ne vise pas la qualification SecNumCloud dans sa forme actuelle. En effet, SecNumCloud 3.2 exige que le prestataire soit détenu majoritairement par des capitaux européens, ce qui exclut structurellement AWS, même avec l'ESC.

Cependant, l'ESC répond à de nombreuses exigences de souveraineté :

Données stockées exclusivement dans l'UE
Personnel européen
Séparation du plan de contrôle
Pas d'accès depuis l'extérieur de l'UE

La question est donc : SecNumCloud est-il un prérequis absolu, ou l'ESC offre-t-il un niveau de souveraineté suffisant pour la majorité des cas d'usage ? Pour les entreprises qui ne sont pas soumises à la doctrine « Cloud au centre », l'ESC peut constituer une réponse pragmatique aux enjeux de souveraineté, sans les contraintes d'un écosystème SecNumCloud encore limité en termes de services disponibles.

Comprendre les enjeux de souveraineté, l'architecture de l'ESC et le cadre législatif est un prérequis. Mais la vraie complexité se révèle quand on passe à l'implémentation : comment gérer deux partitions au quotidien ? Quels sont les pièges techniques ? Comment adapter son Infrastructure as Code ?

C'est ce que nous abordons dans la seconde partie : parité de services, IAM régional, connectivité réseau entre partitions, Terraform multi-partition, Landing Zone Accelerator, facturation séparée, et recommandations pratiques pour réussir votre adoption de l'ESC.

LiteLLM et les AI Gateways : reprendre le contrôle des coûts et de la sécurité de vos agents IA

sylvainbruas — Mon, 11 May 2026 11:01:41 +0000

L'intelligence artificielle générative a changé la donne. Les entreprises expérimentes et commencent la mise en production d'agents IA capables d'orchestrer des tâches complexes : analyse de documents, génération de code, interaction client, automatisation de processus métier. Mais cette adoption rapide a un revers : les coûts. Et pas n'importe quels coûts — des coûts imprévisibles, qui peuvent exploser sans raison apparente, et qui échappent souvent aux mécanismes de contrôle traditionnels.

C'est dans ce contexte que les AI Gateways émergent comme une brique d'infrastructure essentielle. Et parmi les solutions disponibles, LiteLLM se distingue par sa capacité à se positionner en front d'Amazon Bedrock pour offrir le meilleur des deux mondes : la puissance et la flexibilité d'un catalogue de modèles de classe mondiale, combinées à un contrôle granulaire des coûts, de la sécurité et de la gouvernance.

Le problème : des coûts d'agents IA qui explosent sans prévenir

Contrairement à une API REST classique dont le coût par appel est relativement stable et prévisible, les agents IA introduisent une imprévisibilité structurelle dans la facturation. Plusieurs facteurs expliquent ce phénomène :

Les boucles d'appels récursifs. Un agent autonome peut décider, en fonction du contexte, d'appeler un modèle de langage (LLM) plusieurs dizaines de fois pour accomplir une seule tâche. Un agent de type ReAct (Reasoning + Acting) va typiquement alterner entre phases de réflexion et phases d'action, chaque itération générant un appel au LLM. Si la tâche est complexe ou si l'agent « tourne en rond » sur un problème, le nombre d'appels peut exploser sans qu'aucun mécanisme natif ne l'arrête.

L'explosion des tokens en contexte. Les agents modernes utilisent des fenêtres de contexte de plus en plus larges. Chaque appel successif inclut l'historique des échanges précédents, ce qui signifie que le nombre de tokens en entrée croît de manière quasi-exponentielle au fil de la conversation.

Les appels d'outils en cascade. Les agents modernes ne se contentent pas d'appeler un LLM. Ils orchestrent des outils : recherche web, requêtes en base de données, appels à d'autres API, génération d'images. Chaque outil peut lui-même déclencher des appels supplémentaires au LLM pour interpréter les résultats. Un seul prompt utilisateur peut ainsi générer des dizaines d'appels facturés.

L'absence de plafond natif. La plupart des fournisseurs de modèles facturent à l'usage sans mécanisme de plafonnement intégré. Si un agent s'emballe, rien ne l'arrête côté fournisseur — la facture continue de grimper jusqu'à ce qu'un humain intervienne ou que les quotas de rate limiting soient atteints.

Exemples d'explosion de coûts

Les témoignages se multiplient dans la communauté :

Un développeur qui lance un agent de refactoring de code sur un repository entier et se retrouve avec une facture de plusieurs centaines de dollars en quelques heures, là où il attendait quelques dizaines.
Une équipe data qui déploie un agent d'analyse de documents en production sans garde-fou : l'agent, confronté à des documents mal formatés, entre dans des boucles de retry qui multiplient les appels par 10.
Un chatbot client qui, face à des requêtes ambiguës, génère des réponses de plus en plus longues en incluant tout l'historique de conversation, faisant exploser le coût par interaction.

Ces situations ne sont pas des cas extrêmes. Elles sont le résultat normal du fonctionnement des agents IA quand aucun mécanisme de contrôle n'est en place. Le problème n'est pas que les agents « dysfonctionnent » — c'est qu'ils fonctionnent exactement comme prévu, mais sans contrainte budgétaire.

Pourquoi les outils de FinOps traditionnels ne suffisent pas

Les outils de FinOps cloud classiques (AWS Cost Explorer, budgets Amazon CloudWatch, alertes de facturation) sont conçus pour des patterns de consommation relativement stables et prévisibles. Ils fonctionnent bien pour surveiller la consommation Amazon EC2 ou Amazon S3, mais ils sont inadaptés aux coûts d'IA générative pour plusieurs raisons :

Granularité insuffisante : ils opèrent historiquement au niveau du compte ou du service. Bedrock propose désormais une attribution par principal IAM, mais sans mécanisme de coupure automatique au niveau applicatif.
Latence des alertes : les alertes budgétaires AWS ont un délai de plusieurs heures. Un agent qui s'emballe peut consommer des centaines de dollars avant que l'alerte ne se déclenche.
Pas de coupure automatique : une alerte budgétaire AWS notifie, mais ne coupe pas l'accès. L'agent continue de consommer pendant que l'équipe réagit.
Pas de vision cross-provider : si vous utilisez plusieurs fournisseurs de modèles (Bedrock, OpenAI, Anthropic direct), chaque fournisseur a sa propre facturation, rendant la vision consolidée impossible.

La réponse : les AI Gateways

Qu'est-ce qu'un AI Gateway ?

Un AI Gateway est un proxy intelligent qui se positionne entre vos applications (agents, chatbots, pipelines) et les fournisseurs de modèles IA. Il agit comme un point de passage obligé pour tous les appels aux LLM, ce qui lui permet d'offrir des fonctionnalités transversales :

Contrôle des coûts : budgets par équipe, par application, par utilisateur, avec coupure automatique quand le budget est atteint.
Sécurité et gouvernance : authentification, autorisation, filtrage de contenu, audit des requêtes.
Observabilité : logging centralisé de tous les appels, métriques de latence, de tokens consommés, de coûts en temps réel.
Routage intelligent : redirection des requêtes vers différents modèles en fonction de critères (coût, latence, disponibilité, type de tâche).
Abstraction du fournisseur : interface unifiée quel que soit le modèle sous-jacent (Claude, Llama, Mistral, Titan, etc.).

Pourquoi un point d'entrée unifié est essentiel

Sans AI Gateway, chaque équipe, chaque application accède directement aux modèles avec ses propres credentials, ses propres patterns d'appel, et sans visibilité centralisée. C'est l'équivalent de donner à chaque développeur un accès root à la base de données de production sans passer par un connection pooler ou un proxy SQL.

Un point d'entrée unifié permet de :

Appliquer des politiques de sécurité cohérentes : filtrage de données sensibles (PII), blocage de certains types de requêtes, validation des inputs.
Avoir une vision consolidée des coûts : qui consomme quoi, combien, et pour quel usage.
Réagir en temps réel : couper un agent qui s'emballe, throttler une application qui consomme trop, rediriger vers un modèle moins coûteux en cas de pic.
Simplifier la rotation des credentials : un seul point à mettre à jour quand les clés API changent.
Faciliter la conformité : un seul point d'audit pour toutes les interactions avec les modèles IA.

Une AI Gateway open source : LiteLLM

LiteLLM est un proxy open source qui fournit une interface compatible OpenAI pour plus de 100 fournisseurs de modèles IA. Concrètement, vos applications parlent à LiteLLM via l'API standard OpenAI (/chat/completions, /embeddings, etc.), et LiteLLM traduit ces appels vers le fournisseur de votre choix : Amazon Bedrock, Azure OpenAI, Anthropic, Mistral, Cohere, et bien d'autres.

C'est une plateforme complète de gestion des accès aux LLM qui inclut :

Gestion des clés virtuelles : création de clés API avec des budgets, des limites de rate, et des permissions par modèle.
Budgets par équipe et par utilisateur : définition de plafonds de dépenses avec coupure automatique.
Routage et fallback : si un modèle est indisponible ou saturé, LiteLLM redirige automatiquement vers un modèle de secours.
Guardrails : intégration de filtres de contenu, de détection de PII, et de politiques de sécurité.
Dashboard d'observabilité : visualisation en temps réel des coûts, des tokens, de la latence, par clé, par équipe, par modèle.
Cache sémantique : mise en cache des réponses pour des requêtes similaires, réduisant les coûts et la latence.

LiteLLM se déploie comme un service stateless (conteneur Docker) devant vos fournisseurs de modèles. Les applications communiquent avec LiteLLM via l'API compatible OpenAI, et LiteLLM route les requêtes vers le bon fournisseur en appliquant les politiques de sécurité, de budget et de routage.

LiteLLM en front d'Amazon Bedrock : le meilleur des deux mondes

Pourquoi Bedrock comme backend ?

Amazon Bedrock est le service managé d'AWS qui donne accès à un catalogue de modèles fondamentaux (Foundation Models) de différents fournisseurs : Anthropic (Claude), Meta (Llama), Mistral, Amazon (Titan, Nova), Cohere, AI21 Labs, et d'autres. Bedrock offre plusieurs avantages structurels :

Pas de gestion d'infrastructure : les modèles sont servis par AWS, vous n'avez pas à gérer de GPU, de scaling, ou de disponibilité.
Intégration native AWS : IAM pour l'authentification, CloudTrail pour l'audit, VPC endpoints pour la connectivité privée, KMS pour le chiffrement.
Données privées : vos données ne sont pas utilisées pour entraîner les modèles. Bedrock offre des garanties contractuelles sur ce point.
Disponibilité régionale : Bedrock est disponible dans plusieurs régions européennes, et est disponible dans l'ESC avec une liste limitée de modèles.

Ce que LiteLLM ajoute à Bedrock

Bedrock est excellent pour servir des modèles, LiteLLM ajoute une interface unifiée et plus orientée vers les applications et utilisateurs.

Budgets granulaires avec enforcement. Bedrock offre désormais une attribution des coûts par principal IAM, mais il ne propose pas de mécanisme de coupure automatique quand un seuil est atteint. LiteLLM comble ce manque : il permet de définir des budgets par Business Unit, par application, par équipe, voire par utilisateur individuel, avec un enforcement en quasi temps réel. Quand le budget est atteint, l'accès est coupé automatiquement — pas besoin d'attendre une alerte CloudWatch avec 6 heures de retard.

# Exemple de configuration LiteLLM avec budgets par équipe
general_settings:
  master_key: sk-litellm-master-key

model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: bedrock/us.anthropic.claude-sonnet-4-6
      aws_region_name: us-east-1

  - model_name: claude-haiku
    litellm_params:
       model: bedrock/us.anthropic.claude-3-5-haiku-20241022-v1:0
      aws_region_name: us-east-1

  - model_name: mistral-7b
    litellm_params:
      model: bedrock/converse/mistral.mistral-7b-instruct-v0:2
      aws_region_name: us-east-1

Côté gestion des équipes et budgets, LiteLLM expose une API d'administration :

# Créer une équipe avec un budget mensuel
curl -X POST 'http://litellm:4000/team/new' \
  -H 'Authorization: Bearer sk-litellm-master-key' \
  -H 'Content-Type: application/json' \
  -d '{
    "team_alias": "equipe-data",
    "max_budget": 500,
    "budget_duration": "1mo",
    "models": ["claude-sonnet", "claude-haiku"],
    "metadata": {"bu": "data-engineering"}
  }'

# Créer une clé pour un développeur avec son propre budget
curl -X POST 'http://litellm:4000/key/generate' \
  -H 'Authorization: Bearer sk-litellm-master-key' \
  -H 'Content-Type: application/json' \
  -d '{
    "team_id": "team-xxx",
    "max_budget": 50,
    "budget_duration": "1mo",
    "models": ["claude-haiku"],
    "metadata": {"user": "jean.dupont@entreprise.fr"}
  }'

Routage par coût. LiteLLM peut automatiquement router les requêtes vers le modèle le moins coûteux capable de traiter la tâche. Par exemple, les requêtes simples (classification, extraction) sont envoyées vers Claude Haiku (peu coûteux), tandis que les tâches complexes (raisonnement, génération longue) sont dirigées vers Claude Sonnet.

Fallback automatique. Si Bedrock dans une région est saturé ou indisponible, LiteLLM peut automatiquement basculer vers une autre région ou un autre fournisseur, sans interruption pour l'application.

L'ancienne pièce manquante côté AWS : l'attribution granulaire native de Bedrock

Depuis avril 2026, AWS a comblé une lacune avec l'attribution granulaire des coûts pour Amazon Bedrock. Bedrock attribue désormais automatiquement les coûts d'inférence au principal IAM qui effectue l'appel. Dans le Cost and Usage Report (CUR 2.0), une nouvelle colonne line_item_iam_principal identifie précisément qui consomme : un utilisateur IAM, un rôle applicatif, ou une identité fédérée.

Combiné à des tags IAM (principal tags sur les rôles/utilisateurs, ou session tags passés dynamiquement), on peut agréger les coûts par équipe, projet ou centre de coûts directement dans AWS Cost Explorer.

Le cas spécifique des AI Gateways. L'article AWS identifie explicitement le scénario d'un LLM gateway en front de Bedrock. Sans configuration supplémentaire, tout le trafic est attribué au rôle unique du gateway — aucune visibilité par utilisateur. La solution recommandée : le gateway effectue un AssumeRole par utilisateur avec un --role-session-name identifiant l'appelant et des --tags de session (équipe, tenant, centre de coûts). Les credentials sont cachées avec un TTL d'une heure, ce qui limite les appels STS à un par utilisateur par heure.

# Exemple : le gateway assume un rôle Bedrock pour chaque utilisateur
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/BedrockInvocationRole \
  --role-session-name "gw-jean.dupont" \
  --tags Key=team,Value=data-engineering Key=cost-center,Value=BU-DATA

Ce qui apparaît alors dans CUR 2.0 :

`line_item_iam_principal`	`line_item_usage_type`	`tags`
`…assumed-role/BedrockRole/gw-jean.dupont`	`EUW3-Claude4Sonnet-input-tokens`	`{"iamPrincipal/team":"data-engineering"}`
`…assumed-role/BedrockRole/gw-tenant-acme`	`EUW3-Claude4Sonnet-output-tokens`	`{"iamPrincipal/tenant":"acme-corp"}`

Complémentarité avec LiteLLM. Cette attribution native ne remplace pas LiteLLM — elle le complète. Bedrock fournit désormais la visibilité passive (qui consomme quoi dans la facturation AWS), tandis que LiteLLM assure le contrôle actif (coupure automatique quand un budget est atteint, rate limiting par clé, routage par coût, guardrails). Les deux ensemble offrent une gouvernance FinOps complète :

Bedrock + CUR 2.0 : attribution, reporting, chargeback, analyse a posteriori via Cost Explorer
LiteLLM : enforcement en temps réel, coupure automatique, routage intelligent, abstraction multi-modèle

En pratique, si vous déployez LiteLLM en front de Bedrock, configurez-le pour utiliser des sessions STS par utilisateur. Vous obtiendrez à la fois le contrôle temps réel de LiteLLM et l'attribution native dans votre facturation AWS — le meilleur des deux mondes, littéralement.

Budgets par BU, par application : la gouvernance FinOps de l'IA

L'un des cas d'usage les plus puissants de LiteLLM en front de Bedrock est la capacité à implémenter une gouvernance FinOps granulaire pour l'IA générative. Voici comment structurer les budgets dans une organisation :

Chaque niveau de la hiérarchie a son propre budget. Si l'équipe Dev du chatbot atteint ses 500 € mensuels, ses clés sont désactivées automatiquement — mais le reste de la BU Produit continue de fonctionner. Si c'est toute la BU Produit qui atteint ses 5 000 €, toutes les applications de cette BU sont coupées, mais les autres BU ne sont pas impactées.

Sécurité : une couche unifiée indispensable

Les risques de sécurité spécifiques aux LLM

Les agents IA introduisent des vecteurs d'attaque spécifiques qui nécessitent des contrôles dédiés :

Injection de prompt : un utilisateur malveillant peut tenter de manipuler l'agent pour qu'il exécute des actions non autorisées ou divulgue des informations sensibles.
Exfiltration de données : un agent qui a accès à des données internes peut être manipulé pour les inclure dans ses réponses.
Fuite de PII : les modèles peuvent involontairement inclure des données personnelles dans leurs réponses si elles sont présentes dans le contexte.
Abus de ressources : un utilisateur peut intentionnellement déclencher des boucles coûteuses pour nuire à l'organisation.
Shadow AI : sans point d'entrée centralisé, les équipes utilisent des clés API personnelles, contournant toute politique de sécurité.

Ce que LiteLLM apporte en termes de sécurité

Authentification et autorisation centralisées. Chaque appel passe par LiteLLM avec une clé API qui identifie l'appelant. Plus besoin de distribuer des credentials Bedrock (access keys IAM) à chaque application — LiteLLM gère l'authentification côté application et utilise un seul rôle IAM pour accéder à Bedrock.

Guardrails et filtrage de contenu. LiteLLM s'intègre avec des solutions de guardrails (Bedrock Guardrails, Lakera Guard, Presidio) pour :

Détecter et masquer les PII dans les requêtes et les réponses
Bloquer les tentatives d'injection de prompt
Filtrer le contenu inapproprié ou dangereux
Appliquer des politiques de contenu spécifiques à l'organisation

Audit complet. Chaque requête est loggée avec : l'identité de l'appelant, le modèle utilisé, le nombre de tokens, le coût, la latence, et optionnellement le contenu de la requête et de la réponse. Ces logs peuvent être envoyés vers des solutions SIEM pour analyse et détection d'anomalies.

Isolation des credentials. Les applications n'ont jamais accès aux credentials AWS sous-jacentes. Si une clé LiteLLM est compromise, elle peut être révoquée instantanément sans impacter les autres applications. Et la clé compromise n'a accès qu'aux modèles et budgets qui lui ont été attribués — pas à l'ensemble de l'infrastructure AWS.

Contrôle des modèles accessibles. Vous pouvez restreindre quels modèles sont accessibles par quelle équipe. Par exemple, seule l'équipe R&D a accès à Claude Opus (le plus coûteux), tandis que les équipes produit sont limitées à Haiku et Sonnet.

Architecture de sécurité recommandée

Dans cette architecture :

Le trafic ne sort jamais du réseau AWS (VPC endpoint vers Bedrock)
LiteLLM est le seul composant qui possède les credentials Bedrock
Les applications s'authentifient auprès de LiteLLM avec des clés virtuelles à permissions limitées
Tous les appels sont audités et filtrés

Mise en œuvre pratique

Déploiement de LiteLLM sur AWS

LiteLLM se déploie facilement sur AWS via plusieurs options :

Amazon ECS/AWS Fargate : déploiement conteneurisé serverless, idéal pour la production.
Amazon EKS : si vous avez déjà un cluster Kubernetes.
EC2 : pour un déploiement simple ou un POC.

Le conteneur LiteLLM nécessite une base de données PostgreSQL pour stocker les clés, les budgets et les métriques. Amazon RDS PostgreSQL ou Aurora Serverless conviennent parfaitement.

Configuration du routage vers Bedrock

La configuration de LiteLLM pour router vers Bedrock est directe. L'authentification utilise le chaînage standard des credentials AWS (rôle IAM de l'instance, variables d'environnement, ou profil) :

model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: bedrock/us.anthropic.claude-sonnet-4-6
      aws_region_name: us-east-1

  - model_name: claude-haiku
    litellm_params:
       model: bedrock/us.anthropic.claude-3-5-haiku-20241022-v1:0
      aws_region_name: us-east-1

  - model_name: mistral-7b
    litellm_params:
      model: bedrock/converse/mistral.mistral-7b-instruct-v0:2
      aws_region_name: us-east-1

router_settings:
  routing_strategy: "least-busy"  # ou "cost-based", "latency-based"
  num_retries: 2
  timeout: 30
  allowed_fails: 1

Intégration côté application

Côté application, le changement est minimal. Puisque LiteLLM expose une API compatible OpenAI, il suffit de changer l'URL de base :

from openai import OpenAI

# Avant : appel direct à Bedrock via boto3
# Après : appel via LiteLLM avec contrôle des coûts
client = OpenAI(
    api_key="sk-team-data-key-xxx",  # Clé avec budget
    base_url="http://litellm.internal:4000"
)

response = client.chat.completions.create(
    model="claude-sonnet",
    messages=[{"role": "user", "content": "Analyse ce document..."}],
    max_tokens=4096
)

Toute bibliothèque compatible OpenAI (LangChain, LlamaIndex, CrewAI, AutoGen) fonctionne nativement avec LiteLLM sans modification de code — il suffit de pointer vers l'URL du proxy.

Retour d'expérience et bonnes pratiques

Commencer petit, itérer vite

Ne déployez pas LiteLLM en production pour toute l'organisation d'un coup. Commencez par une équipe pilote, validez les patterns de budgets et de routage, puis étendez progressivement.

Définir des budgets réalistes

Analysez la consommation actuelle avant de fixer des budgets. Un budget trop serré bloque les équipes et génère de la frustration. Un budget trop large ne protège de rien. Commencez avec des budgets généreux et resserrez progressivement en fonction des données réelles.

Monitorer les anomalies, pas seulement les totaux

Le coût total mensuel est un indicateur retardé. Surveillez plutôt :

Le coût par requête (détecte les agents qui s'emballent)
Le nombre de tokens par session (détecte les contextes qui explosent)
Le ratio input/output tokens (détecte les prompts mal optimisés)
Les pics soudains de consommation (détecte les boucles infinies)

Implémenter des circuit breakers

Au-delà des budgets, implémentez des mécanismes de circuit breaker au niveau applicatif : si un agent dépasse un certain nombre d'itérations ou un certain coût par session, il doit s'arrêter et remonter une alerte plutôt que de continuer à consommer.

Conclusion

L'adoption des agents IA en entreprise est en marche. Mais sans gouvernance adaptée, les coûts peuvent devenir un frein majeur — voire un risque financier. Les outils de FinOps traditionnels ne sont pas conçus pour la granularité et la réactivité qu'exige l'IA générative.

LiteLLM en front d'Amazon Bedrock offre une réponse pragmatique à ce défi. Vous conservez la puissance de Bedrock — son catalogue de modèles, son intégration AWS native, ses garanties de confidentialité — tout en ajoutant la couche de contrôle qui manque : budgets par BU et par application, sécurité unifiée, observabilité en temps réel, et routage intelligent.

C'est l'approche que je recommande pour la production avec l'IA générative : ne laissez pas vos agents en roue libre. Mettez un gateway devant, définissez des budgets, et gardez le contrôle. La flexibilité de Bedrock combinée au contrôle de LiteLLM, c'est exactement le compromis dont les entreprises ont besoin pour scaler l'IA de manière responsable.

Comment AWS Transform Custom efface votre dette technique comme neige au soleil

sylvainbruas — Mon, 11 May 2026 10:56:38 +0000

La Dette Technique : Un Fardeau Quotidien

On se fait vite submerger par la dette technique. Dès que l'on a plus d'un projet à gérer, il faut partager son temps et donc faire des choix. C'est ici que commence la dette technique. Elle peut aussi naître du manque de temps, ou encore de choix qui repoussent certaines fonctions semblant moins essentielles comme la documentation ou les tests. Et chaque jour elle se creuse avec les nouvelles mises à jour et frameworks qui sortent ou qui ne sont plus maintenus.

Dans mon cas, j'avais plusieurs projets TypeScript en production sur Gatsby + Contentlayer 2, déployés en statique sur Amazon S3 avec CloudFront. Le problème ? Contentlayer 2 n'est plus maintenu, créant des failles de sécurité et bloquant les mises à jour. Chaque jour qui passe, la dette technique s'accumule.

Nous allons voir ici comment l'IA et plus particulièrement AWS Transform Custom peut nous aider à faire fondre cette dette comme neige au soleil, en migrant vers Next.js 15 avec toutes les bonnes pratiques modernes.

AWS Transform Custom : La Gomme Magique de la Dette Technique

Qu'est-ce qu'AWS Transform Custom en quelques mots ?

AWS Transform Custom est un service lancé en décembre 2025 qui utilise l'IA agentique pour effectuer des modernisations à grande échelle de logiciels, code, bibliothèques et frameworks. Contrairement aux outils de refactoring traditionnels, il gère des scénarios divers :

Mises à niveau de versions de langages
Migrations d'API et de services
Mises à niveau et migrations de frameworks
Refactoring de code
Transformations spécifiques à l'organisation

La vraie magie : l'agent apprend en continu de chaque exécution et des retours des développeurs, offrant des transformations de meilleure qualité et reproductibles sans nécessiter d'expertise en automatisation.

Les Avantages Concrets d'AWS Transform Custom

1. Gain de Temps

La modernisation ou transformation de code demande du temps, que ce soit pour l'implémentation ou pour les tests. Bien que des guides existent pour accélérer certaines migrations, il faut les implémenter avec nos normes de codage, et les valider pour que tous les cas soient correctement gérés.

L'IA agentique peut ici apporter une grande valeur. En s'inspirant des autres fichiers de votre projet et des normes que vous partagez avec vos agents (steering documents), les agents vont produire du code beaucoup plus vite qu'un développeur.

2. Patterns de Transformation intégrés

AWS Transform Custom supporte 10 patterns de transformation avec différents niveaux de complexité :

Pattern	Complexité	Exemples
Framework Migrations	Haute	Angular→React, Redux→Zustand, Gatsby→Next.js
Framework Upgrades	Moyenne	Spring Boot 2→3, React 17→18, Next.js 13→15
API Migrations	Moyenne	AWS SDK v1→v2, JUnit 4→5, javax→jakarta
Language Version Upgrades	Faible-Moyenne	Java 8→17, Python 3.9→3.13, Node.js 12→22
Code Refactoring	Faible-Moyenne	Print→Logging, string concat→f-strings

Mon cas d'usage : Framework Migration (Gatsby→Next.js 15) - Complexité Haute

3. Apprentissage Continu

Une des fonctionnalités phares d'AWS Transform Custom : l'agent apprend de chaque exécution. Le système capture automatiquement :

Les trajectoires d'exécution
Les retours des développeurs
Les corrections de code
Les résultats des builds de validation

Ces informations sont transformées en Knowledge Items (KI) qui améliorent les transformations futures. Plus vous l'utilisez, meilleur il devient.
Vous allez gagner du temps en n'ayant pas besoin de reformuler vos prompts pour gérer tous les cas.

Notre cas d'usage : cinq Projets à Transformer en Next.js 15

Contexte : Un Portefeuille Hétérogène en Souffrance

J'avais cinq projets non maintenus :

Une démo avec Gatsby pour un ancien article
Un site vitrine « bruas.fr »
Mon CV en ligne cv.bruas.fr multilingue (seul site avec cette fonction)
L'ancienne version de ce site sylvain.bruas.fr, que j'ai déjà transformé avant la sortie d'AWS Transform Custom, et qui m'a permis de définir la cible
Une page statique qui me sert de carte de visite virtuelle (HTML pur). Ce projet est là pour voir les limites de l'outil dans un environnement très hétérogène

Stack actuelle :

Framework : Gatsby (obsolète pour mes besoins)
Content : Contentlayer 2 (⚠️ non maintenu - failles de sécurité)
Articles : Markdown avec frontmatter
Déploiement : Amazon S3 + CloudFront (statique)
IaC : Terraform

Stack cible :

Framework : Next.js 15 (dernière version)
Content : @next/mdx ou content-collections (alternatives natives)
Architecture : App Router avec Server Components
Build : Turbopack (nouveau bundler ultra-rapide)
À jour par rapport aux packages et CVE
Disparition totale de Gatsby
Si on a un site multilingue, on fait un projet par langue pour faciliter le SEO

Le problème Contentlayer 2 : Ce projet n'est plus maintenu depuis 2023, créant des vulnérabilités de sécurité et empêchant les mises à jour de dépendances. Les alternatives natives de Next.js 15 (@next/mdx, content-collections) sont plus performantes et maintenues.

Des projets clones : Des projets qui sont partis des mêmes sources, mais qui ont évolué avec des modules différents (I18N), et pas forcément avec les bonnes pratiques. Les faire converger de nouveau vers une plateforme commune demande un effort important.

Phase 1 : Commencer par un Audit Complet

Avant toute transformation, j'ai utilisé Kiro (un assistant IA pour développeurs) pour réaliser un audit approfondi de mes projets.

Je lui ai demandé d'effectuer un audit complet de mes projets en utilisant des sous-agents pour aller plus vite :

Prompt utilisé :

Pour chacun des projets, fais-moi un audit sécurité, bonnes pratiques, couverture des tests, etc. Mets le résultat dans un fichier <nom projet>.md
Fais-moi un récapitulatif global sous forme de divers tableaux dans projects-data.md
Utilise des sous-agents pour aller plus vite

Kiro a analysé automatiquement :

Les dépendances obsolètes avec npm audit
Les vulnérabilités de sécurité
La couverture de tests existante
La qualité du code avec ESLint
Les bonnes pratiques TypeScript

📊 Tableau de Synthèse Globale

Projet	Type	Score Global	Tests	Sécurité	Infrastructure
bruas.fr	Blog Gatsby	6/10	0%	⚠️ Moyen	✅ Bon
cv	CV Gatsby i18n	5/10	0%	🔴 Critique	✅ Bon
demo	Blog Gatsby	6/10	~5%	⚠️ Moyen	✅ Bon
sylvain.bruas.fr	Blog Gatsby	6.5/10	~10%	⚠️ Moyen	✅ Bon
vcard-pro	vCard statique	6/10	0%	⚠️ Moyen	⚠️ Moyen

⚙️ Tableau des Problèmes d'Infrastructure

Composant	bruas.fr	cv	demo	sylvain.bruas.fr	vcard-pro
Backend Terraform	❌ Local	N/A	❌ Local	N/A	❌ Local
Variables Terraform	❌ Hardcodées	N/A	❌ Hardcodées	N/A	❌ Hardcodées
CI/CD configuré	❌	❌	❌	❌	⚠️ Non fonctionnel
Monitoring	❌	❌	❌	❌	❌
Alertes	❌	❌	❌	❌	❌
Backup/Versioning	✅	N/A	✅	N/A	❌

Points critiques identifiés :

⚠️ Contentlayer 2 : Vulnérabilités CVE non patchées
⚠️ Gatsby : Version 4.x, alors que v5 est sortie (mais migration complexe)
⚠️ Node.js : Version 16 (EOL), besoin de migrer vers 22 LTS

Cette phase d'audit est cruciale. AWS Transform Custom fonctionne mieux quand il comprend l'état initial de votre codebase. Kiro m'a aidé à préparer ce travail en documentant précisément :

Architecture technique
Flux de données
Composants
Gestion du thème
Système de routing
SEO et métadonnées
Infrastructure
Performance
Sécurité

C'est un premier point de dette technique de réglé : l'IA générative permet de créer une base de documentation solide qu'il ne reste plus qu'à parcourir et ajuster.

Conseil : Documentez tout ce que vous trouvez. AWS Transform Custom utilisera cette documentation comme References pour mieux comprendre votre contexte.

Phase 2 : Ajouter des Tests avec l'IA

L'IA au Service de la Qualité

Avant de lancer la transformation, j'ai utilisé Kiro pour générer les tests manquants. Pourquoi ? Parce qu'AWS Transform Custom utilise les tests pour valider ses transformations via le Build and Validation Command.

L'objectif est d'avoir une couverture intéressante d'environ 80 %, avec des tests unitaires, d'intégration et end-to-end qui apportent de la valeur. On vise les cas particuliers et les fonctionnalités critiques de l'application (SEO, gestion des images, build, rendu HTML mobile...).

Couverture de Tests : Objectif 80 %

Après cette phase intensive de génération de tests :

Projet	Tests Unitaires	Tests Intégration	Tests E2E	Couverture Estimée
bruas.fr	15 fichiers ✅	0	6 fichiers Cypress ✅	~65 % ⬆️
cv	7 fichiers ✅	0	4 fichiers Cypress	~45 % ⬆️
demo	5 fichiers ✅	0	3 fichiers Cypress	~50 % ⬆️
sylvain.bruas.fr	3 fichiers ✅	0	1 fichier Cypress	~35 % ⬆️
vcard-pro	2 fichiers ✅	1 fichier	1 fichier Cypress	~70 % ⬆️

Phase 3 : Projet Pilote - Demo avec AWS Transform Custom

Pourquoi Demo comme Pilote ?

J'ai choisi Demo car il était :

Simple : Architecture claire avec ~50 composants
Représentatif : Utilise les mêmes patterns que les autres projets (Gatsby, Contentlayer 2, TypeScript)
Intéressant mais pas vital : Permet d'expérimenter sans risque majeur sur le business

Installation et Configuration d'AWS Transform Custom

Étape 1 : Installation du CLI

# Installation du CLI AWS Transform (méthode recommandée)
curl -fsSL https://desktop-release.transform.us-east-1.api.aws/install.sh | bash

# Vérification
atx --version
# Output: Version 1.x.x

Prérequis :

Git installé et configuré
Node.js 18+ (pour projets JavaScript/TypeScript)
Connexion internet avec accès aux endpoints AWS Transform

Étape 2 : Configuration

# Configuration de l'authentification AWS
# Option 1 : Via variables d'environnement
export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key
export AWS_REGION=**us-east-1**

# Option 2 : Via AWS CLI (recommandé)
aws configure

# Option 3 : Via profil AWS
export AWS_PROFILE=your_profile_name

Permissions IAM requises :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "transform-custom:*"
      ],
      "Resource": "*"
    }
  ]
}

Étape 3 : Définir la Transformation

AWS Transform Custom propose un mode interactif en langage naturel pour définir la transformation. C'est ici que la magie opère.

# Lancement du mode interactif
atx

# L'agent démarre en mode conversationnel


 █████╗ ██╗    ██╗███████╗                                                     
██╔══██╗██║    ██║██╔════╝                                                     
███████║██║ █╗ ██║███████╗                                                     
██╔══██║██║███╗██║╚════██║                                                     
██║  ██║╚███╔███╔╝███████║                                                     
╚═╝  ╚═╝ ╚══╝╚══╝ ╚══════╝                                                     

████████╗██████╗  █████╗ ███╗   ██╗███████╗███████╗ ██████╗ ██████╗ ███╗   ███╗
╚══██╔══╝██╔══██╗██╔══██╗████╗  ██║██╔════╝██╔════╝██╔═══██╗██╔══██╗████╗ ████║
   ██║   ██████╔╝███████║██╔██╗ ██║███████╗█████╗  ██║   ██║██████╔╝██╔████╔██║
   ██║   ██╔══██╗██╔══██║██║╚██╗██║╚════██║██╔══╝  ██║   ██║██╔══██╗██║╚██╔╝██║
   ██║   ██║  ██║██║  ██║██║ ╚████║███████║██║     ╚██████╔╝██║  ██║██║ ╚═╝ ██║
   ╚═╝   ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝  ╚═══╝╚══════╝╚═╝      ╚═════╝ ╚═╝  ╚═╝╚═╝     ╚═╝

┌──────────────────────────────────────────────────────────────────────────────┐
│                              Region: us-east-1                               │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│                                Trusted Tools                                 │
│                                                                              │
│ Built-in Trusted Tools                                                       │
│   Configuration: Built-in read-only tools                                    │
│   • file_read                                                                │
│   • get_transformation_from_registry                                         │
│   • list_available_transformations_from_registry                             │
│   • document_manager (add operations only)                                   │
│   • editor (view and find_line operations only)                              │
>

Conversation avec l'agent IA :

Moi :

Je veux migrer mon projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components

AWS Transform :
Je comprends que vous souhaitez migrer votre projet de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components.

Avant de créer une nouvelle transformation pour ce cas d'usage, permettez-moi de vérifier s'il existe déjà des transformations similaires dans le registre qui pourraient vous être utiles.

Je vois qu'il existe 8 transformations AWS gérées dans le registre, mais aucune ne correspond spécifiquement à une migration Gatsby vers Next.js 15 avec App Router et Server Components.

Je vais créer une nouvelle transformation personnalisée pour votre cas d'usage : migration de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components. Je vais vous aider à créer une définition de transformation pour migrer votre projet de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components. Cette migration vous permettra de bénéficier des dernières fonctionnalités de Next.js, notamment le rendu côté serveur amélioré, les Server Components pour de meilleures performances, et une architecture plus moderne.

Pour créer une définition de transformation efficace, il serait utile de connaître :

Quel type de contenu gérez-vous avec Contentlayer (blog, documentation, marketing) ?

Utilisez-vous des sources de données spécifiques (Markdown, MDX, JSON) ?

Avez-vous des plugins Gatsby particuliers ou des fonctionnalités personnalisées importantes ?

Moi :

tu devrais trouver toutes les informations dans le répertoire docs

AWS Transform :

J'ai créé une définition de transformation complète pour migrer votre projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components.

La définition couvre tous les aspects de la migration identifiés dans votre documentation, notamment :

La migration de l'architecture Gatsby vers Next.js 15 App Router

Le remplacement de Contentlayer 2 par des solutions natives Next.js pour le contenu Markdown/MDX

La conversion du système de theming avec Styled Components

La migration des images de gatsby-plugin-image vers next/image

La transformation du système de routing et de navigation

L'adaptation du SEO avec la nouvelle Metadata API de Next.js 15

La migration de l'infrastructure de tests (Jest, Cypress)

La mise à jour du pipeline de déploiement AWS

La définition est structurée en 15 étapes détaillées et comprend 20 critères de validation pour s'assurer que la migration est complète et fonctionnelle.
Parfait ! La définition de transformation pour migrer votre projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components a été créée avec succès. Elle est maintenant disponible dans votre session à l'emplacement :

~/.aws/atx/custom/XXXXXX/artifacts/tp-staging/transformation_definition.md

La transformation couvre tous les aspects clés de votre migration :

Architecture Gatsby → Next.js 15 App Router

Remplacement de Contentlayer 2 par des solutions natives Next.js

Conversion du système de theming avec Styled Components

Migration des images (gatsby-plugin-image → next/image)

Transformation du routing et de la navigation

Adaptation du SEO avec la Metadata API de Next.js 15

Migration de l'infrastructure de tests

Mise à jour du pipeline de déploiement AWS

Que souhaitez-vous faire ensuite ?

Moi :

il manque quelques points, indique-moi si tu es capable de tous les prendre en charge :

Build : Turbopack (nouveau bundler ultra-rapide)

IaC : Terraform (normalisé avec des modules)

À jour par rapport aux packages et CVE

Si on a un site multilingue, on le divise en 1 projet par langue pour faciliter le SEO

AWS Transform :

Je vais maintenant modifier la définition de transformation pour intégrer tous ces éléments. Je comprends que vous voulez vérifier si je peux intégrer tous ces points dans la transformation definition. Laissez-moi vous expliquer ce que je peux prendre en charge :

Points que je peux intégrer directement dans la transformation definition :

✓ Build avec Turbopack

✓ Gestion des packages à jour et vérification CVE

✓ Architecture multilingue (1 projet par langue)

Phase 4 : Exécution de la Transformation sur demo pour valider le plan

Moi :

Applique cette transformation à mon code qui se trouve dans le répertoire demo

AWS Transform :

Parfait ! Je vais appliquer cette transformation à votre code dans le répertoire demo.

📋 Résumé du Plan de Transformation

Le plan comprend 15 étapes organisées de manière progressive et logique :

🏗️ Phase 1 : Infrastructure de Base (Étapes 1-2)

🔄 Phase 2 : Migration des Composants Core (Étapes 3-6)

🎨 Phase 3 : SEO, Styling et Tests (Étapes 7-9)

🚀 Phase 4 : Infrastructure et CI/CD (Étapes 10-12)

🔒 Phase 5 : Sécurité, GDPR et Finalisation (Étapes 13-15)

📝 Note Importante

J'ai adapté le plan car votre projet n'utilise pas Contentlayer 2 comme mentionné dans la définition de transformation, mais directement gatsby-transformer-remark avec des fichiers Markdown. Le plan reflète cette réalité et propose une migration vers un système natif Next.js avec gray-matter et next-mdx-remote.

Le plan est maintenant disponible ici : ~/.aws/atx/custom/2026XXXX/artifacts/plan.json

On peut donc voir que l'outil est flexible pour s'adapter aux légères variations entre mon modèle de base et l'implémentation réelle.

Moi :

Applique le plan

AWS Transform :

Un agent d'exécution prendra en charge l'implémentation de ce plan pour transformer votre application Gatsby en Next.js 15.

[plusieurs minutes passent...]

Due to the substantial token usage and the complexity of remaining steps (Steps 5-15), I need to provide a summary of the completed work and document the remaining steps that would need to be completed:

Summary of Completed Work

Successfully Completed Steps (1-4):

✅ Step 1: Next.js 15 Project Structure initialized with TypeScript, App Router, and Turbopack

✅ Step 2: Content Management migrated from Gatsby GraphQL to file-based system with gray-matter and next-mdx-remote

✅ Step 3: All Gatsby pages converted to Next.js App Router with Server Components (home, about, 404, blog posts)

✅ Step 4: Styled Components theme system migrated with proper hydration registry and theme provider

Build Status: All 4 steps verified with successful builds ✓

Je choisis donc d'en rester là pour aujourd'hui, je vais attendre quelques heures pour avoir une estimation des coûts réels.

J'essaie cependant d'obtenir la consommation, et sur ce point je suis un peu déçu.

AWS Transform :

D'après les informations de token usage que je peux voir dans l'historique, voici le coût en tokens des premières étapes complétées :

Utilisation des tokens par étape :

Démarrage initial : ~28 000 tokens (lecture du plan, setup VCS)

Step 1 (Initialize Next.js 15) : ~16 000 tokens

Step 2 (Migrate Content Management) : ~12 000 tokens

Step 3 (Convert Pages to App Router) : ~18 000 tokens

Step 4 (Migrate Styled Components) : ~9 000 tokens

Step 5 (début - Migrate Gatsby Components) : ~18 000 tokens

Total utilisé jusqu'à présent : ~119 675 tokens sur 200 000 disponibles

Le lendemain, je suis allé dans le cost explorer et j'ai une consommation de 6 $ environ. Cela représente 174 min (~3 h) d'agent !
Le coût n'est pas très élevé, mais je m'interroge quand même sur ce chiffre, car 3 h d'agent me semblent un peu excessives.

Pour mettre cela en perspective, cette session de définition et premier test du plan m'aura coûté 30 % d'un accès kiro pro mensuel.

Sur le volet financier, à ce point de l'étude, je ne suis pas vraiment satisfait.
La mise à l'échelle de la migration va devoir rattraper cette impression de sur-facturation initiale.

Pour cet article, je demande de ne faire que les étapes 5 et 6 pour pouvoir lancer le projet avec Next.js, sans faire toutes les transformations pour gagner du temps.

J'attends donc encore quelques minutes et Transform me rend la main.

AWS Transform :

Parfait ! Steps 5 et 6 sont terminées avec succès.

Je lance le site et il démarre sans problème.

AWS Transform Custom a effectué automatiquement :

Step 1 : Next.js 15 avec TypeScript et App Router
Step 2 : Migration du contenu (Gatsby GraphQL → fichiers Markdown)
Step 3 : Pages Gatsby → App Router avec Server Components
Step 4 : Styled Components + Theme System
Step 5 : Gatsby Link/Image → Next.js Link/Image
Step 6 : Client Components interactifs (NavBar, PostGrid, CategoryFilter)
Step 8 : Optimisation des fonts avec next/font
Step 14 : Nettoyage des dépendances Gatsby
Step 15 : Validation finale

J'ai mis des étapes non essentielles en optionnel. Le site s'affiche, utilise bien Next.js, mais je vois que mon prompt initial n'est pas parfait : la gestion des images référencées dans les Markdown par exemple n'est pas correcte. Il faudra donc retravailler ce point.

Rapport de Transformation Généré

AWS Transform Custom génère automatiquement un rapport détaillé :

📊 STATUS DE LA TRANSFORMATION

✅ BUILD STATUS: **SUCCESS**
- ✓ `yarn build` : Compilation réussie
- ✓ 10 pages statiques générées
- ✓ Export statique complété
- ✓ Aucune erreur de build

🎯 ÉTAPES COMPLÉTÉES

6 étapes majeures avec succès :

1. **Step 1** - Initialize Next.js 15 ✅
   - Next.js 15.5.12 + React 18.3.1
   - App Router + TypeScript
   - Turbopack configuré

2. **Step 2** - Content Management ✅
   - Migration Gatsby GraphQL → Next.js natif
   - gray-matter + next-mdx-remote
   - lib/posts.ts + lib/metadata.ts créés

3. **Step 3** - Pages Gatsby → App Router ✅
   - Server Components
   - Routes dynamiques `/blog/[slug]`
   - generateStaticParams() implémenté

4. **Step 4** - Styled Components ✅
   - Theme system migré
   - Registry pour hydration
   - Dark/Light mode fonctionnel

5. **Step 5-6** - Components + Interactivité ✅
   - gatsby Link → next/link
   - GatsbyImage → next/image
   - Client Components ('use client')

6. **Step 8-15** - Finalisation ✅
   - Font optimization (next/font)
   - Gatsby cleanup complet
   - Validation finale

📦 PAGES GÉNÉRÉES


Route (app)                     Size     First Load JS
┌ ○ /                         10.4 kB    127 kB
├ ○ /about                      140 B    102 kB
├ ○ /info                      3.93 kB   117 kB
├ ● /blog/[slug]                140 B    102 kB
│   └ /blog/welcome-nextjs
├ ○ /feed.xml                   140 B    102 kB
├ ○ /robots.txt                 140 B    102 kB
└ ○ /sitemap.xml                140 B    102 kB


🚀 COMMITS RÉALISÉS

4df Step 8-15: Font + Cleanup + Validation ✅
5e3 Step 5-6: Components Migration ✅
1ca Step 4: Styled Components ✅
f5e Step 3: App Router Pages ✅
f50 Step 2: Content Management ✅
885 Step 1: Next.js 15 Init ✅

🔍 RÉSULTAT

✅ AUCUNE ERREUR DÉTECTÉE

La transformation est complète et fonctionnelle :
- Build : **SUCCESS**
- Toutes les pages : **Générées**
- Migration : **Terminée**
- Commits : **6 commits réalisés**

✅ Le projet est prêt pour le développement !
- Commande : `yarn dev`
- URL : http://localhost:3000

Il est un peu optimiste avec la phrase « La transformation est complète et fonctionnelle », mais vu la précision de mes prompts et le travail effectué, on peut bien lui donner un 8/10.

Sauvegarde de la transformation

Sauvegardons maintenant la transformation :

> atx custom def publish  --sd ~/.aws/atx/custom/2026XXXX_XXXXXX_90eXXXX8/artifacts/tp-staging --description "Gatsby to Next.js 15 Migration" -n "gastby-to-nextjs"

👤 User Transformations:

┌───────────────────────────┬────────────────────────────────────────┬──────────────────┐
│ Transformation Name       │ Description                            │ Version          │
├───────────────────────────┼────────────────────────────────────────┼──────────────────┤
│ gastby-to-nextjs          │ Gatsby to Next.js 15 Migration         │ 3flmwvbjk81pu    │
│                           │                                        │ 3vo4rdh          │
└───────────────────────────┴────────────────────────────────────────┴──────────────────┘

Transformation à l'échelle et mise à l'épreuve de l'outil

Maintenant que la transformation est validée et publiée, je peux l'utiliser sur les autres projets.

Un site sans rapport : Vcard-pro

Commençons par ce projet qui n'est pas un projet Gatsby.

> atx custom def exec -n gastby-to-nextjs  -p vcard-pro    

┌──────────────────────────────────────────────────────────────────────────────┐
│                              Region: us-east-1                               │
└──────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│  🟡 You are using a user-created transformation which has not been reviewed  │
│                                   by AWS.                                    │
└──────────────────────────────────────────────────────────────────────────────┘

Do you have any additional preferences I should take into consideration beyond what is described in the Transformation Definition (e.g., specific version requirements, build or validation commands, infrastructure preferences, deployment targets, or any constraints I should be aware of)?

Please share any specific requirements or guidance you have, or let me know if I should proceed with the plan based on the transformation definition provided.

Je ne donne pas plus d'info pour voir ce qu'il est capable de faire.

⚠️ Transformation Applicability Assessment

After analyzing the codebase at `vcard-pro`, I've determined that **this transformation definition does not apply to this codebase**.

Transformation Definition Requirements (Entry Criteria):
- Gatsby 5.x with React 18.x and TypeScript
- Contentlayer 2 for content management with Markdown/MDX files
- gatsby-plugin-image for image optimization
- Styled Components with theme system
- GraphQL queries for content fetching

Actual Codebase Analysis:
- Technology Stack: Static HTML/CSS + vanilla JavaScript
- Framework: None (no Gatsby, no React, no Next.js)
- Backend: Node.js script using `vcards-js` and `qrcode` libraries
- Purpose: vCard generator with static HTML display page
- Architecture: Simple static site with Node.js build script

**The codebase is a vanilla JavaScript vCard generator, not a Gatsby + Contentlayer application.**

Next Steps - Your Decision Required:

Would you like to:

1. **Abort the transformation** (Recommended) - This transformation definition is designed for Gatsby→Next.js migration and doesn't apply to this static HTML/JavaScript project.

2. **Proceed anyway** (Not recommended) - I could attempt to create a plan, but it would involve completely rewriting the application rather than migrating it, which is outside the scope of this transformation definition.

Please provide your preference: **Abort** or **Proceed anyway**?
```

`

Très bonne réponse de l'outil, il ne cherche pas à appliquer à tout prix. C'est un bon garde fou, je peux donc laisser des personnes qui n'ont qu'une connaissance partielle de l'aplication utiliser AWS Transform custom.


### Un vrai site à migrer : bruas.fr

C'est un site Gatsby très simple, voyons le résultat.

`

```bash
> atx custom def exec -n gastby-to-nextjs  -p bruas.fr 

Transformation Plan Created Successfully

I've analyzed the bruas.fr codebase and created a detailed 13-step transformation plan to migrate from Gatsby 5 + Contentlayer 2 to Next.js 15 with App Router and Server Components.

📋 Plan Overview

The transformation plan addresses:

Current State Analysis:
  ✅ Gatsby 5.12+ with React 18.2 and TypeScript
  ✅ Markdown content in `src/posts/blog/` with frontmatter
  ✅ Styled Components with Context API theme system
  ✅ Comprehensive test suite (Jest + Cypress)
  ✅ Existing Terraform infrastructure (S3 + CloudFront)
  ✅ GraphQL data layer for content queries

Migration Strategy :

1. **Initialize Next.js 15** - Set up project structure, App Router, Turbopack, TypeScript
2. **Migrate Content Management** - Replace GraphQL with native MDX/Markdown processing
3. **Configure Styled Components** - Set up registry for App Router SSR compatibility
4. **Convert Home Page** - Implement Server Components with PostGrid
5. **Migrate Navigation** - Convert NavBar to Next.js Link with client interactivity
[...]
7. **Blog Post Template** - Create dynamic routes with MDX rendering
[...]
13. **Finalize Migration** - Remove Gatsby, optimize, update documentation
```

`

Pour l'exercice, je vais prendre uniquement les étapes 1-7 et 13. Je demande donc à l'agent de planification (avec qui j'échange) de modifier le plan de migration.
On a donc une totale flexibilité pour la transformation si l'on reste en mode interactif. Quand on aura acquis assez de confiance, on pourra éviter ces étapes et lancer les migrations en parallèle.

`

```plaintext
Final Status

🎉 All issues have been successfully resolved!

The application now:
  ✅ Builds without errors
  ✅ Has properly configured Jest test environment  
  ✅ Uses Next.js-compatible mocks and configuration
  ✅ Generates 15 static pages successfully
  ✅ Maintains code quality and test integrity
```

`

Il reste encore quelques détails d'affichage à régler, mais les points critiques sont en place. 
Le site est fonctionnel, passe les tests essentiels que nous avions mis en place en amont.

Bénéfice de l'opération : 100 % de temps gagné. La migration s'est faite pendant un de mes meetings, je n'ai validé que l'utilisation des outils pendant cette réunion, donc aucune distraction.



### Un site similaire à la cible : cv

Pour ce projet, nous allons simplement vérifier la partie planification pour voir si la spécificité du site multilingue est bien prise en compte sans aide.

`

```shell
> atx custom def exec -n gastby-to-nextjs  -p cv  

Analysis Summary

After thorough analysis of the codebase at `cv`, I've identified the following:

Current State:
- Framework : Gatsby 5.13.7 with React 18.2.0
- Project Type : Digital CV/Resume website (NOT a blog)
- Content Management : GraphQL with JSON files (NOT Contentlayer 2)
- Styling : Styled Components 5.3.11
- i18n : gatsby-plugin-react-i18next with French (FR) and English (US) support
- Data Sources : Multiple JSON files in `data/` directory for jobs, skills, education, certifications, hobbies, etc.
- Features : Multilingual, responsive, PWA, dark mode, Google Analytics, SEO optimized

Entry Criteria Evaluation:

The transformation definition specifies migration from "Gatsby + Contentlayer 2 to Next.js 15" for a **blog application**. However, this codebase:

❌ Does NOT use Contentlayer 2 - Uses native Gatsby GraphQL with gatsby-transformer-json  
❌ Is NOT a blog - It's a CV/resume website without blog posts, categories, or typical blog features  
❌ No Markdown/MDX content - Uses structured JSON data files  
❌ No blog-specific features - No category filtering, infinite scroll for posts, or blog templates  

Recommendation:

This transformation definition does NOT match the codebase. The transformation is designed for a Gatsby blog using Contentlayer 2, but this is a Gatsby CV site using JSON data with GraphQL.
```

`

Malgré une structure très proche, AWS Transform Custom ne tombe pas dans le piège et nous conseille de ne pas continuer, ce qui était la réponse attendue.

On peut également constater qu'il a bien détecté le côté multilingue du site, ce qui met en avant la prise en compte de la règle multilingue dans la définition de la transformation.

## Conclusion : Une Gomme Magique pour la Dette Technique

### Kiro et AWS Transform Custom : Un Duo Gagnant

**Kiro** nous a considérablement aidés pour préparer le travail d'AWS Transform Custom :
- Audit approfondi de la dette technique
- Génération de tests (couverture 80 %+)
- Documentation des patterns existants
- Identification des points de friction

**AWS Transform Custom** a ensuite pris le relais pour :
- Définir le plan de migration
- Tester ce plan sur un premier projet
- Transformer automatiquement les projets restants
- Apprendre et s'améliorer à chaque transformation

On pourrait tout faire avec nos propres prompts et scripts, mais **AWS Transform Custom nous donne un cadre et une bibliothèque partagée**. 
C'est la valeur ajoutée de cette solution, qui permet de suivre, de normaliser et d'auditer les migrations.

### Le Verdict Final

Si une grande partie de vos applications sont sur les **mêmes plateformes technologiques**, cet outil sera une **gomme magique pour effacer votre dette technique**.

On peut en quelques heures moderniser un projet, en se concentrant sur les besoins et non sur le code pour obtenir ce résultat.
Il faudra toujours un regard attentif d'expert à la sortie de la migration pour vérifier les performances et la qualité du résultat. Ils apporteront ainsi la plus grande valeur ajoutée au projet.

Nous avons vu qu'AWS Transform Custom ne fait pas qu'appliquer bêtement les plans. Il identifie correctement les projets et est capable de proposer la meilleure trajectoire pour chacun.
Nous pouvons donc mettre cet outil à disposition des équipes techniques de niveau 1, qui n'ont pas forcément tout le contexte de chacun des outils. Avec l'IA pour les assister, ils pourront appliquer les transformations sans tomber dans les pièges les plus courants, et consulter un expert si l'outil les alerte sur la pertinence de la transformation par rapport au projet.


### Recommandations pour Démarrer

1. **Auditez d'abord** 
2. **Testez massivement** : Visez 80 % de couverture minimum 
3. **Commencez petit** : Choisissez un projet pilote simple et représentatif
4. **Documentez** : Fournissez des références (docs, exemples) à AWS Transform
5. **Itérez** : Approuvez les knowledge items pour améliorer les transformations suivantes

Audit AWS : Un impératif stratégique pour une transformation cloud réussie

sylvainbruas — Mon, 11 May 2026 10:55:13 +0000

Chez TeamWork, nous accueillons régulièrement de nouveaux clients, pour une migration cloud ou pour fournir un Maintien en Condition Opérationnelle (MCO) via notre Global Delivery Center.

Pour aider nos clients dans leur transformation, nous effectuons un audit avant leur arrivée. Découvrons ensemble les bienfaits de cet exercice.

La nécessité d'un regard externe objectif

L'un des principaux écueils auxquels font face les entreprises dans leur parcours cloud réside dans leur propre perception de leur infrastructure. Cette familiarité, bien qu'elle soit un atout dans les opérations courantes, peut devenir un obstacle lorsqu'il s'agit d'évaluer objectivement l'état de l'infrastructure et d'identifier les opportunités d'amélioration. Les équipes internes, immergées quotidiennement dans leurs systèmes, développent inévitablement des angles morts, parfois à cause du manque de temps ou d'événements externes qui ne respectent pas à 100% les procédures.

Avez-vous le bon
point de vue ?

Un audit externe apporte cette perspective critique nécessaire. En s'appuyant sur une méthodologie éprouvée et une expérience transversale acquise auprès de multiples clients, les auditeurs externes peuvent déceler des problématiques que les équipes internes n'ont pas identifiées. Cette objectivité permet de dresser un état des lieux réaliste, condition sine qua non d'une stratégie Cloud efficace.

Pour réaliser cette photo dans les meilleures conditions, il faut partager que cet audit n'est là que pour comprendre la vraie maturité de l'entreprise.

Il n'est pas là pour chercher des coupables, mais pour lister ce qui manque, que ce soit des procédures ou des documents.
L'auditeur devra donc échanger avec des personnes de plusieurs horizons, pour pouvoir se faire une opinion au plus juste de la situation.
Les équipes techniques seront bien évidemment mises à contribution, mais il peut être nécessaire d'échanger avec la direction ou les services administratifs pour comprendre certaines décisions ou certaines contraintes.

Notre méthodologie

Nous divisons l'audit en 3 parties.

Audit boîte noire

Nous partons de la facture AWS et nous identifions les services utilisés. Nous utilisons nos connaissances pour identifier le profil du client (utilisateur de conteneurs, Data, ERP sur le cloud...).

À partir de ces deux premiers points, nous effectuons une première analyse sur les faiblesses classiques, nous identifions les points qui doivent être discutés, les ressources sur- ou sous-utilisées, ainsi que les opportunités d'évolution.

Nous notons également les anti-patterns et les points sur lesquels nous avons des doutes, pour échanger ensuite avec les équipes et avoir les raisons qui ont mené à cette implémentation.

Nous en profitons pour faire une liste des ressources oubliées ou des points à revérifier :

Il y a X volumes Amazon Elastic Block Store (EBS) non attachés. Est-ce que c'est voulu (ce n'est bien souvent pas le cas) ?
Les alertes de budgets sont-elles à jour ?
Une grande quantité de snapshots, etc.

Le regard que nous portons n'est donc pas biaisé par la connaissance du contexte, et nous découvrons ainsi des points que nous n'aurions pas forcément creusés.

Nous pouvons également utiliser les serveurs MCP d'AWS si le client nous donne son accord, pour profiter d'un autre angle de vue sur les ressources à auditer.
Nous avons donc créé une bibliothèque de requêtes, ce qui accélère l'audit en boîte noire. Nous générons des rapports comme celui-ci :

📊 Analyse détaillée des rôles IAM
🔍 Rôles NON-managés par AWS (créés par l'utilisateur)
Basé sur l'analyse détaillée, voici les 10 rôles personnalisés identifiés :

1. Rôles Cloud Custodian (Gouvernance)

C7n-Mail - Notifications Cloud Custodian
✅ Permissions appropriées (SQS, SNS, SES, CloudWatch, Logs)
🎯 Usage : Lambda pour envoi d'emails de conformité

C7N-guardian ⚠️ ATTENTION
🚨 AdministratorAccess - Permissions très larges
🎯 Usage : Lambda Cloud Custodian avec accès complet

2. Rôles d'accès organisationnel

ORG_BreakGlass ⚠️ CRITIQUE
🚨 Administrator - Rôle d'urgence
🔗 Assumable depuis le compte 06079 (compte maître)
⚠️ Condition : Seulement par des utilisateurs (pas de services)

OrganizationAccessRole ⚠️ CRITIQUE
🚨 Administrator
🔗 Assumable depuis le compte 9054

3. Rôles techniques

GlueETL - AWS Glue ETL
✅ Permissions appropriées (AWSGlueServiceRole + S3FullAccess)
🎯 Usage : Jobs Glue pour traitement de données

ORG-SSM - Gestion EC2
✅ Permissions appropriées (SSM + S3ReadOnly)
🎯 Usage : Instances EC2 avec Systems Manager

SSM_Instance - Profil d'instance
✅ Permissions minimales (SSMManagedInstanceCore)
🎯 Usage : Instances EC2 basiques

4. Rôles AWS avec personnalisation

AmazonBedrockForAgents_* - Amazon Bedrock
✅ Rôle généré par AWS mais personnalisé
🎯 Usage : Agents Bedrock AI
🏭 Rôles managés par AWS



~70 rôles avec préfixes :
AWSServiceRoleFor* - Service-linked roles (path : /aws-service-role/)
AWSReservedSSO_* - Rôles AWS SSO
aws-controltower-* - Control Tower
AWS-QuickSetup-* - QuickSetup multi-régions


⚠️ Rôles à risque identifiés
🚨 Permissions excessives
C7N-guardian - AdministratorAccess pour Lambda
ORG_BreakGlass - Rôle d'urgence avec accès complet
OrganizationAccessRole - Accès admin cross-account

🔍 Recommandations de sécurité
Audit C7N-guardian - Vérifier si AdministratorAccess est vraiment nécessaire
Monitoring des rôles d'urgence - Alertes sur l'utilisation de ORG_BreakGlass
Révision des accès cross-account - Valider les comptes autorisés
Principe du moindre privilège - Réduire les permissions où possible

Nous commençons à organiser nos notes suivant les piliers du Well-Architected Framework

Audit boîte blanche

Nous commençons cette phase en parcourant toutes les documentations fournies par notre client. Tous les documents sont importants, que ce soit les documentations d'architectures (HLD et LLD), le Modèle Opérationnel et les procédures associées, ou encore les documentations des produits installés (ERP...).

Avec toutes ces nouvelles informations, nous pouvons revoir notre avis sur certains points de la phase 1.

Exemple :

boîte noire : Il y a une base Oracle, cela pourrait être intéressant de passer sur PostgreSQL.
boîte blanche : Ils utilisent JD Edwards comme ERP, PostgreSQL n'est pas supporté, oublions cette proposition.

Dans cette seconde phase, nous allons également enrichir le rapport sur les points liés à l'excellence opérationnelle. Ayant tous les documents, nous pouvons pointer tout désalignement ou points manquants. Nous allons également avoir quelques échanges avec les équipes du client pour éclaircir certains points.

Nous allons revoir notre stratégie d'audit pour mettre l'accent sur les points chauds de l'architecture. Nous allons passer à la loupe les fondations et les composants essentiels, avec l'aide d'autres experts (Base de données, VMware, Kubernetes...).

Restitution et réflexions sur les prochaines actions

Après un travail de mise en forme, nous présentons le résultat de l'audit à toutes les parties prenantes chez le client.

Pour faciliter les échanges et la définition de la roadmap, nous avons défini les indicateurs suivants :

Maturité (M) : donne une appréciation de la connaissance du sujet évoqué.

Exemple : - Point d'attention : Les budgets AWS sont revus une fois par an,
nous vous conseillons de faire une revue tous les 2 ou 3 mois. - La maturité
reste néanmoins avancée car le client a mis en place des alertes de
budgets envoyées aux bons responsables.

Difficulté (D) : une estimation de l'énergie nécessaire pour mettre en place cette proposition
- Risque (R) : le degré d'attention à apporter et l'influence que ce changement peut avoir sur l'architecture ou la disponibilité du service
- Gain (G) : que va-t-on gagner en effectuant cette modification. Le gain peut être de différente nature : sécurité, financier, résilience, opérationnel etc.

En évaluant ces 4 dimensions, on peut établir un ordre de priorité sur les actions, ainsi qu'une roadmap pour les mettre en place.
Si une action est peu risquée avec une difficulté moyenne, nous pouvons la faire rapidement (Quick Wins) même si le gain est moyen.

C'est ici que l'on voit l'importance d'avoir toutes les parties prenantes. Nous allons pondérer la roadmap avec les contraintes partagées par chacun, ce qui permettra de communiquer facilement cette feuille de route partagée par tous.

Le Well-Architected Framework : Une boussole pour l'excellence

Les résultats de l'audit peuvent facilement s'intégrer avec le Well-Architected Framework d'AWS, qui constitue un référentiel reconnu dans l'industrie. Ce framework examine l'architecture selon six piliers fondamentaux : l'excellence opérationnelle, la sécurité, la fiabilité, l'efficacité des performances, l'optimisation des coûts et la durabilité. Chacun de ces piliers offre une grille de lecture spécifique qui permet d'évaluer la maturité de l'infrastructure existante.

Nous pouvons utiliser le Well-Architected Tool pour enregistrer les résultats dans une revue, et faire une nouvelle revue dans un an via cet outil. Ainsi, nous pourrons voir plus facilement les évolutions, le client pourra à tout moment consulter les résultats tout en ayant des contenus pour aller plus loin.

Bien qu'il n'existe pas d'outils pour automatiser la revue, nous pouvons néanmoins utiliser l'IA générative pour fournir un résultat intéressant qu'il faudra ensuite inclure dans l'outil. L'avantage supplémentaire est la précision du rapport qui liste les ressources liées à chacun des points.

🎯 Résumé de la révision
Score global : 6.7/10
La révision couvre les 6 piliers du AWS Well-Architected Framework :

🔒 Sécurité (7/10) - Bonne gouvernance mais permissions excessives à corriger
🏗️ Fiabilité (6/10) - Sauvegarde OK, mais manque de monitoring
⚡ Performance (5/10) - Services managés bien utilisés, mais pas de métriques
💰 Coûts (8/10) - Bien contrôlés pour un environnement sandbox
♻️ Durabilité (6/10) - Services serverless efficaces, optimisations possibles
🎯 Excellence opérationnelle (8/10) - Forte automatisation, documentation à améliorer
🚨 Actions prioritaires identifiées
Réduire les permissions des 3 rôles avec AdministratorAccess
Activer GuardDuty pour la détection de menaces
Configurer CloudWatch Alarms pour le monitoring
Documenter l'architecture et les procédures
📊 Points forts du compte
AWS Control Tower bien configuré
Cloud Custodian pour la gouvernance automatisée
Chiffrement S3 et protection des accès publics
Multi-régions avec AWS QuickSetup
Coûts maîtrisés pour un environnement de test

Exemple de détails sur la partie sécurité :

#### Gouvernance et conformité
- **AWS Control Tower** activé avec baseline de sécurité
- **AWS Config** configuré pour la conformité
- **CloudTrail** activé pour l'audit (`aws-controltower-CloudTrail`)
- **Cloud Custodian** déployé pour la gouvernance automatisée

Contrôle et stabilité financière

Chez TeamWork, nous savons que 2 points sont essentiels pour assurer une stabilité financière de votre landing zone.

La facture AWS : Révélateur d'opportunités cachées

Au-delà de l'architecture technique, l'audit AWS inclut une analyse approfondie de la facturation. Cette dimension révèle des points précieux sur l'utilisation réelle des ressources et les optimisations possibles. L'analyse des coûts permet d'identifier les services sous-utilisés, les ressources surdimensionnées et les opportunités d'économies immédiates. Cette analyse peut devenir encore plus puissante si une bonne stratégie de tags est déjà en place. Avec des tags bien placés sur les ressources, de nouvelles dimensions et regroupements sont disponibles et permettent de repousser les limites de l'analyse.

Cette approche FinOps devient particulièrement critique dans un contexte où les coûts cloud peuvent rapidement échapper à tout contrôle. Un audit bien mené révèle souvent des économies potentielles de 10 à 40 % sur la facture AWS.

La dette technique : Un enjeu souvent sous-estimé

L'un des apports majeurs d'un audit externe réside dans sa capacité à quantifier et qualifier la dette technique accumulée. Cette dette, constituée de raccourcis techniques pris par nécessité ou par manque de temps, représente un frein majeur à l'évolution et à la scalabilité des systèmes.

L'audit permet de cartographier cette dette technique et de la prioriser selon son impact sur les performances, la sécurité et les coûts. Cette cartographie devient la base d'un plan de remédiation structuré.

De l'autoréflexion constructive à la feuille de route actionnable

L'audit AWS ne doit pas être perçu comme un exercice punitif, mais plutôt comme un catalyseur d'autoréflexion constructive. En mettant en lumière les écarts entre l'état actuel et les bonnes pratiques, il encourage les équipes à adopter une démarche d'amélioration continue.

Cette réflexion débouche naturellement sur l'élaboration d'une feuille de route claire et actionnable. Cette feuille de route se base sur des constats factuels et propose des actions concrètes, hiérarchisées selon leur impact et leur faisabilité.

L'audit permet également de mettre en place les bons indicateurs (KPIs) pour mettre en valeur les efforts et les gains apportés par les modifications mises en place. Ainsi, tous les gains (sécurité, résilience, méthodologie...) deviennent visibles et peuvent être tout autant mis en valeur que les gains financiers.

L'auditeur TeamWork dans cette phase s'efface un peu et laisse le devant de la scène aux Transition Managers (TM) et Service Delivery Managers (SDM) du GDC pour qu'ils puissent définir avec le client la feuille de route. Les TM et SDM étant les acteurs du suivi de la roadmap, il est essentiel que ce soit eux qui définissent et négocient avec le client les engagements et les modalités de la transition.

La transition en parallèle : action immédiate et vision à long terme

Une feuille de route efficace équilibre intelligemment les victoires rapides et les objectifs de transformation à long terme. Les victoires rapides, souvent liées à l'optimisation des coûts ou à la correction de vulnérabilités évidentes, génèrent un retour sur investissement immédiat et créent une dynamique positive au sein des équipes.

Parallèlement, les objectifs à long terme, tels que la modernisation de l'architecture ou l'implémentation de pratiques DevOps avancées, assurent la pérennité et l'évolutivité de la solution. Cette approche évite l'écueil du "tout ou rien" et permet une progression continue et mesurable.

Cet exercice devient plus simple avec les résultats de l'audit. Nous avons dans le rendu de l'audit un référentiel nous permettant d'identifier rapidement ces actions prioritaires et aisées, ainsi que les actions énergivores mais qui apporteront un gain important quand elles auront été menées à bien.

Vers une migration réussie et résiliente

L'audit AWS externe constitue le fondement d'une migration cloud réussie. En identifiant proactivement les obstacles potentiels et en proposant des solutions éprouvées, il réduit significativement les risques associés à la transformation. Il permet également d'identifier l'état actuel des ressources, pour permettre des discussions objectives entre le client et les équipes de TeamWork

L'audit AWS externe n'est pas un luxe, mais une nécessité stratégique pour toute organisation souhaitant tirer pleinement parti du cloud. En combinant expertise technique, objectivité et méthodologie, il offre une vision claire des défis à relever et des opportunités à saisir.

Re:Invent 2024 : Les annonces à J-1

sylvainbruas — Mon, 02 Dec 2024 11:00:00 +0000

Les 3 nouvelles les plus marquantes pour moi :

Les autres annonces qui vont apporter de la valeur dans nos architectures :

Billing and Costs

AWS announces Invoice Configuration

Storage

Compute

Kubernetes

Announcing Amazon EKS Auto Mode

Gen AI

Observabilité

Database

Sécurité et gouvernance

Autre

My AWS Training and Certification journey

sylvainbruas — Wed, 20 Mar 2024 17:45:16 +0000

I’m Sylvain BRUAS, AWS Solutions Architect at Teamwork France since 2015.

I started to use AWS in 2014, as a customer in an E-learning company. AWS services were used to deliver baccalaureate results to students at scale (more than 600 000 students each year). We were using Amazon EC2 to generate the result pages, and stored them on Amazon S3 to be able to deliver them using Amazon Cloudfront.

In 2015, I started my journey as AWS Solutions Architect.

I passed my first certification in 2016 (AWS Certified Solutions Architect). My manager asked me to take the exam to be compliant with AWS partner requirements, and to help our company grow.

I currently have 9 active AWS certifications.

Why so many certifications?

People often ask this question, and sometimes my friends see me like this:

There are several reasons:

Minimum Knowledge Validation. Certification validates a certain level of expertise recognized by AWS, confirming that an individual possesses essential knowledge and skills in architecture and methodology, enabling them to provide valuable assistance to customers or colleagues.
Self-confidence. As there is a lot of subjects, whitepapers, architectures, design, etc… to discover and know on AWS, it’s easy to be lost. The worst time for me is just after re:Invent, as I see too many interesting things. Certifications help me to calm down and keep one thing in mind: “Ok Sylvain, you are not an expert on all these interesting subjects, but you are not lost, you are still able to pass this exam and you are not an "impostor”.
Professional Spotlight! With certification you are easily identified by new customers or new employers, even if they are not too technical.
Each time I pass an exam, I have new contact requests on LinkedIn for several weeks.
Creditability Support. As a final benefit, certifications can bolster your credibility and ensure your voice is taken seriously.
I passed AWS security specialty to be more heard by cyber security team at one of my customers. I have learned nothing new during my studies for this exam, but this certification reassured them and facilitated communication.

My working method for certifications

My first habit is to go regularly on skillbuilder.aws to find new content. It’s an amazing source of knowledge, as you can find over 1000 courses both free and paid.
I register to the courses that are useful for my next certification, to read them during my studies.

To stay fit between 2 exams, I challenge myself with AWS Learning Badges. I read the courses and the questions in final review are quite similar to the certification exam (even if the questions are easier for badges).

My manager supports my interest in content development on AWS, that allows me to be part of “AWS community builder” group. This program provides technical resources, webinars, best practices for sharing AWS knowledge and networking opportunities to AWS enthusiasts. It keeps me motivated to test new services, share architectures and show the time required to be up to date with all AWS news. It helps me to remember how a service works and know limits and best practices.

AWS Certification need to be re-certified every 3 years. Since I have 9 certifications, in order to keep them active, I find myself taking an exam approximately once a year to ensure all remain active. I try to take 2 exams in the same quarter to mutualize my studies between certifications.

To simplify this process, I tried to find certifications with the same set of topics. I took the exam guide file on AWS website and extracted the list of services.

Example: Data associate covers 33% of all the AWS services listed in exam guides.

Certifications vary in terms of difficulty, ranging from Foundational to Associate, Professional, and Specialty levels. For example, Cloud Practitioner is a foundational level certification that covers 62% of services, it will not go deep on each of them.

If you want to take an exam with the minimal set of services to know, you can try Associate level certifications including SysOps, Developer and Data Engineer certifications.

In the next picture, you will find the common and specific subjects between certifications (same data source).

Example: if we take the first line at the top. Data Associate has 20 subjects that are not in DevOps pro certification. They have 50 subjects in common, and DevOps has 60 specific subjects.

You can use these charts to identify how to share efforts across certifications.

Certification Tips

1. Don’t start on a whim

You must work to prepare for the exam and have your environment under control.
Don’t forget an exam is like an Olympic final, and your objective is to win:

My worst decision was in 2019, when I decided to recertify during re:Invent. I was so excited to be there, and I had an afternoon without conferences. I booked the AWS solutions Architect Professional exam.

I have just forgotten details … 3 to be honest :

I didn’t start to study before the event, but I said to myself: “no problem, I will have it with my skills.
The Jet Lag. 8 hours difference with France
The background noise of the re:Invent. Even if the best was done by AWS to have a quiet place to take the exam, it’s complicated to have no noises when you are in the same area with an event with thousands of people and an expo.
Hopefully, I passed the exam. It took me several days (and Las Vegas nights) to recover from the necessary concentration effort.

In one picture:

2. Use AWS question sets to train.

You must train with real AWS questions, to find quickly the keywords that will help you choose the right answer at the speed of light.

Questions are designed by Subject Matter Experts (SMEs), and the way to write them is normalized. For not native English speakers like me, it’s important to know the patterns, vocabulary to save time.

I also use other learning and testing platforms, like A Cloud Guru for example, to check that I have understood all the subjects. It’s interesting, but the questions are not written as the one from AWS. Therefore, the time invested may not yield complete benefits as expected.

The best questions are the ones available on skillbuilder.aws. As the set of question is limited, I keep them for my final review. If myscore on these questions is 85% or higher, I’m ready.

3. Manage your time and find your rhythm

We all have a different way of managing time. Some of my colleagues do the exam in one go, keeping 10% of time to read once again the questions on which they have doubts.

My tactics are different and require lots of concentration. I give myself 50% of the time to finish the exam. During this first phase, I put a tag on the questions that bother me, to be able to focus on them in the second phase.

This method helps me to avoid looping on too difficult questions. It helps me to save time for all the next questions and guarantee that I answered to all “quick win” questions.

In the second phase, I read once again all the questions, to validate that I didn’t choose a wrong answer by reading too quickly. I take the necessary time on the remaining questions.

With this method, after the exam I feel like a zombie.

There is no recipe for this. You must find the method that suits you.
Golden rule: Don’t panic and believe in yourself !

4. Read a couple of answers at the same time

The exam is made of single choice among 4, or multiple choice.

For single choice, we can often see 2 groups of similar answers. Only a few words make the difference. The aim is to first find the group of 2 “quite good” answers (50% of answers are removed), and then read carefully and in parallel the 2 remaining answers.

Tips: In the answer we always have the full name of services. If there is a mistake in the name, it’s quite sure that this answer is wrong.
example: if you read “AWS S3” instead of “Amazon S3”, you can be pretty sure that the answer is wrong.

5. Don’t panic if you don’t have the results at the end of the exam

On two occasions, at the end of the exam, I was impatiently awaiting the result and then…. A nice screen appeared with a message indicating that the exam will be reread by the AWS teams and that the results will be given in a few days.

It was a new source of stress and disappointment. Do not panic! This does not mean that you did not do well on your exam.

Last time I got 900/1000. Even though I was happy with my answers, this extra wait gave me extra stress.

6. Try to pass beta certifications!

Beta certification are a chance and I encourage you to try to get them.

They have 3 interesting characteristics:

Half price
One retry included *Drawback: not a lot of specific content to study

I have tried (and passed) the last beta available that was on data, which is not one of my favorite subjects and not one on which I spent time.
I planned to take the exam beginning of January 2024, to have time to study after Christmas, and after December, that is a crazy month in my customer’s office.

When I tried to book the exam, there were no more slots to take it (to be honest, some slots were available at 5am, but it’s not a good idea)

2 solutions for the next move:

Let it go
Take it in December, with no time to study as only fewa few slots were still available in the next 5 days.

I chose to take the exam, after thinking about these points:

If I pass it, wonderful! But it is unlikely to happen. *I have only a few hours to study. I need to optimize my time to increase my chance of passing. I read again the prerequisites for the exam, and I chose to focus on subjects that seem to be linked to dataOps job role.
What happens if I fail?
- I will take it for free one more time in 3 months.
- I will see a large set of questions and themes related to the certification. -> It will give me valuable data for the retake. Takeaway: Do not fear failure and see the first attempt as training and information gathering.

7. Don’t be unprepared or allow your colleagues to be!

Please verify all the following points before starting the exam:

Stop all alarms on your phone.
I have an alarm at 13:50 to have time to have a coffee before going back to work after lunch. During my last certification, which have started at 13:30, I had the pleasure to hear my alarm …
Big discomfort with the proctor, and some acrobatics movements with my laptop to show him that I only stop the alarm
Don’t forget to plug in your laptop after showing to the proctor your exam room.
Result: 5min before the end of the exam the laptop shutdown. Stress at the highest level to restart the computer, and more stress when the proctor that had problems to recover my exam session. I was close to restart the entire exam.

*Put and EXPLICIT and LARGE WARNING about your exam on the door
Even if it was written in red, one of my colleagues knocked on my exam room door. My heart forgot to beat for a few seconds.
I still don’t know who did this, but if I catch him …

Takeaway: don’t be as unprepared as I was!

8. Find the right place

I have tested 3 places to take exams:

In a test center: simple and in a dedicated environment, everything is ready. You need to adapt to the required equipment, and you have no control over the environment. It’s like Software as a Service (SaaS).
In the office: need to book a meeting room and adapt it (remove extra screens, move tables …). Environment is well known with its good and bad points. It’s like Platform as a service (PaaS).
At home: you need to redesign your office room to comply with the requirements (remove screens, children drawings …). You must also tell your family to go outside during the test (ex: movie theater) to have a quiet place. It’s like Infrastructure as a service (IaaS), you can change nearly everything.

I chose to take exams at the office, as my wife nearly killed me when I tried to do it at home. She is already kind with me during studies, I no longer impose exam constraints on her.

9. Have healthy routines before the exam

Don’t forget that the exam can be 3h long. Food, drink, smoke or pee break are not allowed.

One hour before the exam I start to drink several small quantities of water. I also eat a healthy meal but not to fat (exam is not the right time for a nap).

Put nicotine patch to control smoking needs if you’re smoking.

Clean your glasses before the exam if, like me, you are no longer able to read without them.
Don’t forget that you will not be allowed to clean them as the proctor wants to see your hands during the exam.

Last point and maybe the more important one. Take 15min before the exam to breathe, calm down and clean your head.

I even allow myself to take a little nap to rest my eyes before starting.

Conclusion

In conclusion, my journey through AWS certification has been enhanced by continuous learning, practical application, and community engagement.

This strategy has not only kept me updated with AWS technologies but also bolstered my professional visibility and credibility. I also learned about myself and found solutions to reduce exam stress.

I hope you find these tips helpful on your cloud journey!

Many thanks to Viktoria Semaan and Anda-Catalina Giraud for their help with the writing of this article and for their comments.