Lors de ce meetup organisé par GitGuardian et sponsorisé par Docker, plusieurs intervenants ont partagé leur vision des systèmes agentiques modernes.

L’objectif est clair : passer de simples assistants IA à de véritables agents autonomes capables d’agir, collaborer et s’exécuter en production.

La soirée s’ouvre dans les locaux parisiens de GitGuardian, qui rappelle un point souvent sous-estimé dans les discussions autour des agents IA : avant même de parler d’autonomie, il faut parler de sécurité des accès.

Le message est simple. Les secrets sont partout : API keys, JWT, tokens, credentials, ou toute information capable d’ouvrir un accès à une ressource, un service ou une infrastructure. Dans un contexte où les agents interagissent de plus en plus avec du code, des dépôts, des outils collaboratifs ou des systèmes connectés, la détection et le contrôle de ces secrets deviennent une couche critique.

GitGuardian se positionne précisément sur ce terrain : aider les développeurs, équipes sécurité et profils infra à identifier les secrets exposés dans leurs environnements, qu’il s’agisse de dépôts Git, de plateformes collaboratives comme Slack ou d’autres surfaces où des informations sensibles peuvent fuiter.

Un autre signal intéressant ressort de cette introduction : la sécurité des agents n’est plus un sujet théorique. Elle devient un besoin concret du marché, au point d’accompagner une phase de croissance active chez GitGuardian, qui indique recruter sur plusieurs profils, notamment des software engineers et des AI engineers.

👉 Point clé :

Les agents ne doivent jamais exposer des secrets sensibles sans contrôle strict.

La qualité de cette soirée tient aussi à son casting. Plutôt que d’aligner des profils purement théoriques, l’événement réunissait des intervenants directement impliqués dans la construction d’outils, de runtimes et d’infrastructures liés aux workflows agentiques.

Sébastien Blanc, Technical Director chez Sciam, a présenté SAIL: Serverless Agentic Containers, une approche orientée exécution distribuée, où les agents ne sont plus pensés comme de simples assistants locaux, mais comme des workloads capables de vivre dans un environnement serverless. Son intervention prolonge naturellement les discussions sur Kubernetes, Knative et les architectures orientées événements, avec une question de fond : comment construire des systèmes agentiques robustes, scalables et économes en ressources ?

Philippe Charrière, Principal Solutions Architect chez Docker, a proposé une session intitulée Compose and Dragons: Tiny LLMs, sans doute l’une des plus expérimentales de la soirée. Son angle est particulièrement intéressant : montrer que les petits modèles locaux ne sont pas seulement des curiosités techniques, mais qu’ils peuvent servir de base à des systèmes multi-agents, à condition d’accepter leurs contraintes de mémoire, de performance et d’orchestration. Son travail met en lumière un futur possible où les agents ne reposent pas uniquement sur des modèles géants distants, mais aussi sur des briques locales, spécialisées et composables.

David Gageot, Senior Principal Software Engineer chez Docker, est intervenu sur Docker Agent: No-Code AI Agents. Son propos s’inscrit dans une logique de simplification radicale : réduire la friction entre l’idée d’un agent et sa mise en œuvre concrète. L’intérêt de son intervention ne réside pas seulement dans le “no-code”, mais dans la capacité à rendre les agents plus accessibles, plus déclaratifs, et plus faciles à intégrer dans des workflows réels.

Guillaume Lours, Staff Software Engineer chez Docker, a présenté Docker Sandboxes, probablement l’un des sujets les plus stratégiques de la soirée. Là où beaucoup de discussions autour des agents se concentrent sur les modèles ou les prompts, son intervention remet le runtime au centre : si un agent doit agir, il doit être isolé, observable et gouvernable. Les sandboxes Docker apportent ici une réponse très concrète aux questions d’exécution sécurisée, de permissions réseau, de secrets et de contrôle des accès.

Djordje Lukic, Principal Software Engineer chez Docker, partage avec David Gageot la présentation autour de Docker Agent. Son apport est important dans la mesure où il ancre le sujet dans une réflexion plus large sur les frameworks agentiques. Derrière la promesse d’agents “simples à créer”, il y a une ambition plus structurelle : fournir un cadre où modèles, outils, instructions et orchestration peuvent être assemblés proprement, avec une vraie logique d’ingénierie derrière.

