RAG sur CCTP et DPGF : architecture pour bureau d'études

Un bureau d'études reçoit un CCTP de 300 pages pour un nouvel appel d'offres. Dans les archives, 50 chantiers livrés au cours des cinq dernières années : leurs CCTP, leurs DPGF chiffrés, leurs BPU, leurs mémoires techniques gagnants. Tout est là. Personne ne peut relire 15 000 pages en 72 heures. Alors on repart de zéro, ou presque. C'est le problème que résout un système RAG sur corpus CCTP et DPGF : transformer cette mémoire dormante en assistant actif qui répond, cite ses sources internes, et génère un premier brouillon de réponse en quelques minutes.

Cet article ne décrit pas un outil du marché. Il décrit une architecture technique complète, de l'ingestion des documents à la génération citée, en passant par le chunking par article de CCTP, le retrieval hybride et les garde-fous contre les hallucinations. L'angle est celui d'un bureau d'études techniques ou d'une entreprise BTP qui veut capitaliser sur ses chantiers passés pour répondre plus vite et plus précisément aux nouveaux marchés.

Si vous cherchez un article sur l'extraction automatique depuis un CCTP unique, consultez notre guide extraire CCTP, DPGF et plans avec l'IA. Ici, le sujet est différent : construire la mémoire collective de 50 chantiers et l'interroger en temps réel.

Pourquoi la mémoire des chantiers passés est une ressource inexploitée

Un bureau d'études de taille intermédiaire livre 8 à 20 opérations par an. Sur dix ans, c'est 80 à 200 chantiers : autant de CCTP rédigés, de DPGF chiffrés, de BPU négociés, de mémoires techniques gagnants. Cette base documentaire représente plusieurs centaines de milliers d'euros d'heures ingénieur. Elle dort sur un serveur partagé, classée par dossier de chantier, pratiquement impossible à interroger.

Quand un nouvel AO arrive, le chef de projet fait un Ctrl+F dans quelques anciens documents, copie des passages qui semblent pertinents, et adapte. Ce travail de retrouvaille dure 2 à 4 heures par dossier. Multiplié par 30 à 50 AO par an, c'est une charge considérable. Et le résultat est inégal : les seniors connaissent les bons précédents, les juniors repartent de modèles génériques.

Le cas d'usage RAG sur corpus CCTP/DPGF attaque exactement ce problème. Ce n'est pas de l'extraction depuis un document unique — c'est la capitalisation systématique sur l'historique complet, rendue interrogeable en langage naturel. Un ingénieur pose une question : "Quelle isolation thermique avons-nous prescrite sur nos derniers chantiers de logements collectifs RE2020 ?" Le système retrouve les articles pertinents dans les 50 derniers CCTP, classe les réponses par pertinence, cite le marché et l'article exact, et génère un brouillon de prescription adapté au nouveau contexte.

Ce que contient le corpus et comment l'organiser

Avant de parler d'architecture technique, la question des données est plus importante que celle du modèle. Le corpus d'un BE ou d'une entreprise BTP se compose généralement de quatre types de documents, chacun avec ses contraintes de parsing spécifiques.

Les CCTP : la source principale

Les CCTP sont des documents Word ou PDF de 80 à 600 pages, structurés en lots (Lot 1, Lot 2...) et en articles numérotés (1.1, 1.2, 1.2.1...). La numérotation est rarement cohérente d'un marché à l'autre : un bureau d'études utilise une numérotation, le maître d'ouvrage en impose une autre dans le DCE, et les avenants viennent parfois tout renuméroter. C'est la principale difficulté du parsing.

Les CCTP rédigés en interne par le BET sont généralement en Word avec des styles de titre appliqués — ce qui facilite l'extraction hiérarchique. Les CCTP reçus d'un MOA pour chiffrage arrivent souvent en PDF scanné, avec une qualité OCR variable selon l'âge du document.

Les DPGF : tableaux structurés mais complexes

La DPGF (Décomposition du Prix Global et Forfaitaire) est le document de chiffrage quantitatif. Elle arrive sous forme de fichier Excel avec des onglets par lot, des cellules fusionnées, des formules de sous-totalisation et une hiérarchie de postes à plusieurs niveaux. L'extraction automatique rate systématiquement les sous-totaux et la structure hiérarchique si elle n'est pas traitée avec un parser dédié.

La vraie valeur de la DPGF dans le corpus RAG n'est pas d'en extraire des prix (confidentiels et volatils) mais de vérifier que chaque prescription du CCTP a bien un poste correspondant dans le chiffrage. Ce matching CCTP/DPGF est un sous-projet à part entière.

Les BPU et mémoires techniques gagnants

