OCR et RAG dans l'immobilier : de la pile de documents au moteur de connaissance

Le problème : 200 documents, et personne pour les lire

Un programme immobilier génère une quantité absurde de papier — ou plutôt de PDF, de scans, de fichiers joints. Entre le dépôt du permis de construire et la levée de la garantie parfait achèvement, un programme de taille moyenne produit facilement 200 à 400 documents : études de sol, dossier PC avec plans et notices, devis de lot gros-oeuvre, charpente, plomberie, électricité, diagnostics techniques, contrats VEFA, avenants, PV de réception, mainlevées... Je ne parle pas des échanges email. Je parle des documents structurants.

Pendant 17 ans, j'ai vécu ce problème de l'intérieur. La réalité, c'est qu'environ 80 % du temps dit "d'analyse" est en fait du temps de recherche. On ne cherche pas à comprendre un document — on cherche d'abord à retrouver l'information dans le bon document, à la bonne page, dans le bon tableau.

Quelques exemples concrets pour ceux qui ne viendraient pas du métier :

• La SHAB dans un permis de construire. La surface habitable (SHAB) est la donnée clé qui détermine votre prix de vente unitaire, vos droits à construire, votre bilan. Elle est mentionnée dans la notice descriptive, parfois dans le formulaire Cerfa, parfois dans une annexe au règlement de lotissement — rarement au même endroit selon le bureau d'études. Retrouver la SHAB définitive après un modificatif de PC peut mobiliser une demi-heure de lecture attentive si vous ne savez pas exactement où chercher.
• La comparaison de trois devis de maçonnerie. Chaque entreprise a son propre format. L'un présente ses postes HT avec une ligne "installation de chantier" en tête, l'autre l'intègre dans chaque lot, le troisième ne l'affiche pas. Comparer des prix au m² de mur de refend entre trois devis de format différent, c'est soit une heure de tableur manuel, soit une source d'erreur.
• Les conditions suspensives d'un contrat de réservation VEFA. Le lot 14B a été réservé il y a 8 mois. L'acquéreur relance sur la levée de la condition liée au prêt. Dans quelle version du contrat ? Quel est le délai exact mentionné ? Est-ce la version avec avenant ou sans ? Sans un outil pour interroger vos documents, vous ouvrez cinq PDF manuellement.

Ce n'est pas un problème de compétence. C'est un problème d'organisation de l'information. Et c'est exactement ce que l'OCR et le RAG permettent de résoudre — à condition de les implémenter correctement.

Ce qu'est l'OCR — et pourquoi il n'existe pas un seul bon moteur

L'OCR (Optical Character Recognition) est la technologie qui transforme une image — scan, photo, PDF numérisé — en texte brut lisible par une machine. Sans OCR, un scan d'étude géotechnique est une image opaque. Avec OCR, c'est un texte interrogeable.

La difficulté, c'est que tous les documents ne se ressemblent pas. Un PDF généré nativement par un logiciel (Word, AutoCAD, logiciel de devis) est propre : les caractères sont vectoriels, l'OCR n'est souvent même pas nécessaire, il suffit d'extraire le texte. Un scan d'un courrier de mairie sur papier légèrement froissé, c'est une autre histoire. Un tableau de métrés avec des colonnes fusionnées photographié en réunion de chantier, encore une autre.

C'est pourquoi il n'existe pas de moteur OCR universellement supérieur. Voici les trois approches que j'ai retenues dans ma stack :

Tesseract — la référence open source

Tesseract est le moteur OCR open source historique, maintenu par Google. Il est gratuit, rapide, et donne d'excellents résultats sur des documents propres, bien numérisés, avec une typographie standard. Un contrat VEFA scanné à 300 dpi, un courrier de notaire, une attestation d'assurance bien cadrée — Tesseract s'en sort très bien. Ses limites apparaissent sur les mises en page complexes (tableaux multi-colonnes, formulaires Cerfa avec cases à cocher) et sur les documents dégradés.

PaddleOCR — meilleur sur la complexité et les tableaux

