Cadrer un projet RAG ou d’assistant IA : la checklist

La plupart des projets d’assistant IA qui déçoivent n’échouent pas à cause du modèle. Ils échouent parce que personne ne s’est accordé sur la finalité de l’assistant, parce que les contenus sous-jacents étaient incomplets ou obsolètes, parce que les permissions ont été traitées après coup, ou parce qu’il n’existait aucun moyen de savoir si un changement améliorait ou dégradait les choses. Le choix du modèle compte, mais c’est en général l’une des décisions les plus faciles.

Cette checklist rassemble les questions que nous passons en revue avant de construire un système de génération augmentée par récupération (RAG, pour retrieval-augmented generation) ou un assistant IA sur des données d’entreprise. Servez-vous-en pour préparer un projet interne, pour briefer un prestataire ou pour vérifier qu’une proposition reçue couvre l’essentiel. Vous n’avez pas besoin de toutes les réponses dès le premier jour, mais vous devez savoir lesquelles restent ouvertes.

1. Cas d’usage et critères de réussite#

Mettez ces points par écrit avant que quiconque n’ouvre un notebook ou ne compare des modèles.

• Une mission principale. Nommez la tâche unique que l’assistant doit d’abord bien accomplir, par exemple répondre aux questions produit des agents du support ou retrouver des clauses dans des contrats fournisseurs. D’autres cas d’usage pourront suivre une fois le premier mesuré ; en mélanger plusieurs au départ brouille à la fois les exigences et l’évaluation.
• Les utilisateurs et leur situation. Décrivez qui pose les questions, à quelle fréquence, dans quelle langue et sur quel appareil, et ce que ces personnes font de la réponse. Un expert interne qui vérifie les sources n’a pas les mêmes besoins qu’un client qui agit directement sur la foi de la réponse.
• De vraies questions, avec leurs réponses idéales. Rassemblez 20 à 50 questions réelles issues de tickets, d’e-mails ou d’historiques de chat, et demandez à un expert métier de rédiger la réponse idéale et d’indiquer la source dont elle doit provenir. Cet ensemble définit ce que « bon » veut dire et devient le noyau de votre jeu d’évaluation.
• Hors périmètre et refus. Listez ce que l’assistant ne doit pas faire : donner des conseils juridiques, médicaux ou financiers, répondre au-delà de ses sources, prendre des engagements au nom de l’entreprise. Décidez de ce qu’il doit dire à la place et vers où orienter l’utilisateur.
• Point de référence du processus actuel. Notez comment le travail est fait aujourd’hui, combien de temps il prend, qui s’en charge et ce qu’il coûte. Sans point de référence, « l’assistant aide » est une opinion, pas un résultat.

2. Sources de données#

La qualité des réponses est plafonnée par la qualité et l’accessibilité des contenus qui les sous-tendent.

• Inventaire des sources. Listez toutes les sources que l’assistant doit utiliser : wikis, dossiers SharePoint ou Google Drive, systèmes de tickets, bases de données, PDF, sites web. Pour chacune, notez comment y accéder (API, export, crawl) et si cet accès est autorisé.
• Formats et qualité des documents. Repérez les PDF scannés qui nécessitent une OCR, les tableaux complexes, les formulaires, les diapositives et les images porteuses de contenu essentiel. C’est sur les tableaux et les scans que les pipelines naïfs perdent le plus d’information : échantillonnez-les tôt.
• Responsabilité et fraîcheur. Désignez un responsable pour chaque source et notez à quelle fréquence elle change. Si personne n’est responsable du contenu, personne ne corrigera les mauvaises réponses qui en découlent.
• Doublons, versions et langues. Identifiez les copies obsolètes, les brouillons et les versions parallèles d’une même politique, et décidez laquelle fait foi. Notez les langues des documents comme des questions, car la récupération d’une langue à l’autre doit être testée explicitement.

3. Contrôle d’accès et confidentialité#

Réglez ces points avant que la moindre donnée réelle ne quitte vos systèmes.

