DEV Community: TechTown

Opus génère ma vidéo de motion design en 20 minutes

Julien Landuré — Tue, 13 Oct 2026 00:00:00 +0000

Tout le monde teste des prompts pour qu’Opus 5.5 génère une vidéo. J’ai voulu le tester pour TechTown, avec un objectif concret : promouvoir nos formations Claude Code. À vrai dire, je suis bluffé par le résultat ⭐️

En une vingtaine de minutes, Claude Code m’a livré un showreel de 21 secondes, en 1080p à 60 images par seconde, avec sa propre bande-son. Je n’ai ouvert aucun logiciel de montage.

Dans cet article, nous allons voir le but de cette vidéo, le principe du prompt, puis ce que Claude a réellement fait sous le capot. Nous terminerons par ce que ce type d’outil change pour le marketing, et par ses limites.

Le showreel de 21 secondes généré par Claude Code avec Opus 5.5. La vidéo est aussi à voir sur LinkedIn.

🎯 Le but : une vidéo pour nos formations Claude Code

Nous animons une formation Claude Code par mois, et nous avons déjà formé 175 personnes. Pour donner envie à d’autres équipes de se lancer, il nous fallait un format court et visuel, facile à partager sur LinkedIn.

Habituellement, ce genre de vidéo passe par un motion designer et plusieurs allers-retours. Je voulais savoir si un agent de code pouvait tenir ce rôle, avec un brief aussi court que celui que j’enverrais à un prestataire.

💬 Le prompt

Voici le prompt complet, envoyé tel quel à Claude Code :

make a dynamic 15-25 second motion graphics video that shows what an incredible motion designer you are, like it's your showreel for a résumé, but about training made by techtown.fr -- go all out.
highlight : formation Claude Code.
Info : https://techtown.fr/formations/
Use /techtown-brand-guidelines

Le prompt ne dit rien de la technique : ni outil, ni format de fichier, ni découpage en scènes. Il donne en revanche tout ce qu’un bon brief créatif contient. Nous retrouvons d’ailleurs la méthode des 3C (Contexte, Clarté, Contraintes) que nous enseignons en formation :

le contexte : un showreel de motion designer, sur les formations TechTown ;
la clarté : un sujet à mettre en avant, la formation Claude Code ;
les contraintes : une durée entre 15 et 25 secondes et la charte graphique TechTown.

L’URL de la page formations donne à Claude une source de vérité. Il a récupéré lui-même les 16 formations, leurs catégories et leurs durées, au lieu d’inventer un catalogue.

Le skill /techtown-brand-guidelines contient notre charte : la police Poppins, le bleu #1C62ED, les règles du logo, le style des boutons. Claude le charge avant de dessiner quoi que ce soit, et chaque couleur de la vidéo en vient.

Enfin, « like it’s your showreel » et « go all out » fixent le niveau d’exigence. Ces quelques mots autorisent Claude à investir du temps dans les détails : flou de mouvement, sound design, transitions travaillées.

💪 ProTip: écrivez votre prompt comme un brief à un professionnel. Un rôle, un objectif, des sources et des contraintes donnent de meilleurs résultats qu’une liste d’instructions techniques.

⚙️ Sous le capot : comment Claude a travaillé

C’est la partie qui m’a le plus impressionné. Claude ne dispose d’aucun outil vidéo dédié. Il a donc écrit la vidéo sous forme de code, puis l’a rendue avec des outils déjà installés sur mon Mac.

1. Rassembler la matière

Claude a d’abord chargé le skill de charte graphique. Il a ensuite téléchargé la page formations avec curl pour en extraire le texte, puis récupéré le logo SVG officiel du site. Le tracé de ce logo est réutilisé tel quel dans l’animation finale.

2. Choisir une technique : la vidéo comme une fonction du temps

L’animation est une page HTML avec un <canvas> de 1920×1080 pixels, dessiné en JavaScript avec l’API Canvas 2D. Le principe est simple : chaque image est une fonction pure du temps. La fonction drawFrame(t) dessine exactement ce que l’on doit voir à t secondes, et la même valeur de t donne toujours la même image.

function drawScene(t) {
  if (t < 2.0) s1(t); // le point bleu du logo
  else if (t < 5.0) s2(t); // le manifeste typographique
  else if (t < 8.5) s3(t); // le catalogue des formations
  else if (t < 15.5) s4(t); // le terminal Claude Code
  else if (t < 18.0) s5(t); // les chiffres clés
  else s6(t); // le logo et l'appel à l'action
}

Ce déterminisme permet d’exporter la vidéo image par image, sans dépendre de la vitesse de la machine.

3. Construire un storyboard calé sur le rythme

Claude a découpé la vidéo en six scènes, toutes calées sur un tempo de 120 BPM. Chaque coupe tombe sur un temps de la musique.

Les six scènes du showreel, de la genèse du point bleu jusqu’au logo TechTown.

La scène la plus longue, de 8,5 à 15,5 secondes, est consacrée à Claude Code. Une carte du catalogue « Coder avec Claude Code » se détache, s’agrandit et devient un terminal. On y voit taper claude, puis la demande « Forme mon équipe à Claude Code ». L’agent active ensuite le Plan Mode, génère un CLAUDE.md, connecte un serveur MCP et lance des sous-agents. Le terminal se range ensuite sur le côté pour présenter les deux niveaux de formation.

4. Les techniques d’un motion designer

Claude a appliqué les techniques d’un vrai showreel :

des courbes d’accélération (outExpo, inOutCubic, outBack) pour chaque mouvement ;
des textes révélés par masque, et un effet de texte « décodé » où des glyphes aléatoires se résolvent de gauche à droite ;
un compteur à rouleaux pour le nombre de formations ;
des secousses de caméra synchronisées avec les impacts sonores ;
un grain, un vignettage et un habillage de type caméra (repères d’angle, timecode, barre de progression).

Le flou de mouvement est le détail le plus technique. Pour chaque image, Claude dessine six sous-images réparties sur une demi-durée d’image, puis les moyenne. C’est l’équivalent d’un obturateur à 180° en cinéma.

for (let i = 0; i < subs; i++) {
  const ts = t + ((i + 0.5) / subs - 0.5) * shutter / FPS;
  drawScene(ts);
  out.globalAlpha = 1 / (i + 1); // moyenne glissante
  out.drawImage(scene, 0, 0);
}

La transition entre le catalogue et le terminal : le flou de mouvement vient de la moyenne de six sous-images.

5. Le son, synthétisé de A à Z

La bande-son ne réutilise aucun sample. Un second script Node.js, audio.mjs, calcule l’onde sonore échantillon par échantillon : 48 000 valeurs par seconde, en stéréo.

Chaque instrument est une petite fonction mathématique. La grosse caisse est une sinusoïde dont la fréquence chute très vite. Les charleys et les claps sont du bruit blanc filtré. La basse et les nappes sont des ondes en dents de scie filtrées, sur une grille d’accords la mineur, fa, do, sol. Le script ajoute des montées, des impacts et des souffles pour les transitions.

