Comment un système IA se connecte-t-il à votre logiciel métier et qu'est-ce qui bloque sans API ?
Par Christopher Manglou, fondateur de ROUGAIL. Publié le . 8 min de lecture.
Un système IA n'a pas besoin de l'API de votre logiciel métier pour répondre à vos prospects : il lit la notification que le portail envoie déjà à l'agence par email. L'API sert à autre chose : écrire dans le logiciel le lead qualifié et l'échange, ou y lire ce qu'il détient, comme les dates de fin de mandat. Sans elle, la réponse part quand même, mais la fiche du logiciel reste incomplète et certaines tâches qui dépendent de ses données restent manuelles.
Un prestataire vous présente un système qui répond à vos demandes de portail en quelques minutes. Vous posez la question qui vient naturellement : « Est-ce que ça marche avec mon Hektor ? » La réponse honnête tient en deux parties. La première rassure, la seconde se vérifie.
Cet article explique ce dont un système IA a besoin dans votre logiciel métier, ce qu’il fait sans lui, ce que Netty, Hektor et Apimo ouvrent aujourd’hui aux prestataires. Il donne enfin une méthode pour vérifier votre propre cas avant de signer quoi que ce soit.
Votre éditeur n’ouvre pas son API : un système IA peut-il quand même répondre à vos prospects ?
Oui. Pour répondre à une demande de portail, un système n’a pas besoin de passer par votre logiciel métier. Il lit la demande là où elle arrive déjà : dans un email.
Quand un acquéreur remplit le formulaire de contact d’une annonce sur SeLoger, LeBonCoin ou Bien’ici, le portail envoie une notification à l’adresse que l’agence lui a indiquée. Ce message contient en général ce qu’il faut pour répondre : le bien concerné, le nom du prospect, ses coordonnées et le texte qu’il a écrit. Le formulaire de contact du site de l’agence peut fonctionner de la même façon.
Le système reçoit ces notifications sur une adresse propre à l’agence. Il lit le message, identifie le bien et la demande, puis répond au prospect par email, ainsi que par SMS quand un numéro mobile est fourni. Aucune de ces étapes ne passe par le logiciel métier.
Pendant ce temps, votre logiciel continue de faire ce qu’il fait déjà. Si votre éditeur propose la remontée automatique des demandes depuis les portails, la même demande y entre de son côté, sans ressaisie. Ce qu’il en fait ensuite est détaillé dans l’article consacré à ce que Netty, Hektor et Apimo n’ont jamais prétendu faire.
L’absence d’API ne bloque pas la réponse. Elle bloque autre chose.
À quoi sert l’API, si la réponse s’en passe ?
Elle sert à faire circuler l’information entre le système et votre logiciel métier, dans les deux sens. Sans elle, le système ne peut plus rien déposer dans le logiciel. Il ne peut en lire que ce que le logiciel exporte déjà de lui-même.
Une API, ou interface de programmation, est une porte que l’éditeur d’un logiciel ouvre à d’autres logiciels. Elle leur permet de lire certaines données ou d’en déposer d’autres, selon des droits que l’éditeur fixe. Ce n’est pas un réglage que l’agence active elle-même. C’est l’éditeur qui décide si la porte existe, à qui il l’ouvre et pour quelles données.
Deux usages comptent pour une agence :
- Écrire dans le logiciel. Déposer sur la fiche du contact ce que le système a appris : le projet, le budget annoncé, l’échéance, le résumé de l’échange, le rendez-vous calé. Le négociateur retrouve alors tout au même endroit, dans l’outil qu’il ouvre chaque matin.
- Lire dans le logiciel. Consulter ce que le logiciel détient, comme vos mandats et leur date d’échéance. Certaines automatisations en dépendent entièrement.
Entre les deux, la différence est celle qui sépare une gêne d’un blocage. Quand l’écriture manque, l’information existe, mais ailleurs que dans le logiciel. Quand la lecture manque, la tâche qui en dépend ne peut pas être automatisée.
Que proposent Netty, Hektor et Apimo aujourd’hui ?
Apimo et Modelo, qui exploite désormais Netty, présentent publiquement une API. Pour Hektor, aucune page ne la décrit sur le site de l’éditeur au 20 octobre 2026. Dans les trois cas, l’accès d’un prestataire se demande à l’éditeur : il ne se règle pas entre l’agence et son prestataire. Le tableau suivant reprend ce que leurs pages publiques montrent à cette même date.
| Logiciel | Ce que l’éditeur publie sur l’accès des prestataires |
|---|---|
| Apimo | Une page consacrée à son API, qui donne accès aux données des agences, aux annonces et aux contacts. L’éditeur précise qu’il est possible, « en fonction de vos droits », d’envoyer des informations « telles que des leads ». |
| Hektor, édité par La Boîte Immo | Aucune documentation destinée aux prestataires n’apparaît sur le site de l’éditeur. La question se pose donc directement à La Boîte Immo. |
| Netty, désormais Modelo Office | Une page consacrée à l’API de Modelo Office annonce un accès aux « biens, contacts, fiches acquéreur, tâches », pour l’intégration avec des outils tiers. Elle ne précise ni à qui l’accès est ouvert, ni à quelles conditions. |
Une API publiée n’est pas pour autant ouverte à tous : Apimo lie ce qu’un prestataire peut faire aux droits qui lui sont accordés. Un prestataire qui s’y connecte l’explique concrètement : MeerWeb, éditeur de sites d’agence, indique que ses identifiants d’accès sont « demandés à Apimo pour votre agence ». La demande part donc de l’agence, pour le prestataire qu’elle a choisi. La page de Modelo, elle, invite à demander une démonstration. À l’inverse, une absence de documentation publique ne prouve pas l’absence d’API. Elle signifie que la question se pose à l’éditeur.
Sans API ouverte, une voie existe encore pour lire, pas pour écrire. Hektor, par exemple, fournit un export de ses annonces pour alimenter le site de l’agence. MeerWeb décrit ainsi sa connexion à ce logiciel : un export au format Poliris, livré dans une archive à une adresse propre à l’agence, d’où son outil reprend l’ensemble du portefeuille de biens. Un export ne fait que sortir du logiciel : il ne permet d’y déposer ni un contact, ni une demande. Une intégration plus poussée suppose l’accord de l’éditeur. La Boîte Immo est ainsi entrée en 2023 au capital d’ImmoSign, en annonçant une solution « complètement intégrée » à Hektor.
Ces situations évoluent. Un éditeur peut ouvrir un accès, le restreindre ou le rendre payant d’une année sur l’autre. Ce qui compte est ce que l’éditeur vous confirme par écrit, pour votre abonnement, au moment où vous décidez.
Que se passe-t-il, tâche par tâche, quand la connexion manque ?
La plupart des tâches continuent de fonctionner : l’information vit dans le système et dans l’agenda du négociateur plutôt que dans le logiciel métier. Deux tâches du tableau ci-dessous en dépendent vraiment : l’alerte avant la fin d’un mandat et le dépôt d’une annonce dans le logiciel.
| Tâche | Ce dont elle a besoin | Sans connexion au logiciel métier |
|---|---|---|
| Répondre à une demande de portail | Lire la notification email | Fonctionne à l’identique |
| Qualifier le projet du prospect | Lire ses réponses par email ou par SMS | Fonctionne, la qualification se consulte dans le système |
| Retrouver l’échange sur la fiche du contact | Écrire dans le logiciel métier | Le négociateur consulte l’échange dans le système, ou le recopie s’il veut tout dans le logiciel |
| Caler le rendez-vous de visite | Lire et écrire dans l’agenda Google ou Outlook du négociateur | Fonctionne, cet agenda n’est pas le logiciel métier |
| Alerter avant la fin d’un mandat | Lire les dates d’échéance dans le logiciel métier | Ne peut pas être automatisé sans accès à ces dates |
| Publier une annonce rédigée par le système | Déposer l’annonce dans le logiciel métier, qui la diffuse aux portails | L’annonce est rédigée, puis copiée à la main dans le logiciel |
Une réserve sur le rendez-vous de visite : si vos négociateurs tiennent leur agenda dans le logiciel métier plutôt que dans Google ou Outlook, le calage du rendez-vous dépend lui aussi de la connexion.
La gêne principale est la fiche incomplète. Un négociateur qui ouvre le contact dans son logiciel peut ne pas voir ce que le prospect a déjà dit, puis lui reposer la question. Deux réponses existent : consulter l’échange dans le système avant d’appeler, ou recopier l’essentiel sur la fiche. Le choix dépend d’une question que seule l’agence tranche : tout doit-il vivre dans le logiciel métier, ou une partie de l’historique peut-elle vivre dans un autre outil ?
Comment savoir, avant de signer, ce qui est possible avec votre logiciel ?
La vérification tient en quatre gestes, sans rien acheter ni compétence technique. Les trois premiers ne concernent que votre agence et votre éditeur, le quatrième s’adresse au prestataire.
- Ouvrez une notification de portail récente. Repérez l’adresse qui l’a reçue et ce qu’elle contient : bien, coordonnées, message. C’est la matière à partir de laquelle un système répond. Si vos demandes n’arrivent que dans le logiciel métier, sans aucun email, la connexion devient alors la question centrale.
- Écrivez à votre éditeur. Trois questions, à recopier telles quelles :
- « Votre logiciel dispose-t-il d’une interface de programmation (API) ouverte à un prestataire choisi par l’agence ? »
- « Cet accès porte-t-il sur les contacts, les demandes entrantes, les biens, les mandats et leurs dates d’échéance ? En lecture, en écriture, ou les deux ? »
- « À quelles conditions et pour quel coût cet accès est-il ouvert ? Ce coût est-il à la charge de l’agence ou du prestataire ? »
- Vérifiez ce que vous pouvez exporter. Quand votre logiciel vous est fourni en ligne, sur abonnement, le règlement européen sur les données, dit Data Act, encadre déjà votre sortie : son article 25 impose que la liste des données exportables soit écrite au contrat. Ce n’est pas une connexion. C’est ce qui évite que vos données restent captives. Le détail figure dans l’article sur ce qu’une agence doit exiger d’un prestataire avant de signer.
- Demandez au prestataire un tableau tâche par tâche. Pour chaque tâche qu’il propose, il indique si elle passe par l’email, par l’agenda ou par votre logiciel métier. Tout ce qui dépend du logiciel se confirme avec votre éditeur avant la signature. Demandez aussi qui adapte la connexion quand l’éditeur modifie son interface, puis si cette adaptation est comprise dans l’abonnement. Demandez enfin par quel moyen son système lit ou écrit dans votre logiciel : une interface de programmation avec des identifiants demandés par l’agence, l’export des annonces, ou un module intégré par l’éditeur.
Ces quatre gestes peuvent conclure qu’il ne faut rien acheter. Si votre éditeur refuse l’accès et que la tâche qui vous intéresse est l’alerte de fin de mandat ou la publication d’annonces, un système ne pourra pas l’automatiser de bout en bout. Si c’est la réponse aux demandes du soir et du week-end, l’absence d’API ne change rien à la décision.
Que faut-il retenir ?
Un système IA lit vos demandes de portail dans les notifications email que l’agence reçoit déjà. Il y répond sans passer par votre logiciel métier, que celui-ci ouvre une API ou non. L’API sert à écrire dans le logiciel ce que le système a appris. Elle sert aussi à y lire ce que le logiciel détient, comme les dates de fin de mandat. Sans elle, la réponse part quand même, mais une partie de l’historique vit hors du logiciel et certaines tâches restent manuelles. L’accès se décide chez l’éditeur : posez-lui la question par écrit, puis demandez au prestataire ce qui, dans sa proposition, en dépend.