PaddleOCR, développé par Baidu, est une alternative plus récente qui surpasse Tesseract sur plusieurs points importants pour l'immobilier. Sa détection de mise en page est meilleure : il identifie les régions de texte, les tableaux, les headers, les colonnes. Pour un devis de maçonnerie avec un tableau de 40 lignes et 6 colonnes, PaddleOCR reconstitue la structure tabulaire là où Tesseract produirait un flux de texte linéaire. Il gère aussi mieux les documents bilingues et certaines écritures cursives.

Mistral OCR — le recours IA pour les cas difficiles

Mistral OCR (via l'API Mistral) est un moteur d'extraction documentaire basé sur un modèle multimodal. Il traite le document comme une image et comprend son contenu de manière contextuelle — ce qui lui permet de gérer des cas où les moteurs classiques échouent : documents très dégradés, annotations manuscrites dans les marges d'un plan, formulaires non standard. Il est plus lent et plus coûteux que les moteurs locaux, ce qui en fait naturellement un recours de dernier niveau.

Ce qu'est le RAG — ou comment donner une mémoire documentaire à un LLM

RAG signifie Retrieval-Augmented Generation. C'est une architecture qui permet à un modèle de langage (LLM) de répondre à des questions en s'appuyant sur une base de documents réels, plutôt qu'uniquement sur sa connaissance générale issue de l'entraînement.

Pour comprendre pourquoi c'est utile, voici la distinction que je résume souvent ainsi :

ChatGPT improvise avec sa culture générale. Un agent RAG, lui, a lu tous vos documents — et peut vous dire précisément ce qui est écrit dans le contrat de réservation du lot 14B, article 7, signé le 12 mars 2025.

Techniquement, un système RAG fonctionne en trois étapes :

1. Indexation — découper et encoder vos documents

Chaque document est d'abord découpé en fragments (chunks) — des blocs de texte de taille raisonnable, généralement entre 300 et 800 tokens, avec un chevauchement pour ne pas casser le contexte entre deux chunks. Chaque fragment est ensuite converti en un vecteur numérique (embedding) via un modèle d'embedding — dans mon cas, les embeddings Mistral. Ce vecteur représente le sens du texte dans un espace mathématique à haute dimension. Ces vecteurs sont stockés dans une base de données vectorielle — j'utilise pgvector sur PostgreSQL.

2. Recherche sémantique — trouver ce qui ressemble à votre question

Quand un utilisateur pose une question, cette question est elle aussi convertie en vecteur. Le système cherche ensuite dans la base les chunks dont le vecteur est le plus proche du vecteur de la question — c'est la recherche par similarité cosinus. Le résultat n'est pas une correspondance exacte de mots-clés (comme un Ctrl+F), mais une correspondance sémantique : si vous demandez "quel est le délai de rétractation ?" et que le document mentionne "l'acquéreur dispose d'un délai de dix jours calendaires", le RAG fait le lien même si les mots ne correspondent pas exactement.

3. Génération — le LLM répond en s'appuyant sur les sources retrouvées

Les chunks les plus pertinents sont injectés dans le contexte du LLM, avec la question de l'utilisateur. Le modèle rédige une réponse fondée sur ces extraits — et peut citer les sources. L'hallucination est drastiquement réduite : le modèle ne répond plus de mémoire, il répond à partir de vos documents réels.

Cas d'usage concrets en immobilier

Assez de théorie. Voici quatre cas d'usage que j'ai modélisés ou directement implémentés, qui illustrent ce que ces technologies changent concrètement dans le quotidien d'un promoteur ou d'un AMO.

Extraction automatique d'un permis de construire

Un dossier de permis de construire déposé comprend en général entre 15 et 40 pièces : formulaire Cerfa, plans de masse, coupes, façades, plan de situation, notice architecturale, notice ERP si applicable, étude thermique préliminaire, tableau des surfaces... La SHAB, la SDP (surface de plancher), la hauteur maximale, le numéro de parcelle cadastrale, les conditions suspensives liées à l'archéologie préventive — ces données sont réparties sur plusieurs documents sans standardisation.

Un pipeline OCR + extraction structurée permet de traiter l'ensemble du dossier PC à l'ingestion et de produire une fiche synthétique : SHAB par niveau, SDP totale, hauteur faîtage, date de dépôt, numéro de dossier en mairie, conditions particulières identifiées. Ce qui prenait 45 minutes de lecture attentive prend quelques secondes de traitement — et la fiche est versionnée à chaque modificatif.

Comparaison automatisée de devis entreprises

C'est probablement le cas d'usage qui dégage le plus de valeur opérationnelle. Trois devis pour le lot plomberie : Entreprise A présente ses postes en unités d'oeuvre (prix/point d'eau), Entreprise B en forfait par logement, Entreprise C en bordereau détaillé avec matériaux séparés de la main d'oeuvre. Comparer ces devis manuellement, c'est une heure de travail pour un économiste de la construction expérimenté.

