Leaders d’opinion

La résolution d’entité devient une infrastructure d’IA, et non une opération de nettoyage de données

Publié le 15 juin 2026

Par

Steven Renwick, Co-fondateur et PDG, Tilores

Il y a un certain temps, j’ai regardé un agent IA donner une réponse confiante mais erronée pour une raison tout à fait banale. Une entreprise avait deux enregistrements pour le même client corporate. L’un contenait l’ancien nom commercial et un contact financier, tandis que l’autre contenait le nouveau nom légal que l’entreprise avait adopté après une acquisition, ainsi qu’une adresse de facturation différente. L’agent a été posée une question simple : cet compte est-il en bonne standing ? Il a trouvé un enregistrement, n’a pas vu de factures impayées et a répondu oui. Les factures impayées étaient classées sous l’autre nom.

Rien n’a été inventé. Le modèle a raisonné de manière propre sur les données qui lui ont été fournies. Les données se sont simplement avérées décrire deux clients où il n’y en avait qu’un dans le monde réel. L’erreur n’était pas dans le modèle de langage. Elle était dans la jointure.

J’en suis venu à penser que c’est l’un des risques les plus sous-estimés dans l’IA d’entreprise, et l’un des moins discutés. Nous parlons sans cesse de la précision des modèles, de la conception des invites et de la gouvernance. Nous parlons beaucoup moins de savoir si un système sait réellement quel client, fournisseur ou compte réel il traite. Cette question a un nom. Il s’agit de la résolution d’entité, et après soixante ans en arrière-plan, elle se transforme tranquillement en une pièce d’infrastructure vivante.

Le problème a changé de temps

Pendant la majeure partie de sa vie active, “ces deux enregistrements sont-ils la même entité ?” était une question de nettoyage. Vous l’exécutez par lots, selon un calendrier, quelque part à l’intérieur d’un programme de gestion des données maîtres, d’un entrepôt ou d’un pipeline d’analyse. Ce n’était jamais parfait, mais c’était survivable, car la sortie était un rapport que quelqu’un lisait la semaine suivante. Si deux enregistrements pour le même fournisseur n’étaient pas fusionnés, un chiffre de dépenses sortait légèrement faux, un analyste le remarquait et il était corrigé dans la prochaine exécution. Le système avait un jeu dedans. Le temps absorbait les erreurs.

Un agent IA supprime ce jeu. Il change le temps de la question de “éventuellement” à “maintenant”. Lorsqu’un agent est sur le point d’approuver un remboursement, de router un cas, de mettre à jour un profil ou de répondre à une question de conformité, l’entité résolue ne nourrit plus un tableau de bord. Elle nourrit une action. Le coût d’une jointure incorrecte passe d’un chiffre légèrement faux à quelque chose qui se produit dans le monde, immédiatement, et souvent sans aucun humain dans la boucle pour le rattraper.

C’est le déplacement qui vaut la peine de s’y asseoir. Le problème sous-jacent est ancien et bien compris. Ce qui est nouveau, c’est que nous l’avons connecté directement à des systèmes qui agissent seuls.

Un problème de statistiques des années 1960

La résolution d’entité n’est pas arrivée avec les grands modèles de langage. Elle est arrivée avec les cartes perforées. En 1959, H. B. Newcombe et ses collègues ont publié un court article dans Science sur le raccordement automatique des dossiers vitaux, décrivant comment un ordinateur pouvait décider si un dossier de naissance et un dossier de mariage faisaient référence à la même personne. Une décennie plus tard, Ivan Fellegi et Alan Sunter ont donné à l’idée une théorie mathématique formelle, définissant les trois résultats que tout système de correspondance produit encore aujourd’hui : un lien, un non-lien et un lien possible qui nécessite une révision humaine.

Il y a un détail dans cette lignée qui vaut la peine de s’y attarder, car c’est la partie que les gens se trompent le plus souvent. Le raccordement d’enregistrements n’a jamais été qu’une correspondance exacte sur une adresse e-mail ou un ID partagé. Dès le début, c’était probabiliste. Il a pesé les preuves que deux enregistrements étaient d’accord sur un nom de famille, une date, un lieu, et a produit un score, car les données saisies par l’homme sont désordonnées et les clés exactes échouent constamment. La résolution d’entité moderne fonctionne encore de cette façon. Elle combine des règles déterministes, où un identifiant stable partagé est décisif, avec des correspondances probabilistes et floues basées sur l’apprentissage automatique qui gèrent les fautes de frappe, les surnoms, les champs transposés, les abréviations et la douzaine de petites façons dont la même personne ou entreprise apparaît différemment dans les systèmes. Un bon examen du domaine trace une ligne ininterrompue des dossiers vitaux des années 1950 aux méthodes de regroupement et d’apprentissage automatique utilisées aujourd’hui.