Le BPU (Bordereau de Prix Unitaires) contient les prix à l'unité utilisés pour valoriser les travaux supplémentaires. Il est précieux pour alimenter un retriever sur les postes fréquents et les ratios habituels du bureau. Les mémoires techniques gagnants sont la ressource la plus dense en savoir-faire : ils décrivent la méthode d'exécution, les moyens humains et matériels, et les arguments qui ont convaincu le maître d'ouvrage. Indexés dans le corpus, ils permettent de générer des ébauches de réponse méthodologique directement issues des dossiers gagnés.

Structuration du corpus : les métadonnées critiques

Sans métadonnées, le RAG ne peut pas filtrer. Sur chaque document ingéré, les champs suivants sont obligatoires :

Architecture type de bout en bout

L'architecture se décompose en cinq briques enchaînées. Chaque brique a ses choix techniques propres et ses pièges spécifiques au contexte BTP.

Ingestion          Parsing               Indexation             Retrieval              Génération
─────────────────────────────────────────────────────────────────────────────────────────────────
CCTP (Word/PDF) →  Extraction            Index vectoriel  →     Hybrid search     →    LLM avec
DPGF (Excel)       hiérarchique          par article CCTP       (dense + BM25)         prompt de
BPU (Excel)        par article           (Qdrant)               Filtres :              citation
Mémoires (Word)    OCR si scanné         Index structuré        lot, marché,           obligatoire
Plans annexes      Lien CCTP↔DPGF        (PostgreSQL)           phase, version         + refus si
                   Versioning avenants   Namespace/marché       Reranking              score < seuil
        

Brique 1 : parsing et ingestion des documents

Le parsing est l'étape la plus sous-estimée et la plus chronophage. Elle conditionne tout le reste. Un CCTP mal parsé produit des chunks incomplets qui génèrent des prescriptions tronquées — potentiellement dangereuses sur chantier.

CCTP en Word avec styles de titre

C'est le cas idéal. La hiérarchie des styles (Titre 1, Titre 2, Titre 3) permet une extraction structurée directe avec python-docx. Chaque article est extrait comme un bloc autonome avec son numéro, son intitulé et son contenu complet. La numérotation est récupérée depuis le texte du titre, pas depuis la structure Word (qui peut être incohérente).

CCTP en PDF natif

Un parser de qualité comme Unstructured.io ou LlamaParse extrait le texte avec sa structure approximative. Il faut ensuite un post-traitement qui détecte la numérotation des articles via des expressions régulières calibrées sur les patterns observés dans votre corpus (ex. : ^\d+\.\d+(\.\d+)? pour les numérotations classiques). Ce post-traitement représente 1 à 2 semaines de développement selon la variété des formats rencontrés.

CCTP scannés et OCR dégradé

Les marchés anciens arrivent souvent en PDF scanné. L'OCR de Google Document AI ou d'Azure Document Intelligence donne de meilleurs résultats que les solutions open-source sur les documents dégradés. Prévoir 3 à 5 semaines de travail supplémentaire si le corpus contient plus de 30 % de CCTP scannés. La numérotation des articles est particulièrement fragile à l'OCR : les chiffres "1.2.3" deviennent parfois "l.2.3" ou "1.2,3".

DPGF en Excel

Les DPGF sont des tableaux avec des cellules fusionnées, des onglets multiples et une hiérarchie implicite (poste principal, sous-postes, quantités, prix unitaires). Un parser Excel standard (openpyxl) extrait les cellules mais pas la structure. Il faut un script dédié qui reconstitue la hiérarchie en analysant les indentations, les formatages de cellule et la logique de numérotation. Ce script doit être testé et calibré sur une dizaine de DPGF représentatives avant de l'appliquer au corpus entier.

Brique 2 : chunking par article de CCTP

C'est le choix technique le plus critique de l'architecture. Le chunking par token fixe (512 tokens, 1024 tokens) est une erreur grave sur des CCTP.

Voici pourquoi. Un article de CCTP se présente ainsi :

Si ce texte est coupé après "Le vitrage sera de type feuilleté 44.4 obligatoire", le chunk suivant commence par "épaisseur 6+0,76+6 mm minimum" sans contexte. Le retriever peut retourner ce second chunk en réponse à une question sur les épaisseurs de vitrage, mais la prescription "feuilleté 44.4 obligatoire" sera absente. Une demi-prescription sur un critère de sécurité incendie ou de performance thermique peut conduire à une erreur de chantier.

La règle est donc absolue : un chunk = un article de CCTP complet. Si un article est très long (plus de 1500 tokens), on le découpe en sous-articles, jamais en milieu de phrase.

