Agent IA réponse AO : long context ou RAG ?

Vous voulez déployer un agent IA pour accélérer vos réponses aux appels d'offres. Vous avez lu que Claude peut ingérer 200 000 tokens en une seule requête. Vous avez aussi lu que le RAG est le pattern de référence pour les bases documentaires d'entreprise. Lequel choisir ? La réponse honnête : ça dépend de votre situation, et le choix a des conséquences concrètes sur la qualité des drafts, le coût par dossier et la confidentialité de vos données.

Cet article n'est pas sur l'orchestration du workflow AO (nous l'avons couvert en détail dans notre guide n8n) ni sur le ROI global de l'IA sur les appels d'offres. C'est un article d'architecture, destiné à ceux qui ont déjà décidé de construire et qui veulent éviter de se retrouver avec un système qui hallucine des références ou qui coûte dix fois trop cher en tokens.

Nous allons passer en revue les trois approches disponibles, leurs limites respectives, la grille de décision que nous utilisons chez Tensoria pour nos clients BTP, bureaux d'études et ESN, et les pièges qui coûtent le plus cher à corriger en cours de projet.

Pourquoi ce choix d'architecture n'est pas trivial

Un agent de réponse aux appels d'offres travaille en réalité avec deux types de corpus très différents, et c'est là que la plupart des projets se trompent d'approche.

Le premier corpus, c'est le CDC de l'appel d'offres en cours : le CCTP, le règlement de consultation, la DPGF, le CCAP, parfois les plans. Ce document est nouveau à chaque AO, il n'est pas indexable à l'avance, et la moindre exigence manquée dans l'analyse peut éliminer votre dossier avant même la lecture technique. La précision est critique.

Le second corpus, c'est votre base de références internes : les réponses gagnantes des années précédentes, les fiches projets livrés, les CVs de l'équipe, les certifications, les méthodologies maison. Ce corpus grossit dans le temps, il peut atteindre plusieurs centaines de documents, et il est le matériau brut dont l'agent va extraire le contenu réutilisable pour construire le draft.

Ces deux corpus n'ont pas les mêmes caractéristiques. Ils n'appellent pas la même architecture. Et les confondre dans une seule approche "on met tout dans le contexte" ou "on passe tout en RAG" est la source principale des déceptions en phase pilote.

Approche 1 : le long context, ses atouts et ses vraies limites

Comment ça fonctionne sur un CDC

Avec Claude 3.5 Sonnet (200 000 tokens) ou GPT-4o (128 000 tokens), vous pouvez charger le DCE complet en une seule requête. L'agent reçoit l'intégralité du dossier de consultation, et vous lui demandez d'en extraire les exigences clés, les critères de notation et leur pondération, les contraintes de format et les points différenciants à adresser.

L'avantage est réel : aucune information n'est perdue par découpage en chunks. Avec le RAG, un chunk mal délimité peut couper une exigence en deux, perdre la pondération d'un critère ou ignorer un renvoi entre documents. Sur un CDC où chaque exigence compte, la lecture complète par le modèle est plus fiable que la récupération fragmentée.

Les limites que les benchmarks ne montrent pas

La première limite est ce que les chercheurs appellent le "lost in the middle" : les modèles LLM sont moins précis sur les informations situées au milieu d'un très long contexte que sur celles placées au début ou à la fin. Sur un CDC de 150 pages où les exigences techniques sont réparties du début à la fin du document, cette dégradation devient perceptible.

La deuxième limite est le coût. Un CDC de 80 pages représente environ 90 000 tokens en entrée. À 3 € pour 1 000 000 tokens en entrée (tarif Claude Sonnet 4), cela fait environ 0,27 € par analyse. C'est négligeable sur 40 AOs par an. Mais si vous relancez le modèle plusieurs fois pour affiner les sections, ce qui arrive systématiquement en pratique, le coût par dossier monte vite. Et le long context ne résout pas le problème du corpus de références internes : vous ne pouvez pas mettre 300 mémoires techniques passés dans la même fenêtre.

La troisième limite est la latence. Générer la réponse à partir d'un prompt de 100 000 tokens prend plusieurs dizaines de secondes. Ce n'est pas bloquant pour un usage asynchrone, mais c'est à anticiper si vous voulez des retours quasi temps réel dans votre interface.

Quand le long context seul est suffisant

Il fonctionne bien dans deux cas précis : quand votre entreprise répond à des AOs très standardisés (même type de marché, même structure de dossier) et que la majeure partie du contenu est produite par l'expert plutôt que récupérée dans un historique. Et quand vous êtes en phase de POC avec peu de réponses historiques disponibles, le long context vous permet de démarrer rapidement sans avoir à construire une base vectorielle.

Approche 2 : le RAG sur la base de références internes

Le RAG résout le problème du corpus historique

Quand votre base de références dépasse une cinquantaine de documents, le RAG devient indispensable. Le principe : chaque réponse gagnante passée, chaque fiche projet, chaque CV et chaque certif est découpée en chunks sémantiques, encodée en vecteurs et indexée dans un vector store (Qdrant, Weaviate ou Chroma selon votre stack).

Quand l'agent travaille sur un nouvel AO, il extrait les mots-clés des exigences du CDC, interroge la base vectorielle et récupère les passages les plus pertinents de votre historique. Il construit ensuite le draft de chaque section à partir de ce contenu, adapté au contexte du nouveau marché.

C'est ce que nous déployons chez les bureaux d'études et les ESN qui répondent à des volumes importants d'AOs avec une base de références riche. Le taux de réutilisation des sections remontées par le RAG se situe entre 70 et 85 % quand la base est homogène et bien structurée.

Les limites du RAG qu'il faut anticiper

La première limite est la plus critique en contexte AO : le risque d'hallucination de références. Si le chunk récupéré mentionne un chiffre de projet (budget, nombre d'utilisateurs, durée de mission) et que le modèle le réutilise en le déformant légèrement pour qu'il colle mieux au nouveau contexte, vous vous retrouvez avec une référence erronée dans votre mémoire technique. Dans un AO public où les références peuvent être vérifiées par le pouvoir adjudicateur, c'est un risque d'élimination. Le RAG doit être configuré en mode strictement sourcé : l'agent cite les extraits exacts, il ne les paraphrase pas librement sur les données factuelles.