Un pipeline OCR + normalisation des données peut extraire les lignes de chaque devis, les mapper sur un référentiel de lots standardisé, et produire un tableau comparatif à poste équivalent. Les différences de périmètre (ce qu'une entreprise inclut qu'une autre exclut) sont signalées. Le coût total par logement est calculé sur une base homogène.

Automatisation KYC des acquéreurs

Dans le processus de réservation VEFA, la constitution du dossier acquéreur est un goulot d'étranglement chronique. Pièces d'identité, KBIS pour les SCI et personnes morales, justificatifs de domicile, attestation de financement — chaque pièce doit être vérifiée, les données extraites, les cohérences contrôlées (le nom sur la CNI correspond au nom sur le justificatif de domicile, la date de validité du KBIS est conforme...).

Un pipeline OCR sur les documents déposés par l'acquéreur permet d'extraire automatiquement les champs clés, de vérifier les cohérences, et d'alerter le chargé de commercialisation uniquement sur les anomalies. Les dossiers conformes sont validés automatiquement. Le temps de traitement d'un dossier complet passe de 20 minutes à moins de 2 minutes.

Recherche sémantique dans les contrats VEFA

C'est ici que le RAG prend tout son sens. Sur un programme de 40 logements, vous avez 40 contrats de réservation, potentiellement avec des avenants et des versions successives. Un acquéreur appelle pour savoir quelle est la condition suspensive liée à son financement. Un notaire demande à quelle date a été fixée la date prévisionnelle d'achèvement. Un investisseur veut savoir si son contrat prévoit une clause de renonciation à recours.

Avec un RAG indexé sur vos contrats, ces questions se posent en langage naturel et reçoivent une réponse précise avec citation de la clause source. Sans RAG, c'est une recherche manuelle dans des PDF — souvent délégable, donc souvent retardée.

Ce que j'ai construit dans BeForBuild

Je ne vais pas vous vendre un discours sur "ce qu'on pourrait faire avec l'IA dans l'immobilier". Je vais vous décrire ce que j'ai effectivement construit et mis en production — parce que je suis l'un et l'autre : le promoteur qui avait besoin de ces outils, et le développeur qui les a construits.

Le pipeline OCR multi-moteurs

Dans BeForBuild, chaque document uploadé passe par une chaîne de traitement séquentielle. La première étape est une détection de la nature du document : est-ce un PDF natif (texte extractible directement) ou un PDF image/scan (OCR nécessaire) ? Pour les PDFs natifs, on extrait le texte directement via une librairie d'extraction. Pour les autres, on entre dans le pipeline OCR.

Le pipeline tente d'abord l'extraction avec Tesseract, en configurant la langue (français), le mode de segmentation de page adapté au type de document détecté. Si le score de confiance retourné par Tesseract est inférieur à un seuil (typiquement 0,65 sur les caractères reconnus), on bascule sur PaddleOCR. Si PaddleOCR échoue également ou retourne un texte incohérent, Mistral OCR est appelé en dernier recours via l'API. Ce schéma en cascade garantit qu'on utilise le moteur le plus rapide et le moins coûteux pour les cas simples, et qu'on ne consomme les ressources des moteurs plus lourds que lorsque c'est nécessaire.

Ce pipeline est orchestré via un Cloudflare Worker qui utilise les Workflows de Cloudflare — une primitive qui permet de gérer des tâches longues avec état persistant, retry automatique et gestion des timeouts. L'OCR de 40 pages d'un dossier PC ne peut pas tenir dans une seule requête HTTP sans riques de timeout. Les Workflows découpent le traitement en étapes atomiques, chacune reprise en cas d'échec.

Le pipeline RAG sur pgvector