La séquence Docker s’ouvre avec Georgi et son équipe, qui présentent Docker Agent non pas comme un simple assistant de plus, mais comme ce qu’ils appellent eux-mêmes un “Swiss Army Knife” des frameworks agentiques. L’idée est assez claire : sortir de l’usage ponctuel du modèle pour entrer dans une logique où l’IA devient un composant d’exécution à part entière. Leur point de départ n’est pas théorique. Ils expliquent que Docker travaille sur ces sujets depuis près de deux ans, notamment autour de Gordon, l’assistant intégré à Docker Desktop, et que Docker Agents est désormais utilisé en interne pour construire et faire évoluer ses propres outils.

Ce qui ressort immédiatement, c’est la volonté de rendre les agents configurables, composables et exploitables en conditions réelles. Docker Agents peut se connecter à différents modèles, locaux ou distants, s’intégrer à divers outils, et surtout être décrit de manière très légère, en YAML, sans devoir systématiquement passer par une implémentation complexe. C’est l’un des messages les plus forts de la démo : l’entrée dans l’agentique ne commence pas forcément par un SDK lourd ou une architecture distribuée, mais parfois par une simple définition déclarative suffisamment claire pour produire un comportement utile.

La première démonstration joue volontairement sur quelque chose d’absurde - un agent pirate - pour montrer à quel point la barrière d’entrée est basse. Avec un modèle et une instruction, l’équipe obtient déjà un agent exploitable. La démonstration est légère, presque moqueuse, mais le sous-texte est important : un agent n’a pas besoin d’une énorme infrastructure pour exister ; il a surtout besoin d’un cadre d’exécution clair. À partir de là, Docker peut le faire évoluer vers quelque chose de beaucoup plus sérieux.

C’est précisément ce qui arrive avec la seconde partie, beaucoup plus convaincante techniquement. L’équipe montre comment brancher une API existante à un agent à partir de sa définition OpenAPI. Dans leur exemple, il s’agit d’une API Pokémon - utilisée comme substitut volontairement ludique d’une API métier plus classique - mais le message est limpide : dans un environnement d’entreprise, il serait possible de reprendre exactement le même mécanisme pour brancher des services internes, des bases de connaissance ou des outils spécialisés. L’OpenAPI spec est transformée en ensemble de tools, et l’agent peut alors interroger le système sans que l’utilisateur ait lui-même à manipuler directement les endpoints. Ce n’est plus l’humain qui navigue dans l’API : c’est l’agent qui se charge de la médiation.

La démo souligne aussi un point d’architecture souvent sous-estimé : la question n’est pas seulement de donner des tools à un agent, mais de lui donner les bons tools. Lors des échanges avec la salle, l’équipe reconnaît qu’un agent surchargé devient vite inefficace. Même si une spec OpenAPI peut exposer des dizaines voire une centaine d’outils, il est préférable de filtrer fortement et de n’en garder qu’un sous-ensemble cohérent avec la tâche. L’idée importante ici n’est pas “plus d’outils = meilleur agent”, mais presque l’inverse : un agent spécialisé fonctionne mieux avec un périmètre réduit, lisible et intentionnel.

La partie la plus intéressante arrive ensuite avec les usages plus avancés. Docker Agents ne se limite pas à une logique mono-agent pilotant quelques appels d’API. L’équipe montre un système à plusieurs niveaux, avec un agent principal, des commandes dédiées, puis des sub-agents ayant chacun leur propre rôle, leurs instructions, leur modèle et éventuellement leurs propres outils. Le quiz interactif et la simulation de combat Pokémon servent surtout à illustrer une idée plus générale : l’agentique utile repose moins sur un “super-agent” unique que sur une orchestration de responsabilités bien séparées. Le root agent coordonne, les sous-agents exécutent, et chacun opère dans un contexte mieux défini.

Les réponses apportées pendant les questions renforcent ce point. Docker distingue notamment deux formes d’interactions inter-agents : d’un côté les sub-agents, qui reçoivent une tâche avec un contexte neuf ; de l’autre les mécanismes de handoff, où la conversation peut basculer d’un agent à un autre. L’équipe évoque également la possibilité de partager certains outils de mémoire ou de to-do entre plusieurs agents. Là encore, on retrouve une idée structurante : l’agentique devient intéressante quand elle cesse d’être uniquement conversationnelle pour devenir organisationnelle. On ne demande plus seulement à un modèle de répondre ; on distribue du travail entre plusieurs entités spécialisées.