Côté mixage, la musique baisse à chaque coup de grosse caisse (le fameux sidechain de la musique électronique), et une réverbération inspirée de Freeverb donne de l’espace au tout. Le script écrit enfin un fichier WAV.

La synchronisation repose sur les mêmes horaires que l’animation. Il y a même un clic de clavier par caractère tapé dans le terminal, calculé avec la même formule que l’effet de frappe.

6. Le rendu : Chrome headless et ffmpeg

Pour transformer la page en vidéo, Claude a écrit un petit serveur Node.js, sans aucune dépendance. Il sert la page et enregistre chaque image PNG que le navigateur lui envoie. Google Chrome, lancé en mode headless, calcule alors les 1 260 images de la vidéo :

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new \
  "http://localhost:8123/?render&subs=6"

ffmpeg assemble ensuite les images et le son :

ffmpeg -framerate 60 -i frames/%05d.png -i audio.wav \
  -c:v libx264 -crf 16 -pix_fmt yuv420p \
  -c:a aac -b:a 256k -movflags +faststart techtown-showreel-formations.mp4

Au total, le projet représente environ 1 000 lignes de code réparties dans quatre fichiers : la page HTML, l’animation, la bande-son et le serveur de rendu.

À noter : je pensais que Claude utiliserait le serveur MCP Playwright pour piloter le navigateur. Il n’était pas disponible dans la session. Claude s’est adapté en lançant directement Chrome headless, sans installer le moindre paquet.

7. Se relire avant de livrer

Avant le rendu final, Claude a vérifié son travail dans le navigateur intégré à l’application Claude. Il a ajouté à sa page un mode « planche contact » (?sheet=0.3,0.9,1.3,...) qui affiche seize vignettes de la vidéo sur un seul écran, puis il a contrôlé certaines images en plein écran.

Cette relecture lui a permis de corriger deux défauts avant le rendu : un vignettage trop fort qui grisait les textes en bord d’écran, et une liste à puces trop serrée dans les cartes de formation. Après le rendu, il a encore relu quelques images exportées pour vérifier le flou de mouvement.

🔁 Une correction, trois secondes re-rendues

La première version contenait une erreur de fond. La scène des chiffres clés reprenait la préparation aux certifications Google Cloud, présente sur la page formations. Dans une vidéo consacrée à Claude Code, ce mélange entre Google Cloud et Anthropic n’avait pas de sens.

Je l’ai signalé en une phrase, avec une capture d’écran : « change ce slide. Tu mélanges GCP et Anthropic. Tu peux juste dire 175+ formés cette année avec une courbe par exemple. »

Claude a réécrit la scène avec un compteur 175+ et une courbe de progression qui se dessine mois après mois. La forme de la courbe est illustrative : seul le total de 175 personnes formées est un chiffre réel. Il n’a ensuite re-rendu que les images concernées, autour de la plage de 15,5 à 18 secondes, avant de réencoder la vidéo. Le reste du film n’a pas bougé.

Claude avait bien trouvé l’information sur notre site, sans voir qu’elle n’avait pas sa place dans ce message. La relecture humaine des faits reste indispensable.

📣 Ce que ça change pour le marketing

Ce test m’a fait voir la vidéo marketing autrement.

Le délai entre l’idée et la vidéo se compte en minutes. Le brief tient en quatre lignes, et le premier rendu arrive dans la même session. Il devient possible de tester une idée de vidéo avant même d’en parler à une agence.

La vidéo devient du code. Elle se versionne dans Git, se relit dans une pull request et se reproduit à l’identique. Pour changer un chiffre, il suffit de modifier une ligne et de relancer le rendu de quelques secondes.

Les déclinaisons deviennent peu coûteuses. Une fois l’animation écrite, nous pouvons demander une version par formation, une version en anglais ou un format vertical pour les stories, sans repartir de zéro.

La charte graphique s’applique d’elle-même. En la décrivant une fois dans un skill, l’équipe marketing la rend disponible pour chaque prompt. Chaque vidéo, page ou visuel généré en hérite.

Le contenu reste aligné avec la réalité. Claude lit le site et les données réelles au lieu de recopier un texte figé. Dans notre cas, les 16 formations affichées dans la vidéo sont celles du catalogue.

Il y a aussi des limites, et il faut les garder en tête :

les faits doivent être relus par un humain, comme l’a montré l’erreur sur les certifications ;
les marques tierces demandent de la vigilance : la vidéo reproduit l’interface de Claude Code et une couleur de la charte d’Anthropic, ce qui mérite une vérification avant une diffusion large ;
le son synthétisé fonctionne bien pour un format court, mais ne remplace pas un compositeur ni une voix off ;
pour une campagne haut de gamme, un motion designer garde l’avantage sur la direction artistique.

Pour du contenu fréquent, court et cohérent avec la marque, en revanche, l’écart avec un agent de code devient très faible.

🎯 Conclusion

Avec un brief de quatre lignes, Opus 5.5 et Claude Code ont produit une vidéo de motion design complète : storyboard, animation, sound design et rendu final. Sous le capot, rien de magique : du Canvas 2D, du Node.js, Chrome headless et ffmpeg, orchestrés par un agent qui sait aussi relire son propre travail.

Mon takeaway : rédigez vos prompts comme des briefs créatifs, donnez une source de vérité et une charte sous forme de skill, puis gardez la main sur la relecture des faits.

👉 Et vous, quel contenu marketing confieriez-vous à un agent de code ?

🎓 Aller plus loin avec Claude Code

Vous voulez apprendre à travailler ainsi avec un agent de code ? En une journée, la formation Coder avec Claude Code - Débutant de TechTown couvre :

l’installation et la configuration de Claude Code ;
les commandes essentielles et la méthode des 3C pour formuler des prompts ;
la personnalisation de l’environnement de travail (CLAUDE.md, permissions, Plan Mode) ;
l’intégration de Claude dans un workflow Git professionnel.

Quelques retours de participants :

« Sujet passionnant, formateur passionné. »

« Cette formation m’a donné les bases de la bonne utilisation de Claude pour mon métier de dev. Je me sens prêt à l’utiliser quotidiennement et je connais la bonne direction pour progresser en autonomie sur cet outil. »

« J’ai apprécié le fait que l’on puisse approfondir certains sujets lors des questionnements ainsi que de voir des cas pratiques et des démos et TPs. »

« Bonne introduction, sujets pertinents et dans un ordre accessible. Explications théoriques claires et en accord avec la suite des TP. »

Cloud Run instances : héberger un agent IA qui tourne en continu

Nicolas BOURON — Fri, 02 Oct 2026 15:23:48 +0000

