Agent d'IA sur Dust : fiabiliser un agent sur vos données internes

Un agent qui sait ce que votre entreprise sait

La connaissance d'une organisation ne vit pas dans un modèle. Elle est répartie entre une messagerie où se prennent les décisions, un espace documentaire où dorment les versions officielles, un wiki que trois personnes maintiennent, une base de tickets où vivent les vraies questions des clients. Un agent branché sur cet ensemble ne vaut pas par son moteur de raisonnement : il vaut par ce qu'il sait de vous, et par la fiabilité de ce savoir. La décision structurante n'est plus « quel modèle », elle est « quelles sources, avec quels droits ». Arbitrer entre les familles d'outils se traite au moment de choisir une plateforme d'agent IA ; ici, l'outil est retenu, et la question devient ce qu'on lui donne à lire.

Ce qui change quand la connaissance vient de l'intérieur

Un agent ancré sur des sources internes ne répond pas « en général » : il répond sur votre politique de remboursement, votre grille de remises, votre procédure d'escalade. Le gain est réel — 90 % des utilisateurs estiment que l'IA leur fait gagner du temps (McKinsey, 2025) — mais il se déplace : la valeur ne vient plus de la rédaction, elle vient de la recherche supprimée.

La contrepartie explique la plupart des déceptions : la valeur d'un agent dépend moins du modèle que de l'intégration au système d'information. Un moteur excellent branché sur six sources contradictoires produit vite des réponses assurées et fausses ; un moteur ordinaire branché sur trois référentiels tenus à jour rend un service que personne ne conteste.

Quel agent pour quelle équipe, et jusqu'où le laisser aller

Plutôt qu'un catalogue de cas d'usage, une grille suffit. Elle croise trois choses qui se décident ensemble : l'équipe servie, le type d'agent qui lui rend service, le niveau d'autonomie accordé. La quatrième colonne est celle qu'on oublie : les sources qui font autorité changent d'une équipe à l'autre.

Lisez la troisième colonne comme une conséquence de la quatrième : un agent de support va loin parce que ses sources sont closes et relues, un agent de données reste progressif parce que ses définitions bougent encore.

Choisir ses sources : lesquelles font foi, lesquelles restent dehors

C'est la décision qui commande toutes les autres, et c'est celle qu'on expédie. « Connecter tout ce qu'on peut » paraît généreux ; en pratique, chaque source ajoutée augmente la surface d'erreur plus vite que la couverture. Partez donc d'un périmètre de questions, retenez les deux ou trois référentiels qui y répondent, et justifiez chaque source supplémentaire par une question qu'aucune autre ne couvre. Il s'agit ici de connaissance interne : chercher sur le web ouvert et rendre des réponses assorties de citations publiques est le métier d'un agent d'IA comme Perplexity, et les deux ne se gouvernent pas de la même façon.

Arbitrer entre un wiki, une messagerie et une base de tickets

Chaque type de source a une vertu et un vice ; l'arbitrage consiste à savoir lequel vous pouvez encaisser. L'espace documentaire officiel est fiable mais ne dit pas pourquoi une règle existe. Le wiki explique le pourquoi et vieillit sans prévenir. La messagerie contient les décisions réelles, noyées dans des discussions qu'un agent lira comme des décisions. La base de tickets contient les vraies questions, mal formulées. Posez pour chacune quatre questions : qui en est propriétaire, à quelle fréquence elle est revue, ce qu'elle seule contient, et ce qui se produit si l'agent la cite à tort.

La colonne de droite est le critère d'exclusion : une source dont le risque n'est couvert par aucune règle reste dehors.

Données qui changent, sources qui se contredisent

Séparez deux régimes. Les données stables — définitions, procédures, référentiels — supportent une ingestion périodique. Les données temporelles — politiques, offres, règles légales — exigent la version en vigueur : si la plus récente n'est pas accessible, l'agent se trompe avec assurance, et c'est la défaillance la plus coûteuse parce qu'elle ne ressemble pas à une erreur. Traitez donc le grounding comme un contrat : quelles sources font foi, comment elles sont mises à jour, comment l'agent cite ses références internes. La mécanique qui le soutient — découpage, indexation, fraîcheur, récupération — relève d'un agent d'IA en RAG ; ce qui se décide ici est une question d'organisation et de responsabilité.