Cas des articles avec renvois normatifs

Les CCTP renvoient fréquemment vers des normes sans en inclure le texte : "conforme au DTU 45.1", "selon NF EN 1991-1-1". Si la norme n'est pas dans le corpus, le chunk est incomplet. Deux options :

• Indexer les normes référencées : intégrer les DTU et normes NF dans le corpus (gestion des droits AFNOR à prévoir). Le chunk article CCTP est alors lié au chunk norme par un champ de métadonnée normes_citees.
• Signaler explicitement la lacune : le prompt du LLM lui indique que si une norme citée dans le chunk n'est pas dans le corpus, il doit le signaler dans sa réponse plutôt que d'inventer son contenu.

La deuxième option est plus pragmatique pour un POC. La première est nécessaire si la précision normative est un enjeu fort (CCTP de lots techniques CVC ou structure notamment).

Brique 3 : embeddings adaptés au vocabulaire BTP

Le choix du modèle d'embeddings conditionne la qualité du retrieval sémantique. Les textes de CCTP ont un vocabulaire technique dense : acronymes (DTU, Eurocode, OPR, PPSPS), termes normatifs (feuilleté 44.4, Ug, Bbio, Cep), désignations de produits spécifiques. Un modèle d'embeddings entraîné sur du texte généraliste représente mal ces termes.

Modèles recommandés

BGE-M3 (BAAI, open-source) est la référence actuelle pour le français technique. Il couvre bien le vocabulaire BTP sans fine-tuning, peut être hébergé sur votre infrastructure (aucune donnée transmise à un tiers) et supporte nativement la recherche dense, sparse et hybride via un seul modèle. C'est le choix recommandé pour les BET avec des contraintes de confidentialité sur leurs marchés.

text-embedding-3-large (OpenAI) est une alternative solide si le traitement cloud est acceptable. Ses performances sur le français technique sont légèrement inférieures à BGE-M3 sur des corpus très normés, mais il est plus simple à intégrer.

Fine-tuning sur lexique BTP : si votre corpus représente plus de 5 000 documents, un fine-tuning sur des paires question-réponse issues de vos propres CCTP améliore significativement le recall sur les termes spécifiques à votre domaine (ex. : une entreprise de CVC qui travaille toujours sur les mêmes types de lots). Ce chantier représente 3 à 4 semaines de travail supplémentaire et n'est justifié qu'à partir d'un certain volume.

Évaluation avant déploiement

Quel que soit le modèle retenu, une évaluation sur un jeu de test est obligatoire. Constituez 50 à 80 questions représentatives de ce que les ingénieurs posent réellement (ex. : "Quelle performance thermique avons-nous imposée pour les menuiseries sur nos derniers logements collectifs ?") et mesurez le Recall@3 (la prescription pertinente est-elle dans les 3 premiers résultats ?) avant de déployer. Visez plus de 82 % selon les métriques de notre source technique.

Brique 4 : retrieval hybride — pourquoi BM25 seul ne suffit pas

Un retriever purement vectoriel (recherche sémantique) manque les termes normatifs très spécifiques. Si un ingénieur cherche "DTU 45.1 isolant sous chape", la recherche vectorielle peut retourner des résultats sémantiquement proches mais qui ne mentionnent pas explicitement "DTU 45.1". BM25 (recherche par mots-clés exacts) est imbattable sur ce type de requête.

À l'inverse, BM25 seul échoue sur les questions formulées différemment de la prescription originale. "Quelle épaisseur minimale pour le vitrage feuilleté ?" ne matche pas lexicalement avec "épaisseur 6+0,76+6 mm minimum" si l'ingénieur n'utilise pas exactement les mêmes termes.

La solution standard en 2026 est le retrieval hybride : on exécute les deux recherches en parallèle et on fusionne les scores via un algorithme de Reciprocal Rank Fusion (RRF). Les implémentations disponibles :

• Qdrant : supporte nativement le retrieval hybride dense + sparse depuis la version 1.7. C'est la base vectorielle recommandée pour ce cas d'usage.
• Elasticsearch / OpenSearch : excellent BM25 natif, intégration vectorielle mature. Pertinent si votre BET a déjà une infrastructure Elasticsearch.
• Supabase pgvector + pg_trgm : option plus légère pour un POC, combinant recherche vectorielle et full-text search PostgreSQL natif.

Reranking après retrieval

Le retrieval hybride retourne les 20 à 50 meilleurs chunks. Un reranker (Cohere Rerank ou un modèle cross-encoder open-source) reclasse ces chunks selon leur pertinence réelle par rapport à la question. Cette étape améliore significativement la précision des citations dans la réponse finale. Elle ajoute 0,5 à 1 seconde de latence, acceptable pour une interface de rédaction (pas de contrainte temps réel).

