DEV Community: sylvainbruas

BMAD Method et Agent Lattice : structurer la vision produit avec l'IA de bout en bout

sylvainbruas — Thu, 20 Aug 2026 13:07:41 +0000

Le développement assisté par IA a résolu un premier problème : générer du code rapidement. Mais un deuxième problème, plus fondamental, persiste : qui définit ce qu'il faut construire, et comment s'assurer que l'IA respecte cette vision ? La méthode BMAD et l'outil AWS sample-e2e-product-development-with-kiro apportent chacun une réponse à cette question, avec des approches complémentaires qui s'inscrivent pleinement dans la logique de l'AI-DLC.

BMAD : une équipe virtuelle pour piloter le cycle produit

Le problème de la dérive contextuelle

Quand vous utilisez un agent IA dans un IDE — que ce soit Cursor, Claude Code ou Kiro — chaque nouvelle session repart à zéro. L'agent ne sait plus pourquoi telle décision architecturale a été prise, quels compromis ont été acceptés, ou quels cas limites ont été identifiés. C'est ce que la communauté appelle la dérive contextuelle : un code fonctionnel qui s'éloigne progressivement de la vision produit initiale.

La méthode BMAD (Breakthrough Method of Agile AI-Driven Development) attaque ce problème frontalement. Au lieu de traiter l'IA comme un assistant généraliste, BMAD orchestre des agents spécialisés — chacun avec un rôle précis, une place définie dans le workflow, et des livrables documentés.

Les agents BMAD : des personas avec une mission

BMAD définit plus de 12 agents spécialisés, dont six rôles principaux :

Agent	Persona	Responsabilité
Analyst	Mary	Brainstorming, recherche marché, brief projet
Product Manager	John	PRD, épics, stories, validation produit
Architect	Winston	Architecture système, tech stack, APIs, schémas DB
Developer	Amelia	Implémentation, code review, sprint planning
UX Designer	Sally	Specs UX, patterns d'interaction
Tech Writer	Paige	Documentation technique

Chaque agent est un fichier Markdown/YAML qui encode sa persona, ses commandes et ses dépendances. L'activation suit un template structuré : chargement du contexte persistant, adoption de la persona, puis exécution de la tâche.

Quatre phases, des artefacts durables

BMAD structure le développement en quatre phases successives :

Analyse — Brainstorming, recherche, brief produit
Planification — PRD, spécifications UX, architecture
Conception — Architecture détaillée, design système
Implémentation — Développement story par story, code review, rétrospective

Le point clé : chaque phase produit des artefacts versionnés dans Git (PRD, documents d'architecture, fichiers story) qui deviennent la source de vérité du projet. Quand l'agent Developer ouvre une nouvelle session, il ne repart pas à zéro — il lit le fichier story qui contient tout le contexte nécessaire à l'implémentation.

Agent Lattice : le Design Thinking piloté par l'IA dans Kiro

Un sample AWS qui va plus loin qu'un exemple

Le repository sample-e2e-product-development-with-kiro publié par AWS Labs n'est pas un simple tutoriel. C'est un framework complet — baptisé Agent Lattice — qui orchestre un processus de Design Thinking de bout en bout, directement dans l'IDE Kiro.

Agent Lattice se compose de deux éléments :

Le runtime (.al/) : un orchestrateur qui gère les rôles, workflows, gates et scripts, avec des modules pluggables pour le Design Thinking et la génération de specs Kiro
Les extensions IDE : un plugin de visualisation qui affiche la progression des phases dans une sidebar dédiée

Le workflow Design Thinking complet

L'outil guide l'utilisateur à travers les cinq phases classiques du Design Thinking, orchestrées par des skills Kiro :

Empathize (/al-dt-workflow-empathize) — Interviews utilisateurs, empathy maps, personas
Define — Carte d'affinité, insights, questions "How Might We"
Ideate — Brainstorming structuré, évaluation des concepts
Prototype — User flows, wireframes, spécifications d'interaction
Test — Plans de test, métriques, validation des hypothèses

À la fin du processus, un module Kiro Bridge transforme automatiquement les artefacts de Design Thinking en specs Kiro natives (requirements → design → tasks), prêtes pour l'implémentation.

L'impersonation de rôles

Un mécanisme original d'Agent Lattice : la commande /al-impersonate permet à l'IA d'adopter un rôle spécifique (designer, ingénieur, product manager, UX researcher, market researcher) pendant une phase donnée. Chaque rôle dispose de son propre fichier de steering qui cadre les réponses de l'IA selon l'expertise attendue.

L'intérêt pour la vision produit et l'AI-DLC

Combler le fossé entre intention et implémentation

L'AI-DLC, tel que formalisé par AWS, repositionne l'humain sur la direction stratégique tandis que l'IA exécute. Mais ce modèle suppose que la direction stratégique est clairement articulée et accessible à l'agent d'implémentation. C'est précisément le maillon faible de la plupart des outils actuels.

BMAD et Agent Lattice adressent ce fossé de deux manières complémentaires :

BMAD structure la chaîne de documents (brief → PRD → architecture → stories) qui encode les décisions produit de manière durable et versionnable
Agent Lattice structure la phase d'exploration (empathie → problème → idéation → prototype → test) qui précède la rédaction des specs

Ensemble, ils couvrent l'intégralité du spectre : de la compréhension utilisateur jusqu'au code déployé.

Le développeur comme Tech Lead, pas comme exécutant

Dans un AI-DLC structuré par ces outils, le rôle du développeur change fondamentalement. Il ne passe plus son temps à écrire du code répétitif. Il :

Valide les personas générées par la phase Empathize
Arbitre les décisions architecturales proposées par l'agent Architect
Review les stories avant de lancer l'implémentation automatique
Approuve les gates entre chaque phase du workflow

C'est un rôle de curateur et de validateur — exactement la redistribution de l'effort cognitif que promet l'AI-DLC.

Artefacts versionnés : la mémoire du projet

Le bénéfice le plus tangible de ces deux approches : le projet a une mémoire. Les PRD, les documents d'architecture, les empathy maps, les fichiers story — tout vit dans Git. Un nouveau développeur qui rejoint le projet peut comprendre non seulement ce que le logiciel fait, mais pourquoi il a été conçu ainsi. Un agent IA qui ouvre une nouvelle session peut charger le contexte complet sans que l'humain ait à tout ré-expliquer.

C'est l'antidote à la dérive contextuelle : quand les décisions sont documentées dans des artefacts structurés, l'IA peut les respecter session après session.

Les limites à connaître

Ces approches ne sont pas sans compromis :

Overhead documentaire : le processus complet BMAD génère des dizaines d'artefacts avant la première ligne de code. Pour un fix rapide, c'est disproportionné (d'où l'existence d'un Quick Flow)
Consommation de tokens : les allers-retours entre agents consomment significativement plus de tokens qu'un prompt direct
Coordination manuelle : BMAD laisse au développeur la responsabilité de passer les artefacts entre agents, là où Agent Lattice automatise davantage via les skills Kiro

Ce qu'il faut retenir

La méthode BMAD et l'outil Agent Lattice d'AWS représentent une évolution majeure dans l'écosystème AI-DLC : la structuration de la phase amont. Là où la plupart des outils IA se concentrent sur la génération de code, ces frameworks s'attaquent au vrai problème — s'assurer que le code généré respecte une vision produit cohérente et documentée.

Pour une équipe qui adopte Kiro, la combinaison est naturelle : Agent Lattice pour la phase de Discovery (Design Thinking → specs), puis le workflow natif Kiro (specs → implémentation) pour la phase de Delivery. Le tout versionné dans Git, auditable, et reproductible.

Le futur du développement assisté par IA n'est pas « l'IA fait tout ». C'est « l'IA exécute un processus structuré, guidé par des artefacts que l'humain valide ». BMAD et Agent Lattice montrent à quoi ce futur ressemble concrètement.

Références :

AWS Transit Gateway Policy-Based Routing : le routage intelligent arrive !

sylvainbruas — Wed, 19 Aug 2026 08:59:39 +0000

Le routage réseau sur AWS a longtemps été contraint par une logique simple : le trafic est acheminé en fonction de l'adresse IP de destination. Point final. Pour les architectes réseau habitués aux fonctionnalités avancées des équipements on-premise (Cisco, Juniper, Palo Alto), cette limitation était frustrante. AWS vient de combler ce gap avec l'annonce de la disponibilité générale du Policy-Based Routing (PBR) sur AWS Transit Gateway.

Cette fonctionnalité, annoncée le 30 juillet 2026, permet désormais de prendre des décisions de routage basées sur une combinaison d'attributs : adresse IP source, adresse IP destination, ports, et protocole. C'est un changement fondamental dans la manière dont nous concevons les architectures réseau sur AWS.

Qu'est-ce que le Policy-Based Routing ?

Le Policy-Based Routing est un mécanisme qui permet de diriger le trafic réseau en fonction de politiques définies par l'administrateur, plutôt que de s'appuyer uniquement sur la table de routage classique basée sur la destination. En d'autres termes, vous pouvez désormais dire : « tout le trafic HTTPS provenant du subnet applicatif à destination du port 443 doit passer par mon appliance d'inspection, tandis que le trafic SSH de l'équipe opérations peut prendre un chemin direct ».

Sur AWS Transit Gateway, le PBR fonctionne avec un concept de policy table que vous associez à un attachement Transit Gateway. Dans cette table, vous définissez un ensemble ordonné de règles. Chaque règle classifie le trafic selon les critères suivants :

Adresse IP source : d'où vient le trafic
Adresse IP destination : où va le trafic
Port source et destination : quel service est utilisé
Protocole : TCP, UDP, ICMP, etc.

Les règles sont évaluées dans l'ordre avec une logique first-match-wins : la première règle qui correspond au trafic détermine vers quelle route table le paquet sera dirigé. Si aucune règle ne correspond, le trafic est silencieusement supprimé (implicit deny). Ce comportement, similaire à celui des Security Groups, impose de toujours prévoir une règle catch-all si vous souhaitez éviter les drops involontaires.

Pourquoi c'est un game-changer ?

Avant le PBR : la complexité architecturale

Avant cette annonce, les architectes réseau qui avaient besoin de diriger le trafic de manière granulaire devaient construire des architectures multi-VPC complexes avec des sauts de routage supplémentaires. Concrètement, cela signifiait :

Multiplier les VPC d'inspection : un VPC dédié pour chaque type de trafic à inspecter différemment
Ajouter des Gateway Load Balancers : pour distribuer le trafic vers des appliances tierces
Créer des chaînes de routage : avec plusieurs Transit Gateway route tables interconnectées
Gérer des coûts croissants : chaque saut supplémentaire génère des frais de traitement de données

Cette complexité se traduisait par une surcharge opérationnelle importante, des latences accrues, et un risque d'erreur de configuration élevé.

Avec le PBR : la simplicité retrouvée

Le PBR élimine une grande partie de cette complexité en étendant les capacités natives de routage du Transit Gateway. Plus besoin d'ajouter des couches intermédiaires : vous classifiez et dirigez le trafic directement au niveau du Transit Gateway, en une seule étape.

Cas d'usage concrets

Le PBR ouvre la porte à de nombreux scénarios que les équipes réseau et sécurité attendaient depuis longtemps.

Inspection sélective du trafic

C'est probablement le cas d'usage le plus demandé. Plutôt que de faire passer tout le trafic par AWS Network Firewall ou une appliance tierce (ce qui génère des coûts et de la latence), vous pouvez désormais ne router que le trafic sensible vers l'inspection. Par exemple :

Le trafic à destination des bases de données (port 3306, 5432) passe par l'inspection
Le trafic interne entre microservices sur des ports applicatifs connus peut contourner l'inspection
Le trafic vers des destinations externes spécifiques est systématiquement inspecté

Routage basé sur la source pour la connectivité hybride

Pour les entreprises utilisant AWS Direct Connect et AWS VPN en parallèle, le PBR permet de diriger le trafic vers le bon chemin en fonction de sa source ou de son protocole :

Le trafic critique (bases de données, ERP) emprunte le Direct Connect pour bénéficier de la latence faible et de la bande passante garantie
Le trafic moins sensible (mises à jour, synchronisation) peut utiliser le VPN comme chemin secondaire
Le basculement peut être géré de manière plus fine en fonction des applications

Isolation des environnements

Le PBR permet d'isoler les environnements de production et de développement dans des domaines de routage séparés, limitant ainsi les mouvements latéraux. Même si deux environnements partagent des plages IP similaires ou des attachements communs, les règles PBR garantissent que le trafic de développement ne peut jamais atteindre les ressources de production, et inversement.

Configuration et mise en place

Contrainte fondamentale : policy table OU route table, jamais les deux

C'est le point le plus important à comprendre avant de se lancer : un attachement Transit Gateway ne peut être associé qu'à une policy table OU à une route table, jamais aux deux simultanément. Il n'existe aucun mode hybride. Concrètement :

Si votre attachement VPC est actuellement associé à une route table classique, vous devez d'abord dissocier cette route table avant de pouvoir associer une policy table
Pendant la fenêtre de dissociation/association, le trafic de cet attachement sera interrompu
Une policy table vide (sans aucune règle) entraîne le drop de tout le trafic entrant sur cet attachement — c'est l'implicit deny

Cette exclusivité signifie que le PBR remplace complètement la logique de routage classique pour un attachement donné. C'est un choix architectural binaire par attachement.

Les étapes de mise en place

La configuration du PBR se fait en quatre étapes :

Créer les route tables cibles : chaque règle PBR pointe vers une route table TGW qui contient les routes effectives
Créer une policy table : vous définissez une table de politiques associée à votre Transit Gateway
Définir les règles : vous créez un ensemble ordonné de règles (numérotées de 1 à 50 000) avec les critères de classification et la route table cible
Dissocier la route table existante puis associer la policy table à l'attachement

Le PBR est configurable via la Console AWS, l'AWS CLI, et les SDK AWS. Les commandes CLI dédiées (create-transit-gateway-policy-table, create-transit-gateway-policy-table-entry, associate-transit-gateway-policy-table) sont disponibles dès maintenant.

Exemple concret : filtrage HTTP/HTTPS et SSH

Voici un exemple complet de mise en place via AWS CLI, qui implémente le scénario décrit en introduction : le trafic HTTPS est inspecté, le trafic SSH prend un chemin direct.

# 1. Créer la policy table
aws ec2 create-transit-gateway-policy-table \
  --transit-gateway-id tgw-0bc994abffEXAMPLE \
  --tag-specifications 'ResourceType=transit-gateway-policy-table,Tags=[{Key=Name,Value=app-security-policy}]'
# Retourne : tgw-ptb-0ca78a549EXAMPLE

# 2. Règle 100 : trafic HTTPS (port 443) du subnet applicatif → inspection firewall
aws ec2 create-transit-gateway-policy-table-entry \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --policy-rule-number 100 \
  --policy-rule '{"SourceCidrBlock":"10.1.10.0/24","Protocol":"6","DestinationPortRange":"443"}' \
  --target-route-table-id tgw-rtb-0a823edbdeEXAMPLE

# 3. Règle 200 : trafic HTTP (port 80) → même inspection
aws ec2 create-transit-gateway-policy-table-entry \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --policy-rule-number 200 \
  --policy-rule '{"SourceCidrBlock":"10.1.10.0/24","Protocol":"6","DestinationPortRange":"80"}' \
  --target-route-table-id tgw-rtb-0a823edbdeEXAMPLE

# 4. Règle 300 : trafic SSH (port 22) de l'équipe ops → routage direct (pas d'inspection)
#    Ne matche que si ce trafic entre bien par l'attachement associé à la policy table
aws ec2 create-transit-gateway-policy-table-entry \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --policy-rule-number 300 \
  --policy-rule '{"SourceCidrBlock":"10.1.50.0/24","Protocol":"6","DestinationPortRange":"22"}' \
  --target-route-table-id tgw-rtb-0b91f2c3d4EXAMPLE

# 5. Règle 40000 : catch-all → routage par défaut (évite l'implicit deny)
#    Un policy-rule vide matche tout : toutes les conditions valent * par défaut
aws ec2 create-transit-gateway-policy-table-entry \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --policy-rule-number 40000 \
  --policy-rule '{}' \
  --target-route-table-id tgw-rtb-0f5e4d3c2bEXAMPLE

# 6. Vérifier les entries avant de basculer l'attachement
aws ec2 get-transit-gateway-policy-table-entries \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE

# 7. Dissocier la route table existante de l'attachement source
#    Un attachement ne peut être associé qu'à une route table OU une policy table
aws ec2 disassociate-transit-gateway-route-table \
  --transit-gateway-attachment-id tgw-attach-0def6EXAMPLE \
  --transit-gateway-route-table-id tgw-rtb-0c7d8e9f01EXAMPLE

# 8. Attendre la fin de la dissociation : associer trop tôt fait échouer la requête
while :; do
  STATE=$(aws ec2 get-transit-gateway-route-table-associations \
    --transit-gateway-route-table-id tgw-rtb-0c7d8e9f01EXAMPLE \
    --filters "Name=transit-gateway-attachment-id,Values=tgw-attach-0def6EXAMPLE" \
    --query 'Associations[0].State' --output text)
  # "None" : l'association a disparu de la liste
  if [ "$STATE" = "None" ] || [ "$STATE" = "disassociated" ]; then
    break
  fi
  sleep 5
done

# 9. Associer la policy table à l'attachement
aws ec2 associate-transit-gateway-policy-table \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --transit-gateway-attachment-id tgw-attach-0def6EXAMPLE

# 10. Confirmer l'association
aws ec2 get-transit-gateway-policy-table-associations \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE

Avec cette configuration, le trafic est traité comme suit :

Paquet TCP:443 depuis 10.1.10.x → inspecté par le firewall (règle 100)
Paquet TCP:80 depuis 10.1.10.x → inspecté par le firewall (règle 200)
Paquet TCP:22 depuis 10.1.50.x → routage direct sans inspection (règle 300)
Tout autre trafic → routage par défaut (règle 40000 catch-all)

Considérations et bonnes pratiques

Comme toute fonctionnalité réseau avancée, le PBR nécessite une approche structurée :

Commencez simple : déployez d'abord une ou deux règles sur un attachement non-critique pour valider le comportement
Documentez vos politiques : la logique first-match-wins peut devenir complexe avec de nombreuses règles. Maintenez une documentation claire de l'ordre et de l'intention de chaque règle
Surveillez les métriques : utilisez Amazon CloudWatch pour monitorer les hits sur chaque règle et identifier les règles inutilisées. La métrique PacketDropCountNoPolicy vous alerte quand du trafic est droppé faute de règle correspondante
Prévoyez toujours une règle catch-all : sauf si vous souhaitez explicitement un comportement Zero Trust (deny-all), ajoutez une règle à numéro élevé (ex: 40000) qui capture le trafic restant
Laissez des gaps entre les numéros de règle : utilisez 100, 200, 300… pour pouvoir insérer de nouvelles règles sans tout renuméroter
Testez les scénarios de basculement : validez que vos règles PBR se comportent correctement en cas de panne d'un attachement cible
Attention au BGP : associer une policy table à un attachement VPN (Site-to-Site) ou Connect stoppe les advertisements BGP vers le peer. Direct Connect n'est pas affecté (utilise la liste allowed-prefixes)

Impact sur la latence réseau

Une question légitime : le PBR ajoute-t-il de la latence au transit du trafic ?

La réponse est non. L'évaluation des règles PBR s'effectue au niveau du plan de données du Transit Gateway, au même point de décision que la table de routage classique. Il n'y a pas de saut réseau supplémentaire, pas de composant intermédiaire ajouté dans le chemin. La décision est prise « en ligne » lors du transit du paquet.

En réalité, le PBR peut même réduire la latence globale de votre architecture :

Avant le PBR : pour inspecter sélectivement le trafic, il fallait tout envoyer vers un VPC d'inspection (un saut supplémentaire) puis filtrer au niveau de l'appliance. Même le trafic « propre » subissait la traversée.
Avec le PBR : seul le trafic qui nécessite effectivement une inspection est dirigé vers l'appliance. Le reste prend le chemin direct, économisant un ou plusieurs sauts réseau.

Les quotas de bande passante ne sont pas impactés non plus : chaque attachement VPC conserve sa capacité de 100 Gbps par Availability Zone dans chaque direction.

Limites et quotas

Comme tout service AWS, le PBR a ses limites qu'il faut connaître avant de concevoir votre architecture :

Ressource	Limite	Ajustable
Policy tables par Transit Gateway	20	Non
Policy entries (customer-managed) par TGW, toutes tables confondues	200	Oui
Numéros de règle	1 à 50 000	—
Types d'attachement supportés	VPC, VPN, Direct Connect, Connect, Peering (sauf Cloud WAN)	—

Autres contraintes importantes :

Exclusivité absolue : un attachement est associé à une policy table OU une route table, jamais les deux
Pas de PBR sur les peering Cloud WAN : seules les entries system-managed (gérées par Cloud WAN) s'appliquent sur ces attachements
Ports limités à TCP/UDP : le filtrage par port ne fonctionne que pour les protocoles TCP (6) et UDP (17). Pour ICMP, GRE ou « Any », les ports sont automatiquement à *
Policy table vide = blackhole : associer une policy table sans aucune règle à un attachement provoque le drop silencieux de tout le trafic
Route table référencée non supprimable : une route table utilisée comme cible par une policy entry ne peut pas être supprimée tant que la référence existe

Migration : passer d'une route table au PBR sans coupure

La migration vers le PBR est la question qui préoccupe le plus les équipes réseau en production. Soyons clairs : il existe une micro-interruption inévitable lors du basculement, car la dissociation de la route table et l'association de la policy table ne sont pas atomiques.

Voici la stratégie recommandée pour minimiser l'impact :

Approche progressive (recommandée)

Préparez tout en amont : créez la policy table, définissez toutes les règles, et créez les route tables cibles avec les routes nécessaires — tout cela sans aucun impact sur le trafic existant
Commencez par un attachement non-critique : choisissez un VPC de développement ou de test pour valider le comportement
Incluez une règle catch-all qui réplique le comportement actuel : votre règle à numéro élevé doit pointer vers une route table qui reproduit exactement le routage actuel. Ainsi, même si vos règles spécifiques ont un bug, le trafic continue de transiter
Planifiez une fenêtre de maintenance : la dissociation de la route table suivie de l'association de la policy table prend généralement quelques secondes, mais prévoyez 30 à 60 secondes de micro-coupure potentielle
Basculez : dissociez la route table, puis associez immédiatement la policy table
Validez : vérifiez les flux avec GetTransitGatewayPolicyTableEntries et surveillez la métrique PacketDropCountNoPolicy
Itérez : une fois validé, répétez sur les attachements de production

Ce qui se passe pendant la bascule

[Route table associée] ──dissociation──▶ [Aucune association] ──association──▶ [Policy table associée]
                                              │
                                    Trafic droppé pendant
                                    cette fenêtre (secondes)

Pendant la fenêtre où l'attachement n'a ni route table ni policy table, le trafic entrant est droppé. Les connexions TCP établies seront coupées et devront être ré-établies. Pour les protocoles stateless (UDP, ICMP), la reprise est transparente dès que la policy table est active.

Stratégies de mitigation

Applications tolérantes : la plupart des applications avec des mécanismes de retry (HTTP, gRPC) survivent à une interruption de quelques secondes sans impact utilisateur visible
Trafic critique : pour les flux qui ne tolèrent aucune perte, envisagez un schéma de migration par duplication d'attachement — créez un second attachement VPC (dans un subnet dédié), migrez-le vers PBR, puis basculez le trafic applicatif vers ce nouveau subnet
DNS failover : si vous avez un mécanisme de failover DNS (Route 53 health checks), vous pouvez basculer le trafic temporairement vers un chemin alternatif le temps de la migration
Coordination multi-AZ : migrez un AZ à la fois si votre architecture le permet (attachements distincts par AZ)

Rollback

En cas de problème, le rollback est simple : dissociez la policy table et réassociez l'ancienne route table. La même micro-interruption s'applique dans l'autre sens. C'est pourquoi il est essentiel de ne pas supprimer l'ancienne route table tant que la migration n'est pas validée en production.

Disponibilité et tarification

Le Policy-Based Routing pour AWS Transit Gateway est disponible dans toutes les régions commerciales AWS où Transit Gateway est disponible. Point important : le PBR n'engendre aucun coût supplémentaire au-delà des frais standard de Transit Gateway (frais par attachement + frais de traitement de données). Il n'y a pas de tarification par règle ni par évaluation. C'est une excellente nouvelle car cela signifie que l'adoption ne sera pas freinée par des considérations budgétaires.

Conclusion

Pour les architectes réseau et les équipes sécurité, c'est une fonctionnalité qui va simplifier considérablement les architectures existantes tout en ouvrant de nouvelles possibilités.

Mon conseil : si vous avez aujourd'hui des architectures multi-VPC complexes uniquement pour gérer du routage conditionnel, c'est le moment de revoir votre design. Le PBR peut potentiellement vous permettre de réduire le nombre de composants intermédiaires, diminuer la latence, et simplifier vos opérations quotidiennes.

Commencez par identifier vos flux de trafic les plus critiques qui nécessitent un traitement différencié, puis testez le PBR sur un périmètre restreint avant de l'étendre à l'ensemble de votre organisation.

AWS Lambda MicroVMs : bastions serverless, sandboxes IA et Cloud9 DIY avec VS Code OSS + EFS

sylvainbruas — Wed, 12 Aug 2026 08:12:49 +0000

Introduction

Le 22 juin 2026, AWS a lancé Lambda MicroVMs, un nouveau type de ressource serverless qui change la donne. Jusqu'ici, Lambda était synonyme de fonctions stateless limitées à 15 minutes. Désormais, vous pouvez obtenir une machine virtuelle Firecracker dédiée, stateful, avec isolation hardware, démarrage quasi-instantané depuis un snapshot, et une durée de vie allant jusqu'à 8 heures. Le tout sans infrastructure à gérer.

Ce n'est pas une évolution incrémentale de Lambda Functions — c'est un nouveau type de ressource avec sa propre API (run-microvm, suspend-microvm, resume-microvm). AWS expose directement la couche Firecracker qui propulsait déjà secrètement plus de 15 000 milliards d'invocations Lambda par mois.

Dans cet article, nous allons explorer ce que Lambda MicroVMs apporte concrètement, pourquoi c'est un game-changer pour les bastions et les sandboxes, puis nous construirons pas à pas un équivalent de Cloud9 basé sur OpenVSCode Server, Lambda MicroVM et Amazon EFS pour la persistance du code.

Lambda MicroVMs : ce que c'est (et ce que ce n'est pas)

Architecture et spécifications

Lambda MicroVMs repose sur le modèle image-then-launch :

Vous fournissez un Dockerfile + code source packagé en zip sur S3
Lambda exécute le Dockerfile, lance votre application via ENTRYPOINT ou CMD, attend le signal /ready (hook optionnel), puis capture un snapshot Firecracker (mémoire + disque)
Chaque lancement ultérieur reprend depuis ce snapshot pré-initialisé — démarrage quasi-instantané

Le sizing suit un modèle baseline-peak : vous configurez une baseline, et la MicroVM peut burst jusqu'à 4x cette baseline automatiquement. Vous payez la baseline tant que la MicroVM tourne, et uniquement le surplus consommé au-delà.

Baseline	Peak (burst 4x)	Disque max
0,5 Go / 0,25 vCPU	2 Go / 1 vCPU	8 Go
1 Go / 0,5 vCPU	4 Go / 2 vCPU	8 Go
2 Go / 1 vCPU (défaut)	8 Go / 4 vCPU	8 Go
4 Go / 2 vCPU	16 Go / 8 vCPU	16 Go
8 Go / 4 vCPU	32 Go / 16 vCPU	32 Go

Autres caractéristiques :

Caractéristique	Valeur
Architecture	ARM64 (Graviton) uniquement
Durée max	8 heures (28 800 secondes)
Isolation	Firecracker microVM — kernel dédié, pas de partage entre sessions
OS	Amazon Linux 2023 (base image managée par Lambda)
Protocoles inbound	HTTP/1.1, HTTP/2, WebSockets, gRPC, SSE
Authentification	Token JWE obligatoire (`X-aws-proxy-auth`)

Ce qui différencie Lambda MicroVMs

Le positionnement est clair : Lambda MicroVMs se situe entre Lambda Functions et EC2 :

Lambda Functions : stateless, 15 min max, event-driven, scale-to-zero
Lambda MicroVMs : stateful, 8h max, interactive, suspend/resume avec état intact
EC2 : stateful, illimité, mais vous gérez tout (AMI, scaling, patching...)

Le modèle économique est intéressant : 0\$ de compute pendant la suspension. Vous payez uniquement le stockage du snapshot (~0,08\$/Go/mois) et les opérations de suspend/resume. Pour des workloads qui utilisent beaucoup le burst (exactement le profil d'un développeur ou d'un agent IA), c'est redoutable.

Cas d'usage : bastions et sandboxes

Bastions éphémères serverless

Traditionnellement, un bastion SSH est une instance EC2 t3.micro qui tourne 24/7 dans un subnet public ou privé, avec un coût fixe mensuel et une surface d'attaque permanente. Avec Lambda MicroVMs, vous pouvez repenser complètement cette approche :

Le concept : un bastion qui n'existe que quand vous en avez besoin, avec isolation VM complète, et qui disparaît après usage.

# Créer un network connector VPC pour le bastion (une seule fois)
aws lambda-core create-network-connector \
  --name bastion-vpc-egress \
  --configuration '{
    "VpcEgressConfiguration": {
      "SubnetIds": ["subnet-private-a"],
      "SecurityGroupIds": ["sg-bastion"],
      "NetworkProtocol": "IPv4",
      "AssociatedComputeResourceTypes": ["MicroVm"]
    }
  }' \
  --operator-role arn:aws:iam::123456789012:role/NetworkConnectorOperatorRole