La deuxième limite est la qualité du chunking. Un CCTP de 80 pages découpé en chunks de 512 tokens sans tenir compte de la structure logique du document va produire des chunks qui coupent des tableaux en deux, séparent une exigence de sa pondération, ou mélangent deux corps de métier dans le même fragment. La phase de préparation des données, parsing PDF, découpage sémantique, enrichissement par métadonnées, représente souvent 40 % de l'effort total du projet.

La troisième limite : le RAG ne résout pas l'analyse du CDC courant. Vous ne pouvez pas indexer à l'avance un CDC que vous n'avez pas encore reçu. Pour l'analyse des exigences du nouveau marché, vous avez besoin d'une autre stratégie, c'est là que le long context entre en jeu.

Ce que doit contenir la base de références pour que ça marche

Une base RAG efficace pour les AOs est structurée autour de trois types de documents :

• Fiches projets livrés (une fiche d'une à deux pages par projet) : contexte client, mission réalisée, résultats mesurables, technologies ou méthodes utilisées, durée, budget. C'est le contenu que le modèle va adapter pour rédiger les sections "Références similaires" de vos réponses.
• Sections méthodologiques validées : approche projet, organisation de la mission, livrables types, planning type, par type de marché. Ces sections sont les plus stables et les plus récupérables d'un AO à l'autre.
• Profils et CVs équipe structurés : compétences, expériences passées par secteur, certifications. Indispensables pour les sections "Équipe proposée" des mémoires techniques ESN et bureaux d'études.

La règle d'or : si votre équipe n'a pas formalisé cette base avant de démarrer le projet IA, la constitution de la base documentaire sera le vrai projet, le développement technique en sera le prolongement.

Approche 3 : l'architecture hybride recommandée en production

Le principe : deux corpus, deux stratégies

L'architecture que nous recommandons pour les structures répondant à plus de 20 AOs par an combine les deux approches en les appliquant à leur corpus naturel :

• Long context sur le CDC entrant : le dossier de consultation du nouvel AO est chargé en intégralité dans la fenêtre de contexte de Claude. L'agent extrait les exigences, les critères de notation et leur pondération, les contraintes de format et les points différenciants à adresser. Zéro perte d'information sur le CDC qui décide de votre qualification ou de votre élimination.
• RAG sur la base de références internes : pour chaque section de la réponse à construire, l'agent interroge la base vectorielle et remonte les passages les plus pertinents de l'historique. Il adapte ce contenu au contexte du nouveau marché sans repartir de zéro.

Les deux résultats sont combinés dans le prompt de génération de chaque section : l'agent dispose à la fois des exigences précises du CDC courant et du contenu de référence pertinent de votre historique. C'est le pattern "context engineering" : donner au modèle exactement l'information dont il a besoin au bon moment, ni plus ni moins.

Le flux de traitement complet

Voici comment ce flux se matérialise en pratique, dans une stack LangGraph ou n8n :

1. Ingestion du DCE : parsing des fichiers PDF et DOCX via PyMuPDF ou Azure Document Intelligence, extraction du texte structuré.
2. Analyse CDC en long context : envoi du DCE complet à Claude avec un prompt d'extraction structuré (exigences obligatoires, critères de notation, pondérations, format attendu, délai de remise). Sortie : un JSON structuré des exigences.
3. Décomposition en sections : l'agent planifie les sections de la réponse à partir de la structure du CDC et des exigences extraites.
4. RAG par section : pour chaque section, requête sémantique sur la base vectorielle interne. Filtrage par métadonnées (type de marché, secteur, taille similaire). Récupération des 3 à 5 chunks les plus pertinents avec leur score de pertinence.
5. Génération de chaque section : prompt combinant les exigences de la section (du CDC), les passages de l'historique (du RAG) et les contraintes de format. Le modèle produit un draft sourcé.
6. Checklist de conformité : vérification automatique que chaque exigence obligatoire du CDC est adressée dans le draft.
7. Export et soumission à l'expert : génération du DOCX via python-docx ou Google Docs API, notification avec le draft et la checklist.

La grille de décision par volumétrie

Voici la grille que nous utilisons en première session client pour orienter l'architecture :

Le choix du LLM selon votre contexte

Claude 3.5 Sonnet pour le long context et la qualité rédactionnelle

Pour les sections qui nécessitent une qualité rédactionnelle élevée, méthodologie, présentation de l'approche projet, argumentation sur les critères qualitatifs, Claude 3.5 Sonnet reste le modèle de référence en 2026. Sa fenêtre de contexte de 200 000 tokens couvre la quasi-totalité des CDCs rencontrés en marchés publics français. Il gère bien les instructions longues et les contraintes de format complexes.

La limite : c'est un modèle cloud. Tout document que vous lui envoyez transite par les serveurs Anthropic. Pour la plupart des bureaux d'études et des PME BTP répondant à des marchés publics classiques, ce n'est pas un problème. Pour les ESN ayant des NDA stricts avec leurs clients grands comptes, ou les structures travaillant sur des marchés de défense ou d'OIV, c'est rédhibitoire.

Mistral on-premise pour la confidentialité

Mistral Large, déployé en local via Ollama (pour les petits volumes) ou vLLM sur GPU (pour la production), offre une fenêtre de contexte de 128 000 tokens et une qualité rédactionnelle suffisante pour les sections standard des mémoires techniques. Aucun document ne sort de votre infrastructure.

Le coût d'infrastructure est à intégrer au TCO : un GPU A100 ou H100 en location cloud coûte entre 2 et 4 € de l'heure. Pour un usage intermittent (pas de traitement en temps réel), une instance à la demande peut rester économique. Pour un usage intensif, le calcul doit être fait au cas par cas.

GPT-4o est une troisième option viable, avec une fenêtre de 128 000 tokens et une qualité comparable à Claude sur les sections courtes. Il s'impose naturellement si votre stack est déjà intégrée dans l'écosystème Microsoft Azure (Azure OpenAI Service, SharePoint, Teams).

Intégrations : Batigest, Onaya, HubSpot, n8n

L'agent ne vit pas en isolation. Les structures qui en tirent le plus de valeur sont celles qui l'intègrent dans leurs outils métiers existants plutôt que de le faire fonctionner comme un outil parallèle que personne n'utilise.

Pour les PME BTP et artisans sur Batigest ou Onaya : l'agent peut lire les éléments de chiffrage existants (BPU, prix unitaires) pour pré-remplir la DPGF et générer le mémoire technique en cohérence avec l'offre financière. L'intégration passe par l'export CSV ou Excel de ces ERPs, il n'existe pas d'API native dans ces outils.

Pour les ESN et cabinets de conseil sur HubSpot ou Salesforce : l'agent peut alimenter les opportunités CRM (création automatique de la fiche AO, attachement du draft généré, suivi du statut) et récupérer dans le CRM les informations sur les contacts existants dans l'organisation acheteuse, un contexte précieux pour personnaliser l'introduction du mémoire technique.

Pour l'orchestration : n8n reste la stack de référence pour les structures qui veulent un système de workflow visuel, auto-hébergeable et intégrable à leurs outils sans développement backend lourd. LangGraph s'impose quand vous avez besoin d'un état persistant complexe (plusieurs passes d'analyse, boucle d'affinement des sections, gestion d'erreurs granulaire). Make est une alternative à n8n si votre équipe est à l'aise avec les outils no-code et que le volume d'AOs traités reste sous 10 par mois.

