DEV Community: Julien Landuré

GitHub Universe 2026 : pourquoi et comment adopter le harnais Copilot!

Julien Landuré — Tue, 03 Nov 2026 00:00:00 +0000

Le 28 octobre 2026, GitHub a dévoilé ses annonces de GitHub Universe 2026 , et l’équipe VS Code a sorti le même jour la version 1.144 de l’éditeur. La liste est longue : Copilot Projects dans l’app GitHub Copilot, automations dans le cloud, pull requests empilées, nouvelles protections de sécurité…

Source : GitHub Blog

Pour les développeurs qui utilisent des agents dans VS Code, le changement le plus structurant est aussi le plus discret : le harnais. Depuis l’automne 2026, les nouvelles sessions d’agent tournent par défaut sur le harnais Copilot, construit sur le Copilot SDK, à la place du harnais Local historique de VS Code.

Dans cet article, nous allons voir pourquoi adopter le harnais Copilot, ce qu’il faut adapter pour basculer, puis quatre nouveautés à tester tout de suite : Copilot Fusion, Compare Models, la génération d’images dans le chat et l’option --attach de GitHub CLI.

📌 Un harnais, c’est quoi ?

La documentation VS Code donne une définition simple : un harnais d’agent est la couche logicielle qui fait tourner une session d’agent. Il relie le modèle au contexte et aux outils, pilote la boucle de l’agent et garde l’état de la session.

Changer de modèle ne change donc pas le harnais. Nous pouvons utiliser le même modèle avec deux harnais différents et obtenir des comportements différents, parce que les outils, les permissions et les customisations disponibles ne sont pas les mêmes.

VS Code propose plusieurs harnais dans le contrôle Session Target :

Copilot : construit sur le Copilot SDK, il tourne dans l’ Agent Host , un processus séparé des fenêtres de l’éditeur ;
Local : le harnais historique de VS Code, qui tourne dans l’extension host de la fenêtre ;
Claude et Codex : les harnais des fournisseurs, eux aussi accessibles via l’Agent Host.

Le bilan publié par l’équipe VS Code résume l’histoire : l’équipe a fusionné le harnais Local de VS Code et celui de Copilot CLI pour créer le nouveau harnais Copilot, désormais le harnais par défaut des nouvelles sessions, dans l’éditeur comme dans la fenêtre Agents.

Source : VS Code Wrapped

1. 🤖 Pourquoi adopter le harnais Copilot

Le harnais Local est en fin de vie. Dans les notes de version de VS Code 1.143, l’équipe VS Code présente les réglages qui permettent de rester sur Local comme temporaires, le temps que Local soit retiré (« These controls are temporary while Local is retired. »). Les nouveautés comme la fenêtre Agents ou Compare Models ne sont d’ailleurs pas disponibles avec Local.

La recommandation de la documentation des harnais est claire : commencer par le harnais Copilot pour le code et les tâches d’agent du quotidien, et ne choisir un autre harnais que pour un besoin précis d’outils, de customisations ou d’exécution. Voici les raisons concrètes de suivre ce conseil.

Un seul runtime pour toutes les surfaces

Le harnais Copilot repose sur le même runtime que Copilot CLI et l’app GitHub Copilot. Les notes de version de VS Code 1.144 le résument en une phrase : « Write agent customizations once and use them consistently across all these experiences. »

Concrètement, une skill, un custom agent ou une configuration MCP rangés dans les dossiers natifs de Copilot (.github/, .agents/, ~/.copilot/) sont lus par VS Code comme par Copilot CLI. Les sessions Cloud ne supportent d’ailleurs que ce harnais.

Une orchestration qui survit à la fenêtre

Avec le harnais Local, fermer la fenêtre de l’éditeur arrête le travail de l’agent. Avec le harnais Copilot, l’Agent Host gère les sessions et donne accès aux harnais, aux modèles, aux fichiers et aux terminaux. Le travail continue en arrière-plan, y compris sur une machine distante via Remote SSH ou les dev tunnels.

La même session reste synchronisée entre la vue Chat et la fenêtre Agents , qui permet de piloter plusieurs agents sur plusieurs workspaces. Le harnais Local, lui, n’est pas disponible dans la fenêtre Agents. Or c’est là qu’arrivent les nouveautés comme Compare Models.

Des garde-fous appliqués

La documentation est explicite : le harnais Local n’applique pas les règles de sandbox et de permissions propres au runtime. Le harnais Copilot les applique, avec le mode Assisted permissions (disponibilité générale dans VS Code 1.144) qui évalue le risque des actions de l’agent.

À noter : un runtime partagé ne veut pas dire des outils identiques partout. La documentation précise que le harnais Copilot n’expose pas tous les outils intégrés de VS Code ni ceux fournis par les extensions. Ces derniers ne suivent pas une session reprise dans Copilot CLI.

2. ⚙️ Ce qu’il faut adapter pour basculer

Le harnais se choisit dans le contrôle Session Target , avant d’envoyer le premier prompt. Le harnais actif s’affiche en préfixe du titre du chat.

La migration des customisations est guidée : avec Copilot comme Session Target, la commande Chat: Open Customizations ouvre un onglet Migrations qui propose une conversion automatique, une conversion assistée par l’agent ou une revue manuelle. Le guide de migration détaille les cas particuliers. Voici les principaux points à adapter.

	Harnais Local	Harnais Copilot
Sous-agent	`runSubagent`	`task`
Lire un fichier	`read_file`	`view`
Lancer une commande	`run_in_terminal`	`bash`
Prompt files `*.prompt.md`	Oui	Non : à convertir en skills
MCP	`.vscode/mcp.json`, `${input:...}`	`.mcp.json`, `~/.copilot/mcp-config.json`, `${VAR}`
Hooks	Contrat Local	Contrat Copilot

Les prompt files deviennent des skills

Le harnais Copilot ne lit pas les fichiers *.prompt.md. La conversion en skills est proposée par l’onglet Migrations. Attention, elle ne conserve pas les champs agent, model ni tools du prompt file.

Les serveurs MCP changent de fichier et de syntaxe

Le harnais Copilot lit .mcp.json à la racine du workspace et ~/.copilot/mcp-config.json pour l’utilisateur, avec une clé racine mcpServers. Les secrets passent par des variables d’environnement ${VAR} au lieu des ${input:...} de VS Code.

Un serveur dont la configuration utilise un ${input:...} secret n’est pas migré automatiquement : il n’est pas transmis au harnais Copilot et ses tools disparaissent de la session. Les serveurs protégés par un token saisi via un input secret sont donc à traiter en priorité. Pour la question du filtrage des tools MCP, j’avais détaillé les options dans un article précédent 👇

https://techtown.fr/blog/gouvernance-mcp-entreprise-filtrer-tools-agents-de-code/

Les hooks changent de contrat

Les hooks du harnais Copilot suivent le contrat Copilot (version: 1, clés en camelCase). Un hook écrit pour le harnais Local doit être relu avant d’être réutilisé.

3. 🧠 Copilot Fusion prend la place d’Auto

Dans le sélecteur de modèles, Copilot Fusion remplace l’option Auto là où il est disponible. Il est en disponibilité générale depuis le 28 octobre 2026, sur tous les plans Copilot, dans VS Code, l’app GitHub Copilot, Copilot CLI et les IDE JetBrains.

Fusion combine la sélection automatique de modèle d’Auto et l’orchestration multi-modèles du projet HydraFusion. C’est un routeur et un orchestrateur : pour chaque prompt, il choisit le modèle ou la combinaison de modèles, l’effort de raisonnement et le pattern d’exécution adaptés à la tâche.

Nous ne choisissons que le niveau :

Standard pour le travail courant ;
High pour une tâche de code importante et bien délimitée, comme un bug complexe ou une modification sur plusieurs fichiers ;
Max pour les problèmes qui demandent le raisonnement le plus poussé.

Source : changelog GitHub Copilot Fusion

Fusion décide ensuite du pattern pour chaque prompt :

Single : un seul modèle traite la tâche ;
Cascade : un modèle efficace propose une solution, et un juge l’accepte ou la confie à un modèle plus puissant ;
Critique : un modèle rédige, d’autres modèles critiquent en parallèle, puis le premier révise.

Côté coût, chaque modèle utilisé est facturé à son tarif standard, avec une remise de 30 % pour les plans payants jusqu’au 30 novembre 2026. Dans VS Code, les niveaux High et Max sont réservés aux plans Pro+, Max, Business et Enterprise. Côté résultats, GitHub annonce que Fusion Max obtient 60 points sur l’Artificial Analysis Coding Agent Index, à deux points de Claude Code avec Opus 5.5 Max, pour un coût moyen par tâche environ deux fois plus faible et environ 40 % de temps en moins.

À noter : les administrateurs gardent la main. Fusion n’utilise que les modèles autorisés par les politiques de l’entreprise et de l’organisation, et un modèle peut être exclu de Fusion sans être désactivé ailleurs.

4. ⚖️ Compare Models dans la fenêtre Agents

Compare Models (en preview) envoie un même prompt à plusieurs modèles, ou à plusieurs harnais, en parallèle, puis affiche les résultats côte à côte. Il est disponible uniquement dans la fenêtre Agents, avec le paramètre sessions.chat.compareAgents.enabled, activé par défaut pour les nouvelles sessions éligibles dans VS Code 1.144.

L’idée est simple :

Dans le sélecteur de modèles, choisir Compare Models (ou ⌥⌘M sur macOS, Ctrl+Alt+M sur Windows et Linux).
Sélectionner au moins deux tentatives, en mélangeant si besoin les harnais Copilot, Claude et Codex, avec un niveau de raisonnement différent pour chacune.
Lancer le prompt : chaque tentative tourne dans sa propre session, avec son worktree.
Optionnellement, laisser un modèle Judge recommander une solution, avec un tableau du temps et des tokens consommés.
Lancer Synthesize pour repartir de la tentative recommandée en y intégrant les meilleures idées des autres.

Pratique pour se faire sa propre idée sur ses vraies tâches, en complément des benchmarks. La comparaison n’est pas disponible dans les Dev Containers.