# Lancer un bastion éphémère
aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:eu-west-1:123456789012:microvm-image:bastion-hardened \
  --execution-role-arn arn:aws:iam::123456789012:role/BastionMicroVMRole \
  --ingress-network-connectors "arn:aws:lambda:eu-west-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \
  --egress-network-connectors "arn:aws:lambda:eu-west-1:123456789012:network-connector:bastion-vpc-egress" \
  --idle-policy '{"maxIdleDurationSeconds":1800,"suspendedDurationSeconds":600,"autoResumeEnabled":false}'

Avantages par rapport à un bastion EC2 classique :

Coût quasi-nul : le bastion est suspendu (gratuit en compute) quand personne ne l'utilise. Fini le t3.micro qui tourne 730h/mois pour 10h d'utilisation effective
Surface d'attaque réduite : pas de machine permanente exposée, kernel dédié sans partage
Immutabilité : chaque session repart d'un snapshot propre. Pas de drift de configuration, pas de malware persistant
Audit natif : chaque run-microvm est un événement CloudTrail. Qui a lancé quoi, quand, combien de temps
Auto-destruction : politique d'idle qui termine automatiquement le bastion après inactivité

Le bastion MicroVM est particulièrement pertinent pour les équipes qui pratiquent le Just-In-Time access : un SRE déclenche un bastion via une Step Function, obtient un accès temporaire à un RDS ou un cluster EKS, et le bastion est terminé 30 minutes plus tard.

Sandboxes pour agents IA et exécution de code non fiable

C'est le cas d'usage principal mis en avant par AWS. Les agents IA (coding assistants, data analysts, vulnerability scanners) ont besoin d'exécuter du code qu'ils génèrent eux-mêmes dans un environnement isolé. Lambda MicroVMs résout le trilemme classique :

Containers : démarrage rapide mais isolation faible (kernel partagé)
VMs EC2 : isolation forte mais démarrage lent et gestion lourde
Lambda MicroVMs : isolation hardware + démarrage rapide + zéro gestion

AWS a d'ailleurs publié une intégration native avec Claude Managed Agents : chaque appel d'outil de l'agent s'exécute dans une MicroVM dédiée, isolée du reste du système.

Pour les plateformes SaaS multi-tenant, c'est le pattern idéal : un étudiant qui exécute du Python sur votre plateforme éducative ne peut jamais accéder aux données d'un autre étudiant, car chaque session tourne dans son propre kernel.

Tutoriel : recréer Cloud9 avec Lambda MicroVM + VS Code OSS + EFS

AWS a retiré Cloud9 des offres pour les nouveaux comptes. Voici comment construire un environnement de développement cloud serverless qui le remplace en combinant Lambda MicroVM, OpenVSCode Server et Amazon EFS pour la persistance.

Architecture cible

┌─────────────────────────────────────────────────────────┐
│                    Développeur (navigateur)             │
│         https://mvm-xxx.lambda-microvm.eu-west-1.on.aws│
│         Header: X-aws-proxy-auth: <token>              │
└──────────────────────────────┬──────────────────────────┘
                               │ HTTPS (port 8080)
                               ▼
┌─────────────────────────────────────────────────────────┐
│              Lambda MicroVM (ARM64 / Graviton)          │
│              Baseline: 4 Go / 2 vCPU                   │
│              Peak: 16 Go / 8 vCPU (burst auto)         │
│                                                         │
│  ┌─────────────────────────────────────────────────┐    │
│  │         OpenVSCode Server (port 8080)           │    │
│  │         Extensions, terminal, LSP               │    │
│  └─────────────────────────────────────────────────┘    │
│                                                         │
│  ┌─────────────────────────────────────────────────┐    │
│  │         /home/developer/workspace               │    │
│  │         (local ou mount EFS optionnel)          │    │
│  └─────────────────────────────────────────────────┘    │
│                                                         │
│  Runtime: Node.js 20, Python 3.12, AWS CLI v2           │
└─────────────────────────────────────────────────────────┘
                               │ (optionnel) NFS via VPC
                               ▼            egress connector
┌─────────────────────────────────────────────────────────┐
│              Amazon EFS (Access Point /dev/workspace)   │
│              Persistance du code entre sessions         │
│              Throughput mode: elastic                   │
└─────────────────────────────────────────────────────────┘

Étape 1 : créer le filesystem EFS

# Créer le filesystem
aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode elastic \
  --encrypted \
  --tags Key=Name,Value=dev-workspace-efs \
  --region eu-west-1

# Créer un Access Point dédié
aws efs create-access-point \
  --file-system-id fs-0abc123def456 \
  --posix-user Uid=1000,Gid=1000 \
  --root-directory "Path=/dev/workspace,CreationInfo={OwnerUid=1000,OwnerGid=1000,Permissions=755}"

# Créer les mount targets dans les subnets privés
aws efs create-mount-target \
  --file-system-id fs-0abc123def456 \
  --subnet-id subnet-private-a \
  --security-groups sg-efs-access

Étape 2 : construire l'image MicroVM

Voici le Dockerfile qui crée notre environnement de développement. On utilise l'image de base container public.ecr.aws/lambda/microvms:al2023-minimal fournie par AWS, qui est compatible avec le processus de snapshot Firecracker :

FROM public.ecr.aws/lambda/microvms:al2023-minimal
USER root

# Outils système de base
RUN dnf install -y \
    nodejs20 npm \
    python3.12 python3.12-pip \
    git wget unzip tar gzip \
    && dnf clean all

# AWS CLI v2
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip" \
    && unzip awscliv2.zip && ./aws/install && rm -rf aws awscliv2.zip

# OpenVSCode Server (build ARM64)
ARG OPENVSCODE_VERSION=1.109.5
RUN mkdir -p /opt/vscode \
    && curl -fsSL "https://github.com/gitpod-io/openvscode-server/releases/download/openvscode-server-v${OPENVSCODE_VERSION}/openvscode-server-v${OPENVSCODE_VERSION}-linux-arm64.tar.gz" \
    | tar xz --strip-components=1 -C /opt/vscode

# Créer l'utilisateur développeur avec workspace local
RUN useradd -m -u 1000 -s /bin/bash developer \
    && mkdir -p /home/developer/workspace \
    && mkdir -p /home/developer/.openvscode-server/data/Machine \
    && chown -R developer:developer /home/developer

# Pré-configurer pour désactiver le workspace trust (évite le reload loop)
RUN echo '{"security.workspace.trust.enabled": false}' \
    > /home/developer/.openvscode-server/data/Machine/settings.json \
    && chown developer:developer /home/developer/.openvscode-server/data/Machine/settings.json

# Script d'entrypoint
COPY entrypoint.sh /opt/entrypoint.sh
RUN chmod +x /opt/entrypoint.sh

# Extensions VS Code pré-installées
RUN su - developer -c "/opt/vscode/bin/openvscode-server \
    --install-extension ms-python.python \
    --install-extension dbaeumer.vscode-eslint \
    --install-extension esbenp.prettier-vscode \
    --install-extension amazonwebservices.aws-toolkit-vscode"

EXPOSE 8080

WORKDIR /home/developer/workspace

CMD ["/opt/entrypoint.sh"]

Quelques points importants sur ce Dockerfile :

USER root : nécessaire pour installer les paquets système et créer l'utilisateur. L'entrypoint switchera vers developer pour lancer VS Code
OPENVSCODE_VERSION=1.109.5 : version ARM64 stable de OpenVSCode Server
Workspace trust désactivé : sans cette configuration, OpenVSCode Server entre dans un reload loop au premier accès car il demande à l'utilisateur de « faire confiance » au workspace
Extensions pré-installées : elles sont incluses dans le snapshot, donc disponibles instantanément au démarrage sans téléchargement

Étape 3 : le script d'entrypoint

L'entrypoint lance OpenVSCode Server en tant qu'utilisateur developer. Le montage EFS est géré au niveau de la MicroVM via le VPC egress connector — la MicroVM accède à EFS par le réseau NFS depuis le subnet privé configuré.

#!/bin/bash
# entrypoint.sh — Lance OpenVSCode Server

set -e

# Lancer OpenVSCode Server en tant que developer
exec su - developer -c "/opt/vscode/bin/openvscode-server \
    --host 0.0.0.0 \
    --port 8080 \
    --without-connection-token \
    --default-folder /home/developer/workspace"

Note sur EFS : le Dockerfile fourni ne contient pas nfs-utils et ne monte pas EFS dans l'entrypoint. Pour ajouter la persistance EFS, deux options :

Montage NFS dans l'entrypoint : ajouter nfs-utils au Dockerfile, activer --additional-os-capabilities '["ALL"]' lors du create-microvm-image (nécessaire pour mount), et monter EFS avant de lancer VS Code

Workspace local : utiliser /home/developer/workspace comme stockage éphémère — le code est perdu à la terminaison mais conservé pendant suspend/resume (le snapshot préserve l'état disque)

L'option 1 avec montage EFS dans l'entrypoint ressemblerait à :

#!/bin/bash
# entrypoint.sh — Version avec montage EFS

set -e

EFS_DNS="${EFS_FILE_SYSTEM_ID}.efs.${AWS_REGION}.amazonaws.com"
MOUNT_POINT="/home/developer/workspace"

# Monter EFS (nécessite nfs-utils dans le Dockerfile + additionalOsCapabilities)
if ! mountpoint -q "$MOUNT_POINT"; then
    mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 \
        "${EFS_DNS}:/" "$MOUNT_POINT"
    chown developer:developer "$MOUNT_POINT"
fi

# Lancer OpenVSCode Server en tant que developer
exec su - developer -c "/opt/vscode/bin/openvscode-server \
    --host 0.0.0.0 \
    --port 8080 \
    --without-connection-token \
    --default-folder /home/developer/workspace"

Pour activer les capabilities OS nécessaires au montage NFS, ajoutez --additional-os-capabilities lors de la création de l'image :

aws lambda-microvms create-microvm-image \
  --name vscode-dev-environment \
  --code-artifact uri=s3://my-microvm-artifacts/vscode-microvm.zip \
  --base-image-arn arn:aws:lambda:eu-west-1:aws:microvm-image:al2023-1 \
  --build-role-arn arn:aws:iam::123456789012:role/MicroVMBuildRole \
  --environment-variables '{"EFS_FILE_SYSTEM_ID":"fs-0abc123def456"}' \
  --additional-os-capabilities '["ALL"]'

Étape 4 : packager et créer l'image MicroVM

# Packager le code source
zip -r vscode-microvm.zip Dockerfile entrypoint.sh

# Uploader sur S3
aws s3 cp vscode-microvm.zip s3://my-microvm-artifacts/vscode-microvm.zip

# Créer l'image MicroVM
aws lambda-microvms create-microvm-image \
  --name vscode-dev-environment \
  --code-artifact uri=s3://my-microvm-artifacts/vscode-microvm.zip \
  --base-image-arn arn:aws:lambda:eu-west-1:aws:microvm-image:al2023-1 \
  --build-role-arn arn:aws:iam::123456789012:role/MicroVMBuildRole \
  --environment-variables '{"EFS_FILE_SYSTEM_ID":"fs-0abc123def456"}'

# Vérifier l'état du build
aws lambda-microvms get-microvm-image \
  --image-identifier vscode-dev-environment

Le build est asynchrone. L'image passe de CREATING à CREATED en succès, ou CREATE_FAILED en cas d'erreur. Consultez les logs CloudWatch sous /aws/lambda/microvms/vscode-dev-environment pour le diagnostic.

Étape 5 : lancer l'environnement de développement

# Créer un network connector VPC pour accéder à EFS (une seule fois)
aws lambda-core create-network-connector \
  --name dev-vpc-egress \
  --configuration '{
    "VpcEgressConfiguration": {
      "SubnetIds": ["subnet-private-a"],
      "SecurityGroupIds": ["sg-dev-microvm"],
      "NetworkProtocol": "IPv4",
      "AssociatedComputeResourceTypes": ["MicroVm"]
    }
  }' \
  --operator-role arn:aws:iam::123456789012:role/NetworkConnectorOperatorRole