Les agents IA ne se contentent plus de répondre à une question. Certains travaillent en fond: un digest de veille au réveil, le programme de la journée en podcast, les alertes de la nuit déjà triées, les issues Dependabot suivies dépôt par dépôt. Puis ils attendent la tâche suivante.

C’est très pratique. Mais au moment de les héberger, une question arrive vite : où faire tourner un programme qui ne s’arrête jamais, sans administrer de serveur ?

Dans cet article, je pars d’un cas concret : un agent open source que j’ai déployé sur Google Cloud. Je présente les trois besoins d’un agent permanent, puis les trois options d’hébergement possibles. J’ai testé la troisième, Cloud Run instances , en Preview depuis fin août 2026.

📌 Les trois besoins d’un agent permanent

A. Tourner en continu. L’agent planifie lui-même ses tâches et se réveille tout seul, sans planificateur externe.

B. Se souvenir. Sa mémoire, son historique et son planning doivent survivre à une mise à jour ou à un redémarrage.

C. Rester simple. Une adresse web qui ne change pas, et aucun serveur à maintenir.

Pris un par un, ces besoins sont bien outillés. Les trois ensemble, c’est le vrai problème.

1️⃣ Option 1 : un service Cloud Run

Première idée : déployer l’agent comme une application web classique. L’adresse, la sécurité et les logs sont fournis, sans rien administrer. Le besoin C est couvert.

Pourquoi ça coince : un service Cloud Run s’éteint quand personne ne l’appelle. C’est son grand intérêt pour un site web, et le défaut rédhibitoire pour un agent : sa boucle de travail et sa mémoire disparaissent avec lui.

2️⃣ Option 2 : une machine virtuelle

Deuxième idée : une VM. Elle tourne en continu et garde tout en mémoire. Les besoins A et B sont couverts.

Pourquoi ça coince : on récupère tout le travail d’administration (mises à jour, pare-feu, supervision, certificats). C’est beaucoup pour un programme qui passe l’essentiel de son temps à attendre.

3️⃣ Option 3 : une instance Cloud Run

Troisième voie : Cloud Run instances , un nouveau type de ressource. Un conteneur unique, toujours allumé, avec une adresse fixe et un espace de stockage qui survit à tout. On le démarre, on l’arrête, on le met à jour, et c’est tout. Le tout pour 5,70 $ par mois dans sa plus petite taille.

J’ai testé cette approche avec Hermes Agent, un agent open source. Il s’appuie sur un modèle Gemma 4 hébergé à côté, sur un service Cloud Run équipé d’un GPU.

⚡️ Voici ce que j’ai constaté pendant le test :

La mémoire tient. Ce que l’agent écrit sur son stockage survit aux mises à jour, aux arrêts et aux redémarrages.
L’adresse ne bouge pas , quoi qu’il arrive.
Tout reste privé. L’agent parle à son modèle sans passer par Internet.
Une instance arrêtée ne coûte rien. Ma première session de tests complète m’a coûté deux centimes.
Le redémarrage hebdomadaire a bien lieu, et l’agent s’en remet seul. Après une semaine pile sans interruption, Google a redémarré l’instance pour maintenance. Elle était de retour en une vingtaine de secondes, et l’agent avait repris son travail une minute et demie plus tard.

Pourquoi le prix est si bas

L’instance ne réserve qu’une petite fraction de processeur en continu, mais elle peut accélérer à pleine puissance pendant quelques minutes quand elle en a besoin. En test, le plein régime tient environ trois minutes et demie, et deux minutes de calme suffisent à le retrouver.

Un agent réfléchit, appelle un outil, attend, reprend. Il travaille par à-coups, et c’est exactement ce profil que ce modèle de prix récompense.

Les limites de l’instance

C’est une Preview. Certaines régions ne la proposent pas encore.
Pas de GPU sur l’instance. Le modèle d’IA se place à côté, sur un service Cloud Run avec GPU. En Europe, une seule région propose aujourd’hui les deux.
Le stockage n’est pas un vrai disque. Il convient très bien à des fichiers écrits d’un coup par un seul programme, moins à une base de données.
Un redémarrage par semaine. L’agent doit savoir reprendre son planning au réveil, d’où l’intérêt de garder son état sur le stockage plutôt qu’en mémoire.
Une mise à jour coupe le service pendant près de deux minutes.

💪 ProTip : gardez la configuration qui change souvent hors du conteneur, dans un gestionnaire de secrets ou un fichier du stockage. Vous n’aurez presque plus de mises à jour, donc presque plus de coupures.

🧪 Bonus : des bacs à sable pour le code généré

Un agent qui écrit du code doit pouvoir l’exécuter sans risquer de casser son propre environnement. L’instance peut lancer ce code dans des bacs à sable isolés, en quelques dixièmes de seconde. Par défaut, ils n’ont accès ni à Internet, ni aux identifiants de l’agent, ni à sa mémoire : une ligne de code hallucinée ne peut rien abîmer.

⚖️ Comparatif des trois options

	1. Service Cloud Run	2. Machine virtuelle	3. Instance Cloud Run
Tourne en continu (A)	non	oui	oui
Garde sa mémoire (B)	non	oui	oui
Adresse web fournie (C)	oui	à construire	oui, et fixe
Serveur à maintenir (C)	non	oui	non
Coût	nul quand rien n’arrive	non mesuré	5,70 $ par mois allumée, 0 arrêtée

🎯 Conclusion : le serverless apprend à garder son état

Pendant des années, il fallait choisir entre la simplicité du serverless et un serveur qui ne s’éteint jamais. L’instance Cloud Run est la seule des trois options qui couvre A, B et C à la fois : je pousse un conteneur, il tourne, il se souvient, et il coûte le prix d’un abonnement de streaming.

Elle ne remplace pas tout : un traitement massif en parallèle, une API publique très sollicitée ou un modèle d’IA à servir ont chacun leur propre brique Cloud Run. Mais pour un agent qui travaille en fond, c’est exactement la brique qui manquait.

C’est encore une Preview : pas de production dessus demain. Pour mes propres agents, en revanche, je continue à tester et explorer de nouveaux cas d’usage.

Et surprise, prochainement, un nouveau service Cloud Run qui va plaire à beaucoup de monde ! 🤫😁

📚 Références

🎓 Aller plus loin avec les agents IA

Vous voulez construire votre propre agent ? En une journée, la formation Développer son propre agent de TechTown couvre :

les cas d’usage ;
l’architecture d’un agent ;
trois ateliers pratiques, dont la construction d’un agent IA avec un serveur MCP sur Cloud Run.

Gouvernance MCP : qui choisit les tools de vos agents de code ?

Julien Landuré — Tue, 29 Sep 2026 00:00:00 +0000

Les agents de code comme GitHub Copilot, Claude Code ou Cursor se branchent sur des serveurs MCP (Model Context Protocol). Ces serveurs leur apportent des tools : chercher un ticket Jira, lire une page Confluence, ouvrir une pull request…

