Agent IA et données d'entreprise : documenter avant de brancher

Le 9 octobre 2026, LinkedIn Engineering a décrit une couche partagée de contexte de données, conçue pour aider les personnes et les agents IA à découvrir les bons actifs de données (LinkedIn Engineering, 09/10/2026). Elle associe des profils de jeux de données générés automatiquement et des connaissances maintenues par les équipes.

Notre lecture : un agent IA branché sur les données d'une entreprise n'est utile que si ces données sont décrites avant d'être interrogées. Pour une PME, le chantier qui conditionne un agent utile dans l'ERP ou le CRM n'est pas le choix du modèle, c'est la description de ses propres données : quelle table fait foi, quels filtres sont obligatoires, quelles règles existent déjà.

Que décrit LinkedIn dans sa couche de contexte de données ?

Dans l'architecture décrite par LinkedIn, le profil généré de chaque jeu de données indique son objectif, ses champs, ses clés de jointure et des requêtes représentatives. LinkedIn y ajoute des consignes rédigées par des humains : définitions métier, exceptions et problèmes de qualité des données.

L'exemple donné est une métrique adaptée au suivi de l'engagement mais « unsuitable for financial close », donc inadaptée à la clôture financière. Deux autres règles sont citées : les personnes utilisent des filtres de partition pour éviter un double comptage (« people use partition filters to avoid double-counting »), et une clé de jointure peut n'être valable que pour les données postérieures à une certaine date (« a join key may be valid only for data after a particular date »).

LinkedIn chiffre l'effet dans un test sur un domaine d'activité : le taux de réponses acceptables est passé de 25,9 % à 79,5 % après l'intégration de la couche de contexte, et le temps médian pour obtenir une réponse de 10,7 à 4,7 minutes. Ces chiffres valent pour ce test et ce domaine.

Notre lecture : ce qui compte est la nature des règles consignées. Un filtre à poser pour éviter un double comptage ne se devine pas depuis le schéma d'une base. Ces règles vivent souvent dans la tête de quelques personnes, et c'est ce que la couche de contexte rend lisible pour un agent.

Que montrent Coinbase et le billet « Agents don't need memory » ?

Selon Cryip, qui relaie dans un article du 08/10/2026 un billet du blog de Coinbase, l'agent de risque fondé sur un LLM s'ajoute au modèle de machine learning et aux règles déjà en place pour Onramp. Il intervient en aval des contrôles existants, comme revue contextuelle supplémentaire de transactions sélectionnées. Nous ne reprenons pas les pourcentages du test A/B, lus seulement dans ce relais.

Le 03/10/2026, l'auteur du blog liao.gg soutient que les plugins de mémoire pour agents reposent sur la recherche de fragments dans une base vectorielle, ce qui ne dit pas ce qui est correct, à jour ou manquant. Sa conclusion : « Agents don't need memory. They need documentation. »

Il recommande une documentation structurée que l'agent lit avant de travailler et met à jour ensuite, limitée à ce que le code ne peut pas montrer (exigences, décisions, contraintes). Ses faits sont réécrits quand ils changent plutôt qu'ajoutés. Il présente son propre outil open source, Operator, comme appliquant cette approche.

Notre lecture : avec LinkedIn, ces deux textes disent la même chose sous trois angles. Chez Coinbase, selon le relais de Cryip du 08/10/2026, l'agent se place après des contrôles qui existaient déjà. Chez liao.gg, l'exemple est celui du code, et la transposition aux tables d'un ERP ou d'un CRM est la nôtre.

Que fait Microsoft avec ses compétences Copilot dans Dynamics 365 ?

Selon l'avis Microsoft Message Center MC1492151 (copie publiée par mc.merill.net, 08/10/2026), Microsoft déploie à partir du 8 octobre 2026 trente compétences de vente et de service pour des expériences Copilot, autour de Dynamics 365 Sales et Customer Service. Selon le même avis, elles sont en disponibilité générale dans Cowork, dans le programme Frontier pour Code, et en préversion privée pour Autopilot.