Reste le cas le plus fréquent, et celui que personne n'instruit : deux sources se contredisent. Trois comportements sont possibles, et il faut en choisir un explicitement, par famille de questions. Trancher suppose une hiérarchie écrite à l'avance — l'officiel l'emporte sur le wiki, qui l'emporte sur la messagerie — et ne vaut que si elle est vraie. Signaler consiste à exposer le désaccord et les deux références : c'est le défaut le plus sûr. Refuser se réserve aux surfaces à risque. Ce choix s'écrit dans les instructions et se vérifie en test.

Les droits d'accès : espaces, rôles et journalisation

Brancher un agent sur des documents internes est d'abord un sujet de confiance : 60 % des salariés se déclarent préoccupés par la confidentialité des données (Hostinger, 2026), un repère qui figure avec ses variantes dans notre relevé de statistiques sur l'IA. Le premier incident — quelqu'un obtient par l'agent un document qu'il n'aurait pas dû voir — coûte des mois d'adoption. Trois décisions se posent ensemble : quelles sources connecter, en priorisant des référentiels qui font autorité ; qui a accès à quoi, par des droits par rôle et des espaces dédiés ; ce qui est journalisé, c'est-à-dire l'entrée, les sources consultées et la sortie.

Droits minimaux et permissions héritées

La règle est simple à énoncer et difficile à tenir : un agent ne doit jamais rendre visible ce que la personne qui l'interroge ne pourrait pas lire elle-même. Cela interdit le raccourci le plus tentant : un compte de service à accès large, qui répond à tout le monde avec la même connaissance. Ce montage transforme l'agent en contournement de vos habilitations, et il le fait silencieusement — rien dans la réponse n'indique que la source était réservée.

La conséquence tient en quatre points : une segmentation par espaces qui reproduit vos périmètres existants ; une minimisation des données, chaque connexion ouverte au strict nécessaire et non à tout un outil ; des revues d'accès périodiques, parce qu'un périmètre accordé pour un pilote survit au pilote ; des scénarios de test de fuite, avec prompts malveillants et confusion de sources. Journalisez qui a demandé quoi, quels documents ont été consultés, ce qui a été produit : sans ce triplet, aucun incident ne s'explique après coup.

Ce qu'on exige au contrat, plutôt que ce que l'éditeur promet

Les pages produit annoncent toutes la sécurité, le chiffrement et la conformité. Ces affirmations ne sont pas opposables ; ce qui figure au contrat l'est. Formulez donc vos exigences avant la démonstration. Quatre se posent sans négociation.

• La non-réutilisation des données : obtenir par écrit que vos contenus n'entraînent aucun modèle, engagement étendu aux sous-traitants.
• La localisation des traitements : où les données sont hébergées, où elles transitent, de quel droit relèvent les demandes d'accès — une clause, pas une case dans une plaquette.
• La révocation des accès : le délai entre le départ d'un collaborateur et la perte de ses droits côté agent, et qui peut couper une connexion en urgence.
• L'export des journaux : récupérer vos traces dans un format exploitable, sur une profondeur suffisante pour un audit.

Demandez enfin à voir un refus en démonstration : un outil qui ne sait pas montrer une action bloquée, sa raison et sa trace ne saura pas non plus expliquer une dérive en production.

Lire, proposer, exécuter : trois niveaux, trois régimes de contrôle

Plus l'agent peut agir, plus il faut distinguer ce qu'il consulte, ce qu'il suggère et ce qu'il déclenche. Confondre ces régimes est l'erreur qui transforme un pilote réussi en incident : on valide l'agent sur sa capacité à répondre, puis on lui ouvre l'écriture sans revoir les contrôles. Les niveaux se posent dans l'ordre, et chacun ajoute une exigence que le précédent ne portait pas.