5. 🎨 Générer des images dans le chat

Copilot peut maintenant générer et modifier des images en langage naturel, en pleine tâche de code ou dans une nouvelle demande. L’aperçu s’affiche dans le chat et l’image est enregistrée directement dans le workspace. Le modèle de raisonnement sélectionné appelle un outil dédié, basé sur GPT Image 2.5 Flare.

La fonctionnalité est en preview publique dans VS Code, l’app GitHub Copilot et Copilot CLI, pour les plans Copilot Pro, Pro+, Business et Enterprise. Quelques réglages à connaître :

la génération est facturée à part, en tokens d’image qui comptent dans les crédits IA du plan ;
chat.copilot.imageGeneration.watermark à true ajoute un filigrane « Made with AI », désactivé par défaut ;
chat.copilot.imageGeneration.model à off désactive la fonctionnalité, et les administrateurs peuvent la couper via les politiques de modèles.

6. 💻 Joindre images et vidéos avec `gh --attach`

Côté terminal, GitHub CLI accepte une option --attach depuis la version 2.99.0, mise en avant dans le récapitulatif de Universe. Elle téléverse une image ou une vidéo locale et insère le lien dans le corps d’une issue, d’une pull request ou d’un commentaire.

Elle fonctionne avec gh issue create, gh issue edit, gh issue comment, gh pr create, gh pr edit et gh pr comment. L’option est répétable, et le texte alternatif d’une image se place après un # :

gh issue create --title "Erreur à la connexion" \
  --attach "./login.png#Message d'erreur sur la page de connexion"

gh pr comment 13 --attach ./before.png --attach ./after.png

Si le corps de l’issue, de la pull request ou du commentaire référence déjà un fichier local (![alt](./login.png)) et que ce même fichier est passé avec --attach, GitHub CLI remplace le chemin local par l’URL téléversée.

Quelques limites à connaître :

formats PNG, JPEG, GIF, WebP, SVG, MP4, MOV et WebM ;
10 Mo pour les images, 10 Mo pour les vidéos sur un plan Free et 100 Mo sur un plan payant ;
accès en écriture au dépôt requis ;
GitHub Enterprise Server non supporté dans la première version.

💪 ProTip : combinée à un agent qui fait des captures d’écran, l’option permet de produire des pull requests avec un avant/après visuel, sans passer par le navigateur.

🚀 Bonus : les autres annonces à suivre

Universe 2026 ne se limite pas à VS Code. Quelques annonces à garder en tête :

Copilot Projects (preview publique) : dans l’app GitHub Copilot, un objectif et son contexte (dépôts, maquettes, fils Slack, notes de réunion) deviennent des tâches coordonnées sur un ou plusieurs dépôts ;
Computer use (preview publique sur macOS et Windows) : Copilot peut piloter des applications de bureau, après approbation ;
Copilot automations : des workflows IA déclenchés à la demande, sur un calendrier ou sur un événement, qui tournent dans le cloud ;
Pull requests empilées : découper une grosse modification en PR liées, relues une à une ;
Copilot code review Max : un nouveau niveau de revue, à côté de Lite et Balanced ;
Protection push par IA : détection des secrets non structurés, comme les mots de passe.

Côté VS Code, la version 1.144 permet aussi de lancer des automations dans le cloud depuis la fenêtre Agents (Cloud Automations, en preview). Elles tournent sur l’infrastructure GitHub, même ordinateur éteint.

Source : notes de version de VS Code 1.144

Le récapitulatif officiel et l’article de Jay Parikh donnent la vue d’ensemble.

🎯 Conclusion

Compare Models, la fenêtre Agents et les sessions Cloud s’appuient sur le harnais Copilot et l’Agent Host. Rester sur le harnais Local, c’est s’en priver et garder des agents qui s’arrêtent avec la fenêtre, sans les règles de sandbox et de permissions du runtime.

Le passage demande un peu de travail sur les customisations : noms de tools, prompt files, serveurs MCP avec secrets et hooks. Mon conseil : basculer la Session Target sur Copilot, lancer l’onglet Migrations, traiter les serveurs MCP en premier, puis tester Fusion et Compare Models sur une vraie tâche de votre backlog.

Pour revoir toute l’année côté éditeur, le bilan VS Code Wrapped : GitHub Universe 2026 retrace le chemin parcouru depuis Universe 2025 : Agent Host, harnais Copilot, fenêtre Agents, Fusion, Compare Models, canvases et génération d’images.

Filtrer les tools MCP de vos agents avec AgentGateway.dev

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

Dans un précédent article, nous avons comparé trois façons de choisir les tools MCP auxquels nos agents de code ont accès. La gateway MCP était la solution la plus fiable : la règle est appliquée côté serveur, au même endroit pour tous les agents.

Restait à voir comment la mettre en place. Bonne nouvelle : avec agentgateway, un fichier YAML et une image Docker suffisent.

Dans cet article, nous allons présenter le projet et son histoire, puis monter pas à pas une gateway qui donne accès à Context7 et filtre les tools d’un serveur MCP Atlassian.

🧩 Le use case

Nos agents de code (GitHub Copilot, Claude Code, Cursor) utilisent deux serveurs MCP (Model Context Protocol) :

Context7 , un serveur distant qui fournit de la documentation à jour sur les librairies. Il expose deux tools, sans authentification.
Atlassian , via le serveur open source mcp-atlassian, pour Jira et Confluence. Il expose 97 tools, dont une quarantaine qui modifient des données : jira_create_issue, confluence_delete_page…

Nous voulons trois choses :

accéder à Context7 en passant par la gateway ;
ne garder qu’une liste de tools Atlassian en lecture seule ;
que chaque utilisateur garde son propre token Atlassian, sans aucun secret côté serveur.

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

📌 agentgateway en bref

agentgateway est un proxy open source pensé pour le trafic des agents IA. Il couvre trois familles de trafic avec un seul binaire :

LLM Gateway : router les appels vers OpenAI, Claude, Gemini ou un modèle auto-hébergé, avec la gestion des clés d’API et le basculement automatique (failover) d’un modèle à l’autre ;
MCP et A2A : un support natif du Model Context Protocol et du protocole A2A (Agent-to-Agent), le trafic entre agents ;
APIs et services : le trafic HTTP, gRPC et TCP classique, observable par défaut, avec mTLS et OIDC intégrés.

Notre use case n’utilise que le pilier MCP, mais la même gateway peut ensuite porter le trafic LLM et API de l’équipe, avec la même configuration et les mêmes logs.

GitHub : agentgateway/agentgateway, plus de 5 600 stars en octobre 2026

Documentation : agentgateway.dev/docs

Pour notre use case, quatre fonctionnalités nous intéressent :

la fédération MCP : une route par serveur MCP, distant ou local ;
le filtrage des tools avec des règles CEL (Common Expression Language), une syntaxe d’expressions simple ;
la manipulation des en-têtes , pour décider quel token part vers quel serveur ;
l’observabilité : logs JSON, métriques Prometheus, traces OpenTelemetry et une UI web.

Le projet est écrit en Rust et publié sous licence Apache 2.0.

ℹ️ Un peu d’histoire

Le projet est jeune, mais il a déjà fait du chemin :

mars 2025 : Solo.io crée agentgateway, un proxy pensé dès le départ pour MCP et A2A ;
25 août 2025 : la Linux Foundation accueille le projet, annoncé à l’Open Source Summit Europe à Amsterdam ;
fin 2025 : la Linux Foundation lance l’Agentic AI Foundation (AAIF) avec MCP d’Anthropic, goose de Block et le standard AGENTS.md ;
4 juin 2026 : agentgateway rejoint l’AAIF et devient son quatrième projet hébergé.

Selon Solo.io, le projet comptait en juin 2026 plus de 300 contributeurs actifs venant de plus de 60 organisations. C’est un point important pour une brique d’infrastructure : la gouvernance est neutre et le projet ne dépend pas d’un seul éditeur.

À noter : nos tests ont été faits avec la version 1.5.0 (août 2026). La version 1.6.0 est sortie le 2 octobre 2026.

⚙️ 1. Lancer la gateway avec Docker Compose

Commençons par le fichier docker-compose.yaml. Il démarre deux conteneurs : le serveur mcp-atlassian et la gateway.

services:
  mcp-atlassian:
    image: ghcr.io/sooperset/mcp-atlassian:latest
    ports:
      - "8080:8080" # gateway : routes MCP
      - "4001:4001" # gateway : UI
    environment:
      TRANSPORT: streamable-http
      HOST: 127.0.0.1
      PORT: "8000"
      STATELESS: "true"
      JIRA_URL: https://votre-site.atlassian.net/
      CONFLUENCE_URL: https://votre-site.atlassian.net/wiki
      ATLASSIAN_EXTERNAL_AUTH_ENABLE: "true"
      READ_ONLY_MODE: "true"

  agentgateway:
    image: cr.agentgateway.dev/agentgateway:v1.5.0
    command: ["-f", "/config/config.yaml"]
    network_mode: "service:mcp-atlassian"
    volumes:
      - ./config:/config:ro

Quelques points méritent une explication :

network_mode: "service:mcp-atlassian" place les deux conteneurs dans le même réseau. La gateway joint mcp-atlassian sur localhost:8000, exactement comme un sidecar sur Cloud Run. La même config sert donc en local et dans le Cloud.
HOST: 127.0.0.1 : mcp-atlassian n’écoute que sur localhost. Seule la gateway peut l’appeler.
ATLASSIAN_EXTERNAL_AUTH_ENABLE: "true" indique à mcp-atlassian que chaque requête apporte son propre token. Sans ce réglage, le serveur ne trouve aucun identifiant global et n’expose aucun tool.
READ_ONLY_MODE: "true" ajoute une seconde barrière, en plus du filtrage de la gateway.

Il n’y a aucun secret dans ce fichier.

⚙️ 2. Exposer Context7 derrière la gateway

Passons au fichier config/config.yaml. Il déclare d’abord le port de la gateway et celui de l’UI :

gateways:
  default:
    port: 8080
  ui:
    port: 4001

ui:
  gateways: [ui]