# Lancer la MicroVM avec politique d'idle intelligente
aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:eu-west-1:123456789012:microvm-image:vscode-dev-environment \
  --execution-role-arn arn:aws:iam::123456789012:role/DevMicroVMRole \
  --ingress-network-connectors "arn:aws:lambda:eu-west-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \
  --egress-network-connectors "arn:aws:lambda:eu-west-1:123456789012:network-connector:dev-vpc-egress" \
  --idle-policy '{"maxIdleDurationSeconds":3600,"suspendedDurationSeconds":1800,"autoResumeEnabled":true}' \
  --maximum-duration-in-seconds 28800

La réponse contient l'endpoint HTTPS dédié et le MicroVM ID :

{
  "microvmId": "mvm-01234567-abcd-ef01-2345-6789abcdef01",
  "state": "PENDING",
  "endpoint": "mvm-01234567-abcd-ef01-2345-6789abcdef01.lambda-microvm.eu-west-1.on.aws"
}

Pour vous connecter, générez un token d'authentification :

# Générer un token valide 8h (durée max de la session)
aws lambda-microvms create-microvm-auth-token \
  --microvm-identifier mvm-01234567-abcd-ef01-2345-6789abcdef01 \
  --expiration-in-minutes 480 \
  --allowed-ports '[{"port":8080}]'

# Accéder à l'IDE dans le navigateur :
# https://mvm-01234567-abcd-ef01-2345-6789abcdef01.lambda-microvm.eu-west-1.on.aws
# Header requis : X-aws-proxy-auth: <token>

La politique d'idle est configurée pour suspendre la MicroVM après 1 heure d'inactivité, la garder suspendue 30 minutes, et la reprendre automatiquement au prochain accès HTTP. Pour un développeur qui fait des pauses café ou des réunions, la MicroVM se suspend et se réveille de manière transparente.

Étape 6 : automatiser avec une Step Function

Pour une équipe, vous pouvez automatiser la provision avec une Step Function déclenchée par un portail interne :

{
  "Comment": "Provision dev environment on demand",
  "StartAt": "RunMicroVM",
  "States": {
    "RunMicroVM": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:lambdamicrovms:runMicrovm",
      "Parameters": {
        "ImageIdentifier": "arn:aws:lambda:eu-west-1:123456789012:microvm-image:vscode-dev-environment",
        "ExecutionRoleArn": "arn:aws:iam::123456789012:role/DevMicroVMRole",
        "IngressNetworkConnectors": ["arn:aws:lambda:eu-west-1:aws:network-connector:aws-network-connector:ALL_INGRESS"],
        "EgressNetworkConnectors": ["arn:aws:lambda:eu-west-1:123456789012:network-connector:dev-vpc-egress"],
        "IdlePolicy": {
          "MaxIdleDurationSeconds": 3600,
          "SuspendedDurationSeconds": 1800,
          "AutoResumeEnabled": true
        },
        "MaximumDurationInSeconds": 28800
      },
      "ResultPath": "$.microvm",
      "Next": "NotifyDeveloper"
    },
    "NotifyDeveloper": {
      "Type": "Task",
      "Resource": "arn:aws:states:::sns:publish",
      "Parameters": {
        "TopicArn": "arn:aws:sns:eu-west-1:123456789012:dev-notifications",
        "Message.$": "States.Format('Votre IDE est prêt : {}', $.microvm.Endpoint)"
      },
      "End": true
    }
  }
}

Pourquoi le suspend/resume change la donne (et EFS en option)

Le point clé de cette architecture est le modèle suspend/resume natif de Lambda MicroVMs :

Pendant le suspend : le snapshot Firecracker préserve l'intégralité de la mémoire et du disque. Votre code, vos fichiers ouverts dans VS Code, votre historique terminal — tout est intact au resume
La MicroVM est éphémère mais stateful : tant qu'elle n'est pas terminée, le workspace persiste entre les sessions suspend/resume
EFS pour la persistance long-terme : si vous avez besoin que le code survive à la terminaison de la MicroVM (après 8h max ou idle trop long), ajoutez EFS comme décrit à l'étape 3

Sans EFS, le workflow est :

La MicroVM tourne → vous codez
Idle 1h → Lambda suspend (0\$ compute, snapshot préservé)
Vous revenez → auto-resume en ~1-2 secondes, tout est là
Après 8h ou terminaison → workspace perdu

Avec EFS :

Même workflow, mais le code est sur un montage NFS
Terminaison → vous relancez une MicroVM, EFS est remonté, code intact
Partage possible : plusieurs développeurs peuvent monter le même EFS (ou des Access Points différents) pour du pair programming

Étape 7 : proxy local pour l'accès navigateur

Un navigateur ne peut pas injecter le header X-aws-proxy-auth sur chaque requête HTTP et WebSocket. Pour accéder à OpenVSCode Server depuis votre poste, vous avez besoin d'un proxy local qui :

Écoute sur http://localhost:8080
Forward chaque requête vers l'endpoint HTTPS de la MicroVM en ajoutant le token d'authentification
Gère les upgrades WebSocket (indispensables pour le terminal et le LSP de VS Code) en passant le token via les subprotocols lambda-microvms
Renouvelle automatiquement le token avant expiration

Voici un proxy minimal en Node.js :

// proxy.mjs — Proxy local d'authentification Lambda MicroVM
import http from "node:http";
import https from "node:https";
import { execSync } from "node:child_process";

const MICROVM_ID = process.env.MICROVM_ID;
const MICROVM_ENDPOINT = process.env.MICROVM_ENDPOINT;
const REGION = process.env.AWS_REGION || "eu-west-1";
const LOCAL_PORT = parseInt(process.env.PORT || "8080", 10);
const TOKEN_EXPIRATION_MINUTES = parseInt(process.env.TOKEN_EXPIRATION || "60", 10);

let authToken = null;
let tokenExpiresAt = 0;

function refreshToken() {
  const cmd = `aws lambda-microvms create-microvm-auth-token \
    --microvm-identifier ${MICROVM_ID} \
    --expiration-in-minutes ${TOKEN_EXPIRATION_MINUTES} \
    --allowed-ports '[{"allPorts":{}}]' \
    --region ${REGION} --output json`;
  const result = JSON.parse(execSync(cmd, { encoding: "utf-8" }));
  authToken = result.authToken["X-aws-proxy-auth"];
  tokenExpiresAt = Date.now() + (TOKEN_EXPIRATION_MINUTES - 5) * 60_000;
}

function getToken() {
  if (!authToken || Date.now() >= tokenExpiresAt) refreshToken();
  return authToken;
}

function getEndpoint() {
  if (MICROVM_ENDPOINT) return MICROVM_ENDPOINT;
  const cmd = `aws lambda-microvms get-microvm --microvm-identifier ${MICROVM_ID} --region ${REGION} --output json`;
  return JSON.parse(execSync(cmd, { encoding: "utf-8" })).endpoint;
}

const endpoint = getEndpoint();

// Forward HTTP
async function handleRequest(req, res) {
  const chunks = [];
  for await (const chunk of req) chunks.push(chunk);
  const body = Buffer.concat(chunks);

  const headers = { ...req.headers, host: endpoint, "x-aws-proxy-auth": getToken() };
  delete headers.connection;

  const proxyReq = https.request(
    { hostname: endpoint, port: 443, path: req.url, method: req.method, headers },
    (proxyRes) => {
      res.writeHead(proxyRes.statusCode, proxyRes.headers);
      proxyRes.pipe(res);
    }
  );
  proxyReq.on("error", () => { res.writeHead(502); res.end("Bad Gateway"); });
  if (body.length) proxyReq.write(body);
  proxyReq.end();
}

// Forward WebSocket upgrades
function handleUpgrade(req, socket, head) {
  const token = getToken();
  const headers = { ...req.headers, host: endpoint, connection: "Upgrade", upgrade: "websocket" };

  // Injecter le token via subprotocols WebSocket
  const existing = headers["sec-websocket-protocol"]?.split(",").map((p) => p.trim()) || [];
  headers["sec-websocket-protocol"] = [
    "lambda-microvms",
    `lambda-microvms.authentication.${token}`,
    "lambda-microvms.port.8080",
    ...existing,
  ].join(", ");
  headers["x-aws-proxy-auth"] = token;

  const proxyReq = https.request({ hostname: endpoint, port: 443, path: req.url, method: "GET", headers });

  proxyReq.on("upgrade", (proxyRes, proxySocket, proxyHead) => {
    // Filtrer les subprotocols lambda-microvms de la réponse
    let responseHead = "HTTP/1.1 101 Switching Protocols\r\n";
    for (const [key, value] of Object.entries(proxyRes.headers)) {
      if (key.toLowerCase() === "sec-websocket-protocol") {
        const filtered = value.split(",").map((p) => p.trim()).filter((p) => !p.startsWith("lambda-microvms"));
        if (filtered.length) responseHead += `${key}: ${filtered.join(", ")}\r\n`;
        continue;
      }
      responseHead += `${key}: ${value}\r\n`;
    }
    responseHead += "\r\n";
    socket.write(responseHead);
    if (proxyHead.length) socket.write(proxyHead);
    proxySocket.pipe(socket);
    socket.pipe(proxySocket);
    proxySocket.on("error", () => socket.destroy());
    socket.on("error", () => proxySocket.destroy());
  });

  proxyReq.on("response", (proxyRes) => {
    let resp = `HTTP/1.1 ${proxyRes.statusCode} ${proxyRes.statusMessage}\r\n`;
    for (const [k, v] of Object.entries(proxyRes.headers)) resp += `${k}: ${v}\r\n`;
    resp += "\r\n";
    socket.write(resp);
    proxyRes.pipe(socket);
  });

  proxyReq.on("error", () => socket.destroy());
  proxyReq.end();
}

const server = http.createServer(handleRequest);
server.on("upgrade", handleUpgrade);
server.listen(LOCAL_PORT, () => {
  console.log(`MicroVM proxy → http://localhost:${LOCAL_PORT} → https://${endpoint}`);
});

Utilisation :

# Lancer le proxy
MICROVM_ID=mvm-01234567-abcd-ef01-2345-6789abcdef01 \
MICROVM_ENDPOINT=mvm-01234567-abcd-ef01-2345-6789abcdef01.lambda-microvm.eu-west-1.on.aws \
  node proxy.mjs

# Ouvrir VS Code dans le navigateur
open http://localhost:8080

