Un RAG pour les appels d’offres recherche des passages dans un corpus autorisé, les fournit à un modèle de langage, puis rattache chaque affirmation à sa source. Ce n’est pas « un chatbot branché sur un dossier partagé », mais une chaîne d’ingestion, d’indexation, de recherche, de génération, de citation et de validation humaine.
Bien conçu, ce système accélère l’analyse d’un DCE, la recherche de références et la préparation d’une réponse. Il ne décide pas seul de la conformité, ne transforme pas une archive médiocre en connaissance fiable et n’élimine pas les hallucinations.
Ce que le RAG change dans une réponse à appel d’offres
Le NIST définit le retrieval-augmented generation comme l’association d’un modèle génératif avec un système de recherche ou une base de connaissances : à partir d’une requête, le système retrouve des informations pertinentes et les ajoute au contexte du modèle (définition officielle du NIST).
Pour la requête « quelles références prouvent notre capacité à assurer un support 24/7 ? », le moteur ne doit pas seulement trouver « support ». Il remonte les passages compatibles avec le secteur, la période et les droits de l’utilisateur. Le modèle rédige ensuite avec des citations vérifiables.
Cette approche diffère d’un entraînement du modèle sur vos archives. Les connaissances restent dans un corpus distinct, modifiable et gouvernable. Une référence expirée peut être désactivée sans réentraîner le modèle. Pour structurer ce patrimoine en amont, voyez comment construire une bibliothèque de réponses RFP.
La méthode éditoriale complète est détaillée dans le guide pour bâtir une bibliothèque de réponses AO réutilisable, avec taxonomie, versions et conditions d’emploi.
L’architecture complète d’un RAG pour les appels d’offres
Une architecture robuste sépare le flux documentaire, préparé en continu, du flux de réponse déclenché par une question ou une exigence du DCE.
1. Ingestion et contrôle des documents
Des connecteurs lisent uniquement les emplacements approuvés : GED, SharePoint, CRM, référentiel qualité ou espace projet. À l’arrivée d’un fichier, le pipeline conserve l’identifiant source, la version, le propriétaire, les droits et une empreinte permettant de détecter les doublons.
L’extraction traite PDF natifs, scans par OCR et tableaux. Un contrôle signale les pages vides, caractères illisibles et tableaux mal reconstruits. Un fichier douteux n’entre pas silencieusement dans l’index.
Avant toute indexation, appliquez les règles documentaires : source autorisée, durée de conservation, données personnelles, secret d’affaires, statut validé ou brouillon. Le RAG ne doit pas devenir une copie incontrôlée de tous les lecteurs réseau.
2. Découpage, enrichissement et indexation
Le document est découpé en passages, ou chunks. Un découpage purement fixe risque de séparer une exigence de sa condition, un chiffre de son unité ou une réponse de son titre. Pour un DCE, privilégiez les frontières logiques : article du RC, clause du CCAP, section du CCTP, ligne de tableau et annexe. Ajoutez un léger chevauchement lorsque le sens traverse deux sections, sans dupliquer massivement le corpus.
Il n’existe pas de taille de chunk universelle. Une clause contractuelle courte et un retour d’expérience détaillé n’ont pas la même granularité utile. Testez plusieurs stratégies sur des questions réelles, puis mesurez si le passage contenant la preuve apparaît dans les premiers résultats.
Chaque chunk reçoit un vecteur et des métadonnées : type, secteur, version, validité, langue, lot, confidentialité, groupes autorisés et URL source. Combinez recherche sémantique et lexicale, utile pour « article 4.2 », un numéro de certification ou un acronyme rare.
3. Recherche avec filtrage des droits
Le système identifie l’utilisateur et le dossier actif. Il peut décomposer la question, mais conserve l’original dans les journaux.
Les autorisations s’appliquent avant la transmission au modèle. Il ne faut pas récupérer un document interdit puis demander au modèle de l’ignorer. Mots-clés, similarité et métadonnées sélectionnent les candidats, qu’un reranker peut reclasser.
Une règle d’abstention traite les recherches faibles. « Je n’ai pas trouvé de preuve validée » révèle un manque au lieu de le masquer.
4. Génération contrainte
Le modèle reçoit consigne, passages autorisés et format de sortie. Une matrice peut imposer : exigence, proposition, source, page et point à valider. Les instructions interdisent de compléter une donnée absente et distinguent citation, synthèse et hypothèse.
La génération peut préparer un plan ou un premier jet de mémoire technique, mais elle ne doit jamais inventer une certification, une disponibilité de consultant, un engagement de délai ou un prix. Ces informations viennent de systèmes maîtres ou d’une validation métier explicite.
5. Citations et retour au document d’origine
Une citation pointe vers le document, sa version et la page ou section. Le système vérifie que l’identifiant cité faisait partie du contexte et que le passage soutient l’affirmation associée.
Afficher cinq sources en bas d’une réponse ne suffit pas. Le lecteur doit savoir quelle source soutient quelle phrase et pouvoir ouvrir l’original. Les citations accélèrent la revue ; elles ne la remplacent pas.
6. Validation, publication et boucle de retour
Un responsable métier accepte, corrige ou rejette la proposition. Engagements, prix, CV, références clients et sécurité suivent une validation renforcée. Seule une version approuvée alimente le document final.
Les corrections ne sont pas réinjectées automatiquement. Un propriétaire contrôle portée, confidentialité et validité. Cette gouvernance relie l’analyse d’un RFP à une production traçable.
En amont, le workflow d’analyse automatique d’un DCE fournit les exigences atomiques, leurs citations et les statuts qui déclenchent la recherche.
Quelles sources indexer et avec quelles règles d’accès ?
Commencez par les sources fréquentes dotées d’un propriétaire. Voici un modèle à adapter.
| Source | Usage dans la réponse | Métadonnées minimales | Règle d’accès et validation |
|---|---|---|---|
| DCE actif et questions-réponses acheteur | Exigences, critères, clauses, échéances | Consultation, lot, version, pièce, page | Équipe bid du dossier ; dernière version seule |
| Réponses AO validées | Formulations et preuves réutilisables | Client, secteur, thème, date, statut | Exclure les brouillons ; accès selon confidentialité |
| Fiches de référence client | Périmètre, résultats, contacts de référence | Autorisation, période, secteur, date d’expiration | Utilisation externe seulement si autorisée |
| Référentiel qualité et sécurité | Processus, certifications, contrôles | Propriétaire, version, validité | Groupes habilités ; revue qualité ou RSSI |
| CRM et données de staffing | Contexte compte, compétences, disponibilité | Source maître, horodatage, niveau de sensibilité | Lecture à la demande ; ne pas figer dans l’index si volatil |
| Tarifs et modèles financiers | Hypothèses de prix et coûts | Entité, devise, période, approbateur | Accès restreint ; validation finance obligatoire |
| Sources publiques officielles | Réglementation et normes publiques | Éditeur, URL, date de collecte | Liste blanche ; contrôle de fraîcheur et de licence |
Séparez les corpus lorsque les frontières sont fortes : entités juridiques, clients cloisonnés, données classifiées ou environnements de production et de test. Un simple champ confidentialite: haute ne suffit pas si toute l’application peut interroger le même index avec des privilèges techniques excessifs.
Évaluer le RAG avant de mesurer les gains de temps
Constituez un jeu représentatif : exigences multi-documents, informations absentes, versions contradictoires, tableaux et accès interdits. Des experts identifient la réponse attendue et les passages probants.
Mesurez séparément les étages :
- recherche : proportion de questions pour lesquelles une preuve attendue figure dans les k premiers passages ;
- classement : rang des preuves et quantité de bruit remontée ;
- fidélité : proportion des affirmations soutenues par les passages cités ;
- citation : exactitude du lien, de la version et de la page ;
- abstention : capacité à refuser lorsque la preuve manque ou que l’accès est interdit ;
- opérationnel : délai, coût par requête, disponibilité et taux de corrections humaines.
Ne réduisez pas ces dimensions à un score. Le bon document peut être mal synthétisé ; une réponse élégante peut utiliser la mauvaise version. Le programme TREC du NIST sépare recherche, génération augmentée et chaîne complète (présentation du track RAG). Le profil GenAI du NIST couvre les risques sur tout le cycle de vie.
Relancez les tests à chaque changement de modèle, d’embeddings, de chunking, de droits ou de prompt. En production, surveillez recherches sans réponse, sources périmées et corrections récurrentes.
Exemple opérationnel fictif
L’exemple suivant est entièrement fictif et ne constitue ni un benchmark ni un résultat client.
Une ESN prépare un appel d’offres de 186 exigences. Son corpus autorisé contient 420 documents validés. L’équipe construit 60 questions, dont 8 sans réponse et 6 sur des contenus réservés à la finance.
Au premier essai, une preuve attendue apparaît dans les cinq premiers passages pour 41 des 46 questions répondables et accessibles. La revue détecte pourtant neuf affirmations mal soutenues. L’équipe corrige le découpage des tableaux, ajoute versions et expirations, puis impose une citation par affirmation.
Au test suivant, deux questions restent sans preuve et partent au propriétaire documentaire. Pour le dossier réel, le RAG préremplit une matrice ; technique valide les capacités, finance les chiffres et le bid manager le texte. Ces nombres illustrent une méthode, pas une promesse.
Confidentialité et sécurité : traiter le corpus comme un actif critique
Les DCE peuvent contenir données personnelles, prix, architectures ou secrets clients. Pour une documentation sensible destinée au RAG, la CNIL considère qu’un déploiement sur site peut être plus approprié ; avec un hébergement externe, responsabilités, accès, réutilisations et transferts doivent être encadrés (questions-réponses de la CNIL). Le choix dépend de l’analyse de risque.
Le guide de sécurité de l’ANSSI inclut base vectorielle, filtres et composants connectés. Il recommande sécurité sur tout le cycle de vie, droits stricts, tests et journalisation. Protégez aussi les journaux, qui peuvent contenir requêtes et extraits sensibles.
Considérez tout document comme non fiable : une instruction dissimulée dans un PDF peut détourner le modèle. Le RAG ne neutralise pas l’injection de prompt, rappelle le projet OWASP GenAI Security. Limitez les actions, isolez les outils et testez des documents hostiles.
Limites et erreurs de conception
Confondre pertinence et vérité. Le passage le plus proche sémantiquement peut être ancien, incomplet ou faux. Le statut et la validité comptent autant que la similarité.
Indexer sans propriétaire. Une base pleine de doublons, de brouillons et de réponses contradictoires industrialise l’incertitude.
Autoriser après la recherche. Les droits doivent contraindre la récupération elle-même, pas seulement l’affichage final.
Promettre zéro hallucination. Le contexte réduit certains écarts factuels, mais le modèle peut encore déformer, combiner ou surinterpréter les passages.
Valider uniquement la rédaction. Une réponse fluide peut contenir un engagement inexécutable. La conformité, le prix et les capacités restent sous responsabilité humaine.
Négliger l’exploitation. Les sources, modèles et règles changent. Sans supervision, réindexation contrôlée, tests de régression et gestion des incidents, la qualité se dégrade.
Offry ne commercialise pas un générateur autonome. Nous concevons, intégrons et opérons des agents IA sur mesure dans l’environnement du client, selon ses sources, ses habilitations et ses circuits de validation. Cette méthode d’intégration est aussi importante que le choix du modèle.
Checklist avant le passage en production
- Chaque source possède un propriétaire, un statut et une règle de conservation.
- Les doublons, brouillons et versions expirées sont exclus ou signalés.
- Le chunking respecte titres, clauses, tableaux et limites documentaires.
- Les métadonnées incluent version, validité, confidentialité et groupes autorisés.
- Les droits sont filtrés avant la transmission des passages au modèle.
- Chaque affirmation sensible peut renvoyer au passage et à l’original.
- Le système s’abstient lorsqu’aucune preuve suffisante n’est disponible.
- Un jeu de tests couvre recherche, génération, citations et accès interdits.
- Les prompts, sources récupérées, sorties et validations sont journalisés de façon proportionnée.
- Les injections indirectes, fuites de données et régressions ont été testées.
- Les responsabilités de validation métier, finance, juridique et sécurité sont attribuées.
- La maintenance de l’index et la réponse aux incidents sont organisées.
Pour replacer cette architecture dans le processus complet, consultez le guide pour répondre à un appel d’offres.
FAQ sur le RAG pour les appels d’offres
Un RAG supprime-t-il les hallucinations ?
Non. Il fournit au modèle des passages retrouvés dans un corpus, mais celui-ci peut encore mal les interpréter ou produire une affirmation non soutenue. Citations, abstention, tests et validation humaine restent nécessaires.
Le protocole pour éviter les hallucinations dans une réponse à appel d’offres transforme ces principes en contrôles de sources, matrice de validation et journalisation.
Faut-il indexer tous les anciens appels d’offres ?
Non. Indexez d’abord les contenus validés, utiles, autorisés et encore exacts. Les réponses perdues, brouillons et informations client non réutilisables doivent être exclues ou isolées.
Une base vectorielle suffit-elle ?
Rarement. Les appels d’offres contiennent des références exactes, tableaux et acronymes qui bénéficient d’une recherche lexicale, de filtres de métadonnées et parfois d’un reranking, en complément des vecteurs.
Le RAG doit-il être déployé sur site ?
Pas systématiquement. La sensibilité des documents, les exigences contractuelles, les transferts, les garanties du prestataire et les coûts d’exploitation déterminent l’architecture. Une analyse de risque documentée doit guider le choix.
Qui valide une réponse produite avec un RAG ?
Le responsable métier valide le fond ; finance, juridique, sécurité ou ressources humaines interviennent selon la donnée. Le bid manager conserve la responsabilité de la cohérence et de la version déposée.
Concevoir un RAG adapté à votre processus AO
Vous voulez cadrer une architecture RAG traçable, connectée à vos sources et opérée selon vos règles d’accès ? Réservez un échange avec Offry.