Ajoutons ensuite une première route, pour Context7 :

routes:
- name: context7
  matches:
  - path:
      pathPrefix: /context7/mcp
  policies:
    mcpAuthorization:
      rules:
      - 'mcp.tool.name == "resolve-library-id"'
      - 'mcp.tool.name == "query-docs"'
  backends:
  - mcp:
      targets:
      - name: context7
        mcp:
          host: https://mcp.context7.com/mcp
        policies:
          requestHeaderModifier:
            remove: [authorization]

La route reçoit les requêtes MCP sur /context7/mcp et les relaie vers le serveur distant de Context7. Le bloc requestHeaderModifier retire l’en-tête Authorization : le token Atlassian d’un utilisateur ne doit jamais partir vers un service externe.

⚙️ 3. Filtrer les tools Atlassian

La seconde route suit le même modèle, avec une liste blanche plus longue :

- name: atlassian
  matches:
  - path:
      pathPrefix: /atlassian/mcp
  policies:
    mcpAuthorization:
      rules:
      - 'mcp.tool.name in ["jira_get_issue", "jira_search", "jira_get_project_issues", "jira_get_transitions", "jira_get_all_projects", "jira_get_agile_boards", "jira_get_board_issues", "jira_get_sprints_from_board", "jira_get_sprint_issues", "jira_get_user_profile"]'
      - 'mcp.tool.name in ["confluence_search", "confluence_get_page", "confluence_get_page_children", "confluence_get_space_page_tree", "confluence_get_comments", "confluence_get_labels"]'
  backends:
  - mcp:
      targets:
      - name: atlassian
        mcp:
          host: http://localhost:8000/mcp

Ici, pas de requestHeaderModifier : l’en-tête Authorization de l’utilisateur doit arriver intact jusqu’à mcp-atlassian.

Lançons la stack :

docker compose up -d

Voici ce que nous avons constaté :

tools/list ne renvoie que les 16 tools de la liste blanche, sur les 97 du serveur ;
un appel direct à jira_create_issue est rejeté par la gateway, même forcé à la main avec curl ;
une requête sans token reçoit une erreur 401 de mcp-atlassian ;
avec un token valide, jira_search et confluence_search renvoient bien les données de l’utilisateur.

La gateway filtre les tools sans rien savoir d’Atlassian. Elle lit simplement les messages MCP qui passent.

💪 ProTip : gardez une route par serveur MCP. agentgateway sait aussi regrouper plusieurs serveurs derrière une seule URL, mais les noms des tools reçoivent alors un préfixe (atlassian_jira_search) et il devient plus difficile de contrôler quel token part vers quel serveur.

💻 4. Brancher un agent de code

Côté poste, il n’y a plus rien à installer. Chaque utilisateur prépare son en-tête à partir de son email et de son token API Atlassian :

printf '%s:%s' 'prenom.nom@exemple.fr' 'VOTRE_TOKEN_API' | base64

Avec Claude Code, une seule commande suffit :

claude mcp add --transport http atlassian-gw http://localhost:8080/atlassian/mcp --header "Authorization: Basic <BASE64>"

Avec Cursor, dans ~/.cursor/mcp.json :

{
  "mcpServers": {
    "atlassian-gw": {
      "url": "http://localhost:8080/atlassian/mcp",
      "headers": { "Authorization": "Basic <BASE64>" }
    },
    "context7-gw": {
      "url": "http://localhost:8080/context7/mcp"
    }
  }
}

L’agent voit alors les 16 tools autorisés. Si nous lui demandons de créer un ticket Jira, il répond qu’il n’a pas de tool pour ça.

⚡️ ProTip : utilisez un token API classique d’Atlassian. Les tokens « avec scopes » ne fonctionnent pas avec l’URL du site (votre-site.atlassian.net) : ils passent obligatoirement par https://api.atlassian.com/ex/{jira|confluence}/<cloudId>. Nous avons perdu un peu de temps sur ce 401 avant de comprendre.

🎯 Conclusion

En quelques dizaines de lignes de YAML, agentgateway nous donne une gateway MCP qui :

expose Context7 et Atlassian derrière une seule URL ;
filtre les tools côté serveur, pour tous les agents à la fois ;
relaie le token de chaque utilisateur, sans secret à stocker.

Le projet est simple à démarrer et sa gouvernance est neutre depuis son arrivée à l’AAIF. Pour une équipe qui veut encadrer les serveurs MCP de ses agents de code, c’est une bonne première brique, en local avec Docker Compose puis sur Cloud Run.

Le code complet de ce test tient en deux fichiers : docker-compose.yaml et config/config.yaml.

🚀 Bonus : aller plus loin avec l’observabilité

Une gateway voit passer tous les appels de tools. C’est l’endroit idéal pour mesurer l’usage réel des serveurs MCP.

Ajoutons une politique de logs d’accès en tête de config/config.yaml :

config:
  logging:
    format: json

frontendPolicies:
  accessLog:
    filter: 'mcp.methodName == "tools/call"'
    add:
      mcp_target: 'mcp.tool.target'
      mcp_tool: 'mcp.tool.name'

Chaque appel de tool produit maintenant une ligne JSON avec le serveur et le tool utilisés :

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

Un peu de jq suffit pour compter les appels par serveur et par tool. Voici le résultat après quelques tests :

MCP TOOL APPELS ERREURS
atlassian confluence_search 3 0
atlassian jira_create_issue 3 3
atlassian jira_get_issue 3 0
context7 resolve-library-id 3 0

Les trois erreurs sur jira_create_issue sont les appels refusés par la gateway.

En local, jq suffit. En production, trois options s’offrent à nous selon les outils de l’équipe :

Les logs, sans rien installer. Sur Cloud Run, tout ce que la gateway écrit arrive automatiquement dans Cloud Logging. Le même tableau peut alors se construire avec une requête SQL dans Log Analytics, sur les champs mcp_target et mcp_tool.
Un compteur Prometheus. agentgateway publie le compteur agentgateway_mcp_requests_total (nombre de requêtes MCP par serveur et par tool) sur le port 15020. Prometheus le collecte et Grafana en fait un tableau de bord.
Des traces OpenTelemetry. Elles suivent chaque appel de bout en bout, de l’agent jusqu’au serveur MCP, avec le temps passé à chaque étape.

À noter : la colonne ERREURS ne compte que les appels bloqués par la gateway, comme jira_create_issue ici. En version 1.5.0, si l’appel passe la gateway mais échoue chez Atlassian (un token invalide, par exemple), il est compté comme réussi.

🎓 Envie de maîtriser MCP ?

Pour comprendre MCP de l’intérieur, notre formation Model Context Protocol (MCP) couvre en une journée l’architecture client-serveur, les tools, resources et prompts, la création de serveurs MCP en Python et en Java, puis l’intégration avec des agents IA et le déploiement dans le Cloud. La journée alterne théorie et ateliers pratiques.

👉 Et vous, quels serveurs MCP mettriez-vous en premier derrière une gateway ?

Certificats TLS : 200 jours en 2026, 47 jours en 2029, êtes-vous prêts ?

Julien Landuré — Thu, 22 Oct 2026 00:00:00 +0000

La durée de vie des certificats TLS baisse depuis des années, et le mouvement s’accélère. Depuis le 15 mars 2026, un certificat public ne peut plus dépasser 200 jours. En 2029, ce sera 47 jours.

J’ai récemment rencontré l’effet de bord le moins attendu de ces règles : un outil de développement qui change de bibliothèque TLS et une registry MCP interne qui devient brusquement « injoignable » sur macOS. Rien n’avait changé côté serveur.

Dans cet article, je vous propose de voir le calendrier officiel et ce qu’il implique pour la validation des domaines (et donc pour votre DNS). Je vous expliquerai ensuite pourquoi Copilot CLI a cassé une registry MCP interne, comment vérifier vos certificats, et ce qui pourrait encore bouger côté Windows et Linux.

📅 1. Le calendrier du CA/Browser Forum

📌 Le CA/Browser Forum réunit les autorités de certification (CA) et les éditeurs de navigateurs et de systèmes. Il publie les Baseline Requirements, les règles que doivent respecter tous les certificats TLS publics.

En avril 2025, le ballot SC-081v3, proposé par Apple, a été adopté sans aucun vote contre. Côté éditeurs, Apple, Google, Microsoft et Mozilla ont tous voté pour. Le ballot réduit la durée maximale des certificats en trois étapes (section 6.3.2 des Baseline Requirements) :

Certificat émis à partir du	Émis avant le	Durée maximale
	15 mars 2026	398 jours
15 mars 2026	15 mars 2027	200 jours
15 mars 2027	15 mars 2029	100 jours
15 mars 2029		47 jours

À noter : le texte compte un jour comme 86 400 secondes, et toute fraction de seconde en plus compte comme un jour entier. Les Baseline Requirements recommandent donc de ne pas émettre pour la durée maximale (397, 199, 99 ou 46 jours au lieu de 398, 200, 100 ou 47).

🌐 L’enjeu DNS : la validation des domaines

Le ballot réduit aussi la durée pendant laquelle une CA peut réutiliser une preuve de contrôle du domaine (DCV, Domain Control Validation) :

À partir du	Réutilisation maximale de la validation du domaine
Avant le 15 mars 2026	398 jours
15 mars 2026	200 jours
15 mars 2027	100 jours
15 mars 2029	10 jours

Avec 10 jours de réutilisation et des certificats de 47 jours, la preuve de contrôle du domaine devra être refaite à presque chaque renouvellement. Si vous validez vos domaines avec un enregistrement DNS (le challenge DNS-01 du protocole ACME, obligatoire pour les certificats wildcard), votre DNS doit pouvoir être modifié automatiquement, par API. Un enregistrement TXT ajouté à la main une fois par an ne tiendra plus.

Let’s Encrypt anticipe : ses certificats durent 90 jours par défaut, des certificats de 6 jours sont déjà disponibles en option, et la durée maximale passera à 45 jours en février 2028 (plan officiel).

🍏 2. Apple n’attend pas : la règle des 825 jours

Ces règles visent les certificats publics. Une PKI interne n’est pas soumise au CA/Browser Forum, mais macOS lui impose quand même ses propres limites.

