Fermez le laptop, les agents continuent : du compute cloud dédié pour vos agents de codage IA

Mercredi matin, 8h30. Vous ouvrez votre laptop, vous touchez votre Yubikey, et trois secondes plus tard, iTerm2 affiche six panes — un par instance Amazon Elastic Compute Cloud (Amazon EC2). Chaque pane est déjà connecté via tmux. Les agents de codage que vous avez lancés hier soir ont continué de travailler pendant la nuit. Vous vérifiez les résultats, vous mergez, vous passez à la suite.

Il y a un an, ce scénario n’existait pas. Ce post vous montre comment mettre en place une infrastructure Amazon Web Services (AWS) dédiée aux agents de codage autonomes, pour que votre équipe gagne en productivité sans sacrifier la sécurité ni la réactivité du poste local.

Les agents de codage en 2025-2026 : un changement de paradigme

Le paysage a basculé en quelques mois. En 2024, l’assistant IA était un copilote dans l’éditeur — une boucle synchrone où vous tapiez un prompt, attendiez la réponse, relisiez, itériez.

En 2025, les agents sont devenus autonomes. Ils peuvent lire un codebase, planifier des modifications, écrire du code, exécuter des tests, et itérer seul jusqu’à ce que les tests passent. Le développeur n’est plus dans la boucle d’exécution. Il définit l’intention, l’agent exécute.

L’adoption est massive. Selon le Pragmatic Engineer Survey de février 2026, 95 % des 15 000 développeurs interrogés utilisent des outils IA au moins une fois par semaine. 75 % les utilisent pour plus de la moitié de leur travail. 70 % jonglent avec 2 à 4 outils simultanément. Selon SemiAnalysis, les agents de codage autonomes représentent une part croissante des commits publics sur GitHub. Chez Stripe, les « Minions » (Part 1, Part 2) — des agents de codage autonomes — produisent plus de 1 300 pull requests par semaine, toutes revues par des humains. Le rapport Octoverse 2025 de GitHub confirme la tendance. Près d’un milliard de commits ont été poussés en 2025, soit 25 % de plus que l’année précédente. 43 millions de pull requests sont mergées chaque mois. La moitié des projets open source ont au moins un mainteneur qui utilise un assistant IA.

Ce qui change pour le développeur au quotidien, c’est la possibilité de travailler sur plusieurs features en même temps. Vous lancez un agent sur le refactoring du module d’authentification pendant que vous supervisez un autre agent qui écrit les tests d’intégration d’une nouvelle API. Vous n’attendez plus qu’une tâche soit finie pour passer à la suivante. Le développeur devient un administrateur d’agents : il distribue le travail, surveille l’avancement, revoit les résultats, et merge.

Mais ce mode multi-agent a un coût physique. Trois à cinq agents en parallèle saturent le laptop. La consommation mémoire augmente significativement, les ressources locales deviennent insuffisantes, et si vous fermez le couvercle, tout s’arrête. Les agents IA ont besoin de compute durable, pas d’un portable qui dort.

Cette séparation entre le poste de travail et le compute apporte quatre avantages concrets. La machine locale reste réactive — elle ne fait que piloter. L’instance Amazon EC2 dispose de ressources dédiées — RAM, CPU, stockage — dimensionnées pour la charge des agents. Les agents accèdent directement aux ressources internes via le réseau privé AWS, sans tunnel ni VPN supplémentaire. Et surtout, la continuité de session : vous fermez le laptop, vous le rouvrez le lendemain, et tmux rattache exactement là où vous en étiez.

C’est exactement ce que cette architecture met en place : des instances dédiées, provisionnées en Infrastructure as Code comme AWS CDK ou AWS CloudFormation, accessibles sans port entrant exposé, avec des serveurs MCP pré-configurés et une authentification corporate transparente.

La config centralisée qui pilote tout

Un seul fichier YAML — config.yaml à la racine du projet — déclare l’ensemble de l’environnement : la région AWS, les noms des instances, et les repos à cloner.

