La résolution d'entités est le problème central des agents IA

Chez Revo AI, nous développons un agent IA ambiant basé sur l'email. Nous avons expliqué pourquoi l'email résout le problème du démarrage à froid pour les agents IA. Cet article traite du défi technique le plus complexe que nous avons rencontré — et pourquoi nous pensons qu'il s'agit du problème le plus difficile de l'IA ambiante en général.

Le problème dont personne ne parle car il n'est pas glamour

La conversation autour de l'IA se focalise sur les modèles. Qualité du raisonnement, fenêtres de contexte, utilisation d'outils, vitesse d'inférence. Tout cela compte. Mais ce n'est pas là que les agents échouent réellement en production.

Les agents échouent sur la résolution d'entités.

La même personne apparaît sous forme de prénom dans Slack, de nom complet dans un contrat, de domaine email dans un fil de discussion, de nom d'entreprise dans un enregistrement CRM et d'ID de compte dans un ticket de support. Un agent opérant dans un contexte professionnel voit tous ces signaux et doit décider, sans halluciner, s'ils font référence à la même entité — et quelle est la relation de cette entité avec tout ce qu'il connaît.

Échouer ici ne fait pas que l'agent dysfonctionner discrètement. Il rédige une réponse en utilisant le langage du mauvais contrat. Il relance le mauvais contact. Il connecte une conversation sensible à quelqu'un qui ne devrait pas la voir. Les échecs de résolution d'entités dans un agent ambiant ne sont pas des problèmes d'UX. Ce sont des risques relationnels et des violations potentielles de la confidentialité.

C'est le problème sur lequel nous avons passé le plus de temps chez Revo AI. Il n'est toujours pas résolu — il est géré. Voici ce que nous avons appris.

Pourquoi la résolution d'entités est structurellement plus difficile pour les agents que pour la recherche ou le CRM

La résolution d'entités n'est pas un nouveau problème. Les moteurs de recherche, les CRM et les entrepôts de données y font face depuis des années. Mais les agents font face à une version plus difficile pour trois raisons.

Le coût de l'erreur est asymétrique. Une mauvaise autocomplétion dans un client email classique est agaçante. Une mauvaise correspondance d'entité dans un agent qui rédige et envoie en votre nom est un risque relationnel. La tolérance à l'erreur est inférieure d'un ordre de grandeur à celle des outils passifs.

Le signal est plus bruité. L'email est informel, incohérent et humain. Les gens font référence à la même entité de dizaines de façons différentes à travers des milliers de messages. Il n'y a pas de schéma. Il n'y a pas de convention de nommage imposée. L'agent doit déduire la structure à partir d'un signal non structuré à grande échelle.

Le graphe est dynamique. Les entités changent. Les gens changent de rôle. Les entreprises sont acquises et les domaines changent. Le graphe d'entités ne peut pas être construit une fois et mis en cache — il doit se mettre à jour continuellement à mesure que de nouveaux messages arrivent et signaler les conflits lorsque le nouveau signal contredit ce qu'il pensait savoir.

Ce que nous avons réellement construit chez Revo AI

Nous maintenons un graphe d'entités vivant qui se met à jour à chaque message traité. Le graphe connecte les personnes, les entreprises, les affaires, les fils de discussion et les outils — résolvant la même entité à travers différentes conventions de nommage et sources de données en temps réel.

Lorsque le graphe rencontre des signaux contradictoires — deux contacts nommés James dans la même entreprise, un domaine qui a changé après une acquisition, un nom qui pourrait plausiblement faire référence à deux personnes différentes — il signale l'ambiguïté au lieu de deviner. Nous traitons l'ambiguïté non résolue comme un état de première classe, pas comme une erreur à supprimer.

Cela nous coûte en couverture d'automatisation. Signaler l'ambiguïté signifie que certaines actions ne sont pas prises automatiquement et remontent pour examen humain. Nous avons fait ce compromis délibérément. L'alternative — deviner et se tromper — produit le genre d'échec qui fait que les utilisateurs désactivent définitivement un agent.

La résolution d'entités doit également se produire dans des limites de confidentialité strictes. Un agent lisant une boîte de réception professionnelle a accès à des informations sensibles sur les clients, les affaires, les équipes et les niveaux organisationnels. Le graphe d'entités doit savoir non seulement comment les entités sont connectées mais ce que l'agent est autorisé à connecter. Le contrôle d'accès au niveau du domaine n'est pas une infrastructure optionnelle — c'est une partie essentielle de la logique de résolution. La résolution d'entités sans contrôles de confidentialité est une responsabilité, pas une fonctionnalité.

Ce que fait réellement l'IA ambiante quand elle fonctionne

La plupart des produits d'IA ambiante sont morts dans l'écart entre "techniquement correct" et "digne de confiance". La partie difficile n'est pas de construire un agent qui peut agir — c'est d'en construire un qui sait quand ne pas agir.

Voici à quoi ressemble un mardi matin lorsque la résolution d'entités fonctionne :

8h14. "Lisa Chen a signalé la clause PI dans le contrat Meridian. Réponse prête avec votre formulation standard du contrat Acme."

8h22. "Pas de réponse de James Park sur le budget T2 (5 jours). Relance rédigée."

9h01. "Sarah a mentionné que la migration est terminée. Trois tickets clients font référence à ce bug. Mises à jour rédigées."

Pour chacune : accepter, refuser ou donner un retour. C'est toute l'interface d'interaction. L'agent planifie le travail. L'utilisateur gouverne la sortie.

La conséquence UX : la confiance se gagne progressivement

Nous avons conçu l'agent Revo AI pour commencer de manière ciblée et gagner sa place vers des actions plus larges. Le premier jour, il fait remonter des choses simples : un suivi oublié, un brouillon pour une réponse en attente, un conflit signalé. Accepter ou ignorer. Pas de configuration, pas de prompt, pas de manuel.

Ce n'était pas le design original. C'était une réponse à l'observation des premiers utilisateurs désactivant un agent techniquement correct mais qui se déplaçait plus vite qu'ils n'étaient prêts à faire confiance. La divulgation progressive n'est pas seulement un modèle UX — c'est comment vous donnez aux utilisateurs suffisamment de temps pour vérifier que la résolution d'entités fonctionne avant que l'agent ne commence à prendre des actions à enjeux plus élevés.

Ce que cela signifie pour l'infrastructure des agents

La résolution d'entités est une infrastructure, pas une fonctionnalité. C'est la couche qui détermine si un agent IA opérant sur un contexte professionnel réel peut être digne de confiance pour agir — ou s'il s'agit d'une démo sophistiquée qui échoue dès que les données deviennent désordonnées.

La plupart des frameworks d'agents la traitent comme un cas limite. Ce n'en est pas un. C'est le problème central. Les agents qui gagneront une utilisation à long terme seront ceux qui le résolvent avec la bonne combinaison d'architecture de graphe, de gestion de l'ambiguïté, de contrôles de confidentialité et de rythme de confiance — pas ceux avec la meilleure inférence.

L'email est l'environnement le plus difficile pour résoudre la résolution d'entités, car les données sont les plus désordonnées et la tolérance aux erreurs est la plus faible. C'est aussi pourquoi la résoudre sur l'email se généralise. L'infrastructure que nous avons construite chez Revo AI pour résoudre les entités dans une boîte de réception professionnelle est la même infrastructure dont tout agent ambiant a besoin pour fonctionner de manière fiable sur des données réelles non structurées.

Si cela vous parle, contactez-nous : mehdi@revo.ai