Les agents IA d'Asana partagent la mémoire dans l'entreprise, mais pas vos secrets

Les agents IA en entreprise échouent souvent parce qu'ils ne retiennent pas ce qu'ils ont appris

Les agents d'intelligence artificielle déployés en entreprise échouent régulièrement dès qu'ils doivent enchaîner des décisions complexes, et la cause est souvent la même : ils oublient ce qu'ils ont appris. C'est le problème que cherche à résoudre Rippletide, une startup gravitant dans l'écosystème Neo4j, avec une architecture appelée "decision context graph". Fondée par Yann Bilien, co-fondateur et directeur scientifique, la société a conçu un système qui dote les agents d'une mémoire structurée, d'un raisonnement ancré dans le temps et d'une logique de décision explicite. L'objectif central : des agents dits "non-régressifs", capables de figer des séquences d'actions validées et de capitaliser dessus au fil du temps. Le problème que Rippletide adresse touche au cœur de la majorité des déploiements d'IA en entreprise. Les architectures RAG (Retrieval-Augmented Generation), qui constituent aujourd'hui le standard, se contentent de récupérer des documents sémantiquement pertinents depuis des sources variées, ERP, bases de données, politiques internes, et de les injecter dans le contexte du modèle. Mais comme le souligne Wyatt Mayham, consultant chez Northwest AI Consulting, cette approche "fonctionne pour les chatbots, mais se brise immédiatement dès qu'un agent doit prendre des décisions et agir". Un document récupéré ne dit pas à l'agent s'il est encore valide, s'il a été remplacé, ou si une règle contradictoire a la priorité. Résultat : des agents qui combinent des règles incompatibles, inventent des contraintes pour combler les vides, et produisent des erreurs difficiles à tracer et à reproduire. À l'échelle d'un workflow multi-étapes, même un faible taux d'erreur par étape devient catastrophique, raison principale pour laquelle la plupart des agents d'entreprise ne sortent jamais de la phase pilote. Le "decision context graph" répond à ce problème en encodant explicitement une carte structurée : quelles règles s'appliquent, dans quel contexte, et à quel moment. Le temps y est traité comme une dimension de premier ordre, chaque règle, décision et exception est délimitée temporellement, permettant à l'agent de distinguer "ce qui était vrai à ce moment-là" de "ce qui est vrai maintenant". Le système repose sur trois piliers : l'applicabilité (le bon contexte est retourné uniquement quand il est pertinent), la mémoire temporelle, et les chemins de décision explicites, l'agent peut expliquer pourquoi il a inclus tel contexte et non un autre. Lors de l'initialisation, les données non structurées sont ingérées puis organisées en ontologie. Ce marché de l'infrastructure agentique en entreprise attire une attention croissante alors que les limitations du RAG seul deviennent un frein réel au passage à l'échelle des systèmes d'IA autonomes.

Les agents Claude peuvent désormais se connecter aux API d'entreprise sans exposer leurs identifiants

Anthropic vient d'annoncer deux nouvelles fonctionnalités pour Claude Managed Agents qui s'attaquent directement au principal frein à l'adoption des agents IA en entreprise : la sécurité des identifiants d'accès. La première, les sandboxes auto-hébergées, permet aux équipes d'exécuter les appels d'outils au sein de leur propre infrastructure, et est disponible dès maintenant en bêta publique. La seconde, les tunnels MCP, connecte les agents à des serveurs MCP privés sans que les identifiants ne transitent par le contexte de l'agent ; elle est pour l'instant en préversion de recherche. Cette architecture divise le système en deux parties distinctes : la boucle agentique (orchestration, gestion du contexte, récupération sur erreur) s'exécute sur l'infrastructure d'Anthropic, tandis que l'exécution des outils reste dans le périmètre de l'entreprise. Les tunnels MCP, eux, fonctionnent via une passerelle légère en sortie uniquement, installée dans le réseau de l'organisation, sans qu'aucun identifiant ne passe par l'agent. Ce changement architectural répond à un problème de fond dans les déploiements actuels : dans la plupart des systèmes en production, l'agent transporte lui-même les jetons d'authentification lors de l'exécution des appels d'outils. Un agent compromis ou mal configuré emporte donc avec lui tout ce dont il a besoin pour causer des dégâts sur les systèmes internes. En déplaçant le contrôle des identifiants vers la frontière réseau plutôt que de les laisser à l'intérieur de l'agent, Anthropic modifie substantiellement le modèle de menace. Pour les équipes d'orchestration, l'enjeu dépasse la sécurité : cette séparation permet de cartographier plus précisément les flux de travail des agents, de mieux contrôler les ressources de calcul et d'isoler les responsabilités entre la plateforme et l'infrastructure métier. Anthropic n'est pas seul sur ce terrain. OpenAI avait déjà ajouté l'exécution locale à son Agents SDK en avril 2025, en réponse à des demandes similaires de ses clients entreprise. La distinction que revendique Anthropic réside précisément dans cette séparation franche entre boucle agentique et exécution des outils, que les approches sandbox existantes, y compris celle d'OpenAI, ne font pas. Le protocole MCP, adopté rapidement en environnement de production, a en effet précédé la maturité des architectures de sécurité qui l'entourent, créant un écart que ces nouvelles fonctionnalités cherchent à combler. Pour les équipes qui évaluent la plateforme, la recommandation pratique est claire : commencer par migrer l'exécution des outils vers les sandboxes auto-hébergées et valider cette frontière avant d'explorer les tunnels MCP, encore en phase expérimentale.

Les agents IA apprennent en cours de tâche, mais pas pour toute l'équipe