aws:
  region: eu-west-1

instances:
  - sarah-connor
  - marie-lys
  - eva-lou
  - anna-lea

repos:
  authentication:
    - name: origin
      url: "https://git.internal/team/authentication"
  selfcare:
    - name: origin
      url: "https://git.internal/team/selfcare"
  admin:
    - name: origin
      url: "https://git.internal/team/frontend"

Ce fichier est consommé par deux choses. D’abord le code d’Infrastructure as Code : il lit la liste instances et crée une instance Amazon EC2 par nom, avec son rôle IAM, son security group et son volume persistant. Ensuite les scripts de provisionnement : chaque script Python lit ce même fichier pour savoir sur quelles machines déployer et quels repos cloner.

En quelques minutes, les instances sont créées et accessibles via SSM. Reste ensuite à les provisionner — c’est l’objet des étapes suivantes.

L’accès : SSM, pas SSH

Aucun port entrant n’est configuré sur les instances. Pas de port 22, pas de security group avec des règles entrantes. Tout le trafic passe par AWS Systems Manager (SSM) sur HTTPS port 443.

Côté local, un ProxyCommand dans la config SSH tunnelise la connexion via SSM :

Host i-* mi-*
    User ec2-user
    ProxyCommand sh -c "aws ssm start-session --target %h \
        --document-name AWS-StartSSHSession \
        --parameters 'portNumber=%p'"
    ForwardAgent yes
    ControlMaster auto
    ControlPath ~/.ssh/control-%C
    ControlPersist 5m
    ServerAliveInterval 15

Un script python génère automatiquement des alias pour chaque instance. Le script résout les noms via les tags EC2 et écrit les blocs Host dans ~/.ssh/config.

Le ForwardAgent yes est l’élément central de cette configuration. L’authentification corporate est transférée via l’agent SSH. Sur l’instance, vous accédez à vos ressources d’entreprise sans stocker de credential sur la machine distante. Cette approche est conçue pour que les secrets restent dans la mémoire de l’agent SSH local. Attention: ce principe est à valider avec votre équipe Sécurité.

Le provisionnement : six étapes via SSM

Une fois l’infrastructure déployée, six étapes de provisionnement. Chaque étape est un script Python qui envoie des commandes via SSM SendCommand — en parallèle sur toutes les instances.

Le pattern est toujours le même :

def deploy_to_instances(instances, commands_fn, label):
    """Deploy commands to instances in parallel via SSM."""
    with ThreadPoolExecutor(max_workers=len(instances)) as pool:
        futures = {pool.submit(_run_one, n, iid): n for n, iid in instances}
        for future in as_completed(futures):
            name, success = future.result()
            print(f"  → {name} {'✅' if success else '❌'}")

Étape 1 — SSH Agent Proxy

Le problème classique du SSH agent forwarding : quand vous vous reconnectez, le socket change de chemin. Tout ce qui pointait vers l’ancien socket est cassé.

La solution : un service systemd qui surveille les sockets et maintient un lien symbolique fixe à /tmp/ssh-agent-fixed.

#!/bin/bash
FIXED_SOCKET="/tmp/ssh-agent-fixed"
while true; do
    ACTIVE_SOCKET=$(find /tmp -maxdepth 2 -name 'agent.*' \
        -user ec2-user -type s 2>/dev/null | head -1)
    if [ -n "$ACTIVE_SOCKET" ] && [ -S "$ACTIVE_SOCKET" ]; then
        CURRENT_TARGET=$(readlink "$FIXED_SOCKET" 2>/dev/null)
        if [ "$CURRENT_TARGET" != "$ACTIVE_SOCKET" ]; then
            rm -f "$FIXED_SOCKET"
            ln -s "$ACTIVE_SOCKET" "$FIXED_SOCKET"
        fi
    fi
    sleep 5
done

