Pourquoi un agent IA métier bat ChatGPT à plate couture dans l'immobilier

L'illusion du généraliste

ChatGPT est impressionnant. Il rédige, reformule, explique, synthétise. Et il le fait avec une fluidité qui donne l'impression d'avoir affaire à quelqu'un de compétent. C'est précisément là que le piège se referme.

Demandez-lui : "Quel est le taux de marge sur mon programme de 42 logements à Lorient ?" Il va vous répondre. Avec assurance. Il va probablement évoquer les ratios habituels en promotion — 8 à 12% de marge nette selon le segment — peut-être citer une méthode de calcul, construire une réponse qui semble raisonnée. Et elle sera entièrement fausse, parce qu'il ne sait pas une seule chose : vos chiffres réels.

Il ne connaît pas votre coût foncier réel, votre CAHT contractualisé, vos honoraires de maîtrise d'œuvre, votre taux de commercialisation actuel, vos appels de fonds déjà émis, votre GFA en cours. Il ne connaît pas votre programme. Il vous invente une réponse plausible sur la base de ce qu'il a lu sur internet.

Ce comportement s'appelle l'hallucination. Ce n'est pas un bug qu'on va corriger dans la prochaine version. C'est une caractéristique structurelle des LLMs généralistes : ils sont entraînés à produire des textes vraisemblables, pas des données vraies. Un modèle généraliste sans ancrage dans vos données n'a aucun moyen de distinguer une réponse correcte d'une réponse inventée — et il ne le signale pas.

Pour un promoteur immobilier, où une erreur de 0,5 point de marge sur un programme de 10 M€ représente 50 000 € d'écart, faire confiance à une réponse inventée n'est pas une option. Il faut un outil qui travaille avec vos données — pas avec les données de tout le monde.

Ce qu'est vraiment un agent IA métier

Un agent IA métier n'est pas un chatbot amélioré. La différence fondamentale est dans l'architecture : un chatbot répond, un agent agit.

Techniquement, un agent IA repose sur ce qu'on appelle le tool-use (ou function calling). Au lieu de simplement générer du texte, le modèle de langage décide quels outils appeler en fonction de votre question. Ces outils sont des fonctions réelles qui s'exécutent dans votre système :

• calculer_marge(programme_id, hypotheses) — interroge votre base de données, applique votre logique métier, retourne un résultat numérique fiable
• lire_bilan(programme_id) — récupère le bilan financier courant depuis votre base de données en temps réel
• rechercher_documents(query, programme_id) — fait une recherche sémantique (RAG) dans vos propres documents contractuels
• analyser_foncier(adresse) — interroge DVF, PLU, GeoRisques, BDNB et retourne une synthèse structurée

Le LLM orchestre ces appels. Il reçoit votre question en langage naturel, décompose ce qu'il faut faire, appelle les bons outils dans le bon ordre, et synthétise les résultats en une réponse lisible. C'est ce qu'on appelle une boucle agentique : raisonnement → action → observation → raisonnement suivant.

À cela s'ajoute le RAG (Retrieval-Augmented Generation) : vos documents — contrats GFA, bilans promoteurs, conventions foncières, cahiers des charges — sont vectorisés et stockés dans une base de données vectorielle (pgvector dans le cas de BeForBuild). L'agent peut les retrouver par similarité sémantique et les injecter dans son contexte de réponse. Il ne "sait" pas ce que disent vos contrats : il les lit, en temps réel, quand la question le requiert.

Enfin, la mémoire de session permet à l'agent de maintenir le fil d'une conversation : si vous avez commencé à parler du programme de Lorient, il se souvient que les questions suivantes portent sur ce même programme. Pas besoin de tout répéter à chaque message.

Exemple concret : l'agent BeForBuild en action

Voici une interaction réelle avec l'agent de BeForBuild. La question posée :

"Quel est le taux de marge de ce programme si le coût foncier augmente de 5 % ?"

Voici ce que l'agent fait, étape par étape :

