Agents d’IA : trois usages du contexte, retours d’étude

Des utilisateurs avancés d’un agent d’IA distinguent un triptyque de contextes — global, local et ambiant — alimenté par des fichiers, des bases et des connexions en direct. Des exemples concrets vont des transcriptions de réunions aux données Shopify, en passant par des règles de gouvernance et des listes de tâches générées par l’agent.

Flux ambiants massifs sans tri, connectés en continu à l’agent

Le contexte ambiant décrit le pan le plus vaste et le plus désordonné du paysage informationnel. Il se compose de flux non filtrés comme les emails, les transcriptions de réunions et les messages de chat, jugés précieux parce qu’ils reflètent les priorités réelles et la perception d’un « bon » travail sans que l’utilisateur ait à les documenter. Dans la pratique observée, les participants n’ont ni défini, ni nettoyé, ni formaté ces flux, qui provenaient pour l’essentiel de sources en évolution constante, comme les courriels ou des publications Reddit, acheminées via des connexions MCP. Faute de temps pour trier et classer en global ou local, ils transmettaient l’intégralité du flux à l’agent en espérant qu’il suive. La plupart transcrivaient autant de réunions que possible et considéraient ces transcriptions comme essentielles à leur bibliothèque de contexte. Les messages Slack et courriels, envoyés comme reçus, étaient aussi jugés clés et devaient être disponibles pour l’agent. Certains allaient jusqu’à demander le parcours d’environ 30 sous‑reddits populaires couvrant IA, marketing et affaires. D’autres reliaient des outils produits comme Amplitude pour un accès continu aux métriques. Dans un cas, l’agent exportait régulièrement des données Shopify via un script fourni par une participante pour mettre à jour des profils clients HubSpot et suivre le statut de chaque client. Ces flux, toujours actifs et jamais organisés, influençaient en permanence la façon de penser des utilisateurs, ce que l’agent devait prendre en compte.

Une typologie en trois rôles pour structurer l’information des agents

Les informations qu’exploitent les agents se répartissent en trois rôles complémentaires. Le contexte global réunit des éléments stables qui orientent les actions de l’agent au fil des interactions. Le contexte local couvre des informations strictement liées à une tâche ou à un projet. Le contexte ambiant englobe des flux bruts non filtrés, au sein desquels l’agent identifie ce qui est pertinent. Ensemble, ces rôles se combinent comme une architecture : le global sert de base, le local joue les piliers qui soutiennent l’exécution, et l’ambiant forme l’environnement informationnel qui entoure le travail.

Un même contenu passe d’un usage ambiant à local selon l’action

Le rôle d’une même information n’est pas figé. Un message Slack peut débuter comme flux ambiant via une connexion MCP, puis devenir local dès lors que l’utilisateur y renvoie explicitement l’agent pour une tâche donnée. À l’inverse, un article souvent mobilisé comme ressource locale peut être archivé et prendre rang de référence transversale, devenant global. Certaines informations peuvent même, selon les circonstances, jouer plusieurs rôles à la fois.

Ce que recouvre le global : profil, règles, corpus et pratiques

Le contexte global est conçu pour durer, guidant le raisonnement et les priorités de haut niveau, et il évolue peu. Il peut inclure des informations spécifiques sur l’utilisateur, enregistrées lors de conversations et réutilisées ultérieurement, y compris sur d’autres sujets. Il agrège aussi des meilleures pratiques sous forme de directives, d’exemples ou de modèles décrivant un travail bien fait ; l’une des configurations observées comportait une compétence intitulée « Construisez votre propre X ». Des règles de gouvernance y précisent quelles actions nécessitent l’aval de l’utilisateur et lesquelles l’agent peut engager seul ; dans un exemple, toute action publique et tout « changement radical » exigeaient une permission. Le global peut intégrer un corpus prescriptif, tel qu’un canon de livres assorti d’instructions explicites dans un fichier markdown pour cadrer l’approche du travail. Des consignes permanentes de clarification des intentions peuvent aussi y figurer, afin d’imposer des questions de précision. En pratique, ce socle dispense l’utilisateur de réitérer ces éléments à chaque nouvelle session.

Ce que recouvre le local : listes, historiques et artefacts de soutien

Le contexte local regroupe des informations directement liées au travail en cours. Il comprend des listes de tâches par projet que l’agent peut générer et mettre à jour de façon autonome, stockées dans un fichier markdown ou un outil dédié comme Todoist. Des compétences codifiées en fichiers markdown sont appelées pour exécuter des tâches déterminées. L’historique de chat sert de contexte conversationnel, et il peut être résumé puis importé dans une nouvelle discussion pour poursuivre lorsque la longueur devient un frein. Des journaux de changements consignent automatiquement, en fin de session, les évolutions de chaque projet. Le local peut vivre dans des bases externes : des dossiers de candidatures étaient tenus dans Notion, l’agent lisant et mettant à jour les enregistrements, la participante ne les éditant jamais directement. Des rapports de recherche produits, par exemple pour analyser des terrains, ont ensuite servi de contexte temporaire pour des projets ciblés. D’une manière générale, le local est stocké dans des supports que l’agent peut lire et modifier, et une partie — listes, journaux de changements ou de décisions — est écrite par l’agent. Ce n’est pas l’artefact final de l’utilisateur, mais un dispositif d’appui pour exposer priorités et avancement.

Qui décide du rôle et comment l’agent accède à l’information

Dans les usages observés, chaque utilisateur avancé avait bâti une bibliothèque de contexte alimentée en plus de l’invite, sous des formes variées. Le rôle attribué à une information peut relever de l’agent ou de l’utilisateur. Des fichiers, comme des compétences assorties d’une courte description d’application, permettent à l’agent d’identifier de façon autonome ce qui est pertinent pour l’interaction en cours et de l’exploiter. À l’inverse, l’utilisateur peut téléverser une ressource ou diriger explicitement l’agent vers un élément stocké pour une tâche donnée. Lors de la rédaction d’un rapport de recherche, les meilleures pratiques structurent le global, la liste de tâches et les données de recherche forment le local, et des courriels avec le client ainsi qu’une transcription d’échanges constituent l’ambiant. Le rapport produit est l’issue de la tâche, non un contexte, mais il peut ensuite devenir une référence pour des projets similaires si sa qualité le justifie.