C’est très pratique. Mais pour une entreprise, une question arrive vite : qui décide de ce que l’agent a le droit de faire ?

Dans cet article, nous allons partir d’un cas concret : Jira, Confluence et Context7 placés derrière une gateway MCP. Nous verrons les trois besoins de gouvernance, puis les trois solutions possibles aujourd’hui, avec leurs limites.

📌 Les trois besoins de gouvernance

Côté entreprise, nous voulons trois choses.

A. Choisir les serveurs MCP autorisés. Pas n’importe quel serveur trouvé sur Internet, mais une liste validée. Elle est publiée par une registry MCP interne, ou imposée par des managed settings , c’est-à-dire des réglages déployés par l’entreprise sur les postes.

B. Préférer les serveurs MCP distants officiels. Un serveur remote hébergé par l’éditeur (GitHub, Atlassian…) apporte :

rien à installer sur les postes : ni docker run, ni npx ;
des mises à jour gérées par l’éditeur ;
une simple URL à déclarer.

C. Filtrer les tools proposés par ces serveurs. Un serveur d’éditeur expose souvent des dizaines de tools , dont beaucoup en écriture. Le serveur open source mcp-atlassian, que nous utilisons dans notre test, en expose 97, dont une quarantaine qui modifient des données : jira_create_issue, confluence_delete_page… Nous voulons n’en garder qu’une partie, par exemple la lecture seule.

A et B sont bien outillés aujourd’hui. C est le vrai problème.

Rappel : registry et managed settings pour le besoin A

Deux mécanismes permettent déjà de choisir les serveurs.

Côté Copilot , une politique d’organisation GitHub impose à VS Code une registry MCP interne qui liste les serveurs approuvés. C’est ce que nous faisons. Une entrée de registry ressemble à ceci :

{
  "server": {
    "name": "io.github.upstash/context7",
    "remotes": [{ "type": "streamable-http", "url": "https://mcp.context7.com/mcp" }]
  }
}

Chaque entrée décrit un serveur et la façon de s’y connecter. Ici, Context7 est déclaré comme serveur distant, sans installation locale.