La base de références internes : le vrai projet, pas l'IA

C'est le point sur lequel tous nos projets AO butent à un moment ou à un autre, et sur lequel nous insistons systématiquement en phase de cadrage.

L'agent est aussi bon que la base dans laquelle il puise. Si vos références projets ne sont pas formalisées, si les mémoires techniques gagnés sont des DOCX éparpillés dans des dossiers réseau sans structure, si les fiches projets font 20 pages de rapport au lieu d'une fiche d'une page par projet, si les CVs équipe n'ont pas été mis à jour depuis 18 mois, alors le RAG va remonter des contenus inutilisables.

La conséquence la plus fréquente : le modèle comble les lacunes par de la génération libre. Il invente des chiffres plausibles pour les références manquantes, déforme les résultats pour les adapter au contexte du nouveau marché, ou amalgame deux projets distincts pour en construire un qui n'a jamais existé. En AO public, ces références peuvent être vérifiées. C'est un risque d'élimination, voire de sanction.

La bonne approche : avant de démarrer le développement de l'agent, commencer par un atelier de structuration de la base de références. Définir le format de fiche projet standard (contexte, mission, livrables, résultats, équipe, budget, durée, technologies). Demander à chaque chef de projet de remplir rétrospectivement les 10 à 15 derniers projets livrés. Ce travail prend 2 à 4 semaines mais c'est lui qui déterminera la qualité de l'agent, pas le choix entre Claude et Mistral.

