Pour éviter les hallucinations de l’IA dans une réponse à appel d’offres, reliez chaque affirmation à une source autorisée, imposez des citations vérifiables, permettez la réponse « information absente », contrôlez les calculs par des règles déterministes et confiez chaque validation sensible à une personne identifiée. Ces garde-fous réduisent le risque ; aucun dispositif sérieux ne promet zéro hallucination.
L’IA doit préparer une réponse traçable ; les responsables métier valident les faits, les engagements et la version déposée. Cette discipline s’intègre au processus pour répondre à un appel d’offres.
Définition opérationnelle d’une hallucination en appel d’offres
Le NIST emploie le terme de confabulation pour un contenu erroné ou faux produit avec assurance. Son profil de gestion des risques de l’IA générative traite ce risque sur tout le cycle de vie.
Dans une réponse AO, une hallucination est une sortie présentée comme factuelle sans être soutenue par la bonne source, dans sa bonne version et pour le bon périmètre. Même plausible, elle reste non fiable si le rédacteur ne peut pas remonter à sa preuve.
Cela inclut l’invention, la déformation d’une clause, la fusion de références, un tarif périmé ou une hypothèse transformée en engagement. L’enjeu est contractuel : l’article L2152-2 du Code de la commande publique qualifie d’irrégulière une offre qui ne respecte pas les exigences des documents de la consultation.
Typologie des erreurs à détecter
Invention de faits internes
Le modèle attribue au candidat une certification, une référence, une fonctionnalité ou une disponibilité absente des sources validées.
Confusion entre demande et capacité
Le CCTP exige une astreinte ; le modèle écrit que le candidat l’assure. Il a converti une demande de l’acheteur en capacité du soumissionnaire.
Mauvaise version ou mauvais périmètre
Une réponse exacte pour une autre filiale, un ancien DCE ou un lot voisin devient fausse ici. Entité, version, validité et droits de réutilisation doivent correspondre.
Citation décorative
La source existe, mais ne prouve pas la phrase. Une politique de sécurité, par exemple, ne démontre ni une certification ni sa validité.
Calcul ou transformation erronés
Les tableaux et calendriers exposent aux totaux incohérents, mauvaises unités et confusions de dates. Ces contrôles relèvent du code et des règles métier.
Omission présentée comme exhaustivité
Une synthèse correcte peut omettre une annexe, une condition ou une exception. L’exhaustivité doit être vérifiée séparément.
Mettre en place les garde-fous essentiels
Hiérarchiser et figer les sources
Créez un registre des sources autorisées. Pour le besoin : DCE courant, modifications et réponses officielles de l’acheteur. Pour le candidat : systèmes maîtres et documents approuvés, comme le référentiel qualité, les références autorisées, les données RH et la grille tarifaire.
Conservez identifiant, propriétaire, version, validité, périmètre, sensibilité et statut. Excluez les brouillons, contenus expirés et réponses non réutilisables. Cette provenance doit accompagner chaque exigence dès l’analyse de RFP par IA.
Une bibliothèque de réponses AO réellement réutilisable formalise précisément ces propriétaires, statuts, dates de révision et conditions d’emploi.
Exiger une citation par affirmation vérifiable
Structurez la sortie : affirmation, extrait, document, page ou section, version et niveau de validation. Le lien ouvre l’original. Une citation prouve une origine, pas l’approbation d’un engagement.
Refusez automatiquement toute référence absente du contexte. Vérifiez ensuite que le passage implique la phrase ; en cas de contradiction, alertez un humain.
Contraindre la sortie et permettre l’abstention
Interdisez de compléter une donnée manquante et imposez les états « sourcé », « à confirmer », « contradiction » ou « information absente ». Un champ critique reste vide sans validation de son propriétaire.
Séparez extraction, recherche de preuve et rédaction. L’erreur devient localisable et le mémoire technique reste fondé sur des preuves.
Réserver les contrôles exacts aux règles déterministes
Utilisez du code pour l’inventaire, les empreintes de fichiers, les dates, les formats, les formules, les totaux et les unités. Le modèle peut expliquer une anomalie, pas décider si un écart critique est acceptable.
Tableau risque vers contrôle
| Risque observé | Contrôle préventif | Preuve attendue avant publication |
|---|---|---|
| Certification inventée | Liste blanche issue du référentiel qualité | Certificat valide et validation qualité |
| Exigence transformée en capacité | Séparer corpus acheteur et corpus candidat | Source interne distincte du CCTP |
| Clause issue d’une ancienne version | Figer la version active du DCE | Empreinte et horodatage du fichier |
| Citation non probante | Vérifier le lien phrase-passage | Extrait précis relu par le propriétaire |
| Prix ou total incohérent | Recalculer hors LLM | Résultat du contrôle de formule et visa finance |
| Exigence omise | Comparer inventaire, matrice et pli | Statut explicite pour chaque exigence |
| Réponse sans preuve | Autoriser l’abstention | Mention « information absente » |
Construire une matrice de validation humaine
Une case « relu » ne dit ni ce qui a été contrôlé ni par qui. Attribuez chaque domaine à un responsable.
| Domaine | Validateur responsable | Ce qu’il contrôle | Condition de sortie |
|---|---|---|---|
| Conformité au DCE | Bid manager | Pièces, exigences, critères, formats, versions | Aucune exigence critique sans statut |
| Solution et delivery | Responsable métier | Faisabilité, périmètre, moyens, délais | Engagement compatible avec la capacité réelle |
| Prix | Finance | Hypothèses, unités, formules, marges, taxes | Modèle financier approuvé |
| Clauses | Juridique | Réserves, responsabilités, propriété, pénalités | Écarts acceptés ou signalés |
| Sécurité et données | RSSI et DPO selon le cas | Architecture, accès, données personnelles, sous-traitants | Mesures et responsabilités documentées |
| Pli final | Signataire habilité | Cohérence entre validations et documents déposés | Version finale identifiée et approuvée |
Conservez validateur, date, objet, statut et motif. Une modification postérieure à un visa rouvre les validations concernées.
Tester et journaliser sans créer un nouveau risque
Avant la production, testez des documents autorisés et annotés : information absente, versions contradictoires, tableaux, accès interdit, référence expirée et instruction malveillante. Évaluez séparément extraction, recherche, fidélité, citations, abstention et contrôles déterministes.
Ces scénarios peuvent être construits à partir du workflow d’analyse d’un DCE avec l’IA, afin de vérifier aussi l’inventaire des pièces et la couverture des exigences.
Relancez les tests après tout changement de modèle, prompt, règle, indexation ou corpus. Aucun seuil universel ne garantit une réponse sûre : les critères d’acceptation dépendent de la criticité et du contexte d’usage, comme le préconise le NIST.
Journalisez rôle de l’utilisateur, versions du prompt et du modèle, sources consultées, sortie, contrôles et décisions humaines. L’ANSSI recommande une sécurité sur tout le cycle de vie, incluant accès, flux et journalisation.
Ne copiez pas tout le DCE dans les logs. La CNIL recommande de tracer les opérations, de protéger les traces et d’en proportionner la conservation. Ses questions-réponses sur l’IA générative rappellent de vérifier entrées et sorties et de ne transmettre que les informations autorisées.
Exemple fictif clairement signalé
Cet exemple est entièrement fictif ; ce n’est ni un résultat client ni une promesse. Asteris Conseil répond à un marché de maintenance applicative. Le CCTP demande une astreinte ; l’IA écrit : « Asteris assure une astreinte permanente ».
Le contrôle classe la phrase « non sourcée » : le contexte contient la demande, mais aucune procédure interne approuvée. Il bloque la formulation. Le responsable delivery définit alors un engagement exact, que le bid manager rapproche du prix et le juridique de la clause.
Une politique de sécurité mentionne aussi un référentiel sans prouver une certification. La citation est rejetée et la réponse ne décrit que les mesures documentées. Le garde-fou rend l’absence de preuve visible ; il ne « trouve » pas seul la vérité.
Limites et erreurs de conception fréquentes
Croire qu’un bon prompt suffit. Une consigne claire réduit certaines dérives, mais ne corrige ni une source fausse, ni une mauvaise version, ni un accès excessif.
Présenter le RAG comme une garantie. La recherche augmentée fournit du contexte ; le modèle peut encore ignorer, mélanger ou surinterpréter les passages retrouvés.
L’architecture RAG pour les appels d’offres doit donc être évaluée séparément sur la recherche, la génération, les citations et le respect des accès.
Confondre citation et validation. Une citation prouve une provenance. Seul le propriétaire métier peut approuver un engagement futur, un prix ou une disponibilité.
Tout faire vérifier par la même personne. Le bid manager maîtrise le dossier, pas nécessairement les marges, la cybersécurité ou les conséquences juridiques. La revue doit suivre les compétences et les délégations réelles.
Journaliser sans gouvernance. Des traces exhaustives mais illisibles, trop accessibles ou conservées sans règle déplacent le risque au lieu de le réduire.
Réinjecter automatiquement les corrections. Une correction valable pour un client peut être confidentielle ou fausse dans un autre contexte. Elle doit être qualifiée avant d’enrichir le référentiel.
Automatiser le dépôt. La génération, la validation et la remise sont des responsabilités différentes. Une personne habilitée conserve le contrôle de la version envoyée.
Offry est un service sur mesure : nous concevons, intégrons et opérons le dispositif avec les équipes du client, ses sources et ses circuits de validation. Ce n’est pas un SaaS autonome. La méthode Offry part du risque métier et des responsabilités avant de choisir les modèles ou les composants.
Checklist anti-hallucinations avant dépôt
- Le DCE actif et ses éventuelles modifications sont identifiés par version.
- Chaque affirmation factuelle renvoie à un passage précis et accessible.
- Les sources acheteur et candidat sont séparées.
- Les brouillons, contenus expirés et références non autorisées sont exclus.
- Le système sait répondre « information absente » sans compléter.
- Les contradictions sont remontées à un responsable.
- Dates, montants, unités, formules et inventaires sont contrôlés hors LLM.
- Chaque engagement possède un validateur métier nommé.
- Les tests couvrent omissions, mauvaises versions, accès interdits et citations faibles.
- Les prompts, sources, sorties, contrôles et décisions sont traçables.
- Les journaux sont protégés et leur conservation est définie.
- Toute modification après validation rouvre les visas concernés.
- Le signataire contrôle la version exacte du pli final.
FAQ sur les hallucinations de l’IA en appel d’offres
Peut-on supprimer totalement les hallucinations d’une IA générative ?
Non. Les sources, contraintes, tests et validations humaines réduisent leur probabilité et leur impact, mais ne garantissent jamais leur disparition. Le bon objectif est de détecter les affirmations non prouvées avant qu’elles deviennent des engagements.
Un RAG suffit-il pour fiabiliser une réponse AO ?
Non. Un RAG améliore l’accès aux documents pertinents, mais il dépend de la qualité des sources, des métadonnées, des droits et de la recherche. Citations, abstention, contrôles déterministes et validation humaine restent indispensables.
Quelles informations doivent toujours être validées par un humain ?
Au minimum, les engagements de capacité et de délai, les prix, les références clients, les CV, les certifications, les réserves contractuelles et les éléments de sécurité. Le validateur doit être compétent et habilité pour le domaine concerné.
Comment vérifier qu’une citation soutient réellement une phrase ?
Ouvrez le document d’origine, contrôlez la version et le périmètre, puis vérifiez que le passage implique précisément l’affirmation. Une proximité de mots ou une mention générale du sujet ne constitue pas une preuve suffisante.
Faut-il conserver toutes les requêtes et réponses de l’IA ?
Pas sans analyse. Journalisez ce qui est nécessaire à la traçabilité, à la sécurité et à l’amélioration, puis protégez les traces et fixez une durée adaptée. Évitez d’y dupliquer inutilement des données sensibles ou personnelles.
Sécuriser votre chaîne de réponse AO
Pour cadrer un dispositif anti-hallucinations sur mesure, intégré et opéré selon vos sources et validations, réservez un échange avec Offry.