Selon Microsoft Learn (30/09/2026), le plugin Customer Service de Copilot Cowork permet de déléguer des flux de traitement de dossiers : enquêter, faire remonter les bons enregistrements, coordonner des actions, déclencher les étapes suivantes. Cowork opère dans les permissions déjà en place, sur des données de dossiers en direct, avec des points de contrôle pour approuver les mises à jour avant enregistrement.

Notre lecture : les permissions disent qui a le droit de voir quoi, elles ne disent pas quelle table fait foi. Les points de contrôle permettent à une personne de rattraper une erreur avant l'écriture. Décrire les données sert à réduire le nombre d'erreurs à rattraper.

Voir aussi notre article Copilot Studio face aux agents Dynamics.

Que cela change-t-il pour l'hôtellerie-restauration, la finance, les RH et les écoles ?

Notre lecture, pour les quatre exemples de cette section : en hôtellerie-restauration, la première question est de savoir quel outil fait foi pour un même chiffre, par exemple le chiffre d'affaires d'une journée, entre la caisse et le logiciel de réservation. Un agent qui interroge les deux sans règle écrite peut donner deux réponses défendables.

En finance et comptabilité, l'exemple de LinkedIn parle de lui-même : un indicateur correct pour un suivi peut être inadapté à la clôture. Listez ceux qui servent à la clôture et ceux du pilotage courant, puis dites à l'agent lesquels utiliser pour quoi, et à partir de quelle date une clé est valable.

Aux RH, un effectif peut se lire dans le dossier du personnel, dans la paie ou dans un tableau de suivi, avec des périmètres différents. Décrivez quelle source donne l'effectif de référence et quelles données l'agent ne doit pas consulter. Les permissions en place restent un garde-fou.

Dans une école, la liste des inscrits peut différer selon qu'on part du dossier d'admission ou de la base de scolarité. Un agent qui répond à « combien d'élèves en première année ? » doit savoir quelle liste fait foi, et à quelle date.

Par où commencer pour documenter ses données avant de brancher un agent IA ?

Notre lecture : trois questions suffisent pour démarrer, une table à la fois. Quelle table fait foi pour cette notion ? Quels filtres sont obligatoires pour ne pas compter deux fois ? Quelles règles existent déjà, écrites ou connues de quelques personnes seulement ? Ce sont, chez LinkedIn, les définitions métier, les exceptions et les problèmes de qualité.

Cette documentation se rédige avec les personnes qui utilisent les données. Elle se réécrit quand un fait change, comme le recommande liao.gg. Le branchement technique est ensuite un sujet à part : notre guide pour connecter un agent IA par MCP détaille cette étape, et l'intégration de l'IA dans l'ERP cadre la démarche d'ensemble.

Voir aussi : ce que Claude Dashboards demande à vos données.

À suivre ou à ignorer ?

Notre lecture : si vous n'avez ni ERP ni CRM et aucun projet d'agent, vous pouvez ne pas suivre ce sujet. Rien dans ces signaux ne vous demande d'agir cette semaine. Retenez seulement que décrire ses données précède tout branchement.

Si vous utilisez Dynamics 365, suivez-le de près. Ce sont Dynamics 365 Sales et Customer Service que vise l'avis MC1492151 présenté plus haut.

Selon Microsoft Learn (30/09/2026), chaque tâche de Cowork s'appuie sur les données de dossiers Dynamics 365 en direct. Notre lecture : la façon dont vos dossiers et vos champs sont renseignés pourrait donc peser sur ce que ces compétences donnent.

Si un agent est déjà en pilote dans votre ERP ou votre CRM, la documentation des données est le sujet à traiter avant d'élargir. Notre article sur l'IA dans l'ERP, du pilote à la production prolonge ce point.