Quatre niveaux d'action, et la validation qui ne se négocie pas

• Lecture : accès contrôlé aux documents, aux tickets et aux bases internes. Seul niveau qui se déploie sans réunion de sécurité, à condition que les droits soient hérités.
• Proposition : brouillons, listes de contrôle, réponses candidates. Réversible, mais l'agent touche déjà à vos contenus.
• Validation humaine : obligatoire sur le juridique, la finance, la marque et toute action irréversible. Ce périmètre s'écrit une fois et ne se réduit pas sous prétexte que l'agent « se trompe rarement ».
• Exécution : autorisée seulement sur des actions à faible risque, avec logs. Le critère n'est pas la confiance, c'est le coût de l'annulation.

Exigez un réglage de la validation par surface. Un dispositif qui ne la règle que globalement vous oblige à choisir entre bloquer tout le monde et n'encadrer personne : elle finira par sauter en bloc, le jour où elle ralentira une équipe pressée.

Le workflow en cinq temps et les réponses de repli

Un agent d'entreprise exécute une chaîne, pas une conversation. Cinq temps la structurent, et chacun doit être observable : le déclencheur — demande d'un utilisateur, ticket entrant, événement planifié ; la collecte de contexte — documents autorisés, historique utile, rien de plus ; la production — réponse, synthèse, proposition d'action ; le contrôle — liste de vérification, logs, validation humaine quand la surface l'exige ; puis l'exécution, si elle est autorisée, et sa journalisation. Chaque workflow porte des limites explicites : périmètre de sources, étapes obligatoires, point d'arrêt avant toute action irréversible.

Préparez enfin les réponses de repli, qui sont la marque des agents qu'on garde en production : « je ne sais pas », « je dois escalader », ou « voici les documents à vérifier ». La troisième est propre à un agent ancré sur des documents internes, et c'est souvent la plus utile : elle ne prétend pas répondre, mais elle rend la main avec de quoi trancher en deux minutes.

Spécifier et tester : ce que le low-code n'exempte pas

Configurer un agent sans code raccourcit la mise en route, pas la spécification : plus vous autorisez l'agent à agir — écrire, router, publier —, plus vous devez formaliser les cas limites et tester. Ce qui accélère : gabarits, instructions réutilisables, connecteurs standard, itérations rapides. Ce qu'il faut spécifier : la définition de « bon », les règles de ton, les sources autorisées, les seuils d'escalade. Ce qu'il faut tester : données obsolètes, permissions, contenus sensibles, conflits entre sources.

La séquence de création en cinq temps

Un agent performant n'est pas « généraliste » : vous lui assignez un rôle, des objectifs, des contraintes, et des critères de qualité. La séquence qui tient est toujours la même.

• Définir le rôle et l'objectif : ce que l'agent est censé faire, sur quel périmètre, avec quel objectif mesurable — temps gagné, réduction d'erreurs, taux d'escalade.
• Rédiger les instructions et les contraintes : ce qu'il ne doit jamais faire — inventer une politique, agir sans validation, exposer une donnée sensible — et quand il escalade.
• Connecter les sources retenues, avec les droits minimaux nécessaires, sans périmètre « au cas où ».
• Fixer des sorties stables : formats constants, citation systématique des documents consultés.
• Tester sur un jeu de cas réels, puis activer une validation humaine avant toute action sensible.

La deuxième ligne décide de tout. Un agent dont les interdits ne sont pas écrits n'a pas de garde-fous : il a des habitudes, et elles changent au prochain changement de modèle.

Les tests qui doivent échouer

Un jeu de tests fait de questions normales montre seulement que l'agent fonctionne quand tout va bien. La recette utile est faite de cas « pièges », construits pour provoquer un échec propre, et rejoués à chaque élargissement du périmètre.

