Vos agents IA ne sont plus des chatbots. Ce sont des workloads.

Combien de credentials votre dernier agent IA a-t-il en mémoire, là, maintenant ?

Chez Grab, des centaines d’agents autonomes tournent déjà en production : ils lisent du code, appellent des API, lancent des tests, ouvrent des merge requests, répondent sur Slack [1]. À ce stade, un agent n’est plus une interface de chat. C’est un workload qui agit. Et ça change tout.

Un agent qui agit, c’est une surface d’attaque qui marche toute seule

La première vague d’outils IA vivait collée à l’utilisateur : un plugin dans l’IDE, une fenêtre de chat, un assistant en ligne de commande sur le laptop du dev [1]. Familier, facile à adopter. Mais dès qu’un agent a un accès réseau, des credentials, des outils et une mémoire persistante, le modèle de risque bascule : ce n’est plus un assistant, c’est une charge de travail capable d’actions autonomes.

L’équipe de Grab a vu revenir la même question sous toutes les formes : comment laisser un agent faire du travail utile dans l’entreprise sans traiter chaque nouvel agent comme un projet d’infra sur-mesure ? [1] Et surtout : pour quel utilisateur cet agent agit-il ? Quels secrets peut-il utiliser ? Peut-il voir l’état d’un autre utilisateur ? Peut-il se connecter directement à Internet ? La réponse n’était pas de « faire tourner des agents dans des conteneurs ». Le conteneur emballe le runtime, il ne répond à aucune de ces questions-là.

Isoler, identifier, auditer : l’agent comme citoyen de première classe du cluster

La réponse de Grab s’appelle Palana, une plateforme Kubernetes-native qui donne à chaque agent un namespace isolé, du stockage persistant, un ingress contrôlé, une egress passant par un proxy, des credentials injectés depuis Vault, un routage LLM, des accès Git encadrés, des logs d’audit structurés et des kill switches d’urgence [1]. Trois principes de design tiennent l’ensemble : l’isolation comme unité de confiance, les credentials hors de portée de l’agent, et tout le trafic réseau médiatisé [2].

Concrètement, chaque agent tourne dans un namespace agent-{user}-{agent}, avec un service account lié à ce seul namespace, un volume /data dédié, une egress forcée à travers les proxys de la plateforme, et des secrets répartis entre chemins Vault lisibles par l’agent et chemins réservés au proxy [2]. L’agent ne tient jamais ses propres clés ; le proxy les injecte au moment d’appeler le service autorisé. Autrement dit : on a pris tout ce que la sécurité réseau et la gestion d’identité savent faire depuis vingt ans, et on l’a appliqué à une nouvelle classe de workload.

Rien de magique là-dedans. Et c’est justement le point. Le futur agentique ne se construit pas sur une percée conceptuelle — il se construit sur de la discipline d’infrastructure bien ennuyeuse.

Et pendant ce temps, le vrai travail reste… du SQL

La meilleure illustration de cette tension, c’est un billet sur la détection de fraude. Son auteur le dit sans détour : détecter la fraude dans des données transactionnelles, c’est surtout du SQL. Pas du machine learning, pas des bases de graphes, pas ce que Gartner hype cette année [3].

If money moves and gets logged, these queries will find weird things in the log.

Six patterns suffisent : la vélocité (une carte volée qu’on vide vite), le « voyage impossible » (une carte qui swipe à Chicago puis à Los Angeles sept minutes plus tard), et quelques autres formes que des fenêtres glissantes et des LAG() bien placés font remonter [3]. La même leçon revient côté ads : chaque pub que vous croisez résulte d’une décision prise en moins de 100 millisecondes, sur des millions de candidats. La solution n’est pas de balancer un modèle ML sur chaque candidat — c’est un entonnoir [4].