1. Appel de l'outil lire_bilan — L'agent récupère le bilan financier actuel du programme depuis la base de données : CAHT contractualisé, coût foncier actuel, coûts de construction, honoraires, frais financiers, TVA applicable, marge nette cible initiale.
2. Appel de l'outil calculer_marge avec l'hypothèse foncier +5 % — La fonction applique votre modèle de calcul exact (celui que vous avez configuré, avec vos règles de gestion), recalcule le bilan complet avec la nouvelle base foncière, et retourne le taux de marge résultant.
3. Comparaison avec la marge cible initiale — L'agent calcule le delta entre la marge cible du dossier et la marge simulée, et vérifie si le programme reste dans les seuils d'approbation.
4. Synthèse structurée — La réponse finale : "Avec un coût foncier en hausse de 5 %, le taux de marge passe de 9,2 % à 7,8 %, soit un écart de -1,4 point. Le programme reste au-dessus du seuil minimum de 7 % fixé dans les paramètres. Impact en valeur absolue : -87 400 € sur la marge nette."

Pas d'hallucination. Pas de chiffre inventé. Chaque donnée dans la réponse est issue d'un appel à votre base de données réelle ou d'un calcul appliqué à des données réelles. L'agent ne sait rien par lui-même — il sait où aller chercher.

Pourquoi les 17 ans de terrain changent tout

Construire un agent IA pour la promotion immobilière, ce n'est pas prendre un LLM généraliste et lui coller quelques prompts dessus. C'est modéliser un métier avec toute sa complexité — et pour ça, il faut connaître le métier.

Quelques exemples concrets de ce que vous ne pouvez pas construire sans expérience terrain :

SHAB vs SDP. La Surface Habitable et la Surface de Plancher ne sont pas interchangeables. L'une détermine la commercialisation, l'autre les droits à construire autorisés par le PLU. Un agent qui confond les deux dans un calcul de densité produit des résultats inexploitables — et potentiellement illégaux.

Les conditions suspensives dans un contrat VEFA. Une "condition suspensive d'obtention de financement" a une valeur juridique et une date limite précises. Un agent qui répond à un acquéreur sans distinguer "condition levée", "condition en attente" et "condition caduque" ne rend pas service — il crée du risque.

L'impact d'un écart de marge. Sur un programme de 50 logements à 250 000 € de prix de revient moyen, soit un CAHT de 12,5 M€, 0,5 point de marge représente 62 500 €. Ce n'est pas un détail de calcul. C'est la différence entre un programme qui passe en comité d'engagement et un qui est retoqué.

Ces connaissances ne s'apprennent pas dans une documentation API. Elles viennent de 17 ans passés à monter des bilans, à négocier des fonciers, à gérer des chantiers en retard, à expliquer des appels de fonds à des acquéreurs inquiets. C'est ce savoir-là qui s'est encodé dans les 86 contraintes d'intégrité SQL de la base de données BeForBuild.

Ces contraintes ne sont pas des validations techniques banales. Ce sont des règles métier : un taux de TVA de 5,5 % n'est applicable que sous certaines conditions de zone géographique et de plafond de prix ; un appel de fonds ne peut pas dépasser le stade d'avancement déclaré ; une résidence ne peut pas avoir simultanément un statut "commercialisé" et un statut "permis non purgé". Ce sont les leçons apprises à la dure, encodées en SQL pour qu'un agent IA ne puisse jamais les violer — même si le LLM voulait improviser.

Use cases à fort ROI : trois exemples concrets

Voici trois cas d'usage où un agent métier produit un retour sur investissement mesurable, rapidement.

1. Agent FAQ acquéreurs VEFA

Chaque programme génère un flux continu de questions acquéreurs : date de livraison prévisionnelle, conditions suspensives encore en cours, étendue de la Garantie Parfait Achèvement, modalités des appels de fonds, personnalisations encore possibles. Ces questions sont répétitives, prévisibles, et accaparent le temps des responsables de programmes.

Un agent connecté à la base contractuelle du programme — contrats de réservation, actes de vente, planning de chantier — peut répondre à environ 80 % de ces questions sans intervention humaine. Il cite la clause contractuelle source, donne la date exacte issue du planning, et oriente vers le responsable de programme uniquement quand la question sort du périmètre structuré. Le temps libéré est réel et immédiat.

2. Agent d'analyse foncière

Vous avez une adresse. Vous voulez savoir si le terrain vaut la peine d'être étudié sérieusement. Aujourd'hui, cette pré-faisabilité demande plusieurs heures de recherche manuelle : consulter le PLU de la commune, interroger DVF pour les valeurs foncières comparables, vérifier GeoRisques pour les contraintes environnementales, récupérer les données BDNB pour estimer les besoins énergétiques si réhabilitation, croiser avec les données de tension locative.