Vous vous reconnectez, le proxy met à jour le symlink en 5 secondes. tmux, les agents, les git push — tout continue de fonctionner sans interruption.

Cette étape déploie aussi la clé publique SSH sur les instances et configure le keepalive SSHD pour détecter les clients déconnectés.

Étape 2 — MCP Proxy

Le serveur MCP Proxy tourne en service systemd sur le port 3663. Il agrège plusieurs serveurs MCP backend en un point d’accès unique. La config est un fichier JSON déployé sur chaque instance :

{
  "mcpServers": {
    "aws-doc": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "type": "stdio"
    },
    "aws-iac": {
      "command": "uvx",
      "args": ["awslabs.aws-iac-mcp-server@latest"],
      "type": "stdio"
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"],
      "type": "stdio"
    },
    "think": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"],
      "type": "stdio"
    }
  }
}

Le script python de déploiement lit ce fichier, l’envoie via SSM, redémarre le service, et vérifie qu’il est actif. Il déploie aussi la config MCP pour Kiro CLI et IDE dans ~/.kiro/settings/mcp.json.

La solution est agnostique de l’agent de codage, tous consomment le même endpoint MCP. Vous changez d’agent sans reconfigurer l’infrastructure.

Étape 3 — CodeCommit et repos

Ce script clone tous les repos déclarés dans config.yaml.

- Deploying CodeCommit config to 4 instance(s)...
  → sarah-connor ✅
  → marie-lys ✅
  → eva-lou ✅
  → anna-lea ✅

- Cloning 12 repos...
  → sarah-connor ✅
  → anna-lea ✅

Étape 4 — tmux

tmux (terminal multiplexer) vous permet de gérer plusieurs sessions terminal dans une seule fenêtre. Vous ouvrez une session tmux sur un serveur distant, vous pouvez la détacher et vous déconnecter du serveur. Quand vous vous reconnectez, vous rattachez la session (tmux attach) et tout est exactement comme vous l’avez laissé : processus en cours, historique, disposition des panneaux. Cette persistance est particulièrement utile en développement remote. Si votre connexion SSH tombe, vos processus (serveurs de dev, builds, agents) continuent de tourner dans la session tmux au lieu d’être interrompus.

Le script configure aussi le .bashrc pour pointer SSH_AUTH_SOCK vers /tmp/ssh-agent-fixed — ce qui permet aux sessions tmux de bénéficier du SSH agent proxy même après une reconnexion.

Étape 5 — Kiro CLI

Kiro CLI permet de faire tourner des agents headless directement sur l’instance, sans IDE. Le déploiement commence par l’installation du CLI via le script officiel envoyé par SSM. Le script synchronise alors le répertoire ~/.kiro/ via rsync — steering files, hooks, skills, MCP configs — en excluant les sessions et extensions locales. Enfin, il fusionne les settings locaux dans le cli.json distant.

L’agent headless travaille avec les mêmes règles que votre IDE local. Les steering files, les hooks — tout est synchronisé.

iTerm2 : une grille de panneaux automatique

Le script launch_iterm2.py utilise l’API Python d’iTerm2 pour créer une fenêtre avec un pane par instance, arrangés en grille. Chaque pane se connecte via SSH/SSM et attache automatiquement une session tmux :

for name, _iid in instances:
    remote_cmd = "tmux new-session -A -s main"
    cmd = (
        f'while true; do echo "Connecting to {name} (tmux)..."; '
        f"ssh -A -t {name} {remote_cmd!r}; "
        f'"\\n[Disconnected] Reconnecting in 3s..."; '
        f"sleep 3; done"
    )
    panes.append((name, cmd))

La boucle while true gère les reconnexions automatiques. Si la connexion SSH tombe, le pane attend 3 secondes et se reconnecte. tmux rattache la session existante — vous retrouvez exactement où vous en étiez.

La grille est calculée automatiquement : pour 6 instances, vous obtenez 3 colonnes × 2 lignes. Pour 4, 2×2. Le layout s’adapte au nombre d’instances.

