Cahier des charges d’un assistant RAG : les décisions à prendre avant le devis

1. Partir d’une tâche, puis définir la réponse attendue

« Avoir un chatbot interne » ne permet pas de comparer deux propositions. « Aider l’équipe support à retrouver une procédure valide et à citer son numéro de version » décrit une tâche que l’on peut essayer. Indiquez qui pose la question, dans quel outil, à quel moment et ce que la personne fait ensuite de la réponse.

Le RAG associe une recherche d’information à une génération de texte. Cette approche est notamment formalisée par les travaux de Lewis et ses coauteurs. Elle ne garantit pas qu’une réponse soit exacte : il faut vérifier les documents retrouvés, leur interprétation et la façon dont les sources sont présentées.

2. Décrire les documents réellement disponibles

Préparez un inventaire : emplacement, format, volume approximatif, fréquence de modification et personne responsable. Un PDF scanné, un tableau et une page de documentation structurée ne demandent pas la même préparation. Un échantillon représentatif doit inclure les documents difficiles, pas seulement ceux qui fonctionnent bien en démonstration.

• Sources : dossiers partagés, GED, pages internes ou données accessibles par API.
• Qualité : scans, tableaux, doublons, documents incomplets et langues utilisées.
• Versions : règle permettant de choisir un document à jour et de retirer un contenu périmé.
• Synchronisation : délai attendu entre une modification et sa prise en compte par l’assistant.
• Responsabilité : équipe qui valide les sources et traite les erreurs signalées.

Demandez une restitution des erreurs d’import. Un fichier ignoré silencieusement peut donner l’impression que l’information n’existe pas.

3. Faire respecter les accès avant la génération

Le cahier des charges doit distinguer les profils utilisateurs et leurs documents autorisés. Prévoyez des essais avec plusieurs comptes : le contenu restreint ne doit apparaître ni dans la réponse, ni dans une citation, ni dans un extrait de recherche. Définissez également le comportement attendu quand une permission est retirée.

Les documents récupérés peuvent contenir des instructions malveillantes. L’OWASP décrit ce risque d’injection indirecte et rappelle que le RAG ne le supprime pas. Le contrôle des autorisations doit être assuré par l’application, avec des outils limités au besoin et une validation pour les actions sensibles.

Listez les lieux de traitement, les prestataires techniques, les journaux conservés et les personnes autorisées à les consulter. Ces choix doivent être validés avec les responsables concernés selon la sensibilité des documents.

4. Préciser comment l’assistant rejoint vos logiciels

Choisissez le point d’entrée utile : portail interne, application métier, CRM ou interface dédiée. Décrivez l’authentification, les connecteurs nécessaires et la façon de remonter un problème. Un assistant en lecture seule et un agent qui modifie un dossier ont des périmètres différents.

Pour toute écriture, précisez les champs modifiables, l’utilisateur responsable, la validation requise et la méthode de reprise après échec. Définissez aussi le comportement en cas d’indisponibilité d’une API, de document supprimé ou de question envoyée deux fois.

Ces choix rejoignent le cadrage d’une intégration CRM/ERP et API : la réponse de l’IA doit s’insérer dans les règles de votre métier.

5. Définir une recette avant de développer

Constituez un jeu de questions à partir du travail réel, accompagné des sources et résultats attendus. Réservez une partie des questions à l’évaluation finale pour éviter de juger uniquement des exemples utilisés pendant les réglages. La grille ci-dessous est un point de départ proposé par Codialis ; les seuils d’acceptation se fixent selon le risque et l’usage.

Séparez la qualité de recherche et celle de la réponse : retrouver le mauvais passage et mal interpréter le bon passage ne se corrigent pas de la même manière. Mesurez aussi les délais, les coûts d’usage et les corrections humaines nécessaires. Un score de démonstration unique ne suffit pas.

6. Comparer les devis sur un périmètre commun

Demandez des postes distincts pour le cadrage, la préparation documentaire, les connecteurs, les droits d’accès, l’interface, les tests et l’exploitation. Séparez le coût de mise en place des coûts récurrents : hébergement, appels au modèle, stockage et maintenance.

Pour chaque proposition, vérifiez les hypothèses de volume, le nombre d’utilisateurs, les sources incluses, les exclusions et les livrables. Précisez qui conserve le code, la configuration, les jeux de tests et la documentation. Demandez comment changer de fournisseur ou arrêter le service en récupérant les éléments nécessaires.

Un prix ou un délai sans ces hypothèses ne permet pas une comparaison fiable. La page d’intégration IA de Codialis présente les dimensions à cadrer pour un projet LLM ou RAG.

Un modèle court à compléter avec votre équipe

Commencez par remplir ce modèle avec un utilisateur métier et la personne responsable des données. Les zones encore inconnues deviennent des questions de cadrage, plutôt que des hypothèses cachées dans un devis.