Depuis macOS 10.15 et iOS 13, le système lui-même refuse les certificats serveur TLS qui ne respectent pas les exigences d’Apple : clés RSA d’au moins 2048 bits, signature SHA-2, nom DNS dans le SAN (Subject Alternative Name), serverAuth dans l’EKU (Extended Key Usage) et une validité de 825 jours maximum pour les certificats émis après le 1er juillet 2019. Pour un certificat rattaché à une racine préinstallée par Apple, la limite est de 398 jours depuis le 1er septembre 2020.

La règle des 825 jours s’applique aussi aux certificats émis par une PKI d’entreprise. Apple ne l’écrit pas noir sur blanc, mais c’est ce que j’ai constaté sur macOS 26. Un certificat interne valable 3 ans fonctionne dans Chrome, avec curl ou avec Node, et échoue dans Safari et dans toutes les apps qui utilisent le vérificateur du Mac.

🤖 3. Quand Copilot CLI change de bibliothèque TLS

C’est exactement ce que j’ai vécu avec GitHub Copilot CLI.

Le contexte : une organisation qui impose une registry MCP (Model Context Protocol) interne, avec la politique « Registry only ». Copilot CLI interroge cette registry pour vérifier que chaque serveur MCP configuré est autorisé.

Avec la version 1.0.78, tous les serveurs MCP personnalisés ont été bloqués d’un coup sur macOS :

! 3 MCP servers were blocked by policy: '<server-a>', '<server-b>', '<server-c>'

Les logs de debug montrent la vraie cause :

[ERROR] failed to verify TLS certificate: invalid peer certificate: Other(OtherError("“*.<domain>” certificate is not standards compliant: -67901"))
        log.target=rustls_platform_verifier::verification::apple
[ERROR] MCP server "<server-id>" filtered: Registry https://<registry>/ was unreachable

Le code -67901 correspond à errSecCertificateValidityPeriodTooLong dans Security.framework. Le message parle de certificat « not standards compliant », mais le problème est uniquement sa durée : 1095 jours, émis en janvier 2026 pour 3 ans.

Ce qui a changé, c’est le client. Avant la 1.0.78, la vérification de la registry passait par Node, qui vérifie les certificats avec OpenSSL et n’impose aucune durée maximale. Depuis, elle passe par le runtime Rust de Copilot CLI (reqwest + rustls-platform-verifier), qui délègue la vérification au système. Sur macOS, c’est donc Apple qui décide, avec sa règle des 825 jours. Comme la registry semble injoignable, Copilot CLI bloque par précaution tous les serveurs MCP qu’elle n’a pas pu vérifier.

Le diagnostic est piégeux, parce que tous les tests habituels passent :

Client	Vérificateur	Résultat
Copilot CLI < 1.0.78	OpenSSL (Node)	✅
Copilot CLI ≥ 1.0.78 sur macOS	`Security.framework`	❌ `-67901`
Safari	`Security.framework`	❌
Chrome, `curl`, Node	Leur propre vérificateur ou OpenSSL	✅

Et mes collègues sous Windows ? Ils ne sont pas concernés : sur Windows, rustls-platform-verifier passe par CryptoAPI, qui n’impose pas de durée maximale.

J’ai documenté le problème dans l’issue #4364. Il n’est pas isolé : l’issue #5085 montre qu’à partir de la 1.0.93, davantage de requêtes passent par le runtime natif, avec une autre régression TLS sur macOS quand Copilot CLI tourne dans une sandbox.

🔍 4. Vérifiez vos certificats, surtout internes

Pour savoir si un certificat passera sur macOS, curl ne suffit pas : il faut interroger Security.framework. J’ai donc créé un petit outil open source : jlandure/macos-tls-cert-check.

Il contient deux scripts qui affichent un verdict PASS ou FAIL, sans rien installer :

check-tls.sh sur macOS, qui vérifie le certificat avec le vérificateur d’Apple ;
check-tls.ps1 sur Windows, qui vérifie avec le vérificateur de Windows et prédit le résultat macOS à partir des règles d’Apple.

Sur macOS, une seule commande suffit :

git clone https://github.com/jlandure/macos-tls-cert-check.git
cd macos-tls-cert-check
./scripts/check-tls.sh github.com

Le script affiche aussi où se situe le certificat par rapport aux limites de durée :

Target: github.com:443
Certificate: CN=github.com
Issuer: C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV E36
Validity: 2026-09-01 -> 2026-11-29 (89 days, 38 days left)

Lifetime limits (informative):
  Apple, private root CA 825 days OK
  Apple, Apple-trusted root CA 398 days OK
  CA/B Forum, public CA at issue date 200 days OK
  CA/B Forum, public CA from 2029-03-15 47 days OVER

macOS verifier (Security.framework): PASS

Pour notre registry interne, le verdict est clair :

Validity: 2026-01-22 -> 2029-01-21 (1095 days, 822 days left)

macOS verifier (Security.framework): FAIL
  FAILED (-67901): “*.<domain>” certificate is not standards compliant
  -67901 errSecCertificateValidityPeriodTooLong: lifetime above 825 days (398 for an Apple-trusted root).

Depuis un poste Windows, la commande équivalente est :

powershell -ExecutionPolicy Bypass -File .\scripts\check-tls.ps1 -HostName internal.example.com

Les scripts renvoient 0 pour PASS, 1 pour FAIL et 2 si la connexion échoue. On peut donc les brancher en CI ou dans une sonde de supervision.

💪 ProTip : badssl.com héberge des certificats volontairement défectueux (expiré, mauvais hôte, racine inconnue…). C’est pratique pour voir comment un outil réagit avant de le pointer vers votre infrastructure.

Côté PKI interne, quelques réflexes :

faire l’inventaire des certificats serveur internes et de leur durée ;
émettre pour 825 jours maximum si des Mac doivent s’y connecter, et viser plutôt 398 jours ou moins ;
automatiser le renouvellement (ACME interne, cert-manager sur Kubernetes…) avant que les durées ne baissent encore ;
tester avec le vérificateur de chaque système, pas seulement avec curl.

🪟 5. Et Windows, Linux, les autres bibliothèques ?

En octobre 2026, Apple est la seule plateforme qui impose une durée maximale dans le système lui-même. Les autres s’appuient sur leurs programmes de certificats racines, qui obligent les CA publiques à suivre les Baseline Requirements :

Microsoft Trusted Root Program pour Windows : je n’ai trouvé aucune documentation d’un contrôle de durée côté client ;
Mozilla Root Store Policy pour la plupart des distributions Linux, dont le magasin de certificats commun repose sur la liste de Mozilla (doc Red Hat) ;
Chrome, qui refuse lui-même les certificats publics de plus de 398 jours depuis Chrome 85, mais exempte les autorités configurées localement.

Personne n’a annoncé de date pour un contrôle des 200, 100 ou 47 jours côté client. Le précédent existe pourtant : en 2020, Apple dans ses systèmes et Chrome dans son navigateur ont appliqué eux-mêmes la limite de 398 jours.

L’histoire de Copilot CLI montre un second risque, plus discret. Vos certificats peuvent devenir invalides sans qu’aucune règle ne change, simplement parce qu’un outil change de bibliothèque TLS. De plus en plus d’outils passent d’OpenSSL au vérificateur du système, par exemple avec rustls-platform-verifier en Rust. Le jour où vos outils, ou Windows et Linux, se mettront à appliquer ces limites, mieux vaut que vos certificats internes soient déjà en règle et renouvelés automatiquement.

🎯 Conclusion

Les durées des certificats publics sont fixées jusqu’en 2029 : 200 jours depuis mars 2026, 100 jours en mars 2027, 47 jours en mars 2029, avec une validation de domaine à refaire tous les 10 jours. Sans renouvellement automatique, ça ne tiendra pas, et un DNS pilotable par API devient indispensable pour les certificats wildcard.

Pour les certificats internes, la limite immédiate est celle d’Apple : 825 jours. Si vous ne devez faire qu’une chose cette semaine, lancez check-tls.sh sur vos services internes depuis un Mac.

👉 Et vous, combien de temps durent les certificats de votre PKI interne ?

📚 Pour aller plus loin

CA/Browser Forum :

Baseline Requirements, section 6.3.2 : durée maximale des certificats publics
Ballot SC-081v3 : le calendrier 2026-2029 et le vote

Apple :

Exigences pour les certificats approuvés dans iOS 13 et macOS 10.15 : la règle des 825 jours
Limites à venir des certificats approuvés : la règle des 398 jours
Apple Root Program Policy

Microsoft, Mozilla et Linux :

Chrome et Let’s Encrypt :

Le cas Copilot CLI :

Issue #4364 : registry MCP rejetée sur macOS (-67901)
Issue #5085 : régression TLS dans les sandbox macOS depuis la 1.0.93
Le diagnostic complet dans le dépôt de l’outil

🎓 Aller plus loin avec GitHub Copilot

Vous utilisez déjà GitHub Copilot au quotidien et voulez passer aux usages avancés ? En une journée, la formation Coder avec GitHub Copilot - Avancé de TechTown couvre :

les workflows complexes et l’automatisation avec GitHub Copilot ;
l’intégration dans les pipelines CI/CD ;
l’optimisation du code legacy, des performances et de la sécurité.

Google Antigravity & Gemini 4 Argon: How to Load Your Global ~/.agents Skills

Julien Landuré — Wed, 14 Oct 2026 00:00:00 +0000

Reuse your global Agent Skills in Google Antigravity with Gemini 4 Argon using a single symbolic link, and clean up your legacy Gemini configuration.

The Agent Skills specification has quickly become the standard way to package reusable instructions, scripts, and references for coding agents. Across tools listed on the Agent Skills clients page such as Claude Code, Cursor, Gemini CLI, and OpenAI Codex, the community has converged on a shared directory convention: .agents/skills/.

When you test Gemini 4 Argon inside Google Antigravity (AGY), project-level skills inside <workspace>/.agents/skills/ work out of the box. Global skills stored in ~/.agents/skills/, however, do not appear at startup.