La seconde partie complète parfaitement la première. Après avoir montré comment construire des agents, l’équipe Docker pose la vraie question : où et comment les laisser agir ? C’est là qu’intervient la démonstration autour de Docker Sandboxes. Le constat de départ est très concret : tant qu’un agent doit lire des fichiers, installer des dépendances, lancer des commandes ou accéder au réseau, il devient impossible de le faire travailler sérieusement directement sur la machine hôte sans accepter un niveau de risque trop élevé. L’intervenant le dit de manière très directe : il n’est pas question de donner ce niveau d’accès à un agent sur son laptop.

La réponse proposée par Docker est un environnement d’exécution isolé sous forme de micro-VM, contenant son propre moteur Docker, dans laquelle vient tourner un conteneur hébergeant l’agent. C’est un changement de perspective important. Le problème n’est pas seulement de “restreindre” l’agent, mais de créer un cadre où l’on peut au contraire lui donner davantage d’autonomie, tout en conservant la capacité d’observer, de filtrer et d’interrompre ses actions. L’objectif n’est donc pas de rendre l’agent inoffensif en le bloquant partout, mais de lui donner assez de liberté pour travailler réellement, dans des limites explicites.

La démonstration est parlante : dans un projet web simple, l’agent peut installer seul les dépendances nécessaires, lancer des commandes de build ou exécuter des tests, y compris quand cela implique des opérations que l’on n’accepterait pas volontiers sur sa machine personnelle. Le point fort n’est pas seulement l’isolation technique ; c’est aussi la visibilité. Les sandboxes exposent une interface permettant de lister les environnements en cours, d’inspecter les processus actifs, d’observer le trafic réseau généré par l’agent et, plus largement, de comprendre ce qu’il est réellement en train de faire. On ne délègue donc pas à l’aveugle : on délègue dans un espace instrumenté.

La gestion réseau est probablement l’aspect le plus convaincant de cette partie. Docker montre plusieurs modes de politiques réseau, allant du refus total à l’ouverture beaucoup plus permissive, avec une option intermédiaire équilibrée. Surtout, l’intérêt ne réside pas tant dans le nom des modes que dans la granularité qu’ils permettent ensuite. Un accès bloqué peut être visualisé dans les logs réseau du sandbox, puis explicitement autorisé. Cela transforme le comportement réseau de l’agent en politique observable et réglable, et non en permission globale accordée une fois pour toutes. Autrement dit : l’accès au web ou à un domaine précis ne relève plus d’une confiance implicite, mais d’une décision explicite.

La même logique est appliquée aux secrets. Là aussi, Docker prend un parti intéressant : les secrets ne sont pas simplement “visibles” dans l’environnement de l’agent comme ils le seraient sur une machine mal configurée. Ils sont injectés au moment de la création du sandbox, avec une portée globale ou spécifique selon le besoin. Ce détail a une vraie importance en production : cela signifie qu’un agent ne doit pas hériter par défaut de tout ce qui traîne sur la machine de développement. Il n’opère qu’avec ce qui lui a été fourni dans son environnement contrôlé. En pratique, cela fait des secrets une ressource explicitement provisionnée, et non un effet de bord de la session de l’utilisateur.

La démo sur l’exposition de ports va dans le même sens. Une application peut tourner dans le sandbox sans être immédiatement visible depuis l’extérieur. Si l’on veut y accéder, il faut publier le port concerné ; si on le retire, l’application continue d’exister dans son environnement isolé, mais redevient inaccessible depuis l’extérieur. Là encore, Docker montre une séparation nette entre exécution et exposition, ce qui est exactement ce qui manque dans beaucoup de démos agentiques trop rapides.

Enfin, la démonstration se termine sur un cas particulièrement intéressant pour les workflows modernes : plusieurs agents travaillant sur le même code source, mais sans se gêner mutuellement. L’approche proposée repose sur la création automatique de branches ou de worktrees séparés, de sorte que chaque agent puisse opérer dans son propre espace de travail. Cette partie est importante, car elle montre que Docker ne pense pas seulement l’agent comme un assistant individuel, mais aussi comme un acteur parallèle dans un flux de développement collaboratif. L’agent n’est plus seulement là pour répondre, mais pour prendre en charge une partie du travail dans un espace contrôlé, isolé et potentiellement concurrent.

La conclusion implicite de cette séquence est sans doute la plus utile de toute la soirée :

le vrai sujet n’est pas d’empêcher les agents d’agir, mais de construire l’environnement dans lequel ils peuvent agir correctement.

Autrement dit, l’autonomie utile ne naît pas de la confiance aveugle, mais d’un runtime bien conçu : isolation, politiques réseau fines, injection maîtrisée des secrets, observabilité et séparation des espaces de travail. C’est probablement là que cette proposition Docker devient la plus intéressante pour des stacks comme Darkwood, Flow ou toute architecture cherchant à faire passer les agents du stade “démo” au stade “système”.