• Informations contradictoires : deux documents qui disent l'inverse. L'agent doit appliquer le comportement choisi — trancher, signaler ou refuser —, pas en improviser un troisième.
• Documents périmés : une ancienne version laissée dans le périmètre. L'agent doit citer la version en vigueur, ou reconnaître qu'il ne sait pas laquelle l'est.
• Permissions : une question posée par un profil qui n'a pas accès à la source qui y répond. La bonne réponse est un refus explicite, pas une réponse évasive tirée du document interdit.
• Fuite et confusion de sources : une demande construite pour extraire un contenu réservé, ou pour faire passer une source externe pour interne.

Chaque test porte un résultat attendu écrit à l'avance, sinon la relecture devient une appréciation. Et le critère se formule en négatif : on ne cherche pas la meilleure réponse, on cherche l'absence de réponse fausse et assurée.

Gouverner l'agent et le faire adopter

Un agent d'entreprise ne « remplace » pas un process : il l'exécute plus vite. Encore faut-il qu'un process existe et que quelqu'un en réponde. La gouvernance tient en quatre questions : qui crée, qui valide, qui audite, qui coupe l'agent en cas d'incident. Quatre rôles y répondent, et le deuxième est celui qu'on oublie : un propriétaire métier, qui décide de ce que l'agent fait ; un propriétaire des données, qui répond des sources connectées et de leur fraîcheur ; un référent sécurité, qui arbitre les périmètres ; des relecteurs, qui valident les surfaces à risque. S'y ajoutent des politiques écrites — sources autorisées, règles de publication, escalades — et des revues appuyées sur une journalisation exploitable.

La mesure suit la même logique : quatre dimensions, chacune avec un indicateur et ce qu'on cherche derrière. La qualité se lit au taux de réponses validées ou corrigées : on cherche moins d'édition humaine à effort constant. Le risque se lit au taux d'escalade sur cas sensibles ; un taux nul n'est pas une bonne nouvelle, on cherche un agent qui sait « dire stop ». La productivité se lit au temps moyen de traitement : une réduction mesurable, sans perte de qualité. La traçabilité se lit à la complétude des logs : pouvoir auditer. Gardez les attentes sobres : 45 % des entreprises déclarent avoir doublé leur productivité avec l'IA générative (Google & WEnvision, 2025), ce qui situe un ordre de grandeur atteignable, pas un résultat acquis.

Reste l'adoption, qui dépend rarement de la technologie seule : elle dépend de la capacité des équipes à formuler de bons objectifs, à comprendre les limites, et à documenter « ce qui marche ». Formalisez un kit interne : guide d'usage, exemples de demandes, règles de qualité, circuit de retour. C'est là que se situe le frein le plus cité : le manque de compétences internes en IA est désigné comme l'obstacle principal (Bpifrance, 2026).

FAQ sur les agents IA sur Dust et la Dust Platform

Qu'est-ce que Dust ?

Dust est une plateforme d'agents d'IA d'entreprise : elle permet de créer, de déployer et de gouverner des agents spécialisés connectés aux outils et aux connaissances internes d'une organisation. Sa logique n'est pas de fournir un modèle, mais une couche au-dessus des modèles : connecteurs vers les sources internes, espaces de droits, orchestration entre agents et journalisation des usages.

Qu'est-ce que la Dust Platform et que couvre-t-elle exactement ?

Elle couvre trois briques. Une couche de contexte, qui raccorde l'agent aux sources internes et gère ce qu'il a le droit de lire. Une couche d'outils, qui lui permet d'agir au-delà de la réponse textuelle. Une couche d'entreprise : identités, espaces de permissions, rôles et journaux. Ce qu'elle couvre ou non pour vous se vérifie au contrat, pas sur une page produit.

Comment créer un agent sur Dust ?

En cinq temps : définir le rôle et l'objectif mesurable, rédiger les instructions et les interdits, connecter les sources retenues avec les droits minimaux nécessaires, fixer des formats de sortie stables avec citation des documents consultés, puis tester sur un jeu de cas réels avant d'activer une validation humaine sur les actions sensibles. La configuration prend peu de temps ; la spécification en prend beaucoup.

Quels cas d'usage sont les plus pertinents en B2B ?

