CRM agentique : ce qu’un prototype immobilier m’a appris

Depuis plus de cinq ans, une idée me revient : permettre à un conseiller immobilier de mettre son outil à jour sans interrompre son travail.

Il sort d’une visite, prend son téléphone et dit simplement : « J’ai terminé la visite avec Mme Dupont. Ajoute mon compte rendu à son projet d’achat et prépare la prochaine action. »

Il y a quelques années, ce scénario relevait surtout de la démonstration. Les modèles d’IA générative l’ont rendu techniquement accessible. Mais accessible ne veut pas dire utile, fiable ou prêt pour la production.

J’ai donc construit un prototype de CRM immobilier pour tester une question plus concrète : où l’IA peut-elle réellement enlever du travail à un conseiller, sans lui retirer le contrôle ?

Supprimer des gestes, pas ajouter un chatbot

Je n’ai pas cherché à reconstruire tout le cycle immobilier. Le prototype couvre principalement le mandat et ce qui l’entoure : contacts, projets d’achat ou de vente, biens, annonces, visites et offres. Il ne gère ni le compromis ni la vente définitive.

Ce périmètre réduit était volontaire. Un prototype doit répondre à une hypothèse précise, pas imiter un logiciel complet.

Le contact reste le centre de gravité. Une même personne peut être vendeuse, acquéreuse, liée à plusieurs projets et avoir un historique d’échanges. Cette structure permet de tester l’IA sur de vrais objets métier, plutôt que dans un chat isolé du reste du logiciel.

Voilà le premier point important pour une PME : ajouter une fenêtre de conversation à un outil existant ne le rend pas « agentique ». Le changement commence lorsque le système comprend le contexte d’une tâche, utilise les bonnes informations et propose une action dans le processus réel.

Séparer ce qui doit être certain de ce qui peut rester incertain

Le principal apprentissage n’a pas été le choix d’un modèle. Il a été de placer correctement la frontière entre le code classique et l’IA.

Une règle métier, un contrôle de droit d’accès, une validation obligatoire ou une mise à jour comptable doivent rester déterministes : même entrée, même résultat, avec des logs exploitables.

L’IA est plus adaptée à ce qui tolère une part d’incertitude :

• comprendre une demande formulée librement ;
• résumer un historique ;
• proposer un brouillon d’e-mail ;
• analyser une annonce ou des photos ;
• suggérer un ordre de priorité ;
• préparer un plan d’action.

Dans ces cas, le système produit une proposition. Il ne transforme pas une estimation en fait certain.

Cette distinction évite une erreur fréquente : confier à un modèle une décision qu’une règle simple exécuterait mieux, plus vite et à moindre coût. Si une automatisation classique suffit, je préfère l’automatisation classique.

Trois façons d’intégrer l’IA au logiciel

Dans le prototype, l’IA n’est pas cantonnée à une interface de chat. Elle intervient de trois manières.

1. Observer les événements métier

La création d’un prospect, un nouvel e-mail, un compte rendu de visite ou un changement de statut peuvent déclencher une analyse.

L’objectif est de réduire la saisie et d’apporter une recommandation au bon moment : enrichir une fiche, suggérer une relance, préparer un message ou créer une tâche. Par défaut, toute modification sensible reste soumise à une validation humaine.

2. Maintenir une mémoire courte et utile

Chaque contact et chaque projet disposent d’une synthèse courte : contexte de la relation, points d’attention, irritants et prochaine étape possible.

Cette mémoire n’a pas vocation à conserver tout ce qui a été dit. Elle doit rester lisible, révisable et soumise à une durée de conservation définie. C’est autant un choix produit qu’un garde-fou sur les données personnelles.

3. Analyser régulièrement le portefeuille

Des processus spécialisés examinent les informations disponibles et cherchent les situations qui méritent une action : projet sans nouvelle, annonce à améliorer, visite à préparer ou prospect à rappeler.

À ce stade, le prototype compte 15 agents spécialisés, 6 processus structurés sous forme de graphes, 19 gestionnaires d’événements et plus de 20 outils CRM. Ces chiffres décrivent un terrain d’expérimentation, pas une promesse de performance. Un système plus simple serait préférable si deux agents et trois règles couvraient le besoin.

Un exemple concret : préparer une visite sans perdre le contexte