D’abord des filtres booléens déterministes — l’annonceur cible les US, l’utilisateur est en France : éliminé en quelques millisecondes. Ensuite un modèle léger (un GBDT type XGBoost) qui élague les perdants évidents. Et seulement à la fin, le modèle lourd sur une poignée de survivants [4]. « L’éligibilité est déterministe et binaire. La qualité est probabiliste et continue. Confondre les deux est une erreur de design. » C’est exactement la discipline qu’on oublie quand on colle un LLM sur tout : savoir quand ne pas utiliser l’IA.

L’identité et le consentement ne sont pas des détails d’implémentation

Le fil rouge de Palana — qui agit, avec quelle permission, sur quelles données — c’est aussi le problème central des plateformes data modernes. Razorpay a construit un Customer Data Platform qui sert des segments d’audience sur plus de 500 millions de profils en moins de 30 ms, avec les PII isolées dans les systèmes sources [5].

Le déclencheur ? Une cliente qui paie 1 200 ₹ en UPI, puis avec une carte Visa, puis en net banking : trois transactions, trois instruments, trois appareils. Pour les systèmes, trois personnes différentes — sauf si on a fait le travail d’identité pour comprendre que c’est la même cliente [5]. Avant, répondre à une question de segmentation prenait 2-3 jours et un job Spark sur-mesure. La fenêtre commerciale était déjà fermée. Le « consent-native » et l’isolation des PII ne sont pas des cases à cocher pour le légal : ce sont les fondations qui décident si la plateforme tient à l’échelle.

Le schéma est un contrat, pas une métadonnée

Reste la question la moins glamour de toutes : que se passe-t-il quand les données changent de forme ? Chez Pinterest, le schéma n’est pas une métadonnée — c’est un contrat inter-systèmes qui traverse l’ingestion, la transformation, le stockage et le backfill historique [6]. Un changement de schéma mal géré casse des jobs Flink, bloque des upserts Spark, crée des incohérences entre online et offline. Leur réponse : une évolution de schéma automatisée, propagée par PR avec versioning et audit, sur une cohérence éventuelle pilotée par SLA [6].

Le même angle mort guette nos notebooks. Un notebook commence innocemment — quelques imports, une query, un dataframe — puis devient une dépendance de production qui alimente un dashboard et informe une décision business [7]. Le jour où quelqu’un demande « pourquoi le chiffre a changé ? », on découvre la vérité inconfortable : la plupart des notebooks sont conçus pour être exécutés, pas pour être compris après coup [7]. Schéma silencieux qui dérive, objets intermédiaires non tracés, logique redondante : un notebook peut tourner parfaitement tout en étant structurellement fragile.

Tout se tient. Qu’on parle d’un agent autonome, d’un CDP à 500 millions de profils ou d’un notebook devenu critique, la question est la même : qui agit, sur quelles données, et peut-on retracer ce qui s’est passé ?

Le futur agentique ne sera pas gagné par ceux qui collent des LLM partout. Il sera gagné par ceux qui savent isoler, identifier, auditer — et reconnaître quand un bon vieux GROUP BY fait mieux qu’un modèle. La vraie question : votre plateforme est-elle prête à traiter un agent IA comme un workload de première classe, ou attend-elle le premier incident pour s’en rendre compte ?

Sources

Pour aller plus loin

LakeDB - Next Generation Data Architecture — la vision d’un lakehouse avec ACID natif, branches Git-like et sécurité au niveau du stockage, pour creuser où va l’architecture data.
Can We Agree on a Storage/Workload Architecture Taxonomy? — Jack Vanlightly — un vocabulaire clair (OLTP, OLAP, HTAP, LTAP, tiering, materializing) pour enfin parler d’architecture sans se mélanger les pinceaux.
Zone-Failure-Resilient OpenSearch® at Uber — comment Uber encaisse la perte complète d’une zone sans perdre query ni ingestion : la résilience comme exigence non négociable.

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.

Cet article a été rédigé en m'appuyant sur une IA pour m'aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.