Ce qui a vraiment changé, c’est quand nous avons besoin de la réponse. Les chercheurs écrivaient sur la résolution d’entités au moment de la requête, plutôt que purement à l’avance, bien avant la vague actuelle d’IA. À l’époque, c’était une optimisation intéressante. Maintenant, c’est plus proche d’une exigence.

Pourquoi les agents la transforment en infrastructure

La plupart des systèmes d’IA d’entreprise ne répondent pas à partir de la mémoire du modèle. Ils récupèrent. Le modèle popularisé sous le nom de génération augmentée de récupération a un agent qui récupère le contexte pertinent au moment de la question et raisonne à ce sujet. C’est, dans l’ensemble, une bonne chose. Cela ancre les réponses dans vos données plutôt que dans la formation du modèle.

Cependant, cela comporte une conséquence qui est facile à manquer. L’agent hérite de ce que la récupération lui donne. Si la récupération retourne un client fragmenté, trois enregistrements partiels qui n’ont jamais été connectés, l’agent raisonne sur trois clients. Si la récupération retourne une fusion incorrecte, deux entreprises différentes fusionnées en un seul profil, l’agent raisonne sur une seule. L’ambiguïté déjà présente dans vos systèmes source est transmise directement et présentée au modèle comme un fait établi. Le modèle n’a aucun moyen de savoir que la jointure était incorrecte, pas plus que vous en lisant un résumé propre d’enregistrements que vous n’avez jamais vus.

L’agent que j’ai regardé n’avait pas besoin d’un modèle plus intelligent. Il devait savoir que deux noms étaient un client avant de pouvoir être certain. Lorsque nous donnons à ces systèmes une autorité réelle pour agir, cette discipline silencieuse de soixante ans cesse d’être un nettoyage et commence à être portante.

Le fossé de préparation que personne ne nomme précisément

L’industrie sent déjà que quelque chose manque ici. L’indice de préparation à l’IA de Cisco 2025 a constaté que 83 % des organisations prévoient de déployer des agents autonomes, tandis que seulement environ un tiers estiment que leur infrastructure est vraiment prête pour eux, et seulement environ un quart se sentent équipés pour contrôler et gérer ce que ces agents font réellement. L’enquête la plus récente de McKinsey sur l’état de l’IA décrit un fossé similaire dans l’autre sens : environ 88 % des organisations utilisent désormais l’IA dans au moins une fonction, mais la plupart n’ont pas encore étendu son utilisation à l’ensemble de l’entreprise.

Lorsque les gens expliquent ce fossé, ils ont tendance à utiliser deux mots : qualité des données et gouvernance. Les deux sont importantes, et aucune n’est facultative. Mais il y a une question plus étroite qui se cache en dessous d’elles, que des données propres et bien gérées ne répondent pas seules. Le système peut-il dire quelle entité réelle un enregistrement donné fait référence, dans tous les endroits où cet enregistrement vit, en ce moment ? Vous pouvez détenir des données de haute qualité dans chaque système individuel et toujours échouer à ce test, car l’échec ne vit pas à l’intérieur d’un système. Il vit dans les espaces entre eux, où le même client porte trois visages légèrement différents.

Que vérifier avant de laisser un agent agir

Si vous traitez la résolution d’entité comme une infrastructure vivante, vous pouvez l’inspecter comme une infrastructure. Les modes de défaillance opérationnels sont spécifiques et testables : des identités divisées qui devraient être une seule, des fusions incorrectes d’enregistrements qui devraient rester séparés, des règles de survie obsolètes qui continuent de promouvoir une adresse supplantée, des identificateurs persistants manquants, et des agents qui héritent de l’ambiguïté des systèmes source comme si c’était une vérité établie.

Un test de préparation pratique n’exige pas de nouveau modèle ou de nouvelle catégorie de fournisseurs. Rassemblez un ensemble d’entités que vous comprenez réellement. Exécutez-le sur le même chemin de récupération que votre agent utilise, et non sur une copie propre construite pour la démonstration. Ensuite, mesurez les choses qui décident réellement des résultats : combien de fusions incorrectes et de divisions incorrectes, comment le système gère l’ambiguïté réelle, où se situent ses seuils de confiance, quand il passe à un humain au lieu de deviner, et comment il passe proprement à vos contrôles de données maîtres et de gouvernance existants. Si une équipe ne peut pas répondre à ces questions, l’agent agit sur une identité qu’il ne peut pas vérifier, et la confiance dans sa sortie est mal placée.

Aucun de cela ne remplace la gestion des données maîtres, la gouvernance, les plates-formes de données client ou l’entrepôt. Ceux-ci répondent à des questions différentes et restent nécessaires. La gouvernance décide ce qu’un agent est autorisé à faire. La résolution d’entité décide qui, ou quoi, il le fait. La première est mature dans la plupart des grandes organisations. La seconde est la couche que beaucoup sont sur le point de découvrir qu’ils ont besoin à côté d’elle, en temps réel, au moment où ils laissent un agent agir plutôt que conseiller.