Une fois le texte extrait, il est découpé en chunks de 512 tokens avec un overlap de 64 tokens pour préserver la continuité sémantique aux frontières. Chaque chunk est enrichi de métadonnées : identifiant du document parent, numéro de page, type de document (PC, devis, contrat VEFA...), programme associé, date d'ingestion.

Les embeddings sont générés via l'API Mistral (modèle mistral-embed), qui produit des vecteurs de dimension 1024. Ces vecteurs sont stockés dans PostgreSQL avec l'extension pgvector, dans une table dédiée avec un index HNSW pour les recherches approximatives rapides. Pour une base de 10 000 chunks, la recherche des 5 plus proches voisins prend moins de 50ms.

L'agent conversationnel BeForBuild interroge cette base à chaque question. La requête utilisateur est embeddie, les 8 chunks les plus proches sont récupérés, injectés dans le contexte système avec le prompt métier, et Mistral génère une réponse sourcée. L'utilisateur peut voir quels documents ont été consultés pour produire la réponse.

Ce qui change pour les métiers

Les outils que je viens de décrire ne sont pas des gadgets de démo. Ils changent la manière dont le travail est organisé — et qui peut faire quoi.

Moins de saisie manuelle, moins d'erreurs

La saisie manuelle des données issues des documents est une source d'erreurs sous-estimée dans les organisations immobilières. Quand un assistant de programme retranscrit à la main les surfaces d'un tableau Excel à partir d'un PDF de bilan architecte, les erreurs de copie arrivent. Quand un chargé de commercialisation entre manuellement la date prévisionnelle d'achèvement dans le CRM depuis le contrat VEFA, il peut saisir 2026 à la place de 2027. Ces erreurs semblent bénignes — elles ne le sont pas quand elles alimentent un reporting livré à un investisseur.

Un pipeline d'extraction structurée sur documents réduit cette friction à la source. La donnée entre dans le système une fois — au moment de l'ingestion du document — et se propage dans les différents modules sans ressaisie.

Le focus sur les décisions, pas sur la recherche

Un responsable de programme ou un AMO ne devrait pas passer sa journée à chercher des informations dans des PDFs. C'est pourtant ce qui se passe dans la plupart des organisations immobilières, faute d'outils adaptés. Le temps cognitif de qualité — celui qu'on consacre à arbitrer entre deux partis architecturaux, à évaluer la solidité financière d'un sous-traitant, à négocier avec un acquéreur difficile — ce temps est rogné par les tâches de recherche documentaire.

Quand l'information est instantanément accessible, on pense autrement. On pose des questions qu'on ne posait pas avant parce qu'on savait que la réponse demanderait une heure de recherche. On vérifie des hypothèses qui auraient sinon été acceptées sans contrôle. On gagne en précision sur les données sans y consacrer plus de temps.

L'avantage de celui qui connaît le métier

Il existe une asymétrie importante entre un développeur qui construit un pipeline documentaire pour l'immobilier sans connaître le secteur, et un développeur qui a passé 17 ans à manipuler ces documents. Cette asymétrie se manifeste à chaque point de décision technique :

• Savoir que la SHAB et la SDP sont deux surfaces différentes avec des règles de calcul différentes — et que confondre les deux dans un pipeline d'extraction fausse tout ce qui vient ensuite.
• Savoir qu'un contrat de réservation VEFA comporte des articles obligatoires fixés par l'article R261-28 du CCH — ce qui permet de structurer l'extraction sur des ancres textuelles stables.
• Savoir qu'un devis de charpente bois n'a pas la même structure qu'un devis de charpente métallique — et que les normaliser sur le même référentiel nécessite une étape de mapping qui ne s'invente pas.
• Savoir que le diagnostic de performance énergétique (DPE) a changé de méthode de calcul en 2021 — et que les anciens DPE dans votre base ne sont pas comparables aux nouveaux sans une règle de conversion.

Ces connaissances ne s'acquièrent pas en lisant la documentation technique. Elles viennent du terrain. Et c'est ce qui fait que les meilleurs pipelines documentaires pour l'immobilier ne seront pas construits par des ingénieurs data qui ont lu des papiers sur le RAG, mais par des praticiens qui ont vécu le problème de l'intérieur — et appris à coder pour le résoudre.

C'est, en tout cas, le pari que j'ai fait avec BeForBuild. Et les résultats sur les cas d'usage réels me confirment que c'est la bonne approche.