Un agent foncier fait tout ça en séquence, en quelques minutes : il interroge chaque source via ses API respectives, croise les résultats, et produit une fiche de pré-faisabilité structurée avec un score synthétique et les points de vigilance identifiés. Ce n'est pas une décision — c'est un filtre. Il permet de trier rapidement les opportunités et de concentrer l'analyse humaine sur les dossiers qui le méritent vraiment.

3. Agent de suivi de chantier

Le suivi d'un chantier produit des données en continu : avancements hebdomadaires, situations de travaux des entreprises, PV de réunion de chantier, rapports OPC, révisions de planning. Ces données restent souvent dans des silos — un tableur, un dossier partagé, des emails — et personne ne fait la synthèse transversale en temps réel.

Un agent de suivi connecté à ces sources détecte proactivement les signaux d'alerte : un lot dont l'avancement déclaré dépasse le budget consommé, un écart croissant entre le planning initial et le planning actualisé, une situation de travaux soumise sans PV de réception correspondant. Il ne remplace pas le suivi humain — il le complète en faisant les corrélations que personne n'a le temps de faire manuellement, et en alertant avant que le problème devienne une crise.

Ce qui ne sera pas automatisé

Il faut être honnête sur les limites — pas par modestie, mais parce qu'un outil mal calibré fait plus de dégâts qu'un outil absent.

La négociation foncière ne sera pas automatisée. Pas parce que l'IA ne peut pas analyser des données — elle le fait très bien. Mais parce qu'une négociation foncière n'est pas une optimisation mathématique. Elle implique de lire le vendeur, de comprendre ses contraintes personnelles (succession, urgence financière, attachement sentimental au terrain), de poser les questions dans le bon ordre, de savoir quand se taire. Ce sont des compétences relationnelles que 17 ans de terrain affinent et qu'aucun modèle de langage ne reproduit.

Le jugement de localisation non plus. "Je connais ce quartier. Ce n'est pas le bon programme pour ici." Ce type de jugement intègre des données que personne ne va jamais entrer dans une base de données : le tissu commercial du quartier, la sociologie des habitants, l'effet d'une ligne de tramway attendue depuis dix ans, le souvenir d'un programme concurrent qui a mal vieilli deux rues plus loin. L'IA peut vous donner des indicateurs. Le terrain vous donne la conviction.

La relation client en situation difficile — un acquéreur qui a peur, un retard à annoncer, un défaut à gérer — requiert une présence humaine et une capacité d'empathie que l'automatisation dégrade, pas améliore.

Comment commencer

La plupart des projets IA échouent pour la même raison : ils essaient de tout faire d'un coup. "On va mettre de l'IA partout." Ce n'est pas une stratégie, c'est un chemin vers un PoC qui ne passe jamais en production.

Commencez par un seul cas d'usage, bien délimité, à fort enjeu. Pas "l'IA pour notre métier" — mais "un agent qui répond aux questions des acquéreurs sur leur contrat" ou "un outil qui pré-analyse les opportunités foncières". Un périmètre clair permet de mesurer le résultat, d'itérer vite, et de construire la confiance interne avant de passer à l'échelle.

Construisez la fondation de données d'abord. Un modèle de langage brillant sur des données sales produira des résultats inutilisables. La qualité de la donnée est le vrai déterminant de la qualité d'un agent métier. Avant de choisir quel LLM utiliser, posez-vous la question : est-ce que mes données sont structurées, cohérentes et accessibles programmatiquement ? Si la réponse est non, commencez par là.

Évitez le hype. Vous n'avez pas besoin du modèle le plus récent ni de l'architecture la plus sophistiquée. Vous avez besoin d'un agent simple, fiable, qui fait une chose bien, connecté à des données propres. La sophistication vient après la fiabilité — jamais avant.

Et si vous n'avez pas les ressources en interne pour construire ça, faites-vous aider par quelqu'un qui comprend à la fois le code et le métier. Parce que l'un sans l'autre produit soit un outil techniquement correct mais métier­iquement inutilisable, soit une belle présentation PowerPoint qui ne passera jamais en production.