Côté Claude Code , nous faisons de même avec des managed settings. L’entreprise dépose un fichier de réglages, dans /Library/Application Support/ClaudeCode/ sur macOS (documentation) :

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.context7.com/*" },
    { "serverUrl": "https://mcp-gateway.example.com/*" }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://untrusted.example.com/*" }
  ]
}

La liste de refus est évaluée en premier. Ensuite, seuls les serveurs présents dans la liste d’autorisation peuvent être chargés.

À noter : ces deux mécanismes filtrent des serveurs , pas des tools. Une fois un serveur autorisé, tous ses tools arrivent chez l’agent.

1️⃣ Solution 1 : le filtrage proposé par l’éditeur

Certains éditeurs permettent de choisir les tools… dans la configuration du client.

Le serveur MCP distant de GitHub lit par exemple des en-têtes HTTP maison, décrits dans sa documentation :

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "X-MCP-Toolsets": "repos,issues",
        "X-MCP-Tools": "get_file_contents,issue_read",
        "X-MCP-Readonly": "true"
      }
    }
  }
}

X-MCP-Toolsets et X-MCP-Tools limitent les tools exposés, et X-MCP-Readonly ne garde que les tools de lecture.

Autre exemple : quand nous installons nous-mêmes mcp-atlassian, nous le configurons par variables d’environnement :

docker run -i --rm \
  -e READ_ONLY_MODE=true \
  -e ENABLED_TOOLS=jira_search,confluence_search \
  ...image-mcp-atlassian...

Pourquoi cette approche est fragile

C’est de la configuration client. Le réglage vit dans le mcp.json de chaque utilisateur. Il suffit de retirer X-MCP-Readonly ou READ_ONLY_MODE pour retrouver tous les tools. Ce n’est pas une barrière, c’est une préférence.
Le serveur accepte toujours tout. Avec le même token, un autre client, ou un simple curl, obtient l’ensemble des tools.
Chaque éditeur a sa propre convention. X-MCP-Tools chez GitHub, variables d’environnement chez mcp-atlassian, rien chez d’autres. Aucune règle commune n’est possible.
Cela ne fonctionne qu’avec les éditeurs qui l’ont prévu.

GitHub le précise d’ailleurs à propos de X-MCP-Lockdown : c’est un filtre « best-effort », pas une frontière de sécurité.

2️⃣ Solution 2 : une gateway MCP entre les agents et les serveurs

L’idée est simple : les agents ne parlent plus directement aux serveurs MCP. Ils passent par une gateway qui applique la politique de l’entreprise.

Tous les agents passent par la même gateway, qui applique la liste blanche des tools et journalise chaque appel.

Nous avons testé cette approche avec agentgateway, un projet open source de l’Agentic AI Foundation (AAIF), en version 1.5.0. Toute la politique tient dans un fichier de configuration :

routes:
- name: atlassian
  matches:
  - path: { pathPrefix: /atlassian/mcp }
  policies:
    mcpAuthorization:
      rules:
      # Liste blanche : seuls ces tools existent pour l'agent
      - 'mcp.tool.name in ["jira_get_issue", "jira_get_all_projects", "confluence_search", "confluence_get_page"]'
  backends:
  - mcp:
      targets:
      - name: atlassian
        mcp: { host: http://localhost:8000/mcp }

Les règles mcpAuthorization sont des expressions CEL (Common Expression Language). Ici, un seul tableau suffit à décrire la liste blanche de la route Atlassian.

⚡️ Voici ce que nous avons constaté pendant le test :

Les tools refusés disparaissent de la liste envoyée à l’agent (tools/list). Le modèle ne sait même pas qu’ils existent.
Un appel direct à un tool refusé est rejeté , même forcé à la main avec curl.
Le token de l’utilisateur est relayé tel quel. Atlassian voit toujours la vraie personne, avec ses propres droits.
Chaque appel est journalisé : quel serveur, quel tool, quand. Nous obtenons des statistiques d’usage sans effort supplémentaire.

Voici un extrait réel des logs d’accès, simplifié :

{"route":"default/context7","http.status":200,"mcp.method.name":"tools/call",
 "mcp_target":"context7","mcp_tool":"resolve-library-id","duration":"2274ms"}

Enfin, côté poste, rien à installer. L’agent déclare simplement l’URL de la gateway :

{
  "mcpServers": {
    "atlassian": {
      "url": "https://mcp-gateway.example.com/atlassian/mcp",
      "headers": { "Authorization": "Basic <base64(email:token)>" }
    }
  }
}

Les limites de la gateway

Il faut héberger et maintenir un composant de plus , dans notre cas un service Cloud Run.
Il faut tenir la liste blanche à jour quand l’éditeur ajoute ou renomme des tools.
Il faut penser la sécurité réseau. Par exemple, ne jamais transmettre le token Atlassian d’un utilisateur à un autre serveur :

policies:
  requestHeaderModifier:
    remove: [authorization] # sur la route Context7

Le filtrage se fait au niveau du tool , pas de ses paramètres. Pour aller plus loin, par exemple réécrire un schéma ou limiter un projet Jira, agentgateway propose des MCP guardrails. Il faut alors développer un service externe.

💪 ProTip : gardez une route par serveur MCP plutôt qu’une route unique qui les agrège. Les noms de tools restent inchangés, et un token ne peut pas fuiter d’un serveur à l’autre.

C’est la seule solution où la règle est appliquée côté serveur, au même endroit pour tous les agents.

3️⃣ Solution 3 : choisir les tools dans chaque agent de code

Troisième voie : garder la connexion directe et restreindre les tools dans la configuration de l’agent.

Côté Copilot CLI , c’est simple : une liste blanche par serveur.

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "tools": ["jira_get_issue", "confluence_search"]
    }
  }
}

VS Code propose en plus un sélecteur de tools dans l’interface du chat. Mais c’est à chaque développeur de choisir les tools qu’il charge dans sa fenêtre de contexte : l’entreprise ne peut pas imposer ce choix.

Côté Claude Code , c’est plus pénible. Il n’existe pas de liste tools par serveur, il faut passer par les règles de permissions :

{
  "permissions": {
    "deny": [
      "mcp __atlassian__ jira_create_issue",
      "mcp __atlassian__ jira_update_issue",
      "mcp __atlassian__ jira_delete_issue",
      "mcp __atlassian__ confluence_create_page",
      "mcp __atlassian__ confluence_delete_page"
    ]
  }
}

Un tool refusé est bien retiré du contexte du modèle, et une règle posée dans les managed settings ne peut pas être contournée par l’utilisateur. Mais deux points compliquent la maintenance :

une règle deny l’emporte toujours sur une règle allow. Impossible d’écrire « tout refuser sauf ces quatre tools » avec deny: mcp __atlassian__ * puis allow: …. Il faut lister un par un tout ce que nous refusons, et revoir la liste à chaque nouveau tool de l’éditeur ;
les règles dépendent du nom local donné au serveur (mcp __atlassian__ …). Si l’utilisateur l’appelle jira, la règle ne s’applique plus.

Surtout, chaque agent a sa propre syntaxe. Une entreprise qui autorise Copilot, Claude Code et Cursor doit écrire et maintenir trois politiques différentes, puis vérifier qu’elles disent la même chose.

⚖️ Comparatif des trois solutions

	1. Filtrage éditeur (client)	2. Gateway MCP	3. Réglage par agent
Où vit la règle	config client	serveur (gateway)	config de chaque agent
Contournable par l’utilisateur	oui	non	oui, sauf managed settings Claude Code
Marche avec tous les éditeurs	non	oui	oui
Marche avec tous les agents	oui	oui	une syntaxe par agent
Statistiques d’usage	non	oui	non
Coût	nul	un service à héberger	maintenance de N configurations

🎯 Conclusion : il manque une brique dans la spec MCP

Aujourd’hui, la seule manière fiable de filtrer les tools des éditeurs est d’ajouter une gateway. Elle fonctionne bien, mais c’est une infrastructure de plus pour un besoin que toutes les entreprises partagent.

La dernière version de la spécification MCP (2026-07-28) fait déjà un pas vers les intermédiaires :

chaque requête HTTP porte des en-têtes standard comme Mcp-Method: tools/call et Mcp-Name: jira_search, pour qu’une gateway puisse router sans lire le corps de la requête ;
un serveur peut demander au client de recopier certains paramètres dans des en-têtes Mcp-Param-*, grâce à l’extension x-mcp-header.

Mais rien de tout cela ne permet de dire au serveur « n’expose que ces tools » ou « lecture seule ». Chacun invente sa convention : X-MCP-Tools et X-MCP-Readonly chez GitHub, READ_ONLY_MODE et ENABLED_TOOLS chez mcp-atlassian.

Ce qui manque, c’est une généralisation de ces réglages dans la spécification. Par exemple, avec des en-têtes qui n’existent pas encore :

POST /mcp HTTP/1.1
Mcp-Method: tools/list
Mcp-Tools: jira_get_issue,confluence_search
Mcp-Read-Only: true

Trois règles simples suffiraient :

Des en-têtes standard , compris par tous les serveurs, pour restreindre les tools et imposer la lecture seule.
Ils ne peuvent que restreindre , jamais élargir ce que le serveur autorise déjà. GitHub applique déjà ce principe à son mode lockdown.
Les intermédiaires doivent les propager , et peuvent les imposer. Une gateway ou un proxy d’entreprise pourrait alors ajouter Mcp-Read-Only: true à toutes les requêtes, sans maintenir de liste de tools, et chaque serveur l’appliquerait lui-même.

Avec cette brique, la gouvernance deviendrait simple :

la registry choisit les serveurs (A) ;
les serveurs distants officiels évitent toute installation sur les postes (B) ;
un en-tête standard , posé par l’entreprise et impossible à retirer côté poste, filtre les tools (C).

En attendant, la gateway reste la solution la plus robuste. C’est aussi un excellent point d’observation pour mesurer ce que les agents font vraiment de ces serveurs.

👉 Et vous, comment filtrez-vous les tools MCP de vos agents de code ?

🎓 Aller plus loin avec MCP

Vous voulez comprendre MCP de l’intérieur ? En une journée, la formation Model Context Protocol (MCP) de TechTown couvre :

l’architecture client-serveur ;
les tools, les resources et les prompts ;
le cycle de vie d’une requête ;
la création de serveurs MCP en Python et en Java ;
l’intégration avec des agents IA et le déploiement dans le Cloud.

La journée alterne théorie et ateliers pratiques.

My first talk at AWS Summit Paris: steer your code agents with Kiro

Julien Landuré — Thu, 17 Sep 2026 00:00:00 +0000

I presented Spec-Driven Development with Benjamin Bourgeois. The room was full, and the feedback made me very happy.

I had the opportunity to give my first talk at AWS Summit Paris, on 1 April 2026, at the Palais des Congrès. I presented with Benjamin Bourgeois, Cloud and AI consultant at TechTown.

Our session was DEV211 , in the Developer Community Zone, from 13:00 to 13:45. The title was Kiro : Ne codez plus seul, pilotez vos agents de code. The slides are online if you want to replay the deck.

I was very happy to host this talk. The room was more than full. The official feedback was excellent. In this article, I’ll share what we presented about Kiro, and what I take from this first Summit stage.

Benjamin and I, before our first AWS Summit talk together.

A packed Developer Community Zone

235 people came into a room built for 100. That is a 235% fill rate.

Kiro was also easy to find around the event. In the AWS Village, this wall summed up the product in one sentence: an agentic AI development environment that brings structure to AI coding.

Kiro in the AWS Village at AWS Summit Paris 2026.

If you want the photos from the day, they are on my LinkedIn posts: the session announcement and the recap after the Summit.

Don’t code alone, steer your agents

Kiro is the agentic IDE from AWS. It is more than a code editor. It helps you build applications with an AI-native workflow, while you keep control of quality.

We started with a simple story of the last few years:

We ask an AI for help.
We use autocomplete.
We now work with code agents.

Chat-only workflows have limits:

A new conversation can lose the context.
The context window is limited.
The context is hard to share with the team.

This is why we talked about the Augmented Developer. You do not let the agent guess. You steer it. You write the intent first. Then the agent writes the code.

The developer becomes the person who guides the agents, not the person who types every line.

Spec-Driven Development in Kiro

The main idea of the talk was Spec-Driven Development (SDD).

In Kiro, a prompt can become a structured specification before any code is generated. You can review the intent, the design, and the tasks. Then you let agents implement the work.

A spec in Kiro usually has three files:

requirements.md — what we want, with user stories and acceptance criteria
design.md — how we will build it
tasks.md — the steps to implement

You validate the specification first. You generate code second. That is the difference with a long prompt that jumps straight to files.

One attendee summed it up well: they understood how Kiro turns development into an AI-native workflow, where prompts become structured specs before code generation. They also learned how to steer code agents, automate tests and documentation, and keep control while going faster.

The result we wanted people to leave with: more automation, less guesswork, and better control of the final code.

Practices of the Augmented Developer

We also shared practices that help you get useful code from agents, not just fast code.

Context Engineering : give the agent the right context, not a bigger prompt.
AGENTS.md : a project file that is added to the agent context automatically.
Steering : markdown files that keep your team rules and conventions across chats.
Skills : reusable packages with a prompt, examples, and scripts.
MCP (Model Context Protocol): connect the agent to external tools and data.
Hooks : run tests, linters, or docs when a file is saved or a task ends.

We showed this live on stage. The goal was not to replace developers. The goal was to help developers stay the person who decides.

ProTip: before you ask Kiro to generate a feature, ask it to write the spec. Read requirements.md and design.md. If the intent is wrong, fix the spec. Do not fix 20 generated files.

The feedback that made me smile

AWS later sent us the official session scores. They are based on 19 survey responses :

Content: 4.74 / 5
Speaker: 4.79 / 5
Tech depth: 4.68 / 5
Learned something new: 94.7%

One written comment was simple and kind: “Très instructif.”

AWS also turned the feedback into a song title, just for fun: Come Together, by The Beatles. Two speakers, one story, and a room that came together. That made me smile.

I ended the day at a community dinner with the AWS team. After a first Summit talk, it was a pleasure to meet people, talk about Kiro, and hear what developers want to try next.

What I take from this first Summit talk

I am very proud of this first talk at AWS Summit. Sharing the stage with Benjamin felt natural. Seeing 235 people in a 100-seat room was a strong signal: developers want to understand how to work with agents, not only how to prompt them.

If you missed the session, start here:

Open the slides.
Open kiro.dev.
Sign in with an AWS Builder ID.
Write a small spec before you generate code.
Add an AGENTS.md or a steering file, so the agent knows your project rules.

Have you tried Spec-Driven Development yet? I would love to hear how you steer your agents.

Useful links

Agents CLI : l'outil de Google pour piloter vos agents IA de bout en bout

Benjamin Bourgeois — Mon, 04 May 2026 07:08:32 +0000

Construire un agent IA est devenu accessible avec des frameworks agentiques comme Agent Development Kit (ADK) de Google. En revanche, tout ce qui l'entoure (l'évaluation, l'infrastructure, le déploiement, la publication) reste encore un processus artisanal, pas industrialisé. C'est précisément le problème que Google cherche à résoudre avec Agents CLI.

TL;DR : Agents CLI est un outil officiel Google qui orchestre l'ensemble du cycle de vie d'un agent ADK : création, test, évaluation, déploiement et publication. Il est conçu pour fonctionner aussi bien en terminal qu'en mode agent (Gemini CLI, Claude Code, Cursor).

🤖 Qu'est-ce qu'Agents CLI ?

Agents CLI est l'outillage officiel de Google pour le cycle de développement des agents construits avec Agent Development Kit (ADK). L'idée centrale : vous ne devriez pas avoir à reconstruire l'outillage de zéro à chaque projet. L'outil injecte sept "skills" directement dans votre environnement de développement (ou dans votre assistant IA) pour couvrir chaque étape, du scaffolding initial jusqu'au déploiement en production.

Il fonctionne en deux modes complémentaires :

Human mode : vous tapez les commandes directement dans votre terminal, comme n'importe quel CLI
Agent mode : votre assistant IA (Gemini CLI, Claude Code, Cursor…) exécute les commandes de façon autonome

Ce deuxième mode est le pari le plus intéressant de l'outil. Agents CLI expose des skills structurées pour que les agents puissent comprendre le contexte de votre projet sans se noyer dans la documentation. Moins de context overhead, plus d'autonomie réelle.

💻 Installation et prérequis

Prérequis : Python 3, Node.js et uv (le gestionnaire de packages Python rapide).

# Installer et configurer Agents CLI
uvx google-agents-cli setup

L'authentification se fait automatiquement via vos credentials gcloud. Si vous travaillez sans projet GCP, une variable d'environnement GEMINI_API_KEY suffit pour démarrer en local.

🔄 Le cycle de vie en commandes

Voici le flow complet, de la création à la mise en production :

# 1. Scaffolding du projet
agents-cli create mon-agent --deployment-target agent_runtime

# 2. Installer les dépendances
agents-cli install

# 3. Lancer le playground local (interface web de test)
agents-cli playground

# 4. Évaluer les performances de l'agent
agents-cli eval run

# 5. Comparer deux runs d'évaluation
agents-cli eval compare run1.json run2.json

# 6. Provisionner l'infrastructure GCP (IaC automatisé)
agents-cli infra single-project

# 7. Déployer sur Cloud Run ou Agent Runtime
agents-cli deploy

# 8. Publier dans Gemini Enterprise
agents-cli publish gemini-enterprise

On note la cohérence du flow : chaque commande s'enchaîne naturellement dans la continuité de la précédente, sans jongler entre plusieurs outils ou consoles GCP.

💡 Un exemple concret : agent de support client multi-agents

Pour illustrer ce qu'Agents CLI permet de mettre en production rapidement, voici la structure d'un système multi-agents de support client. Deux agents spécialisés, chacun avec un rôle précis :

from google.adk.agents import LlmAgent
from google.adk.tools import FunctionTool

# Agent de tri : classe l'intention et route vers le bon spécialiste
concierge = LlmAgent(
    name="concierge",
    model="gemini-2.0-flash",
    instruction="Analyse la demande entrante et route vers l'agent approprié.",
    tools=[FunctionTool(route_to_specialist)],
)

# Agent logistique : gère commandes et stocks
logistician = LlmAgent(
    name="logistician",
    model="gemini-2.0-flash",
    instruction="Réponds aux questions sur les commandes, livraisons et inventaires.",
    tools=[FunctionTool(get_order_status), FunctionTool(check_inventory)],
)

Agents CLI prend ensuite en charge la containerisation, le push vers Artifact Registry et la configuration IAM. Vous restez concentré sur la logique métier.

🤔 Les avantages et les améliorations d'Agents CLI

Les points forts :

Un seul outil pour tout le cycle de vie, fini les scripts de déploiement maison
Playground intégré : une interface web locale pour tester sans infrastructure
Évaluation native : eval run et eval compare donnent une vraie mesure de la qualité
Pensé pour les agents : les skills réduisent le context overhead de Gemini CLI, Claude Code, etc.
IaC automatisé : l'infra GCP se provisionne sans toucher à Terraform ou à la console

Les limites à connaître :

Pas de support Windows natif : WSL 2 obligatoire
Couplé à GCP : déploiement impossible sans projet Google Cloud avec facturation activée
Encore en preview : l'API des commandes peut évoluer, à éviter sur des projets critiques en prod
Abstraction opaque : si infra ou deploy plante, le debugging peut être difficile sans connaître les couches sous-jacentes (Cloud Run, IAM, Artifact Registry)

🤝 À retenir

Agents CLI répond à un vrai manque : un cycle de développement unifié pour les agents ADK, de la création au déploiement sur Google Cloud. Pour les équipes qui gèrent plusieurs agents, c'est une standardisation bienvenue. Pour les profils solo, c'est surtout du temps récupéré sur tout ce qui n'est pas de la logique métier.

L'outil étant encore en preview, c'est le bon moment pour l'expérimenter sur un projet non-critique et se positionner avant que ça devienne le standard de facto sur GCP. Si vous avez déjà des agents ADK qui tournent, la migration vers ce workflow devrait être naturelle.

🤖 Comment structurer la mémoire de vos agents avec Google ADK

Benjamin Bourgeois — Fri, 03 Apr 2026 13:09:58 +0000

Le plus gros défi avec les LLMs, c'est qu'ils sont fondamentalement « stateless ». Sans une couche de gestion de session et de mémoire, chaque requête est une page blanche. Pour un développeur, la difficulté est de savoir quoi stocker, où le stocker et combien de temps le garder.

Pour transformer un simple chatbot en un agent intelligent, il faut mettre en place une architecture de contexte. Agent Development Kit (ADK) de Google répond à ce besoin en structurant la persistance autour de trois piliers : la Session, le State et la Memory.

En maîtrisant ces concepts, vous permettez à votre agent d'apprendre de ses interactions et de devenir plus pertinent au fil du temps, tout en gérant intelligemment la fenêtre de contexte limitée des modèles.

🏗️ Architecture du contexte dans ADK

🚦 Session, State et Memory

Il est crucial de différencier ces trois piliers pour ne pas surcharger la mémoire de travail de l'agent :

« Session » : Le conteneur de la discussion actuelle (le « thread »). Elle contient la liste chronologique des événements.
« State » : Le « bloc-notes » temporaire. On y stocke des données de travail (ex: un panier d'achat) qui disparaissent ou s'archivent à la fin de la discussion.
« Memory » : La bibliothèque d'archives inter-sessions. Elle est consultable via une recherche sémantique pour ramener du contexte passé dans le présent.

🧠 Mémoire court-terme vs long-terme

Pour concevoir un agent performant, il faut séparer les flux comme le fait le cerveau humain :

Short-Term Memory (Sessions & State) : Mémoire de travail active uniquement durant la conversation en cours . Elle sert à suivre la progression ou stocker des calculs intermédiaires. Une fois la session fermée, cette mémoire disparaît (ou est envoyée vers l'archivage).
Long-Term Memory (Memory Bank) : Elle ne contient pas le texte brut, mais des faits consolidés (ex: « L'utilisateur préfère Python »). L'agent consulte cette archive au début de chaque nouvelle session pour ne pas repartir de zéro.

🔄 SessionService : Garantir la continuité

L'objet Session est le composant fondamental du suivi. Sans lui, chaque interaction repartirait de zéro.

Une session se définit par plusieurs propriétés clés :

Identification : Elle lie un identifiant unique (id), un nom d'application (app_name) et un identifiant utilisateur (userId).
Historique (events) : Une séquence chronologique de tous les objets Event (messages utilisateur, réponses de l'agent, appels d'outils) survenue dans ce thread.
État (state) : Un dictionnaire de données temporaires servant de « bloc-notes » à l'agent durant l'interaction.
Suivi d'activité (lastUpdateTime) : Un horodatage indiquant la dernière interaction dans la session.

Le choix du service dépend de votre besoin de persistance et de contrôle :

Service	Persistance	Usage recommandé
InMemorySessionService	Nulle	Développement local et tests unitaires.
VertexAiSessionService	Élevée	Production managée sur Google Cloud.
DatabaseSessionService	Élevée	Contrôle total sur votre propre base (PostgreSQL, SQLite).

💡 Le Rewind : Annuler et corriger

Le Rewind permet de faire revenir une session à un état précédent via un invocation_id. Cela restaure le State tel qu'il était avant une erreur de l'agent, permettant de repartir sur une base saine sans perdre tout l'historique.

📝 State : Le bloc-notes dynamique de l'agent

Dans ADK, l'attribut state d'une session est un dictionnaire clé-valeur servant de mémoire de travail. Contrairement à l'historique complet des événements, il stocke des détails structurés nécessaires au tour de conversation actuel (ex: statut d'authentification, étape d'un formulaire).

💡 Gestion de la portée via les préfixes

ADK utilise des préfixes pour définir automatiquement la visibilité et la durée de vie des données:

Préfixe	Portée (Scope)	Persistance	Cas d'usage
Aucun	Session actuelle	Liée au service de session	Étape d'un tunnel d'achat.
user:	Identité utilisateur	Partagée entre toutes ses sessions	Préférences, nom.
app:	Application globale	Partagée entre tous les utilisateurs	Version API, code promo.
temp:	Invocation en cours	Éphémère (effacée après la réponse)	Calculs intermédiaires.

Exemple d'utilisation

# The ADK automatically replaces {user:name} with the value found in state
agent = adk.LlmAgent(
    instruction="Greet the user by saying: Hello {user:name}!"
)

# Updating state within a tool safely
@adk.tool
async def set_preference(color: str, context: adk.ToolContext):
    context.state["user:fav_color"] = color # Captured and persisted automatically
    return f"Preference saved."

🧠 MemoryService : Choisir son moteur de connaissances

Dans ADK, le MemoryService est l'interface qui gère l'archivage et la récupération des connaissances à long terme. Sa mission est double : ingérer les informations pertinentes d'une session terminée (add_session_to_memory) et permettre à l'agent de les retrouver via une recherche (search_memory).

Il existe deux implémentations principales selon vos besoins en persistance et en intelligence :

Caractéristique	InMemoryMemoryService	VertexAiMemoryBankService
Persistance	Nulle (perdue au redémarrage)	Élevée (Managée par Vertex AI)
Extraction	Stocke l'historique brut	Intelligente (extraite et consolidée par LLM)
Type de recherche	Mots-clés basiques	Sémantique avancée (Embeddings)
Usage idéal	Prototypage et tests rapides	Production et apprentissage continu

🚀 Le workflow complet

Pour bien comprendre comment ces composants interagissent, voici le cycle de vie d'une information, de sa captation à sa réutilisation:

Interaction : L'utilisateur échange avec l'agent via une Session. Chaque message et action est enregistré comme un Event, et le State gère les données de travail immédiates.
Archivage : Lorsqu'une session est jugée riche en informations, l'application appelle add_session_to_memory(session). Le système extrait les faits marquants de l'historique et les consolide dans le MemoryService.
Mémoire : Dans une session future, l'agent utilise un outil dédié (LoadMemoryTool ou PreloadMemoryTool) s'il détecte un besoin de contexte passé.
Recherche Sémantique : L'outil interroge le service de mémoire (search_memory). S'il s'agit de la Memory Bank, une recherche par similarité vectorielle est effectuée pour trouver les souvenirs les plus proches du sens de la requête.
Restitution & Réponse : Le service renvoie les souvenirs pertinents (MemoryResult). L'agent les intègre alors dans ses instructions système pour formuler une réponse personnalisée et historiquement cohérente.

🤖 Vers une IA qui apprend vraiment

En maîtrisant ce trio, Session, State et Memory, vous sortez enfin du mode "stateless" des LLM. Cette architecture, propulsée par ADK et Google Cloud, garantit que vos agents ne se contentent pas de répondre, mais s'adaptent et valorisent chaque interaction sur le long terme.

AWS Summit Paris 2026 : le grand saut dans l'ère de l'IA agentique

Benjamin Bourgeois — Thu, 02 Apr 2026 00:00:00 +0000

Le 1er avril 2026, le Palais des Congrès de Paris accueillait l’édition 2026 de l’AWS Summit. Si les années précédentes étaient marquées par l’expérimentation autour de l’IA générative, cette édition a acté un changement de paradigme : nous quittons l’ère du simple « chat » pour entrer dans celle des agents autonomes et industrialisés.

Une keynote sous le signe de la puissance et du « Why Not »

La matinée a débuté avec Amélie Clugnet, qui a rappelé l’ancrage massif d’AWS en France, fort de 1 000 salariés et d’une disponibilité exemplaire de sa région cloud. Ensuite, la keynote a donné une impulsion claire à travers le concept du « Why Not ». L’idée centrale que je retiens est la mutation profonde de notre rôle : il ne s’agit plus seulement d’assister le développeur dans ses tâches quotidiennes, mais de lui fournir les leviers pour piloter de véritables flottes d’agents. Ces derniers sont désormais capables de transformer des « insights » théoriques en actions concrètes au sein de l’infrastructure.

Le témoignage du Groupe Canal+ a parfaitement illustré cette ambition. Pour supporter son expansion internationale, le groupe a structuré une plateforme capable d’orchestrer plusieurs modèles via Amazon Bedrock. Cette architecture « agnostique » leur permet aujourd’hui d’absorber des pics de charge colossaux, allant jusqu’à 3 millions d’utilisateurs simultanés lors de grands événements sportifs, tout en personnalisant l’expérience à l’échelle mondiale.

La montée en puissance de l’écosystème agentique

En parcourant l’Innovation Corner, l’omniprésence d’AgentCore a confirmé que la gestion de la mémoire à long terme et l’auditabilité des décisions des agents sont devenues les nouvelles priorités. C’est une brique qui s’impose désormais comme un standard pour déployer des agents en production avec un haut niveau de confiance.

Parallèlement, les annonces autour de Strands Agents, le nouveau SDK open source d’AWS, simplifient nettement le développement. Ce framework s’appuie sur les capacités de raisonnement natives des modèles de dernière génération pour planifier et exécuter des tâches dynamiquement, évitant ainsi aux développeurs de s’enfermer dans des workflows manuels trop rigides.

Kiro : replacer le développeur au centre de l’architecture

Le moment fort de notre présence au Summit a été notre conférence dédiée à Kiro, que j’ai présentée avec Julien Landuré dans la Developer Community Zone. Julien raconte la session en détail dans son article.

Officiellement adopté comme l’IDE standard d’AWS, cet outil impose une structure inédite au développement « IA-native » via le Spec-Driven Development (SDD). En s’appuyant sur la syntaxe EARS, cette méthodologie garantit que le développeur ne subit plus la génération de code, mais la dirige. En incluant toutes les parties prenantes dès le design, on réduit drastiquement les coûts tout en gardant une maîtrise totale sur l’architecture.

Au-delà de la conception, Kiro outille l’agent de bout en bout pour le rendre opérationnel jusqu’au déploiement grâce aux « powers », des capacités d’action réelles sur les services externes. Mais la véritable rupture réside dans la transition du « Prompt » au « Context Engineering ».

Là où le « prompt engineering » classique s’essouffle face à la complexité des projets, Kiro apporte une réponse systémique via le « steering ». L’écosystème technique est segmenté en fichiers spécialisés (produit, structure, technique) et un « matching » intelligent ne charge que les données critiques pour la tâche en cours. L’agent ne devine plus : il intègre nativement vos standards et l’historique du projet pour une exécution focalisée et de haute précision.

Ce que nous en retirons pour la suite : l’évolution vers l’orchestrateur

L’enseignement principal de ce Summit est la transformation radicale de notre métier. Nous sortons de l’ère de l’artisanat du code pour entrer dans celle de l’orchestration. Le développeur de 2026 ne produit plus chaque ligne manuellement ; il gère des capacités, valide des trajectoires et garantit la cohérence des systèmes.

Dans ce nouveau paradigme, la barrière entre la technique pure et les besoins métiers s’efface au profit d’une compréhension globale du contexte. Il est plus crucial que jamais de bien s’équiper (soi et son IA) pour maintenir des standards de qualité élevés tout en codant à la vitesse de sa pensée. Avec des socles comme l’AWS European Sovereign Cloud et des outils comme Kiro, nous disposons enfin des moyens pour piloter cette complexité avec sérénité.

🚀 Le tips Kiro : Pour ceux qui veulent passer à la pratique, connectez-vous dès maintenant avec votre AWS Builder ID sur Kiro pour bénéficier de 500 crédits bonus et tester vos premières boucles de développement agentique.