• Des permissions appliquées jusque dans la récupération. Si les utilisateurs ne peuvent voir que certains documents, la récupération doit filtrer selon les permissions de l’utilisateur qui pose la question, synchronisées depuis les systèmes sources. Des consignes dans le prompt, ou s’en remettre au modèle pour ne pas divulguer un contenu, ce n’est pas du contrôle d’accès.
• Données personnelles et base légale. Identifiez les données personnelles dans les documents, les questions et les logs, et documentez la base légale au sens du RGPD ainsi que la finalité de leur traitement. Associez votre délégué à la protection des données dès le départ, pas au lancement.
• Contrat avec le fournisseur et localisation des données. Concluez un accord de traitement des données (DPA) avec chaque fournisseur de modèle et d’infrastructure, examinez leurs sous-traitants ultérieurs et vérifiez que le traitement peut rester dans une région de l’UE si vous l’exigez. Obtenez la confirmation écrite que vos données ne servent pas à entraîner les modèles du fournisseur.
• Conservation, journalisation et masquage. Décidez combien de temps les prompts, les passages récupérés et les réponses sont conservés, qui peut les lire et si les données personnelles sont masquées avant la journalisation. Les logs sont nécessaires au débogage et à l’évaluation : l’objectif est une conservation maîtrisée, pas l’absence de logs.

4. Conception de la récupération#

Dans les systèmes RAG, la plupart des mauvaises réponses viennent de la récupération plutôt que du modèle ; pour un corpus restreint et stable, un contexte long avec prompt caching peut remplacer entièrement la récupération (voir RAG vs fine-tuning).

• Un découpage qui suit la structure des documents. Découpez le contenu selon les titres, les sections, les éléments de liste et les limites des tableaux plutôt que selon un nombre fixe de caractères. Conservez le chemin des titres avec chaque segment (chunk), pour qu’un passage garde son sens pris isolément.
• Métadonnées et filtres. Stockez avec chaque segment le titre, la source, la section, la date, la langue, la version et les groupes d’accès. Ce sont les métadonnées qui rendent possibles le filtrage par permissions, les règles du type « dernière version uniquement » et des citations utiles.
• Recherche hybride et reranking. Combinez la recherche par mots-clés pour les termes exacts, comme les codes produit, les références d’articles et les noms, avec la recherche vectorielle sur des embeddings pour le sens, puis reclassez (reranking) l’ensemble des candidats. Testez chaque étape sur vos questions d’exemple au lieu de supposer que les réglages par défaut suffisent.
• Citations obligatoires. Exigez de l’assistant qu’il cite les passages utilisés, avec un lien vers le document source et la section. Les citations permettent aux utilisateurs de vérifier les réponses, et aux relecteurs de voir si une mauvaise réponse vient d’une mauvaise récupération ou d’une mauvaise génération.

5. Choix du modèle et du fournisseur#

Choisissez le modèle une fois que vous disposez d’un jeu d’évaluation, afin que la décision repose sur vos données plutôt que sur des benchmarks génériques.

• Mode d’hébergement. Comparez une API hébergée, des modèles identiques ou similaires dans une région cloud de l’UE, et un modèle open-weight auto-hébergé sur votre propre infrastructure. Chaque option déplace l’équilibre entre qualité des réponses, maîtrise des données, effort d’exploitation et coût.
• Latence et coût par requête. Mesurez le temps de réponse de bout en bout et le coût par question traitée sur vos propres questions d’exemple, en incluant la récupération, le reranking et les tokens d’entrée et de sortie. Le prompt caching et des modèles plus petits pour les étapes simples peuvent modifier sensiblement ces chiffres.
• Solution de repli et dépendance. Prévoyez ce qui se passe quand le fournisseur est indisponible ou retire un modèle : un second fournisseur, un mode dégradé ou un message d’erreur clair. Gardez les prompts, le jeu d’évaluation et la couche de récupération indépendants du fournisseur, pour qu’en changer revienne à modifier la configuration et à relancer une évaluation, et non à tout réécrire.

6. Évaluation#

Si vous ne pouvez pas mesurer la qualité, vous ne pouvez ni l’améliorer ni justifier la décision de mise en production.