Brique 5 : génération avec citation obligatoire et garde-fous

C'est l'étape finale, et la plus visible pour l'utilisateur. Elle détermine si le système est un outil de travail fiable ou une source de risque.

Le prompt de génération

Le prompt doit imposer trois comportements non négociables :

1. S'appuyer exclusivement sur les chunks fournis, jamais sur les connaissances générales du modèle concernant les normes ou les prescriptions. Un LLM peut "se souvenir" d'une version périmée d'un DTU. Cette instruction doit être explicite et répétée.
2. Citer la source interne de chaque prescription : le marché, le lot et l'article exact. Format imposé : "(Réf. : CHT-2023-047, Lot 4, art. 4.3.2)". Sans citation, le passage est marqué comme non sourcé et l'ingénieur sait qu'il doit vérifier.
3. Signaler les lacunes de corpus : si aucun chunk pertinent n'est disponible sur un point demandé, le modèle répond "Aucune référence interne sur ce point — rédaction manuelle requise" plutôt que de générer une réponse générique.

Le garde-fou de refus par score

Avant même d'appeler le LLM, le score de similarité du meilleur chunk retourné est vérifié. Si ce score est inférieur à un seuil calibré (typiquement 0,72 en cosine similarity, à ajuster sur votre corpus), la requête est refusée sans génération. L'interface affiche : "Aucune correspondance suffisante dans les marchés précédents. Ce point requiert une rédaction originale."

Ce comportement doit être testé explicitement lors de la phase de validation, avec des questions qui n'ont délibérément pas de réponse dans le corpus (ex. : une prescription sur un type de lot que votre BET n'a jamais traité).

Exemple de sortie attendue

Versioning des avenants : un impératif souvent oublié

Un CCTP évolue en cours de projet via des avenants. Un avenant peut modifier, remplacer ou annuler des articles entiers. Si le corpus RAG n'intègre pas ces modifications, le retriever peut retourner des prescriptions périmées — et l'ingénieur qui s'appuie dessus introduit dans son nouveau CCTP des exigences qui ne correspondent plus à la réalité du chantier de référence.

La gestion du versioning est simple dans son principe mais demande une rigueur opérationnelle constante :

• Chaque nouveau document est ingéré avec un numéro de version incrémental.
• Les chunks de la version précédente passent en statut remplacé.
• Le retriever filtre par défaut sur statut = actif.
• L'accès aux versions précédentes reste possible pour des questions de traçabilité ("quelle était la prescription initiale avant l'avenant 2 du chantier X ?").

Le vrai défi n'est pas technique, c'est organisationnel : s'assurer que les avenants arrivent bien dans le pipeline d'ingestion et ne restent pas dans une boîte mail ou un dossier partagé non surveillé. Un workflow d'ingestion automatique déclenché par le dépôt d'un nouveau fichier dans un dossier dédié est préférable à un processus manuel.

Coûts, délais et intégration avec les logiciels existants

Indicateurs de coût

Ce qui rallonge les délais : les CCTP scannés avec OCR dégradé (+3 à 5 semaines de prétraitement), le matching CCTP/DPGF si inclus (+4 semaines), la gestion des droits AFNOR si vous intégrez les normes dans le corpus, et l'adoption terrain — les chefs de chantier et ingénieurs juniors ont besoin d'une interface ultra-simple, testée sur tablette avant tout déploiement en chantier.

Intégration avec les logiciels métier

Le RAG s'intègre via API dans les workflows existants. Aucun des ERP du marché (Batigest, Onaya, ProGBat, Cype) ne propose d'intégration native avec un système RAG maison. L'approche retenue est une API REST exposée par le RAG, appelée depuis des workflows d'orchestration (n8n, Make) qui injectent les réponses dans les ERP via leurs modules d'import.

Pour Batigest et ProGBat : l'import DPGF au format Excel structuré est la voie la plus robuste. Le RAG génère un brouillon de DPGF, l'ingénieur le valide, et le fichier Excel est importé dans l'ERP.

Pour Onaya : l'API REST d'Onaya (disponible sur les versions récentes) permet une intégration plus directe pour alimenter les postes de chiffrage depuis le RAG.

