Le context lake : pourquoi votre data lake ne suffit pas pour les agents IA

Une nouvelle expression circule sur les pages produit, les notes d’analystes et les schémas d’architecture : context lake. Port l’utilise pour décrire une couche de connaissance d’ingénierie. Tacnode en construit une version temps réel. Forrester a publié plus tôt cette année un papier expliquant pourquoi le sujet compte pour l’IA agentique. Un article arXiv l’a formalisé comme classe de système. Le terme converge, depuis des angles différents et avec des accents différents, vers la même intuition : l’infrastructure de données pensée pour l’ère analytique n’est pas celle dont l’ère agentique a besoin. La thèse à défendre : le context lake sera aussi fondateur pour l’entreprise agentique que le data lake l’a été pour l’entreprise analytique, et les acteurs qui le comprennent tôt tiendront un avantage structurel difficile à copier.

Le data lake répond à « ce qui s’est passé ». Le context lake répond à « ce que je dois faire ».

Depuis le milieu des années 2010, le data lake est le centre de gravité de la stratégie data en entreprise. Tout déverser dedans, formuler les questions plus tard, laisser les analystes et les modèles s’en sortir. Cela a fonctionné, à peu près, pour les dashboards, la BI et la première vague de machine learning. Cela a même fonctionné aux premiers jours de l’IA générative, quand « branchez vos documents sur une vector DB » passait pour une réponse complète.

Ce n’en est plus une. Et la raison est simple : ce qu’on construit aujourd’hui au-dessus de la donnée d’entreprise est d’une nature radicalement différente d’un dashboard ou d’un modèle. C’est un agent. Et les agents n’ont pas besoin de données. Ils ont besoin de contexte.

Un data lake est un réservoir passif. Il stocke des faits (transactions, logs, documents, événements) et attend qu’un humain ou une machine vienne poser une question. Sa valeur se mesure en volume, en fraîcheur et en performance des requêtes. Ses consommateurs sont des humains équipés de SQL, d’outils BI et de pipelines ML. Son modèle de gouvernance suppose un nombre relativement restreint d’utilisateurs avertis qui savent ce qu’ils cherchent.

Un agent IA est un consommateur d’une tout autre nature. Il n’arrive pas avec une requête pré-écrite. Il arrive avec un objectif (« résolvez cette réclamation client », « clôturez les comptes du T3 », « négociez ce renouvellement ») et il doit déterminer, en cours de route, ce qu’il a besoin de savoir, quels outils il a le droit d’utiliser, quelles règles encadrent sa décision, et ce que « terminé » signifie réellement dans votre entreprise. Aucun volume de fichiers Parquet bien rangés ne lui dira rien de tout cela.

Cette couche manquante (la logique métier, les permissions d’outils, les politiques, la connaissance institutionnelle sur la façon dont votre entreprise opère réellement) est ce que tient un context lake. C’est la différence entre confier à quelqu’un la Bibliothèque du Congrès et lui remettre le livret d’accueil de son poste.

Ce qui vit réellement dans un context lake

Les premières définitions qui émergent sur le marché insistent chacune sur une facette. Port se concentre sur l’ingénierie et l’ownership des services. Tacnode met l’accent sur la fraîcheur temps réel et la cohérence au moment de la décision. Tous les deux ont raison sur leur portion. Mais le tableau complet, à mon sens, est plus large. Trois éléments, et aucun ne vit proprement dans un système que vous possédez déjà.

Le sens métier. C’est la couche sémantique dont un agent a besoin pour agir intelligemment en votre nom. Que veut dire « client actif » chez vous : quelqu’un qui s’est connecté ce mois-ci, ou quelqu’un dont le contrat est en cours ? Quels SKU sont arrêtés mais encore maintenus ? Quels comptes sont stratégiques et exigent un humain dans la boucle ? Cette connaissance existe aujourd’hui, mais elle est dispersée entre les pages Confluence, les threads Slack, la tête des collaborateurs séniors et la mémoire orale. Un data lake détient les transactions ; il ne détient pas la signification.

Les outils et les capacités. La puissance d’un agent vient de sa capacité à faire des choses : appeler des API, écrire dans des systèmes de référence, envoyer des communications, déplacer de l’argent. Un context lake catalogue quels outils existent, ce qu’ils font, quand les mobiliser et, surtout, sous quelles conditions chaque agent a le droit de les utiliser. Ce n’est pas la même chose qu’un API gateway. Un API gateway demande « cette requête est-elle authentifiée ? ». Un context lake demande « est-ce le type de décision que cet agent devrait prendre maintenant, pour ce client, pour ce montant, sans escalade ? ».