Un client demande une visite par e-mail. Le système peut consulter l’agenda du conseiller, les caractéristiques du bien, la météo et la mémoire de la relation.

Si l’annonce met fortement en avant le jardin et que de fortes pluies sont prévues au créneau demandé, il peut proposer un autre horaire et préparer un brouillon de réponse.

Le point utile n’est pas que l’IA connaisse la météo. Une automatisation classique sait déjà récupérer une prévision. La valeur vient du rapprochement entre plusieurs éléments : la demande du client, la disponibilité du conseiller, l’argument principal du bien et le contexte de la relation.

Le conseiller garde la décision. Il peut accepter, modifier ou ignorer la suggestion.

L’autonomie doit être graduée

Je ne crois pas à un choix binaire entre « tout manuel » et « tout autonome ». Dans le prototype, l’autonomie évolue selon l’action :

• conseil : l’agent recommande, sans rien créer ;
• brouillon : il prépare un contenu ou une tâche à valider ;
• exécution encadrée : il réalise une action autorisée et journalisée ;
• orchestration semi-autonome : il enchaîne plusieurs étapes, avec des points de contrôle.

Un message comme « Je viens de voir ce client, voici les photos du bien, prépare le projet de vente » peut déclencher plusieurs opérations : retrouver le contact, créer un brouillon de projet, analyser les photos, proposer une description et rechercher des acheteurs correspondants.

Cela ne signifie pas que le système doit tout valider seul. Le niveau d’autonomie dépend du risque, de la réversibilité de l’action, de la qualité des données et des droits accordés. Envoyer une suggestion interne n’a pas le même impact que modifier une donnée contractuelle ou contacter directement un client.

Pourquoi j’ai utilisé Microsoft Agent Framework

J’ai testé plusieurs approches avant de retenir Microsoft Agent Framework. Son intérêt, pour ce prototype, tient moins à la création d’un agent isolé qu’à l’encadrement des processus : workflows sous forme de graphes, reprise après interruption, validation humaine, outils et télémétrie.

Cela fournit une base utile pour expérimenter sérieusement. Cela ne rend pas automatiquement un produit fiable. Les contrôles d’accès, les tests, la surveillance, la gestion des erreurs et les règles de conservation restent à concevoir dans l’application.

Le protocole MCP complète cette architecture en proposant une manière standard de connecter l’agent à des services externes. Le CRM peut utiliser un calendrier, un outil interne ou une source publique, mais aussi exposer certaines de ses propres capacités à un assistant autorisé.

L’expérimentation MCP de data.gouv.fr illustre bien l’intérêt et la limite : l’accès est aujourd’hui centré sur la consultation de données publiques, et la plateforme rappelle elle-même que les réponses d’un modèle ne constituent pas une source officielle.

Le support du protocole A2A ouvre aussi la possibilité de communiquer avec des agents construits sur d’autres technologies. C’est intéressant pour l’interopérabilité, mais ce n’est pas une raison suffisante pour complexifier un projet.

Ce que je conseillerais à une PME

Je ne commencerais pas par « construire un CRM agentique ». Je choisirais un seul processus fréquent, coûteux en temps et assez peu risqué pour être testé.

Avant de développer, je vérifierais cinq points :

1. Les données nécessaires existent-elles et sont-elles suffisamment fiables ?
2. L’action attendue est-elle clairement délimitée ?
3. Peut-on mesurer le temps évité ou la qualité gagnée ?
4. Quelles étapes exigent une validation humaine ?
5. Que se passe-t-il lorsque le modèle se trompe ou qu’un service externe ne répond plus ?

Le premier test devrait produire des recommandations ou des brouillons, pas agir partout dans le système. Si les équipes ignorent les suggestions ou passent plus de temps à les corriger qu’à faire le travail initial, il faut arrêter ou revoir le périmètre.

Le vrai sujet commence après la démonstration

Ce prototype m’a permis de confirmer qu’un logiciel métier peut devenir plus attentif au contexte et plus proactif, sans se transformer en boîte noire.

Le potentiel est réel : moins de ressaisie, des dossiers mieux préparés et des priorités plus visibles. Mais la valeur ne vient ni du nombre d’agents ni du choix du framework. Elle vient de la qualité du processus, des données et des garde-fous.

Un bon système agentique ne cherche pas à remplacer le conseiller. Il prépare, relie et propose. L’humain reste responsable des décisions qui comptent.