• Le jeu d’évaluation avant le développement. Transformez les questions réelles de la section 1 en un jeu d’évaluation versionné, avec les réponses et les sources attendues, et complétez-le par des cas difficiles et des cas limites. Construisez-le avant le premier prototype, pas après la première démo.
• Qualité de la récupération et des réponses. Mesurez séparément si les bons passages ont été récupérés et si la réponse est correcte, complète et fidèle à ces passages. Vérifiez l’exactitude des citations : le passage cité doit réellement étayer l’affirmation.
• Tests de refus et d’injection de prompt. Incluez des questions que l’assistant doit décliner et des questions auxquelles ses sources ne permettent pas de répondre, et vérifiez qu’il le dit au lieu de deviner. Ajoutez des documents et des saisies qui tentent de contourner ses consignes ou d’extraire les données d’autres utilisateurs, et confirmez que ces tentatives échouent.
• Tests de non-régression et revue humaine. Exécutez le jeu d’évaluation complet à chaque changement de prompts, de modèles, de découpage ou de données, et comparez les résultats à ceux de l’exécution précédente. La notation automatisée par un modèle accélère le processus, mais un expert métier doit contrôler régulièrement les résultats par sondage.

7. Intégration et exploitation#

L’assistant doit vivre quelque part, et quelqu’un doit l’exploiter après le lancement.

• Canal et authentification. Décidez où vit l’assistant : un widget sur le site web, Slack ou Microsoft Teams, un outil interne ou un système de tickets existant. Utilisez votre SSO existant, pour que l’identité et les permissions proviennent de la même source que partout ailleurs.
• Relais vers un humain et retours. Définissez comment un utilisateur joint une personne quand l’assistant ne peut pas l’aider, avec transmission de la conversation. Ajoutez de simples boutons de feedback et versez les retours négatifs dans le jeu d’évaluation.
• Modèle de coûts et monitoring. Estimez le coût par requête et par mois, à l’usage attendu comme en pointe, et configurez des alertes budgétaires. Surveillez la latence, les taux d’erreur, les taux de refus et les retours des utilisateurs, avec des logs masqués comme convenu à la section 3.
• Réindexation, responsabilité des contenus et incidents. Automatisez la réindexation lorsque les documents sources changent, suppressions comprises, pour que l’assistant ne cite jamais un contenu retiré. Désignez qui corrige les problèmes de contenu et définissez une procédure d’incident pour les réponses erronées, préjudiciables ou qui divulguent des données, y compris la manière de désactiver rapidement l’assistant.

8. Critères go/no-go#

Convenez des règles de décision avant l’arrivée des résultats, pour que la décision ne se prenne pas sur la foi d’une bonne démo.

• Des seuils fixés à l’avance. Consignez par écrit les niveaux minimaux d’exactitude des réponses et des citations sur le jeu d’évaluation, la latence et le coût par requête acceptables, et une tolérance zéro pour les réponses qui franchissent les limites de permissions. Comparez les résultats au point de référence de la section 1.
• Un pilote limité dans le temps, avec une sortie claire. Menez un pilote avec un petit groupe d’utilisateurs réels pendant une période définie, et une personne nommément désignée pour trancher. Réduire le périmètre ou arrêter est une issue légitime, et bien moins coûteuse que de s’en apercevoir après un déploiement complet.

Comment nous pouvons vous aider#

Si vous souhaitez parcourir cette checklist avec nous, la voie la plus directe est notre AI Proof-of-Value Sprint, un sprint au périmètre fixe. En deux semaines, nous cadrons le cas d’usage avec vous, construisons un prototype RAG ou d’agent sur vos propres données, créons un jeu d’évaluation, préparons un modèle de coûts et livrons un rapport go/no-go que vous pouvez présenter à vos décideurs. Les détails figurent sur notre page Tarifs et dans nos services IA & automatisation.

Avant qu’un seul de vos documents n’atteigne un modèle, nous convenons avec vous du traitement des données ; vous pouvez consulter au préalable comment nous traitons les données de nos clients dans les projets IA. Si vous préférez commencer par un échange, demandez une estimation gratuite et décrivez le cas d’usage que vous avez en tête.