Avec la présentation de Philippe Charrière, la soirée quitte un instant la question du framework agentique pour revenir à quelque chose de beaucoup plus concret : ce que coûte réellement l’exécution locale d’un modèle. Son intervention a le mérite de ramener le sujet au niveau de la machine, de la RAM et des compromis techniques. Derrière l’enthousiasme autour des “small models”, son constat est simple : oui, les modèles locaux sont intéressants, mais dès qu’on veut faire plus qu’une démo minimale, la contrainte dominante redevient immédiatement celle des ressources, en particulier sur Mac.

Le point de friction principal, dans son retour d’expérience, n’est pas tant Docker lui-même que la pression mémoire générée par les modèles. Sur sa machine - un MacBook Pro M2 Max avec 32 Go de RAM - un modèle peut sembler “tenir” en théorie, puis devenir inutilisable en pratique dès qu’on commence réellement à l’interroger. Philippe insiste sur un détail important : une estimation de compatibilité n’est pas toujours une garantie d’usage confortable. Un modèle peut démarrer, répondre une fois, puis dégrader très vite la machine dès que la charge augmente. Et si l’on ajoute un second modèle différent, ou simplement davantage de requêtes, la situation se détériore encore plus vite. Son retour terrain est presque brutal dans sa simplicité : pendant longtemps, ce qu’il prenait pour un problème Docker était en réalité un problème de mémoire.

Sa démonstration repose sur une stack relativement claire : Docker Model Runner, Docker Compose, et un ensemble de modèles locaux utilisés comme briques d’un système plus large. Lors des échanges avec la salle, il précise que Docker Model Runner s’appuie aujourd’hui sur des moteurs comme llama.cpp et vLLM, avec une ouverture possible vers MLX à l’avenir. Il distingue aussi assez nettement les contextes d’usage : vLLM paraît mieux adapté à la production, tandis que llama.cpp reste plus pertinent pour des usages locaux ou d’expérimentation. Là encore, l’idée importante n’est pas de sacraliser un backend unique, mais de reconnaître que le runtime des modèles est lui-même un sujet d’architecture.

Mais l’intervention ne se limite pas à un simple avertissement sur la RAM. Philippe montre aussi ce que l’on peut construire malgré ces contraintes, à condition d’accepter de travailler avec des modèles petits, spécialisés et locaux. Son exemple prend la forme d’un projet de jeu en mode texte, une sorte de dungeon crawler orchestré par plusieurs composants. Ce choix peut sembler ludique, mais il sert surtout à exposer une architecture intéressante : un serveur MCP pour gérer le donjon, les salles, les monstres et les règles ; un Dungeon Master comme agent principal ; plusieurs NPC agents exposant leur propre API ; et un boss final qui fonctionne lui aussi comme une entité autonome à part entière. On n’est plus ici dans une simple démo de prompting, mais dans une tentative de simulation multi-composants, où chaque rôle dispose de son propre périmètre d’action.

Ce qui rend cette partie particulièrement utile, c’est qu’elle montre que les modèles locaux ne sont pas seulement un sujet de coût ou de souveraineté. Ils impliquent une manière différente de penser le système. Philippe explique par exemple qu’il réutilise le même modèle pour plusieurs agents afin d’éviter d’exploser la mémoire, plutôt que de multiplier les instances hétérogènes. Cette approche est importante : dans un environnement contraint, le bon design ne consiste pas forcément à choisir le meilleur modèle pour chaque agent, mais parfois à concevoir l’ensemble du workflow autour d’un compromis matériel acceptable. Le système doit alors être pensé en fonction de la machine disponible, pas seulement de l’idéal fonctionnel.

Son projet “Compose and Dragons” illustre bien cette logique. La carte du donjon est générée à l’avance, d’autres composants enrichissent ensuite l’expérience avec des descriptions, des NPCs et des interactions. Tout cela repose sur une orchestration combinant modèles locaux, services Docker et agents spécialisés. Ce n’est pas encore une démonstration de robustesse industrielle, mais c’est une preuve de faisabilité intéressante : même avec des ressources limitées, il est possible de faire émerger un système autonome relativement riche, à condition d’accepter ses limites de latence, de mémoire et de complexité. Philippe le dit d’ailleurs sans détour pendant la démo : sur petits modèles, certaines interactions restent lentes, certaines transitions échouent, et le système demande encore des ajustements. C’est précisément ce qui rend le retour crédible.