Le proxy renouvelle le token 5 minutes avant expiration, gère le protocole WebSocket avec les subprotocols lambda-microvms (requis par l'endpoint), et filtre ces subprotocols de la réponse pour ne pas perturber VS Code côté client.

Pourquoi un proxy local ? L'endpoint MicroVM est un service managé par Lambda avec authentification JWE obligatoire — il n'est pas possible de placer un ALB ou un CloudFront devant. Il n'y a pas non plus d'option d'accès non authentifié ni de custom domain. Le proxy local (ou un proxy déployé sur une instance/container dans votre VPC) est le pattern d'accès navigateur recommandé pour les cas interactifs comme un IDE.

Comparaison avec les alternatives

Critère	Cloud9 (ancien)	CodeCatalyst Dev Env	Lambda MicroVM + VS Code
Coût idle	Instance EC2 24/7	Stoppé = gratuit	Suspendu = ~0\$ compute
Démarrage	~60s (boot EC2)	~30-60s	~2s (resume snapshot)
Isolation	Shared tenancy	Container	Firecracker VM dédiée
Personnalisation	Limitée	Devfile	Dockerfile complet
Persistance	EBS	EBS	Suspend/resume + EFS optionnel
Durée max session	Illimitée	16h (puis stop auto)	8h
GPU	Non	Non	Non (ARM64 uniquement)

Considérations de sécurité et bonnes pratiques

IAM least privilege : le rôle d'exécution ne doit avoir accès qu'aux services nécessaires au développeur. Le rôle de l'opérateur network connector se limite à la création d'ENIs
VPC egress connector : routez le trafic sortant via un subnet privé avec un NAT Gateway pour l'accès internet, et des security groups pour contrôler l'accès aux ressources internes (EFS, RDS...)
Authentification : chaque requête vers l'endpoint MicroVM nécessite un token JWE (X-aws-proxy-auth). Scopez les tokens sur le port 8080 uniquement et avec une expiration courte pour les environnements partagés
Chiffrement : EFS chiffré at-rest (KMS) + in-transit (NFS over TLS). Le trafic entre le client et l'endpoint MicroVM est toujours chiffré en TLS
Logs : les logs de build et d'exécution sont dans CloudWatch sous /aws/lambda/microvms/<image-name>. Chaque run-microvm est tracé dans CloudTrail

Conclusion

Lambda MicroVMs n'est pas juste un nouveau service — c'est un changement de paradigme dans la façon dont on conçoit les environnements de calcul éphémères sur AWS. La combinaison d'une isolation hardware Firecracker, d'un démarrage quasi-instantané depuis snapshot, et d'un modèle de facturation à 0\$ pendant la suspension ouvre des possibilités qui étaient auparavant réservées à des startups spécialisées comme E2B ou Daytona.

Que ce soit pour des bastions JIT qui réduisent votre surface d'attaque, des sandboxes d'agents IA qui exécutent du code non fiable en toute sécurité, ou un IDE cloud DIY qui remplace Cloud9 — Lambda MicroVMs mérite une place dans votre boîte à outils architecturale.

Le tutoriel présenté ici avec OpenVSCode Server + EFS est un point de départ. Vous pouvez l'enrichir avec du pair programming (multiple Access Points), des templates par projet (une image MicroVM par stack technique), ou même un système de facturation interne par développeur grâce aux tags CloudWatch.

Sources :

Déléguer les services AWS liés à l'organisation sur des comptes membres

sylvainbruas — Wed, 12 Aug 2026 08:12:06 +0000

Le compte AWS payeur est la brique centrale de votre landing zone. C'est ce compte qui détient les informations de facturation ainsi que la racine de l'organisation.

Au fil des années, AWS a ajouté de nombreuses fonctionnalités autour de l'organisation pour pouvoir travailler à l'échelle et faciliter la maintenance de la landing zone. Le compte payeur devenait de plus en plus stratégique au fil des services ajoutés.

En 2020, AWS a mis en place pour la première fois la délégation de compte vers un compte membre (pour le service IAM Access Analyzer). Cela a permis de déplacer les responsabilités pour ce service, et au fil des mois de nouveaux services ont profité de la délégation pour s'affranchir de la contrainte du compte payeur.

Mes clients font preuve de prudence quand on parle du compte payeur, une liste très limitée d'utilisateurs ont accès à ce compte, avec un respect strict du moindre privilège.

Nous allons voir les services principaux qui peuvent être délégués, et nous allons les regrouper pour optimiser leur utilisation pour chaque équipe, et pour sécuriser ces services plus facilement en les déléguant sur les bons comptes.

Qu'est-ce que la Délégation de Services AWS ?

La délégation de services AWS est le mécanisme qui permet à un service AWS (comme AWS Config ou AWS Systems Manager) d'effectuer des opérations et de gérer des ressources au nom de votre organisation, et surtout, de désigner un compte membre spécifique pour administrer ce service pour l'ensemble de l'organisation.

Il existe deux concepts clés à comprendre :

Accès de confiance (Trusted Access)

C'est la première étape. Lorsque vous activez l'accès de confiance pour un service AWS avec AWS Organizations, vous autorisez ce service à créer des rôles liés au service (Service-Linked Roles) dans vos comptes membres. Ces rôles permettent au service d'accéder aux ressources nécessaires pour fonctionner au niveau de l'organisation. C'est une permission large, mais nécessaire pour l'intégration. Par exemple, si vous activez l'accès de confiance pour AWS Config, AWS Config pourra déployer des règles et collecter des données de conformité dans tous les comptes de votre organisation.

Administrateur Délégué (Delegated Administrator)

C'est le cœur de la délégation. Au lieu que le compte de gestion (Management Account) soit le seul à pouvoir administrer un service pour toute l'organisation, vous pouvez désigner un compte membre spécifique comme « administrateur délégué » pour ce service. Ce compte délégué peut alors effectuer des opérations d'administration pour le service dans tous les comptes de l'organisation, sans avoir besoin d'accéder directement au compte de gestion.

Imaginez le compte de gestion comme le PDG de l'entreprise. Il définit la stratégie globale. La délégation de services, c'est comme nommer un directeur de département (le compte administrateur délégué) qui gère les opérations quotidiennes de son département (le service AWS) pour toutes les filiales (les comptes membres), sans que le PDG n'ait à s'immiscer dans chaque détail opérationnel. Cela permet de décharger le compte de gestion de tâches opérationnelles et de renforcer le principe du moindre privilège.

Les services liés à l'organisation et les possibilités de délégation

Nous pouvons trouver la liste complète de tous les services pouvant être délégués ici : Services AWS que vous pouvez utiliser avec AWS Organizations

Nous allons définir quelle équipe de l'entreprise pourrait être responsable de chaque service, pour ensuite déployer la délégation de service sur les comptes correspondants. Nous allons choisir en priorité les équipes qui effectueront les actions sur les comptes AWS et le maintien en condition opérationnelle (MCO / RUN).

Pour plusieurs services, nous pouvons configurer une délégation sur plusieurs comptes AWS. Je vous conseille de limiter à un compte la délégation pour que l'on soit aligné avec le RACI (Responsible, Accountable, Consulted et Informed). Chaque fonctionnalité doit être prise en charge (Accountable) par une équipe pour éviter tout conflit ou zone non couverte (« Ce n'est pas ma responsabilité mais celle de l'autre équipe »).

Service	Equipes possibles	Equipe responsable
AWS Account Management	Opérations	Opérations
AWS Backup	Opérations	Opérations
AWS Billing and Cost Management	FinOps	FinOps
AWS Systems Manager	Opérations	Opérations
AWS CloudFormation StackSets	Opérations	Opérations
AWS CloudTrail	Sécurité ou Opérations	Sécurité (1)
Amazon CloudWatch	Opérations	Opérations
AWS Compute Optimizer	FinOps ou Opérations	FinOps
AWS Config	Sécurité ou Opérations	Opérations (2)
AWS Config Aggregator	Sécurité ou Opérations	Opérations (2)
AWS Cost Optimization Hub	FinOps	FinOps
Amazon GuardDuty	Sécurité ou Opérations	Sécurité
AWS Health	Opérations	Opérations
Root Management pour comptes membres	Sécurité ou Opérations	Sécurité (3)
AWS License Manager	FinOps ou Opérations	Opérations (4)
AWS Network Manager	Réseau ou Opérations	Réseau
AWS Resource Explorer	FinOps ou Opérations	Opérations (5)
Amazon Simple Storage Service (S3) Storage Lens	FinOps ou Opérations	Opérations (5)
AWS Security Hub	Sécurité	Sécurité
AWS Service Catalog	Opérations	Opérations
AWS IAM Identity Center	Sécurité ou Opérations	Opérations
AWS User Notifications	Opérations	Opérations
AWS Trusted Advisor	FinOps ou Opérations	FinOps
Amazon Virtual Private Cloud (VPC) IP Address Manager (IPAM)	Réseau	Réseau
Amazon VPC Reachability Analyzer	Réseau ou Opérations	Réseau
Amazon Security Lake	Sécurité	Sécurité

(1) : Le choix sur ce point est assez complexe, et les 2
équipes proposées pourraient parfaitement être responsables de ce point. Cette
fonctionnalité touche les la gestion des logs d'audit, ce qui reste un point
très sensible, et donc nous allons privilégier l'équipe sécurité qui est garante
des données critiques, sensibles et confidentielles.

(2) : Malgré le fait que AWS Config soit un service de
sécurité et indispensable pour la gouvernance, il est plus intéressant de le
déléguer à l'équipe opérations. L'équipe sécurité va définir les objectifs (en
se basant sur les obligations légales et des frameworks tels que PCI-DSS ou NIST
par exemple) et lister les tests de conformité à mettre en place. Les Opérations
vont implémenter ces demandes, rajouter d'autres tests, ajouter des remédiations
automatiques dans certains cas. En cas de non-conformité, les opérations seront
alertées et seront responsables de la remise en conformité de la ressource qui a
créé l'alarme. L'équipe sécurité sera informée de ces actions.

(3) : Le choix sur ce point est encore complexe, et les 2
équipes proposées pourraient parfaitement être responsables de ce point. J'ai
choisi de proposer plutôt l'équipe sécurité car dans les grands groupes où j'ai
pu intervenir, la taille et la formation des équipes sécurité était suffisante
pour répondre aux demandes (réactivation exceptionnelle des comptes root ou
déblocage Amazon Simple Queue Service (SQS) et S3). Cette fonctionnalité touche les comptes root, ce qui reste
un point très sensible, et donc nous allons privilégier l'équipe sécurité qui
est garante des données critiques, sensibles et confidentielles.

(4) : Les licences sont un point qui doit être précisément
suivi par les FinOps pour éviter toute pénalité. Ce sont les équipes opérations
qui vont déployer les licences et faire le suivi de leur utilisation. Il est
donc nécessaire que les opérations soient responsables de ce point (Responsible)
et qu'elles partagent les informations de suivi avec les FinOps qui sont
validateurs et responsables de l'utilisation (Accountable).

(5) : Cette fonctionnalité peut être utile pour les FinOps,
mais les utilisateurs principaux seront dans l'équipe opérations.

Avantages de la Délégation de Services

La délégation de services apporte de nombreux bénéfices à votre organisation.

Gouvernance centralisée et simplifiée : Le compte de gestion reste léger et se concentre sur la gouvernance de haut niveau (création de comptes, OUs, SCPs). Les opérations quotidiennes et la gestion des services sont déléguées à des comptes membres spécialisés, réduisant la charge sur le compte racine.
Sécurité améliorée : Réduit la surface d'attaque du compte de gestion en limitant les opérations directes sur celui-ci. La gestion des permissions est plus aisée dans les comptes membres, car la portée de chacun est réduite. Cela permet une application cohérente des politiques de sécurité et une meilleure posture globale.
Principe du moindre privilège : Renforce ce principe fondamental de sécurité. Les équipes n'ont accès qu'aux services nécessaires à leurs missions. Par exemple, le compte de gestion n'a pas besoin d'accéder aux données de sécurité agrégées, c'est le compte de sécurité délégué qui le fait.
Évolutivité : Facilite l'ajout de nouveaux comptes à l'organisation, car ils héritent automatiquement des configurations déléguées des services, réduisant le temps de mise en conformité des nouveaux environnements.

Défis liés à la délégation

Malgré ses nombreux avantages, la délégation de services présente certaines limites.

Complexité initiale : La mise en place demande une bonne compréhension d'AWS Organizations, IAM, et des services spécifiques que vous souhaitez déléguer. Ce n'est pas encore une solution « plug-and-play » et nécessite une planification minutieuse.
Dépendance au compte administrateur délégué : Le compte désigné comme administrateur délégué devient un point de contrôle critique pour le service qu'il gère. Sa sécurité est primordiale. Une compromission de ce compte peut avoir des répercussions sur toute l'organisation pour le service délégué.
Portée des permissions : Il est crucial de comprendre précisément quelles permissions le service délégué obtient et ce que l'administrateur délégué peut faire. Une mauvaise configuration peut entraîner des permissions excessives ou des lacunes de sécurité.
Pas tous les services ne supportent la délégation : C'est une limite importante. Avant de planifier, vérifiez toujours la documentation AWS pour confirmer si le service que vous souhaitez déléguer prend en charge la fonctionnalité "Delegated Administrator" ou "Trusted Access" avec AWS Organizations. La liste des services évolue régulièrement.
Impact sur les SCPs : Les SCPs peuvent toujours restreindre les actions des administrateurs délégués. Assurez-vous que vos SCPs n'empêchent pas les actions nécessaires à la gestion déléguée du service.

Recommandations

Pour tirer le meilleur parti de la délégation de services et éviter les pièges, suivez ces bonnes pratiques :

Planification Rigoureuse : Ne vous lancez pas à l'aveugle. Définissez clairement les rôles, les responsabilités, les services à déléguer et les comptes qui seront administrateurs délégués. Gardez en tête que la transformation du modèle opérationnel et des équipes reste un des grands challenges de la délégation.
Principe du Moindre Privilège (encore et toujours !) : Appliquez des politiques IAM strictes aux rôles et utilisateurs dans le compte administrateur délégué. Ils ne devraient avoir que les permissions nécessaires pour administrer le service délégué, et rien de plus.
Surveillance : Utilisez AWS CloudTrail pour auditer toutes les actions effectuées par les services délégués et les administrateurs délégués.
Automatisation (IaC) : Utilisez l'Infrastructure as Code (IaC) pour gérer la configuration d'AWS Organizations et la délégation de services. Cela assure la cohérence, la reproductibilité et facilite les mises à jour.
Documentation : Documentez minutieusement votre stratégie de délégation, les services délégués, les comptes administrateurs et les processus associés. C'est vital pour la maintenabilité et la compréhension par les équipes.
Formation des équipes : Assurez-vous que vos équipes comprennent le nouveau modèle de gouvernance et leurs responsabilités dans un environnement délégué.
Tests : Testez toujours vos configurations de délégation dans un environnement non-production avant de les déployer à grande échelle. Validez que les services fonctionnent comme prévu et que les permissions sont correctement appliquées.

Conclusion

La délégation de services AWS est intéressante et peut devenir une nécessité pour une organisation souhaitant opérer sur AWS à grande échelle de manière sécurisée, conforme et efficace. Pour des organisations plus modestes, qui n'ont pas d'obligations légales ou qui n'ont pas d'équipes opérationnelles ou de sécurité de taille suffisante, il peut être intéressant de rester sur un modèle centralisé.

Dans tous les cas, une gestion rigoureuse des permissions IAM est nécessaire pour assurer la sécurité de la landing zone.

Mon conseil : commencez par un service clé comme AWS Config ou AWS CloudFormation StackSets, maîtrisez le concept, puis étendez progressivement à d'autres services. La route vers une gouvernance cloud optimale est un marathon, pas un sprint. Investissez dans la planification et l'automatisation, et vous récolterez les fruits d'un environnement AWS bien géré et sécurisé.

Build Games Challenge: Une bonne raison pour tester la puissance d'amazon Q

sylvainbruas — Wed, 12 Aug 2026 08:11:32 +0000

Q" width="800" height="400">

J'ai découvert hier ce challenge et, étant friand de rétro gaming, j'ai pensé que cela serait un bon support pour aborder également l'utilisation d'Amazon Q Developer CLI.

J'ai décidé de faire un hommage à un jeu qui m'a frustré quand j'étais en primaire, R-Type 2 sur Nintendo Super NES ( Description ).

Dépôt GIT du jeu

Vous trouverez ici tous les fichiers du jeu, ainsi que toutes les étapes intermédiaires depuis la création : https://github.com/sylvainbruas/r-type-like

Mécanique du jeu

Le jeu R-Type 2 était très simple et efficace :

5 niveaux à traverser, chacun se terminant par un boss.
Des environnements 8 bits très travaillés
Des groupes d'ennemis à détruire
Des bonus, de puissance ou des vies supplémentaires (très utile !)

C'était un jeu très exigeant et punitif. Même si 5 niveaux donnent l'impression d'un jeu très court, la difficulté est élevée, et passer le 2e niveau vous demandera déjà une bonne connaissance des patterns des ennemis pour vous en sortir.

Ma version sera bien plus simple, le but étant de montrer que l'on peut aller très vite et très loin juste en fournissant les bonnes informations à Amazon Q.

Setup de mon environnement

J'ai commencé par installer Amazon Q Developer en suivant la documentation, puis je me suis connecté avec mon builder ID.

Ce n'est pas le premier projet que je fais avec cet outil, j'ai donc créé un prompt que j'exécute pour chaque nouveau projet :

Initialise le projet avec un README en markdown, ajoute un suivi avec Git, crée un fichier questions.txt qui listera les demandes dans l'ordre et contiendra également une synthèse des actions pour y répondre. Après chaque action, crée un ou plusieurs commits Git pour regrouper les modifications qui ont du sens ensemble, avec un message de commit explicite.

J'ai ajouté les points suivants à mon prompt :

Tous les messages doivent être en français. Ajoute également des tests pour chaque nouvelle fonctionnalité que tu mets en place. Initialise-moi un README pour ce projet et pour les sous-répertoires où cela te semble nécessaire, et mets-le à jour régulièrement. Enfin, après avoir fait une correction, lance les tests pour vérifier que tout est en ordre.

Maintenant que j'ai partagé mes attentes pour l'organisation du projet, donnons le sujet à Amazon Q :

Créer un jeu inspiré de R-TYPE2 sur Super Nintendo. Ce jeu doit être jouable sur le navigateur. Laisser le choix de la bibliothèque la plus efficace pour faire cela. Il y aura 5 niveaux, chacun se terminant par un boss, et un système de points.

Je me retrouve donc avec la structure de projet suivante :

Bonus ! Amazon Q a eu la gentillesse de me faire des scripts de lancement du jeu.
J'ai des explications très claires dans le README, et toutes les informations pour faire le setup du projet dans SETUP.md.

Je n'aurais pas fait une documentation si complète, et la rédiger m'aurait mis de mauvaise humeur car ce n'est pas la partie que je préfère. Avec cet outil, je délègue ces tâches, et il ne me reste plus qu'à vérifier que le rendu est au niveau de mes attentes.

Si le résultat ne me convient pas, je prends du recul, et je me pose les
questions suivantes : - Suis-je vraiment clair sur ma demande ? - Est-ce qu'un
humain aurait pu comprendre ma demande de cette manière ?

Dans 90% des cas, effectivement j'ai fait un prompt trop vague et rapide. Je propose donc un second prompt pour corriger la demande, soit en la précisant, soit en la découpant en plusieurs parties.

Nouvelle Compétence Débloquée : Communication avancée !

En travaillant de cette manière, j'ai pu également améliorer la communication avec mes collègues. Je prends un peu plus de temps pour travailler mes formulations, le plan de mon discours, et j'ai ainsi amélioré la compréhension de mes demandes et réduit le nombre d'allers-retours.

Délégation du codage : premier pas

Dans ce projet, j'ai considéré Amazon Q comme un stagiaire. Il a de bonnes connaissances techniques et méthodologiques, mais parfois il se perd et ne prend pas de recul.
C'est à moi de lui donner les bonnes spécifications, suffisamment claires, tout en laissant également de la place pour qu'il exprime son talent et qu'il apporte sa propre vision.

À la fin du setup, j'obtiens un résultat visuel basique, une mécanique de jeu très limitée. On est loin de R-Type 2 !
Mais vu le prompt très sommaire, c'est un début encourageant.

Je recommande de diviser le projet en petits composants les plus unitaires possible, ainsi Amazon Q aura des besoins précis et nous éviterons les hallucinations ou les fonctionnalités délirantes. Il ne restera plus qu'à expliquer comment faire interagir ces composants pour avoir l'application finale.

Exemple :

Ajouter un système de vies pour le joueur (3 vies au début, perte d'une vie quand touché)

Nous ajoutons ainsi de manière incrémentale de nouvelles fonctionnalités, qui sont testées et validées au fil de l'avancement.

Nouvelle Compétence Débloquée : Gestion de projet agile !

Architecture

Après m'être concentré sur la partie développement, je me suis posé la question de l'hébergement.

Je reste dans mon rôle Product Owner, je partage donc le besoin avec Amazon Q :

Créer un répertoire AWS CloudFormation et créer des templates pour déployer ce jeu sur AWS. Utiliser de préférence Amazon CloudFront avec Amazon Simple Storage Service (S3) et créer un script de build pour optimiser les assets avant de les mettre sur le cloud.

Amazon Q propose une solution au-delà de ce qui est demandé, en apportant de bonnes pratiques. Il permet de déployer le projet dans 3 environnements différents.

Il ne reste plus qu'à relire le fichier, en utilisant nos propres compétences, pour vérifier que cette implémentation est bonne. Un vrai gain de temps quand on sait l'énergie que la lecture de la documentation CloudFormation peut demander.

Si le contenu semble correct, nous pouvons tester le code dans un
environnement de sandbox.

Nouvelle Compétence Débloquée : Génération d'Infrastructure as Code à la vitesse de la lumière !

Pour clore cette partie, ajoutons un peu de documentation, des tests et des diagrammes d'architecture.

Créer des schémas d'architecture logicielle du jeu en format draw.io.

Graphisme

Depuis mai 2025, il est possible d'utiliser Claude 4 dans Amazon Q.

Cela nous permet de créer des images pour le jeu mais aussi des diagrammes d'architecture.
Il est par exemple très pratique de demander une architecture en format draw.io, qui est facilement modifiable et où nous retrouvons les icônes AWS.
Je n'ai pas besoin d'utiliser un autre outil qu'Amazon Q pour mon jeu. Si le résultat n'était pas suffisant, j'aurais pu étendre les fonctionnalités d'Amazon Q avec des MCPs (Model Context Protocol). Ainsi, Amazon Q aurait pu router ma demande vers un outil plus performant pour y répondre.

Les résultats sont suffisants pour ce projet :

Debugging

Une fonctionnalité d'Amazon Q très utile est l'aide à la recherche d'erreur.
Comme l'outil a accès au contexte, il arrive très rapidement à trouver la source des erreurs, et les explique simplement avant de les corriger.

Astuce : demander à Amazon Q de relancer les tests à chaque fois qu'il corrige les erreurs. Ainsi il vérifie que tout est correct avant de vous rendre la main.
Il arrive que la correction ne soit que partiellement bonne, voire incorrecte. Dans ce cas, je regarde le code qu'il a modifié (car sur ce point il est impressionnant) et je lui donne une proposition différente de correction. Il va prendre en compte la proposition et souvent proposer une correction améliorée en prenant en compte le contexte de l'application.

Documentation et tests

Je dois avouer que c'est un grand plus pour moi.

Amazon Q va me préparer un ensemble de tests intéressants, des rapports précis et je peux lui demander de rajouter d'autres tests si nécessaire.

Dans notre cas, je suis resté assez simple :

Écris-moi des tests pour valider que les fonctions du jeu sont correctes. Je dois avoir un rapport complet, avec un résumé des résultats en début, puis le détail des tests et des erreurs trouvées. Si je te demande de corriger une erreur, ajoute un nouveau test pour s'assurer que celle-ci ne reviendra plus.

Amazon Q me fournit un rapport sous ce format :

Ce que j'ai appris

Nous sommes encore loin du résultat final, je vais continuer à faire évoluer ce projet.
Nous avons des bases solides :

une documentation à jour et accessible
des tests sur plusieurs niveaux
des scripts pour lancer l'application, la compiler et la déployer
des templates pour créer de l'infrastructure, avec une gestion de plusieurs environnements.

Ce résultat n'a demandé que peu d'efforts et de temps. Je me suis concentré sur les besoins, j'ai fourni à Amazon Q des prompts très simples, en lui laissant le temps de coder le tout.

Ce développement s'est donc fait juste avant de me faire un café, entre
deux mails ou réunions. Cet assistant m'a permis d'être plus efficace, car j'ai
pu faire cette preuve de concept tout en travaillant, entre autres sur la
rédaction de ce post.

Même avec une interaction limitée sur ce projet j'ai appris :

savoir déléguer, organiser mes propos pour être bien compris
me concentrer sur CE QUE JE VEUX et non sur le COMMENT LE FAIRE
diviser les demandes en unités simples que l'on fera ensuite travailler ensemble
avoir une démarche agile, basée sur les tests, avec des itérations courtes et rapides

J'ai été surpris par les performances de cet assistant et particulièrement par :

la mise en place de bonnes pratiques et les propositions de mise en place d'améliorations de la sécurité ou des performances.
la prise en considération du contexte, le fait de ne pas simplement faire ce que je demande au niveau du code, mais aussi de mettre à jour les tests et la documentation de son propre chef.

AWS VPC centralisée ou VPC dans les comptes projets : Quand, Pourquoi et Comment ?

sylvainbruas — Wed, 12 Aug 2026 08:10:23 +0000

Bien que le partage d'Amazon Virtual Private Cloud (VPC) soit disponible depuis fin 2018, il est encore rare de le voir déployé dans les landing zones.

Cette possibilité peut apporter de nombreux gains en termes d'organisation et de répartition des tâches entre les équipes, des économies non négligeables, et une implémentation réseau alignée avec le modèle opérationnel de l'entreprise.
Nous allons voir ensemble les points qui vont pousser l'adoption de cette implémentation à la place d'une implémentation décentralisée, qui elle est le reflet d'une organisation plus orientée DevOps.

Les Challenges

Les VPCs sont difficilement extensibles, et il est compliqué de réorganiser les ressources qui sont à l'intérieur. Il est donc nécessaire de choisir la bonne implémentation dès la mise en place de la landing zone.

Il est également important de n'avoir aucun VPC avec un CIDR block (ensemble d'IP) identique, ce qui rendrait le routage complexe.

Dans les grands groupes, une portion importante des IP privées ont été consommées.
Souvent un CIDR Block /16 est assigné à un cloud provider, ce qui nécessite une réflexion importante pour organiser les VPCs et les subnets.

L'organisation de l'entreprise est aussi importante. La responsabilité du réseau peut être assumée par différentes équipes, et il est important que les politiques AWS Identity and Access Management (IAM) reflètent ces responsabilités.
Pour faciliter ces règles IAM, une organisation des comptes AWS rigoureuse est nécessaire.

La maîtrise des coûts et la sécurité sont les deux derniers domaines qui influencent l'organisation réseau.
Comme nous le verrons plus loin, les liaisons réseaux ont un coût non négligeable et peuvent à l'échelle devenir un problème financier.

VPC par compte, le modèle par défaut

Chaque compte AWS étant indépendant, nous pouvons donc aisément créer une infrastructure réseau indépendante.
Un VPC par défaut est fourni dans chaque compte, je vous déconseille de l'utiliser dans votre landing zone.

Il est donc aisé de créer les ressources réseau pour un projet lors de son déploiement. Nous avons un tout cohérent, et si nous devons terminer le projet, nous pourrons détruire toutes les ressources liées.
C'est également ce que l'on retrouve sur de nombreux modèles de projet (blueprint). En créant tous les éléments, du réseau à l'application, on s'assure que tous les éléments seront conformes et fonctionnels.

Ce modèle est également apprécié car il fait écho à la philosophie DevOps, où l'équipe projet est responsable de son périmètre.

Modèle centralisé

Le but de ce modèle est d'éviter le morcellement de la partie réseau. Dans ce modèle, nous allons créer un nombre limité de VPC, qui se trouveront dans le compte AWS gérant le réseau.
Il y aura au moins 2 VPCs, un pour la production et un pour la non-production. Cela permettra de gérer les flux entre ces 2 zones, et rassurera les équipes sécurité.
Le modèle de sous-réseau (Subnets) sera le même que pour le modèle décentralisé, c'est la taille de ces subnets qui sera supérieure.
Ces subnets seront ensuite partagés avec les comptes projets pour qu'ils puissent les utiliser.

Ce modèle reflète le modèle opérationnel où les équipes réseau et sécurité sont responsables des fondations réseau. Les équipes projets ne sont qu'utilisatrices des ressources mises à disposition et vont créer les ressources projets dans les sous-réseaux fournis sans pouvoir modifier leur fonctionnement.

Critères de sélection

Plusieurs critères entrent en compte, les plus impactants sont en premier :

Besoin de contrôle et de conformité lié à des contraintes légales

Si la séparation des responsabilités est un prérequis et que le réseau est géré par une équipe spécialisée, un modèle centralisé est la solution à privilégier. Chaque projet aura son compte AWS, mais ils ne pourront pas créer de composants réseau au sein de ces comptes.

Si la responsabilité du réseau est portée par le projet et non par une équipe centrale, un modèle décentralisé sera le meilleur choix.
Il faudra néanmoins déployer des outils permettant de vérifier la conformité à l'échelle. Ces outils devront être capables de récupérer et d'agréger des données venant de nombreux comptes.

Modèle opérationnel et responsabilité des équipes

Les mêmes arguments que la partie précédente sont à utiliser pour choisir le modèle. La seule différence est que ce n'est pas un besoin externe qui impose le choix, mais le fonctionnement de l'entreprise.

Il faut rester vigilant sur ce choix et penser à la transformation de l'entreprise en passant dans le cloud et la trajectoire pour les prochaines années.

Vous pouvez avoir un modèle centralisé car vous êtes en cours de
migration depuis le on-premise, mais la stratégie d'entreprise est de devenir
plus agile en laissant les projets porter leur responsabilité de bout en bout.
Dans ce cas, un modèle décentralisé sera à privilégier, avec un accompagnement
des équipes opérations / sécurité / réseau pour leur permettre d'évoluer et de
s'inscrire dans le nouveau modèle opérationnel.

Maîtrise des coûts

Un modèle décentralisé repose sur l'utilisation de la Transit Gateway pour passer à l'échelle. Mais ce modèle a un coût non négligeable, lié au nombre de VPC qui vont être créés.

Si la consommation de services AWS par VPC est faible (moins de 250$ par exemple, dans ce cas le réseau représente plus de 20% des dépenses), il est intéressant d'évaluer la possibilité de passer sur un modèle centralisé.

Un modèle décentralisé permettra également de plus facilement répartir les coûts par projets. Les ressources n'étant pas mutualisées et un compte AWS n'étant lié qu'à un projet, la somme des consommations par projet sera donc aisée.

Maturité de la société sur AWS

Si vous débutez sur AWS et que vous migrez depuis le on-premise, un modèle centralisé peut être rassurant car plus proche de ce que vous avez on-premise.

Si vous êtes une société en création, que vous voulez être agile et que vous n'avez pas une équipe réseau dédiée, un modèle décentralisé vous apportera plus de souplesse. Cela vous permettra par exemple de proposer de nouveaux produits, et s'ils ne trouvent pas leur public, vous n'aurez qu'à détruire le ou les comptes AWS associés pour ne plus avoir de dépenses.

Gestion des IPs

Si la gestion des IPs est un enjeu, et que chaque IP compte car votre entreprise a consommé presque toutes les possibilités d'adressage IP privé, il est recommandé de passer sur un modèle centralisé qui permettra de ne perdre que très peu d'IPs.

Si votre SI est d'une taille modeste, les 2 modèles peuvent être utilisés, ce sont d'autres critères qui guideront vos choix.

Isolation forte des projets

Si vous devez isoler fortement des projets, par exemple si vous offrez une plateforme SaaS pour des clients, il est recommandé d'utiliser un modèle décentralisé. Les ressources réseau et projets de chaque client seront isolés dans un compte AWS, et vous pourrez également ajouter du filtrage réseau au niveau de la Transit Gateway.

Mise en place de la VPC centralisée

Organisation des VPCs

Nous pouvons organiser les VPCs de différentes manières.

La première solution, la plus simple, est de faire une VPC pour la production et une autre pour la non-production.
L'avantage est que les IPs pour la production sont réservées, nous pouvons contrôler les flux entre les deux VPCs.

La seconde solution est de faire un VPC par environnement. Cela permet un meilleur contrôle des flux est-ouest, et une garantie d'un nombre d'IP par environnement.

Nous ajouterons une VPC supplémentaire pour les outils réseau comme les points de terminaison VPC (VPC Endpoints), la gestion DNS ou la gestion de l'Egress, quelle que soit la solution proposée.
Ainsi, nous mutualisons les coûts des VPC Endpoints et de l'Egress.

Les VPCs doivent être suffisamment grandes pour répondre à vos besoins en IP pour les années à venir.
Il est possible d'étendre une VPC, mais cela reste une opération qui va ajouter de la complexité à votre landing zone.

Exemple

Vous avez 4 environnements : production, recette, intégration et développement.
Vous avez à disposition un CIDR block 10.0.0.0/16

Première solution

un VPC de production 10.0.0.0/18
un VPC de non-production (recette, intégration et développement) 10.0.128.0/17
il reste 10.0.64.0/18 pour les VPCs réseau, sandbox, ou les services partagés

VPC	Subnet address	Range of addresses
production	10.0.0.0/18	10.0.0.0 - 10.0.63.255
non-production	10.0.128.0/17	10.0.128.0 - 10.0.255.255
autre	10.0.64.0/18	10.0.64.0 - 10.0.127.255

Seconde solution

un VPC de production : 10.0.0.0/19
un VPC de recette (iso prod) : 10.0.64.0/18
un VPC d'intégration : 10.0.128.0/19
un VPC de développement : 10.0.160.0/19
il reste 10.0.192.0/18 pour les VPCs réseau, sandbox, ou les services partagés

VPC	Subnet address	Range of addresses
production	10.0.0.0/18	10.0.0.0 - 10.0.63.255
recette	10.0.64.0/18	10.0.64.0 - 10.0.127.255
intégration	10.0.128.0/19	10.0.128.0 - 10.0.159.255
développement	10.0.160.0/19	10.0.160.0 - 10.0.191.255
autre	10.0.192.0/18	10.0.192.0 - 10.0.255.255

Partage des subnets

Nous avons plusieures stratégies pour le partage des subnets.

1 - Centralisation des VPCs dans le compte réseau

C'est le modèle le plus simple, la séparation en VPC projet est conservée, la différence est que les VPCs se trouvent dans le compte réseau.

L'avantage de cette technique est qu'elle simplifie la gestion IAM pour le réseau, on s'assure ainsi que les projets ne pourront pas modifier les fondations mises en place.

2 - Un seul VPC, des subnets indépendants pour chaque compte

Ce modèle assure une isolation stricte entre les comptes, car chaque subnet est lié à un seul compte AWS.
Ainsi il n'y a pas de risque de manque d'IP venant d'un autre projet, les coûts d'interconnexions sont réduits car on a moins de VPCs.

Pour assurer une isolation parfaite, il est recommandé d'ajouter des listes de contrôle d'accès réseau (NACL) aux sous-réseaux pour ne laisser passer que les flux venant de sous-réseaux légitimes.

Cela ne facilite toujours pas suffisamment la gestion des adresses IP. Nous avons toujours des adresses IP utilisées dans chaque sous-réseau, et si nous n'avons plus d'adresses IP disponibles sur un sous-réseau, il faudra utiliser un nouveau sous-réseau pour étendre la plage d'adresses IP.

Cela nécessite encore de trouver la ou les bonnes tailles de sous-réseaux pour les projets, afin de réduire le nombre d'adresses IP non utilisées.

3 - Un seul VPC, des sous-réseaux partagés entre tous les comptes d'un même environnement

Dans cette solution, nous avons un petit nombre de sous-réseaux de grande taille partagés entre les comptes.
L'isolation est en place par design, nous le verrons un peu plus bas, et avec ce modèle nous obtenons une zone de travail où aucune IP ne sera potentiellement inutilisée, et il n'est plus nécessaire de réfléchir longuement à la taille de chacun des sous-réseaux.

Tout comme la solution précédente, le nombre d'interconnexions réseau est réduit au strict minimum pour maîtriser les coûts.

Responsabilité partagée

Comme nous l'avons vu plus haut, le modèle de VPC doit refléter le modèle de responsabilité entre les équipes. AWS a fait le nécessaire au niveau des droits, pour que cette séparation soit claire.
Source : Responsibilities and permissions for owners and participants

Responsabilité du compte qui partage

Il est responsable de la création, de la gestion et de la suppression des ressources associées à un VPC partagé (sous-réseaux, tables de routage, passerelles NAT, etc.).

La liste complète est disponible dans la documentation, et l'on peut vérifier
que ce ne sont que des composants de réseau, sécurité et routage qui peuvent
être gérés.

il ne peut pas modifier les interfaces réseau appartenant aux participants (attacher, détacher...).

Les interfaces sont visibles dans le compte qui partage, ce qui a du sens car
les interfaces utilisent les IPs du compte. Les informations sont limitées, on
ne sait rien sur la ressource liée.

il peut visualiser les groupes de sécurité créés par les participants.

Le principe d'observabilité est respecté, et les responsables du réseau et de
la sécurité peuvent examiner facilement ce qui est implémenté. Dans l'exemple
ci-dessous, nous pouvons voir des groupes de sécurité liés à d'autres comptes
avec la mention shared entre parenthèses.

Exemple :

il peut attacher une passerelle de transit à un sous-réseau VPC partagé. Le principe de responsabilité est bien respecté, et cela évite des dérives de sécurité (cartographie des flux) et financières (prix de l'attachement, coûts de trafic)

Responsabilité des comptes qui utilisent le partage

ils sont responsables des ressources VPC dont ils sont propriétaires.

Tout est dit, on respecte bien le modèle de responsabilité partagée
entre le compte qui partage et les comptes qui utilisent les sous-réseaux

ils ne peuvent créer qu'un ensemble limité de ressources VPC : groupes de sécurité, journaux de flux VPC (sur leurs interfaces réseau).
Les ressources VPC créées par un participant sont comptabilisées dans les quotas VPC du compte participant.
Les participants ne peuvent pas créer, attacher ni supprimer de passerelles Internet.

Cela nous assure qu'il n'y aura pas d'exposition publique incontrôlée.

Les participants ne peuvent pas créer ni supprimer de NAT Gateway.

On évite ainsi des coûts non maîtrisés (35$ par mois). Ce sont des
éléments de routage que les équipes réseaux doivent mettre en place, que les
NAT Gateway soient privées ou publiques. Les équipes projet ne sont
qu'utilisatrices de ces services.

Les participants ne peuvent pas créer, supprimer ni remplacer de listes de contrôle d'accès réseau (NACL)

La sécurité du réseau est la responsabilité des équipes réseau et
sécurité. Personne dans le compte participant ne pourra unilatéralement
modifier des règles de filtrage réseau.

Les participants peuvent visualiser les NACL

Le filtrage mis en place peut être visualisé par l'équipe projet
(transparence) et peut ainsi permettre de comprendre pourquoi certains
composants ne peuvent pas communiquer ensemble. Cela évite des frustrations et
peut faciliter le travail des équipes réseau qui pourront avoir des
indications claires des équipes projet.

Les participants ne peuvent pas travailler sur des tables de routage (par exemple, créer, supprimer ou associer des tables de routage)

Tous les éléments réseau sont bien gérés pour que le partage de
responsabilité soit respecté par défaut.

Les participants ne peuvent pas utiliser le groupe de sécurité par défaut du VPC

Ce n'est pas une bonne pratique d'utiliser le groupe de sécurité par
défaut d'un VPC.

La bonne pratique est de laisser ce groupe de sécurité sans règle, ce
qui bloque tout le trafic entrant et sortant. Donc ne pas pouvoir utiliser ce
groupe de sécurité ne posera pas de problème.

Les participants ne peuvent pas utiliser de groupes de sécurité qui appartiennent au propriétaire du VPC ou à d'autres participants, à moins que le groupe de sécurité ne soit partagé avec eux. Les règles des groupes de sécurité peuvent référencer un groupe de sécurité d'un autre compte. Ce qui permet de gérer via des noms les flux entre les applications. Il est nécessaire d'interdire l'utilisation d'un groupe de sécurité extérieur au compte car les règles liées à celui-ci pourraient être changées sans que le compte qui l'utilise soit informé.

Répartition des coûts

Dans un VPC partagé, chaque participant paie ses ressources applicatives. Ils paient également les frais de transfert de données entre zones de disponibilité, via les passerelles Internet et les passerelles AWS Direct Connect.

Les propriétaires de VPC paient des frais horaires ainsi que des frais de traitement et de transfert de données via les passerelles NAT, la Transit Gateway, PrivateLink et les points de terminaison VPC.

Les adresses IPv4 publiques utilisées dans les VPC partagés sont facturées aux
propriétaires de VPC.

Limites et points d'attention

Modèle centralisé et zones de disponibilité

Dans le modèle centralisé, comme le trafic ne quitte pas le VPC, vous ne payez pas de frais de réseau supplémentaires, mais uniquement les éventuels frais de réseau inter-zones.

Il est important de noter que tous les comptes AWS disposent d'un mappage de zones de disponibilité aléatoire. Ainsi, la zone de disponibilité A du compte A peut être la zone de disponibilité B du compte B. Lors de l'utilisation d'un VPC partagé, il est important d'en tenir compte pour limiter les frais de réseau inter-zones. Une bonne utilisation des tags peut réduire ces coûts en nommant de manière claire les sous-réseaux en s'appuyant sur l'ID de zone de disponibilité.

Que se passe-t-il si le partage est coupé ?

Le propriétaire peut à tout moment annuler le partage d'un sous-réseau partagé. Une fois le partage d'un sous-réseau annulé, les règles suivantes s'appliquent :

Les ressources existantes des participants continuent de s'exécuter dans le sous-réseau.
Les participants ne peuvent plus créer de ressources dans le sous-réseau.
Les participants peuvent modifier, décrire et supprimer leurs ressources.
Si des participants disposent encore de ressources dans le sous-réseau, le propriétaire ne peut pas supprimer le sous-réseau partagé ni le VPC du sous-réseau partagé.

Pour conclure

Ces deux modèles sont complémentaires et répondent chacun à des besoins spécifiques.

Vous pouvez également appliquer chacun de ces modèles à une partie de votre système d'information.

Si vous avez par exemple des applications que vous voulez déplacer à
partir du on-premise et que vous ne pouvez pas transformer, vous pouvez les
héberger sur un VPC centralisé. Pour les nouveaux projets, vous pouvez utiliser
un modèle décentralisé qui apporte plus de souplesse aux équipes de
développement.

Il est important de choisir le modèle qui correspond à vos besoins (légaux, opérationnels, ...), qui soit efficace et aligné avec votre savoir-faire, plutôt que d'utiliser un modèle à la mode qui, au final, vous amènera à des coûts élevés et à des opérations plus complexes et coûteuses.

AWS CloudFront VPC Origin : Sécurisez et Optimisez vos sites web publics

sylvainbruas — Tue, 11 Aug 2026 09:23:52 +0000

Amazon CloudFront est l'un de mes services AWS préférés. Grâce à cet
outil, nous pouvons exposer des sites sur Internet, qu'ils soient
statiques ou dynamiques, hébergés ou non sur AWS, avec une sécurité renforcée.

Grâce à son déploiement au plus près de l'utilisateur, depuis 2008 ce
service permet de distribuer le contenu avec les meilleures
performances.

Pour mettre du contenu à disposition de CloudFront, nous avons 2
possibilités principales :

Utiliser Amazon Simple Storage Service (S3) ou AWS Lambda par exemple en utilisant
les Origin Access Control
Utiliser un équilibreur de charge (Load Balancer) ou une instance
publique.

Dans la suite de l'article, nous allons nous concentrer sur le cas de l'équilibreur de charge public.

Les groupes de sécurité (Security Groups) doivent être bien configurés pour ne permettre l'accès que depuis CloudFront. Des protections supplémentaires peuvent être mises en place comme un AWS Web Application Firewall (WAF) par exemple, qui offre une protection avancée contre les attaques web, mais ceci engendre des coûts additionnels.

Il est possible également d'utiliser un header pour identifier notre distribution CloudFront, mais cette technique ne protège pas contre les tentatives de connexions. Elles sont arrêtées au plus tôt au niveau de l'ALB, mais elles polluent les logs et peuvent impacter les performances.

Voici un exemple de règle de groupe de sécurité permettant un accès uniquement via CloudFront en HTTPS :

Type	Protocol	Port	Source
HTTPS	TCP	443	pl-4fa04526 (com.amazonaws.global.cloudfront.origin-facing)

Ces points d'accès peuvent être découverts via un scan d'IP systématique ou en
listant les sous-domaines d'une entrée DNS, et être la cible d'attaques
malveillantes (DDoS, DoS, tentative d'exploitation de faille etc.). Si l'instance
EC2 derrière le load balancer a un serveur web avec une faille de
sécurité critique et que le groupe de sécurité en amont permet du trafic ne
venant pas de CloudFront, votre instance et par extension votre VPC
pourraient être compromis.

Exemple de règle trop permissive :

Type	Protocol	Port	Source
HTTPS	TCP	443	0.0.0.0/0

Le meilleur moyen d'éviter cela est de garder la source de CloudFront
privée, ce qui est possible depuis le 20 novembre 2024 avec les origines
VPC sécurisées.
Nous pouvons ainsi enlever la partie publique de nos VPCs, et nous
pouvons également bloquer l'accès public aux VPCs de manière systématique
( https://docs.aws.amazon.com/fr_fr/vpc/latest/userguide/security-vpc-bpa.html ).

Avec cette architecture, nous réduisons également le besoin d'IPs privées
par VPC en enlevant les subnets publics, ce qui est un premier point
intéressant pour certaines compagnies où l'adressage privé est un sujet
critique.

Nous remplaçons le load balancer public par un privé, ce qui réduit la
surface d'exposition de manière significative. S'il y avait déjà un load balancer privé qui
exposait ce service, nous faisons donc une petite économie en enlevant
un composant redondant.

Une question demeure. En modifiant cette architecture, est-ce que nous
modifions les performances de notre service ?
Nous allons le vérifier en mettant en place une page Nginx sur une instance EC2 t3.micro à
Singapour, et en testant les performances à partir de nos locaux (Lyon -
France) ainsi que d'une session CloudShell se trouvant en Irlande. Ce
serveur Nginx sera exposé par un Load Balancer public et également via
une VPC origin sur CloudFront.

Dans un premier temps, nous n'activerons pas le cache en périphérie pour
avoir des résultats objectifs (Si nous l'activions, le contenu ne serait
plus récupéré sur le serveur Nginx à Singapour, mais sur l'edge
CloudFront le plus proche contenant une copie). Nous ferons une dernière
série de tests avec le cache activé, pour montrer l'efficacité d'un cache
CloudFront bien configuré avec TTL standard quand on accède à des données qui sont très
éloignées.

Nous allons donc effectuer 10 appels curl successifs et synchronisés à la suite pour avoir quelques
statistiques intéressantes et fiables (Moyenne, Max, P90, Latence...).

Voici le résultat détaillé de nos tests :

Temps total (mesures complètes)
| | Req1 | Req2 | Req3 | Req4 | Req5 | Req6 | Req7 | Req8 | Req9 | Req10 |
| :--------------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- |
| Irlande CloudFront | 0.394960s | 0.191579s | 0.194875s | 0.189899s | 0.191891s | 0.207810s | 0.193402s | 0.205370s | 0.197298s | 0.368063s |
| Irlande ALB | 0.364543s | 0.367283s | 0.363094s | 0.366604s | 0.359450s | 0.362647s | 0.361881s | 0.365909s | 0.365682s | 0.365236s |
| Lyon CloudFront | 0.407051s | 0.211910s | 0.238359s | 0.201906s | 0.369832s | 0.201490s | 0.206589s | 0.218557s | 0.542900s | 0.202360s |
| Lyon ALB | 0.361772s | 0.322014s | 0.322883s | 0.317526s | 0.315286s | 0.317379s | 0.318128s | 0.316579s | 0.321974s | 0.324912s |
| Lyon CloudFront + cache | 0.442350s | 0.043860s | 0.034697s | 0.043316s | 0.035482s | 0.041478s | 0.046235s | 0.033241s | 0.036595s | 0.029393s |

	Moyenne (sec)	Plus longue (sec)	Plus rapide (sec)	P90 (percentile)
Irlande CloudFront	0.2335147s	0.39496s	0.189899s	0.21557633s
Irlande ALB	0.3642329s	0.367283s	0.35945s	0.363894s
Lyon CloudFront	0.2800954s	0.5429s	0.20149s	0.25089489s
Lyon ALB	0.3238453s	0.361772s	0.315286s	0.31963122s
Lyon CloudFront + cache	0.0786647s	0.44235s	0.029393s	0.03825522s

Comme on peut le voir, les performances sont meilleures en passant par
CloudFront, ce qui s'explique aisément par le fait que la requête qui
arrive sur CloudFront au plus près de l'utilisateur est ensuite envoyée
via les backbones AWS vers la bonne ressource (chemin 1-2-3 et 21-22-23)
sur le schéma suivant, optimisant ainsi le temps de latence global.\
\
Dans le cas de l'ALB, on effectue une résolution DNS, puis on passe par
internet pour joindre la ressource (chemin 10-11 et 31-32). Nous passons
par des ressources publiques et par plusieurs relais que nous ne
maîtrisons pas, ce qui allonge les délais de réponses et peut introduire
une variabilité importante.

Comme on peut le voir dans les résultats, utiliser le cache CloudFront à
la périphérie est la solution la plus performante, ce qui n'est pas une
surprise étant donné que le trajet est beaucoup plus court (chemin 1-2
seulement) et bénéficie de l'infrastructure optimisée d'AWS.

La solution via CloudFront et VPC Origin n'est donc pas seulement plus
sécurisée, mais aussi plus performante qu'une exposition via un ALB, grâce
à la mise en cache globale.

Cette solution est très efficace pour les sites Internet ou
l'exposition de contenu de taille importante. Si vous exposez une API
via votre ALB, cette solution peut néanmoins devenir coûteuse. Le modèle
de facturation de CloudFront étant basé sur les données sortantes ET sur
le nombre de requêtes. Dans le cas d'une API, il y a de très nombreuses
petites requêtes, ce qui peut rendre l'exposition via CloudFront plus
coûteuse que via un ALB classique.

On peut donc dire que les VPC Origins pour CloudFront apportent une
nouvelle façon d'exposer le contenu, en ajoutant une seconde couche de
protection contre les mauvaises manipulations et les attaques externes. Même si vous définissez
une règle en 0.0.0.0/0 pour le HTTP(S) dans votre Security Group, vos
ressources étant en privé, elles resteront inaccessibles via Internet.
Si vous n'avez pas encore ajouté CloudFront en première ligne de votre
exposition Internet, je vous engage à le faire rapidement. Vous pourrez
ainsi profiter de performances réseau accrues et d'une sécurité renforcée.

AWS re:Invent 2025 : MCP Server Open Source pour la Planification

sylvainbruas — Tue, 11 Aug 2026 09:23:16 +0000

Le Model Context Protocol, une Révolution pour l'IA

Le Model Context Protocol (MCP) représente une avancée majeure dans l'écosystème de l'intelligence artificielle. Développé par Anthropic, MCP standardise la façon dont les modèles d'IA accèdent et interagissent avec des sources de données externes. Contrairement aux approches traditionnelles où chaque intégration nécessite un développement spécifique, MCP propose un protocole unifié qui permet aux modèles d'IA de découvrir et d'utiliser automatiquement des outils externes.

L'intérêt principal de MCP réside dans sa capacité à étendre les capacités des modèles d'IA au-delà de leurs connaissances pré-entraînées. Un serveur MCP expose des "outils" que l'IA peut invoquer dynamiquement selon le contexte de la conversation. Cette approche ouvre des possibilités infinies : accès à des bases de données en temps réel, intégration avec des APIs externes, manipulation de fichiers, et bien plus encore.

Dans cet article, je partage mon retour d'expérience sur le développement d'un serveur MCP pour AWS re:Invent 2025, mon premier projet open source de cette envergure. Ce projet illustre parfaitement les défis et opportunités du développement MCP, tout en démontrant comment (Kiro)[https://kiro.dev/] peut considérablement accélérer le processus de développement.

Le Défi : Gérer la Complexité d'AWS re:Invent

AWS re:Invent est l'une des conférences technologiques les plus importantes au monde, avec plus de 2200 sessions réparties sur 5 jours dans plusieurs hôtels de Las Vegas. Pour un participant, naviguer dans cette masse d'informations représente un défi considérable :

Volume de données : 2200 sessions avec des métadonnées complexes (niveaux, services AWS, speakers, lieux)
Sources multiples : API officielle, flux RSS des mises à jour, agenda AWS des événements spéciaux
Besoins personnalisés : Gestion d'événements personnels, listes de favoris, export calendrier
Contraintes temps réel : Synchronisation continue des données, cache intelligent

Reinvent-planner.cloud par Raphael Manke

Ce projet s'appuie sur l'excellent travail de Raphael Manke et son site reinvent-planner.cloud, qui constitue la source de données principale de notre serveur MCP. Raphael a créé une API robuste et bien documentée qui agrège les données officielles d'AWS re:Invent, les enrichit avec des métadonnées utiles, et les expose via une interface REST moderne.

L'API de reinvent-planner.cloud fournit :

Catalogue complet : 2200+ sessions avec détails techniques et mises à jour journalières
Flux RSS : Notifications des nouvelles sessions et modifications
Métadonnées enrichies : Niveaux de difficulté, services AWS, topics, speakers
Filtrage avancé : Par lieu, jour, niveau, service, domaine d'intérêt

Sans cette infrastructure de qualité, développer un serveur MCP aussi complet aurait nécessité un effort considérable de scraping et de normalisation des données. Le travail de Raphael illustre parfaitement l'importance de l'écosystème open source dans la création de solutions innovantes.

L'objectif était de créer un serveur MCP capable de transformer cette complexité en une interface simple et intuitive pour les modèles d'IA, tout en s'appuyant sur cette base de données fiable et maintenue.

Architecture Technique : Une Approche en Couches

Vue d'Ensemble du Système

Architecture en Couches Détaillée

L'architecture suit un modèle en trois couches bien défini :

Architecture Locale vs Web : Choix et Implications

Exécution Locale : Avantages et Contraintes

Le serveur MCP re:Invent fonctionne entièrement en local sur la machine de l'utilisateur, une approche qui présente des avantages significatifs mais aussi des limitations :

Avantages de l'approche locale :

Performance optimale : Pas de latence réseau pour les requêtes
Données privées : Événements personnels et favoris restent sur la machine
Disponibilité offline : Fonctionnement même sans connexion internet (cache) ou dans les transports (train, avion ...)
Coût zéro : Pas d'infrastructure serveur à maintenir
Simplicité de déploiement : Installation directe via script

Contraintes identifiées :

Installation requise : Chaque utilisateur doit configurer l'environnement Python
Maintenance individuelle : Mises à jour à déployer sur chaque poste

Configuration Locale Actuelle

{
  "mcpServers": {
    "reinvent-planner": {
      "command": "/path/to/venv/bin/python",
      "args": ["./server.py"],
      "cwd": "/path/to/project",
      "env": {
        "PYTHONPATH": "/path/to/project"
      }
    }
  }
}

Cette configuration lance un processus Python local qui communique avec Kiro via STDIO, créant une expérience transparente pour l'utilisateur.

Composants Clés et Défis Techniques

1. Gestionnaire de Cache Intelligent

Le cache représente un défi majeur avec 2200 sessions à gérer. Il est indispensable d'avoir le moins de pression possible sur les sources de données, ceci est possible car les données ne sont pas rafraichies très fréquemment. L'approche adoptée combine cache mémoire et persistance SQLite.

Défis rencontrés :

Gestion de la cohérence entre cache mémoire et base de données
Optimisation des performances avec de gros volumes
Stratégie de fallback en cas d'indisponibilité API

2. Moteur de Recherche Multi-Critères

Le moteur de recherche doit gérer 8 types de filtres différents avec des performances optimales :

# Exemple de recherche complexe
search_sessions(
    query="AI machine learning",
    day="Tuesday",
    venue="Venetian",
    level=300,
    service="SageMaker"
)

Bonne pratique : Utilisation d'index SQLite optimisés et requêtes préparées pour maintenir des temps de réponse < 2 secondes même avec 2200+ résultats.

3. Synchronisateur Multi-Sources

La synchronisation de trois sources de données hétérogènes présente des défis uniques :

L'Apport de Kiro dans le Développement

Accélération du Processus de Spécification

Kiro a amélioré mon approche de ce développement en me soutenant avec une mise en forme structuré de mes idées et spécifications. j'ai ensuite pu dérouler les phases suivantes (Design puis Taches) pour implémenter cette solution. J'ai pu également tester facilement les évolutions de ce projet en connectant Kiro avec le serveur MCP que j'étais en train de concevoir.

Configuration de Kiro pour le Serveur MCP

Installation et Configuration Initiale

La mise en place du serveur MCP dans Kiro est assez simple :

1. Installation du Serveur MCP

# Cloner le projet
git clone https://github.com/sylvainbruas/reinvent-planner
cd reinvent-planner

# Installation automatique
chmod +x install.sh
./install.sh

# Ou installation manuelle
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

2. Configuration MCP dans Kiro

Créer ou modifier le fichier .kiro/settings/mcp.json :

{
  "mcpServers": {
    "reinvent-planner": {
      "command": "./reinvent-planner/venv/bin/python",
      "args": ["./reinvent-planner/server.py"],
      "cwd": "./reinvent-planner",
      "env": {
        "PYTHONPATH": "./reinvent-planner",
        "LOG_LEVEL": "INFO"
      },
      "disabled": false,
      "autoApprove": [
        "search_sessions",
        "get_session_details",
        "list_available_filters",
        "get_schedule_by_day",
        "get_rss_updates",
        "sync_rss_feed",
        "get_aws_events",
        "sync_aws_events",
        "sync_all_data",
        "get_sync_history",
        "add_personal_event",
        "get_personal_events",
        "delete_personal_event",
        "add_session_to_favorites",
        "get_favorite_sessions",
        "remove_session_from_favorites",
        "create_favorite_list",
        "export_schedule_to_ical"
      ]
    }
  }
}

3. Vérification de la Connexion

Une fois configuré, Kiro affiche le serveur MCP dans le panneau des outils disponibles :

✅ reinvent-planner (18 outils disponibles)
   📊 Sessions: search_sessions, get_session_details, list_available_filters, get_schedule_by_day
   🔄 Sync: get_rss_updates, sync_rss_feed, get_aws_events, sync_aws_events, sync_all_data, get_sync_history
   👤 Personnel: add_personal_event, get_personal_events, delete_personal_event
   ⭐ Favoris: add_session_to_favorites, get_favorite_sessions, remove_session_from_favorites, create_favorite_list
   📤 Export: export_schedule_to_ical

Exemples de Requêtes Complexes avec Kiro

Requêtes Simples - Utilisation du Serveur MCP Seul

1. Recherche et Planification de Base

Trouve-moi toutes les sessions sur l'intelligence artificielle niveau 300 ou plus au Venetian mardi, et ajoute les 3 plus intéressantes à ma liste plan_a

Outils MCP utilisés :

search_sessions(query="intelligence artificielle", venue="Venetian", day="Tuesday", level=300)
add_session_to_favorites(session_id="...", list_name="plan_a", priority=1)

2. Gestion d'Événements Personnels

Ajoute une réunion équipe de 9h à 10h mardi au Treasure Island, puis montre-moi mon planning complet de la journée incluant mes événements personnels

Outils MCP utilisés :

add_personal_event(title="Réunion équipe", start_datetime="2025-12-02 09:00", end_datetime="2025-12-02 10:00", location="Treasure Island")
get_schedule_by_day(day="Tuesday")
get_personal_events(day="Tuesday")

Requêtes Complexes - Combinaison avec d'Autres Sources

1. Planification Optimisée avec Géolocalisation

Je loge au Treasure Island. Trouve-moi les sessions IA mardi au Venetian, calcule les temps de trajet, vérifie la météo prévue, et suggère des restaurants proches pour déjeuner entre les sessions

Sources de données combinées :

Serveur MCP re:Invent : Sessions et planning
Google Maps API : Distances et temps de trajet
OpenWeather API : Prévisions météorologiques
Yelp/Google Places : Restaurants et avis

Réponse coordonnée :

📋 Sessions IA trouvées au Venetian - Mardi:
• 10:30-11:30 | CNS417 - Networking and observability strategies for Kubernetes
• 13:00-14:00 | AIM304 - Building AI-powered applications with Amazon Bedrock
• 15:30-16:30 | MLO315 - Scaling machine learning operations on AWS

🚶 Temps de trajet depuis Treasure Island:
• Venetian: 18 minutes à pied ou 8 minutes en navette gratuite
• Navettes toutes les 15 minutes de 7h à 23h

🌤️ Météo prévue mardi:
• Ensoleillé, 24°C, vent léger
• Aucune précipitation prévue
• Idéal pour marcher entre les hôtels

🍽️ Restaurants recommandés près du Venetian (12h-14h):
• Bouchon Bistro - Cuisine française, 4.5⭐ (5min à pied)
• TAO Asian Bistro - Cuisine asiatique, 4.3⭐ (2min à pied)
• Yardbird - Cuisine américaine, 4.4⭐ (8min à pied)

2. Analyse Comparative Multi-Critères

Compare les sessions de sécurité niveau 400 entre le Venetian et MGM mercredi, vérifie les disponibilités d'hôtels si je veux changer de lieu, et estime le budget total incluant transport et repas

Sources de données combinées :

Serveur MCP re:Invent : Sessions de sécurité niveau 400
Booking.com API : Disponibilités et prix hôtels
Uber/Lyft API : Coûts de transport
Restaurant APIs : Prix moyens des repas

Analyse générée :

🔒 Sessions Sécurité Niveau 400 - Mercredi:

📍 VENETIAN (3 sessions):
• 10:30-11:30 | SEC407 - Building robust container security pipeline
• 14:00-15:00 | SEC412 - Advanced threat detection with AWS GuardDuty
• 16:30-17:30 | SEC419 - Zero-trust architecture implementation

📍 MGM (2 sessions):
• 11:30-12:30 | SEC408 - Cryptographic best practices for cloud
• 15:00-16:00 | SEC415 - Advanced IAM policies and cross-account access

🏨 Disponibilités Hôtels (mercredi soir):
• Venetian: 299$/nuit (Deluxe Suite disponible)
• MGM: 189$/nuit (Grand King disponible)
• Treasure Island: 149$/nuit (votre réservation actuelle)

💰 Estimation Budget Changement vers Venetian:
• Surcoût hôtel: +150$ (299$ - 149$)
• Transport économisé: -25$ (moins de trajets)
• Repas sur place: +40$ (restaurants plus chers)
• TOTAL: +165$ pour optimiser votre temps

📊 Recommandation: Rester au Treasure Island
• Économie de 165$ avec seulement 15min de trajet supplémentaire
• Sessions MGM accessibles en 12min de navette
• Plus de flexibilité pour les repas et pauses

Avantages de l'Approche Multi-Sources

Kiro orchestre automatiquement les différents serveurs MCP pour fournir des réponses complètes et actionnables, transformant des requêtes complexes en plans d'action.
L'IA analyse les contraintes multiples (temps, budget, préférences, disponibilités) pour proposer les meilleures solutions sans intervention manuelle.

Défis d'un Premier Projet Open Source

Qualité et Robustesse du Code

Défi : Assurer la qualité d'un projet destiné à être public et réutilisable.

Approche :

Tests unitaires obligatoires pour chaque composant
Gestion d'erreurs affinées
Documentation technique complète avec exemples d'utilisation

Performance et Scalabilité

Contraintes identifiées :

Temps de réponse < 2s avec 2200+ sessions
Gestion mémoire efficace du cache
Concurrence SQLite avec verrous appropriés

Solutions implémentées :

Index de base de données optimisés
Cache à deux niveaux (mémoire + SQLite)
Pagination intelligente des résultats
Requêtes asynchrones vers les sources externes

Leçons Apprises et Perspectives

Ce qui a Bien Fonctionné

Architecture MCP : Le protocole MCP s'est révélé parfaitement adapté à ce type d'application. La découverte automatique des outils et l'invocation contextuelle par l'IA créent une expérience utilisateur impresionnante.

Écosystème reinvent-planner.cloud : S'appuyer sur l'API de Raphael Manke a considérablement accéléré le développement. Cette approche illustre l'importance de réutiliser des composants de qualité plutôt que de réinventer la roue.

Méthodologie Kiro : Le workflow Requirements → Design → Tasks a structuré le développement et évité les écueils classiques des projets sans spécification claire et partagée. On a ainsi une référence pour l'évolution du projet

Choix techniques : SQLite + cache mémoire + httpx async forment une stack performante pour une application légère.

Évolutions Futures

Assistant IA : Intégration de recommandations personnalisées basées sur l'historique utilisateur et les préférences déclarées.

Écosystème MCP étendu : Développement ou intégration de serveurs MCP complémentaires (géolocalisation, hôtellerie, météo) pour créer un assistant de voyage complet.

Collaboration : Partage de listes de favoris entre participants, recommandations sociales basées sur les profils similaires.

Analytics avancées : Métriques d'utilisation pour optimiser l'expérience utilisateur et identifier les tendances de participation.

Migration progressive vers le web : Évolution de l'architecture locale vers un modèle hybride puis entièrement web pour maximiser l'accessibilité et les fonctionnalités collaboratives.

Améliorations avec les Services AWS

En tant qu'architecte AWS, l'évolution naturelle de ce projet serait d'exploiter l'écosystème AWS pour transformer le serveur MCP local en une plateforme cloud native robuste et scalable. Voici les améliorations clés que les services AWS pourraient apporter :

Architecture Cloud Native avec AWS

Infrastructure Serverless

Fonctionnalités Avancées Possibles

1. Notifications Intelligentes avec Amazon Simple Notification Service (SNS)

Conflits détectés : Sessions en conflit avec événements personnels
Nouvelles sessions : Correspondant aux intérêts utilisateur
Optimisations : Suggestions de planning plus efficace
Rappels contextuels : Basés sur la localisation et l'heure

2. Analytics Avancées avec Amazon QuickSight

Tendances de participation par service AWS, niveau, lieu
Optimisation des ressources : sessions peu sélectionnées, créneaux populaires

Migration Strategy vers AWS

Phase 1 : Lift & Shift

Migration de la base SQLite vers Amazon DynamoDB
Déploiement des AWS Lambda functions pour chaque outil MCP
Configuration d'Amazon API Gateway et authentification Amazon Cognito

Phase 2 : Cloud Native

Intégration d'Amazon ElastiCache pour le cache distribué
Mise en place d'Amazon EventBridge pour l'orchestration
Déploiement du frontend avec AWS Amplify ou Amazon Simple Storage Service (S3) + Amazon CloudFront

Phase 3 : Intelligence Augmentée

Intégration d'Amazon Bedrock pour les recommandations
Déploiement des analytics avec QuickSight

Cette évolution vers AWS transformerait le serveur MCP local en une plateforme cloud native robuste, capable de servir de nombreux utilisateurs simultanément tout en maintenant des coûts optimisés grâce à l'architecture serverless.

Hébergement Web avec FastMCP

Une approche plus simple et accessible consiste à transformer le serveur MCP local en service web public en utilisant des frameworks spécialisés comme FastMCP.

Avantages du Déploiement Web :

Aucune installation requise côté client
Configuration simple : URL + token d'authentification
Compatibilité avec tous les clients MCP
Mises à jour instantanées pour tous les utilisateurs

FastMCP : Framework pour Serveurs MCP Web

FastMCP est un framework Python moderne qui simplifie la création de serveurs MCP accessibles via HTTP/WebSocket, permettant de transformer rapidement un serveur MCP local en service web public.

Architecture Web Simplifiée

Cette solution est plus simple qu'une migration vers du cloud native AWS, mais nécessite une ou plusieurs instances de calcul disponible en continue. Cette solution sera donc moins économique, et ne pourra être rentable que pour un nombre élevé d'utilisateurs.

Conclusion

Ce premier projet open source m'a permis de découvrir la puissance du Model Context Protocol et de profiter de l'efficacité de Kiro pour structurer le développement. L'architecture en couches, la gestion intelligente du cache, et l'exposition de multiples outils MCP créent une solution robuste et extensible qui fonctionne bien en local.

L'expérience a également souligné l'importance de l'écosystème open source : s'appuyer sur le travail de qualité de Raphael Manke avec reinvent-planner.cloud a permis de se concentrer sur la valeur ajoutée du protocole MCP plutôt que sur la collecte de données. Je le remercie une nouvelle fois de m'avoir autorisé à m'appuyer sur son travail. Le fait qu'un projet soit open source n'autorise pas à s'approprier le travail ou les données d'autrui sans permission.

Leçons sur l'Architecture Locale vs Web

L'architecture locale actuelle présente des avantages indéniables : performance optimale, confidentialité des données, fonctionnement offline et coût zéro. Cependant, l'évolution vers une architecture web hybride ouvrirait de nouvelles possibilités :

Avantages immédiats d'une version web :

Accessibilité universelle sans installation
Synchronisation multi-appareils
Maintenance centralisée et mises à jour instantanées

Vision d'Avenir

Le serveur MCP AWS re:Invent Planner démontre qu'il est possible de créer des intégrations IA sophistiquées avec des outils modernes, que ce soit en local ou dans le cloud. Plus encore, il ouvre la voie à un écosystème de serveurs MCP interconnectés : géolocalisation, hôtellerie, météo, transport. Cette vision d'assistants IA spécialisés mais coordonnés représente l'avenir des applications intelligentes.

L'architecture locale actuelle constitue une base solide pour cette évolution. Les composants développés (cache intelligent, synchronisation multi-sources, gestion d'erreurs robuste) sont transposables vers une architecture web, facilitant une migration progressive.

Recommandations pour les Architectes

Pour les architectes souhaitant se lancer dans le développement MCP, je recommande vivement de :

Commencer local : Prototyper rapidement avec une architecture locale simple
Utiliser une méthodologie structurée comme celle de Kiro pour maintenir la qualité
Penser évolutivité dès le départ : patterns compatibles local/web
S'appuyer sur l'écosystème existant plutôt que de tout reconstruire
Planifier la migration : architecture locale comme tremplin vers le web
Prioriser l'expérience utilisateur : performance et simplicité avant tout

Le code source complet du serveur MCP AWS re:Invent Planner est disponible sur GitHub avec documentation technique détaillée et exemples d'utilisation. Remerciements particuliers à Raphael Manke pour reinvent-planner.cloud, source de données essentielle de ce projet.

Construire une App Kiro Crew pour piloter son blog technique

sylvainbruas — Tue, 11 Aug 2026 09:22:31 +0000

Dans les deux articles précédents, nous avons exploré l'architecture de Kiro Crew (Gateway, mémoire, sécurité) puis ses cas d'usage concrets (cron jobs, orchestration multi-agent, Apps existantes). Cette troisième partie est un retour d'expérience : j'ai construit une App Kiro Crew personnalisée pour piloter l'administration de ce blog.

L'objectif : regrouper dans une interface dédiée tout ce que je faisais manuellement — vérifier le statut des articles, valider les posts sociaux générés par l'agent, suivre les jobs planifiés, et monitorer les déploiements.

Pourquoi une App plutôt qu'un chat ?

Certains workflows ne rentrent pas dans une fenêtre de conversation. Quand je veux :

Voir d'un coup d'œil les 3 posts sociaux en attente de validation
Approuver ou rejeter un post LinkedIn d'un clic
Vérifier que le dernier déploiement a passé l'audit SEO
Toggler un cron job on/off sans écrire de commande

...une UI dédiée est plus efficace qu'un échange conversationnel.

C'est exactement ce que les Kiro Crew Apps permettent : combiner une interface React avec le runtime agent, l'event bus et les schedules dans un package cohérent.

Architecture de l'App

Une App Kiro Crew suit une structure imposée par le framework. On peut générer un squelette via kirocrew app init, mais voici la structure complète de l'app blog-admin :

kirocrew/
├── app.json               # Manifeste KiroCrew (agents, crons, UI, backend)
├── agents/                # Définitions JSON des agents
│   ├── content-validator.json
│   ├── social-writer.json
│   └── deploy-monitor.json
├── skills/                # Skills Markdown (contexte injecté aux agents)
│   ├── blog-conventions/
│   │   └── SKILL.md
│   └── social-publishing/
│       └── SKILL.md
├── backend/               # Backend Python (API interne)
│   └── server.py
├── ui/                    # Frontend React (pages du dashboard)
│   ├── src/
│   │   ├── App.tsx        # Point d'entrée (exporté en ESM)
│   │   ├── components/
│   │   ├── pages/
│   │   ├── types/
│   │   └── data/
│   ├── package.json
│   └── vite.config.ts
└── README.md

Stack UI : React 19, TypeScript 5.9, Vite 6, Tailwind CSS 4, Lucide pour les icônes. L'UI est buildée comme un module ESM (pas un SPA classique) car Kiro Crew injecte le composant dans son propre shell. Le routing interne utilise React Router avec un MemoryRouter (Crew ne fournit pas de contexte Router parent).

Backend : Python minimal (stdlib http.server) qui sert une API d'articles en scannant le filesystem. Kiro Crew le démarre automatiquement.

Agents : 3 fichiers JSON déclarant chacun un agent spécialisé avec son prompt et ses outils autorisés.

Skills : fichiers Markdown injectés comme contexte aux agents, encodant les conventions du blog.

Le manifeste `app.json`

Le fichier app.json est le point d'entrée de l'App auprès du runtime Kiro Crew. Il déclare les agents, les crons, le backend et l'UI. On peut le créer manuellement ou générer un squelette avec kirocrew app init blog-admin --ui --backend --cron.

{
  "name": "blog-admin",
  "version": "1.0.0",
  "displayName": "Blog Admin Dashboard",
  "description": "Dashboard d'administration pour sylvain.bruas.fr",
  "author": "sylvainbruas",
  "agents": [
    "agents/content-validator.json",
    "agents/social-writer.json",
    "agents/deploy-monitor.json"
  ],
  "skills": [
    "skills/blog-conventions",
    "skills/social-publishing"
  ],
  "tags": ["blog", "admin", "social", "seo", "deployment"],
  "backend": {
    "entryPoint": "backend/server.py",
    "port": "auto",
    "healthCheck": "/health"
  },
  "ui": {
    "entry": "dist/index.mjs",
    "pages": [
      { "route": "/apps/blog-admin", "label": "Blog Admin", "icon": "LayoutDashboard" },
      { "route": "/apps/blog-admin/articles", "label": "Articles", "icon": "FileText" },
      { "route": "/apps/blog-admin/social", "label": "Social", "icon": "Share2" },
      { "route": "/apps/blog-admin/jobs", "label": "Jobs", "icon": "Clock" },
      { "route": "/apps/blog-admin/deployments", "label": "Déploiements", "icon": "Rocket" }
    ]
  },
  "crons": [
    { "name": "seo-audit-weekly", "every": 604800, "message": "Audit SEO complet de tous les articles publiés", "enabled": false },
    { "name": "dep-scan-daily", "every": 86400, "message": "Scan de vulnérabilités des dépendances npm", "enabled": false },
    { "name": "git-hygiene", "every": 259200, "message": "Identifier les branches stale et commits WIP abandonnés", "enabled": false },
    { "name": "redirect-check", "every": 604800, "message": "Vérifier que toutes les redirections S3 fonctionnent", "enabled": false },
    { "name": "friday-summary", "every": 604800, "message": "Résumer les déploiements de la semaine", "enabled": false },
    { "name": "social-gen", "every": 86400, "message": "Générer des posts sociaux pour le dernier article publié", "enabled": false }
  ]
}

Points clés du manifeste :

agents : chemins relatifs vers les fichiers JSON de définition d'agents
skills : dossiers contenant un SKILL.md qui sera injecté comme contexte
backend : serveur Python démarré automatiquement par Crew, avec healthcheck
ui.entry : le module ESM buildé par Vite — Crew l'injecte dans son shell
ui.pages : routes et labels affichés dans la navigation du dashboard Crew
crons : jobs récurrents avec "every" en secondes, un "message" envoyé à l'agent, et "enabled": false pour les déclarer sans les activer immédiatement

Page Dashboard

Le Dashboard donne une vue d'ensemble en un coup d'œil :

// Extrait simplifié du DashboardPage.tsx
const DashboardPage = () => {
  const stats = mockDashboardStats

  return (
    <div className="space-y-8">
      <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-4 gap-4">
        <StatCard
          label="Articles publiés"
          value={stats.publishedArticles}
          icon={FileText}
          color="success"
        />
        <StatCard
          label="Posts en attente"
          value={stats.pendingSocialPosts}
          icon={Share2}
          color="warning"
        />
        <StatCard
          label="Déploiements (semaine)"
          value={stats.deploymentsThisWeek}
          icon={Rocket}
          color="primary"
        />
        <StatCard
          label="Crédits utilisés"
          value={stats.creditsUsedThisWeek}
          icon={Zap}
          color="primary"
        />
      </div>
      {/* + Dernier déploiement avec scores audit */}
      {/* + Posts sociaux en attente */}
      {/* + Dernières exécutions de jobs */}
    </div>
  )
}

4 métriques clés : articles publiés, posts sociaux en attente de validation, déploiements de la semaine, crédits Kiro Crew consommés.

En dessous : le dernier déploiement avec ses scores d'audit (SEO, Lighthouse), les posts en attente, et les dernières exécutions de jobs.

Page Validation des posts sociaux

Quand l'agent social-writer génère des posts à partir d'un article, ils arrivent ici en statut "En attente" :

Chaque post est affiché avec sa plateforme (X, LinkedIn, Bluesky), son contenu complet, et la date de génération
Deux boutons : ✓ Approuver / ✗ Rejeter
Après approbation : un bouton "Publier" apparaît pour déclencher l'envoi via l'API de la plateforme

L'idée est de garder l'humain dans la boucle pour la publication sociale — l'agent rédige, vous validez. Le mode supervised dans le manifeste Crew garantit que rien ne part sans approbation explicite.

Page Jobs planifiés

Cette page expose les 6 jobs déclarés dans app.json avec une interface de gestion :

Toggle on/off pour activer/désactiver un job sans toucher au manifeste
Bouton "Run" pour déclencher une exécution manuelle
Panel expandable montrant : durée de la dernière exécution, crédits consommés, output terminal, historique des runs

// Chaque job affiche son schedule et son dernier output
{job.lastRun?.output && (
  <div className="bg-gray-900 rounded-lg p-4">
    <pre className="text-sm text-green-400 whitespace-pre-line font-mono">
      {job.lastRun.output}
    </pre>
  </div>
)}

Point économique : les jobs sont déclarés avec "enabled": false dans le manifeste. Cela permet de versionner la configuration sans déclencher d'exécutions dès l'installation. On active ensuite individuellement via le toggle dans l'interface, ou en CLI avec kirocrew cron enable blog-admin/seo-audit-weekly. Le scan de dépendances et la vérification des redirections sont des scripts purs (0 crédit). Seuls l'audit SEO, le résumé de fin de semaine et la génération de posts sociaux consomment des crédits d'inférence.

Job	Fréquence	Crédits/run
Audit SEO	Lundi 8h	3
Scan dépendances	Weekdays 9h	0 (script)
Nettoyage Git	Mar/Jeu 10h	1
Vérification redirections	Mercredi 10h	0 (script)
Résumé fin de semaine	Vendredi 16h	4
Génération posts sociaux	À la publication	5

Total estimé : ~18 crédits/semaine, soit environ $3/mois sur un plan Pro.

Déployer l'App sur Kiro Crew

Pour enregistrer et exécuter cette App dans votre instance Kiro Crew :

Prérequis

Kiro Crew installé et le Gateway actif (kirocrew gateway)
Un compte Kiro authentifié (plan Free minimum, Pro recommandé)
Node.js 18+ pour le build de l'UI
Python 3.10+ pour le backend

Étape 1 : Génération du squelette (optionnel)

Si vous partez de zéro, kirocrew app init génère le squelette :

kirocrew app init blog-admin --ui --backend --cron

Cela crée la structure de base avec app.json, un agent exemple, un skill, un backend Python et un frontend Vite.

Étape 2 : Build de l'UI

cd kirocrew/ui
pnpm install
pnpm build
# → Génère dist/index.mjs (module ESM)

Étape 3 : Installer l'App dans Kiro Crew

kirocrew app install /chemin/vers/kirocrew

Kiro Crew lit le app.json, déploie les agents, programme les crons, démarre le backend, et injecte l'UI dans le dashboard.

Étape 4 : Activer et vérifier

# Activer l'app
kirocrew app enable blog-admin

# Vérifier l'installation
kirocrew app info blog-admin

# Lister toutes les apps installées
kirocrew app list

Mode développement

Pour itérer rapidement sur l'UI sans rebuild à chaque modification :

# Active le live reload dans le dashboard Crew
kirocrew app dev blog-admin

# Ou lancer le dev server Vite en standalone
cd kirocrew/ui && pnpm dev
# → http://localhost:3100

kirocrew app dev active le mode no-store + live reload sur les changements de fichiers. Pratique pour ajuster le dashboard sans reconstruire à chaque fois.

Mode Docker (serveur always-on)

Pour une instance persistante qui tourne même quand votre Mac est éteint :

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

Une fois le container actif, installez l'app depuis le container ou montez le répertoire en volume.

Désinstallation

# Désactiver sans supprimer les données
kirocrew app disable blog-admin

# Supprimer complètement (préserve les données par défaut)
kirocrew app uninstall blog-admin

Connecter aux données réelles

Le backend Python

Le fichier backend/server.py scanne directement le filesystem pour lister les articles et calcule les statistiques :

def scan_articles():
    """Scan le répertoire blog pour extraire les frontmatter."""
    articles = []
    blog_path = Path(BLOG_DIR)
    for mdx_file in blog_path.rglob("index.mdx"):
        slug = str(mdx_file.parent.relative_to(blog_path))
        content = mdx_file.read_text(encoding="utf-8")
        frontmatter = parse_frontmatter(content)
        status = determine_status(frontmatter, slug, devto_data)
        articles.append({
            "slug": slug,
            "title": frontmatter.get("title", ""),
            "date": str(frontmatter.get("date", ""))[:10],
            "lang": frontmatter.get("lang", "fr"),
            "status": status,
            "tags": frontmatter.get("tags", []),
            "summary": frontmatter.get("summary", ""),
            "cover": frontmatter.get("cover", ""),
        })
    return articles

Kiro Crew démarre ce backend automatiquement (déclaré dans app.json → backend.entryPoint).

Le hook `useApi`

Côté UI, un hook React générique gère les appels au backend via le gateway Crew :

function useApi<T>(endpoint: string): FetchState<T> {
  // Essaie les routes du gateway, puis fallback sur le port direct
  const fetchData = useCallback(() => {
    apiFetch(endpoint)
      .then((res) => res.json())
      .then((json) => setData(json))
      .catch((err) => setError(err.message))
  }, [endpoint])

  useEffect(() => { fetchData() }, [fetchData])
  return { data, loading, error, refetch: fetchData }
}

Chaque page consomme ce hook : useApi<ArticlesResponse>('/articles') pour la liste, useApi<DashboardStats>('/stats') pour les compteurs.

Ce que j'ai appris

Pièges d'intégration avec le shell Crew

En déployant l'app pour la première fois, j'ai rencontré trois problèmes classiques d'intégration :

Le chemin ui.entry — Le manifeste résout le chemin depuis le dossier ui/ de l'app, pas depuis sa racine. Mettre ui/dist/index.mjs donnait une URL doublée (/ui/ui/dist/...). La valeur correcte est dist/index.mjs.
Les externals Vite — Externaliser lucide-react pour réduire la taille du bundle semble logique, mais la version fournie par le runtime Crew ne contient pas forcément les mêmes exports que celle du projet. Mieux vaut bundler les icônes directement (~10 kB supplémentaires) pour éviter les erreurs does not provide an export named 'X'.
Le thème dark du shell — Le dashboard Crew est en thème sombre. Si l'app utilise des classes Tailwind en mode clair (bg-white, text-gray-900), il faut forcer colorScheme: 'light' et un fond explicite sur le conteneur racine pour que les couleurs ne soient pas écrasées par le thème parent.
Le Router — Crew injecte le composant App dans son propre shell sans fournir de contexte <Router>. Il faut wraper l'app avec un <MemoryRouter> pour que react-router-dom fonctionne.

Le modèle mental "agent + UI" fonctionne

La séparation est nette : l'agent fait le travail lourd (rédiger, valider, scanner), l'UI donne le contrôle (approuver, rejeter, toggler, monitorer). Le mode supervised est essentiel pour les actions irréversibles comme publier sur les réseaux sociaux.

Les scripts zero-credit sont sous-estimés

Sur mes jobs planifiés, 2 ne consomment aucun crédit parce que ce sont des scripts bash simples. Le scan de dépendances (npm audit --json) et la vérification des redirections (scripts/test-redirects.sh) n'ont pas besoin de raisonnement IA. Kiro Crew les exécute directement sans appel modèle.

La mémoire persistante évite la dérive

Après quelques corrections sur les posts sociaux générés ("trop long pour X", "ajoute toujours le lien canonique", "pas d'émoji dans les posts LinkedIn pro"), l'agent apprend et les prochains drafts respectent les préférences. Sans mémoire persistante, il faudrait ré-expliquer ces conventions à chaque session.

Le rapport d'audit pré-deploy est un filet de sécurité

J'ai découvert un build cassé à cause d'une image PNG (au lieu de WebP) uniquement parce que l'audit l'a détecté. Sans ce check automatique, l'article serait parti en production avec un cover manquant.

Conclusion

Construire une App Kiro Crew se résume à :

Générer le squelette avec kirocrew app init mon-app --ui --backend --cron
Définir les agents (JSON) et skills (Markdown)
Coder l'UI React exportée en module ESM
Installer avec kirocrew app install ./mon-app
Itérer avec kirocrew app dev mon-app (live reload)

La courbe d'apprentissage est faible si vous connaissez déjà React et TypeScript. Le vrai travail est dans la définition des agents et des skills.

Sources :

kiro.dev/crew — Page produit officielle
github.com/kirodotdev/KiroCrew — Repository GitHub
kiro.dev/blog/introducing-kiro-crew — Blog post de lancement
dev.to/aws-builders — Getting Started with Kiro Crew — Guide de démarrage

Kiro Crew : cas d'usage, Apps et perspectives — Partie 2

sylvainbruas — Mon, 10 Aug 2026 12:19:33 +0000

Dans la première partie, nous avons exploré l'architecture de Kiro Crew : le Gateway, le système de mémoire, le modèle de sécurité et le positionnement dans l'écosystème Kiro. Cette seconde partie entre dans le concret : comment utiliser Kiro Crew au quotidien, quelles Apps installer, et quelles perspectives s'ouvrent pour les équipes de développement.

Travail planifié : cron, webhooks et heartbeats

C'est là que Kiro Crew se distingue radicalement de tous les autres outils de coding assisté par IA. Aucun d'entre eux ne propose du travail planifié et non-supervisé.

Jobs cron

Les jobs cron de Kiro Crew sont timezone-aware, avec timeouts par job, jitter pour éviter les thundering herds, et skip dates pour les fenêtres de maintenance.

# Gérer les jobs cron
kirocrew cron list
kirocrew cron add
kirocrew cron remove <job_id>

# Exemple via le chat : créer un digest matinal
> "Tous les jours à 9h, résume les PRs ouvertes et flag celles qui nécessitent mon attention"
# → Crée un job cron timezone-aware livré sur la surface de votre choix

Point économique crucial : les jobs qui ne nécessitent pas de raisonnement IA s'exécutent comme de simples scripts ou commandes sans appel modèle. Un health check, un git status, un scan de dépendances — zéro crédit consommé. Seules les étapes qui nécessitent du raisonnement coûtent des crédits.

Webhooks authentifiés

Des endpoints authentifiés déclenchent du travail agent quand un événement externe arrive — un push CI, une alerte monitoring, un ticket créé.

# Exemple d'architecture webhook
# Alert PagerDuty → Webhook Kiro Crew → Investigation automatique

# Le webhook reçoit un payload, démarre une session agent
# qui investigue les logs et corrèle les timestamps

Heartbeats

Les heartbeats surveillent un changement d'état : une PR qui passe en "merged", un déploiement qui échoue, un pipeline CI qui casse deux fois de suite. Quand la condition est remplie, Kiro Crew déclenche le travail associé.

Orchestration multi-agent

Kiro Crew peut exécuter plusieurs conversations en parallèle, chacune avec un contexte isolé. Il délègue la recherche et l'implémentation indépendantes à des sous-agents qui retournent leurs résultats au parent.

# Spawner des agents parallèles
kirocrew spawn run "Analyze the source code of module auth"
kirocrew spawn run "Write migration tests for the new schema"
kirocrew spawn run "Generate API documentation from OpenAPI spec"

# Le parent coordonne, les sous-agents travaillent en isolation

Exemple concret : migration CDK

Imaginez une migration de 12 stacks CloudFormation vers CDK. Chaque stack prend 20-40 minutes de traitement agent. Avec Kiro Crew :

Chaque stack est un checkpoint. Si la stack 7 échoue la validation, Kiro Crew retry avec une approche différente. Vous ne repartez pas de la stack 1. Vous revenez le lendemain matin à une PR avec les 12 outputs CDK validés.

# Lancer une migration avec checkpoints
kirocrew run migration-plan.md

# Le fichier migration-plan.md contient les étapes,
# les critères de validation, et les retry policies

Les Apps : interfaces dédiées

Certains travaux ne rentrent pas dans une fenêtre de chat. Kiro Crew les porte dans des Apps — des interfaces purpose-built qui combinent agents, skills, schedules, intégrations et services backend.

L'App LaunchDarkly

Un exemple concret d'intégration tierce : l'App LaunchDarkly permet de gérer les feature flags directement depuis Kiro Crew. Un agent peut trouver les références de flags dans le code, implémenter un changement derrière un flag, et vous rendre les contrôles pour le rollout.

Source : kiro.dev/blog/introducing-kiro-crew

Cas d'usage concrets

1. Digest matinal de PRs

# La partie "list PRs" est un script → zéro crédits
# La partie "summarize" est un appel modèle → 2-3 crédits

# Résultat livré sur Slack/Discord/Dashboard avant le premier café

Coût estimé : sur un plan Pro (1 000 crédits/mois à $20), un digest quotidien consomme ~60 crédits/mois. Il reste 940 crédits pour le travail interactif.

2. Drift de dépendances

# Job cron hebdomadaire
# Semaine normale (rien à updater) → script simple → 0 crédits
# Semaine avec advisory → raisonnement agent → 8-12 crédits → PR

kirocrew cron add \
  --name "dependency-drift" \
  --schedule "0 8 * * WED" \
  --task "Check for outdated packages, stale branches, 
          and docs that no longer match the code. 
          If issues found, open an issue with versions, 
          breaking changes, and upgrade path."

outils de communication

Kiro Crew vous rejoint là où vous êtes déjà. Pas besoin d'ouvrir un outil supplémentaire :

Outil	Usage optimal
Desktop app	Expérience locale complète, Gateway bundlé
Web dashboard	Conversations parallèles, mémoire, schedules, apps
Slack	DMs et threads avec streaming, approvals, notifications
Telegram	DMs depuis mobile, réponses en streaming
Discord	DMs avec approvals en boutons
Teams	Messages avec streaming
CLI	Automatisation directe (`kirocrew chat`, `run`, `cron`, `spawn`)

Source : GitHub kirodotdev/KiroCrew — Surface table

Perspectives et idées d'utilisation

Pour une équipe DevOps/SRE

Morning standup automatique : digest des alertes de la nuit, PRs en attente, état des pipelines
Rotation d'astreinte assistée : l'agent fait la première investigation et escalade si nécessaire
Drift detection IaC : comparaison quotidienne entre l'état Terraform et l'infrastructure réelle
Post-mortem assisté : corrélation automatique des logs et timeline d'incident

Pour une web agency

Audit SEO récurrent : scan hebdomadaire des sites clients avec rapport
Mise à jour de dépendances : test + PR automatique pour les patches de sécurité
Monitoring de performance : heartbeat sur Lighthouse scores, alerte si régression
Génération de changelog : à chaque release, compilation automatique depuis les commits

Pour un lead technique

Code review augmentée : analyse de blast radius, détection de patterns anti-DRY
Onboarding assisté : l'agent répond aux questions du nouveau avec le contexte du projet
Tech radar automatisé : veille hebdomadaire sur les dépendances et les nouvelles versions
Documentation vivante : mise à jour automatique des docs quand le code change

Pour un développeur solo

CI personnelle : tests, lint, et déploiement automatiques sur chaque push
Project memory : ne jamais perdre le contexte d'un side project laissé en pause 3 mois
Pair programming asynchrone : laisser Crew travailler sur un problème pendant la nuit

Limites à connaître

Pour être complet, voici les limites actuelles :

Dépendance au plan Kiro : Crew est open source, mais la CLI qu'il pilote nécessite un compte Kiro et des crédits.
Les agents parallèles multiplient les coûts : 3 sous-agents = 3× les crédits. Architecturez vos workflows pour utiliser l'exécution séquentielle quand l'ordre compte, et le parallèle uniquement pour le travail indépendant.
Crew n'architecte pas : Il coordonne et exécute. Il ne prend pas les décisions de design à votre place. Vous restez l'ingénieur qui décide quoi construire et pourquoi.

Conclusion

Ce qui change fondamentalement avec Kiro Crew, ce n'est pas la vitesse d'exécution. C'est la continuité.

Aujourd'hui, chaque session avec un agent IA commence par une phase de reconnexion : rappeler le contexte, re-expliquer les contraintes, relancer ce qui avait été fait la veille. Kiro Crew élimine cette friction. La mémoire persiste, les jobs tournent en arrière-plan, les webhooks réagissent pendant que vous dormez. Le matin, vous trouvez une PR prête, pas un thread de chat à relire.

Mon conseil pour démarrer : identifiez un workflow qui dépasse déjà une seule session. Une migration multi-stacks, un audit de dépendances récurrent, un monitoring de drift IaC. C'est là que Crew apporte le plus de valeur — sur le travail que personne n'a le temps de faire manuellement, mais que tout le monde sait nécessaire.

Le projet est sur GitHub : github.com/kirodotdev/KiroCrew

Sources :

kiro.dev/crew — Page produit officielle
kiro.dev/blog/introducing-kiro-crew — Blog post de lancement
github.com/kirodotdev/KiroCrew — Repository GitHub (README, architecture, sécurité)
infoworld.com — AWS's Kiro Crew aims to turn AI coding agents into autonomous engineering teams
dev.to/sarvar_04 — Introducing Kiro Crew: AWS's Open-Source AI Agent Orchestrator
siliconangle.com — AWS launches Kiro Crew
opensourceforu.com — AWS Open Sources Kiro Crew

Kiro Crew : l'orchestrateur multi-agents qui travaille pendant que vous dormez — Partie 1

sylvainbruas — Mon, 10 Aug 2026 12:19:00 +0000

Dans un précédent article, nous avons exploré la plateforme Kiro dans sa globalité : IDE, CLI, Web, et la construction d'un starter kit pour une web agency. Depuis, l'écosystème Kiro a pris une dimension supplémentaire avec le lancement de Kiro Crew le 4 août 2026 — un workspace de développement persistant, open source sous licence Apache 2.0, qui transforme les agents IA en coéquipiers autonomes.

Cette série en deux parties explore Kiro Crew en profondeur. Dans cette première partie : l'origine, l'architecture, le système de mémoire et le modèle de sécurité. La seconde partie couvre les cas d'usage concrets, les Apps, les exemples de code et les perspectives d'utilisation.

De MeshClaw à Kiro Crew : l'origine

Kiro Crew est né d'un projet interne chez Amazon, baptisé MeshClaw. Ils voulaient quelque chose de simple : lancer une tâche, partir, revenir à quelque chose de reviewable, et exécuter plusieurs tâches en parallèle au lieu de surveiller un seul prompt à la fois.

Le problème fondamental

Le blog officiel de lancement (kiro.dev/blog/introducing-kiro-crew) pose le problème clairement : le développeur est devenu la couche d'intégration entre ses propres outils. Le travail d'ingénierie réel n'est jamais une tâche dans une session. Il traverse des repos, des outils, des reviews, et des jours.

Quand vous fermez un onglet de Kiro CLI ou IDE, le contexte disparaît. La prochaine session commence à froid. Vous passez les 10 premières minutes à ré-expliquer où vous en étiez. Et le moment où vous partez, tout s'arrête.

Kiro Crew rompt ce pattern en rendant le workspace persistant :

La mémoire se maintient entre les sessions
Les corrections deviennent des leçons durables
Les patterns répétés deviennent des skills réutilisables
Le travail continue sur un schedule même quand vous n'êtes plus là

Architecture : la Gateway au centre

L'architecture de Kiro Crew repose sur une séparation claire entre là où l'agent tourne et là où vous travaillez avec lui.

Source : README du repository GitHub kirodotdev/KiroCrew

Les trois couches

Couche	Rôle
Surfaces	Desktop app, web dashboard, Slack, Telegram, Discord, Teams, Webex, WeCom, CLI
Gateway	Process long-running qui route les messages, persiste l'état des sessions, injecte mémoire et skills, lance le travail schedulé, coordonne les sous-agents, broker les approbations
Agent sessions	Sessions isolées pilotées par `kiro-cli` via ACP, avec accès aux outils MCP et aux modèles

Le Gateway est le cœur du système. C'est un processus unique qui tourne sur votre machine (Mac, Linux, conteneur Docker, ou serveur distant). Les conversations, la mémoire et les index restent sur cet hôte. Les requêtes aux modèles passent par kiro-cli selon votre configuration de compte.

Déploiement

Kiro Crew supporte plusieurs modes de déploiement, tous basés sur le même principe : Gateway + sessions agent + état sur un seul hôte.

# Installation one-liner (stable)
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

# Ou Docker pour un serveur always-on
docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

# Ou build from source
git clone https://github.com/kirodotdev/KiroCrew.git
cd KiroCrew
make build
source .venv/bin/activate
kirocrew setup
kirocrew doctor
kirocrew gateway

Source : GitHub kirodotdev/KiroCrew — Quick start

Le dashboard web est accessible sur http://localhost:5476 et ne nécessite aucun credential de messaging. Il bindé sur loopback par défaut — les dashboards distants requièrent une authentification par token.

Agent Client Protocol (ACP)

Kiro Crew orchestre ses agents via l'Agent Client Protocol (ACP), un standard ouvert qui permet aux agents IA de fonctionner avec n'importe quel éditeur compatible. Chaque étape est observable en live : vous pouvez suivre comment l'agent planifie une tâche, spawne des sous-agents parallèles, décide quels outils appeler, gate chaque action pour approbation, et synthétise les résultats.

Le système de mémoire : self-learning et self-evolving

Le système de mémoire de Kiro Crew ne se limite pas à "se souvenir de la dernière conversation". C'est un système à plusieurs niveaux, persistant et inspectable.

Trois types de mémoire

Type	Description	Portée
Memory	Préférences, projets actifs, historique pertinent	Cross-session
Lessons	Corrections transformées en règles durables	Workspace-scoped
Skills	Patterns répétés synthétisés en fichiers Markdown nommés	Éditables et partageables

Knowledge Graph

Les décisions architecturales, préférences de code et contexte projet atterrissent dans un knowledge graph soutenu par des embeddings vectoriels et une recherche full-text. L'agent retrouve ce qui est pertinent au lieu de tout relire.

Leçons workspace-scoped

Un point essentiel : les leçons sont scopées au workspace. Dites une fois à Kiro Crew « ne jamais utiliser var en JavaScript » et cette correction devient une règle permanente pour ce projet. Les règles du projet A ne contaminent pas le projet B.

# Exemple de commande naturelle qui crée une leçon
# Dans un chat Kiro Crew :
> "Non, toujours exécuter les checks frontend avant de déclarer un changement terminé"
# → Devient une leçon workspace-scoped appliquée dans les sessions futures

Sécurité : defense in depth

Donner à un agent un accès réel à votre code et votre CI exige un modèle de sécurité sérieux. Kiro Crew est construit avec la sécurité dès le premier commit, sur 7 couches distinctes.

Détail des couches

Couche	Fonction
OS Sandbox	Isolation namespace (Linux) ou Seatbelt (macOS). Modes : standard, strict, off
Tool Approval Gates	Chaque requête outil peut être reviewée dans le dashboard, Slack ou Telegram
Sensitive Path Blocking	Blocage d'accès aux chemins protégés (credentials, clés SSH, etc.)
Write-Protected Paths	Certains fichiers/dossiers sont en lecture seule pour l'agent
Denied Command Patterns	137 patterns deny bloquent les commandes destructives et l'exfiltration
MCP Input Validation	Validation des entrées et redaction des sorties avant qu'elles n'atteignent le chat
Audit & Signed Events	Log structuré de chaque action, vérifiable avec `kirocrew security verify`

Audit et gouvernance

# Inspecter les événements de sécurité
kirocrew security events

# Auditer les actions passées
kirocrew security audit

# Vérifier l'intégrité des logs
kirocrew security verify

# Afficher la politique de gouvernance active
kirocrew policy show
kirocrew policy validate
kirocrew policy explain

La gouvernance suit un modèle tightest-wins : une app ou un agent peut restreindre les permissions mais ne peut jamais élargir le plafond défini par l'entreprise.

// Politique de gouvernance enterprise (exemple)
{
  "version": 1,
  "boot": { "fail_closed": true },
  "capabilities": {
    "telemetry": { "enabled": false }
  }
}

Source : GitHub kirodotdev/KiroCrew — Security and control

Pourquoi l'open source change tout

L'argument clé : un workspace avec accès à votre code, CI et credentials ne devrait jamais être une boîte noire. Parce que Kiro Crew est open source, vous pouvez :

Lire le code source et tracer l'exécution
Vérifier que le sandbox sandboxe réellement
Auditer les patterns deny et les chemins protégés
Confirmer qu'aucune donnée ne quitte votre machine sans votre consentement

Kiro Crew dans l'écosystème Kiro

Kiro dispose maintenant de quatre surfaces : IDE, CLI, Web et Crew. Voici comment elles se positionnent :

	Kiro IDE	Kiro CLI	Kiro Web	Kiro Crew
Sessions	Interactives	Interactives	Interactives	Persistantes, autonomes
Scheduling	Non	Non	Non	Cron, webhooks, heartbeats
Multi-agent	Non	Sous-agents	Non	Orchestration parallèle complète
Mémoire	Session only	Session only	Session only	Cross-session persistante
Travail sans surveillance	Non	Non	Non	Oui
Open source	Non	Non	Non	Oui

Compatibilité avec la configuration existante

Point crucial : Kiro Crew lit votre configuration .kiro existante. Vos steering files, skills et custom agents sont automatiquement disponibles sans migration ni reconfiguration.

# Votre structure .kiro existante fonctionne directement
.kiro/
├── steering/          # → Injecté dans les sessions Crew
├── skills/            # → Disponible comme skills Crew
├── agents/            # → Utilisable dans les sessions
└── settings/
    └── mcp.json       # → MCP servers disponibles

Commandes essentielles

# Démarrer une session de chat
kirocrew chat

# Exécuter une tâche
kirocrew run

# Gérer les jobs cron
kirocrew cron

# Spawner des agents parallèles
kirocrew spawn

# Installer comme service système
kirocrew service install
kirocrew service status

# Suivre les logs
kirocrew logs -f

Conclusion de la partie 1

Kiro Crew représente un saut qualitatif dans l'outillage développeur : on passe d'agents conversationnels éphémères à un workspace persistant, auto-apprenant et autonome. L'architecture Gateway/Sessions/ACP est solide, le modèle de sécurité est conçu pour la production, et l'open source garantit la transparence.

Dans la seconde partie, nous verrons les cas d'usage concrets : jobs cron, investigation d'incidents multi-repo, migration avec checkpoints, Apps (DevFleets, Issue Radar, Code Review Sage), et les perspectives d'utilisation pour une équipe de développement.

Sources :

kiro.dev/crew — Page produit officielle
kiro.dev/blog/introducing-kiro-crew — Blog post de lancement
github.com/kirodotdev/KiroCrew — Repository GitHub

Accès centralisé aux comptes racine pour votre organisation AWS

sylvainbruas — Mon, 10 Aug 2026 12:16:12 +0000

Chaque responsable de landing zone AWS cherche à réduire la surface d'attaque pour protéger au mieux les systèmes d'information. Une des ressources critiques de la landing zone est le compte racine associé à chaque compte AWS.

Les comptes AWS, même intégrés dans une organisation, possèdent chacun un compte racine. Ces comptes racine étaient indispensables pour effectuer certaines opérations critiques, comme par exemple lors de la configuration initiale du compte et pour débloquer des buckets Amazon Simple Storage Service (Amazon S3), des queues Amazon Simple Queue Service (AmazonSQS).

Ces opérations, qui doivent rester le plus rare possible, nécessitaient l'utilisation du compte racine et la récupération du dispositif MFA physique dans le coffre de l'entreprise. Ces démarches fastidieuses pour se connecter au compte racine étaient nécessaires pour assurer la sécurité. Elles n'étaient pas suffisante pour totalement protéger le compte AWS, car un collaborateur utilisant le compte racine peut effectuer n'importe quel appel API de services AWS, ce qui représente un risque élevé.

Depuis mi-novembre 2024, AWS propose une nouvelle méthode pour simplifier ces opérations via l'accès racine centralisé.
Il n'est plus nécessaire de récupérer le mot de passe du compte racine de chaque compte membre de l'organisation. Les opérations de déblocage de bucket S3 ou de file d'attente SQS peuvent être initiées par un utilisateur IAM ayant les autorisations nécessaires sur un compte membre. La gestion de la récupération du mot de passe racine est maintenant centralisée au niveau du compte payeur.

En utilisant cette méthode, nous pouvons réduire la surface d'attaque et simplifier le modèle opérationnel pour résoudre les erreurs liées à IAM, SQS et S3. Cette méthode permet également de réduire la charge de travail lors du départ d'un administrateur des comptes AWS.

Notre environnement pour cet article

Nous disposons d'une organisation existante avec plusieurs comptes membres pour lesquels nous avons configuré un mot de passe pour chaque compte racine ainsi que l'authentification multi-facteurs (MFA). Un nouveau compte Sandbox nommé Sandbox Sylvain a été créé, mais nous ne nous y sommes jamais connectés.

Nous avons également un compte Breaking Glass avec quelques utilisateurs IAM de secours nous permettant de nous connecter si AWS Identity Center ne fonctionne plus comme attendu.

Mise en place

La première étape est d'activer l'accès centralisé aux comptes racine au niveau du compte payeur de votre organisation. Cette fonctionnalité se trouve au niveau d'IAM si vous passez via la console, vous pouvez également faire cette opération via la CLI.

Pour effectuer cette première étape, vous devez avoir les autorisations suivantes :

  iam:EnableOrganizationsRootCredentialsManagement
  iam:EnableOrganizationsRootSessions
  organizations:RegisterDelegatedAdministrator
  organizations:EnableAwsServiceAccess

Via la CLI

 > aws iam enable-organizations-root-credentials-management
 > aws iam enable-organizations-root-sessions

Via la console

Nous allons dans le service IAM puis cliquer sur le menu de gauche sur le lien Root Access Management

Nous allons utiliser notre compte Breaking Glass comme compte administrateur délégué. Ainsi, nous pourrons non seulement intervenir sur les comptes membres en cas de problème avec nos comptes IAM Breaking Glass, mais en dernier recours, nous pourrons également recréer des identifiants pour le compte racine des comptes membres.

Pour maintenir une observabilité maximale sur ce compte Breaking Glass, nous ajouterons de nouvelles alarmes liées aux nouvelles possibilités offertes à nos utilisateurs IAM.

Nous voyons maintenant la section Centralized root access for member accounts activée.

En cliquant de nouveau sur Root Access Management, vous obtenez la liste des comptes, avec l'indication de la présence ou non d'accès racine. Dans notre cas, le compte Breaking Glass bénéficie de cette fonctionnalité, tandis que les autres comptes ont toujours les accès racine activés.

Validation de la mise en place

Nous n'avons pas encore récupéré le mot de passe pour le compte racine sur le compte Sandbox Sylvain.
Nous allons maintenant vérifier que tout cela fonctionne comme attendu, c'est à dire avoir un message d'erreur lors du processus de récupération du mot de passe.

Essayons de faire un reset du mot de passe.

Rien ne change pour la demande d'oubli du mot de passe et l'envoi de l'email se fait sans problème.

Quand nous utilisons le lien, nous avons un message nous indiquant la désactivation de la fonctionnalité, comme attendu.

Il ne reste plus qu'à retirer les accès au compte racine sur tous les comptes membre de l'organisation. Vous pouvez le faire via la console ou la CLI.

Utilisation de assumeRoot et moindre privilège

Même si l'utilisation de l'API assumeRoot est limitée aux politiques IAM suivantes, il est nécessaire de restreindre son utilisation car avec IAMCreateRootUserPassword, nous pourrions réaliser une élévation de privilèges.

Liste des politiques disponibles :

 IAMAuditRootUserCredentials
 IAMCreateRootUserPassword
 IAMDeleteRootUserCredentials
 S3UnlockBucketPolicy
 SQSUnlockQueuePolicy

Nous allons donc répartir les droits entre deux profils d'utilisateurs :

Administrateurs de comptes AWS	Opérateurs
IAMAuditRootUserCredentials	S3UnlockBucketPolicy
IAMCreateRootUserPassword	SQSUnlockQueuePolicy
IAMDeleteRootUserCredentials

Seuls les administrateurs d'Identity Center et de comptes AWS sont habilités à accorder les droits de connexion sur le compte racine. Ce sont eux également qui gèrent les comptes "breaking glass" et qui appliqueront les mêmes politiques sur ces comptes IAM de secours.

Nous allons créer un permset dédié aux opérateurs, que nous allons appeler UnlockS3SQS. Nous avons délégué la gestion de IAM identity center au compte breaking glass, nous allons donc utiliser celui-ci pour la connexion des Administrateurs et des Opérateurs.

Exemple de politique suivant le principe du moindre privilège pour permettre la gestion des comptes racines par les opérateurs via la console AWS et la CLI :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "Statement1",
         "Effect": "Allow",
         "Action": [
           "organizations:DescribeOrganization",
           "organizations:ListAccounts",
           "organizations:ListChildren",
           "sts:AssumeRoot",
           "organizations:ListAWSServiceAccessForOrganization",
           "organizations:ListDelegatedAdministrators",
           "organizations:ListOrganizationalUnitsForParent",
           "organizations:ListParents",
           "organizations:ListRoots",
           "organizations:ListAccountsForParent",
           "organizations:DescribeAccount",
           "organizations:DescribeOrganizationalUnit",
           "iam:ListOrganizationsFeatures"
         ],
         "Resource": "*"
       }
     ]
   }

Nous allons interdire la réactivation du compte racine des comptes membres via une Service control Policy (SCP). Si un adminitrateur de compte AWS doit rétablir un compte racine, il devra donc desactiver la SCP sur le compte cible avant tout autre opération.

SCP pour bloquer la réactivation d'un compte racine :

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "Statement2",
               "Effect": "Deny",
               "Action": [
                   "iam:CreateLoginProfile"
               ],
               "Resource": "*",
               "Condition": {
                   "ForAnyValue:Bool": {
                       "aws:AssumedRoot": "true"
                   }
               }
           }
       ]
   }