Kiro IDE via Remote SSH : l’expérience IDE complète

iTerm2 + tmux, c’est le mode terminal — idéal pour superviser des agents headless et lancer des commandes. Mais quand vous voulez naviguer dans le code, faire une revue de spécifications, ou piloter l’agent Kiro avec tout le confort de l’IDE, il y a Kiro IDE en Remote SSH.

Kiro IDE utilise l’extension Open Remote-SSH pour se connecter à l’instance Amazon EC2. La connexion passe par le même ProxyCommand SSM que le terminal — pas de port entrant requis, même tunnel HTTPS/443. Vous ouvrez la palette de commandes, tapez « Remote-SSH: Connect to Host », et sélectionnez le nom de l’instance (sarah-connor, eva-lou…). Les alias SSH générés précédemment fonctionnent directement.

Une fois connecté, Kiro IDE tourne sur l’instance. L’édition, l’indexation, les extensions, le terminal intégré — tout s’exécute côté serveur. Seule l’interface graphique reste locale. L’agent Kiro intégré à l’IDE accède aux serveurs MCP directement sur localhost:3663, sans latence réseau. Les steering files, les hooks, la config MCP — tout est déjà en place grâce à l’étape d’install kiro qui a synchronisé ~/.kiro/.

Le résultat : vous avez deux modes d’accès complémentaires à la même instance. iTerm2 + tmux pour le multi-pane, la supervision, les agents headless. Kiro IDE Remote SSH pour le développement interactif avec l’agent intégré. Les deux coexistent — vous pouvez avoir Kiro IDE ouvert sur un projet pendant que tmux fait tourner un agent Claude Code sur un autre projet, sur la même machine.

Le Dock Launcher : un clic pour tout démarrer

Le workflow quotidien complet est encapsulé dans une application macOS .app que vous glissez dans le Dock. Au lancement, l’application ouvre un terminal visible pour l’authentification corporate (bloquant — touchez la Yubikey). Une fois authentifié, trois actions se déclenchent en parallèle : iTerm2 s’ouvre avec la grille SSH/tmux, Kiro IDE se lance avec le workspace multi-root, et le déploiement de Kiro CLI synchronise la config en arrière-plan.

L’app est un bundle macOS minimal : un shell script qui ouvre iTerm2 et exécute le launcher Python. Elle récupère même l’icône de Kiro.app pour le Dock.

Vue d’ensemble

Le diagramme ci-dessous illustre l’architecture complète. Le poste local (macOS) se connecte aux instances Amazon EC2 via AWS Systems Manager, sans port entrant. Chaque instance héberge tmux, le MCP Proxy, les repos clonés et Kiro CLI. Le développeur accède aux instances soit via iTerm2 en mode terminal, soit via Kiro IDE en Remote SSH

Considérations de coût

Les instances Amazon EC2 tournent en continu pour garantir la persistance des sessions. Pensez à dimensionner le type d’instance en fonction du nombre d’agents simultanés et à mettre en place des politiques d’arrêt automatique (par exemple via AWS Instance Scheduler) pour les périodes d’inactivité prolongées comme les week-ends. Vous pouvez aussi utiliser des Savings Plans ou des instances Reserved pour réduire le coût si l’usage est prévisible.

Conclusion

Cette architecture fournit l’infrastructure pour les agents de codage CLI. Chaque membre de l’équipe se connecte avec l’agent de son choix et accède instantanément à des outils pré-configurés. L’infrastructure est la même. Seul le client de codage change.

Les agents travaillent en arrière-plan sur l’instance Amazon EC2 pendant que le développeur orchestre, vérifie et intègre. Le laptop reste réactif. Les sessions tmux persistent. L’architecture est conçue pour que les credentials restent en mémoire et ne soient pas stockées sur les instances distantes. Le résultat : une équipe qui peut lancer plusieurs agents en parallèle, sur du compute dédié, avec une expérience de développement fluide dès la première connexion.