In this article, we’ll explore how the .agents/skills/ convention works, why our first configuration attempt with skills.json failed in Antigravity, how to fix global skill discovery with a symbolic link, and how to clean up your ~/.gemini directory when migrating from Gemini CLI.

📦 1. How the Agent Skills standard organizes your skills

An Agent Skill is a directory containing a SKILL.md file (with name and description in YAML frontmatter, followed by Markdown instructions) and optional subdirectories like scripts/, references/, and assets/:

~/.agents/skills/
├── ai-seo/
│ ├── SKILL.md
│ └── references/
├── blog-post-writer/
│ ├── SKILL.md
│ └── references/
└── humanizer/
    └── SKILL.md

Instead of loading every instruction file into the prompt at once, compatible agents use progressive disclosure in three steps:

At session start, the agent reads only the name and description of each skill (around 50 to 100 tokens per skill).
When your prompt matches a skill’s description, or when you invoke it explicitly with /skill-name, the agent loads the full SKILL.md file.
The agent reads supporting files in references/ or runs helper scripts in scripts/ only when needed.

For cross-client interoperability, the Agent Skills implementation guide recommends scanning two .agents/skills/ locations:

<project>/.agents/skills/ for project-specific skills shared through Git.
~/.agents/skills/ for user-level skills shared across all projects on your machine (including skills installed with npx skills and tracked in ~/.agents/.skill-lock.json).

According to the Google Antigravity Skills documentation, Antigravity scans <workspace-root>/.agents/skills/ at the workspace level (with backward compatibility for .agent/skills/), whereas its global scope is set to ~/.gemini/config/skills/ (unlike Gemini CLI, which already supports ~/.agents/skills/ as a global alias).

❌ 2. Attempt #1: Why `~/.gemini/config/skills.json` fails

If you check Antigravity’s built-in customization documentation (agy-customizations), you will find a JSON configuration mechanism called skills.json designed to register skills stored outside default locations.

Our first try was to create ~/.gemini/config/skills.json pointing to ~/.agents/skills:

{
  "entries": [
    {
      "path": "~/.agents/skills"
    }
  ]
}

After restarting Antigravity and opening a new conversation, none of the skills from ~/.agents/skills were loaded.

The reason is a subtle rule in Antigravity’s customization loader:

“Config files are also honored on explicitly configured customization paths […] when the configured path points directly at a config file (e.g. path/to/skills.json). A configured directory keeps its regular one-level scan; a manifest inside it is not expanded.”

In practice:

Inside a project repository, <workspace>/.agents/skills.json is explicitly checked and expanded.
Inside the global ~/.gemini/config/ directory, Antigravity performs a direct one-level directory scan on ~/.gemini/config/skills/ and ~/.gemini/config/plugins/. It ignores ~/.gemini/config/skills.json.

⚡️ 3. Attempt #2: Link `~/.gemini/config/skills` to `~/.agents/skills`

Since Antigravity expects global standalone skills inside ~/.gemini/config/skills/<skill-name>/SKILL.md, the cleanest fix is a symbolic link from ~/.gemini/config/skills to ~/.agents/skills.

Before creating the symlink, check if you already have an existing ~/.gemini/config/skills.json file or a ~/.gemini/config/skills/ folder:

If you created ~/.gemini/config/skills.json during your own tests and it only points to ~/.agents/skills, you can remove it (rm -f ~/.gemini/config/skills.json).
If your ~/.gemini/config/skills.json listed other custom directories, move that skills.json into your project’s <workspace>/.agents/skills.json (where Antigravity does expand it), or symlink those individual skill folders inside ~/.agents/skills/ so everything stays in one place.
If you already have a non-empty ~/.gemini/config/skills/ directory, move its skill subfolders into ~/.agents/skills/ first, then remove the empty directory (mv ~/.gemini/config/skills/* ~/.agents/skills/ && rmdir ~/.gemini/config/skills).

Then create the symbolic link in your terminal:

# Point Antigravity's global skills folder to ~/.agents/skills
ln -s ~/.agents/skills ~/.gemini/config/skills

Verify that the symbolic link points to your .agents/skills directory:

ls -al ~/.gemini/config/skills

You will see output similar to:

lrwxr-xr-x 1 user staff 26 Oct 13 11:05 /Users/user/.gemini/config/skills -> /Users/user/.agents/skills

Reload Antigravity. Your ~/.agents/skills catalog is now injected at startup, and you can trigger any skill directly in chat with /skill-name.

💪 ProTip: Watch out for nested plugin symlinks inside ~/.agents/skills/. Antigravity scans ~/.gemini/config/skills/ only one level deep (skills/<skill-name>/SKILL.md). If ~/.agents/skills/my-plugin is a symlink to a plugin repository where the skill file is nested at my-plugin/skills/my-skill/SKILL.md, Antigravity will skip it. Point your symlink directly to the folder that immediately contains SKILL.md.

🧹 4. Bonus: Clean up `~/.gemini` when coming from Gemini CLI

Because Google Antigravity and Gemini CLI both store state under ~/.gemini, that directory often accumulates old folders over time.

First, a warning: do not delete ~/.gemini! Antigravity stores its active data there:

~/.gemini/antigravity/ holds your conversation history (conversations/, conversation_summaries.db), generated artifacts (brain/), and internal binaries.
~/.gemini/config/ holds your active Antigravity configuration (config.json), Model Context Protocol (MCP) server definitions (mcp_config.json), installed plugins/, and your new skills symlink.
Root files such as oauth_creds.json, google_accounts.json, settings.json, and GEMINI.md are still used if you run Gemini CLI in the terminal.

However, you can inspect ~/.gemini and remove obsolete migration backups and temporary folders:

ls -al ~/.gemini

Here is what you can safely clean up:

~/.gemini/antigravity-backup/ and ~/.gemini/antigravity-ide/: migration snapshots created when upgrading from earlier builds. Once you have confirmed your conversations and settings work in Antigravity, you can delete both folders.
~/.gemini/tmp/: leftover temporary session directories.
~/.gemini/skills/: an older root-level skills folder sometimes populated by Gemini CLI extensions (for example, GCP Data Cloud skills listed in .datacloud_skills_manifest). Antigravity does not scan ~/.gemini/skills/. If you have custom skills stored there, move them into ~/.agents/skills/ first, then remove the obsolete folder.

# Remove obsolete migration backups and temporary directories
rm -rf ~/.gemini/antigravity-backup \
       ~/.gemini/antigravity-ide \
       ~/.gemini/tmp

Note: Before removing ~/.gemini/skills, run ls -al ~/.gemini/skills to make sure you do not lose any custom skill you created for Gemini CLI.

🎯 Conclusion

Making your ~/.agents/skills setup work with Google Antigravity and Gemini 4 Argon takes a single symbolic link once you know how its global loader operates:

Keep your shared skills in ~/.agents/skills/ so they work across all Agent Skills compatible clients and CLI tools.
Skip ~/.gemini/config/skills.json, which is not expanded in the global configuration directory.
Link ~/.gemini/config/skills to ~/.agents/skills with ln -s ~/.agents/skills ~/.gemini/config/skills and reload Antigravity.
Keep ~/.gemini/antigravity/ and ~/.gemini/config/, and clean up legacy migration folders inside ~/.gemini/.

👉 Give it a try in your terminal and type / in your next Antigravity chat session to see all your global skills in action!

🎓 Go further with Antigravity

Want to master autonomous coding agents in your daily workflow? In one day, the Code with Antigravity training by TechTown covers:

discovering Antigravity and the agentic paradigm;
delegating development tasks to autonomous agents;
validating agent work via Artifacts;
customizing behavior with Rules, Skills, and MCP servers.

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. »

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

Your Face on a World Cup Sticker: Our Nano Banana Story

Julien Landuré — Tue, 28 Jul 2026 11:09:48 +0000

There is something timeless about opening a pack of football stickers. You never know which player, celebration, or rare edition you will find next.

For the 2026 World Cup, we wanted to recreate that feeling with a personal twist: what if the player on the sticker was you, your friends, or your family? That simple idea became Sticker Studio, a small experiment powered by Google's Nano Banana image model.

Take a photo, choose a national team, add your name, and the application transforms your face into a playful cartoon football sticker. In this article, we'll explore the idea, the prompt system behind every scenario, the reference images that fixed our 2026 jerseys, and why we upgraded from Nano Banana 1 to Nano Banana 2.

⚽ 1. The idea: putting our own faces on the stickers

The starting point was not a technical challenge. It was fun.

We wanted the nostalgia of football sticker albums without simply reproducing a traditional player portrait. Each result had to feel personal:

the face should remain recognizable.
the rendering should look like a playful children's illustration, not a photorealistic edit.
the person should wear their selected national team's kit.
every sticker should tell a small story.
rare borders and special effects should bring back the excitement of opening a pack.

The experience is deliberately simple. You provide a photo and a name, choose your team, and let the application create the surprise.

Behind that simple flow, the application runs an Astro frontend on Firebase Hosting and an API on Cloud Run. The browser sends the photo and the user's choices to the backend. The backend selects the scenario, builds the complete prompt, attaches the relevant references, and calls the Gemini image-generation API.

The AI is asked to preserve the real identity cues visible in the photo — face shape, skin tone, hairstyle, facial hair, eyebrows, expression, and accessories such as glasses. At the same time, it must turn that identity into a simplified, expressive cartoon.

This balance matters. Too realistic, and the result loses its friendly illustrated character. Too generic, and the person no longer recognizes themselves. The fun happens in between.

✍️ 2. One prompt engine, dozens of scenarios

A prompt like “turn this person into a football sticker” can produce an image. It does not produce a consistent collection.

To make stickers generated for different people feel as if they belong to the same album, we built every prompt from the same six-part structure:

Subject and identity — who the person is and which visible traits must be preserved.
Kit — the selected national team and its official football jersey.
Action — the humorous pose or celebration.
Environment — the stadium, pitch, city, or imaginary setting around the player.
Style and card layout — the shared visual rules, border, typography, and rarity effects.
Output constraints — a centered, vertical, full-bleed composition suitable for a sticker.

In the backend, those layers are assembled in TypeScript. Here is a shortened version of the production function:

function buildStickerPrompt(opts: PromptOptions): string {
  const name = (opts.userName || "PLAYER").trim().toUpperCase();
  const border = opts.border ?? opts.scenario.border;
  const styleBible = opts.styleBible?.trim() || DEFAULT_STYLE_BIBLE;

  return [
    "Using the attached real photo as the identity reference...",
    `The character wears the official kit of ${opts.teamName}.`,
    ...(opts.referenceInstruction?.trim()
      ? [opts.referenceInstruction.trim()]
      : []),
    `Scenario: the character is ${opts.scenario.action}.`,
    `Presented inside a trading-card layout with ${borderPhrase(border)}.`,
    `At the bottom, render the name '${name}' on one readable line.`,
    styleBible,
    "Center the subject. Use a vertical, full-bleed composition.",
  ].join(" ");
}

The function keeps the permanent art direction in one place, then injects only the values that make a sticker unique. It also makes optional instructions explicit: a jersey reference, trophy, ball, or rare effect is included only when the selected slot needs it.

The scenarios provide variety. One person can perform a bicycle kick in a packed stadium. Another can ride a rocket-powered football through space, take a victory selfie, attempt a Panenka, meditate on the pitch, or lift the trophy under golden confetti.

Here is a shortened example based on the real prompt structure:

Using the attached real photo as the identity reference, transform this exact person into a humorous parodic cartoon caricature. Match their real face closely: face shape, skin tone, hairstyle, facial hair, eyebrows, and expression.

The character is a professional soccer player wearing the official kit of the France national football team.

Scenario: the character is performing a spectacular overhead bicycle
kick in mid-air, with the ball blurring off the foot and a packed
stadium behind.

Presented inside a rectangular trading-card layout with a vibrant blue parallel border. At the top, arched text reads 'WORLD CUP 2026'. At the bottom, the name 'JULIEN' is fully readable.

Art style: die-cut sticker design, bold clean white outer outline,
2D vector illustration, flat colors, simple cel shading, thick black
ink outlines, high contrast, and playful humorous cartoon caricature.

Center the subject. Use a vertical, full-bleed composition.

The shared visual instructions are our Style Bible. They keep the thick outlines, flat colors, card frame, typography, and composition stable across all generations.

We also randomize collectible details. Common stickers appear more frequently, while gold, silver, black, and holographic borders are less common. Some generations receive a World Cup trophy or official ball as a secondary prop. Around one sticker in twenty gets a golden LEGENDAIRE badge.

The result is more than a photo filter. The same input can become a genuinely different collectible each time.

💪 ProTip: separate stable visual rules from variable scenario instructions. It makes your prompt system easier to tune and prevents a change to one celebration from altering the visual identity of the whole collection.

👕 3. When the AI remembered the wrong jerseys

The first stickers looked promising, but one detail immediately broke the illusion: the kits were wrong. For example, this result clearly uses an older France jersey.

Nano Banana often generated older designs, including 2024-era jerseys. That is understandable — a text prompt can describe “the official 2026 France home kit,” but the model still needs reliable visual information about a new design.

We solved this with multimodal reference images.

For France, England, Spain, and Argentina, the backend now attaches a packshot of the official 2026 home jersey to the generation request. The prompt explicitly tells Nano Banana to reproduce its colors, pattern, collar, marks, and crest placement in the cartoon style.

It also draws a strict boundary:

This image is ONLY a clothing reference. Ignore any person, mannequin,
face, body, pose, or background shown in it, and use it solely for the
jersey design.

We applied the same technique to the official 2026 match ball. Whenever a scenario includes a football, the backend sends the ball image and asks the model to reproduce its base color, panel shapes, colored zones, and line patterns.

The complete request can therefore contain:

the user's portrait for identity;
a 2026 jersey packshot for clothing;
the official match-ball image for the ball design;
the assembled text prompt for the scene and visual rules.

The actual Gemini request follows that order:

const parts: Array<Record<string, unknown>> = [
  { inlineData: portrait },
  ...(jersey ? [{ inlineData: jersey }] : []),
  ...(ball ? [{ inlineData: ball }] : []),
  { text: prompt },
];

const response = await ai.models.generateContent({
  model: DEFAULT_MODEL,
  contents: [{ role: "user", parts }],
  config: {
    imageConfig: { aspectRatio: "3:4" },
  },
});

The ordering is intentional: the portrait remains the primary identity reference, followed by controlled visual assets and finally the instructions that explain how to use them. All of this happens on the backend. The browser sends the photo and business choices, but it never receives the Gemini API key or controls the raw production prompt.

There was one important gotcha. A jersey reference containing a recognizable face or head could make the image request fail with finishReason=IMAGE_OTHER and no generated image.

⚡️ ProTip: prepare product references as clean packshots. Crop jersey images to the torso, remove faces and heads, keep the background simple, and use a reasonably sized compressed image. Reference quality directly affects both reliability and adherence.

🍌 4. Moving from Nano Banana 1 to Nano Banana 2

Our first production version used Nano Banana 1 through gemini-2.5-flash-image.

It proved that the concept worked. It could transform a portrait, create the cartoon style, and follow imaginative football scenarios. But as our prompts gained more constraints, we needed stronger adherence: preserve the person's identity, copy a new jersey, use the correct ball, render the name, respect the card frame, and still create a dynamic scene.

We upgraded the production model to Nano Banana 2, exposed through gemini-3.1-flash-image.

The improvement was not about adding more adjectives to the prompt. Nano Banana 2 followed the combined identity, reference-image, text, and layout instructions more reliably. That made it a better fit for a product in which small details — the correct collar, visible glasses, or an uncropped name — determine whether the sticker feels right.

We compared both versions with the same portraits, scenarios, and prompts before switching. Keeping the model name configurable also means we can repeat those A/B tests as the Gemini image family evolves.

The generation still uses a 1K output. For a fast, playful web experience, this gives us a practical balance between visual quality, latency, and cost.

You can learn more about image generation in the official Gemini API documentation.

🚀 5. From a side project to real API limits

The first audience was exactly who we built it for: friends and family.

Then people started generating several versions, trying another team, looking for a rarer border, and sharing the funniest results. That is great product feedback — and a fast way to discover API quotas.

At Gemini API Tier 1, our daily request limits became a real constraint. The API key is only the credential; the effective quota comes from the associated Gemini API project and usage tier. Once the studio became active, generation capacity mattered as much as prompt quality.

A big thank you to Guillaume Vernade, who helped us move to Tier 3 and give the experiment enough room for more people to play.

This was a useful reminder: when an AI demo becomes shareable, usage can grow differently from a traditional application. One visit may trigger several expensive generation calls because exploration is part of the experience. Quotas, concurrency, retries, and graceful error messages belong in the product design from the beginning.

Thanks to a spending cap, we can also control how much we spend on new generations. Each sticker costs approximately $0.20 to generate, so the cap protects the experiment from an unexpectedly high bill.

🎯 Conclusion: now create your World Cup sticker

Sticker Studio started with one simple question: what if our friends and family were the players inside the pack?

Building it taught us three practical lessons:

structured prompts turn isolated images into a coherent collection;
current visual references are essential when recent jerseys and equipment must be accurate;
a stronger model and enough API capacity matter once people start experimenting.

But the main result is much simpler: it is fun.

Friends and family have already generated 365 stickers. With the World Cup final finished, now is the perfect time to create yours, try another team, compare rare editions, and share the result.

👉 Create your own World Cup sticker with Sticker Studio

Which team, scenario, and rarity will you get?

IMPORTANT NOTE: Sticker Studio is a playful, unofficial fan project and is not affiliated with Panini or FIFA.

How to celebrate an achievement as an open source developer?

Julien Landuré — Tue, 30 Jun 2020 14:40:05 +0000

✏️ As an open source developer, I've maintained on GitHub a docker image since July 2017: an "Alpine Chrome" and now the image has been pulled more than 🎉 1 000 000 times 🎉 on the Docker Hub.

I wrote about it recently on Dev.to 👇

Crafting the perfect container to play with a Headless Chrome

Julien Landuré for Zenika ・ May 26 '20

#opensource #docker #testing #javascript

🎯 What can I do to celebrate this achievement?

🤔 I do not know what kind of celebration I could do! It's a big achievement from my point of view.
🚀 I've started with a tweet here

// Detect dark theme var iframe = document.getElementById('tweet-1277969952415215617-374'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1277969952415215617&theme=dark" }

😊 Disclaimer: I am not a designer and I've spent too much time designing the arrows to highlight the docker pulls: 1M information. Please do not judge it... and I've successfully added a :rocket: emoji on the screenshot.

🎉 What else?

💚 Do you have any kind of ideas or stories to share about celebrating your open source achievements?

Create a GIF?
Invite my friends to celebrate it in a restaurant?
[your turn]

⏱ 3 minutes to deploy your static Nuxt.js app on AppEngine

Julien Landuré — Tue, 09 Jun 2020 12:53:17 +0000

I’ve been deploying applications on serverless solutions since 2010. Recently, I discovered Nuxt.js and I wanted to create this post on how to quickly set up a static Nuxt.js app on AppEngine, the Google Cloud PaaS.

📝 Getting started with Nuxt.js

Nuxt.js is described as

The Intuitive Vue Framework
Build your next Vue.js application with confidence using NuxtJS.
An open source framework making web development simple and powerful.

It's very powerful! You can use it to create various architectures: SSR, SPA or Static renderings.
For this demo, we will be focused on the static feature using the nuxt generate command.

⚗ Create the project

For the demo, we will use a fresh new project. To do this, execute the npx create-nuxt-app command to create a simple Nuxt.js application.

$ node -v
v12.16.3

$ npx create-nuxt-app

create-nuxt-app v2.15.0
✨  Generating Nuxt.js project in .
? Project name nuxt-static-deploy-appengine
? Project description My glorious Nuxt.js project
? Author name Julien Landuré
? Choose programming language TypeScript
? Choose the package manager Npm
? Choose UI framework None
? Choose custom server framework None (Recommended)
? Choose the runtime for TypeScript Default
? Choose Nuxt.js modules (Press <space> to select, <a> to toggle all, <i> to inv
ert selection)
? Choose linting tools Prettier
? Choose test framework None
? Choose rendering mode Universal (SSR)
? Choose development tools (Press <space> to select, <a> to toggle all, <i> to invert selection)
...
🎉  Successfully created project nuxt-static-deploy-appengine

✅ Test locally

As described in the command line, run the npm run start script to get your app running on http://localhost:3000/.

Let's edit the index.vue and write this html:

<h2 class="subtitle">Hello Nuxt on AppEngine 🎉</h2>

And it works! Very easy to see our modification instantly.

🏗 Build it

To build the app statically, run the npm run generate command:

$ npm run generate

> nuxt-static-deploy-appengine@1.0.0 generate .../nuxt-static-deploy-appengine
> nuxt generate

ℹ Production build                                                    10:52:36
✔ Builder initialized                                                 10:52:37
✔ Nuxt files generated                                                10:52:37
ℹ Starting type checking service...                   nuxt:typescript 10:52:39

✔ Client
  Compiled successfully in 6.95s

✔ Server
  Compiled successfully in 1.13s


Hash: c5e482cb9772cddb1178
Version: webpack 4.43.0
Time: 6951ms
Built at: 05/27/2020 10:52:46 AM
                         Asset       Size  Chunks                         Chunk Names
../server/client.manifest.json    6.6 KiB          [emitted]              
       98f4a70ff71f0382866c.js   2.31 KiB       3  [emitted] [immutable]  runtime
       9fc3f5e914943c5b3a9b.js   2.97 KiB       2  [emitted] [immutable]  pages/index
                      LICENSES  389 bytes          [emitted]              
       a51444c83f14a6afaeb5.js    153 KiB       1  [emitted] [immutable]  commons.app
       d267ba93006b46dadaa8.js   49.2 KiB       0  [emitted] [immutable]  app
 + 2 hidden assets
Entrypoint app = 98f4a70ff71f0382866c.js a51444c83f14a6afaeb5.js d267ba93006b46dadaa8.js

Hash: fbd0c6af7579246a49e7
Version: webpack 4.43.0
Time: 1127ms
Built at: 05/27/2020 10:52:47 AM
                  Asset       Size  Chunks                         Chunk Names
818a9680ee5eeafdfb4b.js   3.05 KiB       1  [emitted] [immutable]  pages/index
              server.js   26.7 KiB       0  [emitted]              app
   server.manifest.json  145 bytes          [emitted]              
Entrypoint app = server.js
ℹ Generating pages                                                    
✔ Generated /

✨ Congratulations, we built our first Nuxt.js application!

ProTips: We can check the files in the dist folder or run it with npx http-server dist.

☁️ Deploy it on AppEngine

Then, to share the project with the rest of the world, we can deploy it on AppEngine. Appengine comes with a lot of features and quotas.

It is free for a basic usage thanks to its quotas BUT we have to enable billing to enjoy it. As a new customer, we get $300 to spend on Google Cloud Platform products during your free trial.

🛒 Create a project

Go to console.cloud.google.com and create a new Google Cloud Platform project.
Please save the [PROJECT_ID] of the project: you have to replace the nuxt-static-deploy with your [PROJECT_ID] for the rest of the post.

ProTips: we can retrieve the [PROJECT_ID] in the url of the web console like https://console.cloud.google.com/appengine/start?project=nuxt-static-deploy where nuxt-static-deploy is my [PROJECT_ID].

ProTips: To create a project to host your app, we can also use the gcloud projects create command. we need to enter a [PROJECT_ID], nuxt-static-deploy for example.

# Create a project 
$ gcloud projects create nuxt-static-deploy 
Create in progress for [https://cloudresourcemanager.googleapis.com/v1/projects/nuxt-static-deploy].
Waiting for [operations/cp.4929250122387435991] to finish...done.              
Enabling service [cloudapis.googleapis.com] on project [nuxt-static-deploy]...
Operation "operations/acf.803672e3-74b0-43e1-8a6b-3d37a4a0975b" finished successfully.

# List the billing accounts
$ gcloud beta billing accounts list
ACCOUNT_ID            NAME                                          OPEN
00ADEE-870384-XXXXXX  my_account                                    True

# Link the billing account to my project
$ gcloud beta billing projects link nuxt-static-deploy --billing-account=00ADEE-870384-XXXXXX
billingAccountName: billingAccounts/00ADEE-870384-XXXXXX
billingEnabled: true
name: projects/nuxt-static-deploy/billingInfo
projectId: nuxt-static-deploy

# Enable Cloud Build API
$ gcloud --project nuxt-static-deploy services enable cloudbuild.googleapis.com

✏️ Write the descriptor `app.yaml`

AppEngine supports various programming languages: python, go, java, php, nodejs etc.
To deploy static files, the best practice is to use the python37 runtime.

Let's create a file in .appengine/app.yaml

runtime: python37

handlers:
- url: /
  static_files: index.html
  upload: index.html
  secure: always
- url: /(.*)
  static_files: \1
  upload: (.*)
  secure: always

For more information on the descriptor file, please read this doc.

Don't forget to copy the file in our dist folder using this command cp .appengine/app.yaml dist/.

ProTips: We can add it to the build script in your package.json file.

🚀 Deploy your app

If this is the first you are using the Google Cloud Platform, you have to install the gcloud command line utility following the official page or using Homebrew.

Deploy our app using the gcloud app deploy command:

$ gcloud app deploy --project nuxt-static-deploy dist 

You are creating an app for project nuxt-static-deploy.
WARNING: Creating an App Engine application for a project is irreversible and the region
cannot be changed. More information about regions is at
<https://cloud.google.com/appengine/docs/locations>.

Please choose the region where you want your App Engine application 
located:

 [1] asia-east2    (supports standard and flexible)
 [2] asia-northeast1 (supports standard and flexible)
 [3] asia-northeast2 (supports standard and flexible)
 [4] asia-northeast3 (supports standard and flexible)
 [5] asia-south1   (supports standard and flexible)
 [6] australia-southeast1 (supports standard and flexible)
 [7] europe-west   (supports standard and flexible)
 [8] europe-west2  (supports standard and flexible)
 [9] europe-west3  (supports standard and flexible)
 [10] europe-west6  (supports standard and flexible)
 [11] northamerica-northeast1 (supports standard and flexible)
 [12] southamerica-east1 (supports standard and flexible)
 [13] us-central    (supports standard and flexible)
 [14] us-east1      (supports standard and flexible)
 [15] us-east4      (supports standard and flexible)
 [16] us-west2      (supports standard and flexible)
 [17] us-west3      (supports standard and flexible)
 [18] us-west4      (supports standard and flexible)
 [19] cancel
Please enter your numeric choice:  7

Creating App Engine application in project nuxt-static-deploy and region [
europe-west]....done.                                                          
Services to deploy:

descriptor:      [.../nuxt-static-deploy-appengine/dist/app.yaml]
source:          [.../nuxt-static-deploy-appengine/dist]
target project:  [nuxt-static-deploy]
target service:  [default]
target version:  [20200602t094056]
target url:      [https://20200602t094056-dot-nuxt-static-deploy.ew.r.appspot.com]


     (add --promote if you also want to make this service available from
     [https://nuxt-static-deploy.ew.r.appspot.com])

Do you want to continue (Y/n)?   

Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 12 files to Google Cloud Storage               ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...done.                                             
Deployed service [default] to [https://20200602t094056-dot-nuxt-static-deploy.ew.r.appspot.com]

You can stream logs from the command line by running:
  $ gcloud app logs tail -s default

To view your application in the web browser run:
  $ gcloud app browse

🎉 Enjoy

Go here at https://nuxt-static-deploy.appspot.com/ to see our first Nuxt.js app deployed with AppEngine.

🔍 Conclusion

Nuxt.js is a cool technology to create Vue.js app and is trending with the release of @nuxt/content

// Detect dark theme var iframe = document.getElementById('tweet-1263795755954909184-839'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1263795755954909184&theme=dark" }

AppEngine comes with a lot of features:

🔁 Multiple versions available to do A/B testing or Traffic Splitting (each version has a different timestamp on the Versions Page on Appengine)
🔐 Custom Domain Mapping & auto-renew, free, managed SSL certificates
💸 Free quota (1 GB bandwidth)
⭐️ No instance used with Python37 runtime and our configuration because we have only static content
🌐 Static content available through Google CDN and its Edge Network
⚡️ Managed network: Surprise 🎉 our project uses the http3 procotol h3-Q050.

Feel free to contact me on Twitter if you have questions!

NB: You can find another guide on Nuxt.js with AppEngine here in the official documentation.

Crafting the perfect container to play with a Headless Chrome

Julien Landuré — Tue, 26 May 2020 06:19:17 +0000

Since July 30th 2017, I have been contributing to a side project: the idea from the beginning was the ability to use Chrome to make some tests in headless mode and avoid a long queue of CI builds using a tiny Docker image.

🤔 Why use a Headless Chrome

In the world of webdev, the ability to run quickly end-to-end tests are important. Popular technologies like Puppeteer enable developers to make fun things like testing, automating forms, crawling, generating screenshots, capturing timeline... And there is a secret: some of these features are directly available on Chrome! 🙌

For more information on why headless mode is a cool feature, please read a good example on what you can achieve here:

Create PDFs with Node.js and Puppeteer

David Neal ・ Feb 6 '20

#node

💡 Crafting the perfect container

With 28 contributors, I have been working on this project to create the perfect image to run Chromium in Headless mode:

📦 Tiniest Headless Chrome (393 MB)
🐳 Easy to use, ephemeral and reproducible Headless Chrome with Docker
📝 Doc-friendly with examples for printing the DOM, generating an image with a mobile ratio or generating a PDF.
👷‍♂️ Autobuild with the Docker Hub to sync the project and ship the images with confidence
📌 Up-to-date with Chromium 81 (81.0.4044.138) and tags available to test different versions of Chromium
🔐 Secure with the best way to use Chrome and Docker - See "3 ways to securely use Chrome Headless" section
🌐 Ready for internationalisation use: support for asian characters - See "screenshot-asia.js" file
💄 Ready for design use: support for WebGL - See "How to use with WebGL" section
📄 Open Source with an Apache2 licence
👥 Community-built with 28 contributors - See "✨ Contributors" section
💚 Dev-friendly with examples using NodeJS, Puppeteer, docker-compose and also a test with a X11 display - See "Run examples" section

💚 Open Source & Fun

Some open source & fun projects have been set up and used for this open source side project. I want to share it with you: it adds value and confidence to maintain a GitHub repository. 👌

Updates to follow the recommended community standards from the GitHub community profile
Gitmoji for commit messages where I have contributed in the past 😊
All Contributors to thanks everyone who contributes to the project
Inspiration from readme-md-generator made by my friend Franck Abgrall
Inspiration from this cheatsheet on "How to promote your open-source project?"
Renovate for dependency updates
Many reads on dev.to to know what web developers are doing with Chrome and Puppeteer

🚀 Reaching a point

Here is the most interesting insight for a tool: to be used and useful! In almost two weeks, this image will be pulled on the Docker Hub...

🎉 a million times! 🎉

there is currently ~922k downloads and it grows ~6k by day
On GitHub, the repository gets ~3000 views, ~1000 unique visitors every two weeks and ~464 stars.

After 3 years maintaining it, I cannot thank everyone using this container. This is the first time a side project has become so popular.

🗓 The Future

✨ Here is some features in the roadmap:

with-playwright version with Playwright to reuse the installed headless Chromium (PR in draft)
with-deno version with Deno to create a useful and fun things to do with deno
with-lighthouse version with Lighthouse to be able to monitor your website performance in CI builds
Create a dedicated homepage and documentation website: the README.md begins to be complicated to navigate and update
Create a gallery with the name of the project or product using this container

📣 Please test this container or play with it!
💻 If you are interested to help me maintain this image, we are welcome! There is some "Good first issue" labelled issue on the repository.

Disclaimer: these terms in this post are synonyms: "Chrome" vs "Chromium" and "image" vs "container".

State of Cloud Communities in France

Julien Landuré — Tue, 14 Apr 2020 06:52:54 +0000

Karen Tamrazyan wrote a good article that analyzes local communities of 3 major public cloud providers AWS, Azure and Google Cloud in Germany, Austria and Switzerland (German-speaking countries) here:
https://www.tamrazyan.com/state-of-cloud-communities-in-german-speaking-countries/

His article made me think about France. He helped me to create a similar sheet to superficially compare regional communities behind the three major public cloud providers: Amazon Web Services (aka AWS), Microsoft Azure and Google Cloud.

Comparison

The top right quadrant from the latest Gartner cloud market analysis clearly indicates three global cloud leaders: Amazon Web Services, Microsoft Azure, Google Cloud.

How are we going to compare the communities with each other? As Karen did in his article, we will compare them by the amount of registered members or the group size in other words. It is obvious that the group size is just one metric of many, like e.g. the activity rate (how often do events take place), the average number of participants, the date of the last event and so on… The members count should serve as a simplified way of measurement of a group success or importance.

The internet is big. What kind of groups are we going to count? Indeed, there are cloud communities as Facebook groups, on different messenger networks like e.g. Telegram, independently hosted forums and so on. In this work we will count only the communities, which are hosted on the Meetup.com platform. Meetup is at the moment a de facto most popular community platform in those 3 countries.

We will only consider active groups. It means that a group should have at least 1 registered past or upcoming event. In the locations where multiple communities dedicated to the same cloud technology are present, only the biggest one will be considered because of the very high probability of members overlap between those groups.

The article gives only a snapshot of the situation as of April 12, 2020. The author doesn’t intend to update it as the situation changes. It’s a photo, not a video.

Cloud communities in France

France has a population of over 67 million people. It is one of the most important technological hubs of Europe (competing with Germany and England). Plenty of universities, industrial and service companies belong to the landscape of most of the cities in this country. Even small places can often have lively user groups here like in Brest, Tours or Cannes.

Analysis of Cloud Impact

As we can clearly see from the table, AWS has far away the biggest communities in France : it demonstrates a tendency to go on this Cloud Provider. This popularity is clearly brought from the location of one datacenter in Paris, France at the end of 2017.

Azure have broad community networks that cover the top 5 most populated cities. Azure is never the biggest community in the city.

Google Cloud groups (aka “GDG Cloud” chapters) have the weakest cloud community network in France among the 3 contenders. However, one should not forget the much wider network of general Google Developer Groups (abbreviated “GDG”), which also on occasions run Google Cloud themed meetups.

We can observe that Paris, Lyon and Nantes are the top 3 cities where the aws, azure and google cloud communities can enjoy events and meet together.

Lyon is quite particular : it’s the only city where Google Cloud has more members than the others Cloud communities.

This article highlights that cloud communities don’t match the top “La French Tech” cities. However, many cloud providers provide Cloud credits for Startups like this GCP initiative: check this page to redeem it.

There are some large cities in the country like Montpellier, Bordeaux or Lille and a couple more, where none of Azure or Google Cloud have community footprints. These are opportunities for the future to grow.

What about GDGs?

GDGs, Google Developer Groups, are too general to be studied in this article but GDGs bring together tons of passionate developers in France : 4134 members for GDG Paris, 2360 for GDG Nantes, 2213 for GDG Lille and 2133 for GDG Toulouse.

These numbers are boosted by the organization of a DevFest each year, a day or 2-days conference dedicated to share about the technology and its impact. And GDGs run some Cloud events sometimes, please check out the listing of GDGs here.

Disclaimer

Author of this article runs voluntarily the Google Cloud developer group in Nantes (France) and also the GDG Cloud Nantes.

He’s also a GDE Cloud, a community reward from Google Cloud. His opinions were intended to be honest and unbiased. Apart from this research, the following official sources were used: AWS, Azure & Google Cloud.

Thanks to Karen Tamrazyan & Charles-Henri Guérin for the review of the article.

DEV Community: Julien Landuré

GitHub Universe 2026 : pourquoi et comment adopter le harnais Copilot!

📌 Un harnais, c’est quoi ?

1. 🤖 Pourquoi adopter le harnais Copilot

Un seul runtime pour toutes les surfaces

Une orchestration qui survit à la fenêtre

Des garde-fous appliqués

2. ⚙️ Ce qu’il faut adapter pour basculer

Les prompt files deviennent des skills

Les serveurs MCP changent de fichier et de syntaxe

Les hooks changent de contrat

3. 🧠 Copilot Fusion prend la place d’Auto

4. ⚖️ Compare Models dans la fenêtre Agents

5. 🎨 Générer des images dans le chat

6. 💻 Joindre images et vidéos avec gh --attach

🚀 Bonus : les autres annonces à suivre

🎯 Conclusion

Filtrer les tools MCP de vos agents avec AgentGateway.dev

🧩 Le use case

📌 agentgateway en bref

ℹ️ Un peu d’histoire

⚙️ 1. Lancer la gateway avec Docker Compose

⚙️ 2. Exposer Context7 derrière la gateway

⚙️ 3. Filtrer les tools Atlassian

💻 4. Brancher un agent de code

🎯 Conclusion

🚀 Bonus : aller plus loin avec l’observabilité

🎓 Envie de maîtriser MCP ?

Certificats TLS : 200 jours en 2026, 47 jours en 2029, êtes-vous prêts ?

📅 1. Le calendrier du CA/Browser Forum

🌐 L’enjeu DNS : la validation des domaines

🍏 2. Apple n’attend pas : la règle des 825 jours

🤖 3. Quand Copilot CLI change de bibliothèque TLS

🔍 4. Vérifiez vos certificats, surtout internes

🪟 5. Et Windows, Linux, les autres bibliothèques ?

🎯 Conclusion

📚 Pour aller plus loin

🎓 Aller plus loin avec GitHub Copilot

Google Antigravity & Gemini 4 Argon: How to Load Your Global ~/.agents Skills

📦 1. How the Agent Skills standard organizes your skills

❌ 2. Attempt #1: Why ~/.gemini/config/skills.json fails

⚡️ 3. Attempt #2: Link ~/.gemini/config/skills to ~/.agents/skills

🧹 4. Bonus: Clean up ~/.gemini when coming from Gemini CLI

🎯 Conclusion

🎓 Go further with Antigravity

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

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

💬 Le prompt

⚙️ Sous le capot : comment Claude a travaillé

1. Rassembler la matière

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

3. Construire un storyboard calé sur le rythme

4. Les techniques d’un motion designer

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

6. Le rendu : Chrome headless et ffmpeg

7. Se relire avant de livrer

🔁 Une correction, trois secondes re-rendues

📣 Ce que ça change pour le marketing

🎯 Conclusion

🎓 Aller plus loin avec Claude Code

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

📌 Les trois besoins de gouvernance

Rappel : registry et managed settings pour le besoin A

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

Pourquoi cette approche est fragile

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

Les limites de la gateway

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

⚖️ Comparatif des trois solutions

🎯 Conclusion : il manque une brique dans la spec MCP

🎓 Aller plus loin avec MCP

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

A packed Developer Community Zone

Don’t code alone, steer your agents

Spec-Driven Development in Kiro

Practices of the Augmented Developer

The feedback that made me smile

What I take from this first Summit talk

Your Face on a World Cup Sticker: Our Nano Banana Story

⚽ 1. The idea: putting our own faces on the stickers

📌 Un harnais, c’est quoi ?

6. 💻 Joindre images et vidéos avec `gh --attach`

🎓 Envie de maîtriser MCP ?

Certificats TLS : 200 jours en 2026, 47 jours en 2029, êtes-vous prêts ?

🪟 5. Et Windows, Linux, les autres bibliothèques ?

❌ 2. Attempt #1: Why `~/.gemini/config/skills.json` fails

⚡️ 3. Attempt #2: Link `~/.gemini/config/skills` to `~/.agents/skills`

🧹 4. Bonus: Clean up `~/.gemini` when coming from Gemini CLI

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

✏️ Write the descriptor `app.yaml`