Ceux qui combinent trois conditions : du volume, de la répétition et un besoin de contexte interne. En pratique : réponse et routage au support, briefs et contrôle qualité en marketing, préparation de rendez-vous et réponses à appels d'offres côté ventes, requêtes guidées et reporting côté données. Le critère commun n'est pas le métier, c'est l'existence de sources internes tenues à jour.

Dust convient-il à une approche low-code pour des agents d'entreprise ?

Oui, la configuration ne suppose pas d'écrire du code, et des profils métier peuvent piloter des comportements avancés. Mais dès que l'agent agit — écrit, route, modifie —, la qualité dépend de la précision des règles, des tests et de la gouvernance. Le low-code raccourcit la mise en route ; il n'exempte d'aucune spécification.

Quels prérequis de données et de droits d'accès avant de connecter vos sources ?

Trois clarifications préalables : quelles sources font foi, qui a accès à quoi, et quelles données sont temporelles donc à maintenir à jour. Posez ensuite des droits granulaires par espace et par rôle, en reproduisant vos habilitations existantes plutôt qu'en créant un accès de service trop large. Vérifiez enfin que la journalisation couvre l'entrée, les sources consultées et la sortie.

Comment réduire les hallucinations et fiabiliser les réponses d'un agent ?

En combinant quatre choses : limiter les sources à des référentiels officiels et versionnés, forcer la citation des documents consultés, créer des tests « pièges » avec informations contradictoires, documents périmés et permissions, et activer une validation humaine sur le juridique, la finance, la marque et les actions irréversibles. Soignez surtout la fraîcheur : une donnée périmée produit une réponse fausse et assurée.

Quels indicateurs suivre pour mesurer un agent ?

Quatre suffisent, à condition de savoir ce qu'on cherche derrière chacun : le taux de réponses validées ou corrigées, pour mesurer moins d'édition humaine à effort constant ; le taux d'escalade sur cas sensibles, pour vérifier que l'agent sait s'arrêter ; le temps moyen de traitement, pour une réduction sans perte de qualité ; la complétude des logs, pour pouvoir auditer.

Quels sont les risques principaux et comment les limiter ?

Quatre risques dominent : l'exposition de données que l'utilisateur n'aurait pas dû voir, la non-conformité, les réponses fausses mais crédibles, et les actions automatiques erronées. Les contre-mesures sont connues : permissions héritées et minimales, segmentation par espaces, journaux d'audit exportables, scénarios de test de fuite, et validation humaine sur toute action irréversible.

Comment déployer progressivement : pilote, élargissement, industrialisation ?

Démarrez sur un périmètre borné : un flux, une équipe, deux ou trois sources. Stabilisez d'abord les tests, les indicateurs et les règles de validation, puis élargissez source par source, en rejouant les cas « pièges » à chaque ajout. L'industrialisation vient en dernier, quand les rôles sont tenus et que les revues d'accès sont devenues une routine, pas un projet.

Comment comparer Dust avec les alternatives sans se tromper de critères ?

En comparant des capacités opérationnelles, pas des promesses de modèle : connexion aux données et respect des droits, orchestration, gouvernance d'entreprise, évaluation, adoption par les métiers. Ces critères se pèsent différemment selon la famille d'outils visée, et l'arbitrage entre familles précède toujours le choix d'un produit : c'est la grille de sélection d'une plateforme d'agent IA qui le porte, pas la fiche d'un outil.

Continuez votre lecture

• Le frein n'est pas l'outil mais la compétence interne : si vos équipes ne savent pas quoi demander à l'agent, les critères d'évaluation d'une formation à l'agent d'IA vous diront quoi exiger d'un programme.
• Votre premier agent est un agent de support et vous cherchez où s'arrête l'automatisation : périmètre automatisable, conception du transfert vers un humain et indicateurs de résolution sont traités sur l'agent d'IA de service client.
• Les sources sont choisies et il reste à les raccorder : connecteurs, échanges de données et reprise sur erreur relèvent de l'intégration d'un agent d'IA.
• Le pilote a tenu et la question devient celle du déploiement complet : permissions à l'échelle, indicateurs et coût complet de possession sont le sujet de l'agent d'IA en entreprise.