Un agent IA ne répare pas une documentation floue. Il la rend plus visible, plus rapide à consulter, parfois plus convaincante, y compris quand elle est contradictoire, obsolète ou trop ouverte.
Avant de brancher un agent IA support sur une FAQ, des procédures, un CRM ou un historique de tickets, décidez quelles sources il peut lire, dans quel contexte, avec quels droits et avec quelle règle d’arrêt. Le choix du modèle vient après.
La base de connaissances n’est pas une archive plus grosse. C’est un périmètre de travail que l’agent peut consulter, citer, suivre et abandonner quand le risque monte.
Verdict de cadrage Si une source n’a pas de propriétaire, pas de date, pas de droit clair ou pas de cas d’usage précis, elle n’est pas prête pour un agent IA. Elle peut rester utile à l’équipe, mais elle doit être nettoyée, restreinte ou exclue du prototype.
Commencer par la décision, pas par les documents
Une base de connaissances pour agent IA doit servir une décision ou une réponse réelle. Sinon, elle devient vite un grand dossier indexé dans lequel le modèle cherche de quoi produire une phrase plausible.
Formulez d’abord le cas d’usage :
Quand [demande fréquente] arrive, l’agent lit [sources autorisées], prépare [réponse ou action], puis s’arrête si [condition de risque].Exemples génériques : répondre à une question de facturation simple, retrouver une procédure interne, proposer une réponse support à valider, classer une demande entrante, préparer un résumé de dossier avant intervention humaine.
Cette phrase force l’équipe à nommer le périmètre. Elle évite de donner à l’agent “toute la documentation” alors que l’objectif réel tient souvent dans quelques sources fiables. Pour le déploiement d’une IA générative, la CNIL recommande de partir d’un besoin concret et d’encadrer les usages autorisés et interdits.1
Si le besoin n’est pas clair, commencez par un cahier des charges d’agent IA support. La base documentaire viendra ensuite, au service du périmètre.
Inventorier les sources sans tout autoriser
Les sources possibles sont nombreuses : FAQ support, procédures internes, fiches produit, politiques de remboursement, modèles d’email, bases clients en lecture, pages d’aide, historiques de tickets expurgés des données inutiles, règles métier, contrats types, documentations techniques.
Mais “disponible pour l’équipe” ne veut pas dire “lisible par l’agent”. Un document peut être utile à un manager et dangereux dans une réponse automatisée. Un historique de tickets peut aider à repérer des formulations, tout en contenant des données personnelles ou des exceptions qui ne doivent pas devenir une règle.
Pour chaque source, gardez une fiche courte :
Usage
Quelle demande fréquente cette source aide-t-elle à traiter ? Si la réponse est vague, la source n’a pas sa place dans le premier périmètre.
Propriétaire
Qui peut corriger le document quand l’agent ou l’équipe repère une erreur ? Sans propriétaire, la base se dégrade silencieusement.
Version
La source est-elle à jour, remplacée, ou contradictoire avec une autre règle ? Une ancienne procédure bien écrite reste une mauvaise source.
Droits
L’agent a-t-il le droit de lire cette source pour ce canal, cette équipe et ce type de demande ? Le périmètre d’accès doit rester minimal.
Risque
Que se passe-t-il si l’agent utilise mal cette source : gêne mineure, erreur client, donnée sensible, engagement commercial, décision irréversible ?
Arrêt
Dans quels cas l’agent doit-il refuser, demander une clarification ou transmettre le dossier à un humain ?
Cette fiche transforme un stock de documents en matière exploitable pour un prototype. Elle permet aussi de repérer les sources que personne ne sait maintenir ou autoriser.
Nettoyer les contradictions avant d’indexer
Un agent peut retrouver une information plus vite qu’un humain. Il ne sait pas forcément arbitrer deux règles contradictoires si personne ne lui dit laquelle fait foi.
Les cas à traiter avant l’indexation :
- Deux versions d’une même procédure: garder la version qui fait foi, archiver l’autre, noter le propriétaire.
- Règle métier implicite: écrire la règle au lieu de compter sur “l’équipe sait comment faire”.
- Document sensible mais peu utile: exclure du premier périmètre plutôt que multiplier les exceptions.
- Source utile mais incomplète: la garder seulement si l’agent sait demander une clarification ou escalader.
- Historique de tickets: retirer les données inutiles, limiter les accès et sélectionner des cas représentatifs au lieu de tout verser dans la base.
La CNIL rappelle que les systèmes d’IA générative peuvent produire des résultats inexacts tout en paraissant plausibles.1 Une source floue aggrave ce risque : l’agent ne part pas d’un vide, mais d’un mauvais signal.
Gérer les droits comme une partie du produit
Les permissions ne sont pas un détail technique à régler à la fin. Elles déterminent ce que l’agent peut savoir, répondre et tracer.
Un agent support exposé à un client ne devrait pas lire les mêmes informations qu’un agent interne qui prépare un brouillon pour un collaborateur. Une base RH, une facture, un échange commercial ou une procédure de remboursement n’ont pas le même niveau de risque. Même dans une PME, tout document interne n’a pas vocation à devenir une source automatique.
La sécurité ne se limite pas au modèle. Pour le développement d’un système d’IA, la CNIL recommande de combiner l’analyse de l’environnement, des infrastructures, des habilitations et des sauvegardes avec celle du développement logiciel, de la maintenance et des risques propres aux composants IA.2 L’ANSSI recommande aussi une posture de prudence lors de l’intégration de l’IA générative dans un système d’information existant.3
En pratique, commencez avec des droits étroits : lecture seule, sources listées, canal limité, logs lisibles, validation humaine sur les sorties sensibles. Si l’agent doit ensuite déclencher des actions dans un workflow automatisé, les droits d’action méritent un cadrage séparé.
RAG : chercher dans une base autorisée, pas “tout savoir”
La génération augmentée par récupération, ou RAG pour Retrieval-Augmented Generation, alimente un modèle d’IA avec des connaissances tirées de bases internes avant la réponse.4 Dit simplement : un composant de recherche sélectionne des passages dans les sources définies, puis le modèle reçoit ces passages comme contexte pour rédiger.
C’est utile, mais ce n’est pas une garantie magique. Le RAG ne remplace pas le tri des sources, les permissions, les tests et les règles d’arrêt. Il aide surtout quand la base est claire : documents à jour, accès cohérents, sources citables, contradictions traitées.
Le bon objectif n’est pas “l’agent connaît toute l’entreprise”. Le bon objectif est plus modeste : sur ce périmètre, il retrouve les bonnes sources, prépare une réponse utile, montre d’où elle vient et s’arrête quand la source manque.
Une source peut-elle entrer dans la base ?
Utilisez cette carte avant d’ajouter une source au prototype. Si une porte échoue, la source ne doit pas forcément disparaître : elle peut être nettoyée, restreinte ou réservée à une validation humaine.
Une base utile n’est pas une archive plus grosse. C’est un périmètre que l’agent peut citer, suivre et abandonner quand le risque monte.
Tester sur des demandes réalistes et désidentifiées
Le prototype doit rencontrer des cas réalistes sans exposer de données inutiles. Partez de demandes dont les noms, coordonnées, identifiants et détails non nécessaires ont été retirés ou remplacés. Ajoutez des exemples de procédures et des situations qui couvrent les cas simples, incomplets, contradictoires et hors périmètre. Si une réidentification reste possible, traitez toujours le jeu de test comme contenant des données personnelles et limitez ses accès.
Le test doit vérifier au moins ceci :
- l’agent utilise uniquement les sources autorisées ;
- il signale quand une source manque ;
- il ne transforme pas une exception passée en règle générale ;
- il affiche ou résume la source utilisée quand c’est utile ;
- il escalade les cas sensibles, contradictoires ou hors périmètre ;
- il garde une trace compréhensible pour relire les erreurs.
Le lien avec la validation humaine est direct. Au lancement, l’agent doit souvent préparer plutôt qu’envoyer. La valeur vient de la vitesse de préparation et de la qualité du dossier transmis, pas d’une autonomie théorique.
Maintenance : la base doit pouvoir vieillir proprement
Une base de connaissances vivante a besoin d’un rythme simple : ajouter, corriger, retirer, relire les erreurs, limiter les accès. Sinon, elle se transforme en dette documentaire branchée sur un agent très sûr de lui.
Gardez une règle de maintenance compréhensible par le métier : qui ajoute une source, qui valide une modification, qui retire un document obsolète, qui lit les erreurs remontées par l’agent, qui peut couper le flux en cas de dérive.
Cette gouvernance n’a pas besoin d’être lourde. Elle doit seulement exister avant que le prototype soit élargi.
Questions fréquentes
Faut-il une base de connaissances parfaite avant de créer un agent IA ?
Non. Il faut un premier périmètre fiable : quelques sources utiles, à jour, autorisées, testées sur des demandes réalistes et désidentifiées, avec des règles d’escalade.
Le RAG supprime-t-il les hallucinations ?
Non. Il peut réduire certains risques en fournissant au modèle des passages issus de sources définies, mais le modèle peut encore mal les interpréter ou répondre au-delà du contexte. Il faut limiter les droits, montrer les sources utiles, tester les réponses et prévoir l’arrêt humain.
Quels documents éviter au départ ?
Les documents obsolètes, contradictoires, sensibles sans utilité claire, sans propriétaire, ou qui créent une décision à risque sans validation humaine.
Comment Last Word cadrerait le chantier
Last Word peut cadrer un agent IA autour de vos sources réelles : périmètre, droits, règles d’arrêt, prototype court, validation humaine et premières boucles testables. Si vous voulez brancher un agent sur vos documents sans créer une boîte noire, commencez par le service agent IA support ou envoyez le contexte via contact.
Sources
Footnotes
-
CNIL, “Comment déployer une IA générative ? La CNIL apporte de premières précisions”, 18 juillet 2024, https://www.cnil.fr/fr/comment-deployer-une-ia-generative-la-cnil-apporte-de-premieres-precisions ↩ ↩2
-
CNIL, “IA : Garantir la sécurité du développement d’un système d’IA”, 22 juillet 2025, https://www.cnil.fr/fr/ia-garantir-la-securite-du-developpement ↩
-
ANSSI / MesServicesCyber, “Recommandations de sécurité pour un système d’IA générative”, 28 avril 2024, https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-pour-un-systeme-dia-generative ↩
-
France Num, “Génération augmentée par récupération (RAG) : guide pour exploiter les données de sa TPE PME avec l’IA générative”, publié le 3 décembre 2024 et mis à jour le 17 août 2026, https://www.francenum.gouv.fr/guides-et-conseils/intelligence-artificielle/recherche-intelligente-et-analyse-documentaire-0 ↩