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

Vous dirigez une équipe marketing, opérations ou SI, et Dust est l'outil retenu pour brancher un agent sur la connaissance de l'entreprise. Cette page s'adresse à ceux qui doivent décider ce que cet agent d'IA sur Dust a le droit de lire et qui y accède.

Elle permet d'arbitrer trois choses : quelles sources font foi, quels droits l'agent hérite de la personne qui l'interroge, et quels tests doivent échouer avant d'élargir son périmètre.

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 vaut par ce qu'il sait de vous, et par la fiabilité de ce savoir.

La décision structurante n'est donc plus « quel modèle », elle est « quelles sources, avec quels droits ». L'agent lui-même reste un agent au sens de notre pilier sur les agents d'IA, avec des droits gradués selon ses quatre niveaux. 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. 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épend moins du modèle que de l'intégration au système d'information. Un moteur excellent branché sur six sources contradictoires produit des réponses fausses et assurées ; un moteur ordinaire branché sur trois référentiels à 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 l'équipe servie, le type d'agent qui lui rend service et 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.

L'autonomie découle des sources : l'agent de support va loin parce que ses sources sont closes et relues, l'agent de données reste progressif parce que ses définitions bougent.

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 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 citer des sources publiques est le métier d'un agent d'IA comme Perplexity, qui ne se gouverne 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 est fiable mais ne dit pas pourquoi une règle existe ; le wiki explique le pourquoi et vieillit sans prévenir ; la messagerie mêle décisions réelles et discussions qu'un agent lira comme des décisions. Avant de connecter une source, posez-lui quatre questions :

• qui en est propriétaire ;
• à quelle fréquence elle est revue ;
• ce qu'elle seule contient ;
• ce qui se produit si l'agent la cite à tort.

Les réponses se résument par type de source ; la dernière colonne sert de 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) demandent la version en vigueur : sinon l'agent se trompe sans que rien dans sa réponse ne ressemble à une erreur, et c'est la défaillance la plus coûteuse.

Traitez donc l'ancrage documentaire 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 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 ; 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 : expose 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, un document obtenu par l'agent sans droit de le 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 silencieux de vos habilitations : rien dans la réponse n'indique que la source était réservée.

Quatre mesures en découlent :

• 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.

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

Les pages produit annoncent toutes la sécurité, le chiffrement et la conformité. Seul ce qui figure au contrat engage l'éditeur. Formulez donc vos demandes 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.
• 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 d'audit.

Pendant la démonstration, faites poser une question par un profil sans accès à la source qui y répond : l'outil doit montrer le refus, sa raison et sa trace, sinon il n'expliquera pas davantage 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 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.

Ce que chaque régime ajoute quand les sources sont internes

L'échelle est celle du pilier, les quatre niveaux de droits d'un agent (lecture seule, écriture contrôlée avec validation humaine, exécution supervisée, autonomie encadrée), détaillée aussi pour les agents d'IA autonomes. Ce qui compte sur Dust, c'est ce que chaque niveau ajoute quand l'agent lit vos documents.

Le périmètre de validation humaine ne se réduit pas sous prétexte que l'agent « se trompe rarement ». Demandez aussi un réglage surface par surface : une validation globale finit par ralentir une équipe pressée, et ce jour-là elle saute en bloc.

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, chacun 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, journaux, validation humaine quand la surface le demande ;
• 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 aussi les réponses de repli, marque des agents qu'on garde en production : « je ne sais pas », « je dois escalader », « voici les documents à vérifier ». La troisième est propre à un agent ancré sur des documents internes : 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 l'agent agit (écrit, route, publie), 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 » : il a 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 fait, sur quel périmètre, avec quel objectif mesurable (temps gagné, erreurs évitées, 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 sans 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. Le critère se formule en négatif : on ne cherche pas la meilleure réponse, on cherche l'absence de réponse erronée énoncée avec aplomb.

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 : 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 le plus souvent laissé vacant :

• 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 la journalisation. La mesure suit la même logique : quatre dimensions, chacune avec un indicateur et ce qu'on cherche derrière.

Gardez les attentes sobres : le gain se constate sur ces quatre indicateurs, flux par flux, pas dans une promesse globale.

L'adoption dépend de la capacité des équipes à formuler de bons objectifs, à comprendre les limites et à documenter « ce qui marche ». Le frein principal est la compétence interne, pas l'outil. Formalisez un kit :

• un guide d'usage ;
• des exemples de demandes qui fonctionnent ;
• des règles de qualité ;
• un circuit de retour vers le propriétaire métier.

Continuez votre lecture

Selon votre situation, l'article suivant du cocon prend le relais :

• Vos équipes ne savent pas quoi demander à l'agent : les critères d'évaluation d'une formation à l'agent d'IA vous diront quoi demander à un programme.
• Votre premier agent est un agent de support : périmètre automatisable, transfert vers un humain et indicateurs de résolution sont traités sur l'agent d'IA de service client.
• Les sources sont choisies, 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, la question devient le déploiement complet : permissions à l'échelle, indicateurs et coût complet de possession sont le sujet de l'agent d'IA en entreprise.

Si votre besoin dépasse la configuration d'un outil du marché, un agent conçu sur vos données et vos règles d'accès relève de notre offre d'IA personnalisée.

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 sert à créer, déployer et gouverner des agents spécialisés connectés aux outils et aux connaissances internes d'une organisation. Elle ne fournit pas 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, à la date de rédaction.

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

La Dust Platform désigne, à la date de rédaction, 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, et une couche d'entreprise (identités, espaces de permissions, rôles, journaux). Ce qu'elle couvre pour vous se vérifie au contrat.

Comment créer un agent sur Dust ?

Un agent sur Dust se crée en cinq temps : définir le rôle et l'objectif mesurable, écrire les instructions et les interdits, connecter les sources retenues avec les droits minimaux, fixer des sorties stables qui citent les documents consultés, puis tester sur des cas réels avant toute action sensible. La configuration prend peu de temps ; la spécification en prend beaucoup.

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

Les cas d'usage pertinents combinent du volume, de la répétition et un besoin de contexte interne : réponse et routage au support, briefs et contrôle qualité en marketing, préparation de rendez-vous et appels d'offres côté ventes, requêtes guidées et reporting côté données. Le critère commun 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. Dès que l'agent agit (écrit, route, modifie), la qualité dépend toutefois 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écèdent toute connexion : quelles sources font foi, qui a accès à quoi, et quelles données sont temporelles donc à maintenir à jour. Posez ensuite des droits par espace et par rôle qui reproduisent vos habilitations existantes, plutôt qu'un accès de service trop large, et vérifiez 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 ?

On fiabilise un agent en limitant ses sources à des référentiels officiels et versionnés, en forçant la citation des documents consultés, en construisant des tests pièges (contradictions, documents périmés, permissions) et en activant une validation humaine sur le juridique, la finance, la marque et les actions irréversibles. La fraîcheur compte le plus : une donnée périmée produit une réponse crédible et pourtant fausse.

Quels indicateurs suivre pour mesurer un agent ?

Quatre indicateurs mesurent un agent d'entreprise : le taux de réponses validées ou corrigées (moins d'édition humaine à effort constant), le taux d'escalade sur cas sensibles (l'agent sait s'arrêter), le temps moyen de traitement (réduction sans perte de qualité) et la complétude des journaux (chaque réponse reste auditable).