Pour Cype : le format BC3 (standard ouvert d'échange de données de chiffrage BTP) est la voie d'intégration la plus propre. Le RAG génère les prescriptions et postes au format BC3, importables directement dans Cype Engineering.

Les cinq pièges qui font échouer les projets RAG sur CCTP

Ces retours viennent de projets similaires accompagnés ou observés. Ils sont tous évitables avec une conception rigoureuse.

Piège 1 : chunker par token sans respecter les articles

Déjà développé plus haut, c'est le piège numéro un. Un chunk qui coupe un article en deux ne donne pas un résultat médiocre — il donne un résultat potentiellement dangereux. "Le vitrage sera feuilleté..." sans la suite "...44.4 obligatoire, épaisseur 6+0,76+6 minimum" est une prescription incomplète qui peut conduire un chef de chantier à accepter un vitrage non conforme.

Piège 2 : ne pas séparer les marchés dans l'index

Si tous les CCTP sont dans le même namespace, une question sur un chantier peut remonter des prescriptions d'un autre marché avec un contexte réglementaire différent. Les prescriptions RE2020 d'un logement collectif livré en 2025 ne sont pas transposables telles quelles à un ERP de 2019. Le namespace par marché avec des métadonnées de filtrage est la seule protection fiable contre ce risque.

Piège 3 : ignorer les renvois normatifs

Un CCTP dit "conforme au DTU 45.1". Si le DTU n'est pas dans le corpus, la réponse est incomplète. Le LLM peut "se souvenir" d'une version antérieure du DTU et la citer sans avertissement. La solution : soit indexer les normes, soit faire signaler explicitement au modèle que la norme citée n'est pas disponible dans le corpus.

Piège 4 : sous-estimer la complexité du parsing DPGF

Un parser Excel standard extrait les valeurs des cellules mais ignore la structure hiérarchique, les cellules fusionnées et les formules de sous-totalisation. Le résultat est un tableau aplati inutilisable. Prévoir deux semaines de développement spécifique pour le parser DPGF, avec validation sur une dizaine de DPGF représentatives du corpus.

Piège 5 : déployer sans validation terrain préalable

Un ingénieur BET peut valider la précision technique des citations. Mais c'est le chef de chantier ou l'ingénieur junior qui utilise l'interface au quotidien qui détecte si elle est réellement praticable. Les conditions terrain (tablette, connexion limitée sur chantier, temps de réponse, lisibilité des citations) doivent être testées avant le lancement. Un outil techniquement parfait mais inutilisé sur le terrain n'a aucune valeur.

Pour aller plus loin

• Extraire automatiquement CCTP, DPGF et plans avec l'IA : la brique amont de ce RAG — dépouiller un DCE entrant en 20 à 45 minutes pour alimenter le corpus ou préparer une réponse à chaud.
• Agent IA n8n pour répondre aux appels d'offres : comment orchestrer le RAG dans un workflow complet de réponse AO, de l'ingestion du DCE entrant à la génération du brouillon Word.
• Automatiser la rédaction de CCTP avec l'IA : générer de nouveaux CCTP à partir du corpus existant, avec contrôle de cohérence entre lots.
• Automatiser les métrés et quantitatifs avec l'IA : la chaîne complète du métré automatisé à la DPGF, complémentaire du RAG CCTP pour la réponse AO.
• IA et analyse de DCE pour bureaux d'études : extraire les exigences clés d'un dossier de consultation entrant, première étape avant d'interroger le corpus historique.
• Gestion documentaire intelligente pour bureaux d'études : la GED qui alimente le corpus RAG — organisation, versioning, droits d'accès.
• IA et BIM pour la maquette numérique : intégrer les données IFC dans le corpus pour enrichir le RAG avec les dimensions et quantités des projets passés.
• Réponse aux appels d'offres BTP par IA : ROI réel en heures gagnées : les chiffres concrets de gain de temps sur les dossiers AO avec ou sans RAG.
• Assistant IA interne RAG — Tensoria : notre offre de déploiement d'un RAG sur vos données internes, de l'audit au déploiement en production.
• Audit IA : cadrer votre projet RAG sur CCTP avec un diagnostic rapide de la qualité de votre corpus et de vos cas d'usage prioritaires.
• IA pour les bureaux d'études : l'ensemble des cas d'usage IA pour les BET, de la rédaction des CCTP à la gestion documentaire.
• IA pour le BTP : les applications de l'IA dans le secteur construction, du chantier à la réponse aux appels d'offres.

Ressources techniques externes :

• Documentation Qdrant — Hybrid Search : implémentation du retrieval hybride dense + sparse, directement applicable à un corpus CCTP.
• Unstructured.io (GitHub) : parser open-source pour documents PDF, Word et Excel, recommandé pour l'ingestion de CCTP et DPGF.
• Recommandations CNIL sur l'IA : cadre réglementaire applicable aux projets RAG sur données de marchés, notamment pour les BET soumis à des NDA.

Questions fréquentes