Réflexions sur la gouvernance

Nous réduisons notre surface d'attaque grâce à la centralisation des accès aux comptes racine. Bien que les tentatives de force brute soient déjà compliquées avec les mécanismes de protection sur le formulaire de récupération de mot de passe, rien n'est plus efficace que la désactivation d'une fonctionnalité.

Le cycle de vie et la protection des mots de passe des comptes racines sont ainsi réduits à un seul élément à gérer. En cas de départ d'un gestionnaire de la landing zone, il suffit de modifier un seul mot de passe pour s'assurer que seules les personnes habilitées auront accès aux comptes racines.
Cette première ligne de défense est donc maintenant plus facile à gérer, elle restera renforcée par le MFA physique stocké dans un coffre, dont les gestionnaires de la landing zone n'ont pas le code.

Il n'y a plus d'opérations courantes nécessitant l'utilisation du compte racine et la récupération du MFA associé. Un compte IAM supervisé est suffisant, et cette fonctionnalité ne permet qu'une liste FINIE d'actions strictement nécessaires.

Nous pouvons suivre l'utilisation aisément via AWS CloudTrail, tout en maintenant le même niveau d'observabilité.

Conclusion

L'utilisation de cette méthode améliore la sécurité de votre landing zone. Vous pourriez constater une baisse transitoire de votre score sur certains frameworks de sécurité. Cette fonctionnalité étant assez récente, elle n'est pas encore prise en compte et pourrait être considérée comme un compte racine sans MFA pour le protéger.
Par exemple, Scoutsuite considère qu'il n'y a pas de MFA associé au compte racine. Au moment de la rédaction de cet article, aucune pull request n'est ouverte pour corriger ce point.

Comme nous l'avons vu tout au long de cet article, l'accès au compte racine centralisé apporte une grande facilité de gestion, mais il faut rester prudent. L'API IAMCreateRootUserPassword pourrait permettre une élévation de privilèges. Une étude des impacts sur la sécurité est donc indispensable, et le respect de la séparation des responsabilités ainsi que du principe du moindre privilège est nécessaire pour réduire les risques.