La gouvernance et la politique. Chaque industrie régulée a ses règles : ce qui peut être automatisé et ce qui ne peut pas, ce qui doit être journalisé, ce qui exige une revue humaine, ce qui ne doit jamais quitter une juridiction donnée. Dans un monde de logiciel déterministe, ces règles s’incrustent dans le code applicatif. Dans un monde d’agents probabilistes qui raisonnent sur du langage naturel, les règles elles-mêmes doivent devenir des artefacts de premier rang : interrogeables et auditables. Le context lake est l’endroit où la politique devient exécutable, pas comme des if enfouis, mais comme une couche gouvernée que l’agent consulte avant d’agir.

Le point intéressant sur ces trois éléments, c’est qu’aucune entreprise ne les détient au même endroit aujourd’hui. La sémantique métier vit dans la tête des gens et dans des docs éparpillées. Les permissions d’outils vivent dans les API gateways et les politiques IAM. La gouvernance vit dans des PDF juridiques et des tableurs de conformité. Le travail du context lake consiste à rendre les trois lisibles, interrogeables et gouvernés dans une couche unique.

Pourquoi cela doit être une nouvelle couche, pas une option d’un produit existant

L’objection évidente arrive vite : ne peut-on pas tout poser dans le data lake ? Ou dans la vector DB ? Ou dans le framework d’agent ? Beaucoup essaient. Voici pourquoi cela ne tient pas.

Le data lake est optimisé pour le volume et les requêtes analytiques, pas pour les lookups basse latence et haute précision dont un agent a besoin en cours de décision. Les vector DB sont bonnes pour la similarité sémantique, mais n’ont aucune notion native de permission, de politique ou d’affordance d’outil. Elles iront chercher avec entrain un document que l’agent n’a aucun droit d’exploiter. Quant aux frameworks d’agents, ils bougent trop vite et se fragmentent trop pour devenir le système de référence d’un actif aussi durable que vos règles métier. Vous ne voulez pas coupler votre modèle de gouvernance à la bibliothèque d’orchestration à la mode ce trimestre.

Ce dont l’entreprise a besoin, c’est d’une couche agnostique au framework d’agent, gouvernée de manière centrale et bâtie dès le premier jour autour des trois primitives du travail agentique : savoir, agir, et avoir le droit. C’est une forme de produit différente de tout ce qui existait dans la modern data stack il y a deux ans, et c’est précisément pour cela que plusieurs acteurs, dont skilder, convergent aujourd’hui pour le construire.

L’enjeu stratégique

Soyons direct sur la raison pour laquelle ce sujet compte au niveau exécutif, parce qu’il est facile d’entendre « nouvelle couche dans la stack » et de zapper en se disant que c’est de la plomberie.

Les entreprises qui déploieront des agents avec succès sur les trois prochaines années ne seront pas celles qui ont le plus de données. Ce seront celles qui auront fait le travail de rendre leur contexte (leur jugement, leurs règles, leur connaissance institutionnelle) lisible par des machines. Ce travail n’est pas un projet de week-end. C’est la version suivante de ce qu’on appelait « transformation digitale », et c’est le véritable avantage durable. Vos concurrents peuvent acheter les mêmes modèles et les mêmes data warehouses. Ils ne peuvent pas répliquer facilement une décennie de sagesse opérationnelle codifiée.

À l’inverse, les entreprises qui tenteront le raccourci, en jetant des agents sur un data lake brut en espérant que le LLM s’en sorte, vont générer une leçon très coûteuse sur la différence entre contexte et information. On voit déjà les premières versions de cette leçon en production. Des agents qui prennent avec assurance la mauvaise décision. Des agents incapables d’expliquer leur raisonnement à un auditeur. Des agents qui tournent magnifiquement en démo et s’effondrent dès qu’ils rencontrent la réalité désordonnée du fonctionnement réel de l’entreprise.

Par où commencer

Si vous êtes dirigeant et que vous réfléchissez à la préparation de votre organisation pour la vague agentique, la question à ramener à vos équipes n’est pas « quel modèle utiliser » ni « quelle vector DB choisir ». C’est plus simple et plus exigeant :

Si nous devions remettre à un collaborateur nouvellement arrivé, très compétent, le livret qui lui explique comment notre entreprise fonctionne réellement (les règles, les outils, les arbitrages, les choses jamais écrites), pourrions-nous le faire ? Et sinon, qu’est-ce que cela demanderait ?

Ce livret, c’est votre context lake. La catégorie est encore en train de se définir, les éditeurs sont encore en train d’émerger, le terme lui-même cherche encore son sens partagé. Mais le besoin sous-jacent est déjà réel, et les agents sont déjà à la porte. Quel que soit le nom qui s’imposera, le travail de construction de cette couche est celui qui séparera les entreprises pour lesquelles les agents paient de celles pour lesquelles ils ne paient pas.