L’ambition était séduisante : un agent d’intelligence exécutive capable de fournir aux dirigeants des analyses personnalisées, des tableaux de bord dynamiques et des présentations pour le comité de direction. L’idée était simple : connecter directement l’IA à la base de données pour qu’elle puisse interroger les données, générer des visualisations et actualiser automatiquement les tableaux de bord. Le résultat ? Une solution rapide, sans embauche supplémentaire. Sauf que cela ne fonctionnait pas. Les chiffres produits n’étaient pas fiables, obligeant les analystes à intervenir. Le nombre de tickets Jira a augmenté au lieu de diminuer, et l’adoption est restée bien en dessous des objectifs.

Les agents IA interviennent dans différents systèmes pour accomplir des tâches concrètes. Ils interrogent des bases de données, appellent des API et explorent des documents. Leur valeur ajoutée réside dans leur capacité à résoudre les conflits, interpréter les ambiguïtés et fournir des résultats. Les agents les plus performants accomplissent ces tâches sans intervention humaine. C’est aussi là que réside le danger.

La fiabilité des faits, enjeu crucial

Les agents IA non supervisés doivent répondre avec précision aux questions factuelles. Que ce soit en analytique, en vente ou en service client, les faits ne sont pas subjectifs. Leur exactitude est la clé de la confiance. Ce n’est pas un problème d’hallucination : l’agent ne fabrique pas de réponse, il prend une décision sur des données qu’il n’avait pas l’autorité d’interpréter.

L’importance de la supervision humaine

Le modèle « Human-in-the-loop » (HIL) est devenu une norme pour les applications IA, particulièrement dans les environnements réglementés. Ces applications, souvent internes, améliorent l’efficacité des équipes, réduisent les coûts et accélèrent les processus. Par exemple, en développement logiciel, les ingénieurs révise, testent et valident le code avant sa mise en production.

Cependant, il existe des cas où le HIL n’est pas une option, et où la confiance est primordiale. Par exemple, un agent de service client répondant à des questions sur le compte d’un client, un chatbot d’analytique intégré rapportant le revenu annuel récurent à un client, ou un agent d’intelligence exécutive insérant un chiffre dans une présentation pour le comité de direction. Les conséquences d’une erreur sont réelles : un ticket de support, un client perdu ou une perte de crédibilité auprès du comité.

Dans ces trois cas, la personne recevant la réponse ne peut pas la vérifier. Ajouter un humain dans la boucle annulerait la valeur de l’application.

Résoudre les conflits avant l’agent

Nous avons construit un système à quatre agents capable d’agir au nom d’un vendeur et de répondre aux questions des clients dans un contexte de marketplace. Les agents avaient besoin de données sur le vendeur et le client pour fournir des réponses personnalisées. Le système était non supervisé, mais les données provenaient d’API dispersées et silotées. Par exemple, l’adresse d’un client pouvait être stockée en plusieurs endroits, et ces systèmes pouvaient se contredire. Les agents devaient interroger plusieurs API et décider quelle valeur était correcte. Le résultat était peu fiable : la même question pouvait produire une réponse différente lors de sessions différentes.

La solution a été de résoudre les conflits avant que les agents ne voient les données. Nous avons mis en place une logique métier qui réconciliait les enregistrements bruts et chargeait le résultat dans un feature store. L’adresse, le nom et le budget du client avaient désormais une seule valeur. Les agents ont cessé de choisir, et le système est devenu fiable.

Choisir le bon document avant l’agent

Le même problème s’est posé avec les données non structurées. Les avis et les conversations passées avec les clients étaient stockés dans une base de données vectorielle et récupérés via le Retrieval-Augmented Generation (RAG). Les données étaient riches et contenaient souvent ce dont un client avait besoin, mais plusieurs sources pouvaient se contredire. Parfois, les informations étaient obsolètes : les lieux déménagent, les informations de parking changent, les horaires de transport aussi. D’autres fois, ce qui était correct pour un client ne l’était pas pour un autre : les instructions pour quelqu’un arrivant en avion ne sont pas les mêmes que pour quelqu’un arrivant en bus, et les deux sont correctes.

Nous avons donc construit un outil de récupération qui résolvait le conflit avant que l’agent ne voie les résultats. Nous avons classé les sources en fonction de la conversation avec le même client, puis la même région, puis tout client, avec une pondération par actualité.

En résumé, pour les systèmes de production où la confiance est essentielle, la réponse doit être résolue une fois et réutilisée, pas régénérée à chaque demande.