Coûts et délais : POC, MVP, TCO annuel

Les chiffres ci-dessous sont basés sur les projets que nous avons livrés ou cadrés en 2025-2026 pour des bureaux d'études, des ESN et des PME BTP entre 20 et 200 salariés :

Ce qui rallonge le planning de façon systématique : la constitution de la base de références (fiches projets non formalisées, réponses gagnantes éparpillées), la calibration de la qualité rédactionnelle (plusieurs itérations sur des AOs de référence pour affiner les prompts), et l'intégration avec les APIs de veille AO qui sont parfois mal documentées ou instables.

Les quatre pièges qui coûtent le plus cher

Piège 1 : lancer le développement avant d'avoir la base de références

Sans base structurée, le POC va "fonctionner" sur les 5 ou 10 AOs de test que vous lui fournissez manuellement, et s'effondrer le jour où vous essayez de le passer à l'échelle sur votre vrai historique. Construisez la base en parallèle du développement, pas après.

Piège 2 : ne pas configurer le RAG en mode strictement sourcé

La configuration par défaut de la plupart des frameworks RAG autorise le modèle à "compléter" l'information manquante par de la génération libre. En contexte AO, c'est inacceptable sur les données factuelles (chiffres de références, durées, budgets, effectifs). Configurez explicitement le système prompt pour que le modèle cite les extraits exacts et indique "information non disponible dans la base" quand il ne trouve pas, plutôt que d'inventer.

Piège 3 : sous-estimer le temps de validation humaine

Les équipes qui espèrent diviser le temps de réponse AO par 5 sont souvent déçues. Le gain réaliste est de 40 à 60 % du temps de rédaction. Le draft réduit l'effort mais ne l'élimine pas : l'expert doit valider, affiner et signer intellectuellement chaque réponse. Un draft de mauvaise qualité crée plus de travail de correction qu'il n'en économise. Communiquez ce cadre dès la phase de cadrage pour éviter les désillusions.

Piège 4 : choisir le modèle le moins cher pour les sections techniques

Les sections de méthodologie, d'organisation de la mission et de différenciation technique sont celles qui font la différence entre un AO gagné et un AO perdu. Ce n'est pas le bon endroit pour économiser sur le modèle. Un draft de section méthodologique produit par un modèle de faible qualité nécessite autant de temps de correction qu'une rédaction manuelle. Réservez les modèles légers aux tâches d'extraction et de classification ; utilisez Claude Sonnet ou GPT-4o pour la génération des sections à valeur ajoutée.

Garde-fous indispensables avant toute mise en production

Trois règles non négociables avant de passer ce type d'agent en production chez un client :

• Relecture humaine obligatoire sur toutes les données factuelles : références projets, chiffres, dates, noms de clients, résultats. Aucune donnée factuelle ne doit sortir sans validation de l'expert. Le draft est un point de départ, pas une sortie finale.
• Citation systématique des sources dans le draft : chaque section du draft doit mentionner les références internes dont elle est issue. Cela permet à l'expert de vérifier la pertinence du matching et de corriger rapidement si le RAG a remonté une référence hors sujet.
• Feedback loop sur les résultats AO : tracker systematiquement si les AOs où le draft agent a été utilisé ont été gagnés ou perdus, et pourquoi. C'est le seul moyen de mesurer l'impact réel et d'identifier les sections où le prompt ou le RAG nécessitent des ajustements.

Si vous avez des exigences de confidentialité fortes, marchés de défense, clients OIV, clauses NDA strictes sur vos références projets, lisez notre article sur les architectures IA compatibles avec les contraintes de confidentialité en entreprise avant de choisir votre stack.