Les agents d'intelligence artificielle peinent à devenir de véritables outils d'équipe. Selon une étude interne d'Asana, 75 % des travailleurs du savoir utilisent déjà l'IA au quotidien, mais seulement 5 % des entreprises déclarent en avoir tiré des gains de productivité mesurables. La raison principale : lorsqu'un collaborateur corrige ou améliore un agent, en affinant ses instructions, en lui fournissant un contexte plus précis, cette amélioration s'évapore dès qu'un collègue ouvre le même outil. Chaque utilisateur repart de zéro, entraînant en pratique une version différente du même agent selon la personne qui l'interroge. Arnab Bose, directeur produit d'Asana, résume le problème : les fournisseurs de modèles progressent rapidement sur le raisonnement et les boucles de correction, mais échouent à intégrer le contexte de travail d'entreprise d'une manière intelligible et partageable entre humains. Ce défaut architectural a des conséquences concrètes dans les workflows multi-agents, devenus la norme dans les grandes organisations : des agents qui se contredisent, des tâches répétées inutilement, des versions incohérentes de la réalité selon les équipes. Sriharsha Chintalapani, cofondateur et directeur technique de Collate, souligne que les agents sont extrêmement sensibles à la qualité des instructions reçues : un utilisateur expérimenté obtient de meilleurs résultats parce qu'il formule des prompts plus précis et donne de meilleurs retours correctifs, que l'agent mémorise et applique aux interactions suivantes. Ce mécanisme fonctionne bien pour un usage individuel, mais devient un avantage inégalement distribué dès qu'il s'agit d'un usage collectif. Neej Gore, directeur des données de Zeta Global, défend l'idée d'une mémoire partagée qui agirait comme une intelligence composée, s'enrichissant à chaque interaction et bénéficiant à toute l'organisation. La réponse d'Asana consiste à placer la mémoire partagée au coeur de sa plateforme Agentic Work Management : toute correction apportée par un membre de l'équipe s'applique automatiquement à l'ensemble des utilisateurs, via un graphe de contexte injecté directement dans les agents opérant dans son système. Plus besoin que chaque collaborateur maîtrise l'ingénierie des prompts. Mais la question de qui contrôle cette mémoire, ce qui y est stocké et comment elle reste cohérente quand plusieurs agents et utilisateurs y écrivent simultanément reste largement sans réponse dans l'industrie. Chintalapani avance que la piste la plus prometteuse consiste à construire des agents capables de récupérer la mémoire de manière relationnelle, en fonction du contexte précis de chaque requête, une approche que seules quelques organisations disposant de ressources importantes sont aujourd'hui en mesure de mettre en oeuvre.

Les agents IA ne sont pas freinés par les modèles, mais par les permissions

Les agents d'intelligence artificielle déployés en entreprise se heurtent moins à des limites de performance qu'à un problème de gouvernance : qui a le droit de faire quoi, au nom de qui, et comment le système peut-il en être certain ? C'est autour de cette question que Workday a construit Sana, son système de référence pour les agents IA, lancé en mars dernier. Gerrit Kazmaier, président produit et technologie de Workday, l'a confirmé dans un entretien à VentureBeat : les entreprises qui tentent de construire leurs propres solutions en accédant directement aux données brutes perdent la richesse du modèle de sécurité existant, et obtiennent des résultats trop larges, mal ciblés. En parallèle, Workday a élargi son partenariat avec Google pour intégrer Sana à Gemini Enterprise, rendant ainsi les agents construits sur cette infrastructure découvrables depuis l'écosystème Google. L'enjeu est particulièrement critique dans les domaines des ressources humaines et de la finance, où "presque juste n'est pas acceptable", selon Kazmaier. Un bulletin de salaire mal calculé, un entretien mal planifié ou une clôture comptable erronée ont des conséquences immédiates et souvent irréversibles, contrairement à la plupart des sorties d'IA générative, ces erreurs n'ont pas de boucle de correction. Workday a répondu à ce défi en construisant Gemini comme couche de raisonnement de base, puis en superposant son moteur de contexte métier et sa logique de processus. Des modèles de vérification et de classification "interrogent" les résultats avant toute exécution. Concrètement, l'agent Sana Self-Service utilise Gemini comme interface conversationnelle pour déclencher un flux de travail, mais l'utilisateur est ensuite authentifié et autorisé via le modèle d'identité Workday. L'agent n'agit qu'au nom de cet utilisateur précis, dans le périmètre exact de ses droits actuels. Le positionnement de Workday sur ce marché repose sur une réalité déjà bien établie : des fournisseurs d'identité majeurs comme Okta vérifient déjà leurs données en interrogeant Workday, qui fait de facto office de système de référence organisationnelle pour de nombreuses grandes entreprises. Cette position centrale lui permet d'inférer les hiérarchies et structures de ses clients directement à partir des données qu'ils lui confient. Des praticiens du secteur confirment que cette architecture n'est pas un choix technique parmi d'autres. Dan Obendorfer, directeur produit chez Würk, est catégorique : "Si vos permissions sont définies ailleurs que là où les données vivent réellement, vous avez déjà perdu." Kadan Stadelmann, CTO et cofondateur de Compance.AI, abonde dans le même sens : sans traçabilité claire sur la propriété, les coûts et les actions des agents, "c'est le chaos". La course à l'agent autonome en entreprise se jouera donc moins sur la puissance des modèles que sur la capacité à ancrer la gouvernance dans le système qui fait autorité.

💬 Le vrai frein pour les agents en entreprise, c'est pas le modèle, c'est le "t'as le droit de faire ça ou pas". Workday l'a compris avant tout le monde, et leur position est solide : quand t'es déjà le système qui dit qui est qui dans l'organigramme, t'as une longueur d'avance que personne ne peut copier juste en branchant une API. Sur la paie et la compta, là où une erreur ne se corrige pas avec un "oh pardon", c'est exactement le bon endroit pour poser la couche de gouvernance.