Enfin, un point plus discret mais très utile apparaît en fin d’échange : cette architecture locale peut aussi être combinée avec les sandboxes Docker, à condition d’ouvrir explicitement les bons ports pour joindre le model runner depuis l’environnement isolé. Là encore, on retrouve le fil rouge de toute la soirée : les agents, les modèles et les outils ne valent que par le runtime qui les relie correctement. Les modèles locaux ne sont donc pas une alternative “simple” au cloud ; ils déplacent simplement le problème vers un autre niveau, où l’on doit arbitrer entre autonomie, performance, mémoire et architecture d’exécution.

En résumé, la démonstration de Philippe Charrière rappelle une chose essentielle :

les modèles locaux sont utiles, mais ils ne suppriment pas la complexité ; ils la rendent simplement plus visible.

La dernière intervention bascule clairement dans une logique production-ready. Après les agents, les modèles et les sandboxes, la question devient simple :

Où et comment faire tourner ces systèmes à l’échelle ?

La réponse proposée est directe : Java + Kubernetes + Knative.

Le choix est volontairement tranché :

• Java (Quarkus) pour la couche applicative

• Docker pour le packaging

• Kubernetes comme runtime principal

• Knative pour introduire du serverless

Un positionnement clair est même assumé pendant le talk :

les workflows d’agents vont s’industrialiser, et Kubernetes restera leur système d’exploitation.

La démonstration suit un chemin très concret, presque pédagogique :

1. création d’un chatbot local branché sur un modèle via Docker Model Runner

2. exposition via une simple API HTTP

3. containerisation de l’application

4. déploiement sur Kubernetes

5. exécution dans un pod… capable de dialoguer avec le modèle local

👉 Point intéressant : le modèle reste accessible via une API compatible OpenAI, ce qui permet de réutiliser n’importe quelle librairie existante sans adaptation lourde.

Une fois l’application déployée sur Kubernetes, la bascule vers Knative change complètement le modèle d’exécution.

Au lieu de gérer des pods en continu, on passe à un modèle serverless natif Kubernetes :

• aucun trafic → 0 pod

• requête entrante → création automatique d’un pod

• pic de charge → auto-scale massif

• fin d’activité → retour à zéro

👉 Démonstration simple mais efficace :

• un curl → déclenche la création d’un pod

• la requête est traitée

• quelques secondes plus tard → le pod disparaît

On ne gère plus des machines, mais uniquement des workloads à la demande.

Ce modèle pose immédiatement une question critique :

que devient la mémoire quand tout scale à zéro ?

La réponse proposée est pragmatique :

• rendre les agents stateless

• externaliser l’état dans un système dédié

👉 solution utilisée :

• Redis comme mémoire partagée

• stockage de l’état des conversations / agents hors des pods

Résultat :

• les agents peuvent être recréés à la volée

• la mémoire persiste indépendamment de l’infrastructure

• le système reste compatible avec le scaling agressif de Knative

La conclusion ouvre une direction intéressante :

• déploiement d’agents via CRDs Kubernetes

• communication entre agents

• orchestration à grande échelle

• déclenchement via événements (Kafka, HTTP…)

👉 En quelques lignes de YAML, on peut :

• déployer plusieurs agents

• les faire communiquer

• gérer leur cycle de vie automatiquement

Cette partie change complètement de perspective :

un agent n’est plus un script ou un outil local, c’est une unité de calcul distribuée, éphémère, orchestrée par Kubernetes.

Et avec Knative + Redis, on obtient une architecture où :

• l’exécution est élastique

• l’état est externalisé

• et les agents deviennent réellement scalables en production

Les talks convergent vers une même direction :

• LLM = assistant

• usage ponctuel

• agents autonomes

• multi-agents

• orchestration

• exécution réelle

| Domaine | Solution | | ------------- | -------------------- | | Agents | Docker Agents | | Sécurité | Docker Sandbox | | Modèles | Docker Model Runner | | Orchestration | YAML / multi-agents | | Infra | Kubernetes / Knative | | Mémoire | Redis |

Le vrai enjeu n’est pas de limiter les agents, mais :

leur donner un maximum d’autonomie dans un cadre strictement contrôlé

Les concepts clés :

• sandboxing

• policies réseau

• injection sécurisée des secrets

• orchestration multi-agents

• infra scalable

On passe de :

👉 “je demande à une IA” à 👉 “je délègue à un système autonome”